Voir la source de Tableau périodique des techniques de priorisation produit

[[Category: Portail Product Owner]]
[[Category: Portail Planification]]
[[Category: Daniel Zacarias]]
Auteur : Daniel Zacarias<br />
Source : [https://foldingburritos.com/product-prioritization-techniques/ 20 Product Priorization Techniques: A Map and Guided Tour]<br />
----
Traducteur : Fabrice Aimetti<br />
Date : 07/08/2017<br />
----
Traduction :<br />
<br />
__NOTOC__
== Introduction ==
'''La priorisation est une préoccupation majeure pour la plupart des Chefs de Produit''' (NdT : ''Product Managers''). C'est de loin l'un des sujets les plus populaires sur les blogs de gestion de produits, les foires aux questions et les autres communautés en ligne.<br/>
<br/>
Même si '''''ce n'est pas ce pourquoi nous avons été recrutés''''', c'est '''quelque chose que nous ''devons'' faire''' pour atteindre notre véritable objectif : créer des produits réussis qui apportent de la valeur à nos clients et à l'entreprise.<br/>
<br/>
Le besoin de prioriser vient d'un fait très simple : '''nous n'avons tout simplement pas assez de ressources''' pour [https://www.mironov.com/4laws1/ travailler sur tous les sujets que nous découvrons].<br/>
<br/>
Nous avons donc besoin d'un processus pour déterminer les ensembles (et la séquence) de choses à faire sur le produit pour fournir le plus de valeur à chaque instant, compte tenu de nos contraintes.<br/>
<br/>
Si nous analysons ce dernier énoncé, il faut alors répondre à un groupe de questions:<br/>
* Comment pouvons-nous savoir ce qui a de la valeur ? Comment estimer sa valeur ? Qui a de la valeur pour qui ?
* Comment pouvons-nous définir l'ensemble des éléments qui devraient être regroupés dans une version produit ? Comment devrions-nous séquencer ces versions ?
* Comment pouvons-nous obtenir le support nécessaire pour mener à bien ces projets et les mettre à disposition du marché ?
* Comment pouvons-nous savoir si nos hypothèses sont exactes ? Sommes-nous sur la bonne voie ? Livrons-nous vraiment de la valeur ? Pouvons-nous faire mieux ?
<br/>
== De quoi parle ce guide / panorama ? ==
Si vous effectuez des recherches, vous trouverez d'innombrables articles avec des recommandations, des techniques et des approches pour traiter ce problème très difficile. Cependant, l'utilité de chaque méthode dépendra du produit ou projet spécifique dans son contexte. Vos besoins de priorisation peuvent varier considérablement.<br/>
<br/>
Voici ce que vous obtiendrez de ce panorama couvrant 20 techniques populaires de priorisation des produits :<br/>
* '''Une carte, sous la forme d'un ''Tableau périodique''''' pour vous aider à comprendre ce que chaque technique a à offrir ;
* '''Un aperçu de chaque méthode''', avec des schémas et des '''liens vers des ressources plus approfondies''';
* '''5 points communs et points importants à retenir de toutes ces méthodes.'''<br/>
<br/>

==  Tableau périodique des techniques de priorisation produit ==
Lorsque j'ai commencé à travailler sur ce guide, j'ai immédiatement ressenti le besoin d'organiser visuellement toutes ces techniques de manière logique et de montrer le contexte dans lequel chacune d'elles apporte une valeur ajoutée.<br/>
<br/>
Dans cette optique, j'ai trouvé deux dimensions qui répondaient à ce besoin et le résultat obtenu fut la sorte de '''''tableau périodique''''' que vous voyez ci-dessous[1].<br/>
<br/>
[[Image:periodic-table_fr.png|periodic-table_fr.png|700px|border|LE TABLEAU PÉRIODIQUE DES TECHNIQUES DE PRIORISATION PRODUIT|link=]]<br/>© Daniel Zacarias - Folding Burritos<br />
<br/>
L'axe horizontal indique '''dans quelle mesure la méthode se base plus ou moins sur des apports  issus du monde interne ou du monde externe'''. En d'autres termes, de quelle manière elle dépend des données et des opinions de personnes externes à l'équipe noyau qui développe le produit. (NdT : Interne < Vous < Equipe < Parties prenantes < Clients < Externe)<br/>
<br/>
Cette dimension reflète le fait que vous avez parfois besoin de la participation de l'extérieur (par exemple, les clients finaux ou les parties prenantes de l'entreprise) pour vous aider à établir des priorités. Cependant, dans d'autres cas, vous souhaiterez suivre un processus plus simple avec l'équipe de développement ou par vous-même.<br/>
<br/>
L'axe vertical indique '''dans quelle mesure la méthode est plus ou moins quantitative'''. Autrement dit, de quelle manière elle dépend d'opinions (personnelles) d’experts plutôt que d'autres types d'indicateur, de classification, de vote ou de classement.<br/>
<br/>
Certaines personnes sont plus à l'aise avec les approches quantitatives et s'appuient sur des chiffres (pour elles-mêmes ou pour les personnes "plus haut placées"). Dans d'autres cas, vous devez travailler sur le plan qualitatif si ce que vous essayez de réaliser n'a pas de sens dans votre contexte.<br/>
<br/>
Chaque technique a été placée dans le tableau en tenant compte de ce que je crois être leurs positions relatives selon ces deux dimensions. Le placement individuel peut être discutable, mais je pense que c'est un bon point de départ pour les parcourir[2].<br/>
<br/>
La section suivante présente un aperçu de chaque technique, ainsi que des références vers d'autres ressources pertinentes et approfondies.<br/>
<br/>
== Panorama des techniques de priorisation des produits ==
=== Techniques externes & quantitatives ===
==== [[Modèle_de_Kano_(technique_externe_et_quantitative)|Modèle de Kano (fr)]] ====
==== [[Déploiement_des_Fonctions_Qualités_(technique_externe_et_quantitative)|Déploiement des Fonctions Qualités (fr)]] ====
==== [[Notation_des_Opportunités_(technique_externe_et_quantitative)|Notation des Opportunités (fr)]] ====
==== [[Buy_a_Feature_(technique_externe_et_quantitative)|Buy a Feature (fr)]] ====
<br/>
=== Techniques externes & qualitatives ===
==== [[Story_Mapping_(technique_externe_et_qualitative)|Story Mapping (fr)]] ====
==== [[MoSCoW_(technique_externe_et_qualitative)|MoSCoW (fr)]] ====
==== [[Prune_the_Product_Tree_(technique_externe_et_qualitative)|Prune the Product Tree (fr)]] ====
==== [[Speed_Boat_(technique_externe_et_qualitative)|Speed Boat (fr)]] ====
<br/>
=== Techniques internes & quantitatives ===
==== [[Analyse_Financière_(technique_interne_et_quantitative)|Analyse Financière (fr)]] ====
==== [[Cadre_de_Ian_McAllister_(technique_interne_et_quantitative)|Cadre de Ian McAllister (fr)]] ====
==== [[Impact_sur_l%27Objectif_Métier_(technique_interne_et_quantitative)|Impact sur l'Objectif Métier (fr)]] ====
==== [[Valeur_vs_Risque_(technique_interne_et_quantitative)|Valeur vs Risque (fr)]] ====
==== [[Valeur_vs_Coût_(technique_interne_et_quantitative)|Valeur vs Coût (fr)]] ====
==== [[Feuille_de_Scores_(technique_interne_et_quantitative)|Feuille de Scores (fr)]] ====
==== [[Sélection_de_Thèmes_(technique_interne_et_quantitative)|Sélection de Thèmes (fr)]] ====
<br/>

=== Techniques internes & qualitatives ===
==== [[Ordre_de_Classement_(technique_interne_et_qualitative)|Ordre de Classement (fr)]] ====
==== [[Modèle_Systemico_(technique_interne_et_qualitative)|Modèle Systemico (fr)]] ====
==== [[Classement_en_Piles_(technique_interne_et_qualitative)|Classement en Piles]] ====
==== [[Seaux_à_Fonctionnalités_(technique_interne_et_qualitative)|Seaux à Fonctionnalités (fr)]] ====
==== [[Méthode_KJ_(technique_interne_et_qualitative)|Méthode KJ (fr)]] ====
<br/>

== 5 points à retenir ==
Après avoir parcouru toutes ces techniques, vous aurez probablement remarqué qu’'''elles ont chacune plusieurs contextes dans lesquels elles peuvent être utilisées et d’autres dans lesquels elles ne le peuvent pas'''. Pour autant que nous le souhaitions, il n’y a pas de recette miracle pour prioriser et nous devons choisir ce qui convient le mieux à notre produit, à notre équipe, à notre secteur d'activité, etc. En même temps, il existe des points communs importants qui méritent d’être soulignés.<br/>
<br/>
Passons en revue '''les points les plus importants''' de cette tâche fascinante que nous appelons la ''Priorisation''.
<br/>
=== 1. Prioriser à haut niveau ===
'''Toutes les méthodes de priorisation fonctionnent essentiellement avec des caractéristiques produit (''thèmes'') et des objectifs utilisateur de haut niveau'''. Ceci est important pour deux raisons :<br/>
* L'accent est mis sur le fait de fournir de la valeur à l'utilisateur et non d'entrer dans les détails (du moins au début) ;
* Vous ne perdez plus autant de temps si / quand la stratégie change ;
* Après avoir défini la stratégie et les priorités de haut niveau, l’équipe doit s’attacher à trouver les meilleures tactiques pour y parvenir.<br/>
=== 2. Fixer des objectifs, mesurer et ajuster ===
Une autre caractéristique commune à ces nombreuses techniques est leur intérêt pour l'efficacité. Elles reposent sur l'idée que notre motivation à prioriser est que nous visons un objectif avec un effet mesurable (impact, retour sur investissement, utilisation, amélioration des indicateurs métiers, etc.).<br/>
<br/>
'''L'objectif n'est pas de définir des priorités et de les transmettre'''. L'objectif est de '''toujours savoir si ce que nous faisons apporte réellement de la valeur et se déroule comme prévu'''. Quand ce n'est pas le cas, nous aurons au moins quelques indices sur ce qui doit être ajusté.<br/>
=== 3. Ne le faites pas seul ===
'''La priorisation ne devrait pas être un effort solitaire'''. À l'exception de méthodes très simples, presque toutes impliquent quelqu'un d'autre dans le processus. Qu'il s'agisse de clients, de parties prenantes ou de membres d'une équipe, il est très rare que le Product Manager seul définisse les priorités globales. '''Nous sommes juste en charge d'un processus''' et le produit [http://blog.cauvin.org/2011/12/who-owns-product.html appartient à l'équipe].<br/>
<br/>
Obtenir le plus d’informations possible de l'extérieur nous permet d’acquérir la confiance nécessaire dans le fait que ce qui sera priorisé aura effectivement de la valeur. Et même alors, nous n'en devenons certains qu'après avoir mesuré les résultats réels.<br/>
=== 4. Quantitatif vs Qualitatif ===
'''Quantitatif ne signifie pas meilleur que qualitatif (et vice-versa)'''. Par exemple, un piège classique lorsque nous utilisons les méthodes de priorisation quantitative, c'est que les personnes accordent aux chiffres de la précision et de la confiance. En voyant les formules, les ratios et les classements, nous nous sentons généralement plus sûrs de la robustesse et de l’objectivité de certains types d’analyse, mais ceux-ci peuvent être manipulés. Vous devez garder cela à l'esprit, à la fois pour vous-même et lors de la présentation des résultats à d'autres personnes. Ce sont des points de repère / orientations et non des résultats infaillibles.<br/>
<br/>
Soyez bien conscient de ce que vous pouvez sortir de ces méthodes et quand les utiliser. Ce sont des outils, pas des oracles.<br/>
=== 5. Externe vs Interne ===
La distinction entre Externe et Interne que nous avons utilisée dans ce panorama concerne le niveau de participation externe au processus de priorisation. Le niveau de participation ressemble donc à quelque chose comme ça : Vous < Équipe < Parties prenantes < Clients.<br/>
<br/>
Encore une fois, tout dépend des résultats que vous essayez d’obtenir. J'ai personnellement trouvé utile d'y réfléchir en ces termes :<br/>
* Les '''techniques externes''' sont meilleures pour prioriser les '''résultats abstraits''' ;
* Les '''techniques internes''' sont meilleures pour prioriser les '''solutions concrètes'''.
<br/>
==== La valeur des techniques Externes ====
De manière générale, les techniques externes sont plus utiles lorsque vous essayez de naviguer parmi un grand nombre de caractéristiques produit candidates, en cherchant à :<br/>
* Identifier les plus intéressantes pour vos clients - en connaissant leurs attentes de base, proportionnelles, et aussi ce qui les ravit (cf. [[Modèle_de_Kano_(technique_externe_et_quantitative)|Modèle de Kano (fr)]]);
* Obtenir l'adhésion et le consensus d'un groupe de parties prenantes clés dans des grandes organisations ;
* Evaluer les caractéristiques qui n'apportent pas de valeur ou qui déplaisent vraiment aux clients afin que vous puissiez décider de les améliorer ou de les supprimer.
* Faire participer les clients en tant que consultants sur les projets pour leur faire approuver la stratégie de développement et le plan de version.
<br/>
Comme vous traitez principalement avec "le monde extérieur", il est tout à fait naturel que les discussions et la priorisation se produisent à un niveau plus abstrait quant aux résultats, objectifs et caractéristiques de haut niveau espérés par les utilisateurs.<br/>

==== La valeur des techniques Internes ====
C'est parce que vous impliquez des personnes plus proches du produit et de la technologie que ces techniques sont les meilleures pour établir des priorités sur des problèmes plus concrets. Autrement dit, elles sont moins exploratoires puisque les utilisateurs finaux sont moins impliqués (le cas échéant). Ainsi, elles fonctionneront mieux chaque fois que vous devrez :<br/>
* Affiner davantage les résultats obtenus à partir de l'une des techniques ''externes'' ;
* Donner la priorité à un ensemble de caractéristiques produit et d’idées qui, selon vous, sont alignées sur la stratégie du produit et les attentes des clients ;
* Travailler sur des projets internes sans beaucoup (ou pas) de contact avec le marché;
* Prioriser rapidement les caractéristiques produit et les exigences de bas niveau.
<br/>
== Conclusion ==
Avec toutes ces techniques et ces conseils en votre possession, c'est maintenant à vous de décider. Mélangez-les et associez-les. Faites des changements. Mais surtout, '''sortez de l'entreprise et construisez de superbes produits'''.<br/>
<br/>
Si vous l'avez fait jusqu'à maintenant et que vous avez trouvé ce guide / panorama utile, ce serait génial si vous pouviez le partager avec des amis et des collègues qui pourraient peut-être aussi l'apprécier. Donc, si vous avez des commentaires ou des questions, [https://mail.google.com/mail/?view=cm&fs=1&tf=1&to=daniel@foldingburritos.com contactez-moi].

== Références ==
[1] Consultez [https://medium.com/design-of-a-technology-business/ultimate-guide-to-product-prioritization-b08c18d5c00f ces] [http://www.uxmatters.com/mt/archives/2013/12/the-best-ways-to-prioritize-products-and-features.php articles] et cette [http://pt.slideshare.net/tarangbaxi/prioritization-techniques-for-agile-teams présentation] si vous souhaitez en savoir plus sur ce sujet et obtenir différents aperçus sur les méthodes de priorisation.<br/>
<iframe src="https://www.slideshare.net/slideshow/embed_code/key/jsfukXik6tI6HZ" width="595" height="485" allowfullscreen /><br/>
[2] Mais [https://mail.google.com/mail/?view=cm&fs=1&tf=1&to=daniel@foldingburritos.com contactez-moi] si vous avez des suggestions de modification.<br/>
[3] Noriaki Kano et al., “Attractive Quality and Must-be Quality,” research summary of a presentation given at Nippon QC Gakka: 12th Annual Meeting (1982), January 18, 1984<br/>
[4] Je suis aussi un grand fan de la façon dont Kathy Sierra [http://foldingburritos.com/articles/2015/04/19/book-review-badass-making-users-awesome/ définit cette idée].<br/>
[5] Cela semble trivial, mais cette réalité est difficile à accepter pour certains non-techniciens.<br/>
[6] Le "Thème" est un terme courant dans les méthodologies agiles, il représente un ensemble de fonctionnalités majeures (epics), elles-mêmes composées de user stories. En savoir plus à ce sujet [https://www.mountaingoatsoftware.com/blog/stories-epics-and-themes ici].<br/>
[7] Lisez [http://pragmaticmarketing.com/resources/why-prioritizing-your-agile-backlog-for-roi-doesnt-work?p=0 cet article] de Luke Hohmann pour une vision à contre-courant de l'analyse économétrique et de la priorisation.<br/>
[8] Jetez un coup d'oeil à la diapositive 9 de cette présentation de Raviv Turner "The Product Mentor" pour une référence à la priorisation avec les indicateurs AARRR.<br/>
<iframe src="https://www.slideshare.net/slideshow/embed_code/key/60DRMdOtOedh0N" width="595" height="485" allowfullscreen /><br/>
[9] Aussi appelé Indicateurs Pirates, car vous connaissez le [http://www.pirateglossary.com/phrases/ Arrr !]<br/>
[10] Teresa Torres a rédigé une série d'articles expliquant comment [http://www.producttalk.org/2014/01/how-to-set-goals-that-drive-product-success/ déterminer les objectifs] à atteindre et comment [https://www.producttalk.org/2014/03/how-you-build-matters-finding-your-mvp/ "distiller" ces caractéristiques] [http://www.producttalk.org/2014/03/practice-defining-your-mvp/ à un niveau] où vous pouvez travailler dessus en tenant compte de vos contraintes.<br/>
[11] Avec sa part de [http://blog.cauvin.org/2015/08/why-spreadsheets-suck-for-prioritizing.html détracteurs].<br/>
[12] Depuis sa publication initiale, Adam a mis à jour la technique pour inclure un quatrième seau pour les fonctionnalités ''Stratégiques''.<br/>
[13] La "Méthode KJ" est également appelée "Technique KJ" et [https://en.wikipedia.org/wiki/Affinity_diagram "Diagramme d'Affinité"].