Estimativa de projeto freelance: como calcular horas sem chutar (e por que a sua sempre estoura o dobro)

Você recebe o briefing, lê duas vezes, pensa "isso eu faço em três semanas" e manda o preço. Na sexta semana você ainda está ajustando o fluxo de pagamento, o cliente já perguntou duas vezes "e aí, tá quase?", e a sua hora, que era para ser R$ 120, virou R$ 55. Você entrega bem. O código é limpo, o app funciona. O problema não é técnico. O problema é que a estimativa saiu da cabeça, não de um método, e a conta fecha contra você toda vez.

Vou te falar como funciona do lado de quem orça projeto toda semana: na OCA a gente estima dezenas de escopos por mês, porque os leads chegam pelo Google e pelas IAs em volume maior do que a equipe consegue atender. Erramos muito no começo. Hoje erramos menos, e não é porque ficamos mais rápidos programando. É porque paramos de estimar código e começamos a estimar projeto.

A verdade desconfortável: você estima o caminho feliz

Quando um dev olha uma funcionalidade e diz "isso é um dia", ele está descrevendo o tempo de escrever o código com tudo dando certo. Não conta o tempo de entender a regra de negócio que o cliente explicou pela metade, de descobrir que a API do gateway devolve erro diferente em sandbox, de testar em um Moto G com Android 11 porque é o celular da recepcionista, de responder mensagem no WhatsApp, de fazer deploy e de corrigir o que quebrou no deploy.

Isso tem nome: viés de planejamento. Todo mundo tem, inclusive sênior. A diferença é que quem já se queimou o suficiente para de confiar na intuição e passa a usar um processo que corrige o viés de forma sistemática.

A conta é simples. Se a sua estimativa cobre só o código, e o código é 50% a 60% do trabalho real de um projeto, a sua estimativa vai estourar em quase o dobro. Sempre. Não é azar, é matemática.

O método que a OCA usa para estimar um projeto

Não é ciência de foguete. São quatro passos que a gente segue mesmo quando o escopo parece óbvio, porque os projetos que mais estouraram foram justamente os que pareciam óbvios.

1. Quebre até nenhuma tarefa passar de 8 horas

"Módulo de pagamento: 3 dias" não é estimativa, é palpite com unidade. Quebre até chegar em itens do tipo "tela de checkout com resumo do pedido", "webhook de confirmação do Pix", "tratamento de cartão recusado". Quando uma tarefa passa de 8 horas, é sinal de que você ainda não sabe o que tem dentro dela. E o que você não sabe é exatamente onde o prazo estoura.

Esse passo sozinho já aumenta a estimativa em 20% a 30% na maioria dos projetos, porque na hora de listar você lembra do e-mail de recuperação de senha, da tela de estado vazio, da paginação, do loading. Coisas que "não contam" na cabeça e contam muito no calendário.

2. Some as horas que não são código

Este é o passo que quase ninguém faz. Um projeto tem trabalho que não aparece em nenhum arquivo do repositório, e ele é grande. A referência que a gente usa, em cima do total de horas de código:

• Reuniões, alinhamento e comunicação: 10% a 15%. Call de kickoff, dúvidas por WhatsApp, revisão de tela com o cliente, reporte semanal.
• Testes, QA e correção do que você mesmo achou: 15% a 20%. Testar em dispositivo real, corrigir o bug que só aparece com dado de verdade.
• Deploy, configuração e lojas: 5% a 10%. Ambiente, variáveis, certificado, conta de desenvolvedor, rejeição da Apple.
• Documentação e handoff: cerca de 5%. README decente, entrega de acessos, walkthrough gravado.

Somado, dá entre 35% e 45% em cima do código. Se você nunca cobrou isso, você vem pagando do próprio bolso em todo projeto.

3. Aplique buffer por tipo de tarefa, não um número mágico no final

Colocar "20% de gordura" no total é melhor que nada, mas trata um CRUD e uma integração com gateway como se tivessem o mesmo risco. Não têm. A gente separa em três faixas:

• Coisa que você já fez cinco vezes (auth, CRUD, tela de lista): +15%.
• Coisa que você já fez, mas depende de alguém de fora (gateway de pagamento, push, API de terceiro, login social): +50%. Integração é onde documentação mente e sandbox se comporta diferente de produção.
• Coisa que você nunca fez (aquela lib de mapa offline, o SDK de biometria): +100%. Se você nunca fez, você não sabe estimar, e o buffer é o preço da honestidade.

4. Entregue faixa, nunca número único

Estimativa é probabilidade, não promessa. A gente sempre apresenta uma faixa, tipo "entre 220 e 260 horas", e explica o que empurra para cima: mudança de escopo, atraso do cliente na entrega de conteúdo, acesso a sistemas que ainda não existem. O cliente sério entende. O cliente que exige número exato antes de definir o escopo é o mesmo que vai reclamar quando o exato não bater.

Exemplo real: app de agendamento com pagamento

