Catégorie : Gestion de projet

Le marché du numérique peut être vu comme un alien. En effet, celui-ci croît continuellement : selon les chiffres de WeAreSocial, le nombre d’internautes au niveau mondial a augmenté de 8,6% par an en moyenne, en dix ans. De plus, la crise sanitaire a précipité la transition numérique des organisations et des ménages. Cela résulte en une pression pour les éditeurs de logiciels, qui doivent s’assurer de délivrer une application web ou mobile qui fait mouche auprès des utilisateurs s’ils veulent se développer.
Il existe une solution pour augmenter ses chances de réussite : Le Minimum Viable Product (MVP). En quoi consiste-t-il ? À quoi ça sert ? Comment s’y prendre pour créer un MVP ? Que faire une fois qu’il est prêt ?

Nous allons voir dans cet article les avantages du MVP et les étapes pour créer le MVP de votre solution.

Qu’est-ce qu’un Minimum Viable Product (MVP) ?

Définition

Le MVP (que l’on peut traduire par “Produit Minimum Viable”, ou PMV) est ce qu’on rapprocherait le plus d’une version bêta d’un produit dans le langage courant. Concrètement, on parle ici d’une version du produit qui rassemble uniquement les fonctionnalités essentielles.

Défini par Éric Ries (entrepreneur Américain réputé pour ses travaux sur le Lean Startup), il remplit un double objectif : 

• Concentrer les efforts sur ce qui est élémentaire afin de gagner du temps,
• Permettre un rebond rapide et efficace suite à un retour utilisateur afin d’optimiser l’apprentissage ainsi que les mesures de correction.

Pourquoi créer un MVP ?

Le MVP permet de tester la vision du produit et de présenter rapidement ce dernier à ses utilisateurs potentiels cibles. Mais aussi, de vérifier s’il répond à une problématique, un besoin. L’objectif est de développer uniquement les fonctionnalités essentielles qui répondent au(x) problème(s) identifié(s).

C’est pour cela que l’utilisateur est intégré très rapidement dans le processus de conception. En effet, celui-ci est chargé de tester des versions successives du produit afin d’émettre un commentaire. Cela permet d’apprendre à mieux le connaître tout au long du développement du produit, à travers le MVP. Ainsi, l’utilisateur occupe une place importante dans le développement du produit, comme le prône le modèle Lean Startup.

POC, Prototype, MVP : quelles sont les différences ?

Attention, il ne faut pas confondre le MVP avec un POC (proof of concept, ou preuve de concept) ou encore un prototype.

Voici les réflexions à mener afin de faire la distinction entre les trois :

• Je veux savoir si mon projet est faisable => Je fais appel au POC (Proof of Concept) :
  Que ce soit pour une innovation ou encore pour un business model, la preuve de  concept évalue les éléments réalisables d’un projet. Elle intervient en début de projet et porte sur l’aspect technique de ce dernier.
• Je veux être sûr que le “Comment faire” est acquis => J’utilise un prototype :
  On parle ici de la maquette interactive du produit . Il est plus facile de se projeter dans le produit et son utilisation avec un prototype. À travers des tests utilisateurs, le prototype permet de tester l’ergonomie, les fonctionnalités, les interactions entre les composants de l’interface et entre les écrans ou encore l’esthétique du futur produit. L’avantage du prototype est de pouvoir tester et modifier rapidement les maquettes du produit avant de débuter le développement. Pour en savoir plus, n’hésitez pas à aller lire notre article « Comment créer la maquette et le prototype d’une application ?« .
• Je veux déterminer si mon projet est viable => J’emploie la méthode du MVP :
  C’est la base concrète, la version finale du produit avec les fonctionnalités essentielles développées. C’est cette version du produit qui va être lancée auprès des potentiels utilisateurs cibles. Cela permettra de tester le produit pour en tirer des enseignements et itérer. Le produit va ainsi évoluer en fonction des retours utilisateurs.
  Cela va également impacter les dimensions marketing et commerciales. 

Les avantages du MVP

Maintenant que vous connaissez le portrait-robot d’un MVP, il faut comprendre en quoi c’est une solution viable pour la mise en place de votre projet.

Le Minimum Viable Product a de nombreux avantages comme :

