Estimativa é uma coisa. Realidade é outra!

AGRADEÇA AO AUTOR COMPARTILHE!

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

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!

ask-for-estimates-treat-as-deadlines

Obrigado pela visita, leitores!

Abraço!

Publicado originalmente em Blog André Celestino

AGRADEÇA AO AUTOR COMPARTILHE!

André Luis Celestino

Mais artigos deste autor »

Desenvolvedor de software há 7 anos e autor do blog AndreCelestino.com. Graduado em Sistemas de Informação e pós-graduado em Engenharia e Arquitetura de Software com ênfase em Desenvolvimento Ágil. Atualmente trabalha como Analista Implementador Delphi em Florianópolis.


2 Comentários

Rodrigo
1

Bacana o artigo!
Realmente é um assunto bem complexo, ainda mais quando há pessoas que tentam conseguir prazos no grito.

Como desenvolvedor procuro sempre deixar claro que se tratam de previsões e não realidades. Uma coisa que tem dado certo é passar um range, como de 5 a 7 dias.

Sendo a entrega dentro do range ou “gordurinha” prevista, não há motivo de explicações. Agora, quando uma estimativa é de 3 meses, mas você leva 1 ano, ai é outra coisa.

Um desafio seria discutir sobre as “estimativas” dos projetos do governo… deixa pra lá!

André Luis Celestino Autor do Post
2

Ótimo comentário, Rodrigo!

O seu comportamento, de sempre deixar claro o status e previsões de suas atividades, indica que você é um desenvolvedor profissional. :)
A prática do “Range” é uma ótima opção para evitar conflitos com prazos de entrega, porém, alguns gestores não concordam. Claro, quanto mais assertiva uma estimativa, melhor, mas sempre cabe o bom senso de não considerá-la como um deadline.
Acho que tanto o desenvolvedor quanto o gestor precisam trabalhar neste bom senso.

Abraço!

Deixe seu comentário

Seu endereço de e-mail não será publicado. Campos com * são obrigatórios!

Você pode usar estas tags e atributos de HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">