Escopo aberto é prejuízo: como cercar o escopo antes de aceitar um projeto freelance

Você fechou o projeto por R$ 12 mil, estimou seis semanas, e na semana oito ainda está implementando "só mais um ajustezinho" que o cliente jura que estava combinado. Ninguém te enganou de propósito. O problema é que o escopo nunca foi cercado, e escopo que não é cercado cresce. Sempre na sua conta, nunca na do cliente.

Vou te falar como funciona do lado de quem recebe os leads: na OCA, a maioria dos projetos que chegam "para resgatar" de outro fornecedor não morreu por incompetência técnica. Morreu porque dev e cliente tinham duas versões diferentes do que era o projeto, e ninguém escreveu a versão oficial. Este artigo é o processo que eu uso para nunca mais cair nessa.

Por que escopo aberto quebra o freelancer (a conta é simples)

A conta é simples. Se você fechou um projeto de 120 horas por R$ 12 mil, sua hora vale R$ 100. Cada 12 horas de "ajustezinho" não previsto derrubam sua hora efetiva em R$ 10. Em projetos com escopo aberto, é comum entregar 40% a 60% de horas a mais do que o estimado. Suas R$ 100 por hora viram R$ 62. Você não percebe no extrato, percebe no fim do trimestre, quando fez a mesma renda de antes trabalhando muito mais.

E tem o custo invisível: enquanto você está preso nas semanas extras de um projeto que já foi pago, você não está prospectando nem entregando o próximo. Escopo aberto não come só o projeto atual, come o seu pipeline.

A verdade desconfortável: o cliente não sabe o que quer, e o trabalho de descobrir é seu

A maioria dos devs trata o levantamento de requisitos como burocracia antes do código. É o contrário: é a parte do trabalho que define se você vai ter lucro ou prejuízo. O cliente não é técnico. Quando ele diz "um app de delivery simples", na cabeça dele já existem cupom de desconto, notificação push, painel do lojista e chat com o entregador. Ele não está escondendo escopo, ele genuinamente acha que isso é "o básico".

Se você aceita a descrição vaga e precifica em cima dela, a diferença entre a versão da cabeça dele e a sua vira briga na entrega. E na briga da entrega, quem cede é quem quer receber o pagamento final. Ou seja, você.

O processo para cercar o escopo antes de assinar

Isso não é teoria, é literalmente como a OCA fecha projeto hoje. São quatro etapas, e nenhuma delas exige ferramenta paga.

1. Reunião de descoberta com perguntas de borda

Antes de qualquer número, faça uma call de 45 a 60 minutos. O objetivo não é entender o que o cliente quer, é encontrar as bordas do que ele quer. Perguntas que funcionam:

• "O que acontece quando o usuário faz X e dá errado?" (fluxos de erro dobram esforço e nunca estão na descrição inicial)
• "Quem administra isso? Existe um painel?" (o painel administrativo é o escopo fantasma número um)
• "Isso precisa conversar com algum sistema que vocês já usam?" (integração com ERP ou planilha legada é onde estimativas morrem)
• "O que a gente pode deixar para uma segunda fase?" (essa pergunta educa o cliente a pensar em versões, e é a base da renegociação futura)

2. Documento de escopo com lista de exclusões

Depois da call, escreva uma ou duas páginas descrevendo o que será entregue. A parte que quase ninguém faz, e que salva sua pele, é a seção "Fora do escopo desta fase". Liste explicitamente: painel administrativo, app iOS (se combinou só Android), relatórios exportáveis, integração com gateway de pagamento, o que for. Tudo que apareceu na conversa e não entrou no preço vai para essa lista, por escrito.

Quando o cliente pedir o item na semana cinco, você não discute memória. Aponta para o documento e diz: "Está na lista de fora do escopo, posso orçar como adicional". A conversa muda de conflito para orçamento.

3. Precificação por entregável, não por promessa

Quebre o valor por bloco entregável: "Fluxo de cadastro e login: R$ X. Listagem e busca: R$ Y. Checkout: R$ Z". Isso faz duas coisas ao mesmo tempo: mostra ao cliente de onde vem o preço (menos choro na negociação) e cria a régua para precificar mudanças depois. Se ele quiser um bloco novo, existe um precedente de valor por bloco, não uma negociação do zero.

4. Cláusula de mudança no contrato

Uma frase resolve 80% dos casos: "Solicitações fora do escopo descrito no Anexo I serão orçadas separadamente e formalizadas por escrito antes da execução." Simples assim. Sem essa cláusula, todo pedido novo vira zona cinzenta. Com ela, vira proposta comercial.

As armadilhas que pegam até dev experiente

• "É só um botãozinho." Não existe botãozinho. Existe funcionalidade com estado, validação, caso de erro e teste. Responda sempre com "deixa eu ver o esforço e te passo o valor", nunca com "faço rapidinho".
• Fazer cortesia calada. Se você decidir absorver um pedido pequeno para manter a relação, tudo bem, é uma decisão comercial válida. Mas comunique: "Isso está fora do escopo, vou incluir sem custo desta vez". Cortesia invisível vira obrigação na cabeça do cliente.
• Escopo cercado só na conversa. "Combinamos na call" não existe juridicamente nem comercialmente. Se não está escrito e aceito (e-mail com "de acordo" já resolve), não foi combinado.
• Aceitar "a gente vê isso depois" na fase de proposta. Item indefinido na proposta é item que você pagou para descobrir depois. Ou define agora, ou entra explicitamente como fase futura com orçamento futuro.
• Medo de parecer chato. Cliente sério respeita processo. Quem desiste do projeto porque você quis documentar o escopo estava planejando, consciente ou não, abusar dele.

Escopo bem cercado é o que separa fornecedor de parceiro

Tem um efeito colateral que pouca gente comenta: o processo acima muda como o cliente te enxerga. Dev que aceita tudo vago e depois se enrola é tratado como mão de obra. Dev que conduz descoberta, documenta exclusões e precifica mudança com critério é tratado como parceiro técnico. É o mesmo código, com o dobro do respeito e sem as horas de graça.

Na OCA, esse é um dos critérios que a gente mais olha antes de repassar um projeto. Hoje chegam mais leads pelo Google e pelas IAs do que o time consegue atender, e a saída foi montar uma rede de parceiros: devs e times seniores que recebem projetos já qualificados, com escopo cercado e cliente educado sobre o processo. O que a gente espera do parceiro é exatamente o que este artigo descreve: alguém que entrega bem e que trata escopo como parte do trabalho, não como detalhe. O que o parceiro recebe é o que mais falta para quem trabalha sozinho: projeto chegando sem precisar prospectar.

Se você já entrega bem, o seu problema não é técnico, é distribuição. E escopo mal cercado é o que impede sua entrega boa de virar um negócio saudável.

Entre para a rede de parceiros da OCA

O próximo passo que você pode dar esta semana

Independente da rede: pegue o último projeto que você orçou (ou o próximo que chegar) e escreva o documento de escopo com a seção "Fora do escopo desta fase". Vinte minutos de escrita. Se você olhar para trás e perceber quantas horas de graça essa seção teria evitado no seu último projeto, você nunca mais fecha nada sem ela.