Information et décision dans les projets logiciels

De la circulation de l'information

On dit parfois qu'un projet informatique va aussi vite que la circulation de l'information entre l'ensemble des personnes impliquées. C'est flagrant dans le développement par phases, où l'on va attendre que l'ensemble de l'information soit collectée sous forme d'un cahier des charges : l'information s'empile mais ne circule pas. Avant d'être contractualisé entre maîtrise d'ouvrage et maîtrise d'oeuvre : information "en transit", source de délais potentiels alors qu'aucune ligne de code n'a encore vu le jour. Et toute cette information va remonter la branche droite du V, à coup d'évolutions et de correctifs. Bref, cette circulation est l'occasion de nombreuses tractations qui la ralentisse l'information.

Cette circulation de l'information se fait heureusement de manière plus rapide dans une approche agile et pour plusieurs raisons : équipe transversale, communication par les murs, réduction de la taille des "lots"... Pour autant, le critère majeur dans cette accélération est le caractère itératif et incrémental, qui permet le "feedback" avec le retour d'information par les sponsors et utilisateurs à l'issue de la démo. Mais aussi avec l'amélioration continue, au travers des rétrospectives régulières, qui vise à adapter le process et donc la manière de prendre en compte les informations.

L'information, support des décisions

Mais pourquoi la circulation de l'information est-elle si importante ? En fait parce qu'elle est la matière première pour prendre des décisions. Et le développement d'un produit logiciel n'est qu'une longue succession de décisions. Ou plutôt comme un réseau de décisions déjà prises, d'autres encore à prendre, et d'autres non encore envisagées. Tout l'art de faire aboutir un projet informatique consiste donc à rendre ces décisions concrètes, à les "solidifier" non seulement jusqu'à l'obtention de code exécutable,  mais surtout jusqu'à que les utilisateurs soient face au logiciel et satisfaits de leur expérience.

On parle là de décisions liées au besoin, liées à la solution, mais aussi au process (au sens large du terme : dispositif, rôles, méthode, pratiques...). Je ne fais pas là de distinctions entre des décisions "nobles" relatives à la stratégie, à la gestion de projet de projet ou à l'architecture (Christophe nous a illustré la difficulté liée à la prise de telles décisions à moyen terme) et des décisions plus "communes" : "liste ou hashmap ?", "c'est pas un peu long ta méthode de 30 lignes ?". Produire du logiciel complexe, c'est solidifier des décisions en attente d'être prises et recueillir et partager l'information nécessaire à ces prises de décisions.

Information + Decisions = Software Product

De la même façon que Wirth a pu écrire "Algorithms + Data Structures = Programs", qui a donné naissance par la suite au paradigme objet, on peut passer cette affirmation à l'échelle et la transposer à l'échelle d'un projet informatique pour écrire :

Information + Decisions = Software Product.

C'est bien intéressant tout ça, mais quelles conséquences pour moi, professionnel du logiciel ? Ok, je suis Chef de Projet, j'ai bien compris que tout l'enjeu d'un projet tourne autour de ces notions d'information et de décision, mais alors comment contrôler toutes ces décisions ?

En fait la question n'est pas tant de contrôler toutes les décisions que de s'assurer que chaque décision concoure à un produit intègre. Voilà quelques exemples de ce que je peux chercher à faire :

• faire émerger rapidement des informations qui simplifient et accélèrent ce réseau de décisions : vision produit, architecture, étude de risques, règles de fonctionnement d'équipe... Bref, ce que l'on élabore de façon synthétique dans le cadrage à 360° d'un projet pour créer les conditions minimales de démarrage d'un projet.
• tout faire pour recueillir du feedback au plus tôt en livrant du logiciel fonctionnel et pouvoir ainsi prendre des décisions en s'appuyant  sur des éléments concrets et non des suppositions.
• faire apparaitre, prioriser et chercher à réduire les stocks d'information et de décisions en attente (comme on le fait avec un kanban)
• valider la pertinence des décisions prises (parfois en l'absence d'information) en comparant le résultat obtenu et le résultat attendu et réviser si besoin  les modèles mentaux sur lesquelles elles s'appuient...

Pas d'informatique sans "décisionnique"

Nous parlons de notre métier comme étant  l'informatique. Certes, notre matière première est l'information, mais celle-ci n'est utile que pour les décisions qu'elle permet de prendre. Peut-être devrions-nous en tant que professionnels du logiciel et puisque nous manipulons de la decision, nous pencher un peu plus sur la manière dont sont prises nos décisions. Bref, faire un peu plus de "décisionnique"...

Et vous, si vous regardez votre projet en vous intéressant uniquement aux décisions (à tous les niveaux), que voyez-vous ?