• Réduire les coûts : Le MVP étant la version la plus basique du produit, sa conception ne représente pas une lourde charge financière.
• Limiter votre prise de risque : Inclure l’avis de vos utilisateurs dans l’élaboration et l’amélioration du MVP permet d’apprendre à mieux les connaître et comprendre leurs besoins. Ainsi, cela impacte positivement votre courbe d’apprentissage en plus d’augmenter vos chances de créer un produit réussi (notamment en évitant l’effet tunnel).
• Alléger le processus : Créer un produit est long – parfois très long -, et comprend de nombreuses étapes. Le MVP permet de raccourcir le temps entre l’idéation et le lancement d’une première version de la solution sur le marché grâce à un processus plus léger et agile.
• Approuver le produit sur la durée : Les tests d’hypothèses et de concept sont une opportunité à saisir. Non seulement ils vérifient la viabilité du produit, mais ils donnent également l’occasion de constater les tendances du marché afin de déterminer la meilleure adéquation produit-marché possible.
• Améliorer votre proposition commerciale : En vous dotant de méthodes d’apprentissage et de compréhension de vos clients, vos équipes marketing et commerciales agrémentent leurs démarches respectives (pitch, proposition de valeur, campagne publicitaire/promotionnelle, élaboration de Personæ précis…).

Comment Keleo vous aide à créer votre Produit Minimum Viable

Imaginons que vous ayez une idée d’application que vous souhaitez tester rapidement auprès de votre marché ou que vous souhaitiez faire évoluer votre produit déjà existant. 

Voilà les différentes phases que nous vous proposons pour réaliser votre MVP : 

Phase 1 : Révéler votre projet 

Cette phase commence par plusieurs étapes :

• Cadrage : Keleo vous aide à cadrer votre projet en définissant la demande et vos besoins. Nous nous alignons ensemble sur votre vision du projet et du produit. Cela nous aide à définir les contours de notre collaboration afin de créer votre PMV et d’en définir le coût. 
• Immersion : il s’agit ici de comprendre qui sont vos utilisateurs et quels sont leurs besoins. Pour y parvenir, nous faisons appel à des méthodes utilisées en UX design telles que l’observation sur le terrain, les entretiens, les focus group, les questionnaires, etc.
  Cette étape est complétée par la compréhension du marché : les concurrents, la vision du produit.
• Définition : ici nous définissons la problématique et le projet pouvant la résoudre.
• Idéation : après avoir conceptualisé le MVP, il est temps de lui donner la forme d’un prototype. Nous utilisons pour cela un Design Sprint, qui permet de concevoir rapidement un prototype du MVP testable auprès des utilisateurs.

Phase 2 : Backlog produit

On parle ici du carnet des fonctionnalités du produit . Ce backlog nous permet de définir le périmètre du MVP en se concentrant sur les fonctionnalités à forte valeur ajoutée pour les utilisateurs.  La priorisation de ces fonctionnalités sert de feuille de route pour définir les étapes de conception et de développement à suivre. 

Pour mieux comprendre comment adapter votre projet à un contexte Agile, nous avons écrit un article sur le sujet ici : Pourquoi et comment adapter votre cahier des charges à un contexte agile ?

Phase 3 : Conception en cycles courts sous forme itérative – le scrum / l’agilité

Chaque itération permet de concevoir une partie fonctionnelle potentiellement livrable. Cette étape commence par définir l’aspect visuel des interfaces (UI design) traitées en priorité dans l’étape précédente. Ces interfaces sont ensuite développées au cours de sprints.  À chaque fin de sprint, une revue des développements est effectuée et permet de confronter les développements avec vos attentes, mais aussi celles de vos utilisateurs.

Phase 4 : Amélioration continue

L’avantage d’une mise sur le marché rapide est de recueillir des retours et d’adapter le produit en continu. À la suite de chaque itération, le produit développé peut être mis en production (c’est-à-dire en ligne) et testé sur le marché auprès de vos  utilisateurs finaux. Il ne faut pas hésiter à multiplier les phases de feedbacks afin de comprendre-mesurer-apprendre. Cela permet in fine d’aboutir à un produit mature qui entre en adéquation avec votre  marché et vos  utilisateurs.

