Organigramme d'ingénierie : relier les équipes aux systèmes qu'elles possèdent

La plupart des organigrammes répondent à une seule question : qui rend compte à qui. Les ingénieurs ont rarement besoin de cette réponse. Pendant un incident, ils doivent savoir quelle équipe possède le service en panne et qui est d'astreinte. En revue de conception, ils doivent savoir quelles équipes un changement touche et comment ces équipes travaillent ensemble. Un schéma de noms et de titres ne répond à aucune de ces questions.

Cet article construit un organigramme d'ingénierie qui y répond. Il garde les liens hiérarchiques pour la dimension humaine et ajoute ce dont l'ingénierie a besoin : type d'équipe, systèmes possédés, horaires d'astreinte et façon dont les équipes interagissent. Il utilise le vocabulaire de Team Topologies pour les équipes et se termine par ce qu'il faut étiqueter et par la façon de garder le schéma à jour.

Ce qu'un organigramme d'ingénierie doit montrer

Au-delà de quelques équipes, laissez les ingénieurs individuels hors du schéma et montrez une carte par responsable d'équipe. Un schéma de soixante noms est un annuaire ; un schéma de huit équipes est une carte. Reliez chaque équipe à sa propre liste de membres si les noms sont utiles.

Les liens hiérarchiques ne disent pas tout

L'article de Mel Conway « How Do Committees Invent? » a été publié dans Datamation en avril 1968. Sur sa propre page consacrée à la loi, il en énonce ainsi la thèse : une organisation qui conçoit un système produit une conception dont la structure copie la structure de communication de l'organisation. Fred Brooks l'a ensuite appelée loi de Conway, et le nom est resté.

Notez le mot communication. Un organigramme montre les liens hiérarchiques, et ce n'est qu'une partie de la façon dont les gens communiquent. Deux équipes rattachées à des directeurs différents qui se parlent tous les jours façonnent le système davantage que le trait entre leurs managers. C'est pourquoi le schéma de cet article note comment les équipes travaillent ensemble, et pas seulement à qui elles rendent compte.

La loi sert aussi d'outil de conception. Si deux services doivent rester indépendants, ne les confiez pas à des équipes qui doivent coordonner chaque changement. L'article de Conway ajoute un corollaire : la première conception est rarement la meilleure, donc l'organisation doit être assez souple pour évoluer avec elle.

Types d'équipes et modes d'interaction

Team Topologies, de Matthew Skelton et Manuel Pais, donne aux équipes un vocabulaire réduit et partagé : quatre types d'équipes et trois façons d'interagir.

Les trois modes d'interaction :

• Collaboration. Deux équipes travaillent étroitement pendant une période définie pour découvrir quelque chose de nouveau, comme une API ou une pratique. C'est coûteux, alors fixez-lui une date de fin.
• X-as-a-Service. Une équipe fournit quelque chose et l'autre le consomme avec peu d'interaction, comme un pipeline de déploiement.
• Facilitation. Une équipe en aide et en accompagne une autre, par exemple pendant qu'elle adopte une nouvelle approche de test.

Une mise en garde du site de Team Topologies lui-même : il précise que l'approche n'est pas une méthode pour concevoir un nouvel organigramme. Elle décrit la façon dont le travail circule entre les équipes. Utilisez son vocabulaire comme étiquettes sur votre schéma, pas comme une raison de redessiner chaque lien hiérarchique.

Gardez la responsabilité au même endroit

Une responsabilité inscrite seulement sur un diagramme devient vite obsolète. Gardez la source de vérité là où les ingénieurs regardent déjà, et laissez le schéma la refléter au niveau des équipes.

Dans un catalogue de services comme Backstage, chaque composant doit désigner un propriétaire : dans le format de descripteur du catalogue, spec.owner est un champ obligatoire, et le propriétaire est une entité unique, le plus souvent une équipe. Dans un dépôt, un fichier CODEOWNERS associe des chemins aux personnes ou équipes qui en sont responsables, et GitHub demande automatiquement une revue aux propriétaires du code quand une pull request qui n'est pas un brouillon modifie leur code.

Si le schéma et le catalogue se contredisent, le catalogue a généralement raison, et le schéma aurait dû être revu depuis longtemps.

L'exemple : l'ingénierie d'une boutique en ligne

Le département d'ingénierie d'une boutique en ligne compte un VP et deux directeurs. Product Engineering dirige trois équipes : Checkout et Search, toutes deux alignées sur un flux, et Payments, une équipe sous-système complexe qui possède le traitement des paiements et le scoring de fraude. Platform Engineering dirige l'équipe Platform, qui possède le CI/CD, les clusters Kubernetes et la stack d'observabilité, ainsi qu'une équipe Developer Experience dont le poste de responsable est encore vacant.

Deux interactions sont actives ce trimestre. Payments et Checkout collaborent sur 3-D Secure jusqu'à la fin du T2. Developer Experience facilite le passage de Checkout aux tests de contrat.

Comment le lire :

