Dans ce qui suit, les mots compliqué et complexe sont utilisés au sens donné par le cadre conceptuel Cynefin.
Voici la situation qui me turlupine car j’ai l’impression de la vivre et la revivre :
Un chef de projet informatique dit la chose suivante :
« Nous allons nous appuyer sur les experts et les architectes techniques pour construire nos produits car nous n’arrivons pas à les imaginer. Ces produits sont trop complIQUÉS pour moi qui ne suis pas/plus assez technique. ».
Ce chef de projet attend donc « une architecture» pour commencer le projet.
J’ai l’impression que le rôle des architectes semblent être ici de décomposer un Tout compliqué en pleins de petites briques moins compliquées pour qu’elles soient faisables par des personnes qui ne serait vraisemblablement pas en mesure de comprendre le compliqué du Tout.
Si on pousse cette décomposition, on pourrait dire qu’il a ceux qui pensent le compliqué et le décompose en problèmes clairs pour ceux qui font.
La question que je me pose est la suivante :
La façon de raisonner du chef de projet ne naîtrait-elle pas d’une impossibilité à considérer l’existence du complexe dans un projet informatique ?
Le développement logiciel a-t-il déjà bien fonctionner dans cette logique de décomposition ? Si oui dans quels cas ?
Peu importe la raison, il me semble que l’approche décrite présume que la situation est compliquée. La question est donc, est-ce que la situation est belle et bien compliquée ou non ? Elle est peut-être même confuse (domaine au centre de Cynefin) parce que personne ne s’est posé la question de savoir dans quel(s) domaine(s) on se situe. Comme souvent dans ce cas, les personnes se rabattent sur leur stratégie de prédilection.
Oui, pour une certaine définition de « fonctionner ». Dans un marché, il y en a toujours un qui devient leader. Et puis il y a des situations où le développement logiciel est compliqué : le métier, le besoin et les technos sont bien maitrisées. Je l’ai déjà vécu. Aujourd’hui, certaines personnes font la promotion de l’architecture ennuyeuse (boring architecture), parce que ça élimine une source de complexité.
Trois choses à ne pas perdre de vue :
La plupart des situations sont fractales, c-à-d comportent des aspects dans tous les domaines. Ca sert peu de déclarer qu’un énorme truc est complexe. Il vaut mieux réduire le niveau de granularité. J’utilise de plus en plus l’atelier 3-points pour aider à faire du sense-making sans avoir besoin d’expliquer toute la théorie derrière.
Nier l’ordre (compliqué + clair), c’est aussi désastreux que de nier la complexité. Les agilistes sont trop souvent coupables de cette première erreur.
Je me permets de rebondir sur une de tes questions à laquelle tu réponds.
Ne devrait-on pas ajouter un « pour qui » ? Suivant le niveau de connaissances des intervenants à l’atelier des 3-points, je me dis que les différents aspects du problèmes ne seront pas identiques en termes de contenu et de placement.
Par exemple, une personne ayant une compréhension fine de phénomènes physiques aura tendance à classer certains problèmes de cet ordre dans le domaine compliqué car une analyse lui suffira à prédire les implications. En revanche, une personnes n’ayant pas ce savoir et ignorant l’existence de modèles physiques pour décrire ces phénomènes classera sans doute le même problème dans la case du complexe.
Le placement des problèmes dans le cadre conceptuel Cynefin semble donc être relatif à l’expertise de celui qui le place. N’est-ce pas ?
Je peux t’en parler en long en large et en travers car c’est mon boulot.
D’abord le sujet de l’architecture est la solution et non le problème. Bien sûr, cela ne peut se faire sans une bonne compréhension du problème à résoudre par le Tout. Mais c’est bien ce que dit le chef de projet dans son message : « Ces produits sont trop compliqués pour moi qui ne suis pas/plus assez technique. » En soi, ces produits peuvent répondre à un problème parfaitement clair. Ou être une tentative de réponse à un problème complexe.
Ensuite, c’est une erreur courante de réduire l’architecture à un découpage composite. Bien sûr, c’est un aspect important mais c’est loin d’être le seul. L’interaction entre les composants est aussi un travail important, tout comme leur matérialisation (comment on les fabrique) et leur déploiement (comment on les fournit aux utilisateurs). Si on peut découper un problème en sous-problèmes plus simples, alors on est dans le domaine du compliqué, et c’est effectivement une bonne pratique de découper la solution en miroir du problème. C’est la première analyse que fait un bon architecte. Mais ce n’est pas toujours possible, et c’est là qu’on entre dans le domaine du complexe.
Bien qu’un problème soit complexe, on doit le résoudre avec une solution qu’on est capables de fabriquer. On doit donc établir une topologie, même si la résolution du problème complexe repose sur l’interaction entre les composants du systèmes plus que sur leur juxtaposition. C’est là qu’il devient d’ailleurs important de faire une architecture (à proprement parler) et pas juste une décomposition.
Le point critique sur lequel l’architecte et le chef de projet doivent se mettre d’accord c’est la composition de l’équipe (compétences et dimension). Dans une démarche complexe, les choses changent, mais tous les produits n’ont pas les moyens de remettre en question la topologie générale de la solution et la composition de l’équipe à chaque itération. Il est donc nécessaire de mettre en place un cadre qui réduit plus ou moins les possibilités de solutions en fonction des moyens disponibles.
Parce que c’est cool de se dire que là on pourrait faire un bout de logiciel en COBOL pour résoudre un bout du problème. Mais ça implique d’avoir un développeur COBOL dans l’équipe et ça c’est tout de suite beaucoup moins cool. Surtout si c’est pour ne plus en avoir besoin 3 mois après.
Les trois sont rarement parfaitement alignés. L’intérêt des ateliers comme 3-points est de créer des frottements entre les trois calques pour qu’ils s’alignent le plus possible : pour que notre connaissance, notre perception et la réalité soient dans le même domaine.
Un apport de frottement est l’inclusion d’une diversité de réalités, de connaissances et de perceptions. L’atelier 3-points tire profit de cette diversité en proposant une mécanique de résolution de conflits générative : lorsque plusieurs personnes ne sont pas d’accord sur le placement de quelque chose, on découpe jusqu’à trouver un accord.
qu’un problème complexe n’a pas toujours de définition précise
Tu parles de pivot. Ce n’est pas la réponse préconisé pour faire face à la complexité. On évite de pivoter. On lance une multitudes d’explorations parallèles réversibles (= safe-to-fail).
Oui, une manière de naviguer dans la complexité est de cartographier l’espace des contraintes. C’est ce que propose la cartographie estuarienne.
