Questionner son cahier des charges

J’ai eu l’opportunité de proposer l’atelier « Questionner son cahier des charges » à Paris Web 2017. Pendant cet atelier, beaucoup de choses importantes ont été dites, on s’est marré, on a dessiné. Aujourd’hui, j’ai la chance de pouvoir revenir dessus dans cet article et même d’aller plus loin. Alors, pourquoi passer 1h30 à « questionner son cahier des charges » ?

L’origine, le pourquoi

Tout part d’un non. Le jour où l’équipe dtc innovation dont je fais partie a refusé de réaliser un produit sur la base d’un cahier des charges. Pas parce que nous n’avions pas besoin de signer un contrat. Pas parce que le produit était inintéressant. Le client est une personne que nous respectons grandement et les enjeux du projet étaient enthousiasmants.

Alors pourquoi ne pas s’exécuter dans la réalisation de ce cahier des charges ? Pourquoi ne pas faire simple ?

Parce que ce cahier des charges disait beaucoup de la technique, du planning et des sous-tâches. Mais ce document ne disait pas grand chose du « pourquoi ». Pas grand chose non plus du « pour qui ». Ces sujets existent, ils n’étaient juste pas développés dans cette commande. Et deviner en cours de production le « pourquoi » n’est jamais une bonne idée. Suivre une liste d’instructions écrites sans discuter avec la personne à l’origine du besoin l’est encore moins.

Pourtant c’est ce qui arrive tous les jours quand on suit le principe de ce qu’on appelle communément « consigne », « description des tâches à réaliser » ou encore « cahier des charges ». C’est ce à quoi nous sommes habitués depuis l’école.

Prenons un exemple pour mieux comprendre.

Partager une vision ne va pas de soi

Si je vous dis : UN CHAT.

C’est un concept simple, très éloigné de la complexité technique, juridique, morale que peut revêtir un projet logiciel. Et pourtant. Demandez à n’importe qui de dessiner « un chat » et vous aurez autant de réalisations que de réalisateurs. Parce que chaque personne imagine son chat différemment. Il y a ceux qui le dessinent de face, d’autres de profil, ceux qui dessinent tout le corps et ceux qui dessinent seulement la tête. Et puis la diversité des styles d’exécution.

Vous pourriez dire que ça n’a rien à voir avec un cahier des charges. Un cahier des charges est justement très détaillé. Les caractéristiques de réalisation y sont énoncées clairement. À priori, pas de place à la diversité ou à l’incompréhension.

Pendant l’atelier, nous avons justement expérimenté un jeu agile pour vérifier ça.

Jeu à Gilles – part 1

Les participants se réunissent par binôme : une personne sera « spécificateur » et l’autre « artiste ». Le but pour chaque binôme est de reproduire fidèlement un dessin qui est présenté seulement aux spécificateurs. Les artistes ne voient jamais le modèle. Pour y arriver, les spécificateurs ont 5 minutes pour rédiger des instructions par écrit. A la fin de ces 5 minutes les artistes pourront prendre connaissance des instructions et auront à leur tour 5 minutes pour réaliser un dessin en suivant les consignes. Spécificateurs et artistes ne peuvent pas se parler pendant la phase de réalisation.

11 binômes jouent le jeu pendant cet atelier et voici le dessin à reproduire :

Au bout de 10 minutes, nous constatons que les productions sont toutes différentes. Elles ne comptent pas le même nombre d’éléments. Certaines ont un style géométrique voir abstrait tandis que d’autres sont plutôt courbes voir figuratives.

Nous discutons avec les participant·e·s. Le constat est unanime : l’exercice a été plutôt déstabilisant. Nous prenons le temps d’échanger sur les ressentis de chacun, spécificateurs et artistes. Il ne s’agit pas de juger qui que ce soit. Il n’y a pas de classement ou de bon point. Ce qui nous intéresse ce sont les perceptions. Tenter de comprendre ce qui rentre en jeu dans un processus de production.

Du côté des spécificateurs les prises de paroles convergent vers trois points :

• La définition de l’objectif : doit-on proposer une idée à atteindre ou une somme de parties à exécuter ?

  7 binômes sur 11 ont défini en premier lieu l’idée générale avant de lister les parties à réaliser. Ceux qui ne l’avaient pas fait se sont étonnés : « Ah bon ? On avait le droit de dire que c’était un tracteur ? Je croyais qu’il fallait juste lister les trucs à dessiner ».

  Qu’est-ce qui définit le mieux un objet ? L’exactitude de la description de la somme de ses parties ou l’expression de son rôle, de son but final ? Il est intéressant de noter que les descriptions donnant peu de détail et seulement un objectif sont assez éloignées du tracteur originel. Mais l’objet « tracteur » est reconnaissable. A l’inverse les consignes très précises sur les parties géométriques du dessin sont très fidèles sur la structure géométrique. Mais l’idée du tracteur ne transparaît pas/peu.

