Plus je mène ma barque sur la grand-mare du développement informatique et plus je me rends compte que coder est (avant tout) une activité sociale. C’est un peu une surprise et certainement pas ce pour quoi j’ai signé au moment de me lancer… Moi, si je suis devenu développeur, c’est pour murmurer à l’oreille des ordinateurs, pas pour discuter le bout de gras sur des story points avec un Product Owner. Heureusement, au final, j’ai appris à aimer ça (discuter le bout de gras j’entends, pas les story points) mais ce n’est pas le cas de tout le monde. Pas plus tard que le mois dernier, la développeuse avec qui je travaille se tourne vers moi l’air dépité, retire le casque de ses oreilles : « J’aime pas les gens » me dit-elle. C’est le 4ème e-mail qu’elle échange avec le PO pour clarifier les specs de la story 412. Tout comme elle, à mes débuts, moi non plus “je n’aimais pas les gens”. Je ne faisais d’ailleurs aucun effort en ce sens : j’estimais que si tout le monde faisait bien son boulot, la partie “bla bla” du projet devait être réglée bien avant que j’intervienne.
Il faut bien dire que nous, développeurs, n’avons pas été préparés à faire face à ce genre de frictions. Au cours de nos cursus, nous n’avons fait face qu’à des sujets de TD fixes et définitifs (qui ne changeaient pas d’avis !) et avons fait équipe avec au mieux un ou deux étudiants qui, de par leurs parcours et leurs aspirations similaires aux nôtres, fonctionnaient plus ou moins sur le même modèle que le nôtre. « Hello World ! », la réalité est bien plus volatile et éclectique que ça.
Jusqu’alors je n’ai fait qu’implémenter des algorithmes et trouver des solutions à des problèmes dont les tenants et aboutissant sont entièrement connus et clairement spécifiés (ex. équilibrer un arbre binaire). Or, sorti du contexte artificiel de l’école, je vais devoir enquêter auprès de différents acteurs, interagir avec eux sans froisser leurs egos (ni le mien), interpréter des besoins flous et changeant et ce, en permanence ! J’ai beau faire de mon mieux pour mobiliser ce qu’on m’a appris, repasser mes cours de programmation orientée objet, relire mes notes sur les bases de données, me remémorer les TDs d’architecture réseau : rien. Je sais parler à la machine mais suis plus que démuni face à l’humain.
Pour faire face plus sereinement à l’aspect éminemment collaboratif du développement logiciel, il va falloir dépoussiérer nos compétences molles (aka soft skills, ça claque tout de même un peu plus in english!) laissées au placard.
Les soft skills traduisent en réalité des compétences comportementales et humaines : le savoir-être. On peut par exemple citer de façon non exhaustive : l’intelligence émotionnelle, la capacité à motiver/fédérer/mener une équipe, la confiance en soi, la capacité à se remettre en cause… la liste est longue.
Dans mon cas, une première prise de conscience a été déclenchée par une rencontre. Celle d’Andrew, un statisticien devenu coach. Quelqu’un qui, comme moi, a un fort esprit scientifique et qui « croit » au pouvoir de ces choses que je tenais alors pour accessoires : la communication et la psychologie. Je dis bien « croit » car, à cette époque, cela relève pour moi de l’ordre de la foi religieuse. Grâce à lui, tous mes collègues et moi, avons suivi une formation au MBTI. Il s’agit d’un modèle qui, à partir d’un questionnaire, classe en 16 profils notre façon d’aborder les problématiques, de prendre des décisions et d’agir.
Avant d’aller plus loin, je me dois d’ouvrir une parenthèse pour souligner que le MBTI n’est qu’un modèle. Comme tout modèle, il prétend donner une représentation actionnable de la réalité en lissant la complexité de celle-ci. On prétend ici faire rentrer la psychologie de milliard d’humains dans seulement 16 petites cases: c’est évidemment hyper-réducteur ! Mais rappelez-vous que l’on met souvent l’infinité des couleurs de l’arc-en-ciel dans 7 cases (violet, indigo, bleu, vert, jaune, orange, rouge) ce qui est quand même bien plus pratique pour les dessiner ! Passé outre l’imperfection et les limites du modèle, le MBTI permet tout de même de faire nombre d’observations intéressantes sur des tendances. Fin de la parenthèse.
De façon naturelle, il n’est pas rare que les personnes ayant des professions similaires se voient attribuer, au travers de l’évaluation, des profils MBTI similaires1.
Ainsi les développeurs se sont vu attribuer certains profils et les commerciaux d’autres profils presque diamétralement opposés ! Ce jour-là, je me suis rendu compte que ces deux populations avaient des façons de voir le monde intrinsèquement très différentes. Pour autant, aucun de ces deux profils “majoritaires” n’a foncièrement tort ou raison face à une situation donnée. Si j’avais été “câblé” de la même façon que les commerciaux (même profil MBTI), je tendrais probablement à réagir comme eux et vice-versa. Plus concrètement, le profil vers lequel se sont dirigés les développeurs fait état de la préférence à se retrouver seul pour étudier un problème et y élaborer des solutions alors que celui privilégié par les commerciaux met en évidence celle de débattre à plusieurs2. Le profil vers lequel se sont orientés mes collègues développeurs privilégie la stabilité, la planification et la structure alors que celui vers lequel se sont orientés les commerciaux met en avant une préférence pour la souplesse et la flexibilité afin de réagir aux changements3. Mes collègues développeurs et moi-même tendons à ne jurer que par les faits, l’analyse et la logique lors du processus de prise de décision alors que mes collègues commerciaux se basent principalement sur l’impact émotionnel et les sentiments des personnes impactées par cette décision4.
Se rendre compte de ces disparités m’a fait l’effet d’une grande claque et m’a rendu humble. Cette humilité, pour moi, est un prérequis à l’empathie qui, à son tour, permet la rencontre du meilleur des deux mondes.
À mon sens, il est très difficile (voire impossible) de “grandir” en tant que développeur sans s’exposer aux relations sociales. À la croisée des chemins entre l’homme et la machine, nous, développeurs, sommes les mieux placés pour mettre à jour les incongruences entre ce que pense vouloir notre client, la façon dont il exprime son besoin, la façon dont celui-ci est compris (notre interprétation, notre prisme) et ce qui est effectivement réalisable d’un point de vue technique. Ce n’est pas une position toujours facile à tenir. Boutés hors de notre zone de confort, nous sommes régulièrement amenés à nous mettre dans les baskets de notre client pour mettre à sa portée les contraintes techniques qui se dressent entre son besoin et la réalisation de ce dernier et lever certaines ambiguïtés “métiers”. Plus difficile encore, il nous faut bien souvent lui faire face et entrer en négociation (délais de livraison, réduction du périmètre fonctionnel, sauvegarde de la qualité).
Ainsi, l’image du “développeur-exécutant” qui ne fait que dépiler seul des tickets dans son coin est, à mon sens, loin de la réalité et surtout très néfaste. Elle empêche l’aspirant-développeur de se projeter dans ses futures responsabilités de médiateur homme-machine. Ce dernier ne s’attend pas à devoir endosser ce rôle, il ne se sent pas légitime pour le faire et n’a souvent pas le bagage nécessaire (il n’y est d'ailleurs ni invité ni formé !)...
Nous, développeurs, sommes donc voués à rencontrer de nombreux bugs relationnels au cours de notre carrière. C’est inévitable : la mauvaise qualité de la communication est la cause principale d’échec pour les projets IT. Vous est-il déjà arrivé de ruminer sur le fait que Machin écrive des specs qui ne sont pas claires ? Que Truc ne sache pas ce qu’il veut et qu’il change d’avis comme de chemise ? Que Bidule vous mette la pression inutilement ? Probablement. Ne vous êtes-vous jamais dit qu’il était de votre responsabilité de mettre de l’ordre dans tout ça, d'y jouer un rôle ou, tout du moins d'essayer ? Pas toujours. Affronter ces obstacles alors que nous n’y sommes pas préparés est loin d’être facile. Cela demande du temps, du courage et bien souvent de l’aide. Heureusement, il n’est jamais trop tard pour commencer à prendre nos responsabilités et muscler nos capacités à démêler ces situations délicates et inconfortables. Mon conseil : boostez vos soft skills dès aujourd’hui en commençant par apprendre à vous connaître vous-même et à connaître l’autre pour mieux l’accepter et mieux collaborer.
Les bases du MBTI (Site officiel) / Wikipédia [1] - Les 16 types (Voir section les 10 métiers les plus/moins choisis) [2] - Introversion (I) et Extraversion (E) [3] - Jugement (J) et Perception (P) [4] - Pensée (T) et Sentiment (F)
Chapitre 3, 4, 5, 7 et 8 du livre “La communication non violente : Les mots sont des fenêtres (ou bien ce sont des murs)” de Marshall Rosenberg (fiche de lecture)