Le client, c’est celui qui paie. Que ce soit en interne à l’entreprise ou en externe, pour lui livrer ce qu’il veut, il faut le comprendre.
Vous avez le cahier des charges, une expression de besoin. Vous avez fait des échanges avec le client lors de la qualification. Vous avez une partie de la vision du projet. Mais est-ce que vous avez tout ? Non et c’est pourquoi il va falloir cadrer ce projet pour comprendre les besoins du client et non seulement les connaître.
Si vous ne savez pas par où commencer, voici quelques conseils pour commencer.
Interrogez les principales parties prenantes
La première étape pour comprendre les besoins et les exigences de l’entreprise consiste à interroger les principales parties prenantes.
Il peut s’agir de chefs de service, d’utilisateurs finaux et de cadres exécutifs. Il s’agit d’entretiens en one-to-one ou d’ateliers en groupe.
L’objectif de ces entretiens est de comprendre les processus métier, les flux de travail et les points faibles que votre projet va résoudre.
Le chef de projet doit préparer une liste de questions à l’avance pour guider la discussion et s’assurer que tous les sujets pertinents sont couverts.
Il en ressort un premier document sous forme écrite, un dessin, une carte mentale, etc.
Regrouper les informations
À la suite des entretiens avec les parties prenantes, Il est important de regrouper plus d’informations. Ces informations doivent permettre de comprendre le contexte. Il peut s’agir de documentations (techniques ou fonctionnelles) passées pour récupérer de l’historique, les anciens intervenants.
Ce peut être aussi les informations d’architecture provenant du support, ou d’insights de personnes gravitants autour du projet
L’une des tâches clés du chef de projet est de bien connaître la situation actuelle et d’identifier les domaines à améliorer ou à optimiser. Un besoin non exprimé peut apparaître.
Exemple d’éléments à prendre en compte :
- Cartes ou diagrammes des processus métier actuels
- Manuels ou guides d’utilisation existants
- Résultats de précédents sondages (ou lancement d’un nouveau)
- Commentaires des utilisateurs ou tickets de demandes d’assistance
- Données historiques ou rapports sur l’utilisation du système actuel et performances des processus
Cette nouvelle compréhension permet au chef de projet d’être plus efficacement dans la phase d’atelier et avec l’équipe de développement.
Animer des ateliers
Sur la base de ce qui a été compris, des exigences sont rédigées et des questions doivent apparaître.
Le chef de projet peut animer des ateliers pour approfondir les exigences. Les ateliers peuvent être utilisés pour identifier les lacunes dans les processus métier actuels, hiérarchiser les caractéristiques et les fonctionnalités nécessaires et définir les attentes utilisateurs.
Voici quelques-unes des meilleures pratiques pour assurer le succès des ateliers :
- Préparez-vous et soyez ouverts d’esprit,
- Posez des questions ouvertes,
- Les ateliers ne doivent pas durer plus de 2h00 (prévoir une pause),
- Permettez aux participants de discuter des désaccords,
- Gardez les objectifs affichés.
Types d’ateliers possibles
- Introduction et examen des processus métiers et business :
Cartographier les processus métier et les flux de travail de l’organisation, et d’identifier les opportunités d’automatisation et d’optimisation à l’aide de votre nouvelle solution. - Cartographie du parcours utilisateur :
Comprendre les besoins et les difficultés des utilisateurs, et de cartographier leur parcours. - Hiérarchisation et définition des fonctionnalités :
Définir le Produit Minimum Viable (MVP) qui peut être livré aux utilisateurs le plus rapidement possible tout en répondant à leurs besoins en s’appuyant sur les résultats des autres ateliers. - Exigences techniques et récapitulatif :
Identifier les défis techniques potentiels et les solutions qui doivent être prises en compte au cours du processus de développement
Documenter
A la suite des entretiens, de la documentation recueillies et des ateliers, le chef de projet doit avoir une vision claire qu’il va porter
Il doit donc documenter le mieux possible les exigence des utilisateurs et les contraintes techniques.
Cette documentation forme les spécifications fonctionnelles contenants les fonctionnalités, les parcours utilisateurs (users stories) et les critères d’acceptation qui permettront de préparer les cahiers de recette.
Cette documentation peut-être en un document ou en plusieurs. Il n’y a pas de bonne pratique. Mais elle doit être complète.
Le chef de projet doit faire valider cette documentation par toutes les parties prenantes. Si ce n’est pas la cas, des ateliers permettrons d’améliorer la compréhension.
Par soucis d’améliorer la qualité du projet, le chef de projet peut soumettre, avant validation, le(s) document(s) aux lead dev, lead tech, responsable recette, développeurs, etc. Cette soumission permet de repérer d’éventuelles contraintes non identifiées.
Les exigences uniquement sont validées par la signature d’un PV de validation des exigences ou un PV de validations des spécifications fonctionnelles.