Qu’est-ce que la loi de Conway?

La majorité d’entre vous doit connaitre la loi de Moore, mais connaissez-vous la loi de Conway? Elle date de la même époque, mais elle est beaucoup moins connue dans le monde informatique.

Cette loi dit que « les organisations qui conçoivent des systèmes […] tendent inévitablement à produire des designs qui sont des copies de la structure de communication de leur organisation. »

Plus simplement, on reproduit la structure organisationnelle dans laquelle on vit pour concevoir nos systèmes. Par exemple, nous séparons notre organisation en 3 départements (UI, backend, base de données), nous aurons forcément un système à 3 composantes qui communiquent entre elles.

Cette loi s’applique également à travers les différents outils collaboratifs qu’on utilise tous les jours. Que ce soit Microsoft Team, Jira, Slack, Confluence, etc., on a tendance à reproduire la structure organisationnelle de notre organisation. Or, ceci amène plusieurs problèmes et enjeux.

Voici une petite “blague” en lien avec la loi de Conway de certaines grandes entreprises que vous connaissez et vous pourrez possiblement comprendre le lien entre leur produit sur le marché .

D’ailleurs, pour mes amis en transformation Devops, ils auront surement remarqué le “pattern” suivant dans la conception logicielle:

Quel est l’impact sur mes outils?

Voici quelques exemples d’impacts:

Des espaces Confluence/Sharepoint par équipes/départements, du dédoublement d’information (et potentiellement contradictoire)
Des projets Jira par équipes/départements
Des canaux/équipes dans Slack ou Microsoft Team par équipe/département (en excluant l’accès aux autres)
Des outils différents dans des équipes différentes pour le même besoin

Quand on configure nos outils de cette façon, on reproduit automatiquement la structure organisationnel dans lequel on est. C’est ce qui semble le naturel à faire, mais après quelques années d’adoption des outils, on se rend compte qu’on frappe certains problèmes de collaboration globale et même d’enjeux d’administration des outils.

Qu’arrive-t-il avec tous les items que vous avez configurés lorsque l’organisation décide de faire une grande réorganisation de ses équipes et départements? Vous allez devoir tout changer les configurations, migrer des données, créer de nouveaux éléments, perdre l’historique. Les gens n’arriveront plus à se retrouver à travers l’information qui se retrouve dans les outils. La confusion crée une perte de productivité.

D’accord, mais que puis-je faire pour contrer la loi de Conway?

Maintenant que vous comprenez cette loi et ses impacts sur vos décisions, vous pouvez penser autrement. Quand vous structurez vos outils, pensez à leur donner une flexibilité. Les structures organisationnelles ont tendance à changer, il faut penser à plus long terme.

Par exemple, Confluence ou Sharepoint sont des outils pour aider les gens à retrouver de l’information. Ainsi, vous pourriez classer l’information par grands sujets/produits plutôt que par département. Ainsi vous éviterez que chaque équipe ait sa “documentation” et on se retrouve avec des silos informationnels. Il n’est pas étonnant par la suite qu’il soit si difficile de trouver de l’information.

La même logique s’applique à tous les outils: pensez à comment vous pourriez briser les silos et ramener la structure de travail et de communication autour autour d’un produit/service plutôt qu’autour d’un département ou une équipe.

Cela vous aidera à améliorer la collaboration dans votre entreprise et vous deviendrez tranquillement un briseur de silos.