Business : Mise en place d’une structure d’organisation produit

Équipes de produits et leadership fonctionnel

Dans cet article, je parlerai un peu plus de certaines des meilleures pratiques de configuration organisationnelle pour les équipes de développement de produits. Avant de plonger dans les meilleures pratiques, permettez-moi d’abord de décrire ce qu’une organisation de produits moderne devrait ne pas ressembler.

Maintenant que nous avons vu les raisons d’éviter la gestion du commandement et du contrôle et d’opter plutôt pour l’autonomie, comment organiser l’organisation du développement produit? La réponse est des équipes produit interfonctionnelles autonomes. Une équipe produit est une équipe de développement de produits atomiques, composée des différentes disciplines requises pour construire ou améliorer un produit.

Comment ces équipes produits commencent-elles? Il n’y a pas de réponse «correcte», mais il existe quelques dimensions le long desquelles des décisions peuvent être prises concernant leur configuration.

Permanence des équipes

La première dimension est la pérennité de ces équipes et leur appartenance. À une extrémité du spectre, les équipes restent stables pour toujours (mais leurs objectifs peuvent changer avec le temps). De nouvelles personnes sont embauchées dans une équipe spécifique et devraient y rester. À l’autre extrémité du spectre, les équipes sont mises sur pied pour répondre aux opportunités émergentes et dissoutes une fois leur objectif atteint. Il existe évidemment aussi des modèles entre ces deux extrêmes.

Attribuer des domaines de responsabilité

Pour les équipes stables, se pose également la question de savoir dans quelle mesure les domaines de responsabilité des équipes doivent être fixes. En d’autres termes, chaque équipe continue-t-elle à travailler sur des sujets ou des parties du produit similaires au fil du temps, ou ces responsabilités changent-elles? Si les équipes ont une expertise de domaine spécialisée (par exemple, un expert de domaine dédié fait partie d’une équipe), les domaines de responsabilité peuvent devoir rester assez fixes. Sinon, il y a encore un compromis à considérer: des domaines de propriété stables signifient que l’expertise (par exemple, pour des parties de la base de code) peut être développée dans l’équipe, mais elle peut conduire à des silos de connaissances. Comme pour les équipes stables vs flexibles, il n’y a pas de réponse claire et nette à cette question. Forcer une certaine flexibilité d’équipe peut également aider à réduire le risque de silos de connaissances.

Dotation des équipes

La dotation – la détermination de la personne qui fait partie de l’équipe – peut être extrêmement délicate. Si vous avez des équipes qui restent stables plus longtemps, vous n’avez pas à prendre ces décisions très souvent, mais elles auront un impact sur les performances de l’équipe pendant longtemps. Inversement, avec des équipes flexibles, vous prendrez beaucoup de décisions de dotation, mais chacune n’aura pas autant d’importance. Il s’ensuit qu’avec des équipes stables, votre processus de dotation nécessite plus de diligence, et avec des équipes flexibles, plus de rapidité.

• Experience precedente: il peut être avantageux d’avoir des membres de l’équipe qui ont déjà effectué un travail similaire ou travaillé sur la zone affectée du produit, afin qu’ils aient moins de création de contexte à faire et puissent partager leurs connaissances avec l’équipe.
• Aspects de la gestion des performances: dans les plans de développement, vous pourriez avoir promis à un membre de l’équipe l’opportunité de travailler dans un domaine spécifique ou d’apprendre d’une personne plus âgée. Les décisions de dotation aident à tenir ces promesses.
• Dynamique d’équipe: pour constituer une équipe performante, il est important de prendre en compte des facteurs «doux» comme les relations existantes, les profils de personnalité, les styles de travail, etc., et de rassembler des personnes qui, selon vous, seront capables de travailler ensemble efficacement.
• Emplacement physique: si une équipe n’est pas entièrement distante, elle devrait idéalement être colocalisée. Cela signifie être assis de manière à ce que tout le monde puisse se voir, pas seulement «dans le même bâtiment». Le pire, c’est que certaines personnes s’assoient ensemble, mais pas le reste de l’équipe – cela signifie que les personnes qui ne sont pas assises avec le reste de l’équipe peuvent se sentir moins incluses.
• Mélange d’ancienneté: il est important d’équilibrer correctement l’ancienneté au sein de l’équipe, afin de permettre l’apprentissage mutuel, de préparer l’équipe au succès, d’équilibrer les différentes équipes les unes par rapport aux autres, etc.
• Diversité (sexe, race, âge, parcours,…): les équipes diverses sont plus performantes, vous devez donc viser à rendre vos équipes produits aussi diversifiées que possible. C’est bien sûr en partie une question d’embauche, mais il faut également en tenir compte dans la dotation (par exemple, ne mettez pas toutes vos femmes ingénieurs dans la même équipe).

Dans les grandes organisations de développement de produits, vous avez probablement besoin d’une superstructure couvrant les équipes de produits – une sorte de regroupement qui aide à organiser et à aligner les différentes équipes. Je suis loin d’être un expert sur ce sujet, alors au lieu de m’y plonger trop profondément, permettez-moi de mentionner quelques critères d’organisation possibles selon lesquels vous pourriez regrouper les équipes produits:

• Par client / groupe d’utilisateurs
• Par objectif global, par ex. croissance vs engagement
• Structures temporaires pour des initiatives stratégiques comprenant plusieurs équipes, par ex. un effort de plusieurs trimestres pour améliorer divers aspects de l’intégration

Alors que la plupart du travail est effectué dans des équipes de produits interfonctionnelles, il y a aussi l’élément fonctionnel. Dans de nombreuses organisations de produits, la ligne hiérarchique officielle est fonctionnel. En d’autres termes, les ingénieurs relèvent des directeurs de l’ingénierie, des concepteurs au directeur de la conception et des chefs de produit aux directeurs de produits ou à des rôles similaires.

Coaching fonctionnel et développement

Au lieu de dire à leurs rapports quoi faire, la responsabilité principale des responsables fonctionnels est de développer leurs rapports, par exemple par le biais de plans de développement, de commentaires et de coaching.

Contexte et direction

Le rôle de direction n’est pas en soi une tâche qui diffère selon la fonction de l’emploi. L’orientation produit doit être aussi interfonctionnelle que sa mise en œuvre dans les équipes produit. En d’autres termes, au niveau du leadership, l’alignement doit se produire entre les différentes fonctions (par exemple, la gestion des produits, l’ingénierie, la conception) avant que la direction ne soit transmise aux équipes de produits.

Taille de l’organisation et structure hiérarchique

Surtout dans les petites équipes, il n’est pas nécessaire d’avoir des managers dédiés pour chaque fonction. Par exemple, souvent les premiers chefs de produit relèvent directement du PDG, ou les chefs de produit individuels et les concepteurs individuels peuvent relever du même vice-président du produit plutôt que de chefs fonctionnels distincts. De même, du côté de l’ingénierie, les entreprises commencent souvent avec une structure de gestion d’ingénierie générique et n’ont que plus tard des gestionnaires spécifiques, par exemple backend et frontend.

Alternatives à la gestion de ligne

En plus de ne pas aborder le sujet des lignes hiérarchiques officielles, il existe également des approches alternatives à la conception organisationnelle qui renoncent à la gestion hiérarchique et adoptent une structure plus dynamique. Holacracy, peut-être le plus célèbre mis en œuvre par le pionnier américain du commerce électronique Zappos, pourrait être le plus connu. Personnellement, je n’ai aucune expérience avec ces approches alternatives, et donc je n’ai pas d’opinion forte.