Le réflexe
“C’est dans la spec.”
La demande arrive, tu l’exécutes. Le pourquoi appartient à quelqu’un plus haut dans le bâtiment.
Le réflexe builder
“Ça résout quel problème, et pour qui ?”
Tant que cette réponse n’est pas entre tes mains, la construction n’a pas commencé.
Pourquoi
Une demande arrive déjà traduite, et chaque traduction perd quelque chose.
Un client dit qu’il ne retrouve pas ses factures du mois dernier. Le support écrit “ajouter une barre de recherche”. Le produit écrit “recherche sur la page factures”. Le ticket dit “ajouter recherche”. Tu livres la recherche. Le client ne retrouve toujours pas ses factures du mois dernier, parce qu’elles étaient rangées sous un deuxième compte dont personne n’a parlé.
Quatre personnes honnêtes, une fonctionnalité inutile, trois semaines.
Le pourquoi, c’est aussi ce qui tranche les quarante micro-décisions entre lundi et vendredi. Quel cas limite traiter, lequel abandonner, si l’état vide compte, ce qui se passe quand le réseau coupe au milieu. Personne ne relit ces quarante décisions. C’est pourtant là que se décide la forme réelle du produit.
À essayer
Avant de commencer la prochaine tâche, écris une ligne en haut du ticket.
Ça existe pour que [qui] puisse [quoi], parce qu’aujourd’hui [problème].
Tu n’arrives pas à la remplir ? Remplis-la faux exprès et envoie-la à celui qui a ouvert le ticket. Une hypothèse fausse est corrigée en dix minutes. Une question ouverte attend trois semaines.
À discuter
La dernière fois que quelqu’un ici a demandé “pourquoi on fait ça ?”, c’est passé pour une bonne question ou pour un refus de travailler ?