Em resumo
- Os clientes não precisam de saber como funciona. Precisam de saber quanto custa, quanto tempo demora, qual é o risco e o que muda para eles.
- Mostre o efeito no ecrã, como a página lenta ou o checkout avariado, em vez de o descrever.
- Uma analogia do mundo do cliente ajuda; diga onde deixa de funcionar.
- Dê duas ou três opções com custo, prazo e risco, e recomende uma.
- Nunca mostre código que o cliente não pediu, e nunca mostre credenciais.
Para explicar decisões técnicas ao cliente que não é técnico, fale do que muda para ele, não de como funciona: quanto custa, quanto tempo demora, o que acontece se não o fizer e o que muda para a equipa dele. Mostre o problema no ecrã em vez de o descrever, ofereça duas ou três opções com os respetivos compromissos e recomende uma. Uma gravação de ecrã curta é um bom formato para isto, porque o cliente vê com os próprios olhos a página lenta ou o botão avariado.
Este guia foi escrito para programadores freelancers e equipas de agência que precisam da decisão de um cliente sobre algo que o cliente não consegue avaliar sozinho.
Fale de resultados e de compromissos
O seu cliente não quer saber da framework, da base de dados ou do plugin. Quer saber de quatro coisas:
- Custo: quanto agora, e quanto todos os meses a seguir.
- Prazo: quanto tempo, e se atrasa o lançamento.
- Risco: o que acontece se não fizermos isto.
- Mudança: o que fica diferente para ele e para a equipa dele depois.
Traduza cada ponto técnico para esses termos antes de o explicar:
| O que diria a um colega | O que o cliente precisa de ouvir |
|---|---|
| «O plugin de reservas está abandonado.» | «O sistema de reservas deixou de receber correções de segurança. Hoje funciona, mas cada mês que fica, o risco aumenta.» |
| «Devíamos pôr cache.» | «As páginas vão carregar mais depressa. Depois de editar uma página, a alteração pode demorar uns minutos a aparecer.» |
| «Vamos passar para um CMS headless.» | «Mais liberdade no design, mas dois sistemas para manter em vez de um, e um custo mensal mais alto.» |
| «Há muita dívida técnica.» | «Atalhos tomados no passado tornam cada nova funcionalidade mais lenta e mais cara de fazer.» |
Se uma frase continua a precisar de uma palavra técnica para fazer sentido, explique a palavra uma vez, de passagem, e siga em frente.
Mostre, não conte
«A página está lenta no telemóvel» é uma opinião. Uma gravação da página a demorar uma eternidade a mostrar as fotografias dos produtos numa janela do tamanho de um telemóvel é um facto que o cliente pode ver. O vídeo é a forma mais fácil de mostrar um problema técnico a alguém que não está à frente do seu ecrã:
- O problema como o cliente final o vê: o botão de checkout que não faz nada no Safari, o formulário que perde o que se escreveu.
- O antes e o depois: a página antiga e a mais rápida, lado a lado.
- O ecrã que ele vai usar: o painel de administração depois da mudança, para que «um novo editor» deixe de ser abstrato.
Faça um círculo à volta da parte que importa enquanto fala. Desenhar no ecrã durante a gravação resolve isso bem; veja como desenhar no ecrã enquanto grava no Mac.
Use as analogias com cuidado
Uma boa analogia tirada do mundo do cliente faz uma decisão encaixar. Algumas que costumam funcionar:
- A manutenção e as atualizações são como a revisão do carro: se a saltar, o carro continua a andar, até deixar de andar.
- A dívida técnica é como a cozinha de um restaurante que não é limpa entre serviços: cada serviço é mais lento do que o anterior.
- As cópias de segurança são como um seguro, só que deve confirmar que funcionam antes de precisar delas.
Use uma por decisão, não uma por frase. E diga onde falha: «ao contrário de um carro, uma falha de segurança pode ser explorada por outra pessoa antes de se notar alguma coisa». Uma analogia que esconde um custo ou um risco é pior do que nenhuma.
Dê opções com os respetivos custos
A maioria das decisões técnicas tem mais do que uma resposta. Apresente duas ou três, incluindo «não fazer nada» quando for uma opção real, e ponha-as lado a lado:
| Opção | Prazo | Custo contínuo | Risco |
|---|---|---|---|
| Deixar como está | Nenhum para já | Nenhum | Aumenta todos os meses sem correções |
| Substituir por um plugin mantido | Cerca de dois dias | Uma licença anual | Baixo; as reservas passam para o novo |
| Criar um formulário de reservas à medida | Cerca de duas semanas | O nosso tempo de manutenção | Baixo, mas mais coisas para manter |
Um exemplo hipotético: prazos e custos dependem do projeto.
Depois recomende uma e diga porquê, numa frase: «Nós substituíamos pelo plugin mantido: dois dias de trabalho, e o risco desaparece.» Os clientes decidem mais depressa quando o trabalho de pensar já está feito e só precisam de concordar. Para a parte do dinheiro, apresentar um orçamento ao cliente por vídeo segue a mesma abordagem.
Uma estrutura para a explicação
Quer grave um vídeo, quer escreva um email, esta ordem funciona:
- A decisão numa frase. «Temos de decidir o que fazer com o sistema de reservas.»
- Porquê agora. O que acontece se esperar, nos termos do cliente.
- Mostre. O problema no ecrã, trinta segundos ou menos.
- As opções, com prazo, custo e risco.
- A sua recomendação e a razão.
- O pedido, com uma data. «Pode dizer-me até sexta-feira qual é a opção que prefere?»
Decisão técnica: um plugin abandonado
De um programador freelancer para o cliente de um pequeno negócio · Cerca de 3 minutos
Olá Joana, preciso de uma decisão sua sobre o sistema de reservas. Hoje não há nada avariado, mas o plugin que o faz funcionar deixou de ser mantido, o que quer dizer que não vai ter mais correções de segurança.
Esta é a página de reservas como os seus clientes a veem. Há três opções: deixar como está, que agora não custa nada mas fica mais arriscado todos os meses; substituir por um plugin mantido, cerca de dois dias de trabalho mais uma licença anual; ou criarmos um formulário nosso, cerca de duas semanas. Eu ia pela segunda: resolve o risco e a sua equipa nem vai dar pela mudança. Pode dizer-me até sexta-feira?
Envie-o também com o pedido por escrito, para a Joana poder responder do telemóvel sem voltar a ver o vídeo:
O que não mostrar
Uma gravação de ecrã para um cliente não é uma revisão de código. Deixe de fora:
- Código. A não ser que o cliente o peça, o código só transmite «isto é complicado».
- Credenciais. Palavras-passe, chaves de API, ficheiros de ambiente, histórico do terminal com tokens. Envie os acessos através de um gestor de palavras-passe, nunca num vídeo.
- Registos com dados de clientes. Os registos de erros contêm muitas vezes nomes, emails e pormenores de encomendas.
- Projetos de outros clientes. A barra lateral do seu editor e os separadores do browser podem mostrá-los.
- Conversas internas sobre o cliente ou sobre o problema.
Quando explicar ao vivo
Algumas decisões técnicas são grandes demais para um vídeo sozinho: uma reconstrução, uma mudança de plataforma, tudo o que mexa muito no orçamento. Envie o vídeo como preparação e decidam depois numa reunião curta. Tratamos a fronteira entre os dois em quando não deve enviar um vídeo a um cliente.
E guarde as explicações para mais tarde. Quando o projeto termina, a mesma abordagem dá uma boa entrega: os vídeos de entrega do site mostram ao cliente como as coisas funcionam sem uma única linha de código. O guia completo da comunicação assíncrona com clientes por vídeo junta tudo isto, e a nossa página para freelancers mostra como o JustRec se adapta a quem trabalha sozinho.
Perguntas frequentes
Como se explica uma decisão técnica a um cliente não técnico?
Comece pelo que muda para ele: custo, prazo, risco e trabalho do dia a dia. Mostre o problema no ecrã, ofereça duas ou três opções com os respetivos compromissos, recomende uma e peça uma decisão com uma data.
Devo mostrar código a um cliente?
Quase nunca. O código diz a um cliente não técnico que uma coisa é complicada, não porque é que importa. Mostre antes a página, o erro ou o ecrã de administração que ele vai usar.
As analogias são boa ideia para explicar temas técnicos?
Sim, uma de cada vez e do mundo do cliente. Diga onde a analogia deixa de funcionar, para não esconder um custo ou um risco.
E se o cliente pedir os pormenores técnicos?
Dê-lhos, em poucas palavras, depois do resultado. Alguns clientes têm uma pessoa técnica do lado deles que os vai querer; ofereça uma nota escrita curta para essa pessoa.
As decisões técnicas devem ser explicadas em vídeo ou numa reunião?
Um vídeo curto funciona para a maioria das decisões, porque o cliente vê o problema e pode rever as opções. Para escolhas grandes ou caras, envie primeiro o vídeo e decidam numa reunião.



