Comment communiquer en tant que programmeur

La communication est, à mon humble avis, la partie la plus difficile de tout travail. Parfois, le travail d’ingénierie proprement dit est difficile, mais en général, le plus difficile est d’obtenir les bonnes exigences, de communiquer l’état d’avancement du projet à l’équipe de direction, de former un consensus avec vos collègues sur les idées complexes de votre application, ou quelque chose de tout à fait différent !

En quoi consiste cet article ?

• Il s’agit d’un recueil des meilleures pratiques pour communiquer clairement et efficacement avec vos pairs, vos managers et vos dirigeants.
• Il est basé sur mon expérience personnelle et sur de nombreuses observations faites dans des emplois allant de la restauration à l’épicerie, en passant par la vente au détail de produits électroniques, l’assistance technique, l’assurance qualité des logiciels et le développement de logiciels.

Qu’est-ce que cet article ne contient pas ?

• Il n’est pas fondé sur des données scientifiques. Toutes les opinions présentées ici sont les miennes et reposent entièrement sur mon expérience personnelle.

Organisez vos pensées en listes

J’ai déjà présenté mon astuce de communication préférée dans un article.

Pourquoi ?

• Tout le monde aime les mises à jour scannables.
• Les puces garantissent que les différents points sont digestes individuellement, tout en étant facilement reconnaissables comme étant cohérents avec le point plus large.
• Le fait de condenser votre message sous forme de puces vous oblige à réfléchir aux éléments importants de votre message avant de le délivrer, et à éviter les pertes de mots.
• Tous les points ci-dessus augmentent les chances que votre public vous comprenne. N’oubliez pas que c’est la raison pour laquelle vous communiquez en premier lieu.

Modifier avant d’envoyer

Prenez une minute supplémentaire pour modifier un message court, ou deux minutes pour modifier un message long, avant d’appuyer sur « envoyer ».

• Avant d’envoyer un message (courriel ou message instantané), relisez-le.
• Essayez d’extraire votre point central en une puce, et placez cette puce en haut du message.
• Utilisez plusieurs puces si cela est absolument nécessaire
• N’ayez pas peur de supprimer les détails superflus – vos lecteurs vous en remercieront !

Pourquoi ?

La rédaction de vos messages vous permettra de transmettre clairement votre message. Le fait d’être compris par votre public augmente considérablement les chances d’obtenir le résultat souhaité (par exemple, plus de temps sur un projet, de l’aide pour une fonctionnalité, une clarification des exigences, etc.)

Les chances que vous exprimiez parfaitement vos pensées du premier coup sont extrêmement faibles, à moins que vous ne soyez un communicateur écrit remarquablement doué. Faites preuve d’humilité et reconnaissez que votre première tentative d’expliquer quelque chose n’est probablement pas la meilleure version.

Soyez charitable

1. Ne supposez pas que votre public a du temps à consacrer à votre communication.
2. Ne supposez pas que votre public accordera à votre communication toute l’importance que vous pensez qu’elle mérite.
3. Ne supposez pas que les points 1 et 2 signifient que votre public est prétentieux. Ils sont simplement trop occupés, comme nous tous.
4. Respectez les mêmes normes que les autres. Tout le monde a déjà parcouru un courriel ou un message Slack d’un collègue. Cela ne fait pas de vous une mauvaise personne, tout comme cela ne fait pas de vos collègues de mauvaises personnes lorsqu’ils parcourent vos communications. Nous sommes tous pareils.
5. Partez du principe que vos collègues sont suffisamment intelligents et engagés pour poser des questions complémentaires s’ils veulent ou ont besoin de plus d’informations.

Laissez de côté les détails

(Ceci devrait être pris en charge par la meilleure pratique n°2, « Modifier avant d’envoyer »)

• Laissez de côté les détails. Si quelqu’un veut ou doit savoir, faites-lui confiance pour demander (voir « Soyez charitable, n° 5 »).
• La direction ne se soucie pas des détails de mise en œuvre
• Le produit ne se soucie pas des détails de mise en œuvre
• La conception ne se soucie pas des détails d’implémentation
• L’ingénierie ne se soucie pas des détails de l’implémentation*, sauf s’il s’agit d’une revue de presse et que vous partagez une stratégie spécifique pour une implémentation spécifique.

Vous vous dites peut-être « Mais ils ont besoin de connaître toute la situation ». Pour emprunter borrow logic from Marcus Aurelius : il est impossible pour chaque personne de tout lire. S’il est impossible que tout le monde lise tout, alors vous devez accepter que certaines personnes ne lisent pas tout ce que vous écrivez. Croire le contraire, c’est se rendre fou. En bref, cessez d’aspirer à l’impossible et apprenez à optimiser ce qui est possible.

*Il est évident qu’il existe de nombreuses occasions où l’ingénierie se soucie de la mise en œuvre. Mais en général, vos collègues n’ont pas envie de passer en revue un paragraphe sur la configuration d’exécution de votre lambda juste pour comprendre le bogue que vous avez découvert.

Organisez votre message en pyramide

« Les informations les plus concises/générales/importantes en haut. Les informations les plus verbeuses/spécifiques/soutiennent en bas ».

• Si quelqu’un ne peut pas discerner l’impact de votre message dès la première phrase, c’est que vous vous y êtes mal pris.
• Donnez à votre public une raison de continuer à lire, ou donnez-lui la permission d’arrêter de lire.
  • C’est une question de confiance. Faites confiance à votre public, qui sait comment filtrer les informations par lui-même. Structurez votre message de manière à ce que les personnes qui ont besoin de le connaître puissent immédiatement l’identifier comme important pour leur rôle. Inversement, si votre message ne s’applique pas à quelqu’un, il doit pouvoir le dire dès la première phrase et se sentir en sécurité pour passer à autre chose sans lire le reste.

Exemples

Exemple : Alerte du service de production

Mauvais

Aujourd’hui, nous avons déployé une mise à jour du service d’authentification. Elle comprend plusieurs mises à jour qui amélioreront considérablement l’expérience des utilisateurs. L’une des mises à jour impliquait une modification de la durée de la session. Ce changement a été discuté avec l’équipe de sécurité qui a décidé que l’augmentation de la durée de la session était un risque acceptable pour le gain d’une meilleure expérience utilisateur et des interruptions de session moins fréquentes. Malheureusement, notre configuration de production était différente de celle de notre environnement de test et le changement n’a pas fonctionné. Actuellement, les utilisateurs ne peuvent pas se connecter et nous travaillons sur le retour en arrière de la mise à jour. Nous tiendrons l’équipe informée de nos progrès.

Amélioration

[Impact client] : Les utilisateurs ne peuvent actuellement pas se connecter. Nous travaillons activement à la résolution de ce problème en annulant une mise à jour qui a échoué.

Détails : Nous avons déployé aujourd’hui une mise à jour du service d’authentification. Celle-ci comprend plusieurs mises à jour qui amélioreront considérablement l’expérience des utilisateurs. L’une des mises à jour impliquait une modification de la durée de la session. Ce changement a été discuté avec l’équipe de sécurité et ils ont décidé que l’augmentation de la durée de la session était un risque acceptable pour le gain d’une meilleure expérience utilisateur et des interruptions de session moins fréquentes. Malheureusement, notre configuration de production était différente de celle de notre environnement de test et le changement n’a pas fonctionné. Nous tiendrons l’équipe informée de nos progrès.

Wow ! Nous avons à peine changé quelque chose ! Pourtant, notre message révisé (*ahem*…édité) atteint plusieurs objectifs importants

1. Informe immédiatement les autres équipes de l’existence d’un bogue connu ayant un impact important sur les clients. Par exemple, il s’agit d’une information cruciale à partager avec l’équipe d’assistance, qui sera probablement confrontée à des clients demandant pourquoi ils ne peuvent pas se connecter<./li>
2. Séparer l’essentiel de la mise à jour des détails annexes. Un dirigeant qui se rend à une réunion du conseil d’administration n’a pas besoin de connaître les opérations quotidiennes des ingénieurs. Mais il peut vouloir savoir que l’ensemble de sa base d’utilisateurs est actuellement touché par l’échec d’un déploiement. Plus important encore, il voudra savoir que le problème a été identifié et que l’équipe travaille activement à sa résolution.
3. Inclut les détails pour ceux qui sont intéressés. Mais les détails sont séparés de la mise à jour principale pour indiquer que les informations suivantes ne sont pas essentielles pour comprendre l’importance de la mise à jour.

Exemple : Mise à jour de l’état du projet

Cadre :

Avons-nous presque terminé la fonctionnalité X ?

Mauvais

Nous avons divisé la fonctionnalité X en 5 histoires d’utilisateur distinctes. Après avoir défini le périmètre en équipe, chaque histoire comporte 3 à 6 tâches. Certaines de ces tâches semblent faciles, mais elles sont en réalité très difficiles. Même si les exigences du produit sont assez claires, la fonctionnalité nécessite une réécriture substantielle de certaines parties de notre base de code qui ont accumulé beaucoup de dettes techniques. Cela rend le processus plus lent que nous ne le souhaiterions, mais nous en avons discuté en équipe et nous ne pensons pas qu’il y ait beaucoup d’alternatives. Même si nous avions estimé que nous aurions terminé la semaine dernière, nous pensons qu’il faudra encore quelques semaines à notre rythme actuel. Bien sûr, il y a des inconnus à affronter, donc cela pourrait être plus long. Si ce délai ne semble pas acceptable, nous pourrions envisager de mettre en pause la fonctionnalité Y, ou peut-être de pousser la mise à jour technique Z. Je ne le recommanderais pas cependant, l’équipe ne sera pas très heureuse de cette décision.

Amélioration

Nous avons terminé à environ 40%. Estimation actuelle : il devrait être disponible pour les utilisateurs dans 3 semaines à compter d’aujourd’hui.

