Estimativa de prazo no freelance dev: por que você erra por 2x e como estimar projeto sem trabalhar de graça (o método de 5 passos da OCA)

Você lê o escopo, pensa “isso dá umas três semanas”, manda a proposta com esse prazo e calcula o preço em cima dele. Seis semanas depois o projeto ainda não foi entregue, o cliente manda áudio todo dia e você está trabalhando de graça desde a quarta semana. Não foi preguiça. O código ficou bom. O que falhou foi a estimativa.

Se isso já aconteceu com você, saiba que esse é o erro mais comum do freelance dev, e também o mais caro. No projeto fechado por escopo, cada semana de atraso sai direto da sua hora efetiva. Um projeto de R$ 18 mil pensado para 120 horas paga R$ 150 por hora. Se ele consome 240 horas, você recebeu R$ 75 por hora. A entrega é a mesma e você recebe metade. E ninguém te avisa disso no fechamento, porque o prejuízo só aparece quando já é tarde para renegociar.

Por que dev erra a estimativa de prazo quase sempre para menos

Raramente alguém estima o dobro do necessário. O erro vai quase sempre na mesma direção, e as causas são bem previsíveis:

• Você estima o caminho feliz. Na cabeça, “tela de cadastro” é o formulário funcionando. Na prática, a tela inclui validação, mensagens de erro, estado de carregamento, layout no celular, e-mail de confirmação e o caso do usuário que fecha o app no meio do processo.
• Você estima o que conhece e chuta o resto. Você sabe quanto tempo leva um CRUD. Não sabe quanto leva a integração com o ERP do cliente, a API de terceiro com documentação de 2019 ou a publicação na App Store, mas coloca um número redondo mesmo assim.
• Você esquece o trabalho que não é código. Call de alinhamento, resposta no WhatsApp, configuração de ambiente, homologação, ajuste de texto. No freelance, isso consome de 20% a 35% do tempo do projeto.
• Você estima com medo de perder o cliente. Prazo curto parece competitivo. Só que o cliente não compra o prazo da proposta. Ele compra o prazo que você cumpre.

A verdade desconfortável é esta: estimativa não é previsão técnica, é compromisso comercial. Quando você chuta baixo para fechar, não fica mais competitivo. Só transfere todo o risco do projeto para o seu bolso.

Como estimar projeto de software em 5 passos (o método que a OCA usa)

Isso não é teoria, é literalmente como a OCA estima hoje, depois de errar bastante nos primeiros projetos e no próprio Revo. O método cabe numa planilha e leva de duas a quatro horas para um projeto médio. Esse tempo se paga no primeiro projeto que não estoura.

1. Quebre o escopo até nenhum item passar de 2 dias

“Painel administrativo” não é um item, é um projeto. Quebre em listagem com filtro, edição, permissões e exportação. Se um item ainda parece maior que dois dias de trabalho, é sinal de que você ainda não entendeu bem o que ele exige, e é aí que mora o atraso. Itens pequenos são mais fáceis de estimar e mais fáceis de defender quando o cliente pergunta por que custa tanto.

2. Estime cada item em três pontos

Para cada item, escreva três números: otimista (tudo dá certo), provável (o normal) e pessimista (a API não ajuda, o requisito muda). Depois aplique a média ponderada clássica: (otimista + 4 × provável + pessimista) ÷ 6. Ela puxa a estimativa para o realista sem ignorar o risco.

Exemplo de um sistema web de agendamento com pagamento, em dias de trabalho focado:

Repare que a soma otimista dá 15 dias, ou três semanas. É exatamente o número que a maioria dos devs mandaria na proposta. A soma ponderada já dá quase 27 dias, e ainda falta o passo seguinte.

3. Some o trabalho invisível

Em cima da soma ponderada, a OCA acrescenta percentuais fixos:

• Setup, infraestrutura e deploy: 5% a 10%
• Testes e correção de bugs: 15% a 20%
• Comunicação, reuniões e homologação com o cliente: 15% a 20%

No exemplo, com 40% de acréscimo, os 26,8 dias viram cerca de 38 dias de trabalho, algo entre 7 e 8 semanas. São duas vezes e meia as três semanas do chute inicial. Se você trabalha 6 horas produtivas por dia e sua hora vale R$ 150, a diferença entre 15 e 38 dias passa de R$ 20 mil. Esse é o tamanho do buraco que a estimativa otimista abre.

4. Trate o desconhecido como risco, não como número

