# Como explicas ao teu cliente porque é que o projeto demorou mais do que o previsto?

Source: https://baqueiro.es/pt/la-sala-de-maquinas/como-explicar-atraso-projeto-cliente/
Published: 2025-07-30T07:05:00+00:00
Updated: 2025-07-30T07:05:00+00:00
Author: Baqueiro Desarrollo Web
Language: pt-PT
Usage: Attribution required: quoting allowed with a visible link back

---

**TL;DR**

- Um atraso mal comunicado prejudica mais a relação com o cliente do que um erro técnico: o erro corrige-se, a desconfiança custa muito mais a reparar.
- O método tem 3 passos: antecipar antes de o cliente dar por isso, explicar com contexto e sem jargão, e comprometer-se com um plano concreto.
- No final tens um modelo de email pronto a adaptar.

Os atrasos em desenvolvimento são tão frequentes que até têm lei própria. A lei de Hofstadter diz que qualquer projeto demora mais do que o previsto, mesmo quando tens em conta a lei de Hofstadter.

Serem frequentes não os torna menos incómodos de comunicar. E a forma como os comunicas decide, mais vezes do que parece, se o cliente fica ou se vai embora.

## Porque é que os atrasos destroem mais relações do que os erros técnicos

Quando aparece um bug importante, o cliente vive-o como um problema técnico. Há frustração, mas também um enquadramento claro: há um problema, alguém o está a resolver e existe um processo para isso.

Quando o projeto se atrasa e ninguém avisa, esse enquadramento desaparece. O cliente não sente que haja um problema técnico, sente que perdeu o controlo. Algo que esperava para uma data não vai chegar, e ninguém lhe tinha dito que isso podia acontecer. Essa sensação de perda de controlo costuma provocar uma reação mais intensa do que qualquer bug.

Além disso, os atrasos têm consequências reais. O lançamento muda de data, a campanha de marketing é adiada, a formação da equipa tem de ser reorganizada.

## Os 3 erros mais comuns ao comunicar um atraso

### Erro 1: esperar que o cliente dê por isso

O pior momento para comunicar um atraso é quando o cliente pergunta. A conversa começa a partir da frustração e qualquer explicação soa a justificação, não a transparência.

Um atraso que comunicas antes de o cliente o detetar transmite controlo. O mesmo atraso, comunicado depois, transmite que esperavas que ninguém reparasse.

### Erro 2: explicar o atraso em termos técnicos

“A integração com a API de terceiros teve um comportamento inesperado no ambiente de staging e tivemos de refatorizar parte do módulo de autenticação.” Tecnicamente preciso. Para o cliente, inútil.

