Erros comuns na comunicação com o cliente: como não frustrar seu cliente

Quando alguém solicita um projeto, temos que assumir que é muito importante e que eles se preocupam profundamente com o produto em que você estará trabalhando. Portanto, é seguro supor que um cliente é obrigado a criar muita expectativa em torno do produto final e, portanto, pode se emocionar quando se trata de entrega.

Ao longo do projeto, um cliente pode ficar super empolgado com um recurso entregue e amar você, e no dia seguinte ele ou ela pode descobrir que algo não funciona e esse carinho desaparecerá. Na maioria das vezes, é apenas uma questão de comunicação com o cliente que deu errado.

Embora não existam receitas para o sucesso no desenvolvimento remoto de software, acredito que existem algumas coisas que devem ser evitadas para manter um relacionamento saudável e produtivo com clientes que depositaram tanta confiança em suas mãos.

Não falhe na comunicação básica com os clientes

Imagine a comunicação com os clientes como faria diariamente com colegas de trabalho, amigos ou qualquer outra pessoa a quem você estenderia cortesia.

Se um velho amigo estiver visitando sua casa e você concordar em saborear uma iguaria local “na sua antiga casa” ao meio-dia, algumas semanas depois, você simplesmente apareceria lá? Você ficaria em contato enquanto isso, ligue para confirmar com alguns dias de antecedência? Ou talvez você suponha que eles estão muito ocupados e não gostaria de incomodá-los sem uma boa razão? Você esperaria que eles avisassem quando chegarem?

Não é provável que você continue conversando todos os dias, a menos que tenha muito o que conversar, mas manterá alguma forma de comunicação, por questão de cortesia e praticidade: você não quer que a outra pessoa pense que você se esqueceu dela , mas você definitivamente não quer dirigir no meio da cidade sem uma boa razão.

Em algum momento, você provavelmente também passou por situações semelhantes em sua comunicação profissional, mesmo com parceiros e colegas de trabalho de longa data. Alguns projetos são executados com o mínimo de comunicação, como dizer “o de sempre, ao meio-dia, nos vemos lá” para confirmar um almoço leve. Mesmo que algo aconteça, a outra parte certamente o informará e você concordará em reagendar.

No entanto, as coisas não são tão simples ou lineares no mundo do desenvolvimento de software.

Se você começar a trabalhar em um projeto, especialmente quando estiver lidando com um novo cliente, se ele nunca ouvir falar de você, ele começará a ter dúvidas sobre seu trabalho e compromisso. Mesmo que você apareça com um produto impecável depois de algumas semanas, os clientes já podem ter uma percepção menos do que ideal de você.

Embora às vezes pareça estranho, não faz mal conversar com o cliente, mesmo que você não tenha nada fora do normal para relatar! Você tem alguma dúvida sobre um pequeno ponto de uma história de usuário? Se você acha que é importante, deixe-os saber. Você está um pouco atrasado e não tem certeza se conseguirá cumprir a data prevista com a qual concordou? Ligue para o cliente o mais rápido possível! É melhor eles ouvirem sobre isso imediatamente.

Você não tem dúvidas e o projeto está perfeitamente dentro do prazo, mas o cliente não fala muito? Por que não enviar um e-mail descrevendo seu progresso a cada poucos dias? Não causará nenhum dano porque os e-mails não serão um incômodo para ninguém, além de você documentar seu progresso e manter uma comunicação regular com o cliente.

Falha na comunicação com o cliente gera expectativas irreais

Então, no início, eu mencionei que o cliente deve ter muitas expectativas sobre o projeto, certo? Certo. Período.

O cliente já espera muito do produto. Se não for como eles imaginaram, os clientes inevitavelmente ficarão frustrados. Então, por que alguém prometeria mais do que pode entregar, criando expectativas ainda mais irreais?

Aqui está um paralelo rápido: você comprou um tablet online e foi prometido entrega em 10 dias. No 8º dia, a loja informa que há um problema e atrasa a entrega em uma semana. Para compensá-lo pelo inconveniente, o varejista promete dar US$ 75 de crédito na loja.

