Planification à l'aide de roadmaps de résultats
Auteur : Itamar Gilad
Source : https://itamargilad.com/outcome-roadmaps/
Traducteur : Fabrice Aimetti
Date : 10/03/2024
Crédit : Vincent Billon
Traduction :
À l'heure où j'écris ces lignes, le cycle de planification annuel tant redouté arrive à grands pas et le débat sur les roadmaps refait surface. D'une part, il est clair que les roadmaps classiques qui présentent les versions sur une ligne de temps entraînent à la fois des coûts de planification élevés et un gaspillage important. D'autre part, les tentatives d'élaboration de roadmaps autour de résultats et de thèmes (souvent sans calendrier) peuvent laisser l'organisation sur sa faim. Les roadmaps classiques sont très prometteuses : elles permettent de planifier les ressources, de suivre les progrès et de coordonner les lancements. Bien qu'elles ne tiennent pas vraiment leurs promesses, le désir de disposer de ces éléments n'est pas près de disparaître.
Et si nous essayions de combiner les deux mondes - une roadmap des résultats qui montre le travail réel effectué pour atteindre les objectifs, selon un calendrier. Une telle roadmap permet de communiquer efficacement les éléments que la plupart des roadmaps omettent, tout en soulignant que le plan doit être adapté au fur et à mesure de la découverte de nouvelles données.
Les éléments de cette roadmap sont les suivants
- Objectifs
- Recherche (facultatif)
- Product Discovery (découverte du produit)
- Product Delivery (livraison du produit)
- Effet Retard
Voici à quoi pourrait ressembler une telle feuille de route pour un seul objectif.
Une roadmap de résultats pour un seul objectif, présentée sur une ligne de temps
Voici un modèle de roadmap de résultats sur Miro que vous pouvez copier.
Examinons de plus près chaque élément de la roadmap.
Objectifs
Une omission flagrante dans la plupart des roadmaps de production est qu'il n'y a pas d'objectifs visibles. Il n'y a que des livrables (outputs), pas de résultats (outcomes). Un bon point de départ consiste donc à essayer de faire figurer les objectifs de l'entreprise sur une ligne de temps.
Si vous êtes familiarisé avec les objectifs et les résultats clés (OKR), ce diagramme devrait être assez facile à comprendre. Les quatre lignes représentent les quatre objectifs annuels de l'entreprise, quelque peu abrégés. Le losange indique la date à laquelle l'objectif sera atteint, et nous ajoutons un ou plusieurs résultats clés qui indiquent ce qu'est la réussite. Je n'en ai cité qu'un seul par souci de simplicité, mais le tableau des OKR peut en comporter d'autres.
La présentation de vos objectifs sur une ligne de temps comme celle-ci nous aide déjà à évaluer si nous sommes ambitieux tout en restant réalistes. Les CTO expérimentés peuvent détecter à partir d'une telle image si l'organisation de développement va être trop sollicitée. Naturellement, il s'agit là d'estimations très approximatives que vous devrez ajuster au fur et à mesure que vous avancerez, comme pour tout plan.
Vous pouvez vous arrêter à ce niveau et, dans certains cas, cette structure est suffisante pour démarrer. Mais si vous souhaitez une planification plus claire, vous pouvez zoomer sur chacun des objectifs et planifier le travail nécessaire pour les atteindre.
Recherche et idéation
La première étape pour atteindre un objectif consiste à se demander si l'on comprend suffisamment le contexte pour effectuer un travail significatif. Le contexte peut inclure les besoins des clients, les technologies applicables, le paysage concurrentiel et les partenaires, les défis et les opportunités, etc. Par exemple, si nous souhaitons réduire le taux de désabonnement (churn), savons-nous ce qui pousse les clients à se désabonner ? Si nous souhaitons lancer notre produit dans de nouveaux pays, savons-nous quel pays présente la meilleure opportunité ?
Il est tentant de répondre à ces questions par un oui. Les clients se désabonnent parce que nous n'avons pas les fonctionnalités A, B et C. Le meilleur pays pour le prochain lancement est l'Inde parce qu'il y a une demande massive pour notre type de produit. Mais il faut alors être honnête et se poser la question suivante : dans quelle mesure sommes-nous sûrs de ces hypothèses ? En d'autres termes, quelles sont les preuves ?
L'indicateur de confiance peut vous aider à calibrer vos hypothèses :
L'indicateur de confiance (téléchargez la calculatrice gratuite ici
Si votre conviction repose sur des opinions, des thèmes ou des preuves anecdotiques, votre confiance dans vos hypothèses doit être faible. Dans ce cas, il est préférable de consacrer du temps à la recherche, également connue sous le nom de recherche exploratoire ou générative, et de porter le niveau de confiance à moyen-faible ou moyen.
Il existe de nombreux types de recherches : études d'utilisateurs, études de marché, études concurrentielles, études technologiques, etc. Vous devez décider du type de recherche à mener et y consacrer le temps et les ressources nécessaires.
La recherche n'est pas un vilain mot - une once de recherche peut vous épargner une tonne de travail inutile à la recherche d'opportunités qui n'existent pas. Les résultats de la phase de recherche doivent être clairs : des idées (insights) et des opportunités étayées par des preuves de niveau moyen à faible.
La recherche mène souvent à l'idéation, c'est-à-dire à l'élaboration de moyens potentiels pour atteindre l'objectif. D'autres idées viendront en dehors de votre recherche - de la part des clients, des managers, des parties prenantes et des membres de l'équipe. Tout cela est normal et sain. Nous devons recueillir toutes les idées que nous trouvons pour les utiliser dans la phase suivante.
Product Discovery
Une fois que nous avons une bonne compréhension du contexte et une première ébauche d'idées, nous pouvons nous lancer dans la product discovery. La product discovery (terme défini par Marty Cagan (fr)) est un vaste sujet traité par de nombreux auteurs et le thème principal de mon livre Evidence-Guided (Guidé par les faits). En bref, lors de la product discovery, nous évaluons et validons plusieurs idées par rapport à l'objectif, en éliminant celles qui ne fonctionnent pas et en redoublant d'efforts pour celles qui fonctionnent.
Source de l'image : Evidence-Guided : Créer des produits à fort impact face à l'incertitude.
Le résultat de la Product Discovery est un petit ensemble d'idées suffisamment validées pour passer à l'étape de delivery. On me demande souvent combien de temps il faut consacrer à la discovery, et la réponse est le temps qu'il faut, car si l'on abrège, on risque de construire les mauvaises choses. Toutefois, vous pouvez fixer un délai pour votre travail de discovery, en sachant que si vous n'avez pas trouvé d'idées validées dans un délai de quatre semaines, par exemple, vous passerez à un autre objectif ou reviendrez à un travail de recherche pour trouver d'autres idées.
Product Delivery
Une fois que nous avons découvert une idée susceptible de contribuer à l'objectif, l'étape suivante consiste à la construire et à la lancer. Avec un peu de chance, une seule idée permettra d'atteindre l'ensemble de l'objectif, mais il en faudra souvent plusieurs. La plupart des idées qui ont fait l'objet d'une product discovery sont déjà partiellement développées, et vous devriez avoir une bien meilleure idée du temps et des efforts qu'il faudra consacrer à leur réalisation.
Notez que cette partie de la roadmap est équivalente à la roadmap classique - une série de projets avec des lancements concrets sur une ligne de temps. Hélas, en l'absence de recherche et de product discovery, nous ne pouvons pas prédire quelles seront ces idées et combien de temps il faudra pour les développer. Commencer par cette partie de la roadmap n'est donc pas du tout une bonne idée.
