Projeto freelance atrasou: como avisar o cliente sem perder o contrato (e o que fazer antes do estouro)

Você fechou o projeto, estimou oito semanas, e agora está na sexta semana com uns 50% de progresso real. O cliente pergunta "como está indo?" e você responde "indo bem, na reta final". Não está na reta final. Você sabe disso, o commit history sabe disso, e daqui a duas semanas o cliente vai saber também. Cada dia que passa, a conversa que você está evitando fica mais cara.

Vou te falar como funciona do lado de quem recebe os leads: uma parte relevante dos clientes que chegam na OCA vem de projeto que azedou com outro dev. E quando a gente pergunta o que aconteceu, quase nunca a resposta é "o código era ruim". A resposta é "ele sumiu", "o prazo passou e ninguém me avisou", "eu descobri o atraso sozinho". O atraso não matou o contrato. O silêncio matou.

A verdade desconfortável: o cliente aguenta atraso, não aguenta surpresa

Todo cliente que já contratou software mais de uma vez sabe que prazo de desenvolvimento escorrega. O que ele não perdoa é descobrir o atraso na data da entrega, porque aí o problema dele deixa de ser "o projeto atrasou duas semanas" e vira "eu não posso confiar em nada que esse dev me fala".

A conta é simples. Um atraso comunicado com três semanas de antecedência é um replanejamento. O cliente ajusta o lançamento, avisa o sócio, reorganiza o marketing. O mesmo atraso comunicado na véspera é uma crise, e crise precisa de culpado. Adivinha quem vai ser.

Tem um segundo ponto que dev evita encarar: quando você esconde o atraso, você está tomando uma decisão de negócio pelo cliente sem autorização. Ele pode ter um investidor esperando demo, um evento marcado, um contrato com fornecedor dependendo do sistema. Você não sabe o que depende daquela data. Ele sabe. Por isso a informação tem que chegar nele cedo, mesmo que seja desconfortável para você.

Como comunicar atraso de projeto: o roteiro em 4 partes

Quando um projeto aperta aqui na OCA, a mensagem para o cliente segue sempre a mesma estrutura. Não é script de vendas, é só a ordem que reduz pânico do outro lado:

1. O fato, sem enrolação, na primeira frase. "O módulo de pagamentos vai atrasar. A entrega que estava para o dia 20 vai para o dia 4." Nada de começar com três parágrafos de contexto antes da notícia. O cliente sente o cheiro de má notícia enrolada e fica mais ansioso, não menos.
2. A causa, em uma ou duas frases, sem vitimismo. "A integração com o gateway exigiu um fluxo de antifraude que não estava no escopo original" é causa. "Tive uns problemas pessoais e as coisas complicaram" é desabafo, e desabafo transfere o peso emocional para o cliente. Se a causa foi erro seu de estimativa, fale isso: "eu subestimei a complexidade dessa parte". Assumir erro técnico com clareza gera mais confiança do que qualquer desculpa.
3. O plano, com data nova e o que você já fez para protegê-la. Data nova sem plano é chute, e o cliente sabe. "A nova data é dia 4. Para garantir, eu já cortei X do caminho crítico e vou te mandar uma versão parcial dia 27 para você validar o fluxo principal antes." Entrega parcial no meio do replanejamento é o que separa "dev que atrasou" de "dev que está no controle".
4. A escolha, quando existir. Se dá para entregar no prazo original cortando algo, ofereça: "consigo manter dia 20 sem o painel de relatórios, que entraria dia 4. Ou entrego tudo junto dia 4. O que funciona melhor para o seu lançamento?" Devolver a decisão para o cliente transforma a conversa de confissão em reunião de trabalho.

Formato: ligação ou call curta primeiro, resumo por escrito depois. A ligação mostra que você não está se escondendo atrás de texto. O resumo escrito protege os dois, porque prazo renegociado só por áudio de WhatsApp é briga futura garantida.

Quando avisar: a regra dos 20%

A regra que uso: se o risco de atraso passa de uns 20% na sua cabeça, o cliente precisa saber. Não espere ter certeza. "Certeza de atraso" normalmente chega quando já não dá mais para fazer nada, e aí você não está comunicando risco, está comunicando fato consumado.

