Un logiciel n'est utile qu'à l'usage

Dans tout projet, il arrive un moment où la roadmap semble plus importante que la livraison. Un beau planning, un large ensemble de fonctionnalités, une mise en ligne dans six semaines. Ça paraît confortable.

C’est l’inverse du confortable. Un logiciel qui ne se retrouve pas entre les mains de quelqu’un dans les semaines qui suivent ne s’y retrouve souvent jamais. Le monde a avancé, le budget est épuisé, l’enthousiasme retombé, ou l’utilisateur qui devait s’en servir est passé depuis longtemps à autre chose.

Deux semaines, pas deux mois

Je travaille en itérations de semaines, pas de mois. Pas par principe têtu, mais parce qu’un utilisateur final ne dit quelque chose d’utile qu’une fois qu’il a quelque chose entre les mains. Tant que c’est sur papier, tu reçois des politesses. Dès que ça fonctionne, tu reçois la vérité.

• La première livraison est utilisable, pas complète.
• On affine sur la base de retours réels.
• Ce que personne n’utilise est supprimé.

Dix ans de développement m’ont appris : une fonctionnalité que personne n’a utilisée n’a pas non plus droit à des heures supplémentaires. Mieux vaut découvrir en deux semaines que quelque chose ne fonctionne pas, plutôt que de le constater après trois mois.

La boucle de retour, c’est le vrai travail

Dès que quelque chose est entre les mains de quelqu’un, la conversation change. « Ce bouton ne fait pas ce que je pensais » vaut plus que cent notes d’atelier. Le premier vrai bug en dit plus que deux semaines de planification, parce qu’il oblige à regarder ce qui gêne réellement.

C’est pour ça que j’ose livrer tôt, même quand la pièce est encore brute. Ce qui est en ligne se peaufine par étapes. Ce qui reste coincé entre conception et livraison meurt entre conception et livraison.

Les roadmaps sont internes

Les roadmaps sont un instrument pratique pour moi en tant que développeur — pas une promesse à l’utilisateur final. Une roadmap que le client claironne devient une dette. Une roadmap qui reste tranquille dans ma tête reste un outil. Laquelle des deux te livre un logiciel qui fonctionne, à toi de deviner.

Pas de jalons qui restent sur l’étagère.

Voilà ce que veut dire être utilisé.

Ce que ça veut dire pour ce que mes clients reçoivent de moi

Pas de livraison purement démonstrative. Pas d’écran qui ne fonctionne bien qu’à la réception. Pas de fonctionnalité « en ligne » qu’on ne trouve nulle part. Petit, tôt, en usage — et seulement ensuite construire la suite sur ce que tu as réellement appris.

Le pire résultat n’est pas un projet qui s’écarte de la roadmap. Le pire résultat, c’est un projet qui a suivi exactement la roadmap — mais dont personne ne peut dire avec certitude s’il est vraiment utilisé quelque part.