public
Created

Falando a língua do cliente

  • Download Gist
cliente.md
Markdown

Falando a língua do cliente

Hoje deparei-me com uma situação que me fez refletir sobre a forma como o cliente interpreta as informações recebidas por programadores e, por esta e outras, vou falar um pouco, dando uma dica para quem é da área.

A situação no caso é que, ha alguns anos desenvolvi um sistema de loja virtual simples para um amigo. Por não ter conhecimentos de programação, ele buscou uma empresa para oferecer serviços de hospedagem e manutenção para o site. Eis que hoje recebo um email deste amigo pedindo que eu “desse uma olhada e tentasse entender” uma proposta enviada pela empresa responsável. A proposta, em poucas palavras, dizia que o código do sistema era muito ruim, que ocorriam alguns erros no sistema e que, para resolver o problema, seria necessário um refactoring de tudo. Até aí tudo bem, o código do sistema pode ser melhorado de fato, e muito. Mas o que me chamou atenção nisso tudo, foi um trecho do email relatando os problemas da aplicação, em uma linguagem mais técnica e pouco explicativa. O trecho dizia o seguinte: “sobrecarga de método, excesso de consultas no banco, mau uso de variáveis de sessão, pouquíssimos tratamentos de erros”.

Com certeza esta proposta não teve muito sentido para o cliente, uma vez que ele não entendeu o que de fato seria melhorado no site e pediu auxílio para saber da coerência sobre o que estava sendo dito. Uma proposta que não convença e, além disso, cause questionamentos fundamentais por parte do cliente pode prejudicar a empresa de várias formas, desde o desperdício de tempo até consequências como falta de confiança. Muitas vezes nós desenvolvedores tendemos a falar dessa forma, não é nenhuma novidade, mas o que podemos fazer para mudar isso?

Primeiro de tudo, separo estas propostas mal-sucedidas de duas formas: a proposta que de fato não traz nenhum benefício ao cliente e aquela que não consegue explicar os benefícios que trará. Para não correr estes riscos, estude se as mudanças propostas irão realmente trazer retorno ao cliente, a solução nem sempre está em resolver os problemas mais técnicos da aplicação, mas sim no resultado final. Usando o exemplo citado, não podemos oferecer ao cliente alterações nos códigos que fazem consultas no banco de dados (para não haver “excesso de consultas”) quando esta alteração não fizer nenhuma diferença para o negócio. Digamos que o site funcione perfeitamente da forma em que está, de acordo com a quantidade de acessos e recursos de servidor. Neste caso, qual o verdadeiro resultado para o cliente? Nenhum, pois o mesmo irá investir em algo que não lhe trará retorno.

Quando a proposta realmente for boa para o negócio, é necessário deixar claro de forma que o cliente entenda os benefícios, utilizando uma linguagem de fácil compreensão, pois uma linguagem técnica e muito detalhada pode confundir ou não soar legal até mesmo para alguém com experiência na área. O cliente quer saber se o investimento vale a pena, e por isso está mais preocupado com o resultado do que os detalhes que envolvem a solução. Ele quer saber se a solução vai aumentar a taxa de conversões, se os compradores não desistirão durante a compra, se isso fará com que ele venda mais produtos, enfim, resultados mensuráveis e que realmente façam diferença.

O caso citado é bastante específico, porém estes princípios podem ser aplicados para qualquer proposta, desde uma pequena conversa até um documento mais elaborado. Empresas que destinam profissionais de vendas para este tipo de comunicação com cliente geralmente têm menores dificuldades, porém sabemos que o nosso cliente nem sempre é aquele que contratou o serviço da empresa, mas podemos interpretar como o líder do projeto, colega ou qualquer pessoa envolvida e, para estes, vale a mesma dica.

Please sign in to comment on this gist.

Something went wrong with that request. Please try again.