Le scope-creep se cache dans les mots
J'avais gelé le périmètre de mon jeu. Puis j'ai écrit une feuille de route qui, sans jamais mentir, avait ré-étiqueté en "finition" des chantiers rangés pour après la sortie. Petite mécanique du scope creep, et le document qui m'a arrêté.
Ma feuille de route ne savait plus si elle finissait ou grossissait
Fin juin, j'avais gelé le document de design de mon jeu. Gelé veut dire : figé, plus aucune modification sans décision écrite. Dedans, une frontière nette. D'un côté le périmètre de la 1.0 : un vaisseau, un boss, la station. De l'autre, une liste explicitement estampillée "après la 1.0" : des boss supplémentaires, un deuxième vaisseau, la traduction anglaise.
Quelques jours plus tard, j'écris une feuille de route intitulée "le chemin vers la 1.0". Je la relis, et je n'arrive plus à dire si elle finit le jeu ou si elle le fait grossir. Les boss en plus, le deuxième vaisseau, la traduction : tous présents, tous repeints "vers la 1.0". Aucune ligne ne ment. Chacune est raisonnable. Et pourtant l'ensemble avait avalé, sans que je le voie, une partie de ce que mon document gelé rangeait pour plus tard.
"Finir" et "grossir" se ressemblent trop
Le problème n'est pas la mauvaise foi, c'est le vocabulaire. Dans la prose d'une feuille de route, "finir le jeu" et "agrandir le jeu" s'écrivent avec les mêmes verbes : ajouter, compléter, enrichir, polir. Un deuxième vaisseau, ça "complète l'offre". Des boss en plus, ça "densifie la fin". La traduction, ça "élargit le public". Tout élargissement se raconte comme une finition.
C'est ça, le scope creep, l'élargissement silencieux du périmètre : rarement une grosse décision qu'on assume, presque toujours une série de reformulations qui ne se présentent jamais comme des ajouts. Sur mon titre, le décor rendait la dérive absurde : 16 téléchargements, 0 abonné. Aucun signal ne réclamait plus de contenu. Et ma propre feuille de route proposait quand même plusieurs chantiers post-1.0 déguisés en dernière ligne droite.
La parade : un document qui dit non à ma place
Un audit du plan (cinq relecteurs et un arbitre) a nommé la chose : la feuille de route re-labellisait du contenu post-1.0 sans amendement, sans chiffrage, sans borne. La correction n'a pas été "faire plus attention". Se méfier de soi ne tient pas dans la durée. J'ai remis le document gelé au centre et posé trois règles simples.
Le mot qui compte est "avant". Une réintroduction datée avant le commit (l'enregistrement d'une modification dans l'historique du code) laisse une trace ; une décision prise dans le feu de l'implémentation n'en laisse aucune. Le document ne me rend pas plus discipliné, il me force à écrire ma décision là où je la relirai, au lieu de la laisser fondre dans une phrase de roadmap.
- La liste "hors périmètre" reste gelée. Elle ne bouge pas parce qu'une feuille de route en parle joliment.
- Chaque item du plan se confronte à cette liste, un par un. S'il y figure, il est hors 1.0. Point.
- Réintroduire un item exige une ligne écrite, datée, AVANT la première ligne de code. Pas après, pas "on verra".
Partout où une spec est gelée
Le piège ne tient pas au jeu vidéo. Il se déclenche dès qu'un plan d'action côtoie une spécification gelée (le périmètre décidé une fois pour toutes) et qu'on laisse le premier commenter la seconde. Un backlog produit (la liste des travaux en attente), les tâches d'un projet client, une feuille de route personnelle : partout où on peut ré-étiqueter un item sans amender la référence, l'expansion se déguise en finition.
La parade est toujours la même, et elle est ennuyeuse : rendre la réintroduction coûteuse en la rendant explicite. Une ligne. Datée. Avant le code. Ce n'est pas la volonté qui tient le périmètre, c'est le geste d'écrire noir sur blanc qu'on en sort.