« Equipes Produit vs Equipes Feature » : différence entre les versions
De Wiki Agile
Aucun résumé des modifications |
Aucun résumé des modifications |
||
| Ligne 43 : | Ligne 43 : | ||
* le risque de ''faisabilité'' (pouvons-nous le construire avec le temps, les compétences et la technologie dont nous disposons ?) | * 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 ?) | * le risque de ''viabilité'' économique (cette solution fonctionnera-t-elle pour les différentes activités de notre entreprise ?) | ||
Dans une équipe produit émancipée, le product manager est explicitement responsable de la valeur et de la viabilité du produit, le designer est responsable de l'utilisabilité et le responsable technique (''tech lead'') est responsable de la faisabilité. Pour ce faire, l'équipe [https://svpg.com/coaching-collaboration/ collabore véritablement] de manière intense, en donnant et en prenant, afin de découvrir une solution qui fonctionne pour chacun d'entre nous. | |||
Lorsque je parle et écris à quel point il est difficile d'être un véritable product manager d'une équipe produit émancipée, c'est précisément parce qu'il est très difficile de garantir la valeur et la viabilité. Si vous pensez que c'est facile de le faire, lisez [https://svpg.com/ceo-product-revisited/ ceci]. | |||
Cependant, dans une équipe feature, il y a toujours (si tout va bien) un concepteur pour assurer l'utilisabilité et des ingénieurs pour assurer la faisabilité, mais, et il est crucial de le comprendre : la valeur et la viabilité économique sont la responsabilité de la partie prenante ou de la personne dirigeante qui a demandé la feature dans la feuille de route. | |||
S'ils disent qu'ils ont besoin que vous construisiez la feature x, c'est qu'ils croient que la feature x apportera une certaine valeur, et qu'elle est viable pour l'entreprise. | |||
Il convient de souligner que même si la partie prenante est implicitement responsable de la valeur et de la viabilité, elle trouvera toujours un moyen de vous blâmer, vous et votre équipe, si les résultats escomptés ne sont pas atteints. Cela a pris trop de temps, la conception était mauvaise, des caractéristiques essentielles ont été supprimées pour respecter la date, etc. Et bien sûr, votre équipe n'a probablement jamais été convaincue que le projet valait la peine d'être construit. C'est une vieille chanson et j'ai [http://www.svpg.com/product-fail beaucoup écrit] sur ce problème. | |||
À première vue, une feature team et une véritable équipe produit émancipée sont toutes deux des brigades. Elles se ressemblent donc, mais les différences sont profondes. | |||
Commençons par le rôle du product manager. Dans une équipe produit émancipée, où le product manager doit assurer la valeur et la viabilité, une connaissance approfondie du client, des données, du secteur et surtout de votre entreprise (ventes, marketing, finance, support, juridique, etc.) constitue un élément absolument non négociable et essentiel. | |||
Pourtant, dans une équipe feature, ces connaissances sont (au mieux) dispersées parmi les parties prenantes. | |||
Dans tous les cas, j'espère qu'il est clair que les responsabilités du product manager dans ce modèle sont très différentes de celles d'une feature team. | |||
Le travail du product manager au sein d'une équipe feature est le plus souvent décrit comme une sorte de facilitateur, qui "garde les chats" afin d'obtenir la conception et la livraison de la feature, ou une forme nébuleuse et faible de leader pluridisciplinaire qui n'est pas vraiment responsable de quoi que ce soit de spécifique. Ces équipes features pensent souvent qu'elles font de la découverte de produit, mais il s'agit en fait de conception et peut-être d'un petit test d'utilisabilité. | |||
Mais il y a d'autres conséquences de la feature team sur le rôle du product manager. | |||
Comme l'équipe n'est pas émancipée - pour être clair, lorsqu'on vous donne des travaux à réaliser, vous n'êtes pas émancipé au sens propre du terme - il est très difficile d'attirer et de retenir de [https://svpg.com/the-product-designer-role/ véritables concepteurs produits] (une personne compétente en matière de conception de services, de conception d'interactions, de conception visuelle et de recherche sur les utilisateurs). | |||
Dans la grande majorité des cas où vous disposez d'équipes features, le concepteur (s'il y en a un) est un concepteur graphiste. Ce n'est pas que la conception graphique ou visuelle n'est pas importante, mais ce qui est pertinent ici, c'est qu'il y a maintenant un grand vide - quelqu'un doit au moins définir la conception de l'interaction et, si possible, faire des recherches sur les utilisateurs. Dans ce modèle, il est donc très courant de voir apparaître une pression sur le product manager pour qu'il tente de combler ces lacunes. | |||
Cette situation a d'autres conséquences négatives, car il n'est pas difficile d'apprendre les outils utilisés par les concepteurs, mais il est difficile d'apprendre à faire une bonne conception et une bonne recherche sur les utilisateurs. Malheureusement, de nombreux chefs produits n'ont jamais eu l'occasion de travailler avec un véritable concepteur produit professionnel, de sorte qu'ils ne savent même pas ce qui leur échappe. | |||
Si vous avez la chance d'avoir un véritable concepteur produit dans votre équipe (du moins jusqu'à ce qu'il parte dans une entreprise où ses compétences peuvent être pleinement utilisées), il se demande généralement (et à juste titre) à quoi sert le product manager, car il n'est pas difficile pour lui d'assumer les responsabilités supplémentaires du product manager de l'équipe feature, puisqu'il fait de toute façon la majeure partie du travail. | |||
Il en résulte que dans les équipes features, le rôle du product manager est principalement celui de chef de projet, et partiellement celui de concepteur (non compétent). | |||
Il y a souvent une frustration similaire chez les ingénieurs. Le product manager, qui est en fait un chef de projet, est souvent en désaccord avec la façon dont les ingénieurs pensent devoir travailler. Sans compter que dans ce modèle, les ingénieurs sont relégués au développement et, comme je l'ai dit à plusieurs reprises, si c'est le cas, nous n'obtenons que la moitié de leur valeur réelle (donc, encore une fois, les bons ingénieurs voudront partir et rejoindre une équipe produit émancipée où ils pourront vraiment exercer leur métier). | |||
Pour conclure sur ce point essentiel, lorsque j'écris que le product manager doit "faire partie des meilleurs talents de l'entreprise", que "le PDG doit considérer les product managers comme les futurs leaders potentiels de l'entreprise" et que "le product manager le plus fort est le PDG du produit", je ne parle absolument pas du product manager d'une équipe feature. | |||
J'espère qu'à ce stade, vous savez si vous travaillez dans un modèle d'équipe feature ou dans un modèle d'équipe produit émancipée, mais j'ai constaté que les gens sont souvent très réticents à admettre qu'ils sont dans le modèle d'équipe feature. | |||
Donc, voici quelques tests que vous pouvez appliquez à votre équipe : | |||
* Vous fournit-on des feuilles de route avec des features prioritaires et des dates, ou vous assigne-t-on des problèmes à résoudre avec des résultats métiers ? | |||
* Y a-t-il une ambiguïté dans les rôles entre vous et votre concepteur ? | |||
* Y a-t-il une ambiguïté dans les rôles entre vous et votre responsable développement ? | |||
* Passez-vous la majeure partie de votre journée à gérer des projets ? | |||
* Avez-vous essayé d'utiliser les OKRs et c'était un vrai désastre, soit parce qu'ils ont été rejetés, soit parce qu'il y a eu un mélange artificiel de résultats et de features livrées ? | |||
* Avez-vous une équipe de [https://svpg.com/missionaries-vs-mercenaries/ missionnaires ou de mercenaires] ? | |||
* Quel est le niveau de responsabilisation ? | |||
