[VIDEO] E03 – Le quotidien d’une BA : la road map

Bonjour à tous,

Cette fois-ci, je vais vous présenter la notion de Road Map – la feuille de route en français.

Pourquoi ? Parce qu’un Business Analyst va forcément devoir préparer et présenter sa feuille de route à un moment donné de son projet. Pas forcément pour le projet en entier. Tout dépend de l’organisation projet, s’il y a des chefs de projets ou si le Business Analyst a aussi cette casquette de pilotage, ce qui arrive assez souvent lorsque ce sont des projets où le business analyst est la seule ressource qui va réfléchir à la mise en place et à la définition d’une nouvelle solution.

Qu’est-ce que la feuille de route ?

C’est un document que l’on présente pour partager le périmètre d’un projet. Pour présenter également une planification dans laquelle on va définir les activités principales, les livrables associés, les différents jalons et l’estimation de la charge.

Dans le cadre de ma mission, je suis à l’avant-projet. Je suis en train de préparer une étude d’opportunité, donc on n’a pas encore lancé le projet, on est juste en train de réfléchir à sa faisabilité. Malgré tout, je commence déjà à préparer une feuille de route, mais pas une feuille de route sur l’intégralité du projet, puisque la décision de faire ce projet n’a pas encore été actée. Cependant, c’est quand même une feuille de route pour proposer une planification sur les deux prochains jalons qui sont :

• La réflexion sur le périmètre-projet et sa planification
• Et la définition précise des fonctionnalités générales et détaillées.

Notez que cette étape est un peu particulière parce que je travaille en méthodologie agile, en « SAFe » pour être exacte, donc ce ne sont pas des documents aussi formels que ceux réalisés sur des projets ayant un cycle de vie en cascade par exemple (méthode traditionnelle). Néanmoins, il y a quand même une phase où l’on va devoir définir les fonctionnalités, les « features » que l’application et la solution cible devront avoir à la fin, même si ce n’est pas décrit formellement dans les spécifications fonctionnelles.

Donc ma Road Map, pour l’instant, est une Road Map préliminaire : non pas sur la totalité du projet mais sur ces deux prochains jalons, sur ce que je prévois comme activités et comme charge pour atteindre ces deux prochains jalons.

Pour faire cela, je pars du contenu que je veux présenter (je vous renvoie à mon site bestofbusinessanalyst.fr pour avoir un peu plus d’information sur la Road Map).

Donc je vous le rappelle, la road map préliminaire consiste à présenter le périmètre, la méthodologie que vous allez employer, les activités et livrables, ainsi que la planification associée et l’estimation de la charge.

Comment bâtir sa road map

Pour ce projet, je n’ai pas pu obtenir de retour d’expérience exploitable me permettant de la bâtir en utilisant des moyens de comparaison avec des projets similaires. En fait, pour construire sa road map, tout dépend des services et des entreprises. Dans certains contextes, on va pouvoir aller très vite parce que la méthode – par exemple – est agile, et les gens ont de la disponibilité, alors que dans d’autres, ce sera tout l’inverse, les contributeurs ne seront pas disponibles, et la durée du cycle de vie des projets est beaucoup plus longue.

La raison peut provenir du fait que, par exemple, le projet est géré à l’aide d’une méthodologie traditionnelle de cycle en V et donc on aura tendance à d’abord étudier l’intégralité du périmètre et du sujet avant de commencer à lancer les développements.

A l’inverse, avec une méthode agile, on va le faire de manière itérative, incrémentale et progressive. Le périmètre n’est donc pas arrêté dès le début mais il est découvert au fur et à mesure.

Je suis précisément dans ce cas-là.

Comme je ne suis pas très habituée à travailler dans ce cadre agile SAFe, et que je ne connais pas non plus la manière de travailler ni l’organisation du département, j’ai besoin de retour d’expérience concret.

J’ai commencé par regarder le calendrier, afin de calculer mon nombre de jours de travail disponibles (je ne travaille pas à plein temps chez ce client pour ce projet).

Note : attention, quand on travaille en agile avec des équipes de développement, la road map est fixée au travers de sprints et les fonctionnalités à développer dans chaque sprint sont donc prévues en fonction des décisions communautairement validées par l’équipe agile. Mais dans cette road map préliminaire, je suis pour l’instant inscrite en dehors du cadre agile car je ne planifie que la partie amont (les analyses)

