L'harmonie idéale entre autonomie et régularité

Comment les équipes produit peuvent trouver le juste équilibre

Atlassian Par Atlassian
Parcourir les rubriques

« Les équipes produit ont besoin d'autonomie pour innover efficacement. Mais à mesure que les organisations évoluent, cette autonomie peut créer le chaos sans le bon framework. »

En tant que Senior Product Manager pour Jira Product Discovery, des clients de tous secteurs et de toutes tailles m'ont confié qu'ils rencontraient tous ce défi. Une question revient sans cesse : comment donner aux équipes les moyens de travailler de manière autonome tout en maintenant une cohérence suffisante pour que l'organisation fonctionne efficacement ?

Le point de rupture

Toutes les organisations en pleine croissance se retrouvent dans cette situation à un moment ou un autre. Avec une ou deux équipes produit, tout se passe bien. Quand vous en avez cinq, les fissures commencent à apparaître. Mais quand vous atteignez dix ou vingt équipes ? C'est là que les choses se gâtent.

J'observe sans cesse cette tendance dans les conversations avec nos clients. Les équipes produit ne fonctionnent pas en vase clos. Elles doivent interagir avec la direction pour s'aligner sur les objectifs de l'entreprise, les équipes d'ingénierie pour développer et livrer leurs idées, et le marketing et les ventes pour promouvoir leurs fonctionnalités. Lorsque quelques équipes travaillent différemment, le reste de l'organisation peut s'adapter. Mais au fur et à mesure que vous évoluez, une situation autrefois gérable se transforme en véritable chaos.

Ce point de rupture est particulièrement intéressant, car il est souvent dû à un succès, et non à un échec. Vos équipes produit réussissent chacune à leur manière. Certaines se concentrent sur la satisfaction des besoins des clients par le biais de sessions de design conjoint et d'améliorations de la convivialité, d'autres sur la stabilité de la plateforme et les performances système. Chaque équipe travaille bien à sa manière, en utilisant des processus adaptés à son contexte. Mais sans un framework commun qui assure la cohésion, ce succès ne sera pas durable.

Les mesures extrêmes ne sont pas la solution

Au cours de nombreuses conversations avec des clients, j'ai observé deux tentatives courantes pour résoudre ce problème de coordination de l'équipe produit. Certaines organisations essaient d'imposer une standardisation complète, en obligeant chaque équipe produit à utiliser des processus, des modèles et des outils identiques. D'autres suivent la voie opposée, laissant les équipes agir en toute indépendance en espérant que les pièces du puzzle s'assembleront d'une manière ou d'une autre.

Aucune de ces deux approches extrêmes ne fonctionne. Comme me l'a dit un responsable des opérations produit, « quand nous avons essayé de faire en sorte que toutes nos équipes produit travaillent de la même manière, nous avons atteint une conformité sans engagement. Les équipes ont suivi le mouvement, mais ont perdu leur étincelle ». D'un autre côté, l'autonomie totale s'est traduite par une fragmentation et une inefficacité. Les équipes produit n'ont pas pu partager leurs connaissances de manière efficace, les parties prenantes ont eu du mal à se faire une vue d'ensemble, et des opportunités de collaboration ont été manquées.

3 éléments pour trouver le juste équilibre

Les organisations les plus performantes relèvent ce défi en utilisant trois éléments clés pour créer un équilibre sans compromettre l'autonomie.

Premièrement, elles définissent un langage commun : des moyens partagés de discuter des objectifs, des phases de développement et des efforts qui permettent une communication claire sans imposer un processus. Deuxièmement, elles établissent des visualisations cohérentes qui permettent aux équipes de travailler à leur façon, tout en offrant aux parties prenantes la clarté dont elles ont besoin. Enfin, elles adoptent les bonnes pratiques en combinant la culture, des frameworks flexibles et des outils de support.

Dans cet article, nous verrons comment ces éléments interagissent pour trouver le juste équilibre entre l'autonomie de l'équipe et la clarté organisationnelle. Vous verrez des exemples spécifiques montrant comment différents types d'équipes produit, qu'elles se concentrent sur les fonctionnalités destinées aux clients ou travaillent sur les fonctionnalités de la plateforme, peuvent conserver leurs approches uniques tout en contribuant à un objectif commun.

Créer un langage commun

Les équipes produit doivent réaliser un point important : inutile de standardiser les méthodes de travail, elles doivent juste parler la même langue. Dans le cadre de notre travail avec les clients, nous avons identifié trois éléments clés qui permettent de créer cette compréhension commune sans pour autant renoncer à l'autonomie de l'équipe :

Des objectifs qui connectent les équipes

Prenons l'exemple de l'un de nos clients qui s'est fixé pour objectif d'augmenter le taux de satisfaction client à 80 % à l'échelle de l'entreprise. Ses équipes produit ont abordé cet objectif de manière complètement différente en fonction du contexte :

  • Une équipe s'est attachée à réduire le nombre de clics nécessaires pour effectuer les actions courantes
  • Une autre s'est concentrée sur l'amélioration de la fiabilité du système et la réduction des temps d'arrêt
  • Une troisième a donné la priorité à la précision des résultats de recherche

