Mudança de escopo no projeto freelance: como cobrar o pedido extra sem brigar com o cliente (o fluxo de change request que a OCA usa)

Você fechou o projeto em R$ 24 mil, oito semanas, escopo combinado na call. Na semana três chega o primeiro áudio no WhatsApp: “consegue colocar um filtro por data nessa tela? É rapidinho”. Você faz, porque é rapidinho mesmo. Na semana cinco é um relatório em PDF. Na semana seis, login com Google, “que todo app tem”. Você faz tudo, porque não quer parecer difícil e porque cada pedido sozinho parece pequeno demais para virar conversa sobre dinheiro.

Na semana dez, o projeto de oito semanas ainda não acabou, o cliente está ansioso com o atraso e você está trabalhando de graça há um mês. Ninguém agiu de má-fé. O que faltou foi um processo para lidar com mudança de escopo enquanto o projeto acontece. É isso que este artigo resolve.

A verdade desconfortável: o cliente não sabe que está pedindo algo novo

Quase todo dev trata scope creep como problema de cliente folgado. Na prática, o cliente quase nunca sabe que o pedido é novo. Para quem não é técnico, “filtro por data” e “trocar a cor do botão” têm o mesmo peso. Ele não enxerga a query, o índice no banco, o teste, o estado vazio da tela, o ajuste no mobile.

Quem sabe que é novo é você. E se você faz calado, está ensinando ao cliente que aquilo era incluso. O silêncio vira contrato.

A conta é simples. Um projeto de R$ 24 mil estimado em 160 horas dá R$ 150 por hora. Agora some 12 pedidos “rapidinhos” de 3 horas cada, já contando teste e deploy: 36 horas extras. Sua hora efetiva cai para R$ 122. Você deu 18% de desconto sem ninguém pedir e ainda atrasou a entrega, o que deixa o cliente insatisfeito justamente com o trabalho que ele não pagou.

Mudança de escopo não é o problema. Software muda porque o cliente aprende usando. O problema é mudança sem preço, sem prazo e sem registro.

Como classificar cada pedido: ajuste, troca ou adição

Antes de responder qualquer pedido, classifique. Isso tira a emoção da conversa: você não está “cobrando o cliente”, está aplicando uma regra que ele conheceu antes de assinar.

A régua que uso para separar ajuste de adição: se exige lógica nova, tabela nova, endpoint novo ou integração nova, é adição. Se é mudança visual ou de texto dentro de algo que já existe, é ajuste.

A troca é a sua melhor ferramenta de negociação. Muitas vezes o cliente não quer gastar mais, quer mudar a prioridade. “Posso fazer o filtro por data no lugar do relatório de comissões, que ainda não comecei. Fica no mesmo preço e no mesmo prazo.” Resolve na hora, sem cobrança.

O fluxo de change request em 5 passos (o que a OCA usa)

Change request parece coisa de empresa grande com formulário em três vias. Não precisa ser. Na OCA funciona com um card no board e uma mensagem padrão. O que importa é a ordem.

1. Registre antes de responder

Todo pedido vira um item escrito, com data, quem pediu e a descrição nas palavras do cliente. Pedido feito em áudio vira texto seu: “Só para eu registrar direito: você quer X na tela Y, certo?”. Sem registro, em três semanas ninguém lembra quem pediu o quê.

2. Classifique e estime

Ajuste, troca ou adição. Se for adição, estime as horas com o mesmo método que você usou no projeto inteiro e aplique um fator de 1,3 para cobrir teste, revisão e o contexto que você perde ao interromper o trabalho em andamento.

3. Apresente três caminhos, não um preço

Um preço isolado soa como cobrança. Três caminhos soam como consultoria:

1. Somar: entra agora, custa R$ X e o prazo anda Y dias.
2. Trocar: entra no lugar de outro item do escopo de tamanho parecido.
3. Guardar: vai para a lista da versão 2, sem custo agora.

Na nossa experiência, uma parte relevante dos pedidos morre no terceiro caminho. Quando o cliente vê que o filtro custa um dia e meio e empurra a entrega, ele descobre que pode esperar. Isso não é receita perdida, é projeto entregue no prazo.

4. Aprovação por escrito

Um “pode fazer” no WhatsApp vale, desde que seja escrito e responda à sua mensagem com valor e prazo. Áudio não vale. Ligação só vale com um resumo por escrito logo depois.

5. Só então você abre o editor

Nenhuma linha de código antes da aprovação. É aqui que a maioria dos devs escorrega: começa “para adiantar” e depois fica sem argumento para cobrar algo que já está pronto.

Mensagem pronta e a conta para precificar o pedido extra

A mensagem que mais uso tem esta estrutura. Adapte ao seu tom:

