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
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
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 »
Et vous, si vous regardez votre projet en vous intéressant uniquement aux décisions (à tous les niveaux), que voyez-vous ?
2 commentaires sur “Information et décision dans les projets logiciels”