Mon expérience personnelle me permet de savoir à peu près le temps dont j’ai besoin afin de collecter l’information, pour la restituer et pour en faire une présentation synthétique sous forme de Road Map. Mais ce n’est pas suffisant parce que je ne connais pas encore très bien le sujet. Encore une fois, on n’en est encore qu’à l’étude d’opportunité et je ne connais pas bien le contexte, les produits et les services, donc ce n’est pas évident.

Ne croyez pas qu’on ait tous une baguette magique pour estimer la charge et la planification, ce n’est pas vrai. Bien sûr, ceux qui travaillent toujours au même endroit et ce, depuis des années, ont ce retour d’expérience « dans leur tête », qui n’est pas forcément formalisé. En tout cas ils sont capables de comparer avec d’autres projets ayant eu des besoins similaires et donc de proposer une planification.

Ce n’est pas trop mon cas, donc je vais à la pêche aux informations.

Je demande à mes contributeurs – par exemple le Product Owner ou le Product Manager, de me dire un petit peu leur sentiment là-dessus. Déjà à propos des dates des prochains jalons – quand ceux-ci sont planifiés, puisque l’une des contraintes du projet est de s’insérer dans une méthodologie SAFe, avec des jalons communs à tous les projets.

Ce n’est pas le moment de vous expliquer ce qu’est la méthodologie SAFe, mais en gros, le projet ne vit pas tout seul, il est rattaché à ce qu’ils appellent un « train » et donc on ne peut pas imaginer une Road Map comme si on était seul sur une île déserte. Elle dépend du contexte de ce « train SAFe ».

Donc vous voyez, tous ces retours d’expériences, j’en ai besoin pour pouvoir proposer une feuille de route macroscopique qui ne soit pas complétement fantaisiste et ce n’est pas évident…

A l’heure où je tourne cette vidéo, la feuille de route n’a pas encore été finalisée. Je suis plutôt en phase d’échange, si ce n’est de négociation. En effet, souvent, les clients veulent tout, tout de suite et ce n’est pas forcément faisable ni tenable. Il faut donc être capable d’entendre les besoins du client, mais il faut aussi être capable de dire « ce n’est pas possible », en étayant son argumentation. Certaines personnes seront très pessimistes, d’autres au contraire, seront très optimistes. Ainsi pour certains cela peut être « C’est facile ! Il me faut 3 semaines et ce sera bon » et finalement ils n’arrivent pas à tenir leurs délais. Pour d’autres, ils ont l’impression d’avoir un mur en face d’eux et ils vont mettre 3 mois dans leur Road Map alors qu’en fin de compte, au bout de 1 mois et demi, ça peut avoir été réalisé. Donc tout est question de nuance, et de communication entre les différents contributeurs, afin réussir à trouver une feuille de route qui soit tenable (là, je parle de la partie planification).

Note : après avoir tourné cette vidéo, j’ai présenté ma road map à mon client. Et devinez quoi ? Il ne l’a pas acceptée, car il veut tout, tout-de-suite ☹. J’ai donc du totalement revoir mon organisation et mes livrables. C’est aussi cela, la vie d’un business analyst !

En ce qui concerne les activités et les livrables, je vous renvoie vers mon site internet qui va vous donner plus informations mais bien évidemment, ce sont des informations que vous devez connaitre au préalable afin de faire une Road Map pour le périmètre de la Business Analyse. Vous devez savoir quelles sont les activités que vous allez faire et quels sont les livrables que vous allez produire, et tout dépend du projet en question.

Enfin, notez qu’en ce qui me concerne, je commence tout juste ce projet, j’en suis à l’analyse d’opportunité. Dans d’autres cas, en tant que business analyst, vous allez commencer plus tard : le cadrage aura été fait, vous aurez peut-être déjà des spécifications fonctionnelles générales. Auquel cas vous aurez une feuille de route qui sera beaucoup plus cadrée avec des objectifs beaucoup plus précis à réaliser.

Voilà, pour cette troisième vidéo, c’est terminé ! La prochaine fois je vous parlerai de l’étude d’opportunité qui est, en ce qui me concerne, le premier livrable que je dois rendre sur ce projet.

A bientôt !