La conférence Ignite Talk* suivante a été donnée par Benjamin Wyss lors des DevOps Days 2022 à Zurich.
*Les orateurs disposent de 5 minutes et de 20 diapositives qui défilent automatiquement toutes les 15 secondes, ce qui permet une présentation rapide et amusante.
vidéo
Parler
Salut à tous.
Je suis Benjamin d'Infometis et aujourd'hui, j'aimerais partager avec vous mes réflexions sur le fameux et tristement célèbre Produit Minimum Viable (MVP).
En tant que responsable des achats, je souhaite proposer des produits aussi simples que possible.
Parce que chaque fonctionnalité
- est une source potentielle d'erreurs de toute nature
- nécessite un entretien
- ou peut rendre un produit plus complexe
C'est là qu'intervient le titre de MVP. Mais revenons d'abord sur les événements précédents.
En 2001, un certain Frank Robinson a tenté de résoudre le problème selon lequel le nombre de fonctionnalités est plus important que la valeur qu'elles apportent réellement.
Il a très tôt compris la différence entre les résultats et la production.
Frank a dit : « Nous pouvons trouver le produit minimum viable (MVP), là où le retour sur investissement est élevé et l'effort faible. ».
Certains d'entre nous l'appelleraient le principe de Pareto, ou simplement le principe 80/20.
En 2011, le MVP a gagné en popularité grâce à la Lean Startup . Pourquoi ? Parce qu'il a frôlé l'échec !
Les grandes entreprises peuvent attendre, mais les investisseurs en capital-risque, eux, veulent voir des progrès.
Et nous savons…
…Un logiciel fonctionnel est le principal indicateur de progrès ! Le reste n’est que garniture pour votre plat principal : le produit savoureux.
Mais qu’est-ce qu’un « produit savoureux » ?
Nous formulons des hypothèses à ce sujet. Et avec le MVP, nous voulons les tester au plus tôt.
Et c'est une bonne chose, car les humains ont tendance à poursuivre des activités inutiles simplement à cause des ressources qu'ils ont déjà dépensées.
Voici la recettepour quelque chose de viable
- Les besoins fondamentaux non exprimés
- Des exigences de performance suffisantes que vos parties prenantes demanderont
- et des trucs sympas que vos utilisateurs vont adorer
Et pour chaque besoin que vous souhaitez satisfaire…
…essayez de trouver la solution la plus simple possible – Ou comme le dit le Manifeste :
« La simplicité – l’art de maximiser la quantité de travail non effectué – est essentielle. »
GitLab écrit dans ses valeurs: « Nous optons toujours pour les solutions ennuyeuses ».
Et je trouve ça formidable. Consacrer du temps à réfléchir à la simplicité dès le départ vous rendra plus rapide sur le long terme.
Partant de ce principe, nous pouvons rechercher la solution la plus ennuyeuse pour répondre au moins de besoins possible.
N'oubliez pas d'associer vos parties prenantes à vos décisions. Vous pourriez avoir à argumenter..
…mais c’est bien mieux que d’avoir ce genre de discussion après coup. Pour éviter que cela ne se reproduise, il faut aussi certaines conditions préalables de l’environnement – ou au moins la volonté de les créer.
Par exemple:
Un MVP n'est pas une fin en soi. Il permet de tester vos hypothèses. Par conséquent, vous devez être prêt à construire, mesurer, apprendre et vous adapter.
Quelqu'un sur Internet a dit un jour que Léonard de Vinci avait dit :
«L'art n'est jamais fini, seulement abandonné.».
Et dans le grand ouvrage « The Professional Product Owner », cela est écrit comme suit :
« Parce qu’aucun produit n’est jamais « terminé », on crée une série de MVP, l’un après l’autre ».
Malheureusement, dans le monde des projets, où le principal indicateur de progrès est le plan de projet et le nombre de « fonctionnalités », soit la première et la dernière chose que les clients voient est le MVP, soit…
…il faut vraiment faire preuve de patience pour intégrer les enseignements tirés dans la prochaine version. C’est pour cela que j’apprécie autant le DevOps.
La livraison se poursuit. C'est ce qu'on appelle l'agilité mise en œuvre techniquement.
Mais attention aux pièges ! Être MVP ne signifie pas bâcler le travail au détriment de la qualité ou se perdre dans les détails techniques. Car cela finira par vous rattraper.
Vous pouvez gagner le sprint.
Mais cela provoque un effondrement pendant le marathon. Et on finit par faire plus de stabilisation que de nouvelles fonctionnalités.
N'oubliez pas : la qualité, le coût et le calendrier peuvent être fixés. Le périmètre, lui, doit être variable.
Vous avez déjà entendu parler de ce truc de M* ? Produit minimum commercialisable ? Fonctionnalités minimales viables ?
Attention ! Cela peut s'avérer utile. Mais tous ces termes risquent fortement de semer la confusion chez vos parties prenantes.
S'il y a une chose que je veux que vous reteniez, c'est celle-ci :
Utilisez le MVP comme un processus de réflexion pour obtenir la solution la plus simple et la plus banale possible à vos problèmes.
