La roadmap c’est pour qui ?
La roadmap ou feuille de route sert souvent uniquement – en tout cas, c’est un constat basé sur mon expérience – à communiquer l’information aux clients internes ou externes de la société.
Elle est rarement faite pour les équipes qui réalisent le produit malheureusement : un peu comme si Daniel Elena ne communiquait pas le roadbook du rallye avec Sébastien Loeb ? Nul doute que ces deux-là n’auraient pas gagné autant de trophées…
Le dirigeant ou le board en a besoin pour valider l’investissement. Les clients en ont besoin pour savoir s’ils achètent le produit qui ne convient pas à 100% à leurs besoins à date mais qui va convenir à la prochaine version majeure indiquée sur la feuille de route. Mais les équipes ne sont généralement que peu informées / impliquées dans le process de construction de la roadmap.
Il faut dire aussi que le format classique des roadmaps est soit trop éthéré et dénué de sens pour les équipes qui sont sur le terrain : obligation de synthétiser en chiffres et 3 slides un engagement sur 18 mois bien souvent. Quant aux outils ou fichiers Excel, ils sont généralement trop détaillés pour soutenir les 5 minutes d’attention qu’ont parfois les membres du board après le bon repas qu’ils ont partagé…
Certes, j’exagère un peu mais c’est un peu le sujet clé dont les conséquences sont capitales, qui n’intéresse pas ou peu les équipes quand il faut le faire, qui retombe sur les épaules du responsable et qui, bien qu’il nécessite énormément d’énergie pour être fait, ne dure que 5 min au board. C’est un peu comme un soufflet au fromage : cela gonfle (tout le monde ?) et puis en fait, une fois que c’est fini, on l’oublie et la pression redescend…
La roadmap (feuille de route) c’est pour quand ?
C’est là que le bât blesse : dans la plupart des cas, la feuille de route est faite au mieux une fois par an pour étayer l’argumentation de l’exercice budgétaire. Cela a des conséquences fâcheuses:
- Ce n’est généralement pas préparé à l’avance : l’exercice budgétaire tombe comme un couperet en Octobre annonçant l’automne et la fin de l’été. Il faut donc le faire sans vraiment s’y être préparé : c’est le chef qui s’y colle « à l’arrache »
- Quand on sait que les cadres se donnent 3 ans max dans un poste : autant dire qu’il est impossible qu’en 3 exercices budgétaires, leurs équipes soient suffisamment aguerries pour fournir une meilleure roadmap collectivement
- Prévoir et s’engager sur 12 à 18 mois : si cette vision est nécessaire d’un point de vue carburant / budget, c’est très difficile d’un point de vue produit. Impossible d’avoir les spécifications ou les User Stories un an à l’avance ! C’est contraire aux principes agiles et même au bon sens quand on sait qu’il faut systématiquement prendre en compte de nouveaux besoins si un client nouveau arrive en cours d’année et a suffisamment de poids pour changer la roadmap
Se préparer à l’éventualité d’un évènement au cours de l’année qui vienne remettre en question la feuille de route, c’est aussi du bon sens et le board en a aussi bien sûr. Les éditeurs de logiciels un tant soit peu structurés mettent en place une revue trimestrielle a minima pour reprojeter la feuille de route sur 18 mois « glissants » et réajuster le budget en conséquence.
Il faut donc s’habituer et habituer les équipes à expliquer leur capacité à faire les choses à faire de la roadmap.
A propos de l’auteur : Benoît Fillon
A lire aussi :
Comment faire une roadmap 1/5 : Une roadmap c’est quoi ?
Comment faire une roadmap 3/5 : La capacité de l’équipe c’est quoi ?
Comment faire une roadmap 4/5 : Comment évaluer la roadmap ?
Comment faire une roadmap 5/5 : J’ai fait une roadmap et après ?