U1 · Affiner un élément jusqu'à ce qu'il soit prenable · Lecture · 20 min
Un élément est prenable quand ces cinq conditions sont remplies. Pas quatre.
La dernière est celle qu'on escamote, et c'est la plus coûteuse. Prendre un élément avec une question en suspens, c'est se garantir un blocage à mi-parcours — et un blocage dont le client n'a pas été prévenu.
Pas un événement de démarrage : une habitude hebdomadaire. À tout moment, le haut de ta liste doit contenir environ deux semaines de travail prêt.
Moins, et tu te retrouveras un lundi matin sans rien de prenable, à improviser. Plus, et tu retombes dans le gaspillage de la fiche 6.1 : du travail de spécification investi dans des éléments qui changeront.
Quand un élément dépasse trois journées, il se découpe. Quatre façons, à essayer dans cet ordre :
Ce qui ne marche pas : découper par couche technique — « la base », puis « les vues », puis « les automatisations ». Aucun morceau n'est livrable seul, et l'on retombe sur des tâches déguisées.
C'est l'élément à plus fort impact du projet, estimé à six journées, donc trop gros. Découpé par type de données, il devient : les demandes téléphoniques entrent en base — deux jours, et c'est déjà 60 % du volume ; les mails entrent en base — deux jours ; les messages Instagram entrent en base — deux jours, et c'est celui qui dépend de la fille du gérant, donc le plus risqué.
Le découpage vient de rendre visible ce que l'estimation globale masquait : les deux tiers de la valeur sont accessibles sans toucher au morceau risqué.
Un élément n'est pas fini quand il est construit. Il est fini quand il est construit, testé sur un cas réel, validé par la personne concernée, et que celle-ci sait s'en servir.
Chez Vermont, « Sophie enregistre une demande en trois champs » n'est pas fini tant que Sophie ne l'a pas fait elle-même sur un vrai appel. Sans quoi tu découvriras à la bascule que le parcours ne tient pas les trente secondes.