Cahier des charges fonctionnel : pour qui ? pourquoi ?

Cahier des charges fonctionnel : pour qui ? pourquoi ?

La question peut paraître banale mais je suis persuadé que tout le monde n’a pas la même réponse dès lors qu’il s’agit de dire qui le cahier des charges fonctionnels cible. De fait, écrit-on pour :

  • son commanditaire ?
  • le sponsor projet ?
  • la Direction ?
  • les développeurs ?
  • soi-même ?
  • les utilisateurs finaux ?
  • le métier ?

On écrit pour tout ceux-là mais également pour d’autres parties prenantes pas encore identifiées sur le projet :

  • le renfort éventuel qu’on vous allouera,
  • les équipes des lots ultérieurs qui sont peut-être différentes,
  • des spécialistes fonctionnels et d’autres qui ne le sont pas,
  • etc.

Ainsi, cela signifie qu’un bon cahier des charges fonctionnel doit être lisible et compréhensible de tous, quel que soit leur niveau :

  • d’implication dans le projet,
  • de connaissance fonctionnelle.

Un cahier des charges doit-il être compréhensible de tous ?

Les différents types de lecteurs

Très souvent, que l’on rédige un cahier des charges fonctionnel seul ou en tant que Business Analyst / assistant à Maîtrise d’Ouvrage (interne ou prestataire), le temps fait que l’on finit par écrire uniquement pour les valideurs, c’est-à-dire les gens qui ont participé aux ateliers de recueil des besoins.

Ainsi, on injecte donc de plus en plus d’induit dans le cahier des charges fonctionnel, postulant à tort que tout le monde a la même compréhension des choses, un développeur comme un référent métier. Dit différemment, nous écrivons comme s’il n’y avait qu’un seul type de lecteur alors qu’il y en a en fait plusieurs.

Par conséquent, notre objectif sera donc d’écrire pour que tous les types de lectorat comprennent exactement la même chose, sans distorsion. Si l’on atteint cet objectif alors nos documents seront des des textes pérennes et nous augmenterons les chances de réussite des projets.

Des lecteurs pressés

A ce titre, un cahier des charges fonctionnel est un défi : faire lire à des gens qui ont peu de temps, voire pas du tout, un document qu’ils n’ont pas forcément envie de lire.

C’est un fait observé sur bon nombre de projets auxquels j’ai participé ou menés par des collègues : nos commanditaires sont surchargés, saturés d’informations. Par conséquent, lire un cahier des charges ne fait pas partie des activités qu’ils mettraient au sommet de ce qu’ils aiment le plus dans leur travail.

Donc, il va falloir adopter des stratégies rédactionnelles qui doivent à la fois minimiser le temps de lecture et en accélérer la validation. Si une ou plusieurs des techniques que j’évoquerai ci-dessous vous intéressent, n’hésitez pas à laisser un commentaire car chacune d’elle pourrait faire l’objet d’un article spécifique.

Comment faire son cahier des charges ?

  • Première chose : écrire, se relire, et donc… réécrire, puis recommencer.
  • Deuxième chose : une fois parfait pour soi, se faire relire par quelqu’un d’autre.

L’on pourrait penser que, pour faciliter la vie d’un commanditaire, moins je lui donne à lire, plus je lui rends service. Ce n’est pas la position de « SOS Cahier Des Charges ».

D’abord parce qu’en termes de gain de temps, il vaut mieux lire une fois un document clair et détaillé que plusieurs fois un document incomplet et vague (ou alors par morceaux clairs, le reste n’étant pas présenté).

Ensuite parce que nous écrivons également pour des développeurs qui sont rarement des spécialistes fonctionnels . Si on ne leur dit pas exactement ce que nous souhaitons, ils feront ce qu’ils comprennent ou ce qui les arrangent. Dans les deux cas, c’est mauvais. Dit concrètement : si le développeur est en régie, il optera pour la solution la plus longue et coûteuse, s’il est au forfait il fera au plus rapide.

