Comment commander un logiciel sur mesure sans tomber dans le périmètre infini

Le périmètre infini n'est pas quelque chose que les prestataires vous infligent. C'est ce qui arrive quand personne dans la pièce ne définit ce que le logiciel ne doit pas faire. Un projet sans frontières explicites s'étend pour absorber chaque bonne idée qui surgit en chemin, et chacune de ces idées est, prise isolément, raisonnable. Le résultat est un chantier qui reste en permanence à trois mois de la fin.

La solution n'est ni un négociateur plus dur ni un contrat plus épais. C'est une autre façon de cadrer : définir le projet par les résultats opérationnels qu'il doit produire, pas par la liste des fonctionnalités qu'il devrait contenir. Nous le disons en tant qu'équipe qui construit des logiciels et exploite aussi ses propres produits en production. Faire tourner un logiciel après l'avoir livré apprend vite qu'un petit périmètre qui fonctionne dans une vraie journée vaut mieux qu'un grand périmètre qui n'existe que dans un document.

Pourquoi les listes de fonctionnalités créent un périmètre infini

Une liste de fonctionnalités a l'air rigoureuse, mais elle embarque une valve à sens unique. Chaque réunion ajoute une fonctionnalité, parce qu'ajouter ressemble à du progrès et ne coûte rien au moment de la planification. Personne n'en retire, parce que retirer ressemble à renoncer à quelque chose de déjà payé. La liste ne fait donc que grossir, et chaque ajout rend le suivant plus facile à justifier.

Puis la liste devient le cahier des charges, et le cahier des charges devient le conflit. Chaque ambiguïté, comme savoir si 'rapports' incluait l'export vers Excel, se transforme en négociation sur qui doit quoi. Le document censé protéger les deux parties devient le terrain sur lequel elles s'affrontent. Et pendant ce conflit, personne ne pose la seule question qui compte : le point 23 change-t-il quoi que ce soit à la façon dont l'entreprise fonctionne réellement ?

Cadrez par résultat

Un résultat opérationnel est un moment précis de l'activité qui doit être différent une fois le logiciel en place. Par exemple : un ouvrier de terrain photographie un reçu, et la dépense existe dans le système, catégorisée, avant qu'il ne remonte dans le camion. Cette seule phrase vaut mieux que trois pages de fonctionnalités d'un module de dépenses, parce qu'elle nomme qui, faisant quoi, avec quel résultat, et qu'elle se vérifie en observant une vraie personne dans une vraie journée plutôt qu'en lisant une checklist.

C'est ainsi que Cazullo cadre ses projets : comme un petit ensemble de moments nommés, chacun vérifiable dans l'opération réelle. Les fonctionnalités deviennent des détails d'implémentation, choisis par celui qui construit et jugés à l'aune du moment qu'ils servent. Ce qui ne sert aucun moment nommé est, par définition, hors périmètre. Pas rejeté, simplement pas dans ce projet.

La discipline de la v1

Une fois les moments nommés, la première version exige un acte de discipline supplémentaire : refuser l'étalement. Nous tenons cette ligne sur nos propres produits pour une raison égoïste, parce que c'est nous qui devons exploiter ce qui est livré.

• Un flux complet de bout en bout vaut mieux que cinq flux à moitié faits. Un reçu qui devient une dépense catégorisée, à chaque fois, est un produit. Cinq modules à 60 pour cent, c'est une démo.
• Le logiciel qui tient une vraie journée gagne le droit de grandir. Quand un flux porte l'opération réelle, la conversation de périmètre suivante s'appuie sur l'usage, pas sur l'imagination.
• Tout le reste est un backlog étiqueté, pas une promesse. Notez les idées écartées avec un nom et une raison, pour que les retirer de la v1 ressemble à un classement, pas à une perte.

Des formes de contrat qui aident

Aucune forme de contrat n'élimine la dérive de périmètre, méfiez-vous donc de quiconque prétend que la sienne y parvient. Certaines formes rendent toutefois l'honnêteté plus facile. La principale : des phases dont chacune se termine par quelque chose qui fonctionne, un livrable qu'une vraie personne utilise dans le vrai travail. 'Exigences finalisées' et 'architecture approuvée' sont des jalons de documentation, pas des livrables. Un ouvrier qui enregistre une vraie dépense dans le système, ça, c'est un livrable.

L'autre forme utile est la possibilité de s'arrêter après chaque phase sans laisser de décombres. Si le client peut partir après la phase un avec un logiciel qui fonctionne et qui lui appartient, alors le constructeur doit rendre la phase un réellement utile, et le client doit y mettre ce qui compte vraiment. Cette option de sortie garde tout le monde honnête, nous compris.

Des questions qui réduisent le périmètre

Quand la conversation de cadrage commence à gonfler, ces questions la dégonflent :

• Quel tableur meurt dans la v1 ? Si aucun tableur, groupe de messages ou processus papier ne disparaît, le logiciel est un ajout plutôt qu'un remplacement, et l'adoption le montrera.
• Qui l'utilise le premier jour ? Nommez de vraies personnes. Une fonctionnalité qu'aucune personne nommée ne touchera le premier mois appartient au backlog.
• Qu'est-ce qui casse si on coupe ceci ? Si la réponse honnête est 'rien pour l'instant', coupez.
• Comment l'opération se débrouille-t-elle pendant la construction ? Le contournement manuel révèle souvent quelle partie est vraiment urgente.
• Lesquelles de ces fonctionnalités quelqu'un a-t-il demandées, et lesquelles avons-nous imaginé que quelqu'un voudrait ?
• Que doit-il être vrai dans quatre-vingt-dix jours pour appeler cette phase un succès, sans que personne ne lance une démo ?
• Si le budget était réduit de moitié, que garderions-nous ? Ce qui survit à cette question est le vrai périmètre.

Commencez plus petit que ce qui semble confortable

Notre recommandation est directe : commandez le plus petit logiciel qui change un vrai moment opérationnel, mettez-le entre de vraies mains, et laissez ce qui se passe réellement écrire le périmètre suivant. Une v1 petite, en ligne et utilisée vous apprendra plus sur ce qu'il faut construire ensuite que n'importe quel cycle de planification. Venant d'une équipe qui doit exploiter ce qu'elle construit, ce n'est pas un compromis. C'est le chemin le plus rapide que nous connaissions vers un logiciel qui compte.