Como estimar prazo e esforço de projeto freelance sem chutar: o método que evita trabalhar de graça

Você recebe o briefing, olha as telas, pensa "tranquilo, umas três semanas" e manda a proposta. Na semana cinco, você ainda está no meio do projeto, o cliente cobrando prazo, e cada hora extra saindo do seu bolso. Se isso já aconteceu com você, não foi azar. Foi estimativa no chute.

Estimar mal é a forma mais silenciosa de trabalhar de graça. Você não vê o dinheiro saindo, só percebe no fim do mês que passou 60 horas num projeto que precificou como 30. Vou te falar como funciona do lado de quem estima projeto toda semana: a OCA recebe dezenas de leads por dia, e cada proposta que sai daqui passa por um processo de estimativa. Errar aqui custa margem, reputação e, no limite, o cliente.

Por que dev experiente também erra estimativa

A primeira verdade desconfortável: senioridade técnica não protege contra estimativa ruim. Dev bom tende a estimar o caminho feliz, o tempo de escrever o código que ele já sabe escrever. Só que o código é a menor parte do projeto.

O que ninguém coloca na conta:

• Comunicação com o cliente. Reunião, WhatsApp, explicar decisão técnica para leigo. Em projeto pequeno, isso come 15% a 25% do tempo total.
• Ida e volta de feedback. O cliente vai pedir ajuste. Sempre. Se a estimativa assume aprovação de primeira, ela já nasceu errada.
• Integração com o que já existe. API de terceiro mal documentada, gateway de pagamento com sandbox quebrado, ERP legado. Cada integração externa é uma caixa-preta de risco.
• Deploy, ambiente e entrega. Configurar produção, domínio, variável de ambiente, loja de aplicativo. No Revo, nosso app com mais de 40 mil usuários, a primeira publicação nas lojas levou mais tempo que a última feature do MVP.
• Bug pós-entrega. Se o contrato tem garantia (e deveria ter), esse tempo precisa estar precificado.

Quando você estima só o caminho feliz, está estimando talvez 50% do projeto real. A conta é simples: por isso tanto projeto de "três semanas" vira dois meses.

O método de estimativa que usamos na OCA

Isso não é teoria, é literalmente como a gente monta proposta aqui. Quatro passos.

1. Quebre o projeto em entregas pequenas antes de estimar qualquer número

Nunca estime "o app". Estime tela de login, cadastro, fluxo de checkout, painel admin, integração com Pagar.me, publicação nas lojas. Regra prática: se uma entrega passa de 16 horas na sua cabeça, ela ainda está grande demais e esconde complexidade. Quebre de novo.

O ato de quebrar já é metade da estimativa. É nesse momento que você descobre o "ah, mas também precisa de recuperação de senha" que ninguém tinha falado. Cada item que você descobre agora é um item que não vira surpresa no meio do projeto.

2. Estime em faixas, nunca em número seco

Para cada entrega, defina dois números: o cenário bom e o cenário ruim. "Checkout: 12 a 20 horas." A faixa te obriga a pensar no que pode dar errado, e o tamanho dela revela onde está o risco. Se uma entrega tem faixa de 8 a 30 horas, você não tem um problema de estimativa, tem um problema de definição: falta informação do cliente antes de assinar qualquer coisa.

Na proposta, você pode até apresentar um número fechado. Mas internamente, sua conta é feita sobre o cenário ruim das entregas críticas, não sobre a média otimista.

3. Aplique o multiplicador de realidade

Somou as faixas? Agora multiplique. Nossa referência interna:

• 1,3x quando o escopo está bem definido, você domina a stack e não há integração externa.
• 1,5x no projeto padrão: cliente leigo, uma ou duas integrações, algum ponto de incerteza.
• 1,8x a 2x quando envolve sistema legado, API sem documentação decente ou cliente que "ainda está definindo" partes do produto.

Parece exagero até você medir. Faça o exercício: pegue seus três últimos projetos e compare estimado com realizado. Se você nunca mediu, é quase certo que seu erro histórico está acima de 40%. O multiplicador não é gordura, é a correção estatística do seu próprio otimismo.

