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

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 suivez-moi sur les réseaux sociaux!

Alice Svadchii
Alice Svadchii
Auteure du blog et Business Analyst enthousiaste
0 0 votes
Évaluation de l'article
Alice Svadchii

Alice Svadchii

Formatrice, coach, conférencière et productrice de contenus enthousiaste !

Cet article vous a plu? Partagez-le et suivez-nous sur les réseaux sociaux!

Découvrez des articles similaires

Préparer le recueil des besoins

Guide pratique du recueil des besoins

En Business Analyse, la matière première est l’information, sous toutes ses formes. Il existe de nombreuses techniques pour recueillir l’information, dont le « fameux » atelier de recueil des besoins. Celui-ci peut

Lire la suite

[Outil] Le diagramme de flux de données

Le diagramme de flux de données (DFD) permet de représenter visuellement le flux de données dans un système d’information. C’est un outil incontournable quand on souhaite modéliser les activités, déclencheurs,

Lire la suite
2
0
Would love your thoughts, please comment.x