conflit d'idées
product owning #2
[cohesion]
Merci Laurent Prost et Mauko Quiroga Alvarado pour vos contributions à ma réflexion d’hier sur ce système à 3 acteurs qui modélise pour moi le developpement.
Si cette conversation tendue entre un Tech Lead et son Manager à propos du pilotage fonctionnel et technique du projet nous évoque un Mexican Stand-off plutôt qu’une saine relation de collaboration, c’est parce qu’il y a conflit.
🛡 ⚔️ 🏳️
Précisons : il y a un conflit qu’il s’agit de résoudre, et non pas un conflit au sens d’une agression ou même d’une animosité.
C’est un conflit d’idées (techniques, fonctionnelles, pratiques, méthodologiques, stratégiques, voire déontologiques) qui s’appuie lui-même sur un conflit de ressources. Ce n’est pas un conflit de personnes.
Dans un projet d’ingénierie complexe,
💬 les conflits d’idées sont indispensables, car ils sont la voie la plus rapide vers la meilleure solution. (Si vous me dites ici que vous n’êtes pas d’accord, vous allez prouver mon point).
💶 les conflits de ressources sont inévitables, comme nous savons depuis que nous sommes en âge de réaliser nos rêves en utilisant de l’argent (ou des branches d’arbres, ou des legos).
😥 les conflits de personnes ou de territoire n’ont pas leur place. C’est déjà assez compliqué comme ça.
Qui doit “gagner” dans ce conflit ? Il faut réaliser un logiciel, c’est à dire résoudre un problème mal compris à l’aide d’informations incomplètes, dans un contexte incertain.
Chacun joue son rôle :
Le pilote fonctionnel précise la nature du problème, la portée de la solution, et l’ampleur de l’investissement.
La technique cherche la meilleure conception, ce qui inclut également le meilleur état de l’art pour faire vivre cette conception. (Aucun·e ingénieur·e n’a passé 5 ans sur des bancs d’école en vue d’apprendre comment faire du logiciel jetable ou du legacy).
Le management répond des connections nécessaires à l’initialisation du projet, et de la continuité des moyens de le réaliser.
Une chose est établie : si l’un des 3 gagne “sa” bataille, l’entreprise perd. C’est comme un problème du prisonnier, mais à trois prisonniers, et dont le prix serait un logiciel et non une remise de peine (OK, ce n’est pas comme le problème du prisonnier 😅).
🌫
Oublions le conflit pour un moment, et considérons un logiciel réussi : c’est un succès (commercial, ou autre). Son code est habitable. Sa conception évolue depuis 15 ans. Les tentatives de le “simplifier”, de le refondre, de l’outsourcer (pardon pour le barbarisme) ont été sagement reportées sine die. Ce logiciel est une pièce essentielle du SI de ses utilisateurs. Son code, son architecture et sa méthodologie font école.
🗺
La conversation initiale qui a mené à ce projet a grandi de façon arborescente. Le cercle s’est élargi, sans perte de cohérence. C’est peut être “culturel”. En tout cas c’est très fort !
Une telle réussite suscite toujours la même question : mais comment font ils ?
Stay Tuned !
🌁