Profissionais TI - Pra quem respira informação

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!

Obrigado pela visita, leitores!

Publicado originalmente em Blog André Celestino