• La priorisation de l’information

  Tous les binômes ont eu du mal à prioriser l’information. Par quoi commencer ? Quel côté ? Un des spécificateurs a même évoqué être gêné car il n’avait « aucun point par où commencer ».

• La granularité de l’information

  Dernier point, la granularité. Jusqu’où faut-il aller ? Est-il nécessaire de tout préciser ? Ou est-ce une perte de temps qui va rendre confus l’artiste ?

Un point est commun à tous les spécificateurs : sans possibilité de dialoguer avec la personne qui réalisera l’objet au moment de la rédaction des consignes, il est difficile de savoir quelles sont les justes bornes de ces consignes. La question de la réception se pose donc dès l’étape de la conception.

Du côté des artistes, d’autres questions émergent :

• La réception n’est jamais passive, elle amène à se questionner sur le sens de celui qui délivre « Simplement la compréhension de la phrase » : parfois les artistes avaient des difficultés de compréhension sur le sens de la phrase ne sachant pas comment interpréter les consignes. Sans possibilité d’interagir, ils ont dû choisir eux-mêmes sans savoir s’ils respectaient ou non le souhait du spécificateur.
• Le questionnement de l’existence ou non d’une culture commune « Oui mais je ne le connais pas mon binôme ». Les profils présents à cet atelier étaient plutôt approchants pourrait-on supposer. Des personnes travaillant autour de l’« industrie web » se posant des questions sur leur pratique, en tout cas assez pour participer à une conférence telle que Paris Web et aller s’impliquer dans un atelier. Mais un langage commun est plus complexe à construire et dépasse des valeurs ou des intérêts communs. Le langage commun doit être précis, aller dans le détail.
  

  – Oui mais “à côté” ça veut dire que ça touche l’autre carré ou pas ?
  – Ah mais pour moi ça ressemble pas DU TOUT à un tracteur ça !

• Comment lire une consigne ? « Je ne savais pas trop s’il fallait tout lire avant ou pas ». Faut-il lire au fur et à mesure ou tout lire d’un coup puis partir sur la réalisation ? Cette question était très dépendante du processus d’écriture proposé. Car certains spécificateurs ont eux-mêmes écrit suivant le fil de leur pensée reprenant des consignes le long du document pour re-préciser ou changer plus tard ce qui était écrit. D’autres établissaient dès le début l’objectif puis numérotaient les étapes sans nécessiter une vue globale pour commencer.
• Les « caractéristiques » personnelles. « Le dessin, ça va mais c’est que je confonds ma droite et ma gauche ». « Le dessin c’est pas mon truc, je suis pas à l’aise ».

Jeu à Gilles – Part 2

Pour la deuxième partie du jeu, nous reprenons nos binômes et encore une fois les spécificateurs vont prendre connaissance d’un dessin sans le montrer aux artistes. Cette fois-ci pas de consignes écrites mais un dialogue continu pendant 7 minutes. Les spécificateurs ne peuvent pas dessiner à la place des artistes mais ils peuvent dicter les consignes, réagir aux dessins et au besoin pointer des éléments. Pour cette deuxième partie le dessin choisi est un peu plus complexe et contient davantage de formes à réaliser.

Cette partie était clairement plus bruyante dans son exécution, plus éparpillée en apparence. Tout le monde parle. A la fin du temps imparti, les binômes ont globalement le sourire et sont impatients de montrer le résultat. L’ambiance est différente de la fin de la première partie.

A nouveau nous observons les résultats, toujours sans jugement et en accueillant les ressentis. Tous sont plutôt satisfait du caractère approchant et de la forme reconnaissable.

Les constats sur l’exécution sont les suivants :

• La correction instantanée permet un ajustement au plus près de l’objectif. Les artistes ont apprécié connaître en temps réel le retour du spécificateur sur leur réalisation. Le caractère de « jeu » de cet exercice a aidé à accepter plusieurs tentatives de la part des artistes. Cette coopération entre les binômes a renforcé le travail de précision de tous. « Je me sentais plus à l’aise parce que j’étais guidée ».
• La construction en direct d’un langage commun. À part un binôme qui ne parlait pas la même langue, la discussion a permis au fur et à mesure d’avoir des consignes de plus en plus précises. Spécificateurs et artistes comprenaient mieux les indications au fil du temps. « On a le temps de s’ajuster, de se comprendre ».
• La confiance. Visible dans l’attitude de tous les binômes, elle s’est traduite par un rendu des dessins « en équipe ». La co-réalisation du dessin avait construit une confiance partagée par le simple fait d’avoir traversé cet exercice ensemble. La représentation du processus de production devenait une matière commune aux deux personnes et non pas deux expériences très différentes comme lors du premier tour.

