Engenharia De Software Duração

Estimar tempo em projetos de software é um exercício de honestidade

A maioria das pessoas acha que engenharia de software duração se resume a somar horas de coding e transformar em semanas. Na prática, isso raramente funciona. O problema não é a matemática, é o que fica invisível na planilha. Comecei a perceber isso em 2017, quando assumi um projeto de migração de banco legado para uma fintech. A estimativa inicial do gestor era de oito semanas. Eu disse treze. Eles não gostaram. Fizemos treze. O projeto levou dezesseis semanas porque ninguém havia considerado a documentação que precisava ser reconstruída de forma empírica — cada stored procedure tinha regras de negócio que não estavam escritas em lugar nenhum.

Engenharia de software duração: o que ninguém conta

O método mais honesto que eu uso hoje é o bottom-up com faixas, não valores pontuais. Você quebra o trabalho nos menores componentes possíveis, estima cada um com um intervalo — por exemplo, entre 8 e 16 horas — e depois compila tudo com um multiplicador de contingência. O multiplicador varia conforme a maturidade do time e a novidade da tecnologia. Para times novos trabalhando com stack desconhecida, eu fixo em 1,4. Para times estabelecidos em tecnologia consolidada, 1,2. Sempre. Um detalhe contra-intuitivo: quanto mais específico o escopo, maior a margem de erro relativa. Um módulo bem definido como "implementar login OAuth" pode ter uma estimativa precisa de 24 a 32 horas. Mas se o escopo for vago, tipo "melhorar a segurança da plataforma", a variância explode para algo entre 120 e 400 horas. O problema é que gestores tendem a aceitar o extremo inferior sem questionar, porque soa mais confortável. A técnica que realmente funcionou para mim foi aplicar a regra dos três pontos de vista. Eu peço três pessoas diferentes do time para estimarem o mesmo módulo separadamente, sem conversar entre si. Se as três estimativas caem dentro de uma faixa de 30%, eu confio no resultado. Se afastarem mais do que isso, significa que alguém viu algo que os outros não viram — geralmente uma dependência oculta ou uma restrição técnica não documentada. Nesses casos, eu reviso antes de fechar o número.

Existem frameworks que prometem precisão. Planning poker, t-shirt sizing, estórias com pontos de esforço. Eles funcionam até o momento em que a realidade aparece. O planning poker, por exemplo, sofre de efeito de ancoragem — a primeira pessoa que fala define o teto mental do grupo. Eu já vi um sprint ser fechado em 5 pontos e, na execução, consumir 23. A causa raiz era sempre a mesma: alguém não mencionou uma integração com API de terceiros que tinha limitação de taxa e precisaria de retry logic com backoff exponencial. Isso não aparece em reunião de planejamento se você não fizer a pergunta direta. Outro problema sério que as pessoas ignoram: custo de comunicação cresce de forma não linear com o tamanho da equipe. Adicionar mais duas pessoas em um projeto com seis semanas de prazo não reduz o tempo pela metade. Muitas vezes aumenta. Cada nova pessoa precisa de onboarding técnico, contexto de negócio, acesso a ambientes e revisão de código. Em média, isso consome 40 horas por pessoa nas duas primeiras semanas sem entregar valor direto. Se você tem um prazo apertado e pede mais gente, o projeto pode atrasar mais do que se mantivesse a equipe original. Um workaround prático que desenvolvi foi dividir projetos grandes em fases com entregáveis independentes. A fase um entrega o core funcional em quatro semanas. A fase dois agrega as melhorias em duas semanas. A fase três trata de otimizações e edge cases em mais duas semanas. Cada fase tem sua própria estimativa de engenharia de software duração separada. Isso permite ajustar o escopo realista se a fase anterior estourar, em vez de descobrir no final do projeto que o prazo era impossível.

O que também ajuda muito é manter um histórico de estimativas versus tempo real. Eu registro sempre: estimativa inicial, estimativa revisada, tempo de desenvolvimento puro, tempo de testes, tempo de deploy e tempo de suporte pós-lançamento. Depois de seis meses, você tem dados suficientes para calibrar seu multiplicador de contingência com base em evidências reais, não em achismo. Eu comecei com multiplicador de 1,5 porque eu era pessimista. Hoje estou em 1,25 porque meus dados mostram que meus times são consistentes, mas ainda tenho margem para imprevistos de infraestrutura. Se você quer uma ferramenta concreta para começar, pode usar uma planilha com colunas para: módulo, sub-tarefa, estimativa mínima, estimativa provável, estimativa máxima, responsável, dependências, bloqueadores conhecidos e margem de contingência aplicada. Não precisa ser complexo. O Google Sheets funciona. O importante é preencher com honestidade, não com otimismo. Existem softwares específicos como Monday.com, Jira com plugins de estimation, e ferramentas especializadas como Estimote que oferecem templates prontos. A vantagem deles é a automação de cálculos e histórico organizacional. A desvantagem é que a complexidade da ferramenta pode consumir mais tempo do que uma planilha simples, especialmente para times pequenos. Eu recomendo começar com algo mínimo e só migrar para ferramentas mais robustas quando o volume de projetos justificar.

Há um ponto que poucas pessoas consideram e que eu aprendi na prática: a dur