Voilà comment nous pouvons vous aider à concevoir votre MVP et faire évoluer votre application. 

Vous souhaitez réaliser votre MVP ? Il ne reste plus qu’à vous lancer !
N’hésitez pas à contacter notre équipe pour présenter votre projet !

Le cahier des charges est un bon moyen pour commencer à structurer votre projet d’application numérique.

Il aide à formaliser une vision commune en interne. Il donne des guidelines pour le choix d’une agence partenaire. Enfin, c’est un outil de communication avec l’agence de développement que vous choisissez.

Néanmoins, s’en tenir au cahier des charges peut aussi constituer un frein dans un projet de développement. En s’accrochant à une vision globale du projet, vous perdez en agilité et rallongez les délais de livraison.

Alors comment adapter votre cahier des charges à un contexte agile ?

Le cahier des charges, utile… mais pas agile ?

Comme nous l’avons évoqué dans notre article sur la rédaction d’un cahier des charges, celui-ci est utile pour s’aligner en interne autour d’une vision commune de la future application puis pour communiquer cette vision à l’agence de développement.

Autant il est important au démarrage du projet, autant il ne doit pas devenir un poids au moment de la conception.

Attention donc aux risques qu’il peut y avoir comme : intégrer toutes les demandes internes sans priorisation, manquer d’une vision commune pour aligner toutes les parties prenantes ou encore se retrouver dans l’effet tunnel en manquant d’agilité.

Le cahier des charges est très souvent un document qui se veut exhaustif. En interne, vous listez les spécifications que vous voulez transmettre à l’agence. Mais le défaut, dans la plupart des cas, réside dans le manque de hiérarchisation.

Pour votre partenaire, il n’est pas forcément évident, à la lecture du document, de distinguer ce qui est absolument indispensable de ce qui relève de l’accessoire.

Suivre aveuglément le cahier des charges peut donc conduire à consacrer énormément de temps et de ressources à concevoir des éléments qui, au final, ne sont pas essentiels pour la réussite du projet.

Les limites du cahier des charges s’expliquent notamment par le fait qu’il soit rédigé en interne en amont de la collaboration avec l’agence partenaire.

Le rôle de l’agence est justement de vous aider à prioriser ce qui compte vraiment dans le projet afin de gagner en agilité et mieux maîtriser les délais et les coûts de développement.

Dans la pratique, si vous choisissez une agence qui fonctionne en mode agile, c’est pour gagner du temps sur la conception et améliorer le time to market de votre application.

Notre expérience chez Keleo montre qu’il est souvent utile de passer par d’autres étapes de conception (ateliers de co-conception, design sprint, réunions de cadrage,…) avant de commencer la production et le développement.

Toutefois, vous pouvez aussi, dès sa rédaction, adapter votre cahier des charges à un mode agile.

On vous explique comment.

Adapter votre cahier des charges à un mode agile : mode d’emploi

1 – Regrouper les fonctionnalités en features

Beaucoup de cahiers des charges énumèrent des fonctionnalités de manière désordonnée. Les fonctionnalités ne sont pas regroupées de façon cohérente et il est difficile pour le lecteur de comprendre à quel besoin elles répondent ou même à qui précisément elles s’adressent.

Dans ces circonstances, c’est l’agence, par ses questionnements, qui va vous aider à regrouper et préciser vos fonctionnalités. C’est une phase assez chronophage dont vous pourriez faire l’économie en structurant d’emblée votre cahier des charges.

C’est pourquoi nous vous conseillons, en premier lieu, de regrouper les fonctionnalités que vous avez listées en features (par modules ou par catégories). Les features sont des fonctions cohérentes du produit, des parties de l’ensemble qui apportent de la valeur aux utilisateurs.

2 – Vérifier à quel besoin répond chaque fonctionnalité

Dans un cahier des charges « classique », les fonctionnalités listées émanent de différentes parties prenantes. Mais, parfois, certaines de ces fonctionnalités ne répondent pas à un besoin réel ou, en tout cas, pas à un besoin essentiel.

En d’autres termes, certaines fonctionnalités pourront être supprimées ou dépriorisées. Par contre, on s’efforcera de maintenir celles qui répondent à un véritable besoin.

