Depuis l'enfance, nous sommes conditionnés pour penser en 1 seule dimension.
Par exemple, lorsqu'on reçoit une note après une évaluation ou un examen.
Ce nombre angoissant permet d'appliquer un classement (je sélectionne les 10 meilleurs) ou un seuil (ceux qui ont une moyenne supérieure à 10 sont admis).
Que signifie passer à la 2D ?
Imaginez que chaque copie soit notée avec un couple de deux nombres. Par exemple, il y aurait la note comme avant, mais aussi la durée consacrée par l'étudiant à réviser.
Ainsi, la note n'est plus 15/20. Mais [15 ; 4 heures].
Qu'est-ce que ça change ?
Comparons les notes de deux étudiants américains installés dans le massif central avec cette nouvelle méthode :
- La note de Bill est [14/20 ; 1 heure]
- celle de Joe est [18/20 ; 8 heures]
Quelle est la meilleure note ?
Ou plutôt quelle est celle de l'étudiant le plus performant ? Est-ce qu'obtenir un honorable 14/20 en y allant au talent n'est pas un meilleur résultat que l'acharné 18/20 ?
Penser en 2D est un schéma mental qui aide à nuancer. Et ça fonctionne aussi pour les idées.
Associer 2 idées
Vous avez déjà entendu cette affirmation :
Un bon manageur doit être bienveillant.
Maintenant, essayons de revisiter ce cliché en 2D.
C'est vrai qu'un chef sans aucune bienveillance risque de devenir le tyran de son équipe, en micro-manageant chaque action et chaque décision. Inversement, l'excès de bienveillance peut mener au chaos.
Passer en 2D consiste à associer une seconde idée. Par exemple, l'association de la bienveillance avec l'exigence.
Et plutôt que de poser la question en 1D de savoir si Bill est un manageur bienveillant, adressons la question en 2D : dans quelle mesure Bill parvient-il à combiner bienveillance et exigence ?
Avec ce schéma mental, on aborde la question avec davantage de lucidité et de profondeur.
Appliquer ça au métier du développeur
Avouons-le : la plupart des développeurs préfèrent les conversations aux cahiers des charges.
Pour une raison simple : le cahier des charges empêche son auteur de changer d'avis.
Un document détaillé fige une idée du logiciel que l'on voudrait. En avançant dans le projet, cette idée est sévèrement bousculée par la réalité.
- Les utilisateurs découvrent des cas non prévus, ou des données manquantes
- Le contexte a changé, et ce qui était vrai à l'époque de la rédaction est remis en cause.
Pourtant, on persiste à les écrire. Parce qu'un cahier des charges donne l'illusion de la sécurité financière. Le développeur a (grossièrement) chiffré le coût de la prestation. C'est un prix ferme et définitif.
Sauf que tout change en cours de route. Des heures de réunions sont perdues à s'étriper sur ce qui est écrit et sur ce qui ne l'est pas. Pendant ce temps, le projet n'avance pas.
Donc, on arrête d'écrire des pavés obsolètes sitôt sortis de l'imprimante. On fixe un budget, et on se parle.
- Avec qui ? Avec l'expert métier.
- De quoi ? D'abord du problème à résoudre. Et jamais immédiatement de la solution envisagée.
❌ Il faut un formulaire de collecte du temps passé par chaque salarié sur chaque affaire.
✅ Il faut détecter les déséquilibres entre la charge et les ressources sur le portefeuille d'affaires.
- Comment ? En 2D.
En 2D ?
Oui. En 2D.
Par exemple l'utilisateur demande que ce soit visuel.
Vous répondez "visuel mais... ?" 😳
Laissez passer le court moment gênant durant lequel votre interlocuteur vous prend pour un abruti qui ne comprend rien.
Visuel mais détaillé ?
Visuel mais synthétique ?
Visuel mais commenté ?
Et la conversation prend de l'épaisseur. De la nuance.
Une conversation en 2D augmente notre vision de la fonctionnalité que l'on va coder.
