The Lean Startup, revue de livre

Voilà un livre que j’étais très enthousiaste de recevoir. En effet, en ce moment que ce soit en bien ou en mal, on entend parler de la méthode Lean un peu partout. Dans le monde des startups informatiques ce thème revient même très souvent. Mais qu’a cette méthode de particulier ? Elle repose sur les principes suivant : il faut éliminer toute action inutile, chaque réalisation doit prouver son efficacité et permettre de progresser vers le succès (validation par l’apprentissage) et il faut se poser régulièrement la question de changer d’orientation ou de persévérer. Voilà en très résumé ce que raconte ce livre de 300 pages. Oui 300 pages pour expliquer ça c’est un peu beaucoup, l’auteur aurait pu faire plus concis. Heureusement il n’y a pas que du blabla, Eric Ries, l’auteur, nous expose beaucoup d’exemples concrets (expérience personnelle ou cas rencontrés en tant que consultant). Ce qui a tout de même pour avantage de rendre le livre assez convaincant.

Revenons à la méthode Lean. Pour que les choses soient claires, Eric Ries, ne recherche que la croissance maximum. On est donc pas dans le “Why grow ?” de 37signals. Pour cela il faut commencer de petit avec un produit minimum (MVP, Minimum Viable Product) afin d’avoir au plus vite des retours utilisateurs . On commence ainsi au plus tôt l’apprentissage. Comme pour lui les utilisateurs ne savent pas toujours ce qu’ils veulent, il ne va pas se contenter de leur poser des question, il va aussi analyser leurs réactions. En créant des indicateurs pertinents (évolution du taux de conversion par exemple) et en mettant de côté les indicateurs vantards (nombre de visites par exemple pour un site de produit payant) il va valider ou non l’ajout d’une feature, la modification d’un design, etc… Il conduit clairement des expérimentations pour définir la marche à suivre et n’hésite pas à revenir en arrière si ça n’a pas fonctionné. Pour que cela soit possible, il préconise de n’avancer que par petits pas et de travailler en petite équipe. Ainsi le retour en arrière est moins douloureux s’il doit avoir lieu. Après ça il continue sa progression jusqu’à ce que ça commence à coincer (croissance ralentie). Là il se pose la question, doit on continuer à améliorer l’existant ou doit on changer de positionnement ? Là il compte plus ou moins sur son instinct et ses résultats précédents pour faire son choix, puis il recommence le cycle.

NB : Pour les logiciels cloud, il prône la méthode du déploiement continu. Chaque modification passe en production rapidement. Il ne juge pas ça risqué car si un bug est mis en prod (malgré les tests automatiques) il sera facilement identifiable et corrigé rapidement car on peut relivrer tout de suite après.

Le concept n’est pas idiot même si je trouve ça gênant de prendre ses utilisateurs pour des rats de laboratoires. Autre point qui me pose problème, c’est qu’il prétend que c’est comme cela qu’on obtient de l’innovation. Alors que pour ma part, je ne trouve pas ce concept vraiment compatible avec l’innovation. Innover c’est parfois changer les habitudes et je ne suis pas sûr que les réalisations impliquant du changement soient “validées” par sa méthode. A l’inverse le bon côté de ce qu’il propose est que ça permet de diminuer les risques d’échec puisqu’on est sûr de développer ce que les gens veulent.

Ce livre présente aussi quelques trucs et astuces, comme la technique des 5 pourquoi. C’est un principe qui vient de Toyota (oui j’oubliais la plupart des principes Lean prennent leur source dans les manufactures Toyota qui avait pour principe de faire des voitures d’un seul coup et non par étapes. Cela leur permettait de mieux gérer leur stock de pièces et de se rendre compte plus vite s’il y avait un problème dans la chaine de production). Les 5 pourquoi qui consiste à analyser les problèmes en profondeur plutôt que de les attribuer à leur cause direct. Pour cela on réunit toutes les personnes impliquées depuis le début jusqu’à la fin de la chaine, management compris et on se pose 5 fois la question pourquoi. Ex : Jhon déploie une feature buggé. Pourquoi la feature est buggée ? parce que Jhon l’a déployée. Pourquoi Jhon a pu déployer une feature buggée ? parcequ’il n’avait pas fait les bons tests. Pourquoi n’a-t-il pas fait les bons tests ? Parcequ’il n’avait pas les bons outils, etc…

En résumé, c’est un livre très intéressant à lire (ok un peu chiant par moment) qui propose une méthode qui se tient avec comme bémol le côté expérimentation sur les utilisateurs.

Je me permettrai aussi une remarque : le principe de travailler avec des petites tâches et en permanence peut être assez épuisant pour les employés. En effet il n’y a plus jamais de pause comme on peut en trouver à la fin des projets ni même d’objectif conséquent à atteindre. A mon avis, il faut donc penser à aménager l’organisation du travail en conséquence : congés forcés, pas d’heures sup et petites victoires régulières me semblent obligatoires pour éviter manque de créativité, burnout ou lassement prématuré.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: