La pensée systémique
Il m’arrive de travailler avec des clients qui ont un problème majeur de livraison dans les délais et avec la qualité convenue. Lorsque je commence à investiguer les causes, je constate que lorsque je parle à l’équipe produit, elle dit que le problème vient du fait que l’ingénierie n’est pas assez rapide et/ou produit trop de défauts, et lorsque je parle à l’ingénierie, on me dit qu’ils reçoivent des spécifications incomplètes de la part du produit, ce qui signifie qu’ils doivent passer plus de temps à développer, et parfois défaire des modifications car elles ne correspondaient pas à ce que le client voulait. Il est courant que ces organisations se voient comme un ensemble de silos, et croient que la solution réside dans la « correction » de l’un de ces silos (par exemple, l’ingénierie). Mais c’est une vision réductionniste du problème, et cela aide rarement à le résoudre. Pour s’attaquer à la racine du problème, nous devons repenser notre façon de comprendre l’organisation, et c’est là que la pensée systémique peut aider. Comme Einstein l’a dit : « Nous ne pouvons pas résoudre les problèmes en pensant de la même manière que lorsque nous les créons ».
Il y a quelques années, j’ai découvert le livre Team Topologies (de Mathew Skelton et Manuel Pais), qui parle des organisations comme des systèmes logiciels. Le livre introduit la loi de Conway, qui stipule que les organisations produisent des systèmes qui imitent leurs structures de communication. Des exemples de cette loi en pratique peuvent être observés lorsque nous séparons une équipe travaillant sur le même composant ou microservice : il est courant que ce composant finisse par se scinder, puisque la structure de communication entre les équipes se divise, rendant la collaboration étroite nécessaire pour travailler sur le même composant plus compliquée. Le livre parle de la manoeuvre inverse de Conway, qui nous invite à concevoir notre organisation en fonction de l’architecture que nous voulons atteindre. Cela remet en question de nombreuses décisions organisationnelles prises dans les entreprises, où l’architecture n’est pas prise en compte ou joue un rôle secondaire dans la conception de l’organisation. Et cela nous invite à considérer les personnes et le logiciel qu’elles produisent comme des parties du même système.
Les entreprises sont des systèmes, mais elles ne sont souvent pas perçues comme tels. Et bien que nous ne soyons pas toujours conscients du système qui constitue notre organisation, ce système est réel et il est là. Parfois, la seule représentation visuelle du système d’une entreprise est un organigramme traditionnel, mais c’est une vision très limitée qui ne montre que les personnes, les équipes et les lignes hiérarchiques. Elle ne reflète ni le flux d’information, ni les connexions dynamiques, ni la culture, ni les relations réelles et complexes qui se produisent à travers l’organigramme.
Linéarité et non-linéarité
Nous avons l’habitude de penser de manière linéaire : si X alors Y. Cependant, les systèmes ne peuvent pas être compris de cette façon. Le nombre de composants et de relations entre eux croît de manière exponentielle, et les systèmes deviennent non-linéaires. J’ai continuellement des conversations dans lesquelles les gens essaient d’aborder les problèmes de manière trop simplifiée. Par exemple, en discutant avec un manager il y a quelques mois de la nécessité d’investir dans la mise à niveau de son infrastructure cloud, il m’a demandé quel était le ROI attendu, en termes de nombre d’heures par semaine que chaque développeur allait économiser par rapport au coût de la mise à niveau de l’infrastructure. Il voulait savoir cela pour décider s’il approuvait l’investissement ou non. Bien que nous puissions estimer les économies en heures de développeur, calculer le ROI de cette manière et prendre une décision go/no-go laisse de côté de nombreux autres aspects importants. Si nous pensons en termes de systèmes et travaillons à identifier les implications d’avoir une infrastructure obsolète, de nouvelles perspectives s’ouvrent où nous pouvons voir que cela n’affecte pas seulement la productivité, mais aussi les personnes, les opérations et les clients. Dans ce diagramme, à titre d’exemple, on peut clairement voir :
Lorsque nous pensons en termes de systèmes, nous commençons à prendre conscience des différentes parties et de la façon dont elles sont liées et influencent les résultats du système. Mais plus nous approfondissons le système, plus nous prenons conscience du nombre de variables et de l’éloignement de la recherche de la bonne décision. Le paradigme change, et au lieu de chercher la décision définitive, nous expérimentons, collectons du feedback et réajustons la direction. Nous apprenons. Les méthodologies Agile fonctionnent de cette manière, reconnaissant l’impossibilité de développer un projet conçu et planifié intégralement au départ, pour répondre aux besoins complexes d’un client de manière adéquate. Les startups fonctionnent ainsi : au lieu d’usines, elles sont conçues comme des moteurs d’expérimentation et d’apprentissage. La devise de Facebook était « Move fast and break things », ce qui peut être vu comme la reconnaissance que le monde est un système complexe, et que pour trouver la bonne solution, il vaut mieux expérimenter, ne pas avoir peur d’échouer et apprendre de manière empirique.
La pensée systémique nécessite un changement de mentalité, elle nécessite d’abandonner une approche réductionniste, où si nous faisons X alors nous obtenons Y. Elle nécessite d’identifier les différentes pièces d’un problème et les relations entre elles. Elle nécessite d’identifier les différentes pièces qui influencent un problème et les relations entre elles. Elle nécessite de faire une analyse des causes profondes, de ne pas s’arrêter au symptôme, d’accepter que souvent nous n’avons pas suffisamment d’informations pour prendre une décision, et qu’alors nous devons expérimenter, apprendre et réévaluer la décision. L’outil de la pensée systémique est la modélisation, la représentation des parties, des relations, du tout et des résultats. Cela peut se faire avec un tableau blanc physique ou en ligne (par exemple Miro), comme le montre le diagramme ci-dessus.
Bien que l’utilisation de la pensée systémique ne soit pas encore répandue dans l’industrie du logiciel, je crois que ce n’est qu’une question de temps avant que cela ne se produise. Nous voyons continuellement comment la mentalité et la vision plus classiques pour aborder les problèmes se heurtent à la réalité. Commencer à utiliser la pensée systémique n’est pas compliqué, peut-être y a-t-il un problème qui vous trotte dans la tête, et pour lequel la pensée systémique peut vous aider à progresser.
Références
Je travaille actuellement pour aider les entreprises et les équipes technologiques à mieux exploiter leur potentiel. Je les aide à prendre conscience de leurs inefficacités et de la manière dont elles peuvent travailler sur des actions concrètes pour s’améliorer dans leur contexte, et ce de manière continue. Si vous sentez que vous avez une marge d’amélioration dans votre entreprise, mais que le quotidien vous accapare, nous pouvons discuter pour explorer des solutions ensemble. Réservez un appel ici.