Avez-vous une idée qui doit exister avant que vous puissiez savoir si elle fonctionne ?
Du concept à une première version déployée que l'on peut mettre devant de vrais utilisateurs : applications web, panneaux d'administration, produits cartographiques et applications mobiles, gardés assez petits pour en apprendre quelque chose.
Le problème
L'idée est généralement claire. Ce qui ne l'est pas, c'est quelles parties comptent. Les équipes construisent soit tout d'un coup et lancent tard un produit que personne n'a touché, soit un prototype si mince que les retours portent sur le prototype et non sur l'idée. Dans les deux cas, on gaspille la seule ressource qui compte à ce stade : une réponse rapide et honnête.
Notre approche
Nous définissons la seule question à laquelle la première version doit répondre, puis nous construisons uniquement ce qu'il faut pour y répondre, mais nous le construisons correctement : de vrais comptes, de vraies données, déployés sur une infrastructure qui ne vous fera pas honte si la réponse est oui. Tout le reste est supprimé ou simulé ouvertement. Nous instrumentons le produit pour que la réponse vienne de l'usage et non des opinions, et nous ne planifions la deuxième version qu'une fois la première utilisée. Nous avons livré des produits de cette façon en tant qu'unique développeur, du premier commit à une version 1.0 publiée, et nous en avons aussi arrêté un à ce stade parce que la réponse était non. Comparé à une année de développement, c'est un dénouement peu coûteux.
Exemple concret
Un système d'information géographique, panneau et cartes compris
Quatre années à construire des produits d'information géographique nous ont appris où ces projets se bloquent : la carte est la partie visible, mais le produit vit dans le panneau qui se trouve derrière. Sur un SIG web en cours, nous avons construit seuls l'intégralité de ce panneau d'administration, de la gestion des utilisateurs et des rôles aux flux de travail qui alimentent la carte, et nous avons implémenté les opérations cartographiques qui permettent de dessiner, d'interroger et de modifier des objets. Un produit mobile a suivi le chemin inverse : trois associés, un développeur, et une version 1.0 livrée à de vrais utilisateurs. Il a été arrêté peu après, sur la base de ce que ces utilisateurs faisaient, ce qui est exactement le rôle d'une première version.
Ce que vous obtenez
- Un périmètre écrit pour la première version, avec ce qui a été retiré et pourquoi
- Un produit déployé avec de vrais comptes, de vraies données et une mesure de l'usage
- Un court rapport d'usage après les premières semaines, en langage clair
- Le code et l'infrastructure, documentés et à vous pour la suite