Avoir une prise de notes efficace (deuxième partie)

Avoir une prise de notes efficace (partie 2)

Ce second article sur les prises de notes (niveau avancé) va vous proposer quelques techniques de notations textuelles et graphiques et vous présenter le contexte dans lequel elles s’appliquent. Il fait suite à Avoir une prise de notes efficace (partie 1).

Quel support utiliser pour la prise de notes ?

Compte tenu de la pluralité des supports physiques ou numériques, c’est un vaste sujet pour lequel il n’y pas vraiment de bonne réponse. Par conséquent, le plus important serait que celui qui note soit parfaitement à l’aise avec le support utilisé afin de ne pas ressentir de gêne technique. Ensuite, il faudrait faire en sorte que ce support soit également en adéquation avec le format de l’entretien : face à face ou en groupe, atelier de recueil de besoin ou brainstorming, etc.

Plutôt que de recenser les outils existant, il m’a paru plus intéressant de me concentrer sur ce qu’il me semble important de tracer lorsqu’on prend des notes.

Conseil générique

Déjà, quel que soit le format de l’entretien, il ne faut pas hésiter à utiliser un paperboard, surtout si ce que l’on a besoin de représenter peut prendre une forme graphique : diagramme d’activité (ou logigramme), de flux, d’état, de classe, etc.

La prise de notes en face à face

Dans un entretien en face à face, mieux vaudrait privilégier le support papier ou une tablette équipée d’un logiciel de prise de notes (Evernote par exemple) plutôt que l’ordinateur. Cela favorise l’échange (moins formel, plus convivial) et ne crée pas la barrière symbolique de l’écran.

La prise de notes face à un groupe

En groupe, l’usage de l’ordinateur s’avérera plus efficace et le problème de la barrière symbolique de l’écran ne se posera pas. Toutefois, et particulièrement si la réunion est « dissipée », que des conversations parallèles s’engagent, etc. cela ne sera pas suffisant pour canaliser les participants. Il faudra donc animer la réunion au paperboard de façon à recentrer l’attention de tous sur un élément visuel collectif.

L’usage des post-it est également très répandu et quand on est debout pour animer, que ce soit à déplacer les post-it ou à écrire sur un paperboard, il devient bien entendu très difficile de noter quoi que ce soit sur son ordinateur. Par conséquent, il s’agira de définir avec les participants au moins deux règles simples qui peuvent se combiner :

  • désigner dans l’assistance un rapporteur,
  • se mettre d’accord sur le fait que seules les choses validées par tous, sur lesquelles il y a consensus, seront notées sur le paperboard ou les post-it .

Toujours photographier sa prise de notes !

En sortie de réunion, n’oubliez pas de photographier les différentes pièces produites.

Elles pourront faire office à la fois de mémo, de compte-rendu de réunion et alimenteront bien entendu le livrable.

Que faudrait-il prendre en notes ?

A moins de manier la sténographie, tout noter exactement comme l’a dit notre interlocuteur est impossible. Il faut donc trier et ne conserver que l’utile, cette notion d’utilité pouvant varier en fonction du type de réunion. Nous allons en traiter deux, qui nous paraissent comme étant les principales lorsqu’on rédige un cahier des charges.

Mais en préambule, précisons tout de même un point qui nous semble primordial :

On ne devrait noter que ce qui est compris.

La prise de notes des consignes

Lorsque notre commanditaire nous transmet ses attentes, les éléments qui nous paraissent structurants sont finalement proches du concept de « ready » en agilité :

  • le chiffrage (en j.h et/ou en €) sur lequel on s’est accordé pour exécuter la tâche,
  • le périmètre et hors-périmètre de la tâche,
  • la date d’échéance.

Dans le cadre de la production d’un livrable (cahier des charges, spécifications fonctionnelles, Epic, Feature, user story, etc.), il conviendra de préciser :

  • le format attendu (World, Excel, PPT, ticket, email, etc.),
  • le contenu du livrable (enjeux, schémas et lesquels, décrits ou non, écrans, etc.),
  • ce que le livrable ne doit pas contenir,
  • le volume à produire (en pages, exigences/US, tickets, etc.).

La prise de notes en atelier de recueil du besoin

