Aujourd'hui, nous jetons à nouveau un regard prudent dans notre cuisine magique. Je souhaite montrer comment nous abordons les nouveaux projets de développement. Deux approches différentes s'offrent à nous.
Nous construisons simplement l'app
Lorsque la portée d'une nouvelle app est très limitée, il est facile d'évaluer le risque de développement. Le coût est faible, car par exemple un seul développeur y travaille pendant une courte période (moins d'un mois). Dans ce cas, nous définissons un ensemble de fonctionnalités, l'app est construite, puis lancée au public. C'est ainsi que nous avons procédé pour Phone Memos, Meeting Cards et aussi pour Herein.
Le périmètre fonctionnel est trop grand pour "construire à la va-vite"
Parfois, lors des premières discussions sur une nouvelle app, on perçoit immédiatement que le périmètre dépassera le seuil d'un mois-personne. Ou bien, comme pour Merlin Project, le produit revêt une importance stratégique. Dans ce cas, nous parlons d'un investissement à risque et nous procédons naturellement avec la prudence qui s'impose.
Dans la première phase, nous construisons des mockups (des images dans Apple Keynote représentant l'app telle que nous l'imaginons) à partir desquels nous simulons mentalement le fonctionnement et les processus de la future app. Parfois, cependant, nous atteignons les limites de notre imagination et avons besoin d'une autre technique : un prototype.
Un prototype est pour nous un petit programme qui illustre une technique précise, un flux de travail ou simplement un concept. Nous construisons ainsi de nombreuses petites apps. Comme ces apps de test ont une durée de vie très courte, nous cherchons à atteindre l'objectif rapidement. La beauté du code ou la propreté de la programmation ne sont pas notre préoccupation ici.
Durant cette phase, il m'incombe encore généralement de vérifier les aspects financiers de la future app : combien nous coûtera son développement et que pourrions-nous en tirer comme revenus. Comme je le dis toujours : "Les années soixante-dix sont révolues. Nous ne pouvons malheureusement pas vivre que d'amour et d'eau fraîche."
À un moment donné, nous aurons (espérons-le) exploré tous les aspects de la nouvelle app. Il existe alors un ensemble de diapositives montrant l'apparence visuelle. Et chaque fois que cela s'est avéré nécessaire, les techniques nouvelles ou critiques ont été testées dans un prototype jusqu'à ce que nous soyons satisfaits du résultat. De plus, un bilan détaillé des coûts attendus et des revenus espérés est établi. Nous nous réunissons alors (à distance via Zoom, bien entendu) pour discuter de nos conclusions.
À ce stade, de nombreuses idées d'apps ont déjà échoué : soit en raison d'une idée de base insuffisante, d'une barrière technique trop basse ou au contraire trop haute. Si le nombre d'utilisateurs estimé est trop faible, l'app n'est pas développée. Je suis bien conscient que ces évaluations, même lorsqu'elles sont prises en équipe, restent très subjectives et ne correspondent pas nécessairement à la réalité future. Mais à un moment donné, une décision doit être prise.
Le coup d'envoi du MVP
Lorsque notre confiance dans la nouvelle app et notre motivation à la construire atteignent un niveau suffisamment élevé, nous démarrons le développement.
Mais là encore, la prudence s'impose. Je ne veux pas mettre en péril l'avenir de l'équipe par un faux pas. C'est précisément ici qu'intervient un autre mécanisme de gestion des risques : créer un produit minimum viable.
Selon Wikipedia, le terme MVP a été utilisé pour la première fois par Frank Robinson et popularisé par Steve Blank et Eric Ries. L'idée est d'une clarté intuitive : on construit un nouveau produit doté uniquement des fonctionnalités essentielles. Sur la base de ce produit, on peut ensuite vérifier, au sein de l'équipe, avec des partenaires stratégiques et des représentants de groupes clients potentiels, si l'intérêt pour ce produit existe et si le marché estimé est suffisamment large. Bien entendu, on teste également si l'ergonomie de l'app correspond aux hypothèses formulées.
Chez ProjectWizards, une approche itérative du développement s'est établie depuis de nombreuses années :
- On développe en suivant les mockups créés.
- Nous examinons le résultat en petit comité et décidons si cela fonctionne bien.
- Si nous ne sommes pas satisfaits, nous itérons : pour les problèmes mineurs, directement dans le logiciel ; pour les problèmes fondamentaux, on retravaille le mockup.
Toujours selon la devise : la voie la plus rapide et la plus simple dicte la marche à suivre.
Ainsi, les blocs constitutifs du MVP s'assemblent peu à peu. À partir d'un certain moment, quelqu'un, généralement moi, commence à tester le nouveau logiciel.
Premiers tests pendant la phase de développement du MVP
Même si c'est très chronophage et parfois même très frustrant, les concepts et les hypothèses doivent être vérifiés encore et encore. Cela signifie travailler avec des données d'exemple dans la nouvelle app. Au début, bien sûr, tout plante de toutes parts. Mais avec le temps, la situation s'améliore.
À un moment donné, se pose la question du temps à investir dans un MVP. Il n'existe aucune règle en la matière. Cela dure jusqu'à ce qu'on puisse répondre soi-même à la question : le nouveau programme est-il viable dans la nature ?
Distinction par rapport au Minimum Marketable Product (MMP)
Le produit minimum commercialisable (ou vendable) va un pas significatif plus loin, du moins dans ma définition.
Alors que le MVP n'est destiné qu'à un usage interne (y compris quelques personnes clés) et ne génère encore aucun revenu, le MMP franchit une étape essentielle supplémentaire : cette version peut être vendue.
Contrairement aux usages du monde de l'open source, un MMP nécessite pour moi au minimum :
- un numéro de version 1.0
- une documentation
- un site web
- un partenaire de vente (App Store, Paddle, etc.)
- et plus encore
C'est pourquoi nous n'utilisons pas le terme MMP, mais version 1 ou 1.0.
Quand s'effectue la transition du MVP vers la version 1 ?
Pour nous, c'est une transition progressive. Nous fixons une date pour la finalisation du MVP, qui constitue aussi la date de départ du développement des fonctionnalités restantes de la version 1.0.
Comme on peut le voir sur le graphique, le processus est planifié de manière séquentielle. Dans la réalité, cependant, les frontières se brouillent parfois considérablement.
Quand un MVP est-il terminé ?
Il n'y a pas de date vraiment fixée pour cela. Si nous décidons que nous ne sommes pas satisfaits de la qualité ou du périmètre fonctionnel, nous continuons à travailler sur l'app, même si ce n'est encore qu'une version interne.
Revenez régulièrement ici, suivez-nous sur LinkedIn ou sur Twitter et vous serez parmi les premiers à apprendre toutes les nouveautés ;-)
Si vous avez des questions sur cet article de blog ou si vous souhaitez en discuter, nous attendons avec impatience votre contribution dans notre forum.