Options pour accélérer la livraison

1. Pause de la fonctionnalité Y
   • cela aura un impact sur l’expérience utilisateur, il faut donc faire un compromis
2. Suspendre la mise à jour technique Z
   • L’équipe d’ingénieurs est convaincue de la nécessité de cette mise à jour, mais nous pourrions la reporter après le lancement pour gagner du temps.

Pourquoi ce retard ? Même si les exigences du produit sont assez claires, la fonctionnalité nécessite une réécriture substantielle de certaines parties de notre base de code qui ont accumulé beaucoup de dettes techniques. Cela rend le processus plus lent que nous ne le souhaiterions, mais nous en avons discuté en équipe et nous ne pensons pas qu’il y ait beaucoup d’alternatives.

Nous avons réalisé plusieurs choses ici

• Nous avons répondu à la question dès le départ. Il est possible que l’exécutant ne se soucie pas d’accélérer la livraison, il a juste besoin d’une réponse pour les actionnaires. Dans ce cas, vous avez donné à votre public la permission d’arrêter de lire, et vous lui avez fait gagner un temps précieux.
• Les options permettant d’accélérer la livraison sont beaucoup plus clairement étiquetées, et les effets secondaires associés sont clairement indiqués. Toute personne lisant ce document sera en mesure de prendre une décision plus éclairée sur les compromis à faire.
• L’explication du retard peut être importante ou non. Regardez en arrière et réalisez que le cadre n’a pas demandé une justification du retard, il a juste demandé si nous avions presque terminé. Vous avez peut-être déduit une certaine impatience et voulu y répondre dès le départ, mais il est toujours préférable de faire confiance à vos collègues (« Soyez charitable ») pour demander les informations qu’ils souhaitent. Anticiper leurs besoins est une bonne chose, mais dans la mesure où cela ne les empêche pas d’obtenir les informations qu’ils demandent.

Développer l’empathie : « écrire des messages aux autres dans le style que vous aimeriez que les autres vous écrivent ».

Cette section part du principe que vous n’êtes toujours pas convaincu de la nécessité d’être concis lorsque vous communiquez au travail. Si vous êtes déjà convaincu, vous pouvez sauter cette partie.

Exerçons nos compétences en matière d’empathie et imaginons une situation qui devrait être familière à chacun d’entre nous : travailler sur un ticket qui a été rédigé par quelqu’un d’autre.

Notre ticket hypothétique nous demande d’exécuter un rapport pour l’équipe de développement commercial. Celle-ci a besoin de savoir combien d’utilisateurs correspondent à certains critères afin d’optimiser les canaux de marketing. Considérons deux scénarios possibles :

Scénario 1 : Le ticket est concis et ne comprend que les détails pertinents, rien de plus

Dans ce scénario, le ticket comprend tous les paramètres pertinents à utiliser pour filtrer les données (par exemple, la période), le format de sortie souhaité et la forme attendue des données. Vous êtes en mesure d’exécuter votre tâche (générer le rapport) rapidement et efficacement, et les deux parties sont satisfaites du résultat.

Scénario 2 : Le ticket comprend des nuances biz dev qui n’ont rien à voir avec la tâche à accomplir.

Dans ce scénario, le ticket comprend un rapport complet sur les pertes et profits du trimestre précédent, ainsi qu’une comptabilité détaillée de tous les partenaires marketing actuels et de leur performance relative d’un mois sur l’autre. Le rédacteur du ticket a inclus des graphiques montrant l’évolution du CAC par rapport à l’année précédente et une description détaillée des différentes options que l’équipe de biz dev a envisagées avant de demander ce rapport. Enfin, le ticket comprend des informations pertinentes telles que les entrées et les sorties attendues du rapport.

Dans ce scénario, vous passez une journée entière à comprendre la tâche à accomplir. Lorsque vous remettez le rapport, vous ressentez un profond sentiment de malaise en vous demandant si vous avez vraiment fait ce qu’on vous a demandé.

Lequel de ces scénarios est le meilleur ? Clairement le premier. Gardez cela à l’esprit lorsque vous communiquez avec vos collègues. Si tous les détails annexes sont probablement importants pour vous, essayez d’évaluer honnêtement leur valeur pour votre public avant de les inclure dans un message.

Résumé

• Tout le monde consomme mieux l’information sous forme de résumé (par exemple, les puces).
• N’inclure que le strict minimum d’informations dans vos messages vous rendra plus efficace car cela augmentera automatiquement la compréhension de votre message par votre public.
• Soyez aimable, courtois et charitable. Cela signifie respecter le temps de vos collègues et croire qu’ils sont capables de demander plus d’informations si nécessaire.
• Modifiez vos messages avant de les envoyer ! Personne n’écrit parfaitement sur un premier jet. En extrayant les informations clés lors d’une révision rapide, vous améliorerez considérablement la compréhension du public, ce qui augmentera votre satisfaction au travail.