Bien rater sa Startup #3: Les contes de la Feature Creep
Une incroyable plongée dans l’univers merveilleux d’une Start-up qui a tout raté, aimablement racontée par son fondateur désespéré mais qui recommence tout et lâchera pas l’affaire, t’entends.
Cette semaine donc, si vous n’avez pas compris mon jeu de mot pourri, on va parler du Feature Creep.
« Mais qu’est-ce que c’est, le Feature Creep, tonton ? », me demande ma nièce de 7 ans à la lecture de ces lignes — elle aussi veut rater sa startup.
Lorsque l’on commence un projet, il est courant, durant la phase de prototypage, de lister la quantité de fonctionnalités nécessaires. Un module de connexion, un espace client, une galerie d’images, etc. Le risque, c’est de ne pas parvenir à s’arrêter. Parce que l’on veut toujours faire mieux, rajouter tel ou tel petit détail, on finit souvent avec beaucoup plus d’éléments que nécessaire, rendant la réalisation du produit irréalisable dans le temps/budget dont on dispose. C’est ça, le Feature Creep, ma petite.
Le Feature Creep est dangereux car insidieux. On a l’impression d’avoir planifié quelque chose de simple, mais progressivement, sans s’en rendre compte, on y a additionné des éléments, des détails, et on n’a pas vu que l’on avait perdu le contrôle.
Notez que le phénomène, par extension, s’applique à d’autres domaines que le développement d’applications. Il peut subvenir dans le cadre de la construction fiscale d’une entreprise, dans la constitution d’une équipe et des postes de chacun, dans une recette de cuisine (tiens, je vais mettre du thym).
Même en écrivant un post comme celui-ci, je suis tenté d’en raconter à chaque fois un peu plus, et pouf je me retrouve avec un pavé illisible.
Alors tout ça n’est pas une fatalité. On peut se protéger, dans une certaine mesure, de la trop grande complexité d’un projet, par exemple en appliquant les principes du Lean Design, brillamment expliqués dans Lean Startup d’Eric Ries, dont je vous recommande la lecture, même si je me doute que c’est déjà fait.
Parfois, malheureusement, cela ne suffit pas. Nous sommes ici pour savoir comment bien rater sa startup, alors je vais passer au cas pratique et vous montrer comment, en gardant bien en tête les principes de Mr Ries, on a quand même réussi à faire un truc dix fois trop compliqué. Pour ça, il faut que je vous parle un peu plus de la première version de Castr.
Le cas pratique
Notre projet, c’était donc de fournir de l’information géolocalisée en temps réel. Utilisation standard : je suis chez moi, j’entends du bruit dans le quartier, je veux savoir ce qu’il se passe. Je démarre l’application et je vois les posts des utilisateurs de mon quartier. A l’inverse, je suis dans la rue, je vois une manif, je prends une photo, je la poste sur Castr, les riverains peuvent commenter l’information. Donc : un wall et un système de posts. Simple enough.
Bon, le problème c’est que si j’habite dans le Larzac et qu’il ne se passe rien… c’est nul. Donc on va rajouter un système qui permet de suivre ses amis, où qu’ils soient. On sépare le wall entre ‘Ici’ et ‘Amis’. PAF. Still simple enough.
Ouais mais attends. Castr c’est pour savoir ce qu’il se passe à un endroit donné, pas avec une personne donnée. Il faut une manière de suivre des lieux, pour savoir ce qu’il s’y passe avant d’avoir des contacts là-bas, quand même, non ? Ou de pouvoir regarder une carte et voir où il se passe quelque chose tout court ? Ca va, ça fait 3 features, c’est pas la mort. Zou.
Bon et puis il faut que les gens puissent faire un peu plus que simplement commenter les posts. Un système de vote ça nous permettrait de trier ce qui est pertinent, une sorte de retweet (‘recast’) pour transmettre un post intéressant. Évidemment, il faut des pages de profil, pour les lieux et les utilisateurs, un système de connexion, des paramètres, quelques détails…
« Ooook, c’est quoi ce bordel ? Comment on en est arrivés là ? On recommence tout».
Encore un truc que personne n’a dit.
Au contraire, j’étais plutôt satisfait de la simplicité du projet. Et il y avait des arguments : malgré tout, l’ensemble tombait sous le sens. Ce que pouvait faire l’utilisateur correspondait à ce que l’on attendait du service, l’architecture de l’appli était relativement intuitive et cohérente, et puis surtout, on avait effectivement enlevé une tonne de choses pour limiter le périmètre du MVP:
- Le support vidéo
- Les messages privés entre utilisateurs
- L’énorme version desktop qui impliquait de tout faire une deuxième fois
- L’affichage des posts en temps réel
- Les mails dynamiques « ce qu’il s’est passé sur Castr cette semaine »
- Les recommandations de lieux
- + une tonne d’autres trucs.
De l’intérieur, ça semblait donc assez réduit, compact… simple.
Un an et demi plus tard
Haha, c’est drôle *rire jaune*, il aurait fallu que ce soit « trois mois plus tard », mais évidemment, non.
Un an et demi plus tard, donc, nous étions prêts à lancer. On est en mai 2015.
En vrai, on était pas vraiment prêts. J’ai vu quelque part un schéma qui résumait assez bien le fait d’avoir la sensation qu’un produit est fini, alors qu’il ne l’est pas du tout. Ça donnait quelque chose comme ça — merci à l’anonyme de l’internet qui l’a initialement pensé :
Vous vous en doutez, on a donc lancé Castr en pensant avoir un produit fini, alors qu’un peu de recul nous aurait montré que nous avions encore beaucoup de travail. Et ça, c’était la faute du feature creep. Si nous n’avions pas mis autant de trucs dans l’appli dès le début, il y aurait eu beaucoup moins de choses à affiner. Mais l’erreur était faite, et il fallait bien lancer à un moment.
La suite est terriblement banale. Nous avons lancé l’appli, et les gens ne l’ont pas utilisée.
Le Feature Creep n’est pas le seul en cause là dedans — loin de là — et je parlerai des autres raisons plus tard, mais dans le cas présent, nous nous sommes retrouvés avec plusieurs problèmes majeurs :
1 — L’application était trop complexe à prendre en main
2 — Elle était finie à la pisse
3 — Elle nous coûtait une blinde à maintenir
Pourquoi maintenant, Castr, c’est mieux
C’est uniquement après s’être pris dans les dents l’échec de notre première version que j’ai pleinement pris le sens du terme MVP (Minimum Viable Product, pour ceux du fond). Ce n’est pas un acronyme. Il faut plutôt le prendre comme une liste :
- Minimum : Réduire A FOND ce que fait le service. Tout ce qui n’est pas fondamentalement indispensable doit dégager. Posez vous la question de l’utilité des features les plus basiques : « A-t-on réellement besoin de s’inscrire ? ». Si vous faites des compromis, vous avez raté.
- Viable : Il faut que ce soit viable tel quel. Si le truc est joli et fonctionnel mais encore tout buggué, et qu’il va exploser entre les mains du premier utilisateur venu, ou au premier pic de connexion, il n’est pas viable, vous avez raté.
- Product : Ne pas perdre de vue que le public attend un produit fini, pas un démonstrateur ou un prototype. Si vous lancez, mais que vous savez, au fond, qu’il faudrait encore une ou deux fonctionnalités majeures pour que le produit fonctionne vraiment, vous avez raté.
Faire mieux, faire moins.
Donc après l’échec de Castr 1, on s’est dit : qu’est-ce qu’on veut faire, en fait ? On veut mettre en relation les gens à proximité. Point. Par un par un comme sur WeChat, tous ensemble, comme une dans une salle de conversation. Keep It Simple, Stupid.
Alors Castr2, c’est ça et uniquement ça. Une salle de conversation, générée dynamiquement en prenant les personnes les plus proches. Il suffit de démarrer l’appli et on peut parler aux gens a côté.
De là, l’architecture de l’application est simple : une page de profil, une page de conversation, une page de messages.
Pour éviter le Feature Creep, notre astuce a été de faire une liste d’anti-features : lister tout ce que l’on a pas besoin de faire :
- Inscription ? Pas besoin, on génère un nom aléatoire à l’arrivée sur l’appli.
- Commentaires ? Pas besoin, les utilisateurs ne soumettent pas de posts, mais des messages. Un commentaire, c’est simplement un nouveau message
- Lieux ? Plus besoin de lister des lieux (les bars, restos, aéroports, etc qui nécessitaient une grosse infrastructure de reverse-géocoding). La position est simplement induite : l’utilisateur parle à des gens proches de lui.
- Profil public ? Pas nécessaire dans une première version.
- Service web ? Pas besoin, Castr 2 repose sur la position, donc est entièrement mobile.
Vous avez compris le principe.
Donc : minimum — Il n’y a pas de superflu, viable — c’est quasiment 100% stable et ça tourne très vite, product — on peut parler aux gens à proximité, ça marche tel quel (et d’ailleurs on s’éclate sur nos versions de dev).
Mais ce coup-ci, on ne fait pas la même erreur. On prend le temps d’affiner au maximum l’appli pour sortir quelque chose dont on sera fier et que l’on pourra mettre entre les mains de n’importe qui sans craindre un « ca marche pas ton truc » dévastateur pour l’ego.
Notez qu’il ne s’agit pas de faire une appli super simple et de s’arrêter là. Il s’agit de lancer une appli super simple afin de valider son marché tôt, de savoir si cela intéresse les gens. Ensuite, viendra le temps de rajouter — progressivement — tout ce que l’on veut y mettre. Ou de s’arrêter avant d’y avoir perdu une décennie.
Ouais, je sais, vu comme ça c’est évident. Comme quand on regarde Fort Boyard, on se dit que c’est fastoche de tenir sur les rouleaux qui tournent. Mais croyez-moi, de l’intérieur, on se fait facilement avoir.
La morale de cette histoire, la rirette, la rireetteu
Le Feature Creep, donc, est dangereux. On ne le sent pas arriver, et il peut foutre la merde dans votre planning, parce que vous avez rajouté mille trucs inutiles mais cools dans votre projet. La solution est donc de se concentrer sur un Minimum Viable Product et de s’arrêter systématiquement sur chaque fonctionnalité pour se demander si vous en avez vraiment besoin au lancement.
Il est aussi exponentiel. Chaque ajout dans un projet affecte toutes les parties de ce dernier. Une feature doit être testée pour elle-même, en conjonction avec le reste, et dans la mesure ou elle a un impact sur son usage global — donc peut le changer fondamentalement. Prenez donc en compte les épi-phénomènes.
Finalement, le Feature Creep est dangereux pour ce qu’il est mais aussi parce qu’il est divertissant. C’est à dire qu’il peut occulter le fait que votre projet lui-même est trop complexe. Simplifier au maximum un projet qui est déjà trop vaste donne l’illusion d’avoir eu une approche Lean, alors qu’on a simplement lissé une usine à gaz.
Voila. C’était un peu plus technique que la semaine dernière, mais le sujet était crucial et il fallait bien passer par là. Je tâcherai de faire quelque chose de plus fun pour la prochaine. En attendant, place aux artistes.
Instant Culture
En titrant mon article sur les contes de la Crypte, il aurait été logique que je vous parle de Stranger Things, la nouvelle série de Netflix qui cartonne, mais comme justement, tout le monde en parle déjà, j’ai tâché de vous trouver quelque chose d’autre. Et comme ça fait deux semaines que je vous parle de film, ce coup-ci on va aller du côté de l’illustration, avec un artiste très original dans un domaine pourtant extrêmement fertile.
Simon Stålenhag, donc, est un peintre/illustrateur suédois, par ailleurs développeur de jeux et musicien, qui peint notamment des paysages de science-fiction. Mais les siens sont particulièrement intéressants, parce qu’ils sont ancrés dans la réalité banale de la grisaille nordique.
Souvent, ce genre d’illustrations utilisant des éléments fantastiques ou futuristes sont très saturés, avec un grand ciel bleu super joli et des voitures volantes, ou au contraire super dark pour nous montrer les bas-fonds d’une ville cyber-punk bien ghetto dans le meilleur quartier pour acheter des bâtons de la mort ou des prothèses militaires illégales.
Simon Stålenhag est intéressant parce que justement, ce qui se dégage de ses œuvres, c’est une sensation de complète banalité. Ok, il y a un énorme mecha dans ce champ, mais c’est un vrai champ, avec des gamins qui jouent autour, une voiture de police un peu déglinguée comme on en croise dans toutes les provinces d’Europe, un ciel gris qui ressemble à celui que le parisien voit tous les matins, ou des immeubles d’un grand ensemble de banlieue à l’horizon.
Ses œuvres sont chouettes (outre le fait qu’elles sont magnifiquement composées) parce qu’il montre ce que serait la science-fiction si elle était là, en vrai, dans notre monde. Si Peugeot sortait demain une 208 GTI volante à sustentation nucléaire, on ne deviendrait pas tous pour autant des héros de blockbuster à tatouages et cicatrices sexy. On irait toujours à Auchan acheter du PQ un dimanche matin sous la pluie.
Mais ce serait quand même un peu cool.
(Vous pouvez retrouver plein d’autres œuvres de Simon Stålenhag sur son site, et même acheter des prints sur Red Bubble. Faites donc ça, moi j’en ai mis partout chez moi.)
A la semaine pro
Cheers
Barth Picq
Et n’oubliez pas, la nouvelle version de Castr est encore cachée chez nous, mais toutes les infos sont ici:
