Estimativa é uma coisa. Realidade é outra.

Estimativa é uma coisa. Realidade é outra.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!

Estimates and Deadlines

 

Obrigado pela visita, leitores!
Abraço!


 

Compartilhe!
Share on FacebookTweet about this on TwitterShare on LinkedInShare on Google+Pin on PinterestEmail this to someone

4 comentários

  1. Parabéns pelo artigo André,

    Isso é uma realidade muito comum, principalmente em empresas pequenas que não possuem nenhuma cultura de gerenciamento de produtos. Eu tive muitos problemas dessa natureza, já me pediram para estimar um software inteiro na hora. Infelizmente é uma situação muito comum.

    1. Obrigado pelo feedback, Robson!
      Se você já teve problemas com estimativas, então compartilhamos das mesmas experiências, rsrs. Hoje eu prefiro ser mais realista do que otimista!

      Abraço!

  2. Olá, meu noivo,
    Parabéns, mais uma vez!

    Estimar, por si só já é complicado, e se torna mais complexa , ao se falar em “desenvolver uma funcionalidade”.
    Vejo que, ter essa realidade, são comuns em ambientes que estão em processo de amadurecimento cultural, já que o Gestor não pode definir o prazo, toma como “verdade absoluta” o que foi “estimado”, utilizando a velha e conhecida: “pressão”.

    Já participei de times, que realmente tinham a sinergia, conhecimento do produto, as especificações eram bem definidas, enfim, a equipe era madura, com isso, as estimativas eram assertivas.
    Porém, outras equipes, que as reuniões se tornavam chatas, extensas, sem foco.. que os resultados não eram os mais favorecidos.

    Nesse segundo cenário, a reunião de estimativa (Sizing) será mais tempo perdido. Seria muito mais rentável a utilização, por exemplo, da sua sugestão, estimativa por “base histórica”.

    Também concordo com as suas observações, e acrescento: Encarar os erros, como parte de amadurecimento do time.

    Um beijo grande!
    Amo você!

    1. Olá, minha noiva!

      Fico muito feliz por novamente ler um comentário seu no blog! Os seus comentários são mais do que bem-vindos! Obrigado! 🙂
      Você tocou em três assuntos importantes para esse contexto de estimativas: o amadurecimento da equipe, o conhecimento do produto e, talvez o mais relevante, as especificações bem definidas.
      Já perdi a conta das vezes que as minhas estimativas não foram correspondidas em função das falhas na especificação de requisitos, afinal, é com base nessa especificação que as funcionalidades são codificadas. Sempre defendo que o levantamento de requisitos reflete na qualidade do projeto, incluindo os prazos de entrega.

      O amadurecimento da equipe e conhecimento do produto também são essenciais para a apresentação de estimativas assertivas. Além disso, estes itens contribuem para a formação da “base histórica”, mencionada no final do artigo. Embora eu ainda não tenha utilizado essa prática, acredito que é uma boa iniciativa para reduzir a distância entre estimativa e realidade.

      Obrigado por compartilhar o seu ponto de vista profissional.
      Te amo! Grande beijo!

Deixe uma resposta

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

Preencha o campo abaixo * Time limit is exhausted. Please reload CAPTCHA.