Le coût du travail invisible

Le travail invisible est tout effort que l'équipe consacre sans qu'il soit suivi dans un système partagé. C'est plus courant que la plupart des équipes ne l'admettent, et il prend des formes prévisibles :

• Décisions prises dans des fils Slack. Un fil de 40 messages entre deux développeurs résout une question de conception, mais la décision n'apparaît jamais dans le ticket ou la description de la PR. Six mois plus tard, quelqu'un renverse la décision parce qu'il ne savait pas qu'elle avait été prise.
• Tâches « je vais juste le faire ». Un développeur remarque un test instable, passe deux heures à le corriger et ne crée jamais de ticket. Le travail a été fait, le temps a été dépensé, mais le plan de capacité de l'équipe ne le reflète pas — et personne n'apprend de la correction.
• Projets parallèles et explorations. Travail exploratoire qui vit sur une branche locale, n'est jamais révisé et meurt tranquillement ou surgit comme une PR surprise trois semaines plus tard.
• Correctifs non documentés. Un problème de production est corrigé à 23 h avec un commit direct sur main. Pas de ticket, pas de post-mortem, aucune trace que la correction existe ou pourquoi elle était nécessaire. Le prochain développeur qui touche ce code n'a aucune idée de ce que les trois lignes mystérieuses protègent.

Rien de tout cela n'est malveillant. Les développeurs font du travail invisible parce que la friction de le suivre semble plus élevée que le coût de simplement le faire. Et pour n'importe quelle instance unique, ils ont raison — créer un ticket pour une correction de 20 minutes ressemble à une surcharge.

Le problème n'est pas une instance unique. Le problème est le pattern.

Le travail invisible ne reste pas bon marché. Il s'accumule de trois façons qui deviennent plus coûteuses avec le temps.

Le coût d'intégration grimpe. Chaque décision qui vit dans la tête de quelqu'un au lieu d'être dans un ticket ou un document est une décision qu'un nouveau membre de l'équipe ne peut pas trouver. Une équipe avec six mois de travail invisible nécessite un transfert verbal de plusieurs semaines pour intégrer quelqu'un — et ce transfert est incomplet, parce que les personnes qui le donnent ont oublié la moitié de ce qu'elles ont fait. Les équipes avec des charges élevées de travail invisible rapportent régulièrement des temps d'intégration de 4 à 8 semaines pour un travail qui devrait prendre 2.

Le travail est dupliqué. Quand le développeur A ne sait pas que le développeur B a déjà résolu le même problème le mois dernier, le développeur A le résout à nouveau. Dans une équipe de 10 personnes, cela arrive plus souvent que quiconque ne le réalise — particulièrement avec le travail d'infrastructure, les fonctions utilitaires et les changements de configuration qui vivent en dehors de la base de code du produit principal.

Le contexte s'évapore. Le code sans trace de ticket est du code sans « pourquoi ». Le prochain développeur qui le lit voit ce qui a été fait mais pas pourquoi c'était fait, ce qui signifie qu'il ne peut pas le changer en toute sécurité. Il le laisse tranquille (accumulant de la dette technique) ou le change et brise l'hypothèse que l'auteur original protégeait (créant un bogue). Les deux résultats sont coûteux, et les deux sont évitables avec une description de ticket d'un paragraphe écrite au moment du travail.

L'accumulation est ce qui rend le travail invisible dangereux. Un seul correctif non documenté coûte cinq minutes de perte de contexte. Une année de correctifs non documentés coûte des semaines d'archéologie chaque fois que quelqu'un touche cette partie du système.