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.

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="">