Les sujets pouvant être abordés en atelier de recueil du besoin sont bien sûr aussi nombreux que variés mais, dans le cadre du métier de Business Analyst / Product Owner, quatre éléments nous semblent prépondérants :

  1. les fonctionnalités (exigences, règles de gestion, structure de données),
  2. les concepts métier et leur définition, qui peuvent donner lieu à différents diagrammes (de classe, d’état, d’activité, de flux, de séquence, etc.),
  3. les motivations (soit au niveau des enjeux du projet, soit au niveau d’une fonctionnalité) et tout ce qui relève des enjeux en général : défauts et points forts, objectifs, périmètre et hors périmètre, risques, priorité, etc.
  4. les exemples partagés avec l’interlocuteur.

Cela constitue en quelque sorte le cœur de la prise de notes, les points qui demandent notre plus grande vigilance et qu’il est primordial de ne pas omettre ou déformer.

A cela, d’autres informations clés peuvent s’ajouter, telles que :

  • le nom d’une personne à rencontrer, son service, son rôle et ses coordonnées (email, téléphone),
  • des dates,
  • des actions à mener qui nous incombent ou qu’il nous faudra suivre et relancer,
  • etc.

Comment faudrait-il prendre ses notes ?

Nous pourrions distinguer deux types de prise de notes, textuelle et graphique et, au sein de la textuelle, séparer ce que l’on notera de façon « télégraphique » des « vraies » phrases.

La prise de notes graphique

Prise de notes niveau avancé
Exemple de prise de notes graphique

L’avantage de la prise de notes graphique, schématique, est qu’elle oblige à ne noter que l’essentiel, l’utile. C’est également une forme de note extrêmement synthétique qui laisse plus de temps pour interagir avec son interlocuteur.

Cependant, il ne faudrait pas confondre « dessin » et usage d’une forme normée de graphique, UML ou Merise par exemple. En effet, en l’absence de structure, et donc de codes de lecture, la prise de notes sera chaotique et ne permettra donc pas un questionnement structuré. Car, oui, la forme de la prise de notes conditionne fortement le fond et la cohérence des questions.

De plus, une forme graphique inventée sur l’instant aura une durée de vie extrêmement limitée. Rien ne garantit que vous serez toujours en mesure de comprendre ce que vous avez souhaité représenter une ou deux heures après l’entretien.

Par conséquent, je recommande d’utiliser les schémas uniquement si l’on est à l’aise avec leur formalisme et qu’ils ne sont pas un frein au questionnement et à la compréhension.

Bien entendu, pour des questions de rapidité, il vaudra mieux réaliser le schéma à la main plutôt que d’utiliser un outil de modélisation en temps réel.

Quels schémas utiliser pour prendre des notes ?

Sans énumérer tous les schémas existants, ce qui serait fastidieux, il en est qu’il me semble néanmoins important de maîtriser car répondant à des problématiques récurrentes dans les projets SI :

La table de vérité, extrêmement pratique pour traiter le sujet des habilitations à un système par exemple, ou encore dérouler un questionnement CRUD (Create, Read, Update, Delete, soit les fonctionnalités élémentaires d’un système informatique) sur les différents concepts métier identifiés. C’est une représentation rapide à faire, facile à valider et facile à modifier.

Les diagrammes :

  • de flux, afin d’identifier les acteurs d’un projet et les informations (flux) qu’ils s’échangent,
  • de classe, pour représenter efficacement les concepts métier d’une application (via les classes), les informations qui les caractérisent (via les attributs) et leur « mode » de communication (via le verbe d’association),
  • d’état, lorsqu’on s’intéresse au cycle de vie d’un système (par exemple, un DAB et ses états « en veille », « en passe », « disponible », « en rupture de billets », etc.) ou d’un concept métier (une commande « en cours de préparation », « expédiée », « livrée », « annulée », etc.),
  • d’activité, afin de représenter un processus métier par exemple.

Les bénéfices de la prise de notes graphique

Il sera toujours plus simple et plus rapide dans ces contextes de représenter graphiquement les choses. Cela vous aidera également à assurer la couverture exhaustive des cas et à les traiter avec un fil directeur (une suite logique dans le questionnement.)

La prise de notes textuelle

Tous les énoncés ne se prêtent pas à une représentation graphique, il faut bien parfois écrire. Mais quand faudrait-il faire des phrases et quand pourrait-on utiliser un style plus télégraphique, au risque de trop élaguer le propos et de ne pas être en mesure de le reconstituer au moment de la rédaction ?

En fait, l’une des clés, sans tenir compte de la mémoire, serait de savoir ce que l’on note et son caractère crucial / complexe. Prenons l’exemple suivant :

