On commence souvent à mesurer le travail au moment où l’implémentation démarre. Pourtant, une bonne partie de l’effort a déjà eu lieu.

Quelqu’un a parcouru d’anciens tickets, cherché le bon interlocuteur, comparé plusieurs versions d’une règle ou attendu le retour d’une personne qui se souvient encore de la décision d’origine. Comme ce travail est dispersé entre messages, réunions et interruptions, il reste facilement invisible.

J’ai fini par le considérer comme une partie de la livraison, et non comme une simple préparation.

La connaissance est dispersée

La documentation est un point d’entrée, rarement le seul. Le contexte utile peut se trouver dans une colonne de base de données, un nom de champ, une note de version, un échange avec le support ou la mémoire d’une personne qui a travaillé sur le sujet plusieurs années auparavant.

Les personnes expérimentées naviguent vite dans cet ensemble parce qu’elles en connaissent déjà la carte. Elles savent quel ticket compte vraiment, quelle table peut induire en erreur et qui peut confirmer une hypothèse. Un nouvel arrivant voit les mêmes éléments sans disposer des mêmes repères.

Le problème n’est donc pas toujours l’absence de connaissance. Elle existe souvent, mais elle est difficile à trouver ou à juger fiable.

Une équipe peut recréer ce qu’elle possède déjà

J’ai vu une équipe préparer une nouvelle structure de données parce que personne, à ce moment-là, ne retrouvait celle qui existait déjà. La proposition était raisonnable et le travail engagé autour d’elle était bien réel. Ce n’est qu’ensuite qu’une personne disposant du contexte manquant a signalé que le produit couvrait déjà le besoin.

Ce n’était pas seulement un problème de documentation. C’était un problème de découvrabilité.

Quand le chemin vers une décision existante est incertain, reconstruire peut sembler plus sûr que continuer à chercher. L’organisation paie alors deux fois : une première fois pour la solution d’origine, puis une seconde pour la redécouvrir.

Le coût apparaît par fragments

Le coût de recherche ne se présente presque jamais comme une tâche bien identifiable. Il ressemble plutôt à une accumulation :

  • vingt minutes dans des tickets mal nommés ;
  • une courte réunion pour identifier le véritable responsable ;
  • plusieurs messages pour reconstituer l’historique ;
  • un après-midi à comparer code, configuration et documentation ;
  • un délai parce que la seule personne qui connaît le sujet est absente.

Pris séparément, chaque élément paraît mineur. Ensemble, ils peuvent représenter une part importante du travail, surtout dans un produit ancien.

Accélérer ne commence pas toujours par le développement

Améliorer l’implémentation reste utile, mais cela ne résout pas tous les ralentissements. Une équipe avancera difficilement si des questions simples restent coûteuses : où vit cette règle, qui peut décider, qu’a-t-on déjà essayé, quelle source est fiable ?

Des noms clairs, une responsabilité visible, quelques décisions tracées et une documentation maintenable réduisent cette distance. Il ne s’agit pas de tout enregistrer, mais de donner un point de départ fiable.

Chercher n’est pas une étape avant le vrai travail. Dans beaucoup d’équipes, c’est déjà une part importante du vrai travail.