Six ressaisies entre la décision et le code

Vous pouvez faire ce compte sur votre dernière feature en quarante minutes, et je vais vous montrer comment. Vous saurez surtout nommer ce qui part à chaque étape, parce que ce n'est pas une brume qui s'évapore au hasard : c'est toujours les quatre mêmes choses, et toujours dans le même ordre.

Trois parties, dans le sens de la marche. Ce qui se passe entre les deux dates. Ce qui se perd à chaque étape. Et pourquoi quinze ans de wikis n'y ont rien changé.

Ce qui se passe entre les deux dates

La chaîne, telle qu'elle existe dans à peu près toutes les équipes produit que je connais :

• ↓La réunion. Quarante minutes, quatre personnes, une décision.
• ↓Les notes, prises pendant, ou juste après, de mémoire.
• ↓Le résumé Slack, pour ceux qui n'y étaient pas.
• ↓Le ticket.
• ↓La spec ou le PRD, parce qu'un ticket ne suffit jamais.
• ↓Le document UX, puis le plan d'implémentation.

Six transcriptions manuelles. Pas des copier-coller : six réécritures, chacune faite en lisant la précédente.

C'est ce que j'appelle une ressaisie, par opposition à une transformation. La distinction fait l'objet de la dernière partie, parce qu'elle n'a de sens qu'une fois qu'on a vu ce que la chaîne coûte.

Ce qui se perd, à chaque étape

Le pourquoi part en premier. Il tombe entre les notes et le résumé Slack. La justification prend trois phrases à écrire et n'intéresse personne le jour même : tout le monde était là, tout le monde sait. Trois semaines plus tard il ne reste que le quoi.

Les alternatives suivent. On avait évoqué trois façons de faire, on en a écarté deux pour de bonnes raisons, le résumé ne garde que la survivante. Six mois après, quelqu'un repropose une option morte et l'équipe refait le débat en entier sans savoir qu'elle le refait. J'ai vu ça arriver deux fois sur le même sujet.

Puis les contraintes. « Ça ne marchera pas pour les comptes multi-espaces », dit à la minute 26 par la seule personne de la salle qui le savait. Il n'y a aucun champ pour ça dans un ticket. On le redécouvre en recette.

La source part en dernier, et c'est la pire. Arrivé à la spec, plus rien ne relie l'exigence à la phrase qui l'a produite. Quand quelqu'un demande huit mois après sur quelle base on a décidé ça, il ne reste que la mémoire de quatre personnes. Quatre mémoires d'une réunion de quarante minutes, ça fait quatre réunions différentes.

Le point qui me gêne, c'est que personne n'a mal travaillé. Chacun a fait ce qu'on lui demandait : il a résumé. Résumer, c'est jeter, c'est la définition du mot. Le problème n'est pas qu'on résume mal. C'est qu'on résume six fois de suite.

Pourquoi quinze ans de wikis n'y ont rien changé

La réponse habituelle à ce constat, c'est le knowledge management. Un meilleur wiki. Une convention de nommage. Un modèle de PRD que tout le monde s'engage à remplir. Un canal Slack réservé aux décisions.

J'ai été ce type. J'ai écrit le modèle de PRD, avec les sections obligatoires et l'exemple rempli en haut. Il a tenu cinq semaines.

Ça ne tient jamais, et ce n'est pas un problème de discipline. Un wiki est un entrepôt : il suppose que l'information arrive bien formée à sa porte et qu'il suffit de la ranger au bon endroit. Or elle n'arrive jamais bien formée. Elle arrive en quarante minutes de parole simultanée, en fils Slack, en retour commercial glissé dans un message privé, en note vocale de treize secondes. Ranger ne coûte presque rien. C'est la mise en forme qui coûte, et c'est exactement ce qu'aucun wiki ne fait.

Le knowledge management répond à « où est-ce que je mets ça ? ». La vraie question est « qui transforme ça, et en quoi ? ».

Ressaisir et transformer