Si cette attitude paraît normale pour un petit jeu, pourquoi ne pas l’appliquer dans la vie professionnelle ?

comment jouer dans la vraie vie alors ?

Se questionner sur le sens d’une commande, construire un langage commun, faire des brouillons, se faire confiance, ce ne sont pas des apprentissages naïfs dédiés à un hypothétique monde parfait déconnecté de la vie réelle (qui serait évidemment rempli de chocolat et de paillettes). Ces questions, il suffit de les poser à voix haute. C’est exactement ce que nous avons réalisé avec ce fameux client à qui nous avions dit non.

Un peu comme si après avoir reçu la description du dessin, nous avions préféré ne pas essayer de le dessiner seul, mais plutôt prendre une feuille avec notre spécificateur à nous, notre client.

Épilogue

Nous avons questionné avec notre client le document qu’il nous avait transmis. Cela s’est traduit simplement par une invitation à expliquer notre refus de production, reprendre ensemble l’origine du cahier des charges, son but, autour d’un thé et sans jugement. À mesure de la discussion, le « pourquoi » a fini par émerger. Nous avons pu verbaliser nos incompréhensions. Il a pu verbaliser ses besoins et en faire émerger de nouveaux. Cette discussion s’est finalisée par une proposition. Pas celle de produire le dit-cahier des charges. Non. La proposition de prendre le temps, une semaine, pour décortiquer tout ça, surtout ne rien coder, faire plein de brouillons et se construire un langage commun.

Pour prendre le temps ensemble et explorer ce besoin, il fallait une méthode, des outils qui nous permettraient de matérialiser cette construction de sens. J’avais entendu parler de la méthode du « design sprint » qui permet rapidement d’éprouver des prototypes pour challenger l’utilité d’un produit. Je me suis donc documentée.

Le livre « Le design Sprint » sous le bras (merci Thomas pour ce cadeau 3 ), j’ai mis en place les actions suivantes pour 3 journées de travail :

• tout le monde regarde la même chose au même moment. Ni téléphone ni ordinateur allumé et une pause toutes les 2h. Accueillir toutes les questions. Des supports d’écritures (brouillons, tableaux) pour tous et visibles par tous. Inviter un à deux collaborateurs, potentiels utilisateurs mais avec des compétences « non techniques ».
  
• définition de l’objectif à long terme. La mise en mots de cet objectif paraît trivial d’abord puis le choix des mots permet de prioriser les réalisations de l’outil et les publics concernés.
• construction d’une feuille de route. Se mettre dans l’hypothèse d’un outil fonctionnel : lister tous les acteurs concernés et toutes les actions qu’ils doivent réaliser. La somme de toutes ces actions doit mener à l’objectif précédemment identifié. Ainsi on définit par l’usage le périmètre fonctionnel de l’outil.
• Itération d’interfaces. Des brouillons encore et encore. Pour manipuler des hypothèses visuelles de ce que rendrait l’interface. Prioriser les plus plausibles. Les visualiser par des outils simples (tableur, présentation type power point).

Toutes ces réflexions ont été documentées. Dans le cadre précis de ce projet, ces actions ont permis de :

• Partager la connaissance du projet aux collaborateurs qui n’avaient pas compris la complexité du projet ;
• Invalider des hypothèses sur la chronologie des actions à mener dans l’outil ;
• Ré-évaluer l’ambition du projet et le temps à y consacrer ;
• Repenser un plan de financement réaliste pour une mise en production ;
• Identifier, caractériser et prioriser les prochains pas techniques à mener. Aucun devis définitif n’a été établi pour la production de l’outil. Seulement des fourchettes de temps et de prix en fonction de nos connaissances.

Au cours de ces trois jours, beaucoup de discussions, de schémas, de dessins, de rires aussi. Pas une seule ligne de code.

Ce processus n’était pas une tactique pour gagner un contrat. C’était un contrat. Nous avons facturé ce temps de réflexion. Parce que ce temps a apporté de la valeur, un document qui retranscrit nos explorations, nos découvertes et les prochains pas à mener. Il a apporté du sens.