Usamos cookies para medir audiência e melhorar sua experiência. Você pode aceitar ou recusar a qualquer momento. Veja sobre o iMasters.
Muita gente ainda acha que dá pra prever exatamente quanto tempo uma feature vai levar, mas a realidade mostra que essa previsão é mais uma arte do que uma ciência exata. A dica do artigo do Medium do Dax brinca que a melhor estratégia é multiplicar o tempo estimado por três, somar uma sprint e, claro, mentir um pouco.
Na prática, essa abordagem reflete uma dificuldade grande que a gente tem de fazer previsões confiáveis, especialmente em projetos complexos ou com muitas variáveis. A questão é que essa 'regra' acaba servindo mais pra criar uma margem de segurança do que uma previsão real.
A grande sacada é entender que o ownership do prazo é difícil demais, e que manter a transparência com o time e o cliente é mais importante que uma estimativa exata. O que vocês acham? Como vocês lidam com essa questão no dia a dia? Sem esse critério, a solução pode parecer simples no começo e cara no suporte. O valor aparece melhor quando operação, produto e engenharia olham para o mesmo risco.
Concordo, mano. No backend, a gente tenta sempre separar tarefas menores pra melhorar a precisão, mas no final das contas, a incerteza sempre pesa.
Isso me pega em projetos de frontend, pq a complexidade às vezes explode de uma hora pra outra. Acho que a estratégia de multiplicar por três ajuda a criar uma margem, mas ainda assim, é difícil prever o impacto das mudanças.
A questão é que essa 'regra' não leva em conta riscos ou imprevistos. Na minha visão, uma estimativa mais confiável envolve uma análise de riscos e uma margem de reversibilidade. Não dá pra confiar só na matemática.