En combien de temps une première version utile

La question arrive toujours au même moment : « et ça prend combien de temps ? »

La réponse honnête est qu’elle dépend d’une décision que vous n’avez pas encore prise — celle de ce que contiendra la première version.

Deux projets, deux calendriers

Un projet qui vise l’outil complet doit tout spécifier avant de commencer. Tous les écrans, tous les cas particuliers, tous les rôles. Cette phase prend des mois, pendant lesquels rien n’est utilisable, et elle repose sur une hypothèse fragile : que vous sachiez aujourd’hui ce dont vous aurez besoin dans un an.

Un projet qui vise la plus petite version utile fait l’inverse. Il choisit le maillon qui coince le plus, le construit, le met en service — et décide de la suite en regardant ce qui s’est passé.

Le second n’est pas seulement plus rapide. Il est moins cher, parce qu’on ne construit jamais ce dont personne ne se sert.

Ce que « utile » veut dire

Une première version utile n’est pas une maquette, ni un prototype qu’on montre en réunion. C’est un outil que quelqu’un ouvre le matin pour travailler, et qui lui manquerait s’il disparaissait.

Ce critère est exigeant. Il élimine les tableaux de bord qui n’aident personne à décider, les écrans construits « parce qu’il en faudra bien un », et les fonctionnalités demandées par précaution.

Il en reste toujours moins qu’on ne croyait.

Comment on découpe

Trois questions suffisent à trouver le premier morceau.

Quelle étape fait perdre le plus de temps, aujourd’hui, à la personne qui la subit ? Pas la plus visible en réunion : celle qui coûte réellement.

Que se passe-t-il si on ne traite que celle-là ? Si la réponse est « déjà beaucoup », c’est le bon point de départ.

Qu’est-ce qui peut rester manuel encore quelques semaines ? Presque tout, en général. Le manuel n’est pas l’ennemi ; le manuel répété et invisible l’est.

Ce qui rallonge vraiment un projet

Ce n’est presque jamais le développement.

Les décisions en attente. Une question posée qui reste sans réponse trois semaines coûte trois semaines. C’est le premier facteur de dérive, et il ne dépend pas du prestataire.

Les données à nettoyer. Si l’information de départ vit dans des fichiers tenus selon quatre conventions différentes, il faut d’abord la remettre d’aplomb. Ce travail n’est pas du développement, et il prend le temps qu’il prend.

Le périmètre qui grossit en route. Chaque « tant qu’on y est » rallonge la première mise en service, donc retarde le moment où l’outil commence à servir.

Ce que ça donne en pratique

Nos premières versions se livrent en quelques semaines, pas en quelques trimestres. Elles ne couvrent pas tout, et c’est volontaire : elles couvrent assez pour être utilisées tous les jours.

Ensuite, on regarde. Ce qui sert beaucoup se renforce. Ce qui ne sert pas ne se construit pas davantage. C’est ainsi que les outils dont parlent les pages de ce site ont été bâtis, module après module.

Pour situer votre propre découpage, décrivez votre situation au diagnostic : il vous répond en moins d’une minute.