Getting Real

Cette semaine j’ai lu un livre que j’ai adoré : Getting Real. Sorti en 2005, il est probable que vous en ayez entendu parler. Il est écrit par la société 37 Signals, startup américaine dont le produit phare est Basecamp, l’appli web de gestion de projet. Vous ne les connaissez peut être pas, mais ils sont également à l’origine du projet Ruby on Rails, rien que ça. Leur philosophie est de réaliser des applications web et de les sortir le plus rapidement possible pour obtenir le feedback utilisateur, d’où le titre. Et les 170 pages valent vraiment la lecture!

Dès le début le ton est donné : ce livre représente leurs idées sur la façon de construire des applications web le plus rapidement et le mieux possible. C’est surtout une façon de refuser de faire l’inutile, très proche de la philosophie Lean dont on entend de plus en plus parler. Cela ne représente que leur vision, mais avec plusieurs centaines de milliers de clients et Jeff Bezos (fondateur d’Amazon) comme investisseur principal depuis (10 millions de dollars), on peut considérer qu’il s’y connaissent un peu. Il n’ont rien inventé et le disent, mais chaque page du livre amène son idée (oui, une par page, “smaller” on vous dit) et éventuellement un petit témoignage d’une personnalité du Web.

Bien des choses énoncées sont des mantras de l’agilité : ne bougez pas la deadline, bougez le périmètre. Les specs entières en amont ne servent à rien. Ecrivez de petites histoires. Résolution de problème just-in-time. Pour ce point là, ils donnent leur propre exemple, lors du lancement de Basecamp : il n’y avait pas de système de paiement. Pourquoi? Parce que l’abonnement étant mensuel, ils avaient donc 30 jours devant eux pour l’implémenter, avant qu’un client en ait besoin! Ça c’est just-in-time!

Il y aussi plein de bon sens :

  • Se concentrer sur une seule idée, mais la faire bien.
  • La scalabilité c’est pour plus tard.
  • Faire le code le plus simple possible.
  • Ne faites pas de réunions.
  • Vous ne plairez pas à tout le monde.
  • Dire toujours non aux propositions de fonctionnalité et attendre d’être harcelé pour considérer son développement.
  • Les mockups d’écran sont le meilleur moyen de commencer une discussion.

Je ne veux pas vous spoiler plus le contenu mais j’ai été frappé par la similarité de leurs idées avec celles que nous avions en fondant Ninja Squad. Construire d’abord des applis pour vous, pour des choses qui vous manquent. Le financement externe est le plan B. Il faut être passionné par le sujet pour faire quelque chose de bon. Une équipe de trois est la taille idéale pour démarrer un projet. Les bons écrivains sont de bons développeurs. Choisissez les outils qui vous passionnent.

Tout ça me parle beaucoup, et la lecture de ce livre a été très motivante pour continuer les petits (et grands) projets que nous avons en cours.

Vous n’avez pas d’excuse pour ne pas le lire, il est gratuit sur leur site. Moi, après m’être flagellé pour avoir attendu aussi longtemps de le lire, je vais m’attaquer à Rework, leur deuxième best-seller!

Article publié sur le blog de Cédric



blog comments powered by Disqus