“Oi, [nome]. Registrei o pedido do login com Google. Ele não estava no escopo que fechamos, então te passo os caminhos: (1) entra agora, são 8 horas, R$ 1.200, e a entrega final passa de 14/11 para 18/11; (2) entra no lugar do relatório de comissões, que ainda não comecei, sem mudar preço nem prazo; (3) fica para a versão 2. Qual você prefere?”

Os números do exemplo saem desta conta:

• Estimativa honesta: 6 horas (configurar o provedor, tela, vínculo com conta existente, teste).
• Fator de interrupção e teste: 6 × 1,3 = 7,8, arredondado para 8 horas.
• Hora do projeto: R$ 150. Total: R$ 1.200.
• Impacto no prazo: 8 horas de trabalho viram cerca de 2 dias úteis no calendário real, porque ninguém tem 8 horas limpas de foco por dia.

Duas regras evitam dor de cabeça. Primeira: tenha um mínimo de cobrança, algo entre 2 e 4 horas. Um pedido de 40 minutos ainda custa a troca de contexto, o deploy e a conversa. Segunda: use a mesma hora do projeto. Cobrar mais caro na mudança parece punição. Cobrar mais barato ensina o cliente a fatiar o projeto em pedidos extras.

Banco de horas para cliente que muda muito

Se você já percebeu na discovery que o cliente vai mudar bastante, ofereça na proposta um pacote pré-pago de mudanças, por exemplo 15 horas a R$ 140, total de R$ 2.100. O cliente ganha agilidade, porque pedidos pequenos entram sem orçamento individual, e você ganha caixa adiantado. Informe o saldo toda semana no report. Quando zerar, ele recompra ou volta ao fluxo normal.

As armadilhas que transformam mudança de escopo em prejuízo

O primeiro favor vira precedente

Fazer de graça uma vez “para criar relação” parece generoso. Na prática, o segundo pedido chega com a expectativa do primeiro. Se quiser dar um bônus, dê nome a ele: “esse eu faço sem custo como cortesia, os próximos seguem o fluxo”. Bônus sem nome vira escopo.

Acumular e cobrar tudo no fim

Você faz dez pedidos, anota tudo e manda a conta na entrega. Para o cliente, isso é emboscada: ele nunca aprovou aqueles valores. Mesmo com razão técnica, você perde a relação e provavelmente parte do dinheiro. Mudança se aprova antes, nunca depois.

Cobrar a adição e esquecer o prazo

Muito dev cobra o pedido novo e mantém a data original, por vergonha de “atrasar”. Aí aperta o resto do projeto, a qualidade cai e o bug que aparece depois vira discussão de garantia. Toda adição mexe no prazo. Diga quanto.

Orçar até a cor do botão

O extremo oposto também queima. Se você orça cada vírgula, o cliente se sente dentro de um processo burocrático e começa a esconder pedidos para negociar tudo de uma vez. Ajustes visuais e de texto dentro do escopo fazem parte do trabalho. Seja firme na adição e generoso no ajuste.

Escopo sem a lista do que está fora

Tudo isso fica difícil se o documento de escopo só diz o que entra. Escreva também o que não entra: login social, painel admin, notificação push, integração com ERP, versão em inglês. É muito mais fácil apontar para uma linha que o cliente já leu do que explicar uma ausência.

Como isso funciona nos projetos que a OCA repassa

Vou te falar como funciona do lado de quem recebe os leads: a OCA aparece no Google e nas IAs em buscas sobre desenvolvimento de software, e isso traz dezenas de pedidos de orçamento por dia, mais do que o nosso time consegue atender. Por isso montamos uma rede de parceiros: devs e pequenos times sêniores que recebem projetos já qualificados e escopados pela gente.

Mudança de escopo é um dos pontos que mais observamos num parceiro. Não esperamos que o projeto nunca mude, porque todo projeto muda. Esperamos que o parceiro:

• sinalize a mudança cedo, em vez de absorver calado e estourar o prazo;
• registre e estime cada adição antes de começar;
• mantenha o cliente informado sem transformar cada ajuste em negociação.

Em troca, o parceiro recebe projeto com discovery feita, escopo escrito e lista do que está fora, o que já elimina boa parte das discussões deste artigo. Não prometemos volume nem aceite na rede: avaliamos encaixe técnico, comunicação e histórico de entrega. Você pode ver o tipo de produto que construímos no portfólio de projetos da OCA.

O próximo passo

Se você entrega bem, sabe segurar escopo e quer receber projetos sem depender só da sua própria prospecção, fale com a gente:

Entre para a rede de parceiros da OCA

E uma ação para esta semana, independente da rede: pegue o projeto que você está tocando agora e mande ao cliente uma mensagem curta com a lista do que está fora do escopo e os três caminhos para pedidos novos (somar, trocar, guardar). Não precisa ser formal. Leva quinze minutos e evita o mês de trabalho de graça lá na frente.