La roadmap produit est un document graphique qu'utilise le product owner dans le but de simplifier la communication de la direction stratégique du projet.
Son objectif est de synchroniser l’ensemble des parties prenantes sur les objectifs à atteindre pour le succès du projet.
Dans cet article, nous verrons comment se servir d'une feuille de route agile, comment la mettre en place, et enfin comment la présenter.
Pourquoi faire une roadmap produit ?
La feuille de route agile est utile pour les principales raisons suivantes :
1) Donner les grandes directions au projet
Elle permet de collecter des besoins et des idées pour le projet.
Ainsi, elle sert à conduire le projet, à donner les grandes directions et bien entendu de la visibilité sur les grandes étapes.
Malgré tout, il faut garder en tête que la feuille de route reste une direction et non un objectif ferme à atteindre.
En effet, si on prévoit tout et qu’on la respecte à la lettre, l’équipe agile mènera finalement le projet en mode prédictif.
2) Enrichir le backlog
Effectuer une roadmap produit permet d’avoir les objectifs dans les grandes lignes.
Cela aidera le product owner à construire le product backlog.
Avec le client, il va creuser les solutions que ce dernier pourrait avoir en tête.
Il va ensuite orienter ses questions sur les besoins qui ont fait émerger cette solution éventuelle.
Petit à petit, il va remonter le fil de l’eau pour comprendre les causes de chaque problématique afin de résoudre le problème racine.
Toutes ces précieuses informations seront compilées et priorisées dans le product backlog.
Comment s'en servir ?
Comme pour le Product Backlog (carnet des besoins), on va venir sélectionner de la roadmap produit les besoins à réaliser en priorisant l’ordre de réalisation.
Les actions entreprises doivent toujours être celles qui apportent le plus de valeur ajoutée au projet.
Ainsi, la feuille de route agile vient compléter le Product Backlog. Son but est de se projeter des prévisions pour donner une vision globale.
Cependant, plus les prévisions sont éloignées, moins elles sont précises.
Pourquoi donner de la prévision dans un projet agile ?
Se projeter va permettre à l’équipe de s’organiser en conséquence, de clarifier les objectifs, de s’aligner avec les parties prenantes.
Modèle du Registre des Parties Prenantes
Gérez les engagements des parties prenantes avec la matrice pouvoir/intérêt.
En bref, de s’assurer que tout le monde est bien au clair avec la direction prise.
La première version de la roadmap de projet agile permettra également d'ajuster le nombre de personnes et de compléter les compétences nécessaires pour le projet.
Qui utilise la roadmap produit ?
Avant tout, la feuille de route est demandée par des collaborateurs occupants des postes de managers, de rh, de drh ou encore de dirigeants.
Cela leur permet d’avoir une vision d’ensemble pour comprendre plus ou moins la direction que va prendre le projet.
Ainsi, la roadmap produit permet d'anticiper certaines tâches, de donner une vision d’ensemble.
Cette vision se précise au fur et à mesure du déroulé des itérations.
Remplace t’on le Product Backlog par la roadmap produit?
Ces deux documents n’étant pas destinés aux mêmes personnes et aux mêmes objectifs, l'un ne peut substituer l’autre.
Si la feuille de route donne une vision macro, le Product Backlog lui, donne une vision spécifique des besoins prioritaires aux développeurs chargés de la réalisation du projet.
Pour l’équipe projet, ce n’est pas un non-sens que d’utiliser les deux documents.
La roadmap produit est-elle indispensable ?
Elle ne l’est pas, elle permet cependant de favoriser des idées de développement en amont de la phase de réalisation.
Cela engendre un potentiel d’anticipation.
L’équipe doit pouvoir se servir de cette roadmap comme une base de données d’idées.
Elle est souvent exigée par les fonctions rh.
Dans un projet agile, le product owner devra s’assurer que cette feuille de route est une direction, et non pas un contrat à suivre à la lettre.
Si les parties prenantes souhaitent que l’équipe suive la feuille de route “agile” à 100%, il faudra expliquer en quoi cela dénature le projet et le mets en péril tout le projet. À commencer par les retours précieux obtenus lors des démos !
En Agilité, on cherche à co-construire au fur et à mesure du temps le projet avec le client.
Il est donc primordial d’innover.
Or, avec la roadmap produit si elle est suivie dans son entièreté, l’innovation n’a plus sa place tant le projet est cadré.
Ainsi, la feuille de route ne peut pas être une promesse.
Si ce n’est pas le meilleur plan à suivre, il ne faut pas hésiter à l’abandonner pour la réussite du projet.
Comment construire une roadmap efficace ?
Elle peut s’avérer utile pour prendre de la hauteur et anticiper certaines actions lors de la conception.
N’étant pas dans le prédictif, on fait des estimations à la louche : la roadmap produit est une sorte d’incrément de la stratégie.
Elle se doit d’évoluer au même titre que le product backlog.
Elle reste vivante !
Une feuille de route réussie passe par un tableau bien souvent nommé “the go product roadmap” pour la remplir, il faut rester synthétique (n’oubliez pas que l’on est en macro)
Voici ses étapes de construction :
- Donner la vision produit : Le produit s’adresse-t-il à sa “cible client” : Qu’est-ce que les utilisateurs recherchent ? Quel est le problème à résoudre ? En quoi cette problématique sera résolue ? Quel est son avantage concurrentiel ?
- Établir des objectifs pour atteindre la vision produit préalablement définie
- Donner des estimations temporelles pour des missions courantes, à court terme ou pour le futur
- Donner les résultats envisagés avec la feuille de route : définir les objectifs en fonction des horizons temporels.
Zone d’efforts : qu’est-ce que c’est et à quoi ça sert ?
Une zone d'efforts va être le taux de complexité qui va être attribué à une tâche.
Cela va se faire via un baromètre allant de 1 à 10.
1 étant une valeur qui demande le moins d'implication et 10 étant la valeur qui demande le plus d'efforts à l'équipe pour la réalisation de cette tâche.
En estimant ces zones d’efforts, l’équipe devra garder en tête les objectifs à atteindre et non les actions à réaliser.
La vision doit rester la plus ouverte possible et non pas étriquée.
Connaître les objectifs à atteindre permettra de réfléchir à plusieurs possibilités d'action afin de les combler.
Au fur et à mesure du temps, les développeurs vont trouver les solutions les plus pertinentes pour répondre à l'objectif tout en étant dans une suite logique par rapport aux missions réalisées précédemment.
Exemple
Le product owner ne doit pas avoir comme objectif de faire une nouvelle page d'accueil, mais plutôt de convertir plus de visiteurs.
Besoin :
Convertir plus de visiteurs
Problème :
Manque de visibilité
Solution :
Développer un nouveau site web et/ou développer les réseaux sociaux et/ou rendre le bouton d’inscription plus imposant et/ou organiser un évènement.
Selon les retours utilisateurs, la solution retenue ne sera pas forcément la première envisagée.
Ils pourraient aussi faire en sorte que les champs du formulaire d'inscription soient moins importants pour éviter la non-inscription d'une personne qui est découragée ou bien qui ne veut pas donner certaines informations.
Ainsi, l’équipe ne s’engagera pas trop tôt dans une réalisation et la roadmap restera agile.
Comment présenter (pitcher) la roadmap produit ?
Vous aurez peu de temps pour donner les éléments essentiels.
Devinez combien de temps le cerveau humain reste concentré à 100%…
10 minutes seulement ! Ensuite, la concentration décroit.
Voilà le temps que vous aurez pour capter toute l’attention de votre audience !
Aussi, préparez en amont les messages clés et structurez-les.
Envisagez votre introduction : ces premières minutes qui retiendront vos interlocuteurs.
Si vous démarrez bien, vous serez positivement lancé.
Enfin, préparez votre conclusion : quels sont ces messages avec lesquels vos interlocuteurs devront repartir ?
Le pitch :
Pour appuyer votre intervention, préparez une présentation légère, aérée et agréable :
- Présentez chacun des objectifs à atteindre ainsi que les résultats clés attendus dans le trimestre à venir (Bonjour les objectifs SMART)
- Passez ensuite au product backlog dans le trimestre à venir pour affiner les besoins à résoudre
- Enfin, reprenez de la hauteur avec une vision plus globale reprenant passé/présent/futur.
Évidemment, tout cela doit répondre sur le long terme à la vision produit qui a été décrétée lors de l’élaboration de la “go product roadmap”.
Restez vigilant !
Gardez en tête que la collecte des besoins/idées sera prolifique.
Toutefois, l’idée n’est pas de la suivre à 100 %, mais bien d’identifier ce qui aura le plus de valeur pour les utilisateurs.
Bien souvent, dans ce cas, l’équipe se met une grosse pression pour concrétiser toutes les idées (en plus de tous les changements qui surviennent).
La masse de travail devient considérable, la cadence s’accélère, le rythme n’est plus soutenable.
La conséquence directe sur le projet : la réalisation sera de qualité moindre.
L’équipe ne rentre alors plus dans le cadre de l’Agile tant avec les valeurs de rythme soutenable que pour l’excellence continue.
Conclusion
La roadmap produit agile sert à avoir une vision globale.
Elle est conforme aux attentes des collaborateurs qui ont un regard sur le projet tout en étant à l’extérieur de ce dernier.
Elle permet aussi au product owner d’avoir une vision stratégique générale pour construire un product backlog plus simplement répondant rapidement aux grandes lignes du projet.
Les idées évoquées étant nombreuses dans la feuille de route agile, l’équipe de développement peut piocher à tout moment une idée pour la développer.
Mais uniquement si cela lui parait pertinent au cours du projet.
La feuille de route agile n’est pas figée, elle évolue en même temps que le projet se déroule.
N’oubliez pas que plus on cadrera le projet, plus on perdra cette notion d’innovation et on rentrera dans du prédictif !
