Une des phrases que j’ai le plus entendue depuis le début de ma carrière est « l’équipe X n’a pas conscience des problèmes de l’équipe Y ». Et dans la plupart des cas où elle est prononcée, le problème est rarement humain. Il est plutôt organisationnel.
Voir la publication originale
Cette dernière est republiée ici afin de ne pas dépendre entièrement d'une plateforme tierce.
Cette situation apparaît généralement lorsque les équipes évoluent en silos, chacune avec ses propres objectifs, sans alignement ni vision commune. Des équipes de développement qui n’ont pas conscience des problématiques du support client parce que leurs objectifs et les indicateurs de performance associés sont uniquement basés sur le développement de nouvelles fonctionnalités.
Ou alors, des équipes de développement qui n’ont pas conscience des problèmes de l’infrastructure (et vice versa) parce qu’elles n’ont pas dans leur périmètre le déploiement et le suivi opérationnel des mises en production. Des exemples comme cela, il en existe une multitude.
Un découpage par expertise technique conduit inévitablement à ces silos. Chaque équipe défend ses intérêts, optimise ses indicateurs, mais perd de vue l’objectif qui devrait être commun aux différentes équipes: la valeur pour l’utilisateur.
C’est là qu’une organisation en équipe produit est intéressante. Une équipe produit s’organise autour de compétences pluridisciplinaires (PO, UX, développeurs, ops, QA…) qui possèdent toutes les compétences nécessaires: analyser, concevoir, développer, tester et déployer. Une équipe capable de gérer un cycle produit dans sa globalité, de la création jusqu’à la mise à disposition aux utilisateurs tout en assurant son suivi opérationnel. Elle incarne le mantra « You build it, You run it ».
À la fois, autonome, auto-organisée et responsable d’un périmètre fonctionnel entier. Chaque membre de l’équipe aura ainsi conscience des problématiques des autres. Tout le monde avance à un objectif commun où la satisfaction de l’utilisateur final est la clé du succès.
