TMA et Minimum Viable Product
Prenons un projet de TMA, dans lequel les contraintes budgétaires sont fortes.
L’application a une sérieuse dette technique, la vie du projet se limite à quelques évolutions fonctionnelles et corrections d’anomalies.
Voilà une description qui ne fait pas rêver, pourtant, elle correspond à la réalité de nombreux projets de maintenance. Comment peut-on faire pour essayer de dynamiser le projet et y intégrer des nouveautés ?
En réalité, la question est vaste et les discussions infinies. L’objet de cet article est de voir comment l’utilisation du Minimal Viable Product permet d’innover au sein d’un projet alors que la situation ne s’y prête pas.
Le contexte
Dans ce type de projet, il n’est pas rare que les marges de manoeuvre soient restreintes. Les sujets prioritaires sont la correction d’anomalies et les demandes d’évolutions fonctionnelles. De l’équipe projet, a émergé l’idée de refondre complètement certains écrans. Cette refonte passe par l’intégration d’un nouveau framework, un nouveau design, une nouvelle ergonomie et au passage la fusion de plusieurs écrans existants. Ceci permet entre autres de se débarrasser d’une maintenance devenue trop lourde.
Il n’y a pas de demande particulière de la part du client (“pourquoi refaire quelque chose qui marche déjà ?”) et donc pas vraiment de ligne budgétaire affectée à ce chantier. Ceci pourra se faire uniquement sur le temps gagné sur d’autres tâches.
L’équipe a pour objectif de refondre des écrans de recherche, ce sont les plus utilisés, ils ont la dette technique la plus importante et surtout ils sont impliqués dans la majorité des accidents de production que rencontre l’application.
L’objectif est de gagner en fiabilité, en maintenabilité et de retrouver l’adhésion des utilisateurs (faire en sorte qu’ils aiment leur application). La situation présente de nombreuses contraintes. Il faut réussir à faire vite, bien et nouveau, le tout avec peu de moyens (n’est-ce pas finalement notre quotidien à tous ?). Le plus compliqué à gérer étant ces utilisateurs finaux, ceux-ci sont mécontents de l’existant et dans le même temps, il est difficile de cibler leurs attentes.
Au vu des moyens et de l’absence de visibilité sur les attentes client (l’équipe ne sait absolument pas si les utilisateurs adopteront ces nouveaux écrans), l’équipe pense alors à une stratégie permettant de concilier ces contraintes car elle a une réelle volonté d’innover sur ce projet (quelle équipe impliquée et motivée ne le souhaiterait pas ?). Un nouvel écran de recherche est présenté sous forme de Minimum Viable Product.
Le Minimum Viable Product : qu’est-ce que c’est ?
Le MVP, c’est une stratégie de développement. On appelle Minimun Viable Product, un produit (nous parlons ici de logiciels mais on peut l’étendre à d’autres domaines) servant à récolter auprès des utilisateurs le maximum d’informations avec un minimum d’effort. L’objectif étant de valider le lancement d’un nouveau concept ou encore l’existence d’un besoin auprès de futurs clients.
Au lieu de lancer un produit longuement étudié, peaufiné dans lequel ont été investis d’énormes moyens de R&D, le MVP sert à lancer tout de suite un prototype minimal, pour un coût moindre donc, et à partir du feedback des “early adopters”, l’améliorer itérativement.
Les principes :
Source : The Lean Startup Principles
Exemples :
- une page web statique présentant un futur service et servant à récolter les avis utilisateurs via un sondage ou une pré-inscription.
- une bannière publicitaire présentant un nouveau produit, les données de clic permettent de savoir si il y a un marché potentiel.
Ainsi, en cas d’échec, qu’il soit marketing, commercial ou même technique, les “dégâts” seront limités. On reconnait ici une démarche “fail-fast“. L’échec est à relativiser, sans forcément abandonner le projet, il sera possible de réorienter la stratégie à partir des informations récoltées. Le MVP a été rendu populaire par Eric Ries, créateur du mouvement Lean Startup.
Son utilisation dans un projet de maintenance
Voilà pour les présentations, revenons au contexte projet évoqué au début. Le MVP peut être utilisé autrement que pour le lancement d’un nouveau produit. Ici, il a été utilisé pour l’intégration d’une nouvelle fonctionnalité (ou plus exactement la refonte complète de celle-ci) dans un logiciel existant. La ligne de conduite de l’équipe pour la mise en place de ce MVP destiné à être un nouvel écran de recherche à été la suivante :
Faisons un écran simple et efficace, qui fait ce à quoi il est destiné et qui le fait bien
Source : Time Management Ninja
Raisonnement simple me direz-vous, voire même simpliste, sauf que l’objectif était de se démarquer de l’existant. A savoir, le fameux écran de recherche multi-critères que nous connaissons tous, celui aux 37 critères (et les dizaines de règles de gestion qui vont avec) disposés sur 5 colonnes, un tableau de résultats énorme, sans pagination, sur lequel il est possible de faire du reporting, des extracts etc…
Une différence notable ici, il n’y a pas de population “d’early adopters”, mais plutôt une population d’utilisateurs qu’il va falloir convaincre. On sait seulement que les utilisateurs sont mécontents de l’existant et dans le même temps, ils ne sont pas en mesure d’indiquer clairement leur besoin. D’où l’idée de se recentrer sur l’essentiel.
Ce nouvel écran possède donc 4 critères de recherche pertinents et un tableau de résultats épuré (les colonnes peu pertinentes, vides la plupart du temps, ont été retirées). Côté serveur, un refactoring minimum a été effectué pour gérer la pagination et rendre le tout plus réactif.
N’ayant pas (ou très peu) d’interaction avec les utilisateurs, il est apparu essentiel de récolter des métriques permettant de réellement connaître la manière dont la fonctionnalité sera utilisée. Quelques traces dans le journal de l’application ou quelques écritures dans une table d’audit peuvent suffire. Pour cette première itération, l’équipe a pu voir la répartition de l’utilisation des critères et la navigation dans le tableau des résultats.
On pourrait dire que cette réalisation dépasse légèrement le stade de MVP, en effet pourquoi ne pas avoir présenté une maquette bouchonnée et demander l’avis des utilisateurs ? Et bien parce que dans le monde réel, les utilisateurs finaux d’applications métier en entreprise ont d’autres priorités que d’être bêta-testeurs. Il fallait donc déployer un écran avec la fonctionnalité minimum, dans ce cas-ci, une recherche multi-critères.
Ce nouvel écran a été bien accueilli, il a d’ailleurs été le point de départ d’un chantier de refonte plus ambitieux et plus important, on est parfois surpris de voir à quelle vitesse certains budgets “se débloquent”. C’était en réalité le doux rêve de l’équipe projet…
Et ça marche !
Il n’est en effet jamais simple de négocier avec un client le fameux “il faut tout refaire…”. Le MVP est à mon sens une bonne approche quand on sait qu’il faut repartir de zéro (ou presque).
Avec une prise de risque minimum et une mise en place relativement simple, le MVP est une approche vertueuse permettant d’être au plus près du besoin des utilisateurs dès le départ et tout au long de la vie du produit.
Les discussions et articles sur le MVP étant nombreuses, l’idée de cet article était de présenter un regard un peu différent à travers un retour d’expérience en entreprise.
Je suis complètement séduit lorsqu’un concept simple permet de résoudre des situations “complexes”. Si vous reconnaissez une de vos expériences dans cet article, n’hésitez pas à la partager en commentaire !
Un peu de littérature sur le sujet :