Erreurs courantes dans la communication client : comment ne pas frustrer votre client

Quand quelqu'un demande un projet, nous devons supposer que c'est très important et qu'il se soucie profondément du produit sur lequel vous allez travailler. Ainsi, il est prudent de supposer qu'un client est tenu de créer beaucoup d'attentes autour du produit final et peut donc devenir émotif lorsqu'il s'agit de livraison.

Tout au long du projet, un client peut être très enthousiasmé par une fonctionnalité livrée et vous aimer, et le lendemain, il peut découvrir que quelque chose ne fonctionne pas et que cette affection aura disparu. Le plus souvent, c'est juste une question de communication client qui a mal tourné.

Bien qu'il n'y ait pas de recette pour réussir en matière de développement de logiciels à distance, je pense qu'il y a certaines choses qui doivent être évitées pour maintenir une relation saine et productive avec des clients qui ont placé tant de confiance entre vos mains.

N'échouez pas dans la communication de base avec les clients

Imaginez la communication avec les clients comme vous le feriez pour une communication quotidienne avec des collègues, des amis ou toute autre personne à qui vous feriez preuve de courtoisie.

Si un vieil ami rend visite à la maison et que vous acceptez de déguster une spécialité locale "chez vous" à midi, quelques semaines plus tard, vous présenteriez-vous simplement là-bas ? Souhaitez-vous rester en contact en attendant, appeler pour confirmer quelques jours à l'avance ? Ou peut-être supposeriez-vous qu'ils sont trop occupés et ne voudriez pas les déranger sans raison valable ? Vous attendriez-vous à ce qu'ils vous informent de leur arrivée ?

Il est peu probable que vous continuiez à bavarder tous les jours à moins que vous n'ayez beaucoup de choses à dire, mais vous maintiendrez une certaine forme de communication, par courtoisie et pragmatisme : vous ne voulez pas que l'autre personne pense que vous l'avez oubliée. , mais vous ne voulez certainement pas conduire à mi-chemin à travers la ville sans raison valable.

À un moment donné, vous avez probablement également vécu des situations similaires dans votre communication professionnelle, même avec des partenaires et des collègues de longue date. Certains projets sont exécutés avec un minimum de communication, comme dire « comme d'habitude, à midi, on se voit là-bas » pour confirmer un déjeuner léger. Même si quelque chose se passe, l'autre partie vous le fera sûrement savoir et vous accepterez de reprogrammer.

Cependant, les choses ne sont pas aussi simples ou linéaires dans le monde du développement logiciel.

Si vous commencez à travailler sur un projet, surtout lorsque vous avez affaire à un nouveau client, s'il n'a jamais de vos nouvelles, il commencera à avoir des doutes sur votre travail et votre engagement. Même si vous vous présentez avec un produit impeccable après quelques semaines, les clients peuvent déjà avoir une perception moins qu'idéale de vous.

Bien que cela soit parfois gênant, cela ne fait pas de mal de parler au client même si vous n'avez rien d'inhabituel à signaler ! Vous avez des doutes sur un tout petit point d'une user story ? Si vous pensez que c'est important, faites-leur savoir. Vous êtes un peu en retard et vous ne savez pas si vous serez en mesure de respecter la date estimée que vous avez convenue ? Appelez le client dès que possible ! Il vaut mieux qu'ils en entendent parler tout de suite.

Vous n'avez aucun doute et le projet est parfaitement dans les temps, mais le client ne parle pas beaucoup ? Pourquoi ne pas simplement envoyer un e-mail décrivant vos progrès tous les quelques jours ? Cela ne fera aucun mal car les e-mails ne seront une nuisance pour personne, de plus vous documenterez vos progrès et maintiendrez une communication régulière avec le client.

Une communication client défectueuse favorise des attentes irréalistes

Donc, au début, j'ai mentionné que le client avait forcément beaucoup d'attentes concernant le projet, n'est-ce pas ? Droit. Point final.

Le client attend déjà beaucoup du produit. Si cela ne se passe pas comme ils l'avaient imaginé, les clients seront inévitablement frustrés. Alors, pourquoi quelqu'un promettrait-il plus qu'il ne peut livrer, créant ainsi des attentes encore plus irréalistes ?

Voici un parallèle rapide : vous avez acheté une tablette en ligne et on vous a promis une livraison en 10 jours. Le 8e jour, le magasin vous signale qu'il y a un problème et retarde la livraison d'une semaine. Pour vous dédommager du désagrément, le détaillant promet de vous offrir un crédit en magasin de 75 $.

