L’ingénierie bienveillante

Qu’est-ce que la bienveillance ?

Kind is about being invested in other people, figuring out how to help them, meeting them where they are.

La bienveillance consiste à s’investir dans les autres, à trouver comment les aider et à les rejoindre là où ils en sont.

— Tanya Reilly, Continuous

La bienveillance, comme le dit Tanya Reilly ci-dessus, consiste à s’investir dans les autres. Ce n’est pas simplement être aimable, mais se mettre à la place de l’autre pour comprendre ses émotions et son contexte. Ce n’est pas une solution universelle dans toutes les situations, mais elle peut aider à résoudre de nombreux problèmes.

Attention portée aux autres

• Concentrez-vous sur votre travail au-delà du simple fait d’être « professionnel ».
• Agissez avec ouverture et humanité pour instaurer la confiance.
• Traitez les personnes directement, mais avec attention et considération.
• Les petits mensonges ne sont pas forcément mauvais, mais ils ne permettent pas aux gens de grandir.
• Ne perdez pas votre bienveillance, félicitez les bons comportements et indiquez les points à améliorer.

Communication asynchrone (async)

• Face au changement, cherchez à mieux comprendre non seulement le « quoi ? » et le « comment ? », mais aussi le « pourquoi ? ».
• Ne présumez ni malveillance ni incompétence.
• Au lieu de faire des déclarations tranchées ou controversées, posez des questions ouvertes.
• Avant de faire une remarque, il est important qu’elle soit clairement étiquetée.
• Trop de remarques peuvent davantage perturber le travail.
• S’il y a beaucoup d’avis, passez à une communication séquentielle.

Sécurité psychologique

• Soyez le premier à demander du feedback à votre équipe ou à vos collègues.
• La structure du feedback est simple :
  • ce qui a bien fonctionné
  • ce qui n’a pas fonctionné
  • ce qu’il faut faire ensuite
• Accueillez avec ouverture le contexte, l’histoire et les préférences personnelles de chacun.
• Soyez attentif aux personnes qui ne contribuent pas beaucoup aux réunions ou aux documents, et cherchez des moyens de leur permettre de s’exprimer.
• Faites entendre votre voix pour que chacun puisse s’exprimer de la manière qui lui semble juste.
• Souvent, un échec individuel peut en réalité révéler une défaillance du processus, de l’environnement ou du workflow.
• Nous réussissons et échouons ensemble.
• Chaque « échec » ou incident doit être célébré comme une occasion de grandir et d’apprendre.
• Pour favoriser l’innovation, il faut encourager les gens à prendre des risques, à relever des défis et à sentir qu’ils peuvent le faire en toute sécurité.

Feedback / critique

• Dès le départ, soyez la personne qui reçoit d’abord l’évaluation, plutôt que celle qui évalue.
• N’en faites pas une affaire personnelle.
• Lorsque vous donnez du feedback ou des compliments, essayez d’être aussi précis et approfondi que possible.
• Si vous donnez un feedback critique à quelqu’un, essayez aussi de proposer une solution.
• Comprenez vos propres préférences en matière de feedback.
• Écoutez, comprenez, puis remerciez la personne qui vous a donné son feedback.
• Ne réagissez pas immédiatement : prenez le temps de mettre vos idées en ordre et de digérer le feedback.
• Demandez des explications ou des exemples.
• Gardez en mémoire les trois éléments du feedback :
  • l’émotion
  • la crédibilité
  • la logique
• Tenez compte des émotions de votre auditoire, pas seulement des vôtres.
• Faites preuve d’expertise et d’humilité.
• Montrez votre manière de travailler et comment vous arrivez à vos conclusions.

---

• Le problème du ton toxique dans l’industrie tech : corrigeons-le !

[arfwene]

C’est évident, mais difficile à mettre en pratique..

[aster]

Comment appliquer l’ingénierie bienveillante au développement à partir des éléments ci-dessus
J’ai essayé d’élaborer ce qu’on pourrait appeler le KDD (Kindness Driven Development) avec l’aide de l’IA.

Écriture du code

• Rédigez les commentaires et la documentation en mettant l’accent sur le « pourquoi ? ». Il est important d’expliquer pourquoi le code existe et dans quel contexte.
• Pour les logiques complexes, utilisez des noms de variables et de fonctions fondés sur le vocabulaire métier afin de faciliter la compréhension pour les autres développeurs.
• Lorsque vous introduisez une nouvelle technologie ou un nouveau pattern, tenez compte de la courbe d’apprentissage de l’équipe.
• Ne critiquez pas le code legacy. Il existait probablement des contraintes et un contexte à l’époque.
• Documentez le traitement des cas limites et des cas d’échec pour les futurs responsables de la maintenance.
  Conception de l’architecture
• Lors de la conception du système, prenez aussi en compte le point de vue des équipes d’exploitation et de QA.
• Faciliter le monitoring et le débogage fait également partie d’une conception bienveillante.
• Une conception évolutive est une forme d’attention portée aux futurs membres de l’équipe.
• Lorsque vous gérez la dette technique, visez non pas son élimination parfaite, mais un niveau « maîtrisable ».
• Il est important de créer une structure qui facilite l’ajout de nouvelles fonctionnalités.
  Revue de code
• Lorsque vous demandez une revue, expliquez suffisamment le contexte des changements.
• Utilisez des retours formulés sous forme de suggestion, comme « Et si on faisait comme ça ? ».
• Mentionnez aussi les points positifs. « Cette partie est vraiment très propre. »
• Lorsque vous proposez une alternative, expliquez aussi pourquoi.
• Pour les améliorations non urgentes, créez un ticket séparé afin de respecter le périmètre de la PR en cours.
  Code de test
• Fournissez des messages d’erreur clairs en cas d’échec des tests.
• Les cas de test servent aussi de documentation. Écrivez des tests qui expliquent clairement les règles métier.
• Créez une structure qui permette à d’autres développeurs d’ajouter facilement de nouveaux tests.
• Pour les données de test, utilisez des cas réels faciles à comprendre.
• Automatisez la configuration de l’environnement de test afin de réduire la barrière à l’entrée.
  Déploiement et exploitation
• Incluez des explications et des guides suffisants dans les scripts de déploiement.
• Préparez à l’avance des logs utiles au débogage en cas d’incident.
• Si un changement de configuration est nécessaire, documentez son impact.
• Lors du lancement d’une nouvelle fonctionnalité, préparez également un plan de rollback.
• Rédigez les guides d’exploitation du point de vue d’un développeur junior.
  Partage de connaissances
• Documentez et partagez vos expériences de troubleshooting.
• Lors de l’introduction d’une nouvelle technologie, créez et partagez des supports d’apprentissage.
• Les guides de développement doivent inclure « pourquoi nous avons décidé de faire ainsi ».
• Encouragez la progression de l’équipe grâce à des temps réguliers de partage technique.
• Créer un environnement où il est facile de poser des questions aide les développeurs juniors à progresser.

[bbulbum]

Ce contenu est suffisamment riche pour mériter un article à part entière haha

[laeyoung]

C’est vraiment très bien !

[aer0700]

C’est un très bon commentaire.