Ilustração de hartboy
Definir quanto tempo será necessário para finalizar uma tarefa ou o desenvolvimento de um software não é (ou pelo menos não deveria ser) algo trivial. Estimar prazos faz parte do nosso dia-a-dia como programadores.
O que muita gente não se dá conta é que a precisão com que um programador prevê a entrega de tarefas e projetos é um poderoso indicador do quão bom ele é.
Para informar de forma precisa o tempo necessário para a realização de algo em desenvolvimento de software é necessário que o programador possua uma certa experiência no assunto, tenha um bom domínio do negócio, seja rápido e produtivo.
Embora muitos de nós não apreciem essa difícil tarefa, estimar prazos é parte do nosso trabalho. Fazer isso bem pode ser a diferença entre um programador profissional e um amador.
Em um dia normal, estamos estimando prazos o tempo todo. Ao colocar a comida no micro-ondas você deve informar quantos minutos serão necessários para esquenta-la. Se você tem um horário fixo para acordar, deve analisar quantas horas de sono serão suficientes e então decidir quando deve ir para a cama.
O segredo não está no tempo, mas em quão precisa deve ser a sua estimativa. Se seu chefe pergunta que horas você entregará o relatório amanhã, ele quer ter uma ideia se será antes ou depois do almoço. Se ele lhe pergunta quanto tempo será necessário para resolver um bug critico e colocar o sistema de volta em produção ele precisa de uma precisão maior.
A escala de tempo é muito importante ao se estimar prazos. Por exemplo, você pode dizer “O projeto será entregue em 25 dias” ou pode dizer “O projeto será entregue em cerca de 5 semanas”. Embora ambas as frases indiquem o mesmo tempo, o efeito sob cada uma delas pode ser diferente. Ao dar a primeira resposta, seu cliente provavelmente anotará na agenda dele o dia exato em que você entregará o projeto. Por outro lado, a segunda resposta fará com que ele lhe procure a qualquer momento daqui a 4 ou 6 semanas.
O livro The Pragmatic Programmer dá uma importante dica que nos ajuda a escolher a escala de tempo apropriada ao estimar prazos. Veja a tabela:
1-15 dias -> dias
3-8 semanas -> semanas
8-30 semanas -> meses
30 + semanas -> pense bem antes de dar uma estimativa
Qual a vantagem disso? O fato é que quanto maior o tempo, mais difícil é a previsão, exigindo que você seja cada vez mais impreciso. Por exemplo, se sua estimativa é que serão necessários 125 dias para terminar um trabalho, é muito mais seguro dizer que precisará de “cerca de 6 meses” para finaliza-lo.
Todas as estimativas que fazemos são baseadas em nossas experiências passadas. Mas, o que fazer quando é necessário estimar algo que você nunca fez ou que não conhece? A resposta é simples: “não estime”. É melhor pedir para que alguém que já tenha feito algo semelhante lhe dê uma ideia do tempo necessário.
Além de considerar o grau de precisão, também é importante entender qual é o problema antes de começar a chutar um tempo. Quase sempre nossas estimativas dependem de outros fatores para darem certo: “Supondo que não haja trânsito dá para chegar aí em 20 minutos”.
Se possível é muito útil testar alguns aspectos do projeto antes de dizer quanto tempo será necessário para cumpri-lo. Se o sistema precisa ser carregado dentro do Facebook, seria muito bom poder gastar um tempo criando alguma coisa bem simples para esta plataforma afim de analisar o grau de complexidade, isto sem dúvida aumentará a precisão da estimativa.
É muito importante levar em consideração que a equipe, sua produtividade e o ambiente afetam diretamente sua estimativa.
Analisando todos estes fatores, a conclusão é que há apenas uma única resposta correta a se dar quando lhe é pedido para estimar um prazo: “Me dê algum tempo para pensar”. Você sempre terá resultados melhores se retardar a resposta e pensar um pouco mais.
Parabéns, muito bacana.
Carlos Brando e sua objetividade cortante mais que um bisturi.
Parabéns pelo artigo, sempre muito bom!
Olá Carlos,
Bacana o post… já vi mtos programadores dizem que determinada tarefa pode levar de dois meses a um ano (de pirraça), quando algum gerente insiste em pedir uma data, mesmo que ninguém tenha noção de como fazer algo.
Abraço
O que complica a estimativa, é que vc não consegue dar um tempo a partir do problema puro. É preciso pensar na solução para dar o tempo e pensar na solução em si já leva um tempo.
O complicante final é que vc nem sempre consegue prever todas as consequências da solução e algumas deles afetam fortemente a estimativa.
Wicked Problem na veia :P
Salvo no meu bookmark!
Outro bom texto. Obrigado.
Carlos ótimo artigo!
Minha opinião e muito interessante se ter uma boa documentação dos projetos , pois são elas que permitem estipular prazos reais e seguros, definir prazos somente baseando-se na experiência, no meu caso foi prejudicial em alguns aspectos, o principal deles foi o fato de que eu e meus companheiros acabamos nos esquecendo de detalhes que tivemos dificuldades nos sistemas que já havíamos construído, e isso levava em alguns casos, a repetirmos o mesmo erro, e gastar tempo resolvendo eles, porém uma boa documentação só ajuda se for pouco burocrática.
Ótimo assunto e sua abordagem foi muito interessante. Estimativas de prazos é uma coisa difícil de fazer. O que vocês acham quanto Pontos de Função?
Os maiores complicadores relacionados aos prazos são na minha opinião: o fator imprevisto, que sempre há, e – como o próprio Carlos disse – o não conhecer a solução do problema.
Parabéns Carlos, esse é um assunto que poucos gostamos de dar opinião. E, aproveitando a oportunidade, uma boa prática que aprendi a duras penas é: “Sempre peça a opinião de pelo menos mais um desenvolvedor”.
Técnicas como planning poker (http://www.planningpoker.com/) são muito eficientes para, além de pedir várias opiniões, não influenciar uma estimativa a partir da visão de um desenvolvedor mais sênior ou mais influente.
[]‘s
Achei bem legal o artigo. Se me permite, gostaria de acrescenter algo:
Quando fornecemos estimativas, precisa ficar bem claro pra quem recebe que esse tempo pode falhar caso não corra tudo como o esperado. A alternativa seria colocar uma gordura nesse tempo, o que eu sou totalmente contra. Digo isso pois muitos clientes recebem a estimativa e consideram esta com um prazo, entendendo que é exato. Isso gera muitos problemas. É muito importante esclarecer antes para o cliente a natureza do nosso trabalho (empírico) para evitar dores de cabeça.
[]s
Simplesmente fantástico esse post.
Convivo com estimativas de tempo diariamente (inclusive, fiz isso 2 vezes hoje).
Mesmo possuindo uma certa experiência, ainda sinto algumas dificuldades na hora de estimar um prazo.
Seu post me fez refletir mais a respeito.
Muito obrigado!
Abraços
Excelente post. Parabéns.
Estimativas de prazos é uma coisa difícil de fazer.
Estimativas de prazos é uma coisa difícil de fazer.
Thanks.