Comment définir le périmètre d’une première version que vous livrerez vraiment

Une première version qui prend huit mois vient rarement d’une équipe lente. C’est presque toujours un périmètre qui n’était pas viable, validé dans une salle où couper passait pour du pessimisme.

Bien définir un périmètre est une compétence, et c’est surtout celle de décider ce qu’on ne construira pas pendant que tout le monde est encore optimiste.

Partez de la boucle

Chaque produit a une boucle centrale : la séquence que l’utilisateur répète et qui délivre la valeur. Pour un dictionnaire : chercher, lire, comprendre. Pour une place de marché : publier, découvrir, transiger.

Écrivez la vôtre en une phrase. Puis triez chaque fonctionnalité proposée en deux tas : indispensable au fonctionnement de la boucle, et tout le reste.

Le second tas est presque toujours quatre à cinq fois plus gros qu’on ne l’imagine, et c’est là qu’est parti votre calendrier. Non parce que ces fonctionnalités sont mauvaises, mais parce qu’aucune n’était porteuse et que toutes étaient planifiées.

« MVP » ne veut plus rien dire

Le terme recouvre désormais deux choses incompatibles : un produit délibérément petit mais réellement bon sur une tâche, et un produit large mais mal fait. C’est le second que la plupart des équipes livrent, et il échoue parce que les utilisateurs pardonnent un produit étroit, pas un produit cassé.

Une formulation plus utile : étroit et terminé. Moins de choses, chacune faite correctement, états d’erreur et états vides compris. Une première version qui accomplit entièrement une tâche gagne le droit à une deuxième. Une qui accomplit huit tâches à 60 % ne le gagne pas.

Coupez dans le périmètre, pas dans la qualité. Couper dans la qualité est invisible sur un plan et parfaitement visible pour un utilisateur.

Les coupes généralement justes

Des choses qui semblent essentielles et qui peuvent presque toujours attendre :

• Les comptes, si la valeur existe sans eux. L’inscription est la plus grosse fuite de la plupart des tunnels. Laissez les gens utiliser la chose, et ajoutez les comptes quand il y a un état digne d’être sauvegardé.
• Les interfaces d’administration. Vous n’êtes pas l’utilisateur. Un client de base de données ou un script tiennent des mois.
• Les réglages. Chaque préférence est une bifurcation de comportement à construire et à tester. Choisissez une valeur par défaut sensée ; ajoutez l’option quand on la demande.
• Les parcours d’accueil. Une visite guidée est souvent un pansement sur une interface qui n’est pas évidente. Corrigez d’abord l’interface.
• La deuxième plateforme. Le web puis le mobile, ou une plateforme mobile puis l’autre. Faire les deux à la fois plus que double le travail et divise par deux la vitesse des retours.
• La localisation. Sauf si un marché précis est le marché de lancement. Traduire un produit qui change encore de forme, c’est le retraduire ensuite.

Les trois choses à ne pas couper

Les couper ressemble à de la vitesse et constitue une dette à taux élevé.

1. Les chemins qui tournent mal

États d’erreur, états vides, états de chargement, hors ligne. Cela représente environ un cinquième du travail et l’essentiel de la qualité perçue. Un produit qui gère l’échec avec élégance paraît solide même petit. Un produit qui affiche un écran blanc quand quelque chose casse paraît cassé, si bon soit le chemin heureux.

2. La mesure

Livrez sans analytique et votre première version ne vous apprendra rien. Vous ne saurez pas quelles parties sont utilisées, où les gens s’arrêtent, ni si la boucle se referme. Vous n’avez pas besoin d’un entrepôt de données ; vous avez besoin de savoir si la boucle centrale aboutit et où elle casse.

3. La capacité à déployer vite

Si publier un correctif demande une journée de manipulations, vous publierez moins de correctifs, et les premières semaines après le lancement sont justement celles où ils comptent le plus. Une chaîne de déploiement basique, c’est deux jours de travail remboursés dès la première quinzaine.

Découpez par parcours utilisateur, pas par couche

L’erreur de planification la plus fréquente est de construire horizontalement : tous les modèles de données, puis toute l’API, puis tous les écrans. Rien ne fonctionne tant que tout ne fonctionne pas, et vous n’apprenez rien avant la fin.

Découpez verticalement. Construisez un chemin complet de bout en bout, fin mais réel, puis élargissez-le. Dès la deuxième semaine vous avez quelque chose de cliquable. Cela fait passer la conversation d’imaginer le produit à réagir devant lui, et c’est là que vivent les retours utiles.

Une forme réaliste

Pour une première version resserrée, en gros :

Huit à seize semaines au total pour quelque chose d’étroit et de terminé. Si votre plan indique six semaines pour quelque chose de large, c’est le périmètre qui est faux, pas l’estimation.

Écrivez ce que vous avez coupé

Une pratique qui ne coûte rien et évite une discussion récurrente : tenez une liste explicite « hors v1 », visible de tous, avec une ligne de justification par entrée.

Elle transforme « on a oublié » en « on a décidé », empêche la même fonctionnalité d’être rejugée chaque mois, et devient votre backlog v2 déjà trié par la discussion menée au moment où vous aviez le plus de contexte.

Le test d’un bon périmètre

Deux questions, et il faut oui aux deux :

• Si nous ne construisions que cela, quelqu’un l’utiliserait-il ? Si non, vous avez coupé quelque chose de porteur.
• Pourrions-nous construire cela correctement, chemins ratés compris, dans le temps dont nous disposons ? Si non, coupez encore.

La plupart des plans échouent à la seconde question, et personne ne le dit avant la dixième semaine.