Quando alguém solicita um projeto, temos que presumir que é muito importante e que eles se preocupam profundamente com o produto no qual você estará trabalhando. Portanto, é seguro presumir que um cliente está fadado a criar muitas expectativas em torno do produto final e, portanto, pode ficar emocionado quando se trata da entrega.

Ao longo do curso do projeto, um cliente pode ficar super empolgado com um recurso entregue e amá-lo, e no dia seguinte ele pode descobrir que algo não funciona e que o afeto se foi. Na maioria das vezes, é apenas uma questão de comunicação com o cliente que deu errado.

Embora não haja receitas para o sucesso quando se trata de desenvolvimento de software remoto , Acredito que há algumas coisas que deve ser evitado manter um relacionamento saudável e produtivo com os clientes que tanto confiam em suas mãos.

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

Imagine a comunicação com os clientes da mesma forma que a comunicação diária com colegas de trabalho, amigos ou qualquer outra pessoa a quem você estenda a 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ê poderia manter contato nesse meio tempo, ligar para confirmar com alguns dias de antecedência? Ou talvez você presuma que eles estão muito ocupados e não gostaria de incomodá-los sem um bom motivo? Você espera que eles avisem quando chegarem?

É improvável que você continue conversando todos os dias, a menos que tenha muito para falar, mas você manterá alguma forma de comunicação, por uma questão de cortesia e praticidade: você não quer que a outra pessoa pense que você se esqueceu dela, mas definitivamente não quer dirigir no meio do caminho para não 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 normal, ao meio-dia, vejo você aí” para confirmar um almoço leve. Mesmo se algo acontecer, 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 de você, começará a ter dúvidas sobre o seu trabalho e compromisso. Mesmo que você apareça com um produto perfeito após algumas semanas, os clientes podem já ter uma percepção menos do que ideal de você.

Embora às vezes possa parecer estranho, não faz mal conversar com o cliente, mesmo que você não tenha nada fora do comum para relatar! Você tem dúvidas sobre um pequeno ponto da história de um usuário? Se você acha que é importante, diga a eles. Você está um pouco atrasado e não tem certeza se conseguirá cumprir a data estimada que combinou? Ligue para o cliente o mais rápido possível! É melhor que eles fiquem sabendo imediatamente.

Você não tem dúvidas e o projeto está perfeitamente dentro do cronograma, mas o cliente não fala muito? Por que não enviar um e-mail descrevendo seu progresso em intervalos de alguns dias? Não fará mal nenhum porque os e-mails não incomodarão ninguém, além disso, você documentará seu progresso e manterá comunicação regular com o cliente.

A comunicação falha com o cliente promove expectativas irrealistas

Então, no começo, eu mencionei que o cliente costuma ter muitas expectativas em relação ao projeto, certo? Certo. Período.

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

Aqui está um rápido paralelo: Você comprou um tablet online e recebeu a promessa de entrega em 10 dias. No 8º dia, a loja avisa que há um problema e atrasa a entrega em uma semana. Para compensar o transtorno, o varejista promete dar a você um crédito de $ 75 na loja.

Você provavelmente não realmente preciso daquele tablet pelos próximos dias de qualquer maneira, então você acha que é um bom negócio! Agora você pode aproveitar o tablet, além de 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ê isso é frustrado!

'O que? Ontem mesmo, você me disse que eu faria um negócio melhor! Isso não é justo! Eu já disse para as crianças… “

Retroceda 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ê ficaria satisfeito com seu brinquedo quando ele chegasse no dia seguinte. Mas agora, você sente que está perdendo por um bom motivo, a não ser a decisão da loja de informá-lo.

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

Por não ficar louco e dizer tudo o que vem à sua mente em primeiro lugar. As sugestões não são proibidas; na verdade, eles são muito bem-vindo se você acha que um determinado recurso 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 / cronograma.

• 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 primeiras quatro etapas significa que você pode acabar perdendo seu tempo e, pior, o tempo do seu cliente.

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

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

Se você foi chamado para um projeto, é porque alguém precisa de algo. E quem saberia melhor sobre essa necessidade do que 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 o que você preparou, as funcionalidades propostas, um design básico para combinar com a identidade visual da loja e tudo. Mas então o cliente intrigado diz que, na verdade, o que ele precisa é de um algoritmo para calcular como exibir melhor os produtos nas prateleiras, visando aumentar a receita de marcas e produtos específicos!

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

