« Des roadmaps produits efficaces » : différence entre les versions
De Wiki Agile
Aucun résumé des modifications |
Aucun résumé des modifications |
||
| Ligne 32 : | Ligne 32 : | ||
La section supérieure de notre roadmap décrit notre vision, notre défi et notre état cible, qui reflètent les objectifs décrits dans [https://melissaperri.com/blog/2014/05/19/rethinking-the-product-roadmap mon article sur la Stratégie Produit]. La roadmap produit doit s'aligner sur ces mêmes objectifs et contribuer à communiquer la tactique pour les atteindre. | La section supérieure de notre roadmap décrit notre vision, notre défi et notre état cible, qui reflètent les objectifs décrits dans [https://melissaperri.com/blog/2014/05/19/rethinking-the-product-roadmap mon article sur la Stratégie Produit]. La roadmap produit doit s'aligner sur ces mêmes objectifs et contribuer à communiquer la tactique pour les atteindre. | ||
Selon cette roadmap, l'équipe X travaille pour atteindre l'objectif global (ou défi) qui consiste à faire en sorte que 99 % des personnes qui créent un compte sur NYS of Health souscrivent une assurance. | |||
Maintenant que nous avons défini notre défi, l'équipe analyse les problèmes des clients qui les empêchent d'atteindre cet objectif. Il s'agit du même processus que nous avons décrit dans le [https://melissaperri.com/blog/2014/05/19/rethinking-the-product-roadmap post original sur la Roadmap]. Supposons qu'après une recherche utilisateurs, nous découvrons que le plus gros problème des utilisateurs du site Web de NYS of Health est qu'il faut beaucoup de temps pour chercher et trouver le régime d'assurance maladie idéal. C'est un processus qui prête à confusion et qui est incroyablement frustrant. Cela incite les gens à abandonner au lieu de s'inscrire. | |||
L'équipe X décide donc de s'attaquer à ce problème et fixe une condition cible qui lui permettra de savoir quand elle aura atteint un résultat concluant. "Diminuer le temps moyen pour trouver et souscrire une assurance maladie en passant de 3 semaines à 2 jours au deuxième trimestre". Bien que les utilisateurs ne puissent s'inscrire qu'une fois par an à une assurance maladie, de nombreux changements pourraient être mis en œuvre pour faciliter les choses une fois la période d'inscription ouverte. | |||
À partir de là, l'équipe X déterminera les principaux domaines qu'elle souhaite explorer ou sur lesquels elle souhaite travailler au deuxième trimestre pour atteindre la condition cible. Nous appelons cela des thèmes. Par exemple, le thème "Amélioration de la recherche" comprendra tout le travail d'interface utilisateur nécessaire pour simplifier la recherche des différents régimes d'assurance maladie. | |||
Afin de répondre à la question "Pourquoi explorons-nous ce thème ?", nous rédigeons une hypothèse ou un énoncé de problème. Lorsque les produits sont encore dans la phase de découverte, nous sommes encore en train de valider le problème et la solution, donc nous voulons préciser ce que nous savons et ce que nous ne savons pas. Notre hypothèse doit montrer que nous pensons que notre solution résoudra le problème le plus important. | |||
Ainsi, avec notre thème d'amélioration de la recherche, nous en sommes à la phase de livraison et notre hypothèse est la suivante : "Nous pensons qu'en améliorant les choix de filtre pour refléter les principaux facteurs de décision des acheteurs lorsqu'ils choisissent une assurance maladie, nous leur permettrons de restreindre plus facilement leurs choix et de trouver le bon régime d'assurance maladie". Nous avons déjà validé le fait que les gens ont des difficultés à restreindre leurs choix pour trouver la bonne assurance santé, et nous pensons que le fait d'offrir quelques améliorations aux choix de filtres peut résoudre ce problème. | |||
Notre dernier thème, la Communication sur les Subventions, est un exemple de problème qui en est encore au tout début de la phase de découverte. Nous avons constaté que le taux de conversion des personnes qui remplissent les conditions requises pour bénéficier de subventions est très faible, et nous voulons en étudier les raisons. Nous avons quelques idées mais nous ne les avons pas encore validées. Nous devons donc communiquer clairement notre hypothèse, en soulignant ce que nous savons ("les personnes qui obtiendraient une assurance santé presque gratuitement ont un taux de conversion très faible") et ce que nous ne savons pas ("nous ne sommes pas sûrs que les gens partent avant de savoir s'ils ont droit ou non à des subventions, ou s'ils ne comprennent tout simplement pas notre explication des subventions"). | |||
Après la rubrique "Hypothèse" vient la rubrique "Résultats" - la partie la plus importante de notre roadmap. Ici, nous indiquons ce que nous espérons obtenir en résolvant ce problème ou en prouvant cette hypothèse. Chaque résultat doit se rapporter d'une manière ou d'une autre à la condition cible. Tout notre travail va nous aider à atteindre la condition cible, donc la roadmap serait plutôt ennuyeuse si chaque résultat pour chaque thème n'était qu'une répétition de cet objectif. Réfléchissez plutôt à la manière dont chacun de ces changements ou améliorations constitue une avancée vers votre objectif. | |||
Par exemple, dans le cas des améliorations de la recherche, nous pouvons savoir si nous facilitons la recherche en mesurant les composantes qualitatives de la frustration et les composantes quantitatives de la réduction du temps d'identification d'une option. Vous devez vous assurer que vous vous concentrez sur une bonne combinaison de résultats commerciaux et de résultats pour l'utilisateur dans ces rubriques, et les rendre mesurables. | |||
Les deux dernières rubriques concernent le statut et la priorité. Le statut doit indiquer où vous vous trouvez dans la phase de découverte ou de réalisation. Si vous êtes dans la phase de découverte, vous livrez pour apprendre, donc vous vous concentrez sur l'expérimentation plutôt que sur la livraison de fonctionnalités. Dans la phase de réalisation, vous livrerez des fonctionnalités et des solutions utiles aux utilisateurs. Définissez avec votre équipe ce que cela signifie au sein de votre entreprise, puis partagez ces définitions avec le reste de l'entreprise afin de parvenir à une compréhension partagée. | |||
Notez que notre roadmap ne contient pas de détails sur la façon dont nous prévoyons de résoudre ces problèmes. Cela s'explique par le fait que nous sommes toujours en train d'expérimenter des options - nous n'avons pas établi de plan pour mettre en œuvre un ensemble de fonctionnalités ou de composants de solution. | |||
L'exemple ci-dessus ne représente que la roadmap d'une équipe. Il pourrait y avoir beaucoup d'autres équipes travaillant sur ce même défi, mais elles auraient toutes des conditions cibles différentes. Ces roadmaps pourraient ensuite être combinées en une roadmap de portefeuille qui pourrait être communiquée à différents niveaux de l'entreprise, comme suit : | |||
[[Fichier:Good-Roadmap-FDS-portfolio.007.jpeg|border|center|1000px|link=]] | |||