« Nous voulons moderniser le système de gestion des règlements client. Il faut pouvoir indiquer au niveau d’un client un délai de règlement. Nous avons besoin de pouvoir rapprocher les règlements constatés en banque avec les factures émises, comme ça nous pourrons identifier les factures non encore réglées. On doit tracer toutes les actions de relance avec les réponses apportées par les clients. On veut pouvoir catégoriser les clients selon qu’ils sont bons payeurs, payeurs moyens ou très mauvais payeurs. En effet, on veut pouvoir blacklister des clients : avec certains ne plus renouveler de commandes et avec d’autres interrompre les contrats en cours. »

Etape 1

Si nous notions :

  • Moderniser la gestion des règlements client
  • Ajouter le délai de règlement au niveau du client
  • Rapprocher les règlements des factures
  • Identifier les factures non réglées
  • Tracer les relances et réponses clients
  • Catégoriser et blacklister les clients (arrêter les commandes et contrats)

Nous ne perdrions pas d’informations clés.

Etape 2

On peut aller plus loin si l’on maîtrise le principe des abréviations. Cependant, attention : comme les schémas, les abréviations ont une norme. On peut certes avoir ses propres moyens mémo-techniques mais mieux vaudrait éviter d’inventer des abréviations sur le moment car le risque de ne plus savoir ce que l’on a voulu dire est élevé.

  • « Moderniser GE règlt cli (ou clt)
  • Ajouter délai règlt cli
  • Rapprocher règlt et fac (ou fact)
  • Id fac non réglées
  • Tracer relances et rep cli
  • Catégoriser et blacklister cli (arrêt cmd et ctr) »

En utilisant les abréviations connues[1], on constate que les verbes ne sont que très rarement abrégés. Concernant « contrat », j’ai utilisé ici « ctr » mais qui n’est pas reconnu en tant qu’abréviation « officielle ».

Par conséquent, si j’ai l’habitude d’utiliser cette abréviation précisément pour ce mot cela ne posera aucun problème. En revanche, si je l’ai inventé sur le moment, je pourrais par exemple la confondre avec « ctrl » et me dire que j’ai voulu exprimer la notion de « contrôle » : j’introduis alors une déformation du propos du fait de l’usage d’une abréviation avec laquelle je ne suis pas familiarisé.

Que noter sous forme textuelle ?

Nous pourrions dire que, dès lors que l’on utilise des schémas pour représenter tout ce qui peut l’être sous forme graphique, il ne resterait à noter que les :

  • fonctionnalités,
  • concepts métier et leur définition,
  • motivations,
  • exemples.

Il semblerait que le style télégraphique soit particulièrement bien adapté pour transcrire des motivations et des fonctionnalités.

En revanche, les définitions, les exemples et certaines règles de gestion semblent imposer une écriture plus complète, sous peine de trop dénaturer ce que l’on aura mis tant d’effort à reformuler et à faire valider en temps réel. Par conséquent, il est parfois nécessaire de temporiser l’entretien et de prendre le temps de noter intégralement une phrase.

Par exemple, si notre interlocuteur nous dit que seuls les concurrents de plus de 16 ans peuvent s’inscrire à la course, nous ne devrions pas uniquement noter : « ctrl âge cct. » Nous pourrions retranscrire précisément la règle, en l’écrivant pendant notre reformulation : « donc, ce que vous me dites, c’est que seuls les concurrents ayant au moins 16 ans à la date de départ de la course doivent pouvoir s’inscrire. »

Cependant, si je maîtrise parfaitement les codes de cette écriture, il m’est également possible d’utiliser un langage formel pour représenter textuellement une règle. Ainsi, « seuls les concurrents ayant au moins 16 ans à la date de départ de la course doivent pouvoir s’inscrire » = « concurrent.âge >=16 ».

Ce type de notification induit cependant une difficulté : il faut savoir identifier en temps réel les classes et les attributs et la notation peut vite devenir complexe à manipuler si la règle que nous souhaitons noter imbrique plusieurs classes et plusieurs attributs.

En espérant que cet article vous aidera dans vos futures prises de notes. Si vous êtes intéressés pour en apprendre davantage sur le langage formel, n’hésitez pas à laisser un message sur l’article !

Vous êtes libre de vous inscrire à notre newsletter en dessous de l’article garantie 100% sans spam. Vous recevrez à cette occasion notre bonus, un mini guide pour bien commencer votre cahier des charges.

Au plaisir !

[1] https://meltingmots.com/

Partager l'article:
 
 
      

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.