Minha sugestão é a seguinte: Converse com seus futuros usuários, muito se possível, e consulte várias partes interessadas no projeto. Eles são os únicos com uma boa visão geral da situação e sabem o que precisam. Tente descobrir o que eles fazem atualmente, em cada etapa do processo, e explique como o software seria útil. Gosto de dizer que, quando tento entender o que um cliente deseja, meu objetivo é quase ser capaz de realizar seu trabalho sozinho. Se você chegar perto desse ponto, terá realmente descoberto quais são as necessidades deles.

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. Em qualquer caso, não importa quão claros sejam os registros, a única coisa que você não pode fazer é presumir que tudo que está escrito lá é a verdade absoluta.

O que???

Exatamente. Em primeiro lugar, 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 que você foi enviado, como você terá certeza de que o que você leu é realmente o que significa? Bem, você vai digerir tudo, fazer algumas anotações, analisar tudo e ... convocar uma reunião . (Está vendo? É 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. Neste estágio, você provavelmente será capaz de identificar quaisquer mal-entendidos.

“Ah, mas no meu caso, não recebi nenhum documento. Eu só 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 válida: reserve um tempo com suas anotações, pense em todo o problema, organize tudo, de preferência em algum tipo de cronograma de eventos, e depois ligue / reúna o cliente para apresentar o que você entendeu. Pode parecer repetitivo para você, mas às vezes até mesmo o cliente não 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á ambigüidade 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 seguir 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 para você resolverá o problema dele? O que eles perguntaram a você é 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 concorda 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 proposição 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, você continuará com sua solução ou terá uma sessão de brainstorming para propor uma melhor (no caso de sua ideia não ser aceitável para o cliente por algum motivo).

Protótipo - não escreva documentação extensa

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

Portanto, 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 quaisquer elementos visuais não vai te ajudar muito. O cliente ficará entediado com a leitura, parará de prestar atenção e provavelmente não será capaz de entender o que você quer dizer com essas regras de negócios complexas - ou eles interpretarão algo completamente diferente do que você imaginou.

Lembre-se 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 sugiro: Sempre faça um protótipo, mesmo que seja apenas um esboço para desenhar o seu plano. E quaisquer definições que você tenha que fazer, comece a partir daí. Faça referências e tente manter as coisas 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 pelo conselho. ” Então, quando o software é entregue, eles dizem “Oh, 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 adianta, em qualquer caso, apenas insistir que você estava certo e eles errados. No mínimo, isso apenas dificultará para você e para o cliente.

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

Mas se não houver nada para provar que você estava certo, então você provavelmente tem uma decisão a tomar (bem 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 não aconteça novamente). Em caso afirmativo, uma conversa com o cliente será a melhor solução; não um focado em “Como você estava certo,” mas em “Como podemos resolver o problema atual.”

Em qualquer caso, a melhor maneira de evitar grandes modificações é entregar 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 os prazos

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

Claro, como cliente, você quer saber quando será capaz de usar todos os 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 no prazo, ou algum outro software interno que você precisa usar, mas não foi lançado quando deveria, ou o ambiente era diferente daquele 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ê, disposto a agradar o cliente, prometeu que entregaria tudo em alguma data e acabaria, pelos motivos certos, não cumprindo, uma coisa que posso garantir é que o cliente vai ficar, pelo menos um pouco , frustrado. Se você é freelancer, precisa administrar seu tempo de forma eficiente, pois O artigo do blog de engenharia ApeeScape explica . Não se esqueça de que a gestão do relacionamento com o cliente também é sua função.

Então, faça um favor a si mesmo e a quem depende do projeto e pelo menos dê uma estimativa de quanto tempo vai demorar 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á fez uma estimativa) que você sempre diga ao cliente quando algo está demorando mais do que o esperado, para que ele possa ajudar você!

Compreender o básico

Como faço para melhorar as habilidades de comunicação?

Aprenda com seus erros e concentre-se em manter a comunicação profissional em todos os momentos. Peça feedback a clientes e colegas e, obviamente, continue lendo artigos como este caso precise de algumas dicas.

O que é comunicação eficaz?

Simplificando, qualquer comunicação que transmita a mensagem com o mínimo esforço possível é uma comunicação eficaz. Os clientes apreciam uma comunicação concisa e precisa, não uma conversa fiada que desperdiça tempo.

O que é comunicação interna?

A comunicação interna é a comunicação entre e seus colegas envolvidos no projeto. Este artigo se concentra na comunicação com o cliente, mas a comunicação entre equipes em projetos colaborativos é igualmente crucial para o seu sucesso.

Como lidar com clientes difíceis?

Calma e profissionalmente. No momento em que você perceber que o cliente pode ser difícil, faça o possível para comunicar-se demais, documentar tudo e evitar possíveis disputas. A prevenção é o seu melhor curso de ação.