De toute façon, vous n'aviez probablement pas vraiment besoin de cette tablette pour les prochains jours, alors vous pensez que c'est une bonne affaire ! Vous pouvez maintenant profiter de la tablette et utiliser le crédit du magasin pour acheter quelque chose de sympa à vos enfants. Mais le magasin appelle le lendemain, disant que tout a été réglé du jour au lendemain.

Vous recevrez la tablette le lendemain. Pas d'extras, pas de crédit en magasin. Maintenant c'est toi qui es frustré !

"Quoi? Pas plus tard qu'hier, vous m'avez dit que j'obtiendrais une meilleure offre ! Ce n'est pas juste! J'ai déjà dit aux enfants..."

Rembobinez quelques jours et tout ce que vous attendiez était la tablette de toute façon. Si personne ne vous avait promis une meilleure offre, vous auriez été satisfait de votre jouet lorsqu'il est arrivé le lendemain. Mais maintenant, vous avez l'impression de manquer quelque chose sans raison valable, autre que la décision du magasin de vous le faire savoir.

Comment les développeurs, en particulier les indépendants, peuvent-ils éviter des situations similaires dans leur communication avec les clients ?

En ne devenant pas fou et en disant tout ce qui vous vient à l'esprit en premier lieu. Les suggestions ne sont pas interdites ; en fait, ils sont les bienvenus si vous pensez qu'une fonctionnalité particulière demandée n'est pas une très bonne option pour résoudre le problème en question. Mais la clé est la suivante : réfléchissez d'abord.

• Écoutez le client.

• Analysez leur problème.

• Analysez la solution proposée.

• Assurez-vous qu'il respecte le budget/échéancier.

• Enfin, allez-y et présentez votre suggestion.

C'est pourquoi les compétences en communication avec le client peuvent être délicates, car échouer à une seule des quatre premières étapes signifie que vous pourriez finir par perdre votre temps et, pire, le temps de votre client.

Ne présumez pas que vous savez ce dont le client a besoin

Paraphrasant Mary Schmich, Mesdames et Messieurs de la promotion 2017 : Écoutez le client. Si je ne pouvais vous proposer qu'un seul conseil pour l'avenir, ce serait celui-ci à l'écoute du client.

Si vous avez été appelé pour un projet, c'est parce que quelqu'un a besoin de quelque chose. Et qui connaîtrait mieux cette nécessité que votre client ? Cela peut sembler évident, mais parfois, dans le monde réel, les gens l'oublient.

Laisse moi te donner un exemple. Un commerçant demande un « système logiciel » pour son entreprise. Dès que vous le voyez, vous sautez à la conclusion que ce qu'ils veulent, c'est quelque chose pour enregistrer tous les produits disponibles, enregistrer chaque achat effectué, générer des reçus pour les clients et faire rapport sur ce qui a été vendu périodiquement et sur les articles qui manquent de Stock.

Ainsi, lors de votre premier rendez-vous, vous voulez montrer que vous êtes efficace et leur présenter ce que vous avez préparé, les fonctionnalités proposées, un design de base pour aller avec l'identité visuelle de la boutique et tout. Mais ensuite, le client perplexe dit qu'en réalité, ce dont il a besoin, c'est d'un algorithme pour calculer comment mieux afficher les produits sur les étagères, dans le but d'augmenter les revenus de marques et de produits spécifiques !

L'erreur ici était simplement de ne pas identifier le problème que vous étiez censé résoudre. Bien sûr, dans ce cas, comme c'était très tôt dans le projet, il y aurait beaucoup de temps pour faire les choses correctement, mais parfois, ce genre d'erreur se produit plus tard. Même si cela ne peut pas être aussi radical que dans l'exemple précédent, cela peut toujours nuire au projet et/ou à votre relation avec le client.

Ma suggestion est la suivante : Parlez à vos futurs utilisateurs, beaucoup si possible, et consultez les différentes parties prenantes du projet. Ce sont eux qui ont une bonne vue d'ensemble de la situation et ils savent ce dont ils ont besoin. Essayez de comprendre ce qu'ils font actuellement, à chaque étape du processus, et expliquez en quoi un logiciel serait utile. J'aime dire que lorsque j'essaie de comprendre ce que souhaite un client, mon objectif est de pouvoir presque faire son travail moi-même. Si vous vous approchez de ce point, alors vous avez vraiment découvert quels sont leurs besoins.

Ne pas comprendre ce que le client demande