Enfin, mettez-vous également un objectif : votre document est-il compréhensible par un bachelier, c’est à dire quelqu’un qui n’a pas  fait d’études spécialisées dans le domaine ? Ce qui est quasiment toujours le cas, vous en conviendrez, d’un développeur informatique  qui a généralement fait ses études… dans l’informatique !

Comment encore mieux faire son cahier des charges rapidement ?

En réalité, la relecture par un tiers va vous aiguiller sur des paragraphes où la clarté a bien été abandonnée ou omise. Et là, l’efficacité revient à une seule clef : l’absence totale d’ego vis à vis de votre écrit. Vous devez tout accepter.

Je sais, c’est dur, j’y suis passé et cela fait mal. On va parfois vous dire que c’est grossièrement écrit mais c’est l’occasion de donner satisfaction car, devinez quoi ? Vous avez ce pouvoir entre les mains : c’est votre clavier. Il est évident que si changer deux lignes de texte vous gêne, vous ne gagnerez pas en notoriété 🙂 Mais si en les corrigeant, votre interlocuteur à l’air content, c’est que vous avez sauvé au moins une partie de votre aura, qui aurait été immanquablement abîmée en temps voulu sur ce même paragraphe…

Parfois les gens n’oseront rien dire : engagez vous-même votre interlocuteur en lui demandant si tel ou tel paragraphe a bien été clair pour lui.

Test final : demandez à votre relecteur de résumer oralement votre cahier des charges ! Vous allez vite vous rendre compte de ce qui était clair par rapport à ce qu’il a compris !

Comment être clair au moment de l’écriture (et pas après une relecture) du cahier des charges ?

Effort et entraînement

La clarté demande un effort et de l’entraînement. Et là, oui, on découvre tout simplement qu’écrire un cahier des charges fonctionnel est une compétence !

Si l’on cite le fameux Standish group dans son Chaos report annuel, nous lisons page 10 :

Successful projects need smart, trained people. Not surprisingly, one of the key project
success factors identified in Standish Group’s CHAOS research is a competent staff.

source :  Chaos report 2011-2015 Standish group

Dans cette étude, on dit que dans 44% des cas, la contribution du personnel entraîné à amener une haute (27%) ou très haute  (17%) valeur ajoutée pour la réussite des projets.

En d’autres termes, si vous êtes entraînés et si vous avez acquis des réflexes d’écriture, vous ferez vous-même partie des clefs de la réussite des projets de votre organisation.

Faire preuve de pédagogie

Nous ne sommes pas naturellement des pédagogues et l’on n’écrit que très rarement de la meilleure des façons au premier coup. Il s’agit donc de savoir se relire avec un œil critique. Par conséquent, mon premier conseil est de vous fabriquer des check list de points de contrôle obligatoires et de ne jamais rien livrer sans avoir balayer l’intégralité de ces contrôles.

Voici les techniques que j’estime les plus dévastatrices dans les cahiers des charges dès lors qu’elles ne sont pas traitées correctement ou éliminées du livrable :

  1. Pas de redondance
  2. Pas d’éclatement thématique
  3. De la progressivité
  4. Du texte phrasé
  5. Pas de flous, pas de synonymes
  6. Des schémas
  7. Des exigences ou users stories bien distinctes du texte explicatif

Je vous remercie d’avoir lu cet article qui malheureusement touche à sa fin. 😀 Déjà ? Oui car ces 7 techniques nécessitent presque toutes un article dédié pour vous permettre de les manipuler facilement, efficacement et sans même vous en rendre compte (une fois bien expliquées).

Dites moi en commentaire celle(s) que vous préféreriez que je vous expose en premier, cela me créera une belle motivation pour vous répondre ! (aller, à 10 000 like je fais une vidéo de cours :-D)

Cet article pourrait également vous intéresser : Cahier des charges : définition difficile du métier

Partager l'article:
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *