Estimativas de prazo em desenvolvimento de software: mito ou realidade?

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.