Il n'est pas rare de recevoir une sorte de documentation sur le problème en question. Parfois, il s'agit simplement d'une description de haut niveau, alors que d'autres fois, il s'agit d'un document détaillé avec des cas d'utilisation et des règles métier. Dans tous les cas, quelle que soit la clarté des enregistrements, la seule chose que vous ne pouvez pas faire, c'est de supposer que tout ce qui y est écrit est la vérité absolue.

Quoi???

Exactement. Premièrement, quelque chose peut signifier une chose pour quelqu'un, dans un certain contexte, et une chose complètement différente pour des personnes qui n'appartiennent pas à cette réalité. Et s'il y a quelque chose que vous et le client n'avez pas en commun, c'est le contexte !

Deuxièmement, tout le monde n'est pas un écrivain très doué ; ils essaient de dire A mais finissent par décrire B.

Ainsi, après avoir lu tout ce que vous avez reçu, comment serez-vous sûr que ce que vous lisez est vraiment ce qu'il voulait dire ? Eh bien, vous allez tout digérer, prendre des notes, tout analyser et… convoquer une réunion . (Vous voyez ? C'est une question de communication !) Lors de la réunion, vous parlerez du problème et décrivez ce que vous avez compris dans vos propres mots. À ce stade, vous serez probablement en mesure d'identifier d'éventuels malentendus.

« Oh, mais dans mon cas, je n'ai reçu aucun document. Je me suis juste assis avec le client et ils m'ont tout expliqué pendant que je prenais des notes ».

Eh bien, il n'y a toujours aucune garantie que vous ayez compris ce qu'ils voulaient dire et ma suggestion est toujours valable : prenez du temps avec vos notes, réfléchissez à l'ensemble du problème, organisez tout, de préférence dans une sorte de chronologie des événements, puis appelez/rencontrez le client de présenter ce que vous avez compris. Cela peut vous sembler répétitif, mais parfois même le client n'a pas une vision complète de tous les processus impliqués pour accomplir une tâche spécifique et verra alors à quel point le logiciel devra être complexe.

À la fin, vous devez être certain qu'il n'y a pas d'ambiguïté ou de malentendu.

Pourquoi vous ne devriez pas livrer tout ce que le client demande sans réfléchir

OK, maintenant que vous savez que vous devez écouter le client et confirmer ce que vous avez compris, vous pouvez simplement continuer et faire tout ce qu'il vous a demandé, n'est-ce pas ?

Tort!

C'est maintenant le moment où vous pouvez enfin utiliser toute l'expérience que vous avez et vous demander : ce que le client vous a demandé va-t-il résoudre son problème ? Est-ce que ce qu'ils vous ont demandé est vraiment ce dont ils ont besoin ?

Vous seriez surpris de voir combien de fois la réponse est « non ».

Avant de simplement livrer ce que le client a demandé, nous devons analyser le problème et, si vous n'êtes pas d'accord avec ce que l'employeur a proposé, c'est votre travail et votre responsabilité professionnelle de le clarifier. Bien sûr, vous devriez alors expliquer pourquoi vous pensez que leur proposition n'est pas bonne et ce que votre approche alternative fera pour remédier à ces lacunes. Encore une fois, la communication est la clé.

Si vous et le client êtes raisonnables, vous devrez soit poursuivre avec votre solution, soit organiser une séance de remue-méninges pour en trouver une meilleure (au cas où votre idée ne serait pas acceptable pour le client pour une raison quelconque).

Prototype—N'écrivez pas de documentation détaillée

J'ai déjà dit que vous et votre client n'avez généralement pas la même perspective, n'est-ce pas ? Par conséquent, tout comme cela affecte votre compréhension de leur documentation, cela affectera leur compréhension de ce que vous livrez par écrit. C'est aussi une question de contexte.

Donc, je suis d'accord que d'une manière ou d'une autre (à un niveau supérieur ou inférieur), nous devons documenter ce que nous sommes sur le point de développer. Mais remettre plusieurs pages de texte sans aucun élément visuel ne vous fera pas grand bien. Le client s'ennuiera à le lire, cessera d'y prêter attention et ne sera probablement pas en mesure de comprendre ce que vous entendez par ces règles métier complexes, ou il interprétera quelque chose de complètement différent de ce que vous aviez imaginé.

Gardez à l'esprit que ces malentendus peuvent être encore pires si le client n'a aucune formation technique.

Tous ces facteurs peuvent entraîner le même résultat problématique : les clients se plaindront lorsque vous livrerez le produit, car il est probable que ce ne sera pas ce qu'ils avaient en tête.

