7 October 20257 min de lecture
Presque toutes les conversations désagréables d’une mission externalisée sont la même conversation. Le travail a été livré, la facture est arrivée, et une partie considère que l’élément est terminé quand l’autre non. Aucune n’est de mauvaise foi. Elles appliquent deux standards différents, tous deux parfaitement raisonnables, parce que personne n’en a jamais écrit un.
Une définition du « terminé » est le document le moins cher du logiciel. Elle tient généralement sur une page, elle prend un après-midi, et elle supprime toute la catégorie de disputes qu’elle couvre.
Pourquoi le « terminé » est l’endroit où les missions échouent
Dans une équipe qui travaille ensemble depuis des années, le « terminé » est un instinct partagé. Chacun sait qu’un changement n’est pas fini tant qu’il n’a pas de test, qu’il n’a pas été relu, qu’il n’a pas une entrée dans le journal des modifications et qu’il n’a pas été vérifié en préproduction. Personne ne le dit, parce que personne n’a eu besoin de le dire depuis la deuxième année.
Faites venir quelqu’un de l’extérieur, et cet instinct ne se transmet pas avec le ticket. Cette personne a le sien, forgé sur d’autres systèmes avec d’autres standards. Quand les deux divergent, cela apparaît au pire moment : à la recette, avec une échéance derrière et de l’argent en jeu. La discussion prend alors l’allure d’un différend sur la compétence, alors qu’il s’agit en réalité d’un différend sur une règle non écrite.
Cela n’est pas propre à l’externalisation. C’est propre à toute personne qui n’a pas absorbé vos habitudes en s’asseyant à côté de vous pendant un an, ce qui inclut aussi chaque nouveau salarié. L’externalisation fait simplement arriver le moment plus tôt, avec une facture à la clé.
C’est un contrat passé avec votre futur vous-même
La raison de l’écrire n’est pas de tenir un prestataire pour responsable. C’est d’obliger votre propre équipe à décider de ce qu’elle exige réellement, avant qu’une pression ne s’exerce pour accepter quelque chose de presque fini.
C’est la partie inconfortable. La plupart des équipes découvrent, à mi-chemin de la rédaction de leur définition du « terminé », qu’elles ne sont pas d’accord entre elles. L’un pense que chaque changement a besoin d’un test, l’autre que les tests servent aux parties qui cassent, un troisième n’y a jamais réfléchi. Ce désaccord était toujours là, produisant en silence des standards de revue incohérents. Le document ne crée pas le problème, il le révèle, et c’est là l’essentiel de sa valeur.
Ce qu’elle doit contenir
Tenez-vous-en à des points vérifiables par quelqu’un qui n’était pas dans la conversation. Si deux personnes raisonnables peuvent regarder le même changement et diverger sur le respect d’une ligne, la ligne n’est pas terminée.
- Le code est relu et approuvé par quelqu’un d’autre que son auteur.
- Les vérifications automatisées passent sur la branche, et la liste de ce qui compte comme vérification est nommée, pas sous-entendue.
- Des tests existent pour le comportement décrit par le ticket, au niveau que votre équipe utilise réellement.
- Cela a été éprouvé en préproduction sur des données réalistes, par quelqu’un, et ce quelqu’un est nommé dans le ticket.
- Tout ce qu’un utilisateur ou un autre ingénieur doit savoir est consigné par écrit : notes de version, README mis à jour, note d’architecture, selon le cas.
- Les feature flags, les migrations et les changements de configuration sont décrits, y compris la façon de les annuler.
- Les erreurs et la journalisation existent pour les chemins d’échec, pas seulement pour le chemin heureux.
Sept lignes, c’est beaucoup. Cinq a plus de chances de survivre. Le document qui est réellement suivi est assez court pour qu’on le garde en tête pendant une relecture.
Ce qu’elle ne doit pas contenir
Les critères d’acceptation d’un ticket donné ne font pas partie de la définition de « terminé ». Ils décrivent ce que ce travail précis doit faire, ils changent à chaque fois, et leur place est dans le ticket. La définition de « terminé » décrit ce qui doit être vrai de tout travail, quel qu’il soit. Mélanger les deux produit un document soit énorme, soit inutile.
Les aspirations n’y ont pas leur place non plus. Si vous écrivez « la performance est mesurée et ne régresse pas » alors que personne n’a jamais mesuré la performance de ce système, vous n’avez pas relevé le niveau. Vous avez écrit une ligne que l’on saute à chaque fois, ce qui apprend à tout le monde que le document est décoratif.
Évitez aussi les critères que vous ne pouvez pas vérifier à distance. Un critère qui suppose que quelqu’un se déplace jusqu’à un bureau n’est pas un critère dans une équipe distribuée.
Une définition par équipe, pas par ticket
Certaines équipes tentent de graduer le standard : léger pour les petits changements, complet pour les grands. C’est raisonnable en principe et cela s’effondre en pratique, car la graduation elle-même devient le sujet de dispute. Chacun trouve que son propre changement est petit.
Un seul standard, appliqué à tout, avec des exceptions explicites et écrites quand vous devez réellement livrer à deux heures du matin. Le fait que l’exception soit visible est tout l’enjeu. Un standard qui plie discrètement n’est pas un standard, et une équipe distribuée ne peut pas distinguer une entorse d’une règle avant de vous avoir observé pendant six mois.
La conversation de recette
Avec une définition du « terminé » en place, la recette cesse d’être un jugement et devient une comparaison. Soit la checklist est satisfaite, soit elle ne l’est pas, et si la réponse est qu’elle l’est mais que vous restez insatisfait, c’est une information réellement utile : il manque une ligne à votre définition du « terminé », et vous venez de trouver laquelle.
Ajoutez la ligne. Ne l’ajoutez pas rétroactivement à la facture que vous êtes en train de contester. Assumez la perte sur ce point, changez le document, et cela ne se reproduira pas. Vouloir appliquer une nouvelle règle à un travail réalisé sous l’ancienne, c’est ainsi que l’on dépense la bonne volonté, et la bonne volonté est ce qui rend la prochaine conversation difficile peu coûteuse.
Revoyez la définition, pas seulement le travail
Reprenez le document une fois par trimestre avec les deux parties autour de la table. Deux questions : quelle ligne avons-nous le plus souvent sautée, et quel problème est arrivé en production malgré la liste. La première vous dit quelle ligne est irréaliste et devrait être supprimée ou modifiée. La seconde vous dit ce qui manque.
Une définition du « terminé » qui n’a pas changé depuis un an est soit extrêmement bien écrite, soit, bien plus probablement, inutilisée. C’est un outil de travail adapté à la façon dont cette équipe précise construit ce système précis, et ces deux éléments évoluent en permanence.