« Comment construire un Arbre Opportunité-Solution » : différence entre les versions
De Wiki Agile
| Ligne 127 : | Ligne 127 : | ||
<small>''Les solutions découlent des opportunités dans l'OST''</small><br/> | <small>''Les solutions découlent des opportunités dans l'OST''</small><br/> | ||
<br/> | <br/> | ||
Vous ne pouvez pas créer de valeur sans diffuser de solutions, et souvent, le meilleur apprentissage vient de la présentation de solutions potentielles à de vrais utilisateurs. Une fois que vous avez décidé de l'opportunité sur laquelle vous allez vous concentrer, vous pouvez commencer à réfléchir aux solutions qui ont du sens et à la manière de les prioriser. | |||
===Générer des solutions=== | |||
Une fois encore, cela reflète le design thinking, cette fois-ci dans sa [https://www.hustlebadger.com/what-do-product-teams-do/design-thinking/ phase d'idéation]. Vous pouvez organiser une session d'idéation avec un groupe diversifié de parties prenantes, ou préférer laisser cette tâche à votre designer.<br/> | |||
<br/> | |||
L'essentiel ici est de se concentrer sur la quantité avant de s'engager dans quoi que ce soit. Si vous n'avez pas d'alternatives parmi lesquelles choisir, vous n'avez rien à comparer. Il n'y a pas de stratégie sans options.<br/> | |||
===Prioriser les solutions=== | |||
Contrairement aux opportunités, où il est généralement judicieux de se concentrer sur une seule à la fois, dans le domaine des solutions, il est souvent préférable d'envisager plusieurs options à la fois.<br/> | |||
<br/> | |||
Les meilleures équipes produit travaillent en parallèle sur un petit ensemble de solutions (peut-être 4 à 8). Bien qu'il y ait toujours une hypothèse sur l'ordre dans lequel celles-ci devraient être développées, approfondir la recherche ou mettre en œuvre l'une de ces solutions nous en apprendra probablement davantage sur les autres.<br/> | |||
<br/> | |||
Dans le même temps, il est très courant que la discovery diminue notre confiance dans une solution donnée. Dans ce cas, il est utile de disposer d'autres solutions en réserve que nous pouvons mettre en avant. Cela nous donnera le temps d'itérer ou d'abandonner l'idée initiale sur laquelle nous travaillions.<br/> | |||
[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 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 | |||
* 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/> | |||
<br/> | |||
Planifier les hypothèses que vous devez tester vous aide à tirer le meilleur parti de votre temps et augmente vos chances d'avoir suffisamment confiance en chaque solution que vous construisez.<br/> | |||