4. Registre estimado versus realizado em todo projeto

Uma planilha resolve: entrega, horas estimadas, horas reais. Depois de três ou quatro projetos, você conhece o seu viés pessoal. Tem dev que subestima integração e acerta CRUD. Tem dev que subestima tudo que envolve front. Esse histórico vale mais que qualquer técnica de estimativa, porque é calibrado em você.

Prazo de calendário não é soma de horas

Erro clássico: o projeto dá 80 horas, você trabalha 8 por dia, logo "duas semanas". Não. Duas coisas quebram essa conta.

Primeiro, ninguém produz 8 horas de código por dia, todos os dias, ainda mais tocando mais de um projeto ou conciliando com CLT. Uma referência honesta é 4 a 5 horas produtivas diárias em cima de um mesmo projeto.

Segundo, existe o tempo que não é seu: o cliente leva três dias para aprovar o layout, dois para mandar o logo, uma semana para responder sobre a regra de negócio. Esse tempo não consome suas horas, mas estica o calendário. Um projeto de 80 horas de esforço raramente sai em menos de 4 a 5 semanas de calendário. Prometa o prazo de calendário, não o de esforço, e deixe explícito na proposta que aprovações do cliente pausam o cronograma.

Quando a estimativa vira arma de negociação

Estimativa bem-feita muda a conversa comercial. Em vez de defender um número mágico, você mostra a quebra: "o checkout custa X porque envolve gateway, antifraude e webhook de confirmação". Cliente confia em quem mostra o raciocínio. E quando ele pedir para caber no orçamento, você negocia escopo, não preço: "nesse valor entregamos sem o painel admin na primeira fase". A estimativa detalhada é o que te permite tirar peça do tabuleiro em vez de derreter sua hora.

Ela também te protege do cliente que compara sua proposta com uma de um terço do preço. Quem cobrou um terço estimou o caminho feliz. Você pode dizer isso com elegância mostrando a lista de itens que a sua proposta cobre e perguntando se a outra cobre também.

As armadilhas que ainda pegam quem já sabe estimar

• Estimar na frente do cliente. "Quanto ficaria mais ou menos?" na reunião é armadilha. Qualquer número dito ali vira teto. Responda com faixa larga e prazo para a proposta formal.
• Assumir que o cliente sabe o que quer. "Um app simples de agendamento" pode ser 60 ou 400 horas. Estimativa começa com pergunta, não com número.
• Não reestimar quando o escopo muda. Cada "aproveita e adiciona" precisa passar pelo mesmo processo: quebrar, estimar em faixa, comunicar impacto no prazo. Por escrito.
• Comprimir a estimativa para ganhar a concorrência. Você ganha o projeto e perde o lucro. Projeto no prejuízo ainda cobra as mesmas horas suas, só que sem pagar por elas.

Estimar bem é critério de parceria, não só de sobrevivência

Aqui vai o lado que pouca gente vê. A OCA recebe mais projetos do que consegue atender e repassa demandas qualificadas para uma rede de devs parceiros. Quando avaliamos um parceiro, a capacidade técnica é o ponto de partida, não o diferencial. O que separa quem recebe projeto de quem não recebe é previsibilidade: a pessoa estima, cumpre, e quando algo foge do estimado, avisa antes do estouro, não depois.

Um dev que entrega em 5 semanas o que prometeu em 5 semanas vale mais para a rede do que um que promete 3 e entrega em 6, mesmo que os dois escrevam o mesmo código. Se você já entrega bem, o seu problema não é técnico, é distribuição, e estimativa confiável é exatamente o que permite alguém te distribuir projetos com segurança. Dá para ver o tipo de projeto que passa por aqui no portfólio da OCA.

Entre para a rede de parceiros da OCA

O que fazer esta semana

Independente da rede, uma ação concreta: pegue seu último projeto entregue e reconstrua a estimativa com este método. Quebre em entregas de até 16 horas, coloque faixas, aplique o multiplicador e compare com as horas que você realmente gastou. A diferença entre os dois números é o quanto você vem pagando para trabalhar. No próximo orçamento, essa conta já entra a seu favor.