Você provavelmente não precisaria realmente desse tablet nos próximos dias, então acha que é um bom negócio! Agora você pode aproveitar o tablet e usar o crédito da loja para comprar algo legal para seus filhos. Mas a loja liga no dia seguinte, dizendo que tudo foi resolvido durante a noite.

Você receberá o tablet no dia seguinte. Sem extras, sem crédito na loja. Agora é você que está frustrado!

"O que? Ainda ontem você me disse que eu faria um negócio melhor! Isso não é justo! Eu já disse para as crianças…”

Rebobine alguns dias e tudo o que você esperava era o tablet de qualquer maneira. Se ninguém tivesse lhe prometido um negócio melhor, você teria ficado satisfeito com seu brinquedo quando ele chegasse no dia seguinte. Mas agora, você sente que está perdendo sem uma boa razão, além da decisão da loja de informá-lo.

Como os desenvolvedores, especialmente os freelancers, podem evitar situações semelhantes em sua comunicação com os clientes?

Por não enlouquecer e dizer tudo o que vem à sua mente em primeiro lugar. Sugestões não são proibidas; na verdade, eles são muito bem-vindos se você achar que um recurso específico solicitado não é uma opção muito boa para resolver o problema em questão. Mas a chave é: pense primeiro.

• Ouça o cliente.

• Analise o problema deles.

• Analise a solução proposta.

• Certifique-se de que está dentro do orçamento/programação.

• Por fim, vá em frente e apresente sua sugestão.

É por isso que as habilidades de comunicação com o cliente podem ser complicadas, porque falhar em apenas uma das quatro primeiras etapas significa que você pode acabar desperdiçando seu tempo e, pior, o tempo do seu cliente.

Não assuma que você sabe o que o cliente precisa

Parafraseando Mary Schmich, Senhoras e senhores da classe de 17: Ouçam o cliente. Se eu pudesse te dar apenas uma dica para o futuro, seria ouvir o cliente.

Se você foi chamado para um projeto, é porque alguém precisa de algo. E quem saberia melhor sobre essa necessidade do que o seu cliente? Pode parecer óbvio, mas às vezes, no mundo real, as pessoas esquecem.

Deixe-me lhe dar um exemplo. Um varejista pede um “sistema de software” para seu negócio. Assim que você vê, você chega à conclusão de que o que eles querem é algo para registrar todos os produtos disponíveis, registrar todas as compras feitas, gerar recibos para os clientes e relatar o que foi vendido periodicamente e quais itens estão acabando estoque.

Então, no seu primeiro encontro, você quer mostrar que é eficiente e apresentar a eles o que preparou, as funcionalidades propostas, um design básico para combinar com a identidade visual da loja e tudo mais. Mas aí o cliente intrigado diz que, na verdade, o que eles precisam é de um algoritmo para calcular a melhor forma de expor os produtos nas gôndolas, com o objetivo de aumentar a receita de marcas e produtos específicos!

O erro aqui foi simplesmente não identificar qual problema você deveria resolver. Claro que, neste caso, como era muito cedo no projeto, haveria tempo de sobra para acertar, mas às vezes esse tipo de erro acontece mais adiante. Mesmo que não seja tão drástico quanto o exemplo anterior, ainda pode prejudicar o projeto e/ou seu relacionamento com o cliente.

Minha sugestão é a seguinte: converse muito com seus futuros usuários, se possível, e consulte vários stakeholders do projeto. São eles que têm uma boa visão geral da situação e sabem o que precisam. Tente descobrir o que eles fazem atualmente, a cada passo do caminho, e explique como o software seria útil. Gosto de dizer que, quando estou tentando entender o que um cliente deseja, meu objetivo é quase poder realizar seu trabalho sozinho. Se você chegar perto deste ponto, então você realmente descobriu quais são suas necessidades.

Não entender o que o cliente está pedindo

