Valider une idée avant de la développer

Écrire le problème avant la solution

Une idée d’outil arrive presque toujours déjà habillée en solution : « il nous faudrait une application pour… ». Commencez par écrire en trois lignes le problème seul, sans nommer d’outil : qui est gêné, à quel moment, combien de fois par semaine, et ce que ça coûte aujourd’hui.

Si ces trois lignes sont difficiles à écrire, le besoin n’est pas encore clair. C’est une information utile, et elle est gratuite.

Aller voir ceux qui feront le travail

La personne qui utilisera l’outil tous les jours n’est presque jamais celle qui a l’idée. Passez une heure à côté d’elle. Regardez ce qu’elle fait réellement, y compris les contournements qu’elle a inventés. Ces contournements décrivent le vrai besoin mieux qu’un cahier des charges.

Tester avec le minimum

Avant de développer, on peut souvent vérifier une idée avec très peu : une page qui décrit l’outil et un formulaire, pour voir si les gens s’inscrivent ; un tableur partagé utilisé pendant deux semaines, pour voir si la donnée est saisie ; une procédure faite à la main pendant quelques jours, pour voir si elle tient.

Ce n’est pas élégant, et c’est exactement le but : ce qui compte, c’est de savoir si le besoin résiste au contact du réel.

Décider avec une règle écrite d’avance

Avant de tester, écrivez ce qui vous fera continuer ou arrêter : combien de personnes doivent s’en servir, combien de fois, pendant combien de temps. Sans cette règle, on interprète toujours les résultats en faveur de l’idée qu’on avait déjà.

Ensuite seulement, construire

Quand le besoin est confirmé, une première version utilisable se construit en quelques semaines, pas en six mois. Elle sert à apprendre, pas à couvrir tous les cas. Les cas particuliers arrivent après, quand vous savez lesquels comptent vraiment.