Como estimar quanto tempo leva desenvolver uma funcionalidade?

Quebre a funcionalidade em tarefas de no máximo três dias cada e estime cada tarefa em três cenários: otimista, mais provável e pessimista. A estimativa ponderada usa a fórmula (otimista + 4 × provável + pessimista) dividido por 6. Itens que não cabem em três dias precisam ser quebrados antes, porque estimativa de item grande erra por fator, não por percentual.

Quanto adicionar de margem em uma estimativa de software?

Depende da incerteza, não de um número fixo. Escopo bem definido em tecnologia conhecida aceita margem de 15% a 25%; escopo parcialmente definido pede 30% a 50%; e ideia ainda vaga não deveria receber preço fechado, e sim uma fase de descoberta paga. Margem uniforme aplicada a tudo esconde onde o risco realmente está.

Quanto do orçamento vai para atividades que não são programação?

Tipicamente entre 40% e 60%. Levantamento, testes, correção de defeito, revisão de código, implantação, reuniões, documentação e treinamento consomem quase tanto quanto o desenvolvimento em si. Orçamentos que contam apenas as horas de codificação erram de forma sistemática e previsível.

Como orçar um projeto de software sem chutar

Orçar software sem chutar tem um método: decompor o escopo até itens de no máximo três dias, estimar cada item em três cenários, somar com peso e aplicar fatores explícitos para tudo que não é código. Estimativa única sobre um item grande, "o módulo financeiro leva um mês", não é estimativa; é um chute com aparência de número.

Passo 1: decompor até três dias

A regra existe por um motivo estatístico. Estimativas de itens pequenos erram para mais e para menos, e os erros tendem a se compensar na soma. Estimativas de itens grandes erram sistematicamente para menos, porque o cérebro simula o caminho feliz e não enxerga o que ainda não foi decomposto.

Se um item não cabe em três dias, ele ainda não foi entendido. Quebre assim:

Módulo → funcionalidades → tarefas.

Exemplo, para "cadastro de clientes":

Modelagem da tabela e migração inicial
API de criação e atualização, com validações
Validação de CNPJ e consulta de endereço por CEP
Listagem com busca, filtro e paginação
Tela de formulário com tratamento de erro
Regras de permissão por perfil
Importação da base atual em planilha
Testes automatizados dos casos principais

Oito itens onde antes havia um. E note que quatro deles não apareceriam num orçamento feito por tela.

Passo 2: estimar em três pontos

Para cada tarefa, três números:

O = otimista: tudo funciona de primeira
P = provável: o cenário realista
Z = pessimista: aparece um problema previsível

A estimativa ponderada é (O + 4P + Z) / 6.

O valor do método não está na fórmula, e sim no que ela obriga. Ao pensar no cenário pessimista, você é forçado a nomear o que pode dar errado, e essa lista vira a seção de riscos da proposta.

Exemplo para "importação da base atual":

Cenário	Horas	Premissa
Otimista	6	planilha limpa, colunas padronizadas
Provável	16	inconsistências normais de dados reais
Pessimista	40	duplicatas, formatos misturados, decisões pendentes do cliente

Estimativa ponderada: (6 + 64 + 40) / 6 ≈ 18 horas.

A distância entre 6 e 40 é a informação mais útil da tabela. Ela diz que este item é arriscado e que vale reduzir a incerteza antes de fechar preço, pedindo uma amostra real dos dados, por exemplo.

Passo 3: aplicar os fatores do que não é código

Somar as horas de desenvolvimento e chamar de estimativa é o erro mais frequente. Aplique multiplicadores explícitos sobre a soma:

Fator	Acréscimo típico	O que cobre
Testes e correção	+25% a 40%	escrever testes, encontrar e corrigir defeitos
Levantamento e revisão	+10% a 15%	reuniões, esclarecimentos, revisão de código
Implantação e ambiente	+5% a 10%	publicação, configuração, monitoramento
Gestão e comunicação	+10% a 15%	acompanhamento, relatórios, alinhamento
Documentação e treinamento	+5% a 10%	manual, repasse, apoio no início do uso

Somados, esses fatores costumam representar de 55% a 90% sobre as horas de desenvolvimento puro. Não é gordura: é trabalho que acontece em todo projeto e que, quando não é orçado, é feito de qualquer forma, às custas da margem ou da qualidade.

Passo 4: calibrar a margem pela incerteza

A margem de risco não deve ser um percentual uniforme. Ela depende de quanto se sabe:

Situação	Margem sugerida	Recomendação
Escopo detalhado, tecnologia conhecida, dados vistos	15% a 25%	preço fechado é seguro
Escopo definido, alguma integração desconhecida	25% a 40%	preço fechado com premissas explícitas
Escopo parcial, sistemas de terceiros não avaliados	40% a 60%	fase de descoberta antes do fechado
Ideia sem escopo	não estime	descoberta paga, sempre

A última linha é a mais importante e a mais ignorada. Dar preço fechado sobre uma ideia vaga produz, invariavelmente, um dos dois resultados: prejuízo para quem executa ou aditivo para quem contrata. Nenhum dos dois é bom para a relação.

Um exemplo numérico completo

Sistema interno de gestão de contratos, com quatro módulos.

Soma das tarefas decompostas e ponderadas: 320 horas de desenvolvimento.

Aplicando os fatores:

Testes e correção (+30%): 96 h
Levantamento e revisão (+12%): 38 h
Implantação (+8%): 26 h
Gestão (+12%): 38 h
Documentação e treinamento (+7%): 22 h

Subtotal: 540 horas.

Escopo bem definido, mas com uma integração cujo acesso ainda não foi validado. Margem de 30%: 702 horas.

A R$ 130 por hora, o orçamento fica em torno de R$ 91 mil, com prazo de aproximadamente 4 meses e meio para duas pessoas em dedicação parcial.

Repare que o número de partida, 320 horas, corresponde a menos da metade do total. Quem orça só o desenvolvimento chega a R$ 42 mil pelo mesmo escopo e descobre o resto no meio do caminho.

Como registrar a estimativa na proposta

Três seções fazem uma proposta ser comparável e defensável:

Entregáveis nominais. Lista de módulos e tarefas, com as horas estimadas por bloco. Permite discutir corte de escopo de forma objetiva em vez de negociar desconto.

Premissas declaradas. "Assumimos até três perfis de acesso", "assumimos que a API do ERP possui documentação e ambiente de testes", "assumimos migração de até 50 mil registros". Cada premissa é uma fronteira. Se ela cair, o orçamento muda, e isso fica claro para todos antes de começar.

Riscos com plano. Os itens cuja distância entre otimista e pessimista foi grande, com o que será feito para reduzir a incerteza. Um fornecedor que expõe risco é mais confiável que um que aparenta certeza absoluta.

Feche o ciclo: compare estimado e realizado

O que separa quem estima bem de quem chuta bem não é o método, é a calibração. Registre, ao final de cada projeto, as horas estimadas e as realizadas por bloco. Depois de cinco ou seis projetos, seus fatores deixam de ser regra de mercado e passam a ser dados da sua operação.

É esse histórico, e não a experiência genérica, que faz uma estimativa parar de ser chute.