Penser en 2D

Hervé Rincent

Hervé Rincent

1 févr. 2024

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 :

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é.

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.

❌  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.

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.


Continuer la lecture

Les LLM, c'est le passé

13 juin 2024

4 min read

Les LLM, c'est le passé

Lire l'article
La couleur des mots

31 mars 2023

4 min read

La couleur des mots

Lire l'article
Inscription à la newsletter

Recevez chaque semaine un article pour réfléchir à votre prochain projet tech/data

gratuit, sans spam, désinscription en 1 clic

Merci ! Regardez dans botre boite mail. Un lien de confirmation n'attend plus que votre clic.
Arghh il semble compliqué de vous ajouter à la liste de diffusion. Et si vous m'envoyiez un mail directement à contact@camilab.co ?