Cenário que chega toda semana nos leads da OCA: clínica quer um app para paciente agendar consulta, pagar por Pix ou cartão e receber lembrete. Precisa de um painel web simples para a recepção. Um dev de intuição olha isso e responde "uns 130 horas, R$ 15 mil". Veja a conta pelo método:

Faixa apresentada: 220 a 260 horas. A R$ 120 a hora, o projeto sai entre R$ 26 mil e R$ 31 mil. A intuição dizia R$ 15 mil. A diferença não é margem gorda, é o trabalho real que ia acontecer de qualquer jeito. A única pergunta é quem paga por ele: o cliente, no orçamento, ou você, nas madrugadas.

Isso não é teoria, é literalmente como a OCA aprendeu a orçar. O checkout do Revo, que hoje converte a 90% com mais de 40 mil usuários, foi a integração de pagamento que mais estourou estimativa na nossa história. Foi ali que o buffer de 50% para integração deixou de ser sugestão e virou regra.

Horas não são dias: a segunda conta que estoura o prazo

Você fechou 240 horas e prometeu seis semanas, porque 240 dividido por 40 dá 6. Só que você não tem 40 horas de código por semana. Tem suporte do projeto anterior, tem call com cliente novo, tem contabilidade, tem dia que rende metade. Um freelancer sozinho, sendo honesto, produz entre 20 e 28 horas de código por semana em um único projeto. As mesmas 240 horas viram 9 a 12 semanas de calendário.

Estimar horas certo e prometer prazo errado dá o mesmo resultado: cliente cobrando, você acuado. A gente sempre converte com uma capacidade realista e diz ao cliente o que precisa dele para o prazo se manter, como conteúdo, acessos e aprovação de tela em até dois dias úteis.

As armadilhas que fazem a estimativa estourar

• Estimar em cima de briefing de duas linhas. "Um app tipo o do meu dentista" não é escopo. Se você precifica sem uma call de levantamento e uma lista do que entra, você está apostando, não estimando.
• Estimar integração pelo tempo da documentação. A doc diz que são três chamadas. A prática tem webhook duplicado, timeout, ambiente de homologação fora do ar na semana da entrega. Dobre.
• Esquecer o "igual ao". Quando o cliente diz "igual ao iFood", ele está vendo o resultado de cem devs por cinco anos. Traduza para funcionalidades concretas antes de colocar número.
• Dar desconto sem cortar escopo. O cliente pede 20% a menos. Você aceita e mantém tudo. Agora as mesmas 240 horas valem menos e você começou o projeto já ressentido. Desconto sério vem com corte de funcionalidade, nunca sozinho.
• Não escrever o que não está incluso. Sem a lista de exclusões, tudo que o cliente imaginou vira "mas isso era óbvio". Painel de relatórios, multi-idioma, modo offline: se não estimou, escreva que não entra.

O que uma boa estimativa entrega além do preço

A estimativa bem feita vira a espinha do contrato e da proposta. Dela saem os marcos de entrega e pagamento, a lista de premissas ("cliente entrega logo e textos até o kickoff"), a lista de exclusões e a base para cobrar mudança de escopo. Quando o cliente pede "só mais uma telinha" na semana quatro, você não discute: abre a planilha, mostra onde ela entra, quantas horas custa e como afeta o prazo. Deixa de ser conversa de opinião e vira conversa de número.

Como isso funciona quando o projeto vem repassado

Na OCA, a quantidade de leads que chega pelo Google e pelas IAs passou do que a equipe consegue entregar. Por isso a gente repassa projetos escopados para uma rede de devs parceiros. E estimativa é a primeira coisa que a gente olha em quem entra na rede.

O que o parceiro recebe: projeto que já passou por call de levantamento, escopo cercado e faixa de horas definida pelo método acima. O cliente já foi qualificado e já sabe o que está comprando. O que a OCA espera de volta: uma estimativa própria que bata com a nossa dentro de uma margem razoável, e principalmente alguém que sinaliza na semana dois quando a integração está indo para o dobro, não na semana oito. Quem estima bem raramente furou prazo com a gente. Quem estima na intuição, mesmo sendo bom de código, é quem mais gerou conversa difícil com cliente.

Se você já entrega bem, o seu problema não é técnico, é distribuição. E a distribuição só funciona se a estimativa do outro lado for confiável, porque projeto repassado com prazo estourado queima a OCA, o parceiro e o cliente ao mesmo tempo.

Próximo passo

Se você entrega com consistência, sabe estimar com método e quer receber projetos que já chegam com escopo cercado, chama a gente:

Entre para a rede de parceiros da OCA

E independentemente disso, uma tarefa para esta semana: pegue o último projeto que estourou, refaça a estimativa com os quatro passos (quebra em tarefas de até 8 horas, horas não-código, buffer por tipo, faixa) e compare com o que você cobrou. A diferença entre os dois números é o quanto você pagou para aprender isso. No próximo projeto, esse valor vai para a proposta, não para a sua madrugada.