Reste la distinction annoncée plus haut. Elle vient en dernier parce qu'elle ne se comprend qu'après avoir vu le coût : deux choses qu'on confond en permanence parce qu'elles se ressemblent de l'extérieur.

Ressaisir, c'est reproduire à la main une information qui existe déjà ailleurs, dans un autre format. Ça ne crée rien. Ça coûte du temps, ça introduit des écarts, ça rompt le lien avec la source. Les six étapes du début sont six ressaisies.

Transformer, c'est un passage réel d'un état à un autre, déterministe, qui conserve son origine. Un transcript devient une liste d'énoncés attribués. Cette liste devient un jeu de features candidates. Une feature devient un périmètre technique. À chaque passage, la sortie sait d'où elle vient.

La différence pratique tient en une phrase : une ressaisie ne se rejoue pas. Si vous trouvez une erreur à l'étape 5, vous ne pouvez pas revenir à l'étape 2 et relancer, il faudrait que six personnes refassent leur travail. Une transformation, si.

Conséquence plus désagréable : tant que la chaîne est faite de ressaisies, l'automatiser ne sert à rien. Vous obtiendrez une machine qui résume un résumé de résumé, avec les mêmes pertes, en plus rapide. C'est d'ailleurs ce que font la plupart des outils de compte-rendu automatique. Ils remplacent l'étape 2 et laissent les cinq autres tranquilles. Le gain est réel et il est minuscule.

Ce qu'il reste une fois les ressaisies retirées

Presque rien à faire pour un humain. Presque.

Il reste les décisions. Est-ce que cette feature candidate est réelle, ou est-ce que le système a pris une phrase en l'air au sérieux ? Est-ce qu'on la fait ? Est-ce que ce périmètre est le bon ? Est-ce que cette contrainte UX passe ?

Ce sont les seuls moments où un humain apporte quelque chose qu'aucune machine n'apporte. Extraire, dédupliquer, reformater, propager, relier : on le fait à la main pour des raisons historiques, pas parce que c'est du travail humain.

D'où le critère qui m'intéresse le plus en ce moment :

Le nombre de points de contact humains dans une chaîne devrait être égal au nombre de décisions à prendre.

Dans une équipe produit normale, il est de six ou sept pour une seule décision. C'est le ratio à regarder. Pas le temps passé en réunion, pas la vélocité, pas la taille du backlog. Combien de fois quelqu'un touche l'information sans rien décider.

L'objection, et elle est bonne

« Une machine qui extrait des features de mes réunions va inventer des choses. »

Oui. Régulièrement. J'ai vu un système transformer « on pourrait imaginer que, un jour, peut-être » en feature candidate parfaitement formée, périmètre technique et définition de fini compris. Elle était impeccable. Elle n'aurait jamais dû exister, et il m'a fallu vingt secondes pour m'en rendre compte, ce qui veut dire que quelqu'un de moins attentif l'aurait laissée passer.

C'est pour ça que la conclusion n'est pas « automatisons la chaîne ». C'est : automatisons les transformations, gardons les décisions humaines, toutes les décisions et rien qu'elles.

Deux conditions, non négociables. Des portes d'abord : rien n'atteint un espace de travail ou un dépôt sans qu'une personne ait approuvé. La traçabilité ensuite : chaque élément produit porte sa source, la réunion, l'horodatage, la phrase exacte, pour que celui qui décide décide sur pièce et pas sur la confiance qu'il accorde au système.

Une machine qui décide est une machine qu'on ne peut pas auditer.

Je ne suis pas neutre là-dessus. C'est la thèse de Calliops et la raison pour laquelle je l'ai commencé.

L'exercice

Prenez votre dernière feature livrée. Remontez du ticket jusqu'à la réunion où elle a été décidée. Comptez les ressaisies, puis à chaque saut demandez-vous lequel des quatre est parti : le pourquoi, les alternatives, les contraintes, la source.

Chez moi c'était six, et à la cinquième le pourquoi avait déjà disparu. Il ne restait que le quoi.

Dites-moi votre chiffre.