Não é incomum receber algum tipo de documentação sobre o problema em questão. Às vezes é apenas uma descrição de alto nível, enquanto outras vezes é um documento detalhado com casos de uso e regras de negócios. De qualquer forma, não importa quão claros sejam os registros, a única coisa que você não pode fazer é apenas supor que tudo o que está escrito lá é a verdade absoluta.

O que???

Exatamente. Primeiro, algo pode significar uma coisa para alguém, em um determinado contexto, e uma coisa completamente diferente para pessoas que não pertencem a essa realidade. E se há algo que você e o cliente não têm em comum, é o contexto!

Em segundo lugar, nem todo mundo é um escritor muito habilidoso; eles tentam dizer A, mas acabam descrevendo B.

Então, depois de ler tudo o que lhe foi enviado, como você vai ter certeza de que o que você leu é realmente o que eles significam? Bem, você vai digerir tudo, fazer algumas anotações, analisar tudo e... convocar uma reunião . (Você vê? É tudo uma questão de comunicação!) Na reunião, você falará sobre o problema e descreverá o que entendeu com suas próprias palavras. Nesta fase, você provavelmente será capaz de identificar quaisquer mal-entendidos.

“Ah, mas no meu caso não consegui nenhum documento. Eu apenas sentei com o cliente e eles me explicaram tudo enquanto eu fazia algumas anotações”.

Bem, ainda não há garantia de que você entendeu o que eles queriam dizer e minha sugestão continua de pé: reserve um tempo com suas anotações, pense em todo o problema, organize tudo, de preferência em algum tipo de linha do tempo de eventos, e depois ligue/reencontre-se com o cliente para apresentar o que você entendeu. Pode parecer repetitivo para você, mas às vezes nem mesmo o cliente tem uma visão completa de todos os processos envolvidos para realizar uma tarefa específica e então verá o quão complexo o software terá que ser.

No final, você deve ter certeza de que não há ambiguidade ou mal-entendido.

Por que você não deve entregar tudo o que o cliente pede sem pensar

OK, agora que você sabe que deve ouvir o cliente e confirmar o que entendeu, pode simplesmente ir em frente e fazer tudo o que ele pediu, certo?

Errado!

Agora é o momento em que você pode finalmente usar toda a experiência que tem e se perguntar: o que o cliente pediu vai resolver o problema dele? O que eles perguntaram é realmente o que eles precisam?

Você ficaria surpreso ao ver quantas vezes a resposta é “não”.

Antes de apenas entregar o que o cliente pediu, precisamos analisar o problema e, se você não concordar com o que o empregador propôs, é seu trabalho e responsabilidade profissional deixar isso claro. Claro, você deve, então, explicar por que você acha que a proposta deles não é boa e o que sua abordagem alternativa fará para resolver essas deficiências. Mais uma vez, a comunicação é a chave.

Se você e o cliente forem razoáveis, então você prosseguirá com sua solução ou terá uma sessão de brainstorming para chegar a uma melhor (caso sua ideia não seja aceitável para o cliente por algum motivo).

Protótipo — Não escreva uma documentação extensa

Eu já disse que você e seu cliente geralmente não têm a mesma perspectiva, certo? Portanto, assim como afeta sua compreensão da documentação deles, afetará a compreensão deles sobre o que você entrega por escrito. É uma questão de contexto também.

Então, concordo que de alguma forma (em um nível superior ou inferior), temos que documentar o que estamos prestes a desenvolver. Mas entregar várias páginas de texto sem nenhum elemento visual não fará muito bem. O cliente ficará entediado ao lê-lo, deixará de prestar atenção e provavelmente não conseguirá entender o que você quer dizer com essas complexas regras de negócios — ou interpretará algo completamente diferente do que você imaginou.

Tenha em mente que esses mal-entendidos podem ser ainda piores se o cliente não tiver formação técnica.

Todos esses fatores podem resultar no mesmo resultado problemático: os clientes reclamarão quando você entregar o produto porque é provável que não seja o que eles tinham em mente.

