PT

Como explicar decisões técnicas a clientes não técnicos

Como explicar decisões técnicas ao cliente não técnico: fale de resultados e compromissos, mostre em vez de contar, dê opções com custos e deixe o código de fora.

Nicolas Ricardi6 min de leitura

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:

  1. Custo: quanto agora, e quanto todos os meses a seguir.
  2. Prazo: quanto tempo, e se atrasa o lançamento.
  3. Risco: o que acontece se não fizermos isto.
  4. 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:

Da conversa de programador para os termos do cliente
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:

Exemplo: três opções para um plugin de reservas abandonado
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:

  1. A decisão numa frase. «Temos de decidir o que fazer com o sistema de reservas.»
  2. Porquê agora. O que acontece se esperar, nos termos do cliente.
  3. Mostre. O problema no ecrã, trinta segundos ou menos.
  4. As opções, com prazo, custo e risco.
  5. A sua recomendação e a razão.
  6. 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:

WhatsApp· para Joana

Olá Joana, três minutos sobre o sistema de reservas. Não há nada avariado, mas o plugin deixou de receber correções de segurança. Recomendo substituí-lo (cerca de dois dias de trabalho). Pode dizer-me até sexta-feira qual é a opção que prefere?

Sistema de reservas: três opçõesJustRec · 3:05

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.

Escrito por

Nicolas Ricardi

Maker of JustRec, at Nube

Nicolas makes JustRec at Nube, a web studio in Italy. He built it for the videos Nube sends to its own clients: design reviews, handovers and quotes explained in a few minutes instead of a meeting.

www.wearenube.dev
Vídeos para clientes