Ne confondons plus le MVP avec le MDP : minimum viable product vs maximum dirty poc

Une seule lettre vous manque et tout est à jeter. Les leçons de vingt années de pratique de la gestion de grands projets de type 100 000 jours-homme.

Comme chacun aura pu le constater, la probabilité d’échec d’un projet informatique est directement corrélée à sa taille.
Nombreux sont les projets fleuve qui ont fini par être abandonnés après trois, quatre ou sept années de travail acharné, de nuits écourtées et autant de dizaines de burnout, voire de centaines de millions d euros. Toute référence aux dénommés Louvois, Socrate ou autres grands anciens ne serait que le fruit du hasard… "Too big to succeed".

Ces douloureux échecs sont toujours la conséquence d’une construction bancale des quatre mêmes composantes de la direction de projet : la complexité, la collaboration, la qualité et les délais :

Cette “Bancalitude” est solidement implantée sur 10 biais cognitifs très communs, pleins d’un roboratif bon sens bien ancré.  Hélas, "Le discours du bon sens n’est pas forcément un discours qui a du sens" François Dupuy (Sociologue des organisations). Pour supprimer chacun de ces travers, le directeur de projet doit changer de logiciel : le sien.

La première composante est la manière dont la direction de l’équipe projet appréhende le périmètre, la connaissance et la complexité de l’objet à développer : le produit.

Les trois biais cognitifs qui minent cette gestion de la complexité sont les suivants :

1. "Une pensée claire est une pensée simple"

Donc il serait essentiel de simplifier au maximum la description du réel afin de la rendre intelligible. Confondante confusion entre la cause et l’effet.

Car le but n’est pas du tout de rendre la représentation du réel accessible au premier venu mais de la rendre suffisamment exacte et précise pour avoir la capacité de le comprendre et de le modéliser. La lisibilité vient, certes, mais en second ordre seulement.

Les gens qui font du Lean et qui utilisent la méthode Obeya pour gérer leurs projets, utilisent le "panneau de représentation du produit". Une représentation détaillée du produit cible, de son périmètre in et out, des points de vue fonctionnels, techniques, de sécurité et d’infrastructure.

De plus, pour chacune de ces vues, il convient d’identifier ce qui restera inchangé, ce qu’il conviendra de modifier, ce qu’il faudra créer.

Ainsi que ce que l’on est, à date, incapable de qualifier : la zone d’ombre dont on peut à minima cartographier le contour. Il s’avère que cette zone d’ombre est fortement liée au niveau d’incertitudes sur le périmètre.

2."Trop d’informations tue l’information"

Donc il conviendrait de ne surtout pas entrer dans les détails technico fonctionnels, en laissant ces contingences absconses entre les doigts crasseux de la plèbe des développeurs, analystes fonctionnels, Product Owners et autres testeurs ou Dev.Sec.Ops. Après tout c’est leur boulot.

"A quoi tout ce niveau de détail va-t-il servir Edmond ? On pourrait le voir plus tard…"

Or, le défaut des informations nécessaires – Materials (terme lean) – mène, au mieux, à l’absence de livrable, au pire, à un livrable construit sur la base contradictoire de l’imagination solitaire des uns et des autres.

Les chances pour un produit ainsi conçu “en gros vu de loin” de tomber en marche restent bien faibles ; celles de répondre au besoin sont quasi nulles…

3."Si cela fonctionne déjà, c’est que cela ne doit pas être si sorcier que cela"

On infère un peu vite qu’une éventuelle rusticité des langages, des infrastructures ou des fonctionnalités du SI antérieur serait la garante d’un code bien documenté, de correctifs rigoureux, de montées de version régulières, de flux monitorés et d’assets tous pilotés et répertoriés, de modèles de bases de donnes richement décrits, mappables et transférables à l’identique…

“Quelle est la qualité de vos SGBD ?" - “Nickel, rien à dire”

“Ah oui ? et vous en avez combien ? “ -“Faut voir…”

Au commencement donc, un projet est surtout une immense "terrae incognitae" à explorer, et dont la connaissance se doit d’être formalisée, répertoriée et partagée au fur et à mesure. La nature de ce que l’on ignore encore représente l’essentiel de ce travail exploratoire itératif. 

Et la manière lean de le décrire en Obeya projet, est portée par le panneau principal : le Produit. Cette exploration préalable et consubstantielle à la conception réclame du temps, donc de l’argent, Au final, elle réduit drastiquement le gradient d’incertitude sur la trajectoire du projet, donc les coûteux retours arrière, refontes post MEP (mise en production) et abandons divers.

Un prochain article sera consacré à la deuxième composante essentielle du projet : la collaboration.