Se você nunca fez aquela integração, não estime como se já tivesse feito. Há duas saídas honestas: multiplicar o item por 1,5 a 2 ou cobrar à parte uma investigação técnica de 2 a 4 dias antes de fechar o prazo daquele item. No Revo, a integração de pagamento foi o item que mais fugiu do planejado. No papel, a tarefa era “integrar o gateway”. Na prática, apareceram split de recebíveis, estorno, webhook chegando fora de ordem e Pix expirando no meio do checkout. Desde então, qualquer pagamento entra na estimativa da OCA com o cenário pessimista como base.

5. Entregue uma faixa com premissas, não um número

Na proposta, escreva “7 a 9 semanas” e liste do que o prazo depende: layouts aprovados até a semana 2, acesso à API do ERP na primeira semana e até dois dias úteis para o cliente responder cada homologação. Se uma premissa não for cumprida, o prazo muda, e isso já está combinado por escrito. A faixa não é sinal de insegurança. É informação que o cliente usa para planejar o lado dele.

Os erros de estimativa que mais queimam freelancer

Vou te falar como funciona do lado de quem recebe os leads: boa parte dos clientes chega à OCA com um prazo na cabeça que não tem relação nenhuma com o escopo. “Um app tipo marketplace em 30 dias” é um pedido comum. Os erros abaixo são os que transformam essa expectativa em prejuízo para o dev.

Estimar ao vivo, na call

O cliente pergunta “mais ou menos quanto tempo?” e você responde “uns dois meses”. Pronto, isso virou contrato na cabeça dele. A resposta segura é: “consigo te passar uma faixa até sexta, depois de quebrar o escopo”. Nenhum cliente sério desiste de um projeto porque precisou esperar dois dias.

Dar desconto no prazo

Muito dev já aprendeu a não baixar o preço sem cortar escopo. Mas aceita o “dá para fazer em quatro semanas em vez de seis?” sem cortar nada. Prazo menor com o mesmo escopo também é desconto, só que você paga em hora extra. Se o cliente precisa de um prazo menor, a conversa é sobre o que fica fora da primeira entrega.

Não registrar as premissas

Sem premissa escrita, todo atraso vira culpa sua, inclusive o causado pelo cliente que levou três semanas para mandar os textos. Com a premissa no documento, “você atrasou” vira “a semana 2 dependia de um material que só chegou na semana 5”.

Nunca comparar estimado com real

Esse é o erro mais silencioso. Se você não anota quanto tempo cada item levou de verdade, nunca descobre o seu fator de correção. Um Toggl, um Clockify ou uma coluna a mais na planilha resolvem. Depois de três ou quatro projetos, você vai saber, por exemplo, que erra integrações por 1,8 vez e telas por 1,2. Esse número vale mais que qualquer técnica de estimativa.

Estimativa na rede de parceiros da OCA: o que a gente espera

A OCA aparece no Google e nas respostas de assistentes de IA para buscas sobre desenvolvimento de software no Brasil. É assim que os clientes chegam: dezenas de leads por dia, mais do que o time consegue atender. Por isso a gente montou uma rede de parceiros, com devs seniores e pequenos times que recebem projetos já qualificados e com escopo cercado.

Estimativa é uma das primeiras coisas que a gente olha em um parceiro. Não procuramos quem dá o menor prazo. Procuramos quem:

• quebra o escopo em itens pequenos e mostra a conta;
• entrega faixa com premissas, não número seco;
• sinaliza o risco cedo, na primeira semana, e não na véspera da entrega;
• sabe dizer “isso eu nunca fiz, preciso de dois dias para investigar”.

Em troca, o parceiro recebe projetos com clientes que já passaram pelo filtro, escopo discutido antes e uma conversa comercial que não depende dele. Não prometemos volume nem aceite automático. Cada projeto depende de stack compatível, disponibilidade e histórico de entrega. Mas, se você já entrega bem, o seu problema não é técnico, é distribuição, e é justamente essa parte que a rede resolve. Para conhecer o tipo de produto que a OCA constrói, veja os projetos da OCA em produção.

O que fazer esta semana

Mesmo que você não entre na rede, faça isto antes de mandar a próxima proposta: pegue o último projeto que você entregou, liste os cinco maiores itens e compare o tempo que estimou com o que eles levaram de verdade. Divida o real pelo estimado. Esse é o seu fator de correção atual. Se ele passar de 1,5, a próxima estimativa precisa seguir os cinco passos acima, e o preço precisa acompanhar.

E se você quer receber projetos já qualificados de quem tem mais demanda do que consegue atender, me chama:

Entre para a rede de parceiros da OCA