N’essayez pas d’éviter, par l’ingénierie, le fait d’écouter ce que disent les gens

• Dans le développement logiciel, la difficulté centrale n’est pas tant le manque de conversation que le manque d’écoute ; chercher à résoudre cela en le reformulant avec des termes comme framework ou system revient à contourner l’écoute réellement nécessaire
• Exécuter exactement la demande de quelqu’un n’est pas la même chose que comprendre son besoin réel, et l’effet d’expertise ainsi que la dichotomie technical / non-technical conduisent à passer à côté des connaissances et du contexte de l’autre
• Supposer que tout le monde dispose de la même énergie, des mêmes compétences et des mêmes moyens financiers, ou généraliser à tout un groupe les caractéristiques d’une seule personne, empêche de saisir correctement les contraintes et critères de jugement propres à chacun
• Les personnes et les organisations évoluent selon le temps, le rôle, le stress et la dynamique de groupe, et ce qui est dit ne correspond pas toujours à ce qui est réellement pensé ; des exigences figées se désalignent donc facilement avec la fabrication logicielle
• L’échec de l’écoute fait manquer les insights les plus précieux, ce qui entraîne la perte d’opportunités de revenus et d’avantages concurrentiels, ainsi qu’une hausse de la tech debt due à l’accumulation des malentendus

---

Argument central

• Dans le développement logiciel, le problème fondamental n’est pas tant l’absence de dialogue entre les personnes que le manque d’écoute, et vouloir le résoudre en le reformulant avec des termes comme framework ou system est une manière d’éviter le vrai travail à faire
• Les designers et responsables produit tentent de traduire les échanges avec les gens dans des formulations plus faciles à accepter pour l’engineering, mais plus qu’un meilleur système, ce qu’il faut, c’est écouter réellement ce que disent les personnes
• En partant de l’idée qu’il est plus difficile d’écouter ce que disent les gens que de simplement parler avec eux, l’article récapitule les pièges typiques qui empêchent cette écoute

Pièges typiques qui empêchent d’écouter

• Faire ce qui est demandé n’est pas la même chose qu’écouter

  • Exécuter exactement ce qu’une personne dit vouloir n’est pas équivalent au fait d’écouter son besoin réel
  • Parmi les approches existantes sur ce sujet, mention de Jobs To Be Done, Outcome Driven Innovation et, côté UX, de l’empathy mapping

• L’effet d’expertise fait sous-estimer son propre point de vue

  • Lorsqu’on a longtemps étudié un domaine donné, il devient facile de partir du principe que « cela, tout le monde le sait »
  • Même si l’autre est expert de son domaine, il ne possède pas forcément les mêmes connaissances ; en revanche, il peut avoir d’autres savoirs
  • Pour bien écouter, il faut mieux comprendre ce que l’autre sait

• Considérer technical comme une catégorie unique

  • C’est un piège particulièrement fréquent chez les développeurs logiciels : technical n’est pas une propriété unique, mais un large spectre de domaines de connaissance hétérogènes
  • Voir les gens à travers la dichotomie « technical / non-technical » fait perdre des insights et augmente le risque de mal écouter

• Supposer que tout le monde dispose des mêmes ressources

  • Penser que tout le monde a la même énergie, les mêmes compétences et la même marge financière conduit à de mauvaises évaluations
  • Même des personnes ayant la même santé peuvent gérer leur situation différemment ou ne pas être réellement capables des mêmes actions
  • Il existe des différences entre les personnes à l’aise en mathématiques, celles fortes dans d’autres compétences, ou celles qui agissent de façon plus prudente parce qu’elles ont moins d’argent ou moins de marge de manœuvre

• Généraliser à un groupe entier les caractéristiques d’une seule personne

  • Avoir rencontré une personne avec une certaine caractéristique ne signifie pas que toutes les autres sont identiques
  • Exemple cité : l’attitude consistant à conclure d’emblée que les personnes âgées ne comprennent pas l’informatique
  • Réduire l’ensemble des femmes à une image issue de relations familiales personnelles relève de la même erreur

• Supposer que les personnes et les organisations sont fixes

  • À l’échelle macro, la personnalité évolue avec le temps
  • À l’échelle micro, la persona au travail diffère de la personne à la maison, et les jugements changent aussi selon le stress ou certaines conditions

• Supposer que ce qui est dit correspond à ce qui est pensé

  • Certaines personnes veulent dire exactement ce qu’elles disent, d’autres non
  • Beaucoup pensent parler avec sincérité alors que, dans les faits, ce n’est pas toujours le cas

• Juger les gens

  • Détester ou balayer quelqu’un qui a mal compris quelque chose de mal documenté réduit fortement la possibilité de réellement l’écouter
  • Partir du principe que l’autre travaille mal ou mène mal sa vie est aussi un facteur qui entrave l’écoute

• Traiter 80 personnes comme un seul groupe plutôt que comme 80 individus

  • Le B2B est, à certains égards, encore plus humain que le B2C : les relations, les dynamiques et des éléments comme le soft power en dehors de l’organigramme y jouent un rôle
  • Avec la dynamique de groupe, des variables encore plus complexes apparaissent qu’au niveau individuel

Le décalage entre exigences figées et logiciel

• Parce que les personnes et les organisations changent, la fixed project management n’est pas adaptée à la fabrication logicielle
• Même si les exigences sont fixées au départ, les personnes changent entre-temps, et lorsque le résultat arrive, il ne correspond au mieux qu’à la demande formulée au lancement
• Au moment du déploiement, ce n’est peut-être déjà plus ce qui est souhaité, et comme chacun ajoute ses propres attentes pendant l’attente, la réalité ne correspond finalement à aucune de ces attentes

Résultats et effets

• Quand on n’écoute pas correctement ce que disent les gens, on passe à côté des insights les plus précieux, ce qui mène à la perte d’opportunités de revenus et d’avantages concurrentiels
• Plus les malentendus s’accumulent, plus de nouveaux éléments s’ajoutent ensuite au code sur lequel il faudra continuer à travailler ; l’écoute est aussi liée à la réduction de certaines causes de tech debt
• Plus on repère les moments où l’on n’écoute pas, plus on a de chances de mieux écouter