Minimum Viable Product
En développement logiciel, le Minimum Viable Product (MVP) est la stratégie qui consiste à construire un produit qui a le minimum de fonctionnalités pour être déployé et exploité par les utilisateurs cibles.
Cette démarche, initiée par les gourous du Lean Startup, est généralement conseillée et appliquée à des startups qui ont vocation à développer des produits innovants. L’idée est simple:
- Aller vite dans la mise en oeuvre pour avoir un produit opérationnel rapidement, avant de ne plus avoir de ressources.
- Aller à l’essentiel, en privilégiant d’abord les fonctionnalités qui ont le plus de valeur, et ne pas se disperser dans des fonctionnalités inutiles.
- Recueillir un feedback de la part des premiers utilisateurs pour savoir si on est sur la bonne voie et compléter ensuite le produit de façon incrémentale.
- Converger vers le produit qui recueillera les feedbacks positifs, vers le produit pour lesquels un utilisateur est prêt à payer.
Dans les projets, on avait l’habitude de faire une maquette ou un prototype pour valider ce à quoi devait ressembler une application; mais on jetait systématiquement la maquette à la poubelle, parce qu’elle n’était souvent pas faite dans les règles de l’art.
Avec le MVP, on est bien dans une considération de produit testable, mais pas jetable. Le premier jet est un produit qui rend une partie du service. Le feedback de l’utilisateur potentiel a beaucoup de valeur à ce stade, car il valide ou non l’idée du produit.
Cette démarche est bien adaptée à une logique de Startup, qui a besoin d’aller vite, avant de plus avoir de ressources, et de ne pas faire de dépenses inutiles. Comme souvent les Startup visent les early adopter, qui sont, en règle général, plus indulgent sur la complétude des produits, ce n’est pas grave de proposer un produit incomplet. Ce qui est important, c’est de montrer les fonctionnalités de base, et d’avoir un retour avant d’aller plus loin. Notre imagination nous pousse souvent à penser à beaucoup de fonctionnalités, alors que la mise en oeuvre révèle que cette imagination ne correspond pas toujours à quelque chose de valable. Le feedback utilisateur est là pour guider l’évolution du produit, pas à pas, vers quelque chose qui a une vraie valeur pour l’utilisateur.
Ce n’est pas tout à fait la même chose qu’une Beta, et ce sera souvent bien plus minimal que ce que vous pouvez imaginer pour votre produit. La version Beta est déjà le résultat d’un processus abouti, qui est en phase de consolidation. Le MVP se construit au fur et à mesure, avec les early adopters; on va d’abord rechercher l’expérience utilisateur pour construire le produit.
Cette idée peut aussi s’appliquer dans le contexte d’un projet d’entreprise plus mature. Après tout, certaines sociétés ont la volonté de continuer à fonctionner avec un esprit de Startup, et l’idée de faire converger un produit au fur et à mesure des besoins, est aussi au coeur de l’agilité. Un product owner doit penser à un MVP dans son cycle de développement. Ne pas gaspiller des ressources pour développer des fonctionnalités inutiles - le fameux YAGNI - est au coeur du Lean et une préoccupation des agilistes.
Cette démarche nécessite de pouvoir mettre en oeuvre rapidement une idée, d’avoir un résultat visible tout de suite, pour construire petit à petit à partir du résultat. Elle est possible si vous pouvez mettre en production tôt, et si vous savez travailler en cycles courts pour mettre en production souvent.
Et c’est exactement comme cela que nous travaillons, et que nous pratiquons l’agilité; on fait pousser les applications par l’usage. Et c’est possible, parce que l’on écrit très peu de code; tout simplement parce plus vous êtes léger, plus vous êtes facile à bouger.