Elicitation et collaborationTechniques et méthodes

Doit-on planifier la lecture de documentation dans un projet?

la lecture de documents

Quand on est Business Analyst, on passe beaucoup de temps à lire.

La masse d’information collectée (voir la rubrique La collecte de l’information) est à la fois une mine d’or et un cauchemar, car il faut non seulement réussir à trier le bon grain de l’ivraie, comprendre le contenu, mais également synthétiser, conceptualiser, projeter sur les attentes implicites et explicites, ou encore anticiper de son utilité pour la production des livrables de l’analyse métier.

Non seulement c’est compliqué, mais cela demande également beaucoup de temps et d’énergie au Business Analyst, surtout quand celui-ci découvre l’environnement professionnel de son client, son métier, son secteur d’activité, ses procédures, son organisation, ses contraintes réglementaires et j’en passe et des meilleurs (pour le cauchemar des acronymes, c’est ici)

La lecture est donc bel et bien une activité fondamentale dans la journée de tout Business Analyst qui se respecte, mais est-elle pour autant une tâche à inclure dans le WBS (Work Breakdown Structure, ou Organigramme des Tâches, OT) du projet?

Petite piqûre de rappel: une tâche est une action à mener pour aboutir à un résultat. Elle est associée à un objectif précis et mesurable, des ressources humaines, matérielles et financières, une charge de travail exprimée en nombre de journées-homme, une durée ainsi qu’une date de début et une date de fin.

Pour pouvoir identifier en tant que tâche une activité de lecture de la documentation, il n’y a donc qu’une seule question à se poser : est-ce qu‘elle produira un résultat concret? Cet objectif peut prendre diverses formes: synthèse, diagramme UML, mémo, mail de questionnement, planification d’ateliers de travail etc…

Si tel n’est pas le cas, l’activité de lecture doit être rattachée à une tâche produisant un livrable (si non, c’est que vous pouvez vous passez de lire!). Par exemple, la préparation d’un atelier de travail peut comporter la lecture de documents métier, sans toutefois être synthétisée formellement. C’est la préparation de l’atelier de travail qui sera une tâche du WBS, et  non la lecture de la documentation, avec comme output, par exemple, une présentation Powerpoint.

Mais attention: la lecture de documentation qui aboutit à la production d’un livrable peut malgré tout ne pas être une tâche. Le découpage du WBS reste en effet un exercice individuel et subjectif, qui dépend du contexte projet, quand bien même il existe de nombreuses méthodes et bonnes pratiques cadrant l’activité de planification.

Pour résumer: la lecture de la documentation est une activité. Si elle aboutit à la production d’un livrable, elle peut également être identifiée comme une tâche du WBS.

Mes conseils pour rendre l’activité de lecture plus efficace

  • Avant de commencer votre lecture, réfléchissez d’abord à l’objectif à atteindre :
    • Est-ce pour la compréhension générale du sujet?
    • Est-ce pour analyser les fonctionnalités existantes d’un système?
    • Est-ce pour préparer un Benchmarking – et dans ce cas, est-ce pour créer un questionnaire, ou préparer une réunion?
    • Est-ce pour rédiger des manuels de formation utilisateur?
    • Est-ce pour mettre en place un plan d’amélioration continue?
    • Est-ce pour analyser les besoins?
    • Etc…
  • La réponse à cette question vous permettra ensuite d’identifier les éléments suivants :
    • D’une part, le rattachement de cette activité de lecture à une ou des tâches du WBS : rédaction des spécifications fonctionnelles détaillées, formation utilisateur, préparation des tests fonctionnels, analyse comparative… Cela permet d’affiner la charge et les délais de la ou des tâches en question, et de savoir quand vous devrez prévoir du temps dans votre agenda pour la réaliser.
    • D’autre part, les charges à prévoir pour chaque activité de lecture pourront être estimées relativement les unes aux autres. On ne passe pas autant de temps à s’imprégner d’un contexte général qu’à comprendre des règles métier complexes qui devront être décrites dans le cadre des spécifications fonctionnelles détaillées. Cela permet d’éviter de perdre du temps sur cette activité … et de sélectionner les techniques de lecture les plus appropriées (dans un prochain article 🙂 ).
  • Enfin, identifiez dès le début la manière dont vous capturerez les connaissances ainsi collectées : mémo écrit, fichier son, photo, email… et où vous les stockerez pour y accéder facilement ultérieurement. C’est fou le temps que l’on peut perdre à rechercher une information « qu’on-se-souvient-avoir-lue-quelque-part-mais-on-ne-sait-plus-où-ni-qui-nous-l’a-donnée »…

>> Cet article vous a plu ? Partagez-le !

>> Et pour en savoir plus sur les bonnes pratiques de la Business Analysis, visitez le site !

2
Poster un Commentaire

avatar
  S’abonner  
plus récent plus ancien Le plus populaire
Notifier de
Franck
Invité
Franck

Super article car je suis en plein dans le sujet 😁 Et oui c’est un vrai cauchemar de lire tous les documents collectés (quand la collecte est complète !). La lecture est fastidieuse et chronophage néanmoins elle apporte souvent les informations importantes à la compréhension d’un sujet jusqu’ici inconnu. Comme on dit « il y a à boire et à manger » dans tous ces documents et c’est là qu’il faut les identifier, les trier et les archiver pour pouvoir y accéder facilement au moment voulu et en tirer le meilleur lors de l’écriture d’un standard par exemple. Malheureusement les documents seuls… Lire la suite »