Les outils pour recueillir et documenter le besoin en AMOA

Les outils de la prise des besoins

La prise des besoins s’appuie sur la méthodologie envisagée lors du cadrage et notamment les éléments de la boîte à outils. Ces éléments se combinent le plus souvent et ne sont pas soumis à un ordre chronologique, ils sont mis en œuvre lorsque cela s’avère nécessaire :

  • L’étude et analyse
    Analyse des besoins connus en autonomie et identification des besoins latents. Ces derniers sont évoqués, étoffés et validés en interview, atelier ou immersion.
  • L’interview
    Temps d’échange avec un ou plusieurs acteurs du projet qui se joue sous la forme d’une session courte n’excédant pas 2h.
  • L’atelier
    Réunion de travail avec un ou plusieurs acteurs du projet pouvant durer jusqu’à 4h.
  • L’immersion
    L’immersion peut durer jusqu’à une journée, elle concerne en général les projets orientés « métier » (exemples que j’ai menés : application chantier pour tablette, interfaces des écrans pour les consignes dans la logistique, mise en place d’un CRM).
  • Document de questions/réponses
    Il est le fruit des points précédents, il concerne les détails, les solutions envisagées autour d’un sujet sont binaires et la réponse est unique. Dans le cas contraire, une interview peut être jouée à nouveau.
  • Compte-rendu
    Le compte-rendu est souvent l’aboutissement d’une interview, d’un atelier ou d’une immersion, ou à la suite de plusieurs itérations de ces actions. Il remet à plat ce qui a été dit, valide les sujets clos et identifie le reste à faire.

La prise de besoin se fait en deux temps, un temps fort où la boîte à outils peut être sollicitée dans son ensemble et un temps faible qui privilégie les documents de questions/réponses, les interviews et les comptes-rendus. C’est durant ce temps faible que la documentation du projet commence.

Documentation du projet

La documentation démarre en parallèle de la prise de besoin, notamment sur son temps faible. Elle peut donner lieu à de nombreux documents en fonction des finalités du projet :

  • Cahier des charges, spécifications fonctionnelles ou techniques
    Il peut y avoir plusieurs documents, un document de spécifications techniques peut concerner une seule fonctionnalité. Il peut y avoir un document de spécifications fonctionnelles pour une V1 et un cahier des charges pour la V2 qui sera converti plus tard en spécifications en fonction de la roadmap.
  • Diagrammes
    • Use cases (cas d’usage)
      Représentation d’une séquence d’actions qu’un système ou toute autre entité peut accomplir en interagissant avec les acteurs du système
    • Workflows (flux opérationnel ou procédure)
      Représentation d’une suite de tâches ou d’opérations effectuées par une personne, un groupe de personnes, un organisme, etc.
  • Document de User Stories
    Brève description d’une fonctionnalité telle qu’elle est vue par l’utilisateur.
  • Modèles de données
    Modèle qui décrit la manière dont sont représentées les données dans une organisation métier, un système d’information ou une base de données. Par exemple un modèle entité-relation pour la modélisation de bases de données relationnelles ou un diagramme de classe (UML) pour la modélisation d’une base de données à la programmation orientée objet.
  • Synthèse marketing
    La synthèse marketing varie selon le contexte, sa forme classique détaille l’offre, la cible (personas, cartes d’empathie), le positionnement, les promesses de l’offre et les raisons de croire en ces promesses. Je vous propose de mettre en œuvre un document simplifié rappelant les missions auxquelles les sites devront répondre ainsi que leurs cibles (sans personas)
  • Cartographie des contenus
    Ce document permet de rubriquer et hiérarchiser les contenus sous différents spectres : améliorer la visibilité du site sur Internet, répondre aux besoins des utilisateurs ou tout simplement organiser les contenus.
  • Zoning voire maquette
    Ils aident les utilisateurs à se projeter dans une application par la visualisation de son interface. Cela permet de faire ressortir de nombreux besoins latents et réduit le risque de déception.
  • Bacs à sable
    Le bac à sable est la mise en place d’une fonctionnalité du projet prise de façon indépendante afin de tester sa pertinence et sa faisabilité. Exemple de cas : Utilisation d’une API ou d’une bibliothèque Javascript.
  • Cahier des réflexions et doléances
    Ce document est utile pour éviter la répétition d’une même réflexion. En effet, au cours d’un projet d’assistance à maîtrise d’ouvrage, des fonctionnalités ou des problématiques pratiques ou théoriques peuvent émerger sans qu’elles soient intégrées dans un document de spécifications ou un cahier des charges car elles ont été évacuées (trop complexe, risque infime, etc.). Il faut néanmoins les enregistrer pour éviter à de nouveaux acteurs de se poser les mêmes questions, et mieux, lui permettre de se les poser autrement et ainsi faire avancer la réflexion. Cela arrive fréquemment pour le prestataire réalisant le projet (développement).

Cette documentation se déroule sur le temps faible de la prise de besoin car la rédaction amène régulièrement de nouveaux sujets, qu’ils s’agissent d’améliorations ou de problématiques plus ou moins bloquantes qu’il est nécessaire de solutionner.

Cette démarche s’accompagne de la création d’une roadmap qui va permettre de prioriser les évolutions (besoins latents découverts) en les replaçant dans la version en cours de l’application, dans la limite des contraintes fixées par le cadrage du projet sauf si ce cadrage est revu. Cela peut amener de nouveaux temps forts. Ou en les plaçant dans des versions futures, cette roadmap donne alors une visibilité aux acteurs du projet.