O cliente não sabe o que é staging nem o que significa refatorizar, por isso não consegue avaliar se o motivo é grave ou trivial. Uma explicação técnica que não entende provoca 2 reações igualmente más: ou a interpreta como uma desculpa, ou sente que lhe estás a falar sem quereres ser entendido. Há mais ideias no nosso guia sobre [como apresentar a parte técnica de um projeto a um cliente que não é técnico](https://baqueiro.es/pt/la-sala-de-maquinas/apresentar-parte-tecnica-cliente-nao-tecnico/).

### Erro 3: dar um novo prazo sem explicar porque é mais fiável do que o anterior

Se o primeiro prazo não foi cumprido, porque é que o cliente havia de acreditar no segundo? Se não explicares o que mudou (que informação nova tens, que medidas tomaste), o novo prazo parece mais um número otimista que provavelmente também não será cumprido.

## O método de 3 passos

### Passo 1: antecipar, comunicar antes de o cliente dar por isso

Assim que a equipa percebe que um prazo não vai ser cumprido, o aviso deve chegar em horas, não em dias. Não esperes ter todos os detalhes resolvidos. Comunica que há um atraso, dá uma estimativa do impacto, mesmo que aproximada, e compromete-te a dar mais informação num prazo curto e concreto.

> “Estamos a ver que a entrega do módulo de reservas que tínhamos prevista para quinta-feira vai precisar de mais 2 dias do que o planeado. Estou a dizer-te já para teres margem para ajustar qualquer plano que dependa dessa entrega. Amanhã às 10 confirmo-te a nova data exata e o que podemos fazer para reduzir o impacto.”

Esta mensagem tem 3 elementos: reconhece o problema, estima o impacto e compromete-se com um próximo passo concreto. Não há desculpas técnicas nem promessas de soluções que ainda não existem.

### Passo 2: explicar com contexto, sem desculpas e sem jargão

A explicação tem de responder à pergunta que o cliente tem na cabeça mas quase nunca faz: “Isto é sintoma de um problema maior ou é algo pontual?”

Se for pontual:

> “O atraso vem de uma dependência externa que não controlávamos. O gateway de pagamentos que estamos a integrar teve um incidente no sistema deles que bloqueou os nossos testes durante 2 dias. Não é algo que possamos evitar por completo, mas também não é um padrão que já tenhamos visto com este fornecedor.”

Se for sistemático:

> “Sendo sinceros, subestimámos a complexidade desta parte do projeto. O que parecia uma integração normal tem mais camadas do que as que vimos na análise inicial. Mudámos a forma como estimamos este tipo de trabalho para que não volte a acontecer.”

A segunda resposta custa mais a dar, mas a longo prazo gera mais confiança do que uma explicação que o cliente vê como uma desculpa elaborada. E se a origem estiver em atalhos técnicos tomados antes, convém dizê-lo: a [dívida técnica](https://baqueiro.es/pt/ingenieria-sin-atajos/o-que-e-divida-tecnica-destroi-projetos/) está por trás de muitos atrasos que parecem surgir do nada.

### Passo 3: comprometer-se com um plano concreto, não com boas intenções

Um plano tem datas, ações concretas e, quando é preciso, aquilo de que precisas do cliente para o cumprir.

> “A nova data de entrega do módulo de reservas é a próxima terça-feira. Para a cumprirmos, precisamos que nos confirmes os textos dos emails de confirmação antes de sexta-feira. Se os tivermos na sexta, podemos comprometer-nos com a terça. Se quiseres incluir alguma alteração de âmbito antes da entrega, este é o momento. A partir de segunda-feira, qualquer alteração passa para a fase seguinte.”

Este tipo de mensagem consegue 2 coisas: dá ao cliente um plano em que pode confiar e envolve-o no seu cumprimento. Quando o cliente faz parte da solução, a forma como vive o atraso muda.

## Modelo de email para comunicar um atraso

Adapta-o a cada caso. O que está entre parênteses retos é o que tens de personalizar.

> **Assunto:** Atualização sobre [nome do projeto]: nova data de entrega
>
>
>
> Olá, [nome],
>
>
>
> Quero dizer-te diretamente que a entrega de [elemento concreto] que tínhamos prevista para [data original] vai sofrer um atraso de [número de dias ou semanas].
>
>
>
> O motivo é [explicação em linguagem clara, sem jargão técnico]. Não afeta o resto do projeto, mas afeta [o que afeta exatamente].
>
>
>
> A nova data de entrega é [data concreta]. Para a cumprirmos, [se precisares de algo do cliente: o quê exatamente e até quando; se não precisares de nada: “não precisamos de nada da tua parte, a bola está do nosso lado”].
>
>
>
> Sei que isto pode afetar [consequência concreta para o cliente, se houver]. Se for o caso, diz-me e vemos como reduzir o impacto.
>
>
>
> Para qualquer dúvida, liga-me ou escreve-me.
>
>
>
> [Nome]

O que faz este modelo funcionar é aquilo que não tem: nem desculpas longas, nem promessas vagas, nem jargão técnico, nem tom defensivo. É direto, concreto e vai à solução.

## O que fazer quando o cliente reage mal

Mesmo com a melhor comunicação, alguns clientes vão reagir com frustração. Não tentes eliminá-la: reconhece-a e segue em frente.

**O que não funciona:** pores-te na defensiva, dares mais detalhe técnico para provar que o atraso não é culpa da equipa ou prometeres que “não vai voltar a acontecer” sem um plano por trás.

**O que funciona:**

> “Percebo que isto vos cria um problema e lamento. O que te posso oferecer neste momento é [ação concreta]. Se houver mais alguma coisa que eu possa fazer para reduzir o impacto, diz-me.”

Essa resposta não elimina a frustração, mas leva a conversa da queixa para a solução, que é o único sítio a partir do qual a relação pode recuperar.

## Perguntas frequentes

**Há atrasos tão pequenos que não é preciso comunicá-los?**

Depende do contexto. Meio dia de atraso num projeto de 3 meses raramente justifica uma comunicação formal. Meio dia de atraso quando o cliente tem um lançamento nessa mesma tarde tem de ser comunicado de imediato. O critério não é o tamanho do atraso, mas o impacto que tem para o cliente.

**E se o atraso for consequência de algo que o cliente fez, como feedback tardio, alterações de âmbito ou aprovações lentas?**

É uma situação delicada. Tens de ser honesto sem soar acusatório. Apresenta os factos de forma objetiva:

> “O atraso de uma semana deve-se ao facto de os textos de que precisávamos terem chegado 10 dias depois da data acordada. Conseguimos absorver parte do impacto, mas essa semana não houve forma de a recuperar.”

Não há censura, mas a relação entre causa e efeito fica clara. Ajuda muito que o [contrato de desenvolvimento](https://baqueiro.es/pt/seguridad-y-juridico/clausulas-tecnicas-contrato-desenvolvimento/) deixe escrito desde o início o que acontece aos prazos quando o cliente se atrasa nas suas entregas.

**Quantos atrasos aguenta a relação com um cliente antes de se romper?**

Não há um número fixo. Depende da dimensão dos atrasos, da forma como são comunicados e da solidez da relação. Uma série de atrasos comunicados tarde e com desculpas desgasta a relação muito mais depressa do que a mesma série comunicada com antecedência e com planos concretos. Gerir bem as expectativas não elimina o problema, mas muda muito a forma como é percebido.

Na Baqueiro trabalhamos com protocolos de comunicação definidos para situações como esta, porque faz parte do que significa ser um [parceiro técnico e não um simples fornecedor de horas](https://baqueiro.es/pt/la-sala-de-maquinas/parceiro-tecnico-vs-fornecedor-horas/). Se quiseres saber como gerimos a comunicação nos projetos que acompanhamos, [falamos](https://baqueiro.es/pt/contacto/).