Le Minimum Viable Product (MVP) est une percée dans le monde de la conception de produits numériques. Le produit se construit comme une suite de poupées ukrainiennes, d’une petite (le MVP) vers une plus grande qui peut l’absorber et ainsi de suite jusqu’au produit final. Travailler en MVP sécurise à la fois le service rendu par le produit et la qualité du produit.

Le Minimum Viable Product (MVP) a du sens dans le domaine suivant : construire une stratégie de construction d’un produit numérique qui sécurise à la fois le service rendu par le produit et la qualité du produit. Le MVP sécurise beaucoup d’aspects de la conduite de projet : la définition du produit cible, l’identification très en amont des difficultés techniques, la collecte des dépendances qu’il faudra traiter, un meilleur étalement de la charge pour les testeurs, un début de formation des utilisateurs, un identification précoce des éventuelles erreurs de conception,  etc.

Nous vous proposons dans cet article plusieurs bonnes pratiques issues de notre expérience.

Bonne pratique lean n°1 : prendre des décisions en réfléchissant sur des faits plutôt que sur des modèles

Le MVP réduit la période de conception et permet de passer bien plus rapidement à l’acte. Ainsi le collectif qui a la responsabilité de créer le produit se confronte très vite à la réalité : identification très en amont des difficultés techniques, collecte des dépendances qu’il faudra traiter, meilleur étalement de la charge pour les testeurs, début de formation des utilisateurs, identification précoce des éventuelles erreurs de conception, etc.

Bonne pratique lean n°2 : mettre le client au centre

LE point clé du MVP : il doit générer une vraie valeur pour un vrai utilisateur ou un vrai client, donc être utilisable. Cette règle oriente très vite la sélection du périmètre du MVP. D’autres critères de choix vont apparaitre en fonction des sujets, tels que, par exemple, la fonctionnalité qui aura le moins de dépendance, les contraintes ou les disponibilités des opérationnels futurs utilisateurs, la logique de micro-déploiement local, les contraintes de disponibilité ou d’ordonnancement technique….

Au démarrage, comprendre son client et ses préférences est donc une activité clé de l’équipe en charge du produit.

Dès que le produit est utilisé, les feedbacks utilisateurs sont collectés, traduits en nouvelles préférences, elles-mêmes déclinées sur l’un des nœuds de la représentation visuelle du produit. L’équipe produit fait des allers-retours permanents entre les attentes identifiées et les choix fonctionnels et techniques.

Bonne pratique lean n°3 : représenter visuellement le produit

Un bon management visuel est une pratique classique des démarches lean. Dessiner permet aux participants d’expliciter leurs propres idées, de les confronter et d’obtenir collectivement une image de la situation.

En matière de produit numérique, il peut y avoir plusieurs dimensions : ce que fera le produit (les aspects fonctionnels), quels systèmes vont le constituer (Modules de traitement, Bases de Données, Flux, micro-services, applicatifs), sur quelle infrastructure informatique il sera instancié (quelles machines, quels réseaux, on-premises ou Cloud, etc.), ainsi que sur quelle géographie il devra être déployé (pays, usine ou tours, ateliers, lignes de production ou services).

Bonne pratique lean n°4 : clarifier la situation

A l’aide du management visuel, les participants peuvent faire apparaitre un état de la situation sur chacune de ces dimensions :

• Que sait-on, qu’ignorons-nous et que devons-nous découvrir ?
• Quelles briques technologiques existent déjà, que faut-il faire évoluer, que va-t-on devoir créer, que faudra-t-il décommissionner ou supprimer ?
• Où se situe la complexité ?
• Sur quoi ne sommes-nous pas d’accord ? Inquiets ?
• De quelle volumétrie parle-t-on ?
• Qu’est ce qui restera en dehors du périmètre du projet ?
• Quel est l’objet essentiel que nous sommes en train d’oublier ? 

Le post it rouge trouve un usage intense, en écho à tous les sujets que l’équipe découvre au fur et à mesure de la création du produit. Il ne s’agit plus de livrer un cahier des charges mais bien de prendre en continu les meilleures options, sur le produit.

Bonne pratique lean n°5 : continuer itérativement et incrémentalement cette livraison du produit de plus en plus riche, sur un rythme qui ne change pas

Le MVP vise a réaliser une première pièce bonne de bout en bout sur la partie la plus simple du processus et sur une pièce simplissime, tout en documentant la manière dont on s’y est pris sous forme de standard. Pour un site de vente sur internet, le MVP offrira la possibilité d’acheter un produit avec une carte visa et de se le faire livrer. Ni plus, ni moins.

La release suivante du produit vise à tester la répétabilité des pratiques précédentes sur un petit lot de cas voisins. Peut-on par exemple commander plusieurs produits ou payer avec une carte mastercard.

La troisième release vise à tester l’adaptation de ces standards à un cas de complexité / ou de périmètre un peu supérieur.

Et ainsi de suite en progressant sur les deux axes complexité / complétude, en gardant la complexité maximale pour la fin, c’est-à-dire pour le moment ou nos connaissances et nos outils sont proche de leur maximum, plutôt que de commencer par le plus complexe au moment où l’on en connait le moins.

LA pratique experte : livrer toutes les deux semaines

La discipline lean invite à un cycle court de livraison : 3 mois, c’est souvent un premier progrès, 4 semaines c’est mieux, deux semaines on rentre dans l’efficacité. On parle bien sur ici de livrer un « produit qui marche » en production.

Est-ce utopique ?

Non, ce n’est pas une utopie puisque différentes équipes que nous connaissons y parviennent. En revanche, ces équipes ont réellement adopté le lean et son esprit constant d’amélioration et s’y adonnent depuis plusieurs années.

Un exemple pour conclure

Un exemple très technique, mais bien réel. Nous avons accompagné une équipe en charge construire un automate pour sécuriser des serveurs dans le cadre d’un renforcement de la politique de cybersécurité. On parle de 6 000 serveurs ! 

En choisissant la famille la plus simple, c’est-à-dire dans ce cas précis un seul serveur mono instance porteur d’une seule application non critique, sont apparus des problèmes de gestion de droits d’accès, la gestion de la mise à niveau des patchs, la révision du monitoring des serveurs, etc… 

1 sur 6000, c’était la bonne taille de MVP. La simplicité de ce MVP a rendu ces obstacles évidents et surtout permis leur résolution documentée. Tant que la compréhension de ces problèmes sur un unique objet, et leur résolution, n’était pas là, il était impossible de déployer à l’échelle.

Les photos sont issues d’une formation organisée par Operae Academy. Si le sujet du MVP ou de l’Obeya de produit vous intéressent, contactez-nous !

Mail : contact at operae-academy.fr

Web : www.operae-academy.fr