Durante a minha jornada como desenvolvedor de software, sempre fui assombrado por um conceito que, idealmente, deveria me ajudar: as estimativas.
A razão desse temor origina-se de vários fatores, desde a inconsistência no gerenciamento de projetos até as dificuldades emergentes de um código de difícil manutenção. Diante disso, faço o meu apelo: não confunda estimativa com realidade.
Imagem via Shutterstock
Como já sabemos, em reuniões de planejamento, os gestores geralmente solicitam estimativas para as funcionalidades que serão desenvolvidas no próximo ciclo. Nesse momento, é comum ouvir a pergunta:
“Quanto tempo você acha que vai levar para desenvolver essa user story?”
Pois bem, com base na experiência que temos com o projeto, nos ricos identificados e na complexidade da user story, fazemos um cálculo aproximado de quanto tempo levaremos para desenvolvê-la. Opa, um adendo: observe que destaquei a palavra “aproximado”, visto que é o que consta no significado de “estimativa” no dicionário:
s.f. Cálculo de valor aproximado; avaliação aproximada que se realiza sobre alguma coisa […]
Porém, é difícil (ou impossível) prever o futuro. Impedimentos e contratempos naturalmente podem ocorrer. Suponha que um desenvolvedor apresentou uma estimativa de 2 semanas para codificar uma funcionalidade, mas, durante esse tempo, teve de corrigir um erro impeditivo, ausentar-se por 1 dia devido a problemas de saúde e passar meio período auxiliando um colega em uma codificação. Todos estes eventos “furam” a estimativa. Mas isso é o de menos.
O grande problema surge quando as estimativas são tomadas como prazos reais, ou seja, para alguns gestores, uma estimativa é sinônimo de data de entrega. Isso não deve acontecer!
Por consequência, quando surge um atraso na codificação, eles aparecem, do nada, exigindo uma justificativa:
“Você não afirmou que terminaria essa codificação essa semana?”
Ninguém afirmou nada. Houve uma estimativa, e não uma afirmação. Por que o verbo “achar”, usado lá no planejamento, foi substituído pelo verbo “afirmar” ao cobrar o prazo? Além disso, pode não ser perceptível, mas a frase acima costuma elevar curiosamente o nosso nível de stress. 
Como analogia, imagine que o piloto de um avião comunica que o tempo estimado de chegada ao destino é de 45 minutos. Se o avião chegar em 50 minutos, devido a condições climáticas, os passageiros vão sair questionando o piloto sobre os 5 minutos de atraso? Claro que não! O tempo foi estimado. É completamente diferente do que afirmar: “Passageiros, chegaremos exatamente em 45 minutos em 12 segundos, independente do que acontecer!”. Não é isso que nós, desenvolvedores, fazemos.
Sinceramente, na minha opinião, estimativas apenas utilizadas para cobrança são improdutivas e ilusórias, além de causar discórdia na equipe. Se estimativas nunca forem entendidas como estimativas, no sentido da palavra, nunca serão úteis.
Uma alternativa muito válida é utilizar uma base histórica para definir prazos. Por exemplo, considere que a funcionalidade X de um projeto web demorou 32 horas para ser implementada. No próximo ciclo, a funcionalidade Y será bem semelhante, mas exige a codificação de uma página adicional. Poderíamos, então, estimar um tempo aproximado de 32 horas + 10%, concorda?
E se houverem impedimentos, impactando na estimativa?
Sem problemas. Ajuste o prazo e recursos conforme necessário (negociação com o cliente, trade-offs de user stories, redução de escopo ou alocação de outros desenvolvedores), mas com uma condição: quando o ciclo for encerrado, utilize ferramentas para rastrear os motivos do impedimento. Uma dica importante é a prática do item investigativo!
Para encerrar, deixo aqui as minhas observações para cada profissional:
- Gestor: associe a diferença entre estimativa e realidade, bem como compreenda que impedimentos e imprevistos são naturais. Aproxime-se dos desenvolvedores e acompanhe o projeto em um ritmo saudável para ambos os lados. Evite o comportamento de aparecer na equipe somente no dia definido na estimativa e cobrar os desenvolvedores de cada entrega.
- Desenvolvedor: seja comunicativo e reporte os impedimentos encontrados, principalmente na reunião diária. Quando notar que a estimativa não será correspondida, levante a “bandeira vermelha” e notifique os stakeholders da situação. Dessa forma, será possível antecipar ações para não prejudicar o projeto.
Ah, e para mostrar que eu não sou o único a implicar com isso, veja que o tema até já virou piada, haha!
Obrigado pela visita, leitores!
Abraço!
Publicado originalmente em Blog André Celestino
O post Estimativa é uma coisa. Realidade é outra! apareceu primeiro em Profissionais TI.