Aqui está o que eu sugiro: Sempre prototipe, mesmo que seja apenas um esboço para desenhar qual é o seu plano. E quaisquer definições que você tenha que fazer, comece por aí. Faça referências e tente mantê-lo simples.

Pare de perder tempo convencendo o cliente de que você está certo

Tenho quase certeza de que todo desenvolvedor já passou pela seguinte situação: No início do projeto, o cliente diz “Preciso que a cor de fundo do software seja amarela. Já foi acordado pela diretoria”. Então, quando o software é entregue eles dizem “Ah, mas a cor de fundo não pode ser amarela. Eu disse que tinha que ser verde!” Agora, como você deve lidar com isso?

Com certeza, não adiantará, em qualquer caso, apenas insistir que você estava certo e eles estavam errados. Se alguma coisa, isso só vai dar a você e ao cliente um tempo difícil.

É sempre bom ter um bom histórico de comunicação com o cliente, apenas para ter certeza de que você está na mesma página e deixar um rastro escrito. Na maioria das vezes, se for algo simples, você pode simplesmente enviar um e-mail ao cliente, dizendo: “Como combinamos naquela reunião, o plano de fundo do sistema será amarelo”. E se, no futuro, o cliente mudar de ideia, você pode argumentar que fez assim por causa daquela reunião mencionada no e-mail, mas se essa modificação realmente precisa ser feita, você pode executá-la, por mais x horas (e às vezes, um extra x dólares).

Mas se não há nada para provar que você estava certo, então você provavelmente tem uma decisão a tomar (assim como uma lição a aprender): a mudança é tão grande que exigirá uma mudança na arquitetura atual ou afetará outros recursos? Se não, provavelmente é melhor ir em frente, fazê-lo e colocar o cliente ao seu lado (mas com os olhos bem abertos para que isso não aconteça novamente). Se isso acontecer, uma conversa com o cliente será a melhor solução; não um foco em “como você estava certo”, mas em “como podemos corrigir o problema atual”.

De qualquer forma, a melhor maneira de evitar grandes modificações é fornecer novos recursos curtos em curtos períodos de tempo. Portanto, se algo tiver que ser mudado, provavelmente não será uma grande transformação do que já existe.

Saiba quando se comprometer com prazos

Por último, mas não menos importante, um dos maiores erros que você pode cometer é dar ao seu cliente um prazo para você terminar o projeto. E eles vão implorar para você cometer esse erro!

É claro que, como cliente, você quer saber quando poderá usar todos esses recursos interessantes que discutiu nas últimas semanas (meses?). Mas, como um projeto não é um produto definido, muita coisa pode acontecer desde o início do desenvolvimento até que o software esteja pronto para uso.

Em primeiro lugar, não se pode prever o imprevisível. É muito provável que você tenha que lidar com algo que não esperava. Pode ser uma licença que o cliente prometeu que não foi comprada na hora, ou algum outro software interno que você precisa usar, mas não foi lançado quando deveria, ou o ambiente era diferente do acordado no início, ou o cliente mudou de ideia sobre alguns (poucos) recursos e você teve que refazer algumas coisas.

Nada disso é realmente culpa do desenvolvedor e pode afetar profundamente o prazo de um projeto. Mas se você, querendo agradar o cliente, prometeu que entregaria tudo em alguma data e acaba, por todas as razões certas, não fazendo isso, uma coisa que posso garantir é que o cliente vai ficar, pelo menos um pouco , frustrado. Se você é um freelancer, precisa gerenciar seu tempo com eficiência, como explica este artigo do Toptal Engineering Blog. Não se esqueça de que o gerenciamento de relacionamento com o cliente também é seu trabalho.

Portanto, faça um favor a si mesmo e a quem depende do projeto e pelo menos dê uma estimativa de quanto tempo levará para desenvolver tudo, mas sempre deixe bem claro que é apenas uma estimativa e não um prazo.

Além disso, sugiro fortemente (especialmente se você já deu uma estimativa) que você sempre diga ao cliente quando algo está demorando mais do que o esperado para que ele possa agir para ajudá-lo!