Le désaccord doit bien avoir lieu quelque part
Chaque projet contient un désaccord : sur le modèle de données, sur la frontière entre deux systèmes, sur ce qu'il se passe quand un tiers est indisponible. Ce désaccord finira par apparaître. La seule question est de savoir s'il apparaît dans un document, dans une revue de code, ou en production à deux heures du matin.
Le document est de loin le moins cher des trois. Nous le plaçons donc délibérément en premier.
Ce que contient le document
Six sections, et rien d'autre.
1. Le résultat visé
Ce qui change pour l'entreprise quand cela fonctionne, écrit de façon mesurable. « Ramener la clôture mensuelle de trois jours à moins d'une journée » est un résultat. « Moderniser le SI financier » est une humeur.
2. Le modèle de données
Les entités, leur propriétaire, et l'endroit où réside la source de vérité pour chacune. La plupart des douleurs d'intégration viennent de deux systèmes qui croient tous deux posséder le même enregistrement.
3. Les frontières
Chaque système avec lequel nous échangeons, et ce qu'il se passe quand il est indisponible. Pas « nous gérerons les erreurs », mais précisément : réessai, mise en file, dégradation, ou échec visible.
4. La surface de sécurité
Qui peut atteindre quoi, et comment cela est appliqué — pas simplement souhaité. Une phrase disant « seuls les administrateurs peuvent le faire » ne vaut rien sans le mécanisme.
5. Les arbitrages retenus
Chaque décision significative, avec l'alternative écartée et la raison. C'est ce qui rend le document utile à l'ingénieur qui arrivera dans un an.
6. Ce que nous ne faisons pas
La section qui évite le plus de reprises.
Pourquoi la section six compte le plus
La dérive de périmètre arrive rarement sous forme de nouvelle demande. Elle arrive sous forme d'hypothèse que personne n'a écrite : le client supposait le multidevise inclus, nous supposions le contraire, et personne ne l'a découvert avant la démonstration.
Lister explicitement les non-objectifs, et les faire valider par écrit, nous a évité plus de gaspillage que n'importe quel autre processus.
Quand cela n'en vaut pas la peine
En dessous de deux semaines de travail, c'est de la surcharge. Nous écrivons un paragraphe et nous démarrons.
Le document devient rentable dès que plusieurs personnes, plusieurs systèmes ou plusieurs mois sont en jeu — c'est-à-dire pour l'essentiel de ce qu'on nous demande de construire.