Je vous ai déjà parlé de la société 37signals, au travers de ses outils Backpack et Basecamp. Je vais maintenant vous parler du livre qu’elle a publié en 2006 et qui contient toutes les règles de création et de gestion de projets web qu’elle applique en interne : Getting Real, The smarter, faster, easier way to build a successful web application.

Ce livre est disponible :

• Gratuitement, en le lisant en ligne.
• En version PDF pour 19 $ (49 $ pour une licence autorisant 10 copies).
• En version papier, pour 25 $ sur le service de publication à la demande Lulu.com.

Le titre du livre est sûrement un gentil jeu de mots avec la très connue méthode Getting Things Done. Ce clin d’œil est une manière à peine déguisée de dire qu’il faut oublier toutes les méthodes existantes, faire table rase et suivre leur direction. Le livre décrit leur propre méthode agile, qui est censée s’appliquer à la réalisation d’applications web, mais peut être utilisée – au moins partiellement – pour d’autres types de projets ou d’organisations.

37signals

37signals a été fondée en 1999, exerçant une activité de web agency. Au cours des années, elle s’est fait connaître en publiant tout d’abord Basecamp, l’outil de gestion de projet utilisé en interne, puis le framework Ruby on Rails sur lequel Basecamp est basé. Depuis, 37signals a sorti plusieurs services en ligne, allant de la gestion de données jusqu’à la relation client, en passant par la messagerie de groupe. Leur blog d’entreprise, Signal vs Noise, qui parle aussi bien des outils édités par la société que de design et de développement web, est très connu et visité.

Les membres de 37signals sont réputés pour leurs idées très tranchées. Ils savent ce qu’ils veulent et ne se gênent pas pour le dire. Cela a souvent été pris pour de l’arrogance, comme en témoignent un article du magazine Wired de mars 2008 (voir la réponse de 37signals) et un post de Don Norman (voir là aussi leur réponse). Mais il n’empêche que cela fonctionne pour eux, et leur exemple est suivi par un nombre grandissant d’adeptes.

Leur grand principe est de cultiver l’art de la simplicité. Que ce soit dans le design des sites qu’ils créent, dans les fonctionnalités des outils qu’ils proposent, et même dans leur manière de s’organiser, cette recherche quasi esthétique de la sobriété est une constante des 187 pages du livre.

L’approche globale

Les premiers conseils peuvent être appliqués au niveau entrepreneurial :

• Privilégier l’auto-financement.
• Faire des projets plus petits mais mieux ciblés.
• Réalisez des logiciels qui peuvent vous servir.
• Soyez flexibles sur les fonctionnalités, pas sur le budget ni sur les dates de sortie.

Ils conseillent de réduire la complexité des projets, dans 2 buts : Proposer rapidement un produit fonctionnel, et se démarquer grâce à la facilité d’utilisation. Quand 80% des utilisateurs ont besoin d’un wiki, pourquoi leur faire utiliser un traitement de texte lourd et compliqué ? La simplification du logiciel doit donc être un but à viser, mais aussi le premier moyen à utiliser pour mener un projet ; il est préconisé de réduire les fonctionnalités plutôt que de dépenser plus d’argent en embauchant plus de développeurs ou en allongeant la durée du projet.

Ces contraintes sont vues comme profitables, dans la mesure où elles obligent à trouver des solutions créatives pour résoudre les problèmes.

Les projets

Comme tout le reste, les concepts-clés sont simples à appréhender :

• Les logiciels doivent être simples à expliquer. En une phrase, on doit pouvoir faire comprendre ce que fait une application, et en quoi elle se différencie des concurrents.
• Entrer dans le concret rapidement. C’est en ayant un produit sous les yeux qu’on fait avancer le projet. Oubliez les détails, commencez par le plus important. Vous réécrirez plus tard les parties qui le nécessitent, ou ferez les optimisations quand elles s’imposeront d’elles-mêmes.
• Faites des choix. Une ergonomie peut être désagréable pour certains utilisateurs si c’est fait sciemment et que cela participe à la cohésion du tout. N’essayer pas de contenter tout ni tout le monde. De la même manière, réduisez les paramétrages proposés aux utilisateurs ; choisissez à leur place quand c’est possible.
• Un logiciel simple n’est pas simpliste. Il vaut mieux faire une moitié fonctionnelle de logiciel, plutôt qu’un logiciel qui fonctionne à moitié. Choisissez les fonctionnalités et résistez à l’envie de tout implémenter – que ce soit parce que vos clients le demandent ou parce que vous le pouvez. Si ce n’est pas important, ne perdez pas de temps à le faire.
• Prenez le temps de vous demander ce que vos clients ne veulent pas. Où ne faut-il pas mettre les pieds ? Que pouvez-vous vous épargner ?

