Equipes Produit vs Equipes Feature
Auteur : Marty Cagan
Source : Product vs. Feature Teams
Date : 29/08/2019
Traducteur : Fabrice Aimetti
Date : 14/11/2022
Traduction :
Cet article va certainement contrarier de nombreuses personnes.
J'en suis désolé, mais le niveau de bruit et de confusion qui entoure le rôle du produit dans les entreprises technologiques ne fait qu'empirer. De plus, je constate que les questions et les comportements problématiques sont institutionnalisés dans les conférences, les programmes de formation et les soi-disant programmes de certification pour les responsables des produits.
J'ai abordé cette question à plusieurs reprises dans le passé, plus particulièrement dans l'article et la conférence sur les équipes produits émancipées (NdT : choix tout à fait personnel pour traduire empowered product teams). Cependant, beaucoup de gens n'y entendent que ce qu'ils veulent entendre, et il est devenu évident pour moi que je dois être plus explicite.
Alors, bien que cet article puisse être pénible à lire, si vous avez été frustré par les messages contradictoires et confus des personnes dans l'univers des produits, si vous me faites confiance, j'espère que cet article apportera un éclairage indispensable.
Dans le monde de la technologie, il existe trois types distincts d'"équipes produits", au sens large.
Les plus courantes en nombre ne sont pas vraiment des équipes produits, mais des équipes delivery. Elles sont également appelées "équipes de développement", "équipes Scrum" ou "équipes d'ingénierie". Si votre entreprise utilise une méthode comme SAFe, vous êtes malheureusement dans ce cas. Dans cette situation, il y a un certain nombre de développeurs, et un Product Owner. Le Product Owner dans ce modèle est ce que j'appelle un "administrateur du backlog". Il faut bien que quelqu'un s'occupe de ce travail administratif, mais il s'agit avant tout de produire des résultats, et cela n'a pas grand-chose à voir avec ce qui me préoccupe, à savoir la nécessité d'une innovation véritable et cohérente pour nos clients. J'ai écrit ailleurs pourquoi ce modèle n'est en fait qu'un cycle en V repackagé, et n'est pas utilisé par les véritables entreprises de produits technologiques. Alors, laissons tomber cette idée.
Cet article porte en réalité sur la différence entre les deux autres types d'équipes.
Je vous préviens que je suis sur le point d'introduire une terminologie qui n'est pas standard et qui ne fait certainement pas l'unanimité. Mais je dois le faire parce qu'aujourd'hui, dans notre secteur, nous appelons les deux autres types d'équipes "équipes produits" ou "brigades". Mais comme vous le verrez, bien que ces deux types d'équipes se ressemblent à un niveau superficiel, elles sont radicalement différentes, surtout lorsque nous parlons du rôle du product manager.
Lorsque j'ai écrit sur les vertus des équipes produits émancipées, je faisais référence à ce que je continuerai à appeler ici les équipes produits. Plus précisément, elles sont pluridisciplinaires (produit, conception et ingénierie), elles se concentrent sur les résultats/outcomes (plutôt que sur la production/output) et sont mesurées en fonction de ceux-ci, et elles sont émancipées pour trouver la meilleure façon de résoudre les problèmes qu'on leur a demandé de résoudre.
Dans cette optique, l'objectif d'une équipe produit est de résoudre les problèmes d'une manière qui satisfasse à la fois nos clients et notre entreprise.
Même si je souhaiterais qu'il en soit autrement, je sais que seul un faible pourcentage des équipes sont des équipes produits au sens propre du terme.
Le plus souvent, les équipes ne sont pas du tout émancipées. En revanche, elles sont là pour servir le métier.
Dans cet article, j'appellerai cette troisième catégorie d'équipes les équipes features (feature teams). Je m'écarte un peu de la définition habituelle des équipes features, mais j'utilise ce terme parce qu'il permet de mettre en évidence le fait que ces équipes se concentrent sur les résultats. Des features, et occasionnellement des projets. Généralement fournies à l'équipe sous la forme d'une liste de priorités appelée feuille de route.
Mais c'est là que je dois aller plus loin.
Rappelons que dans un produit, il y a toujours quatre risques :
- le risque de valeur (les gens vont-ils l'acheter ou choisir de l'utiliser ?)
- le risque d'utilisabilité (les utilisateurs peuvent-ils trouver comment l'utiliser ?)
- le risque de faisabilité (pouvons-nous le construire avec le temps, les compétences et la technologie dont nous disposons ?)
- le risque de viabilité économique (cette solution fonctionnera-t-elle pour les différentes activités de notre entreprise ?)