Na prática, avisar cedo soa assim: "quero te dar visibilidade de um risco. A parte de notificações está mais complexa do que estimei. Ainda estou trabalhando para manter o prazo, mas existe chance real de escorregar uma semana. Te confirmo até sexta." Isso custa dois minutos e compra uma coisa valiosa: quando o atraso se confirmar, ele não será surpresa. E se você recuperar o prazo, você vira o dev que avisa antes e resolve, que é exatamente a reputação que faz cliente indicar você.

Por que seu prazo estourou: os padrões que se repetem

Comunicar bem resolve a crise, mas se todo projeto seu atrasa, o problema está antes da comunicação. Os padrões que mais vejo, inclusive em projetos que a gente avalia antes de repassar para parceiros:

• Estimativa de caminho feliz. Você estimou o tempo de escrever o código funcionando de primeira. Não estimou ambiente, deploy, a API do terceiro com documentação errada, o retrabalho do feedback do cliente. Multiplicar a estimativa crua por 1,5 a 2x não é gordura, é a diferença entre "código pronto" e "projeto entregue". Depois de anos fazendo isso na OCA, nosso multiplicador quase nunca fica abaixo de 1,5.
• Prazo sem dependência mapeada. "Oito semanas" contando que o cliente manda logo, conteúdo, acesso ao servidor e aprovação de layout na hora. Ele não manda. Prazo sério tem condição escrita: "8 semanas a partir do recebimento dos acessos, com até 3 dias úteis para cada aprovação sua". Sem isso, o atraso do cliente vira atraso seu.
• Mudança de escopo sem mudança de prazo. O cliente pediu "só mais um campinho", você aceitou sem falar de prazo, e fez isso seis vezes. Cada "sim" sem reajuste é você assinando o próprio atraso. A resposta padrão é uma frase: "dá para fazer, adiciona X dias no prazo. Quer incluir?"
• Silêncio como estratégia. A pior. Você sabe que vai atrasar, trabalha de madrugada tentando um milagre e some do cliente enquanto isso. O milagre quase nunca vem, e você chega na data estourada, exausto e sem crédito nenhum de confiança para negociar.

Atraso e reputação: o que uma software house olha antes de repassar projeto

Isso não é teoria, é literalmente como a OCA cresceu: a gente aparece no Google e nas IAs, e chegam mais leads de cliente por dia do que o time consegue atender. A resposta foi montar uma rede de parceiros, devs seniores que recebem projetos já vetados, com escopo e orçamento fechados pela OCA.

E aqui vai o detalhe que conecta com este artigo: quando a gente avalia um parceiro, código bom é pré-requisito, não diferencial. O que a gente realmente testa é o comportamento sob atraso. Todo projeto tem um momento de aperto. O parceiro que manda "olha, isso aqui vai escorregar 4 dias, o motivo é X, o plano é Y" continua recebendo projeto. O parceiro que some por uma semana e aparece com desculpa não recebe o segundo. Se você já entrega bem, o seu problema não é técnico, é distribuição, e comunicação de prazo é metade da distribuição, porque é ela que gera indicação e recontratação.

Se esse jeito de trabalhar parece o seu, a rede está aberta: Entre para a rede de parceiros da OCA. Sem promessa de volume, com transparência sobre como funciona o repasse, do mesmo jeito que a gente descreve os projetos que a própria OCA opera em produção.

Uma ação para esta semana

Independente da rede: se você tem um projeto em andamento agora, faça o teste honesto. Pergunte a si mesmo qual a chance real de entregar na data combinada. Se a resposta passar de 20% de risco, mande a mensagem de visibilidade hoje, usando o roteiro deste artigo. Duas frases: o risco, e quando você confirma. Vai doer por dez minutos e vai te poupar de perder o cliente inteiro.

E no próximo orçamento, escreva as condições do prazo antes de enviar: o que precisa vir do cliente, em quanto tempo, e o que acontece quando não vem. Atraso comunicado cedo é gestão. Atraso descoberto pelo cliente é o fim do contrato.