Voici ce que je suggère : Prototypez toujours, même s'il ne s'agit que d'un croquis pour dessiner votre plan. Et quelles que soient les définitions que vous devez faire, partez de là. Faites des références et essayez de rester simple.

Arrêtez de perdre du temps à convaincre le client que vous avez raison

Je peux presque être certain que chaque développeur a vécu la situation suivante : Au début du projet, le client dit « J'ai besoin que la couleur de fond du logiciel soit jaune. Il a déjà été approuvé par le conseil d'administration. Ensuite, lorsque le logiciel est livré, ils disent « Oh, mais la couleur de fond ne peut pas être jaune. Je t'avais dit que ça devait être vert ! Maintenant, comment devriez-vous gérer cela ?

Bien sûr, il ne servira à rien, dans tous les cas, d'insister simplement sur le fait que vous aviez raison et qu'ils avaient tort. Au contraire, cela ne fera que vous donner du fil à retordre à vous et au client.

Il est toujours bon d'avoir un bon dossier de communication avec le client, juste pour s'assurer que vous êtes sur la même longueur d'onde et laisser une trace écrite. La plupart du temps, s'il s'agit de quelque chose de simple, vous pouvez simplement envoyer un e-mail au client en lui disant : "Comme nous en avons convenu lors de cette réunion, l'arrière-plan du système sera jaune". Et si, à l'avenir, le client change d'avis, vous pouvez affirmer que vous l'avez fait à cause de cette réunion mentionnée dans l'e-mail, mais si cette modification doit vraiment être apportée, vous pouvez l'exécuter, pendant x heures supplémentaires (et parfois, un extra x dollars).

Mais s'il n'y a rien pour prouver que vous aviez raison, alors vous avez probablement une décision à prendre (ainsi qu'une leçon à apprendre) : le changement est-il si important qu'il nécessitera une modification de l'architecture actuelle ou affectera d'autres fonctionnalités ? Si ce n'est pas le cas, il est probablement préférable d'aller de l'avant, de le faire et d'avoir le client à vos côtés (mais avec les yeux grands ouverts pour que cela ne se reproduise plus). Si c'est le cas, alors une discussion avec le client sera la meilleure solution ; pas un se concentrant sur "comment vous aviez raison", mais sur "comment nous pouvons résoudre le problème actuel".

Dans tous les cas, la meilleure façon d'éviter d'avoir à faire de grosses modifications est de fournir de courtes nouvelles fonctionnalités en peu de temps. Par conséquent, si quelque chose doit être changé, ce ne sera probablement pas une transformation majeure de ce qui existe déjà.

Savoir quand s'engager sur les délais

Enfin, l'une des plus grandes erreurs que vous puissiez commettre est de donner à votre client un délai pour terminer le projet. Et ils vous supplieront de faire cette erreur !

Bien sûr, en tant que client, vous voulez savoir quand vous pourrez utiliser toutes ces fonctionnalités intéressantes dont vous avez parlé au cours des dernières semaines (mois ?). Mais, comme un projet n'est pas un produit défini, il peut se passer beaucoup de choses depuis le début du développement jusqu'à ce que le logiciel soit prêt à être utilisé.

Tout d'abord, on ne peut pas prévoir l'imprévisible. Il est très probable que vous deviez faire face à quelque chose auquel vous ne vous attendiez pas. Il peut s'agir d'une licence que le client a promise et qui n'a pas été achetée à temps, ou d'un autre logiciel interne que vous devez utiliser mais qui n'a pas été publié au moment où il aurait dû l'être, ou l'environnement était différent de celui convenu au début, ou le client a changé d'avis sur (quelques) fonctionnalités et vous avez dû refaire quelques choses.

Rien de tout cela n'est vraiment la faute d'un développeur et peut profondément affecter le délai d'un projet. Mais si vous, désireux de plaire au client, avez promis de tout livrer à une certaine date et que vous finissiez, pour toutes les bonnes raisons, par ne pas le faire, une chose que je peux garantir est que le client sera, au moins un peu , frustré. Si vous êtes indépendant, vous devez gérer votre temps efficacement, comme l'explique cet article du Toptal Engineering Blog. N'oubliez pas que la gestion de la relation client est aussi votre travail.

Alors, rendez-vous service à vous-même et à celui qui dépend du projet et donnez-leur au moins une estimation du temps qu'il faudra pour tout développer, mais précisez toujours clairement qu'il ne s'agit que d'une estimation et non d'une échéance.

De plus, je suggère fortement (surtout si vous avez déjà fourni une estimation) de toujours informer le client lorsque quelque chose prend plus de temps que prévu afin qu'il puisse agir pour vous aider !