Un même objectif avec des approches différentes. Néanmoins, tout le monde a compris en quoi son travail contribuait à améliorer la situation dans son ensemble.

Des phases qui apportent de la clarté

Au lieu de forcer les équipes à suivre des processus rigides, les organisations prospères standardisent les étapes importantes. Atlassian a défini quatre phases clés qui s'appliquent aux différents types d'équipes produit :

  1. Interrogation : analyse complète du problème
  2. Exploration : solution dimensionnée et validée
  3. Création : fonctionnalité déployée dans toutes les régions
  4. Impact : résultats mesurés au bout de 3 mois

Lorsqu'une équipe produit dit qu'elle est dans la phase « Exploration », tout le monde sait ce que cela signifie : elle comprend le problème et cherche des solutions. Mais comment y parvenir ? Cela dépend de chaque équipe.

Une évaluation sensée de l'effort

Troisièmement, un framework commun pour mesurer l'effort. Cela ne veut pas dire que toutes les équipes estiment le travail de la même façon, mais qu'elles traduisent leurs estimations dans un langage commun. Les équipes chargées des plateformes peuvent tenir compte de la complexité du système et des risques de déploiement, tandis que d'autres équipes produit se concentrent sur la complexité des interactions avec les utilisateurs, mais peuvent communiquer ces évaluations d'une manière compréhensible pour tout le monde.

Synthèse

Vous voulez un exemple qui illustre comment combiner ces trois éléments ? Visionnez mon webinaire intitulé How Product Operations can find the right balance between autonomy and consistency (Comment les équipes chargées des opérations produit peuvent trouver le juste équilibre entre autonomie et cohérence), où j'explique de manière pratique comment deux équipes distinctes peuvent avoir des méthodes de travail très différentes pour atteindre le même objectif.

Project management

Keeping multiple product initiatives on track is no small feat. The product operations manager supports product managers by coordinating complex projects and timelines, tracking progress against product roadmaps, and managing the countless dependencies between teams. They anticipate potential roadblocks and clear the path for on-time delivery.

Créer des visualisations cohérentes

Une fois qu'un langage commun a été établi, le prochain défi consiste à rendre le travail visible au sein de l'organisation. C'est là que de nombreuses équipes produit sont confrontées à une difficulté familière : l'exercice de la feuille de route trimestrielle.

Souvent, les équipes produit passent des heures à élaborer leurs feuilles de route, chacune utilisant des formats adaptés à son travail. Certaines créent des feuilles de calcul détaillées, car elles suivent des dépendances complexes. D'autres préfèrent les diaporamas pour les présentations aux parties prenantes. D'autres encore tiennent à jour leurs feuilles de route dans des outils d'ingénierie afin de suivre les tâches de développement au plus près.

What businesses need product operations?

Résultat ? Les équipes chargées des opérations produit sont confrontées à une tâche impossible. Elles doivent obliger chaque équipe à recréer ses feuilles de route dans un format standardisé (cela prend beaucoup de temps et est source d'erreurs) ou essayer de consolider les différents formats eux-mêmes (cela prend encore plus de temps et est source d'erreurs).

La solution n'est pas d'obliger tout le monde à utiliser le même outil, mais de créer des approches de visualisation qui fonctionnent à la fois pour les équipes produit et pour les parties prenantes. Voici comment s'y prennent les organisations prospères :

Visualisation à la source

Au lieu de copier des informations d'un outil à l'autre, les organisations de premier plan visualisent les données là où elles se trouvent. Par exemple, une équipe produit peut préférer une vue en tableau organisée par phases de développement, tandis qu'une autre a besoin d'une vue chronologique pour gérer les dépendances complexes. Chaque équipe gère son workflow à sa manière, mais les parties prenantes peuvent accéder à une feuille de route unifiée contenant des informations cohérentes sur les objectifs, les phases et les calendriers de toutes les équipes. Oubliez les copier-coller d'informations entre les outils et les mises à jour manuelles à plusieurs endroits.

Différentes vues pour représenter des éléments communs

Pour obtenir des visualisations cohérentes, vous devez d'abord comprendre votre public. Alors que les équipes produit ont besoin d'informations détaillées pour leur travail quotidien, les parties prenantes se concentrent généralement sur un ensemble restreint d'éléments critiques qui les aident à comprendre l'avancement et à prendre des décisions :

  • Objectifs auxquels le travail contribue, afin que la direction puisse suivre l'avancement par rapport aux objectifs de l'entreprise
  • Phase de développement actuelle (Interrogation, Exploration, Création, Impact) qui donne une idée précise de l'avancement et des prochaines étapes
  • Les délais attendus pour permettre une meilleure coordination entre les équipes et avec les parties prenantes externes