Pour amorcer ce travail, dès la rédaction du cahier des charges, vous devriez être en mesure d’associer une fonctionnalité à un besoin. Si ce n’est pas le cas, une fois que vous avez listé les fonctionnalités, pensez à vérifier à quel besoin chacune d’elles répond.

3 – Harmoniser la façon dont sont décrites les fonctionnalités

Pour faciliter la compréhension de vos demandes, vous devez simplifier la façon dont vous décrivez les fonctionnalités. Pour les équipes de conception, il suffit qu’elles répondent de manière synthétique à 3 questions-clés :

• Qui ?
• Quoi ?
• Pourquoi ?

Vous pouvez donc utiliser la formulation suivante  :

En tant que [type d’utilisateur], je peux [action] afin de [finalité].

Par exemple, imaginons une application métier où les managers pourraient gérer différents rôles dans l’application selon les utilisateurs, nous aurions : « En tant que manager, je peux paramétrer les rôles des utilisateurs afin de gérer les droits. »
Il sera alors nécessaire de préciser quels sont les différents rôles et les droits associés.

Autre conseil pratique : vous pouvez numéroter vos fonctionnalités pour mieux les identifier.

4 – Hiérarchiser les fonctionnalités

À ce stade, vous avez ordonné vos fonctionnalités. Cela vous permet en principe de fusionner les doublons et supprimer les fonctionnalités qui ne répondent pas à un besoin réel. Vous avez donc déjà un document bien plus clair et concis.

Maintenant, vous pouvez aller plus loin en attribuant un score à chaque fonctionnalité, par exemple de 1 à 5, le score 5 correspondant aux fonctionnalités les plus prioritaires.

Au final, vous obtenez des fonctionnalités bien « rangées » par features et priorisées au sein de chaque feature.

Félicitations, vous avez constitué le backlog de votre projet !

Par la suite, en ne retenant par exemple que les priorités de score 4 et 5, vous pourrez avoir un aperçu de ce que pourrait contenir votre MVP (Minimum Viable Product), c’est-à-dire un produit présentant les fonctionnalités essentielles, principales pour les utilisateurs.

Sélectionner quelques fonctionnalités-clés réellement utiles et utilisables par vos prospects/clients facilite l’adoption de votre application. À partir de votre MVP, vous pourrez tester et faire évoluer votre produit en fonction des retours utilisateurs.

De plus, autre avantage, en procédant ainsi, vous pourrez déployer plus rapidement votre application auprès des utilisateurs.

Du cahier des charges au backlog

En adaptant tout de suite votre cahier des charges à un mode agile, vous prenez déjà de l’avance sur les étapes de conception.

C’est particulièrement le cas sur la formulation des besoins utilisateurs. En travaillant ceci dès le départ, vous vous poserez les bonnes questions et gagnerez en clarté et en temps. Les besoins pourront ensuite être précisés à travers une approche centrée sur l’expérience utilisateur avec des entretiens ou tests utilisateurs par exemple et des ateliers de co-conception. Cela permettra de vérifier si ce que vous aviez envisagé se révèle juste et de préciser éventuellement certains points.

De la même manière, en classant puis en priorisant les fonctionnalités, vous accélérez la création du backlog de votre projet.

Dans les méthodologies agiles, le backlog désigne une liste priorisée d’éléments ou de fonctionnalités selon leur valeur. C’est un livrable réellement utile pour démarrer la production et lancer le projet dans de bonnes conditions.

Il est le point de départ, l’outil indispensable qui est attendu pour une équipe de développement agile afin de planifier la suite, notamment les sprints.

C’est un enjeu sur lequel votre agence partenaire peut agir. Pour autant, vous pouvez encore accélérer la conception en rédigeant d’emblée votre cahier des charges de manière structurée, concise et en priorisant les fonctionnalités qui constitueront la colonne vertébrale de votre application.

Un cahier des charges adapté au mode agile apparaît comme le chemin le plus court entre la formalisation de vos besoins et la définition du backlog ou de spécifications priorisées.

Nous espérons que vous y voyez maintenant plus clair !

Si vous souhaitez un accompagnement pour cadrer votre projet et réaliser votre MVP, n’hésitez pas à nous contacter !