Nous sommes toutes et tous de grands enfants

le 02/01/2024 par Thomas Aubry
Tags: Product & Design, Agile, Coaching

Je vous propose d’aborder le sujet du storytelling. J’observe depuis un moment, et de plus en plus fréquemment, qu’on le pratique peu. Ne serait-ce pas une erreur ?

Raconter l’histoire de nos produits sert plusieurs causes essentielles dans ses cycles de vie et devient un moyen de création en équipe, de priorisation et de développement conscient des enjeux utilisateurs. Je vous invite à me suivre dans ma réflexion et mes questionnements. Qui sait, peut-être aurez-vous ensuite envie de vous y essayer ?

Une liste de course pour endormir vos enfants

Je constate de plus en plus d’éloignement entre les problèmes que le métier cherche à résoudre, les solutions que le produit propose et la compréhension de ceux qui les réalisent.

Mon constat est qu’une liste de course n’est jamais qu’une énumération sans âme. A l’inverse, faire des petites choses qui ont du sens, permet de créer un tout qui transcende n’importe quel livrable. N’importe quel contrat.

Imaginez-vous avec l’idée d’endormir votre enfant le soir. Il est l’heure d’aller se coucher, alors, vous vous installez confortablement dans sa chambre, vous vous assurez qu’il en fait de même, puis vous prenez sur l’étagère ce nouveau livre que vous venez d’acheter. Vous commencez la lecture comme suit :

“Chapitre 1”

“Un adulte, un autre adulte, deux enfants, une maison” “Un jardin, des animaux, un portail, une route” “Un potager dans le jardin” “C’est le printemps”

“Chapitre 2”

“Un adulte jardine avec les enfants” “Un adulte va au travail” “Deux enfants posent des questions”

“Chapitre 3”

“Des légumes poussent” “Des fruits poussent” “Des repas faits maison”

Vous finissez par arrêter de lire, votre enfant s’étant endormi, certainement d’ennui !

Le lendemain, au petit déjeuner, vous lui demandez de raconter au reste de la famille ce qu’il a compris. Sans nul doute, fort de son imagination débordante, il vous racontera ce que son esprit aura pu créer autour. Il y ajoutera des détails, fera des liens entre les différents éléments dont il dispose. Quoi de plus naturel ? Sans cela, comment parler “d’histoire” ou de “conte” ou encore de “poème” ?

“Un adulte”, “un autre adulte”, “deux enfants”, “une maison”. Est-ce qu’il s’agit d’une famille ? A quoi ressemblent-ils ? Quels caractères ont-ils ?

“Un jardin”, “des animaux”, “un portail”, “une route”. Est-ce que l’on parle du jardin de cette probable famille ? Est-ce qu’il est grand ? En pente ? Clos ? Quelle sorte d’animaux peut-on y trouver ? Les couleurs ? Les odeurs ? Leurs sensations ?

Votre enfant se verra contraint de répondre à certaines de ces questions, oubliant un ou plusieurs éléments, afin de donner un sens à ce qu’il a entendu. De façon à ce qu’il puisse le mémoriser et le raconter à son tour. Qu’il puisse s’identifier et faire des rapprochements avec ce qu’il vit, faire preuve d’empathie et devenir curieux pour la suite.

A l’instar de cet enfant, qui ne peut s’approprier ce qu’il a entendu sans inventer une histoire qui lui correspond, nous avons besoin de comprendre l’âme de ce que l’on nous présente. Quelle intention vers l’utilisateur ce produit ou cette fonctionnalité a-t-elle ? Quelle histoire vise-t-elle à raconter à notre utilisateur ? Qui sont nos utilisateurs ? Comment, dans le livre, cette nouvelle page se positionne-t-elle ? Dans quel chapitre ?

Sans ces discussions, nous forgeons notre propre compréhension, nous créons notre propre histoire.

Une histoire commune, c’est une compréhension commune

Peut-être vous êtes-vous déjà senti comme l’enfant de mon histoire. Peut-être n’en avez vous plus envie. Je passerai sur les écueils que peut provoquer un manque de compréhension mutuelle au sein d’une équipe ou d’une organisation. Je préfère voir quels sont les bénéfices que peuvent nous apporter les chroniques de nos produits. J’interviens en ce moment dans un secteur technique, avec beaucoup d’acronymes, pour lequel mon équipe doit réaliser une application qui effectue beaucoup de calculs. Je vous parle ici de calculs d’un “niveau préparatoire ou études supérieures”.

Au fur et à mesure que notre produit se dessine, nous devons y ajouter de plus en plus de calculs. Non contents de leur complexité unitaire, nous découvrons maintenant les dépendances de certains d’entre eux avec les résultats des calculs précédents. Il s’agit là de plus d’une centaine de calculs.

Arriva ce qui devait arriver. Un des développeurs, devant le cas d’une dépendance calculatoire, se pose la question du lien entre ce qu’il doit faire et ce qui a déjà été fait quelques semaines auparavant.

Il vient me poser la question, peu ou prou dans ces termes : — “Tu vois, j’ai Rgp0 qui se calcule ici, de trois manières différentes, en fonction des cas, et là j’ai H1 qui en dépend. Je ne suis plus sûr des cas d’usages de Rgp0, j’ai l’impression que H1 ne fonctionne pas comme ça. Tu as une idée ?”

