En tant que développeur, comment devons-nous communiquer avec les membres de notre équipe ou avec nos clients ? Comment communiquer efficacement et comment bien communiquer avec les autres ?
L'épisode est disponible à l'écoute sur :
YouTube : https://youtu.be/xCKjq1vVriA
Hello world et bienvenue à la Veille Tech
L’art de communiquer en tant que développeur
Lorsque j’étais à l’université, les étudiants en informatique ou en mathématiques étaient considérés comme des personnes timides pour la plupart parce qu’on jugeait qu’ils ne communiquaient pas.
Dans les films, l’informaticien est présenté comme étant chétif, calme et parfois peureux comme le visage timide d’Eliot dans Mr Robot,
pourtant, certaines personnes comme Chloé O’Brian avaient des sautes d’humeurs et elle était très active en communication.
Toutes ses attitudes, comportement ou expression sont une réalité qu’il ne faut pas généraliser à tous les informaticiens, mais qu’il faut plutôt généraliser à tous les êtres vivants. La communication est un art, elle s’apprend et fait partie intégrante de notre réussite dans la vie.
En tant que développeur, comment devons-nous communiquer avec les membres de notre équipe ou avec nos clients ? Comment communiquer efficacement et comment bien communiquer avec les autres ?
Alors…
Premièrement, il faut savoir écouter. La communication est un aller-retour entre toi qui écoutes et l’autre qui parle. Ainsi, lorsque l’autre parle, il faut rester calme et l’écouter silencieusement en hochant la tête ou en faisant <<umhum, umhum>> pour l’envoyer le signal comme quoi, tu l’écoutes.
Et lorsque qu’il y a des doutes ou des incompréhensions, il faut essayer soit de reformuler ce que tu as entendu ou bien de prendre un exemple qui va dans le même sens, permettant ainsi à l’autre de confirmer si tu as compris, oui ou non de quoi il parlait et par ricochet, renforcer la confiance et le dialogue entre vous.
Il ne faut cependant pas faire des suppositions.
Les suppositions brouillent la communication et peuvent envoyer des signaux négatifs. Il faut à tout prix éviter les suppositions et clarifier ce qu’on a entendu à travers ce qu’on dit. Tout doit être limpide.
L’une des conséquences de l’échec des projets n’est pas trop souvent le manque de compétence, mais le fruit d’une mauvaise communication. On suppose ce que le client a dit, on suppose ce que le collègue veut faire remarquer, on évite de mettre sur la table certains problèmes et au final, on va tout droit au mur.
Imagine-toi, tu es un freelance qui travaille à Douala. Tu as sous la main une mission de 3 jours que tu dois livrer pour un client situé à Yaoundé, mais malheureusement, un orage s’abat sur ta ville et il y a coupure de courant. Tu n’as pas de groupe électrogène et cela va surement retarder ta livraison.
Dans ce cas, au lieu de rester silencieux, il faut être pro-actif et faire un mail au client pour expliquer le fait que pour des raisons indépendantes de ta volonté, tu vas accuser un retard, tout en lui donnant ton état d’avancement actuel sur le projet.
Détrompe-toi, je ne prends pas cet exemple pour t’encourager à prendre de faux prétextes, mais juste pour te montrer qu’il est important d’avoir une communication claire avec ton client lorsqu’un évènement qui va retarder ton travail survient.
Comme je le disais tout juste avant de prendre cet exemple plus haut, il faut éviter les suppositions. D’autres parts, le fait d’éviter les suppositions ne signifie pas qu’il faut aller dans les détails. Il est important d’adapter sa communication ou son message à son interlocuteur.
Si un collègue du service marketing veut savoir comment avance la fonctionnalité pour publier un post sur facebook à partir du site web et que tu rencontres des difficultés avec l’accès à l’API, évite les messages du genre : la méthode POST que j’envoie au endpoint retourne une erreur bizarre, peut-être que les données JSON ne sont pas compatibles. Non ! C’est à éviter.
Dis-lui juste que la communication entre le site web et facebook ne passe pas parce que les données que tu envoies ne sont plus supportés par facebook.
Ainsi, le message sera plus digeste et compréhensible. Par contre, lorsque tu es en face d’un collègue développeur, là, tu pourras entrer dans tous les détails, mais en utilisant une approche allant du général au particulier.
Moi, c'est ce que je fais. Si je dois expliquer un problème à un développeur, je commence toujours par dire OK, en gros voici ce que je veux faire. J’ai déjà fait tel, tel et tel process. Actuellement, je fais tel autre, mais je rencontre ce problème-ci, bla bla bla bla bla.
Dans ce type de communication, il faut être concis pour ne pas brouiller le message. Plus on est concis, plus on maîtrise sa prise de parole et mieux l’interlocuteur comprend le message qu’on véhicule. Lorsque tu es concis, cela se reflète aussi dans tes gestes : on voit très bien que tu n’es pas hésitant et cela renforce ta confiance en soi.
De l’oral à l’écrit
Privilégier l’écriture est une condition incontournable pour une bonne communication et pour la réussite des projets sur lesquels tu travailles. On le dit toujours, les paroles s’envolent et les écrits restent.
L’écrit est d’autant plus important qu’il renforce ton professionnalisme et la manière dont tu es perçu par les autres. Dans le cas d’une discussion avec un client ou un chef de projet, il faut prendre le soin de tout noter, de préférence dans un ticket ou dans l’espace de commentaire prévu à cet effet. Les outils comme Trello sont là pour ça, sans oublier les issues sur GitHub ou GitLab.
Lorsqu’un client demande un bouton qui affiche des données précises, rédige cette demande pour éviter tout malentendu plus tard. Il est aussi important d’avoir l’habitude de lui demander de faire un mail ou d’aller renseigner son nouveau besoin et ses remarques dans le ticket en question.
Sur Peef, je l’ai fait dernièrement pour une mission. Après avoir clarifié les besoins du client, j’ai demandé au développeur de créer un dépôt sur GitHub et j’y ai renseigné toutes les tâches. Lorsque le développeur terminait une tâche, j’aillais la tester et par la suite, je renseignais mes remarques et donnais mon appréciation en commentaire.
Lorsqu’il fallait demander quelque chose au client, le développeur en question, qui s’appelle Emmanuel et qui d’ailleurs est une personne professionnelle, était très réactif et n’hésitait pas à faire un mail au client.
Tout ceci pour souligner qu’à travers la plateforme Peef que tu peux découvrir sur peef.dev, nous poussons les parties prenantes autour d’un projet à avoir une bonne communication.
Et toi, tu dois faire de même, que ce soit avec tes collègues ou tes clients, tout élément lié au projet doit être mis sur écrit.
J’ai souvent l’habitude, lorsque je crée un Merge Request ou un Pull Request, d’expliquer pourquoi je fais ces changements ou de mettre juste le lien du ticket sur lequel j’ai travaillé, afin que le collègue qui fera le code review soit au même niveau d’information que moi.
En parlant de code review, j’entends des voix qui disent que certains collègues sont condescendants avec elles. C’est vrai, cela arrive que dans des équipes d’ingénieurs, certaines personnes heurtent les autres à travers leurs commentaires lors des codes reviews. Ils imposent leurs visions, ils te font passer pour un ridicule qui ne sait pas ce qu’il fait.
Mais il est vrai que des fois, notre syndrome de l’imposteur prend le dessus, il nous fait comprendre le message autrement et on a l’impression d’avoir été insulté.
Pour éviter ces incompréhensions, j’utilise des commentaires conventionnels. Si je ne comprends pas une ligne de code, je commence mon commentaire par QUESTION
Lorsque je veux donner mon avis pour apporter une amélioration, je commence mon commentaire par SUGGESTION
Ensuite, j’écris de manière courtoise ce que j’ai en tête de sorte que celui qui me lit ne soit pas heurté. C’est une bonne approche à prendre en compte lors des codes reviews et cela améliore la qualité de notre relation avec nos collègues.
Vous savez qu’en tant que développeur, il existe une façon d’écrire les commits selon le référentiel “conventional commit”, de même, il en existe pour les commentaires et cela s’appelle “conventional comments”. Fais juste une recherche Google sur “conventionnal comments”, tu en sauras plus et je suis sûr que cela va améliorer ta manière de faire les code reviews.
Enfin, il faut améliorer ton écriture et la rendre plus digeste en évitant les fautes. Je me souviens à cet effet qu’un jour, j’ai demandé à un ami au collège comment il faisait pour avoir toujours 20/20 en dictée et lui de me répondre : Nasser, comme tu vois là c’est parce que je lis beaucoup.
Voilà…
C’était Nasser, le promoteur du site peef.dev, une plateforme qui permet aux développeurs de trouver des missions en freelance ou à temps partiel.
Nous sommes arrivés au terme de cet autre épisode de veille tech et je te dis à très bientôt dans un prochain épisode.
