O gerente de desenvolvimento da sua empresa o chama para uma reunião e o questiona sobre uma nova implantação que deve ser feita no sistema. Por cima, ele diz a você qual a necessidade do cliente e o questiona: “Em quanto tempo você coloca isso em produção?”
Reticente, pois o gerente não foi capaz de definir claramente o escopo do projeto, você hesita em dar uma estimativa de prazo, mas ao ser pressionado você acaba pedindo 30 horas baseado na sua experiência em projetos similares.
Como resposta o gerente diz que acredita muito no seu potencial e por isso estipula um prazo desafiador de 8 horas para a implantação. Como subordinado você aceita o prazo e para mostrar competência e corresponder às expectativas do seu gerente você pula o planejamento e a documentação indo direto para a alteração necessária nos códigos do sistema.
Você acaba entregando o projeto em 20 horas e o seu gerente ainda ironiza dizendo que você estava valorizando ao prever 30 horas para o projeto.
A situação acima, apesar de fictícia, lembra um pouco o dia-a-dia de trabalho de alguns departamentos de TI.
Em geral, quando um projeto desses consegue ser entregue dentro do prazo estipulado pelo gerente (nas condições acima), ou o escopo não foi claramente entendido pelo líder da equipe e portanto o resultado do trabalho não atenderá às necessidades do cliente ou então houve um assassinato da qualidade, o que implica em falta de documentação e excesso de códigos complexos para realizar tarefas simples, o que vai em curto prazo gerar um excessivo número de “bugs” e em longo prazo impactará em uma dificuldade em dar manutenção gerando maiores custos e degradando a performance da aplicação até que um dia a empresa percebe que está na hora de reescrever a aplicação a partir do zero (isso quando não resolvem instalar uma solução de terceiros e acabam com a área de desenvolvimento interna que passa a ser vista como um custo e não como um investimento).
Uma abordagem para o caso acima seria dizer a seu gerente que pela experiência que você possui a implantação levará de 22 a 52 horas, mas que para dar uma estimativa mais correta você precisa primeiro conhecer claramente o escopo das mudanças necessárias e verificar a disponibilidade de recursos para executá-las.
Durante o seu planejamento procure envolver a equipe de desenvolvimento. Sua equipe é quem fará de fato a implementação e portanto deve ser ouvida, até mesmo para levantar questões como a falta de conhecimento para utilizar determinada tecnologia, o que acarretará em um gasto maior de tempo para concluir uma tarefa aparentemente simples.
Não deixe de documentar todas as atividades que você achar necessário fazer para concluir o projeto, não esquecendo de planejar tempo para a elaboração de documentação funcional, técnica, desenvolvimento e testes.
Para este trabalho, não é necessário utilizar ferramentas sofisticadas de gestão de projetos como o MS Project. Esta tarefa pode ser facilmente realizada com uma planilha convencional e será até mesmo mais fácil para quem não está habituado com o MS Project.
Após detalhar as atividades, envolva os seus desenvolvedores e peça que eles respondam as seguintes questões para cada atividade que você escreveu em sua planilha:
- a) Qual o prazo para concluir essa atividade?
- b) Digamos que tudo ocorra bem, e nenhum contratempo aconteça. Neste cenário, qual o tempo mínimo para concluir a atividade?
- c) E se tudo der errado? Qual será o tempo máximo para concluir a atividade?
Estudos comprovam que na maioria das vezes a estimativa da pergunta “a” será o tempo real, mas que desvios podem acontecer e para isso existe um cálculo matemático simples para prever com maior exatidão o prazo da atividade levando em consideração esta variação (das perguntas b e c).
Para isso, antes de colocar a estimativa de prazo na sua planilha, multiplique a resposta da pergunta “a” por 4, some com os tempos das perguntas “b” e “c” e então divida o resultado da soma por 6. É simples, veja o exemplo abaixo:
Estimativa: 10 horas
Se tudo der certo: 8 horas
Se tudo der errado: 15 horas
( 10 * 4 + 8 + 15 ) / 6 = ( 40 + 8 + 15 ) / 6 = ( 63 ) / 6 = 10,5 horas
Ainda que meia hora isolada não represente uma grande alteração, em um projeto de longa de duração, meia hora em cada atividade pode representar dias de trabalho.
Após estimar o prazo para todas as atividades, avalie os riscos envolvidos (como falta de conhecimento da equipe, possibilidade de perder funcionários chave, parada de servidor não programada, etc) e tente quantificar o quanto de tempo cada risco pode custar ao projeto.
Por exemplo, você sabe que o servidor de banco de dados de desenvolvimento costuma ficar parado pelo menos um dia por mês devido a falhas na restauração do backup de produção, então contabilize (para uma atividade estimada de 1 semana) 2 horas como tempo extra para este risco (como calcular? em um mês = 8 horas parado, então em 1 semana, 8h (parada mensal)/4(semanas) = 2 horas por semana).
Ao final, some as estimativas de tempo e adicione separadamente as estimativas de tempo para os riscos que você detectou.
Para apresentar a estimativa ao seu gerente, leve com você esta planilha que criou e entregue ao seu gerente uma cópia, incluindo a listagem das atividades, o tempo estimado para cada atividade (se possível, inclua também o nome do funcionário que deverá executar a atividade).
Ao final, após a soma total de tempo estimado, inclua a relação de riscos e o tempo extra correspondente, que poderá ser utilizado para compensar os riscos listados.
Veja aqui um modelo preenchido de planilha.
Com base em todo este material que você coletou e elaborou, você terá bastante argumento para convencer seu gerente a respeito da estimativa de prazo que você passou, evitando ter de sacrificar a documentação do sistema e o processo de planejamento, elementos essenciais quando se pensa em alta performance, reutilização de códigos, documentação de sistemas, etc.
Ah, e não ache que passar estimativas de prazo altas e entregar em tempo excessivamente melhor vai fazer com que seu gerente acredite que você seja um bom líder. Ao contrário, se isto ocorrer com freqüência vão pensar que você é um péssimo líder pois não sabe estimar com precisão o tempo necessário para concluir suas atividades e aí cada vez mais a história hipotética do começo desse artigo vai acontecer no seu dia-a-dia. [Webinsider]
.
Renato Ucha
Renato Ucha é formado em administração de empresas, especializado em gestão de projetos. Possui vasta experiência na área, além de dar palestras e escrever sobre o assunto.
12 respostas
Renato,
Muito bom o artigo, texto muito bem colocado, pois, a situação citada é exatamente como ocorre no nosso cotidiano infelizmente.
Está de parabéns, creio que a sugestão de acrescentar o desvio padrão seja uma ótima sugestão para trazer o exemplo ainda mais próximo para a realidade.
Um abraço.
Olá Renato Ucha.
Vale lembrar que os calculos são probabilisticos.
Como sugestão, voce poderia agregar ao calculo o calculo de Desvio Padrão e de Variancia, dando um resultado próximo a realidade.
Entretanto, parabéns pela materia.
Sds, Pedro Paulo.
O conceito apresentado acima é nada mais, nada menos que uma simples aplicação da fórmula:
PERT = (O + P + 4 x MP)/6 ,
onde
O = previsão otimista,
P= previsão pessimista e
MP= previsão mais provável
Excelente texto!
Só não concordo com:
A situação acima, apesar de fictícia, lembra um pouco o dia-a-dia de trabalho de alguns departamentos de TI.
Deveria ser:
A situação acima, mais que presente em nosso cotidiano, retrata bem o dia-a-dia de trabalho de alguns departamentos de TI.
🙂
Abraços,
Leonardo.
E viva o Scrum/XP 😉
Muito interessante o seu artigo, realmente é um problema definir e justificar prazos quando, para quase todos, a funcionalidade solicitada é sempre urgente, emergencial, prioridade 0 ou similares. Fiz um post no meu blog sobre o tema focando a justificativa de prazos e preços para o cliente final.
Ucha, muitas vezes a falha nos prazos para os projetos estão mesmo em não comprovar que o prazo que estamos pedindo faz sentido. Excelente artigo. Parabéns! keep going that way!
Olá Renato Ucha,
Muito interessante seu artigo.
Mas gostaria de saber de onde sairam os números para que se faça esse calculo. Foi baseado em algum estudo?
At,
Excelente artigo, pontos muito interessantes que infelizmente em muitos dos ambientes de projeto não são considerados. Apenas um comentário, 30 horas de desenvolvimento para 8 horas, acho que foi um pouco exagerado, mas passa a realidade dos ambientes de maneira muito cômica, para não dizer trágica. Realmente o que já experimentei em ambientes corporativos foi similar, de acabar por deixar de documentar material que poderia/deveria ser reutilizado, de fazer implementações sem os devidos testes para alcançar um DeadLine que foi estipulado com pouca(ou muitas vezes sem nenhuma) análise. Acho muito louvável mostrar essa realidade e dar um primeiro passo para a mudança da mente dos muitos gerentes que ainda não valorizam as opiniões de seus subalternos.
Renato,
Ótimo artigo para ajudar a todos da área de TI a utilizarem mais um método de persuasão no momento de definição dos prazos para se entregar um projeto de sistema.
Também teve uma ótima definição do resultado deste projetos a curto, médio e longa prazo, e que não podemos culpar somente os gerentes quando um analista líder acha que consegue definir tudo sozinho sem consultar opiniões de sua equipe pode estar indo em direção ao fracasso.
Parabéns e continue nesta linha de raciocínio.
Renato,
Atualmente curso MBA em Gestão de Projetos – PMI na Fiap e estou de pleno acordo em que o escopo é base fundamental para o sucesso de qualquer projeto. Sem um escopo bem definido, fica impossível concluir um projeto dentro do prazo e custo estimado.
Parabens pelo artigo!
Muito bem elaborado esse material.
Renato Ucha, parabéns!!!!