Mon premier réflexe fut de lui demander — “Il fait quoi au moment du calcul de H1 l’utilisateur ? Où se trouve-t-il dans l’application ? Et au moment du calcul de Rgp0 ?”. Mon espoir était de nous faire réfléchir sur le “pourquoi” pour mieux appréhender le “comment”. — “Aucune idée”. Echec.

A l’inverse de l’enfant qui peut laisser libre cours à son imagination et se satisfaire de l’histoire résultante, les développeurs ne le peuvent pas. C’est bien trop risqué d’interpréter ce que l’on pense devoir faire car nous avons beaucoup de chance de tomber à côté. Le Product Owner étant en vacances et notre Proxy-Product Owner n’étant pas plus au courant que nous, nous avons dû attendre son retour.

C’est très frustrant pour la personne qui se retrouve bloquée. Le fait d’attendre n’est pas le problème. Celui de ne pas savoir ce que notre utilisateur fait, veut obtenir ou espère au moment de pousser un développement me paraît beaucoup plus inquiétant. Je ne blâme pas les membres de l’équipe, bien entendu. Visiblement, nous ne partagions pas tous le même niveau d’information, de compréhension au sein de l’équipe. Pourtant nous avions “groomé” nos tickets et il y eut pléthore de questions. Il aurait certainement fallu nous raconter une histoire cohérente.

Plus le domaine est complexe, plus nous avons besoin de compréhension mutuelle. Cela permet de clarifier les rapports entre les éléments qui composent ce que l’on vise à réaliser. J‘observe que c’est au moment où l’on constate la complexité de la solution que les équipes s’orientent vers des listes, des backlogs, des estimations, etc. Cependant, c’est lorsque l’on a une vision globale, commune et cohérente que l’on devient performant.

La cocréation au service de l’engagement

Raconter l’histoire du produit permet aux personnes de reformuler et d’exposer leur propre compréhension. Les points de vue fusent. Dès lors, les équipes deviennent auteures. Elles prennent part à la création. Le premier conteur entend ses propres lignes et appréhende ce que ses interlocuteurs en comprennent. Il sait désormais enrichir son histoire. Si vous lisez l’énumération ci-dessus, à trois personnes différentes et qu’à l’instar de votre enfant au petit déjeuner, vous leur demandez quelle histoire ont-ils imaginé, il y a fort à parier qu’aucun d’entre eux ne vous racontera la même chose. Néanmoins, si vous les invitez à échanger sur leur compréhension respective, avec comme ambition de créer une histoire commune, il est très probable qu’au regard de la trame finale, chacun d’entre eux y retrouvent la genèse de ce qu’ils avaient en tête.

La différence, non des moindres à ce stade de l’échange, est qu’ils auront mémorisé la même chose. Ils seront en capacité de le transmettre. Ils s’identifieront aux protagonistes et seront curieux de la suite.

Compréhension mutuelle

Les acolytes sont essentiels aux bonnes histoires, ils ne sont pas prioritaires.

Imaginez maintenant que, demain soir, vous n’aurez pas assez de temps pour lire à votre enfant une histoire complète, vous disposerez de 15 minutes alors qu’il en faudrait 20. Il faudra faire des choix dans ce que vous allez lui dire. Puisque vous voulez le faire rêver, il faut que ce que vous allez lui conter l’embarque. Il faut conserver une cohérence tout en mettant de côté des parties de l’histoire.

Quels sont les éléments de l’aventure dont votre enfant pourra se passer sans perdre le fil ? En restant captivé ?

Si vous décidez d’arrêter le livre lorsque vous avez atteint le quart d’heure, le risque est grand de laisser votre enfant sur sa fin. Mais vous aurez, techniquement, lu quelque chose. Cela paraît évident qu’il faille relire l’histoire, au complet, une fois retranchée d’une partie de son contenu. Vérifier le maintien de son sens. De sa cohérence.

De la même façon, prioriser sur le périmètre d’un produit, devrait avoir comme leitmotiv de garder son essence. Sa substantifique moelle. Une fois qu’une fonctionnalité aura été revue, il faut se raconter de nouveau l’histoire. S’assurer que nos utilisateurs seront toujours embarqués par ce qu’on leur propose. Méthodiquement se poser les questions suivantes :

  • Est-ce que mon utilisateur réussira à résoudre son problème ?
  • Est-ce que mon workflow reste cohérent ?
  • Si je peux m’en passer, qu’est-ce que je voulais raconter ?
  • Etc.

Epilogue

Je souhaite insister sur le fait qu’il ne suffit pas de dérouler des ateliers, à la lettre, avec une liste de questions “orientées storytelling” pour raconter l’histoire de nos produits. Il s’agit plutôt de leur offrir une place dans l’histoire des produits. Ne plus les voir seulement comme des réunions avec des objectifs, un cadre et des règles. Faire cela, c’est réussir à les envisager comme un prétexte à la co-construction, à la compréhension mutuelle, à la réalisation d’un tout qui nous anime et nous émeut. Après tout, laisser s’exprimer l’enfant qui sommeille en nous n’est peut-être pas incompatible avec nos responsabilités d’adulte. Pas plus que le laisser nous raconter des histoires et s’émerveiller en entendant celles des autres.