Leur réalisation

Comme déjà dit plus haut, il faut tout mettre en œuvre pour sortir une première version du logiciel le plus tôt possible. Rien ne remplace les tests grandeur nature, ni les retours des vrais utilisateurs. L’utilisation de principes itératifs permets d’améliorer le produit par la suite. Mais tant que le logiciel n’est pas publié, c’est comme s’il n’existait pas.

Le processus qui conduit à la création d’un logiciel doit aussi être simplifié. Ils préconisent d’oublier la rédaction de spécifications fonctionnelles qui ne sont pas lues, mais au contraire de privilégier un cheminement rapide : cogitation, puis dessins papier, puis maquettes HTML, et enfin codage. Tout doit conduire à cette première version.

La réalisation elle-même doit encourager les petits pas rapides. Un projet doit être découpé en une multitude de mini-projets faciles à développer et tester.

Plusieurs pistes sont fournies concernant la réalisation de projets web :

• Maquetter l’interface avant d’écrire du code.
• Penser au cœur des fonctionnalités, mais penser aussi aux cas limites, comme la première utilisation du logiciel et l’affichage des erreurs. Profiter des premiers accès pour apporter de la documentation non intrusive.
• Réduire la quantité de code nécessaire. Si vous avez besoin de quatre fois plus de code pour ajouter 2 fonctionnalités supplémentaires, demandez-vous si elles sont vitales.
• Ouvrez vos applications par le biais de flux RSS ou d’API, pour permettre à d’autres développeurs de les utiliser pour créer de nouveaux usages.

L’organisation

37signals est une startup et les personnes qui la composent en sont fières. Ils connaissent les avantages d’une petite structure et comment les exploiter au mieux.

• Ne pas séparer les gens. Permettre aux gens de communiquer, quelles que soient leurs spécialités, assure le meilleur résultat global possible.
• Laisser les gens tranquilles. Pour faire son travail, on a besoin de pouvoir s’immerger dedans pendant une période assez longue. Éviter les interruptions rend plus productif.
• Limiter les réunions qui n’ont pas de réelle utilité. Si plus de 2 personnes doivent communiquer, il faut s’assurer que cela est fait de la manière la plus rapide et efficace.
• Entretenir la motivation en réduisant les cycles de développement. Quand un résultat est visible après juste une journée de boulot, tout le monde se montre satisfait et a envie de continuer sur cette lancée.

Le recrutement

Là aussi, quelques règles simples sont expliquées :

• Embaucher peu de monde, et le faire quand c’est absolument nécessaire. Ne pas sous-estimer la complexité d’une organisation faisant intervenir plus de personnes.
• Tester avant d’embaucher. Un projet de test permet de voir concrètement ce que vaut le travail d’un candidat.
• Chercher des gens enthousiastes et qui sont capables de comprendre plusieurs aspects du travail effectué par l’entreprise. Ne pas prendre d’individus hyper-spécialisés qui se transformeront en autistes, qui prendront de mauvaises décisions à cause de leur vision incomplète des choses, ou qui devront être coachés de près.

Et le reste

Je vous passe le détail sur les chapitres consacrés au prix des produits, à leur promotion et au support technique. Ils restent intéressants à lire, ne vous en privez pas.

Mon avis

Difficile de se faire un avis tranché sur la méthode Getting Real. Les recettes qui ont convenu (et qui conviennent encore) à 37signals ne sont pas forcément celles qui conviennent à tout le monde. Mais je dois bien avouer qu’il est assez rafraichissant de voir ces principes écrits noir sur blanc. Trop de startup et de petites entreprises font l’erreur de vouloir mettre en place des procédures lourdes et complexes, s’inspirent de ce que font les grosses compagnies, alors que cela n’est pas adapté.

Seul le côté extrême de certaines propositions me laisse dubitatif.

• Je suis d’accord pour dire qu’il faut limiter les réunions à l’essentiel, mais là, la volonté affichée est le zéro-réunion ; c’est un peu débile.
• L’action est évidemment à privilégier, mais supprimer toute forme de spécification n’est pas applicable à partir du moment où les créateurs ne font pas partie des décideurs.
• Réduire les fonctionnalités au bénéfice du coût et du planning n’est pas toujours le meilleur calcul. Dans certaines situations, on préférera être souple sur les délais pour s’assurer de la présence d’une fonctionnalité qu’on estime importante.
• L’approche itérative est globalement bonne. Mais quand elle devient la seule option envisagée, on risque de faire des erreurs de conception qui seront plus difficiles à rattraper que par un simple refactoring.

Il n’en reste pas moins que je conseille vivement la lecture de ce livre. Si vous hésitez, commencez par la version gratuite.