Geler une V1 consiste à protéger un objectif de livraison, tout en laissant entrer les corrections indispensables. Toute nouvelle demande doit être comparée au résultat que la version doit permettre.
Une règle d’entrée explicite
Dans un portail fictif de suivi de commandes, la V1 doit permettre de consulter un état fiable. Un défaut qui affiche la commande du mauvais client bloque la sortie. Une demande de graphique annuel ne la bloque pas. La distinction porte sur la promesse de la version, pas sur l’ancienneté ou l’insistance du demandeur.
| Demande | Décision proposée |
|---|---|
| Atteinte aux données ou aux droits | Corriger avant ouverture |
| Parcours principal impossible | Corriger ou réduire la promesse |
| Confort sans effet sur le résultat | Placer dans la revue suivante |
| Nouvelle clientèle visée | Revoir le périmètre séparément |
Rendre l’arbitrage traçable
Conservez la demande, son origine, l’impact attendu et la décision. Si une fonctionnalité entre, indiquez ce qui sort ou quel délai change. Un périmètre qui grandit sans contrepartie produit une estimation trompeuse. Préparez une démonstration de la V1 avec les mêmes scénarios que ceux retenus au cadrage.
Que faire d’un retour tardif pertinent ?
Examinez le risque de livrer sans le changement et celui de l’introduire précipitamment. Une correction urgente peut nécessiter de reporter la sortie ; une amélioration peut attendre un lot suivant. Le gel n’interdit pas de réfléchir : il rend les conséquences visibles avant de décider.
Du guide à votre projet
Produit ↗
L’expérience relie votre promesse à l’action que l’utilisateur vient accomplir. Nous concevons ce parcours avant de multiplier les écrans.
Parlez-nous de votre idéeLes exemples sont pédagogiques et ne décrivent pas des résultats clients. Contenu préparé avec assistance IA ; voir notre politique éditoriale. Notre méthode ↗