« L'unique raison pour laquelle les frameworks de priorisation ne fonctionneront jamais, et ce qu'il faut faire à la place » : différence entre les versions

De Wiki Agile
Aucun résumé des modifications
Ligne 112 : Ligne 112 :
Ils sont littéralement chargés de déterminer, parmi l'avalanche de fonctionnalités demandées par les parties prenantes dans le backlog de leur équipe, celle qu'ils doivent construire en priorité, et de veiller à ce qu'elle soit livrée le plus rapidement possible.<br/>
Ils sont littéralement chargés de déterminer, parmi l'avalanche de fonctionnalités demandées par les parties prenantes dans le backlog de leur équipe, celle qu'ils doivent construire en priorité, et de veiller à ce qu'elle soit livrée le plus rapidement possible.<br/>


==Le Product Management est un rôle stratégique==
===Le Product Management est un rôle stratégique===
Si les Product Managers ont d'innombrables responsabilités, ils ne sont en fin de compte là que pour une seule raison :<br/>
Si les Product Managers ont d'innombrables responsabilités, ils ne sont en fin de compte là que pour une seule raison :<br/>


Ligne 120 : Ligne 120 :
<br/>
<br/>
Tout le reste est une sorte de gestion de projet, d'équipe ou de développement.<br/>
Tout le reste est une sorte de gestion de projet, d'équipe ou de développement.<br/>
===Rareté de la clarté stratégique===
Dans les environnements où la stratégie est mal formulée, voire contestée aux niveaux les plus élevés, ce manque de clarté finit par se répercuter vers le bas, plaçant les Product Managers et leurs équipes sous une pression constante de la part de multiples acteurs.<br/>
<br/>
<br/>
Ils ont alors recours au "théâtre des priorités".<br/>
<br/>
Mais il est déjà trop tard, car nous établissons des priorités dans le mauvais espace :<br/>


L'espace des Solutions, au lieu de l'espace des Problèmes.
Et [https://www.mironov.com/strat-layers/ Rich Mironov d'écrire] :
"...nous ne pouvons pas prioriser le travail de manière générique, valider les améliorations potentielles auprès de toutes les parties prenantes, ou supposer que chaque segment de clientèle appréciera les bénéfices de la même manière. Selon moi, trier les backlogs et établir des feuilles de route en se basant uniquement sur des feuilles de calcul à plusieurs colonnes, sur le coût du retard ou sur le WSJF est fondamentalement erroné. C'est une faute professionnelle en matière de "Product Management".
Et [https://swkhan.medium.com/why-you-should-avoid-prioritization-frameworks-779a61c0087 Saeed Khan], leader d'opinion en matière de Product Management, d'écrire :
"Vous ne devriez pas donner la priorité aux "fonctionnalités". Oui, j'ai bien dit cela. Les fonctionnalités sont des implémentations liées à des problèmes ou à des opportunités. Vous devriez vous concentrer sur la priorisation des problèmes et des opportunités qui sont liés à des objectifs et des stratégies à un niveau plus élevé. Vous ne devriez pas donner la priorité aux fonctionnalités.
Comme le souligne [https://medium.com/product-manager-hq/what-is-the-best-framework-to-prioritize-what-to-work-on-next-b20c091b1829 Andrea Saez, la priorisation nous fait défaut au niveau le plus élémentaire] :
"Par-dessus tout, les frameworks manquent un aspect fondamental du Product Management : l'empathie".
===Sommes-nous coincés en pleine Paralysie de l'Analyse ?===
Ainsi, lorsque nous nous plaçons dans l'espace de la solution (ou "Output") en donnant la priorité aux fonctionnalités, nous abandonnons notre rôle essentiel de Product Manager.<br/>
<br/>
Nous nous concentrons intrinsèquement et analytiquement sur la planification, plutôt que de donner vie à notre stratégie par le biais de notre produit pour nos utilisateurs finaux.<br/>
<br/>
Car ce qui distingue la stratégie de la planification, c'est la prise de conscience que nous travaillons pour faire avancer quelque chose qui, par nature, échappe à notre contrôle :<br/>
===''Oucomes'' / Résultats===
Un '''résultat''', ou un changement dans le comportement humain, prépare les clients à réussir d'une manière qui leur convient, ainsi qu'à notre entreprise.<br/>
<br/>
Si nous essayons de nous concentrer sur l'obtention de résultats spécifiques en matière de changement de comportement des clients, nous devons travailler à rebours de quelque chose d'autre :<br/>
===Opportunités===
Les opportunités sont les besoins non satisfaits des clients, exprimés avec leurs propres mots.<br/>
<br/>
Ils nous aident à répondre aux questions suivantes :
* Pour qui construisons-nous cette fonctionnalité, afin qu'ils puissent finalement faire quoi ?
* Quels sont les besoins non satisfaits que cette fonctionnalité les aide à satisfaire ?
* Comment cette fonctionnalité est-elle liée aux choix stratégiques de l'entreprise à un niveau plus élevé ?
<br/>
Nous avons donc choisi de prioriser les besoins de nos clients cibles sur les bons canaux et dans les bonnes zones géographiques (nos choix " Où jouer ?"). Pour répondre à ces besoins, nous avons identifié des moyens spécifiques pour les aider à réussir. (Nos choix "Comment gagner ?").<br/>
<br/>
Travailler à rebours à partir du bon problème du client avec les bons choix " Où jouer ?" et " Comment gagner ?" nous aide à comprendre facilement ce qui doit être construit ensuite - aucun framework de priorisation n'est nécessaire.<br/>
<br/>
[[Fichier:Outs opps outcs short FR.png|border|900px|link=]]<br/>
[[Fichier:Outs opps outcs short FR.png|border|900px|link=]]<br/>
<small>''La priorisation s'effectue au niveau des opportunités afin d'obtenir des outcomes et un impact sur l'entreprise par le biais de la stratégie. Image de l'auteur.''</small><br/>
<small>''La priorisation s'effectue au niveau des opportunités afin d'obtenir des outcomes et un impact sur l'entreprise par le biais de la stratégie. Image de l'auteur.''</small><br/>
 
<br/>
----
----
[[Fichier:Outs opps outcs short EN.jpg|border|900px]]
[[Fichier:Outs opps outcs short EN.jpg|border|900px]]