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.
