Olá pessoal,
depois de um longo período sem postar estou voltando ao meu ritmo normal de posts.
O assunto principal desse post é exatamente o motivo pelo qual eu fiquei tanto tempo sem postar: "O Trabalho". Todos na área de informática querendo ou não já passaram pelo fato de ter que trabalhar bem além do esperado para suprir o prazo de algum projeto. Você que trabalha com pesquisa, suporte, desenvolvimento no ritmo de fábrica (como eu) ou qualquer assunto relacionado a área de TI está sujeito a ter que fazer o chamado "dar o gás", "fazer o algo a mais" ou os outros nomes que são dados a isso. Embora alguns digam que está errado, ou que isso é culpa de nós analistas que não sabemos impor nossas vontades, eu sinceramente acho que isso faz parte da profissão, e que querendo ou não sempre irá acontecer.
O que eu realmente quero discutir nesse post é: Quais são os fatos que levam os prazos dos projetos a não serem suficientes?
Voltando ao meu exemplo, no mês de julho eu trabalhei 28 dos 31 dias, fiquei lá depois das 22 horas uns 15 dias e virei noites em 5 dias, sendo que dois desses dias era final de semana. O que leva um projeto calculado com tanta precisão pelo gerente de projetos a ser um fiasco dessa forma em termos de prazo? Nós, como representantes da fábrica de software (desenvolvimento e testes) somos a ponta do Iceberg, realmente o fim da linha, depois que o projeto passa por nós é direto para homologação no cliente. No caso desse projeto que já chegou até nós atrasado, de quem foi a culpa? Da análise? dos projetistas? O gerente calculou mal?
Se fosse apenas isso seria "normal", mas no caso desse meu projeto fatores externos fizeram que um projeto relativamente simples com meros 300 pfs (pontos de função) se transformasse em um caos total. Nesse caso, uma série de infelizes coinscidências como troca da nossa equipe de análise, troca da equipe do cliente também e pessoas com pouca experiência fizeram com que esse projeto QUASE não desse certo (Digo quase porque nós conseguimos entregar o projeto antes do prazo acordado com o cliente).
No caso desse projeto, foi apenas isso, uma série de infelizes acontecimentos que fizeram dele um fiasco em termos de planejamento, mas é importante que as empresas entendam que embora isso possa acontecer, não é possível fazer desse tipo de projeto uma realidade. A equipe desse projeto se desgastou demais, a vida pessoal fica comprometida (Minha pequena tadinha, sentindo a minha falta), minha casa parecia um hotel pra mim pois eu ia dormir umas horinhas e voltava para o trabalho além de no dia da entrega eu chegar do trabalho quando meu pai estava saindo para ir para o trabalho dele....
Vou colocar uma enquete aqui pois gostaria de saber outras opiniões....
Abraço pessoal...
Até logo (Espero...)
OBS: Obrigado a Sr Emanuel pelo desconto nas pizzas que agente pedia nos sábados e domingos a noite...
www.bardaue.com.br
Assinar:
Postar comentários (Atom)
2 comentários:
Pois é, Marianno. Quando os professores apertam o prazo de um trabalho, ou até mesmo endurecem em seu escopo, os alunos reclamam sem saber que estão sendo treinados para o pior que está por vir no dia-a-dia do trabalho. E o pior, desperdiçam uma oportunidade de desenvolver um diálogo de negociação que muitas vezes será necessário em um projeto real. Muitos preferem criticar o professor a procurá-lo para um entendimento melhor. Como eu sempre digo, alguns, daqui a alguns anos, estarão passeando na Europa... outros, não terão grana para ir na Barroquinha... Ah, se eles soubessem....
Em uma leitura do Livro Code Complete, o autor fala inicialmente sobre requisitos, arquitetura e etc. mas ele sempre frisa que não adianta ter um equipe de desenvolvedores excelente se quem está na cabeça da equipe, o lider, não souber conduzí-la. Conduzir no mais amplo sentido, não somente a equipe, mas o projeto como um todo. Enfim, digo isso por experiência própria pois estudei quatro anos para me formar, ouvir meus professores dizendo o que era certo e o que era errado, e hoje faço tudo diferente em minha empresa. Quando digo vamos realizar reuniões, brainstorms, levantar requisitos, documentar... e o que ouço?! "Não temos tempo para isso, o cliente quer isso para logo!". E mais uma vez vamos codificar sem se quer saber por onde começar...
Postar um comentário