• De haut en bas, les liens hiérarchiques. Le VP, deux directeurs et cinq responsables d'équipe. Les traits montrent qui rend compte à qui, rien d'autre.
• Couleur de la carte, type d'équipe. Ambre pour les équipes alignées sur un flux, rose pour le sous-système complexe, bleu pour la plateforme et violet pour la facilitatrice. Les managers au-dessus du niveau des équipes restent en gris.
• Sous chaque équipe, la vue ingénierie. Les services que l'équipe possède, ses horaires d'astreinte et son interaction actuelle avec les autres équipes.
• La carte en pointillé est un poste vacant. Developer Experience n'a pas encore de responsable, et le schéma le dit au lieu de cacher le manque.

Ce qu'il faut étiqueter

• Les noms d'équipes tels que les gens les prononcent. Si le canal d'incident dit « Checkout », le schéma dit Checkout.
• Les systèmes possédés, sous les noms utilisés dans le catalogue, les tableaux de bord et les alertes.
• Les horaires d'astreinte et le chemin d'escalade.
• Le mode d'interaction et une date de fin pour chaque collaboration.
• Les liens en pointillé, comme une ingénieure sécurité rattachée à l'équipe sécurité qui travaille chaque jour avec Payments.
• Le site ou le fuseau horaire quand les équipes en couvrent plusieurs.
• La date de la dernière revue, sur le schéma lui-même.

Erreurs courantes

• Des personnes sans équipe. Un arbre de noms n'indique à personne où aller quand quelque chose casse.
• Des systèmes sans propriétaire. Si un service n'apparaît sous aucune équipe, c'est cela le constat. Attribuez-le avant que le prochain incident ne le fasse.
• Une responsabilité partagée. Deux propriétaires, c'est souvent aucun. Ce n'est pas un hasard si Backstage demande un propriétaire unique.
• Une collaboration sans fin. La collaboration est prévue pour une période définie. Une collaboration qui ne finit jamais signifie souvent que la frontière entre les deux équipes est au mauvais endroit.
• Des équipes surchargées. Une équipe qui possède une douzaine de services et deux rotations d'astreinte sera lente sur tout. Team Topologies traite la charge cognitive d'une équipe comme une limite à prendre en compte dans la conception, et le schéma rend cette charge visible.
• Un schéma que personne ne met à jour. Mettez-le à jour à chaque réorganisation et à chaque nouveau service, et revoyez-le à intervalles réguliers.

L'organigramme montre qui possède quoi ; il ne montre pas comment les systèmes s'articulent. Pour cela, dessinez un diagramme du modèle C4 ou un diagramme d'architecture microservices, et gardez les deux à jour comme l'explique l'article des diagrammes d'architecture qui ne se périment pas.

Le construire dans Archboard

1. Connectez-vous avec Google ou GitHub et créez un diagramme, ou partez du modèle d'organigramme.
2. Depuis le pack Organigramme, ajoutez une carte Employé pour le VP et renseignez le nom, le titre, le département et le site.
3. Ajoutez des personnes avec les poignées plus : en dessous pour un subordonné, à côté pour un pair, au-dessus pour un manager. Le schéma se dispose tout seul de haut en bas.
4. Ajoutez une carte Poste vacant pour chaque rôle que vous recrutez.
5. Donnez à la carte de chaque responsable d'équipe la couleur de son type d'équipe, et laissez en gris les managers au-dessus du niveau des équipes.
6. Sous chaque responsable d'équipe, ajoutez un Texte du pack Base avec le type d'équipe, les systèmes possédés, les horaires d'astreinte et le mode d'interaction actuel.

L'exemple utilise 8 nœuds de diagramme et reste dans les limites de l'offre Free. Le texte ne compte pas dans cette limite. La page créateur d'organigrammes présente le partage et l'export.

FAQ

Un organigramme d'ingénierie doit-il montrer chaque ingénieur ? Pour quelques équipes, oui. Au-delà, montrez les équipes et leurs responsables, et reliez chaque équipe à sa propre liste de membres. Le schéma reste lisible et change moins souvent.

Comment représenter un manager fonctionnel en pointillé ? Tracez un trait en pointillé depuis le second manager et gardez le trait plein pour le manager qui mène les entretiens d'évaluation. Dans Archboard, une connexion depuis un second manager devient un trait en pointillé, et la disposition reste fondée sur le premier manager.

Quelle différence entre un organigramme et une topologie d'équipes ? Un organigramme montre les liens hiérarchiques. Une topologie d'équipes montre les types d'équipes et la façon dont elles interagissent. Dessinez les deux, ou annotez l'organigramme avec les interactions, comme dans l'exemple.

Où la responsabilité des services doit-elle être tenue ? Dans un catalogue de services ou dans des fichiers CODEOWNERS, où les outils et les personnes peuvent la trouver. L'organigramme la reflète au niveau des équipes.

À quelle fréquence mettre à jour un organigramme d'ingénierie ? À chaque réorganisation, nouvelle équipe ou nouveau service, plus une revue régulière, par exemple mensuelle. Inscrivez la date de la dernière revue sur le schéma.

Commencez gratuitement — un siège, sans carte bancaire.