En agilité, contrairement à ce qui se pratique dans un projet en cycle en V, l’expression de besoin ne se veut pas exhaustive en amont ou au lancement du projet et des développements.
Accompagner au changement d’une infrastructure ou un projet d’évolution d’une solution (logicielle, ERP, CRM, SaaS ou autre…), aider les représentants des équipes métier à formaliser leurs connaissances et leurs besoins d’évolution n’est pas si simple. Idéalement, le recensement de l’expression de besoin peut se pratiquer au fur et à mesure de l’avancée de la préparation des user stories à rédiger. Les différents acteurs peuvent parfaitement connaître leurs métiers, leurs fonctions, postes et attributs dans un contexte donné. Pour autant, les aider à se projeter et à inventer les process et les évolutions qui viendront ensuite n’est en revanche pas donné à tout le monde.
Lors du pilotage ou l’accompagnement de tels projets, il est important de bien comprendre les demandes qui sont faites et d’aller creuser les différentes raisons qui ont poussé faire les choix tels qu’ils sont présentés. Retrouver les causes d’origine d’un choix permet de mieux comprendre le contexte qui a motivé la décision de sélectionner ce dernier (humain, financier, organisationnel…).
Alors, comment procéder ?
Tout d’abord, il faut désigner une personne référente au pilotage des développements ou de la conduite de projet et qui ait un certain pouvoir décisionnel, qui soit habilitée à trancher certaines décisions clés au nom :
- Du comité de pilotage dans des limites préétablies et validées
- Ou des représentants du métier selon le besoin
Cette personne deviendra donc l’interlocuteur privilégié pour toutes les questions qui seraient en souffrance et pour lesquelles notamment le PO aurait besoin d’éléments de réponse.
Il convient ensuite de procéder par étapes et par incrément. On identifie à chaque phase le besoin en répondant aux questions :
- « Quoi » : que veut-on réaliser ? Quel est l’objectif que l’on se fixe (nombre d’utilisateurs, augmentation du nombre de visiteurs unique sur une période donnée par exemple) ?
- « Pourquoi » : quelle est la finalité de cette fonctionnalité ou de ce parcours ? Quelle est sa valeur ajoutée ? Pourquoi cette fonctionnalité plutôt qu’une autre ?
- « Pour qui ? » : quelle est notre cible ? Quelle typologie d’utilisateur est concernée ? Combien d’utilisateurs ciblés ?
Il convient d’imaginer comment, phase par phase (possiblement distinctes des sprints), on va apporter une première réponse partielle puis de plus en plus complète au fur et à mesure des développements.
En revanche, le « comment » et le « quand » (toutes les réponses techniques et la priorisation des éléments du chantier) restent le domaine réservé du PO et de l’équipe de développement.
Ensuite, il convient de schématiser (customer journey et/ou story map par exemple) et de tracer au travers d’EPICs et de premières US (en grosses mailles) les parcours et développements qui répondront à ces besoins. Et comme le contexte agile s’y prête, des évolutions et modifications seront apportées au fur et à mesure de l’avancée des travaux, des tests de recette ou d’un nouveau besoin métier.
Au final, il faut accepter que tout ne soit pas formalisé et arrêté dès le début d’un projet avec une vision parfaitement claire et à long terme. Une vision à quelques sprints d’avance est déjà un très bon indicateur de l’orientation globale d’avancement d’un projet.
