@@ Ligne 1 : / Ligne 1 : @@
 [[Category: Découverte Produit]]
+[[Category: OST]]
 Auteur : Ed Biden<br />
 Source : [https://www.hustlebadger.com/what-do-product-teams-do/how-to-build-an-opportunity-solution-tree/ How to build an Opportunity Solution Tree]<br />
@@ Ligne 22 : / Ligne 23 : @@
 <br/>
 Les arbres opportunité-solution (OST) décrivent :
-* les objectifs métier que vous visez
+* les '''objectifs métier''' que vous visez
-* Les opportunités que vous pouvez exploiter pour atteindre ces objectifs
+* Les '''opportunités''' que vous pouvez exploiter pour atteindre ces objectifs
-* Les solutions que vous pourriez utiliser pour réaliser chaque opportunité
+* Les '''solutions''' que vous pourriez utiliser pour réaliser chaque opportunité
-* Les tests des suppositions que vous pouvez effectuer pour accroître la confiance dans ces solutions.
+* Les '''tests des suppositions''' que vous pouvez effectuer pour accroître la confiance dans ces solutions.
 <br/>
 Il s'agit d ['une autre façon de visualiser votre progression dans la discovery, d'un point de vue légèrement différent du double diamant classique du [https://www.hustlebadger.com/what-do-product-teams-do/design-thinking/ design thinking], et c'est un excellent moyen d'articuler vos [https://www.hustlebadger.com/what-do-product-teams-do/developing-the-pillars-of-your-product-strategy/ axes stratégiques].<br/>
@@ Ligne 40 : / Ligne 41 : @@
 <br/>
 Pour ce faire, ils présentent deux avantages principaux :
-# Lier la réalisation et la discovery aux impacts métiers (“'business outcomes”'). Lorsqu'ils sont lus de haut en bas, les arbres opportunité-solution tracent une ligne directe entre le travail effectué par l'équipe produit (discovery et réalisation) et l'impact métier qu'il soutient. Cela permet à chacun de comprendre pourquoi un élément de travail est important.
+# '''Lier la réalisation et la discovery aux impacts métiers (“'business outcomes”').''' Lorsqu'ils sont lus de haut en bas, les arbres opportunité-solution tracent une ligne directe entre le travail effectué par l'équipe produit (discovery et réalisation) et l'impact métier qu'il soutient. Cela permet à chacun de comprendre pourquoi un élément de travail est important.
-# Priorisation des alternatives - Lorsqu'ils sont lus d'un côté à l'autre, les arbres opportunité-solution vous aident à prioriser les alternatives au même niveau. Par exemple, quelles opportunités devons-nous poursuivre en premier ? Quelles sont les solutions les plus prometteuses ?
+# '''Priorisation des alternatives''' - Lorsqu'ils sont lus d'un côté à l'autre, les arbres opportunité-solution vous aident à prioriser les alternatives au même niveau. Par exemple, quelles opportunités devons-nous poursuivre en premier ? Quelles sont les solutions les plus prometteuses ?
 <br/>
 L'ensemble de ces éléments permet de prendre de meilleures décisions et d'être plus confiant quant à l'action à mener.<br/>
@@ Ligne 47 : / Ligne 48 : @@
 ==Quand utiliser un arbre de solutions d'opportunités==
 Les arbres opportunité-solution sont un excellent outil à utiliser lorsque les conditions suivantes sont réunies :
-* Vous travaillez sur un produit existant : vous devez avoir des opportunités et des solutions à proposer. Si, au contraire, vous travaillez sur un produit créé de toutes pièces, vous essayez de déterminer quelle est votre valeur ajoutée et à quoi pourrait ressembler un MVP raisonnable. Dans ce cas, il est préférable de mener des [https://www.hustlebadger.com/what-do-product-teams-do/qualitative-user-research/ entretiens approfondis avec les utilisateurs] et d'utiliser le design thinking pour aller de l'avant.
+* '''Vous travaillez sur un produit existant''' : vous devez avoir des opportunités et des solutions à proposer. Si, au contraire, vous travaillez sur un produit créé de toutes pièces, vous essayez de déterminer quelle est votre valeur ajoutée et à quoi pourrait ressembler un MVP raisonnable. Dans ce cas, il est préférable de mener des [https://www.hustlebadger.com/what-do-product-teams-do/qualitative-user-research/ entretiens approfondis avec les utilisateurs] et d'utiliser le design thinking pour aller de l'avant.
- * Vous êtes dans une [https://www.hustlebadger.com/what-do-product-teams-do/product-roadmap-templates/ "phase bleue"] : vous devriez travailler avec une équipe autonome et pilotée par les impacts. En revanche, si vous êtes dans une "phase rouge" et que l'on vous demande de fournir une partie d'un projet plus vaste, il est probable que quelqu'un d'autre aura décidé de la solution à mettre en place. Vos principales priorités seront de gérer les délais et les dépendances, plutôt que de faire du travail de discovery supplémentaire.
+* '''Vous êtes dans une [https://www.hustlebadger.com/what-do-product-teams-do/product-roadmap-templates/ "phase bleue"]''' : vous devriez travailler avec une équipe autonome et pilotée par les impacts. En revanche, si vous êtes dans une "phase rouge" et que l'on vous demande de fournir une partie d'un projet plus vaste, il est probable que quelqu'un d'autre aura décidé de la solution à mettre en place. Vos principales priorités seront de gérer les délais et les dépendances, plutôt que de faire du travail de discovery supplémentaire.
 ==Comment construire un arbre opportunité-solution==
 Les arbres opportunité-solution sont construits de manière descendante au départ, et leur construction comporte quatre étapes clés, correspondant aux quatre niveaux différents qu'ils proposent :
-# Impact
+# '''Impact'''
-# Opportunités
+# '''Opportunités'''
-# Solutions
+# '''Solutions'''
-# Tests des suppositions
+# '''Tests des suppositions'''
 Examinons chacun de ces points plus en détail.
@@ Ligne 63 : / Ligne 64 : @@
 <br/>
 Nous aimons utiliser une combinaison (mission + indicateurs) pour définir un impact :
-* Mission : un énoncé inspirant sur ce que vous essayez d'accomplir. Vous pouvez souvent l'interpréter comme votre objectif.
+* '''Mission''' : un énoncé inspirant sur ce que vous essayez d'accomplir. Vous pouvez souvent l'interpréter comme votre objectif.
-* Indicateurs : comment savoir si vous avez atteint votre mission. Les indicateurs doivent servir à mesurer la mission, et non à la définir. Un bon format est le suivant : faire passer [l'indicateur] de [la base de référence] à [cible] d'ici [la date].
+* '''Indicateurs''' : comment savoir si vous avez atteint votre mission. Les indicateurs doivent servir à mesurer la mission, et non à la définir. Un bon format est le suivant : faire passer [l'indicateur] de [la base de référence] à [cible] d'ici [la date].
 <br/>
 Par exemple :
-* Mission : offrir une expérience d'onboarding fluide.
+* '''Mission''' : offrir une expérience d'onboarding fluide.
-* Indicateur : augmenter le taux de réussite du processus d'onboarding de 85 % à 92 % d'ici le 31 mai.
+* '''Indicateur''' : augmenter le taux de réussite du processus d'onboarding de 85 % à 92 % d'ici le 31 mai.
   '''Mission''' : Augmenter notre base d'utilisateurs
@@ Ligne 83 : / Ligne 84 : @@
 ===Cartographier les opportunités===
 Pour comprendre quelles opportunités existent, vous devrez mener plusieurs types de recherches génératives :
-* Entretiens utilisateurs : discuter directement avec les utilisateurs pour comprendre leur vision du monde et leur expérience.
+* '''Entretiens utilisateurs''' : discuter directement avec les utilisateurs pour comprendre leur vision du monde et leur expérience.
-* Analyse comportementale : explorer les données dont vous disposez sur les utilisateurs pour identifier des tendances.
+* '''Analyse comportementale''' : explorer les données dont vous disposez sur les utilisateurs pour identifier des tendances.
-* Cartographie des processus : visualiser les processus et les flots utilisateurs pour comprendre tous les points de contact et toutes les interactions.
+* '''Cartographie des processus''' : visualiser les processus et les flots utilisateurs pour comprendre tous les points de contact et toutes les interactions.
-* Experts du domaine : obtenir la contribution des parties prenantes et d'autres personnes qui connaissent très bien le domaine.
+* '''Experts du domaine''' : obtenir la contribution des parties prenantes et d'autres personnes qui connaissent très bien le domaine.
 <br/>
 Cette approche est très similaire à la manière dont vous étudieriez l'espace du problème dans le cadre du design thinking.<br/>
@@ Ligne 110 : / Ligne 111 : @@
 <br/>
 Quatre grandes catégories d'activités peuvent vous aider à prioriser les opportunités :
-# Évaluation de l'opportunité : créer un modèle d'impact pour comprendre dans quelle mesure cette opportunité pourrait contribuer à l'impact que vous visez.
+# '''Évaluation de l'opportunité''' : créer un modèle d'impact pour comprendre dans quelle mesure cette opportunité pourrait contribuer à l'impact que vous visez.
-# Facteurs liés aux clients : comprendre combien d'utilisateurs seraient concernés par cette opportunité (c'est-à-dire le ''reach''/la portée/l'incidence) et quelle importance elle revêt pour eux (c'est-à-dire la gravité).
+# '''Facteurs liés aux clients''' : comprendre combien d'utilisateurs seraient concernés par cette opportunité (c'est-à-dire le ''reach''/la portée/l'incidence) et quelle importance elle revêt pour eux (c'est-à-dire la gravité).
-# Facteurs liés à l'entreprise : comprendre les implications métiers/affaires plus larges et l'alignement avec la mission, la vision et la stratégie globales de votre entreprise.
+# '''Facteurs liés à l'entreprise''' : comprendre les implications métiers/affaires plus larges et l'alignement avec la mission, la vision et la stratégie globales de votre entreprise.
-# Facteurs liés au marché : évaluer comment le fait d'adresser cette opportunité affecterait la position de votre produit sur le marché.
+# '''Facteurs liés au marché''' : évaluer comment le fait d'adresser cette opportunité affecterait la position de votre produit sur le marché.
 <br/>
 L'effort ne fait pas partie de cette priorisation, car nous n'évaluons pas encore les solutions. Nous ne voulons pas préjuger de la difficulté à adresser une opportunité avant d'avoir eu l'occasion de générer diverses options. Même si les opportunités dont nous partons peuvent nécessiter beaucoup d'efforts, une solution simple et efficace peut apparaître assez facilement si nous savons qu'il s'agit de l'opportunité clé sur laquelle travailler.<br/>
@@ Ligne 142 : / Ligne 143 : @@
 [https://www.hustlebadger.com/what-do-product-teams-do/discovery/ Quelle est la quantité suffisante de discovery ?]. Cela dépend d'un certain nombre de facteurs, tels que :
-* Le coût de développement : le temps et l'argent nécessaires pour  construire la solution
+* '''Le coût de développement''' : le temps et l'argent nécessaires pour  construire la solution
-* Le scénario pessimiste : le degré de gravité du pire scénario possible
+* '''Le scénario pessimiste''' : le degré de gravité du pire scénario possible
-* La maturité et la culture de l'entreprise : les enjeux (par exemple, les revenus) et notre culture de prise de décision
+* '''La maturité et la culture de l'entreprise''' : les enjeux (par exemple, les revenus) et notre culture de prise de décision
-* Le coût d'opportunité : ce que nous pourrions construire à la place
+* '''Le coût d'opportunité''' : ce que nous pourrions construire à la place
 <br/>
 Mais c'est aussi une question de temps. Dans un monde idéal, vous avez renforcé votre confiance au-delà des risques que vous voyez dans une fonctionnalité au moment où elle atteint le haut du backlog. Si ce n'est pas le cas, vous devez alors décider si vous souhaitez la diffuser quand même ou occuper votre temps d'une autre manière (par exemple, en travaillant sur des bugs ou la dette technique).<br/>
@@ Ligne 156 : / Ligne 157 : @@
 <br/>
 Chaque fois que vous lancez une nouvelle solution, vous faites un pari qui, vous l'espérez, créera de la valeur pour l'entreprise ou les utilisateurs. Quatre types de risques contribuent aux chances globales de réussite d'une solution :
-* Risque lié à la valeur : les clients veulent-ils vraiment cette solution ? l'apprécient-ils à sa juste valeur ?
+* '''Risque lié à la valeur''' : les clients veulent-ils vraiment cette solution ? l'apprécient-ils à sa juste valeur ?
-* Risque lié à la facilité d'utilisation : les utilisateurs peuvent-ils comprendre cette solution ? savent-ils comment elle fonctionne ?
+* '''Risque lié à la facilité d'utilisation''' : les utilisateurs peuvent-ils comprendre cette solution ? savent-ils comment elle fonctionne ?
-* Risque technique : pouvons-nous développer cette solution ? est-elle évolutive, sécurisée et fiable ?
+* '''Risque technique''' : pouvons-nous développer cette solution ? est-elle évolutive, sécurisée et fiable ?
-* Risque de viabilité : l'entreprise peut-elle fournir ce produit ? cela crée-t-il une complexité opérationnelle ? est-ce légal ?
+* '''Risque de viabilité''' : l'entreprise peut-elle fournir ce produit ? cela crée-t-il une complexité opérationnelle ? est-ce légal ?
 <br/>
 [[Fichier:OSTs risks.png|border|link=|600px]]<br/>
@@ Ligne 166 : / Ligne 167 : @@
 <br/>
 Deux frameworks vous aident à réfléchir à cette question :
-# Cartographie des suppositions : identification et priorisation des composantes du risque pour une solution.
+# '''Cartographie des suppositions''' : identification et priorisation des composantes du risque pour une solution.
-# Tests itératifs : augmentation systématique de la confiance dans la solution globale.
+# '''Tests itératifs''' : augmentation systématique de la confiance dans la solution globale.
 ===Cartographie des suppositions===
@@ Ligne 199 : / Ligne 200 : @@
 [[Fichier:OSTs Tests itératifs.png|border|link=|700px]]<br/>
 <br/>
+La confiance dans une solution ne vient pas d'un seul coup, et il est rare d'avoir une certitude absolue sur une hypothèse donnée. Dans la plupart des cas, la confiance dans une solution se construit au fil du temps, en effectuant des tests successifs, chacun d'entre eux renforçant votre confiance, mais nécessitant plus de temps et d'argent.<br/>
+<br/>
+Par exemple, si vous essayez de réduire le risque technique :
+* Une conversation avec votre responsable technique pour savoir si cela est théoriquement possible peut prendre quelques minutes.
+* Le responsable technique qui examine le code pour vérifier quelques éléments peut prendre une heure.
+* Un spike technique peut être limité à un ou deux jours.
+<br/>
+Et si vous essayez de réduire le risque lié à l'utilisabilité :
+* Obtenir les feedbacks de votre équipe sur une maquette peut prendre quelques minutes.
+* Obtenir les commentaires d'une poignée d'utilisateurs réels sur un prototype de haut niveau peut prendre des heures.
+* Obtenir les feedbacks d'un grand nombre d'utilisateurs réels nécessitera probablement un prototype détaillé ou un MVP, dont la création peut prendre des jours, voire des semaines.
+<br/>
+Vous ne voulez pas vous engager dans le MVP avant d'avoir obtenu les feedbacks de votre équipe. Mais les feedbacks de votre équipe ne suffisent pas à eux seuls à justifier la création de la fonctionnalité.<br/>
+<br/>
+Il faut plutôt considérer les différents types de preuves comme appartenant à une hiérarchie :<br/>
+<br/>
+[[Fichier:OSTs Hustle Badger confidence scale.jpg|link=|border|600px]]<br/>
+<small>''[https://www.hustlebadger.com/what-do-product-teams-do/joe-tinston/ Échelle de confiance] Hustle Badger''</small><br/>
+<br/>
+Vous progressez pas à pas dans cette échelle, en testant les suppositions principales à tous les niveaux ou presque :<br/>
+<br/>
+[[Fichier:OSTs levels.png|border|link=|800px]]<br/>
+. Plusieurs idées issues de la session d'idéation, que le PM priorise afin de les approfondir avec l'équipe.
+. Feedbacks sur le wireframe présenté aux utilisateurs. Les enseignements tirés sont réintégrés dans l'ensemble des conceptions et du séquençage.
+. Une idée particulière reçoit un bon feedback des clients, l'équipe convertit donc le wireframe en prototype.
+. Le prototype présente quelques problèmes d'utilisabilité, l'équipe effectue donc plusieurs itérations pour les résoudre.
+. Les données du test A/B sont positives, l'équipe déploie donc la fonctionnalité auprès de tous les utilisateurs.
+Au fur et à mesure, vous répertoriez vos principales suppositions et votre niveau global de confiance dans chacune d'elles dans votre arbre opportunité-solution. Pour chaque supposition de votre arbre opportunité-solution, vous n'essayez pas d'effectuer des tests ni d'atteindre directement le niveau de confiance le plus élevé possible. Ces deux approches vous conduiraient à effectuer des tests longs et coûteux alors que vous auriez pu découvrir les problèmes beaucoup plus rapidement et à moindre coût.<br/>
+<br/>
+Au lieu de cela, vous essayez de comprendre le profil de risque global d'une fonctionnalité à travers les quatre catégories de risque (valeur, utilisabilité, technique et métier) et de planifier la prochaine étape logique, car elle augmente votre confiance avec un minimum d'efforts.<br/>
+===Répondre aux tests des suppositions===
+Chaque fois que vous effectuez un test, vous recueillez des preuves concernant vos hypothèses. La suite dépendra du fait que ces preuves corroborent ou non votre hypothèse :
+* '''Supposition corroborée''' : investissez dans des tests plus poussés ou développez un produit réel
+* '''Preuves non concluantes''' : intégrez les enseignements tirés et refaites le test
+* '''Supposition rejetée''' : dépriorisez cette solution par rapport aux autres dans votre OST afin de vous donner le temps de la repenser.
+==Problèmes courants==
+L'un des principaux avantages de l'utilisation des arbres opportunité-solution est qu'ils permettent de visualiser certaines erreurs courantes dans la discovery, ce qui les rend plus faciles à repérer et à éviter.<br/>
+<br/>
+Passons en revue quelques-unes de ces erreurs, ainsi que les tactiques que vous pouvez utiliser si vous êtes confronté à l'un de ces problèmes.<br/>
+===Solutions non liées aux impacts===
+Les opportunités que vous adressez et les solutions que vous élaborez n'auront pas d'incidence significative sur l'impact que vous souhaitez obtenir. Ou vous n'avez même pas défini l'impact que vous recherchez.<br/>
+<br/>
+[[Fichier:OSTs no impact.png|border|link=|800px]]<br/>
+====Solution====
+Avant toute chose, essayez de définir vous-même l'impact souhaité en fonction du contexte métier dans lequel vous évoluez. Partagez ensuite cette définition avec vos principales parties prenantes afin de recueillir leur avis et de vous mettre d'accord avec elles. Si vous obtenez des réponses différentes de la part des différentes parties prenantes, ne vous opposez pas directement à elles. Réunissez tout le monde dans la même pièce et animez une discussion sur ce qui est réellement le plus important à faire.<br/>
+<br/>
+Vous ne pouvez pas gagner si tout le monde attend de vous que vous fassiez des choses différentes, et si vous n'avez pas de résultat clairement défini, c'est pratiquement garanti.<br/>
+===Impacts multiples et contradictoires===
+Vous vous dispersez entre plusieurs impacts, ce qui se traduit par un manque de concentration dans votre travail. Cela peut arriver très facilement si vous utilisez des [https://www.hustlebadger.com/what-do-product-teams-do/okr-template/ OKR] et avez défini plusieurs résultats clés qui vous mènent dans des directions différentes (plutôt que d'être différentes façons d'exprimer un seul objectif).<br/>
+<br/>
+[[Fichier:OSTs Multiple competing outcomes.png|border|link=|800px]]<br/>
+====Solution====
+Si vous définissez vos propres objectifs, déterminez lequel est le plus important et mettez les autres de côté. Les progrès sont inversement proportionnels au nombre de priorités que vous avez, vous devez donc limiter autant que possible le nombre d'objectifs à un seul.<br/>
+<br/>
+Cela dit, il n'est pas toujours possible de faire comprendre aux parties prenantes les inconvénients d'avoir trop d'objectifs concurrents. Si vous le pouvez, demandez-leur de classer les objectifs par ordre d'importance afin de savoir sur quoi vous concentrer et d'avoir une indication sur la proportion de votre temps qu'ils attendent de vous pour atteindre un objectif donné. Cela fonctionne mieux lorsque vous convertissez ce pourcentage théorique en jours/semaines.
+ « D'accord, vous voulez donc que nous consacrions 50% de notre temps à améliorer la recherche, puis 25% à examiner le processus de paiement et de onboarding.
+ Cela signifie donc que nous consacrerons 6 semaines à la recherche et 3 semaines au paiement et à l'onboarding. »
+Vous pouvez souligner l'intérêt de se concentrer sur un nombre réduit de sujets en leur rappelant le temps qu'il a fallu pour mettre en place certaines fonctionnalités par le passé (qui est presque toujours plus long que ce que les gens imaginent).<br/>
+===Un manque d'alternatives===
+Vous n'avez aucune alternative, que ce soit au niveau des opportunités, des solutions ou les deux. Cela se produit lorsque vous n'avez pas effectué suffisamment de recherches génératives pour découvrir davantage de problèmes rencontrés par les utilisateurs, ou suffisamment de réflexion pour créer davantage de solutions potentielles. Sans alternatives, vous ne pouvez pas savoir si vous vous concentrez sur le travail de plus grande valeur, car vous n'avez rien à quoi le comparer.<br/>
+<br/>
+[[Fichier:OSTs Lack of alternatives.png|border|link=|250px]]<br/>
+====Solution====
+Allez sur le terrain et discutez avec les utilisateurs pour comprendre quels autres problèmes ils rencontrent. Organisez une [https://www.hustlebadger.com/what-do-product-teams-do/ideation-session/ session d'idéation] pour trouver d'autres solutions potentielles. Vous pouvez le faire tout en continuant à travailler sur la seule opportunité/solution dont vous avez connaissance pour le moment, cela ne vous ralentira pas.<br/>
+<br/>
+À mesure que vous en apprendrez davantage sur les alternatives, vous pourrez alors vous tourner vers des sujets à plus fort impact si vous en trouvez, ou vous serez convaincu que vous travaillez déjà sur les sujets les plus importants.<br/>
+===Trop de solutions / tests de suppositions===
+Vous avez beaucoup trop de solutions ou de tests de suppositions à gérer. Vous vous perdez dans les détails. Cela peut arriver lorsque vous recevez beaucoup de demandes provenant d'autres équipes et de clients. La cause racine est généralement que votre stratégie n'est pas assez solide : vous ne disposez pas d'un filtre de haut niveau efficace pour éliminer les mauvaises idées.<br/>
+<br/>
+[[Fichier:OSTs Too many solutions and assumption tests.png|border|link=|800px]]<br/>
+====Solution====
+Cessez un instant de regarder votre backlog et votre arbre opportunité-solution, et prenez une feuille de papier vierge. À votre avis, qu'est-ce qui ferait vraiment bouger les choses ? Et pourquoi pensez-vous cela ?<br/>
+<br/>
+Le travail sur les produits est basé sur des hypothèses. Autrement dit, vous ne devez pas proposer une multitude d'idées pour ensuite décider quoi faire, mais plutôt avoir une idée de ce qu'il faut faire, puis la faire évoluer à mesure que vous obtenez davantage de preuves. Si vous n'avez pas d'hypothèse de départ, vous finirez par être paralysé par une liste interminable de discovery à faire pour déterminer sur quoi travailler.<br/>
+<br/>
+Si vous avez besoin d'aide pour élaborer une hypothèse stratégique, consultez notre modèle de [https://www.hustlebadger.com/what-do-product-teams-do/creating-a-strategy-development-plan/ stratégie éclair].<br/>
+===Mélanger solutions et opportunités===
+Vous confondez solution et opportunité. Vous ne savez pas si les clients apprécieront votre solution et vous n'avez pas envisagé d'alternatives. Cela peut arriver lorsque vous (ou une partie prenante) êtes tellement convaincu par une solution que vous essayez de la présenter comme une opportunité afin de vous assurer qu'elle soit adoptée. Et il est assez facile de le faire inconsciemment, sans même se rendre compte de l'erreur que l'on commet.<br/>
+<br/>
+[[Fichier:OSTs Mixing solutions and opportunities.png|border|link=|700px]]<br/>
+====Solution====
+Le test consiste ici à vous demander : « De quelles différentes manières pourrais-je aborder cette opportunité ? ». S'il n'y a qu'une seule façon de la traiter, alors il s'agit d'une solution. Les opportunités peuvent faire l'objet de multiples solutions.
+Prenons les deux exemples suivants :
+# « Je souhaite filtrer ma recherche par couleur » → la seule approche ici consiste à créer un filtre de couleur, il s'agit donc d'une solution.
+# « Je souhaite obtenir de meilleurs résultats de recherche » → vous pourriez créer un filtre par couleur, personnaliser les résultats, modifier l'algorithme de tri... Il existe de nombreuses solutions potentielles à cette affirmation, il s'agit donc d'une opportunité.
+Si vous travaillez sur une solution et que vous ne savez pas quelle est l'opportunité, posez-vous la question suivante : « Pourquoi est-ce important ? » La réponse sera probablement l'opportunité que vous recherchez.
+==Résumé==
+ Arbre opportunité-solution : [https://miro.com/miroverse/opportunity-solution-tree-canvas/ Miro]
+Les arbres de solutions d'opportunités (OST) sont une technique visuelle puissante qui permet de cartographier vos découvertes. Ils vous aident à relier les expériences et les fonctionnalités à des résultats commerciaux plus larges, ainsi qu'à hiérarchiser les tâches les plus importantes à accomplir.<br/>
+<br/>
+Les arbres de solutions d'opportunités comportent quatre niveaux principaux :
+* '''Impact''' : l'impact que vous visez
+* '''Opportunités''' : les défis que vous pouvez relever pour atteindre votre résultat
+* '''Solutions''' : réponses potentielles aux opportunités que vous avez identifiées
+* '''Tests de suppositions''' : moyens d'accroître votre confiance dans l'efficacité de votre solution
+<br/>
+Vous pouvez créer un arbre opportunité-solution après avoir mené quelques entretiens avec des utilisateurs afin de vous aider à cartographier l'espace. Ensuite, vous devez vous baser sur des hypothèses, cartographier votre réflexion actuelle dès que possible, puis mettre à jour votre arbre au fur et à mesure que vous recueillez davantage d'informations.

Anonyme

Rechercher

« Comment construire un Arbre Opportunité-Solution » : différence entre les versions

Navigation

Outils wiki

Outils de la page

« Comment construire un Arbre Opportunité-Solution » : différence entre les versions