Les premiers enseignements de Rework

J'ai déjà parlé plusieurs fois de l'entreprise 37signals, de ses logiciels de gestion de documentation et de projet, et de sa méthode Getting Real. Actuellement, ses membres travaillent au successeur de leur livre, dont le nom sera Rework. Ils ont présenté quelques bribes d'information sur le livre, et je me suis arrêté sur le quatrième de couverture :

Je trouve que le texte qui s'y trouve est très intéressant, un brin controverse, et mérite qu'on s'y attarde. Voici une traduction très libre de son contenu, et ce que j'en pense.

“Dès que possible” est un poison

Il est vrai qu'en entreprise, on rencontre bien souvent ce genre de situation : On essaye de se mettre d'accord sur la spécification d'une nouvelle fonctionnalité, et quand vient le moment d'en définir la date de livraison, on se voit répondre “Dès que possible”. Cela peut sembler la réponse la plus honnête, la plus simple à comprendre de tous et la plus facile à gérer ; mais en fait il s'agit souvent d'un pis-aller qui démontre que le projet n'est pas réellement pris en main.

Quand on demande un développement ASAP (as soon as possible), on abdique sur tous les facteurs qui définissent un projet :

• La définition exacte du projet n'a pas été faite correctement. On sait bien qu'on n'a pas pris le temps de réfléchir à tous les cas limites, à penser à toutes les situations. On sait − mais on ne le dit pas ouvertement − que les développeurs devront affronter tous ces culs-de-sac fonctionnels au fur et à mesure qu'ils se casseront les dents dessus, ce qui empêche d'apporter une quelconque valeur aux estimations qu'ils peuvent faire de leurs développements.
• À partir du moment où la seule contrainte exprimée est celle du temps passé sur le projet, on accepte implicitement que des raccourcis soient fait pour atteindre l'objectif au plus vite. Un aspect en pâtira forcément, qu'il s'agisse de la qualité générale de la réalisation, de la maintenabilité du code, des tests, du débuggage, ...
• À l'inverse, l'absence de deadline réaliste autorise les développeurs à se lancer dans des développements inutiles (je ne parle même pas de ceux qui se tournent les pouces). On arrive ainsi à des situations où on découvre au bout de 2 semaines que le développement “ASAP” aurait pu durer 4 jours si on avait pris le temps de dimensionner et budgéter le projet correctement ; mais si on en fait la remarque au(x) développeur(s), on obtient une réponse du genre «Ah, moi j'estime que tout ce que j'ai fait était nécessaire pour que le projet fonctionne correctement. Il fallait me prévenir si c'était plus urgent que ça !».

Tout cela ne peut conduire qu'à un seul résultat : tout le monde est mécontent. Le client trouvera forcément une raison pour dire que le résultat final est en-dessous de ses attentes : soit il pensait que le développement allait être plus rapide, soit il lui trouvera des défauts dans sa réalisation, soit il le trouvera trop cher.
Pour leur part, les développeurs qui auront travaillé dessus auront toujours un arrière-goût amer : soit il n'auront pas reçu des spécifications précises et auront dû travailler "au jugé" ; soit il auront passé trop de temps sur le projet (trop cher !), soit ils n'auront pas passé assez de temps dessus (mauvaise qualité !).

Éviter la compétition

Ce conseil est intéressant, parce qu'on peut l'interpréter aussi bien d'un point de vue interne à une entreprise, que comme un conseil dans la création de produit ou de service.

Pour le point de vue interne, on ne compte plus les témoignages d'entreprises où chaque projet est le lieu d'une lutte de pouvoir entre personnes ou entre services. Plutôt que de voir le but final (réussir le projet, faire avancer l'entreprise, faire progresser l'activité économique, créer de la richesse), on peut assister à une compétition féroce qui est une pure perte de temps et d'énergie.
Un vieil exemple très connu de ce genre de chose est la manière dont Steve Jobs gérait les choses chez Apple au début des années 80. Il avait réussi à creuser un véritable fossé entre l'équipe qui travaillait sur l'Apple 2 (qui faisait vivre l'entreprise) et celle qui développait le Macintosh (la nouvelle machine . La haine entre les équipes était devenue encore plus forte que celle qu'elles éprouvaient pour IBM ; certaines personnes en étaient même venues aux mains. Au final, le développement du Macintosh a coûté plus cher qu'il n'aurait pu et Steve Jobs s'est fait virer (je simplifie à l'extrême, ne me faite pas un procès sur l'histoire d'Apple).

La coopération doit être le seul mode de travail en entreprise. Il faut être vigilant sur la manière dont les personnes agissent les unes par rapport aux autres, afin qu'elles visent toutes un but commun.

Pour ce qui est de la création de produits et de services, les auteurs de Getting Real disaient déjà qu'il faut être original et ne pas tenter de copier simplement un service existant. J'imagine qu'ils ne sont pas contents de voir le nombre d'outils qui s'inspirent fortement de Basecamp...
Leur point de vue se justifie pleinement. Quand on se contente de copier, il devient quasiment impossible de se démarquer de l'original, ni d'exprimer la moindre créativité.

D'un autre côté, ce raisonnement pose problème : où se situe la limite entre l'inspiration et la copie ? D'autant plus qu'un autre de leurs préceptes, “Choisissez un combat” (voir plus bas) peut éventuellement remettre des choses en cause à ce niveau.

Les réunions sont toxiques

Il s'agit là d'un sujet largement débattu dans Getting Real, et sur lequel je me suis déjà exprimé (ici et ici). Chez 37signals, ce sont des militants du "zéro réunion". Les réunions, c'est mal ; on y perd son temps et celui des autres.
Mais d'un autre côté, ils utilisent leurs outils de communication instantanée pour réfléchir à plusieurs sur leurs projets en cours, et prendre les décisions qui s'imposent. Je n'arrive pas à voir comment des décisions peuvent être prises plus vite en chattant qu'en parlant autour d'une table.

Évidemment, il faut éviter les réunions où 15 personnes se retrouvent pendant 2 heures, à bailler pendant 1h56 et à ne prendre part activement que 4 minutes chacun...
Mais je persiste à dire que lorsqu'on veut prendre des décision importantes et structurantes, il vaut mieux mettre 3 personnes autour d'une table pendant 15 minutes, plutôt que de vouloir tout régler de manière informelle "entre 2 portes".

Virez les drogués du boulot / agissez comme un dealer de drogue

Le “en faire moins pour en faire plus” est un des principes à la mode en ce moment. Chez 37signals, ils vont même plus loin : ils n'aiment pas l'expression “Less is more”, parce qu'elle véhicule quand même l'idée que "plus" reste mieux que "moins". Eux seraient plutôt partisans du "Less is better". Et de la même manière qu'ils appliquent ce précepte à l'ergonomie et aux fonctionnalités, ils l'appliquent aussi à la gestion du temps de travail.

Chez 37signals, les 8 heures de travail quotidien semblent être habituellement une "moyenne haute". L'idée principale est qu'il vaut mieux faire des journées plus courtes, mais dont chaque moment est consacré à la réalisation d'une tâche vraiment importante. Et donc, au lieu de s'autoriser à perdre du temps sur des activités non-essentielles, il vaut mieux identifier les priorités réelles pour les exécuter au plus tôt.

Le parallèle qu'ils font avec les vendeurs de drogue peut sembler un peu déplacée. Mais si on décide de la prendre sur un ton humoristique, on peut se dire que c'est plutôt bien vu, au final.
L'image habituelle des dealers, c'est celle de fainéants qui ont trouvé un moyen pour se faire facilement beaucoup d'argent. Et pour y arriver, ils ont quelques astuces :

• En faire le moins possible, donc se concentrer sur l'essentiel. Tout se qui ne va pas servir à développer le business est écarté rapidement.
• Déléguer un maximum de tâches. Les dealers sont connus pour mettre en place des systèmes pyramidaux de partage de revenus. Ils font souvent appels à des adolescents pour transporter la drogue, voire même pour la revendre à certains endroits.
• Appâter le client et assurer la récurrence des revenus. Le principe même de la drogue, c'est qu'on devient accro. Mais les dealers offrent des doses gratuites pour trouver de nouveaux clients. C'est un principe marketing finalement assez courant.

Choisissez un combat

Là encore, rien de bien nouveau par rapport à Getting Real. Pour eux, le meilleur moyen de définir un business et de garder le cap, c'est de se trouver un objectif qui définisse un combat. Ainsi, ils définissent Basecamp comme étant l'ennemi des gros logiciels de gestion de projet comme Microsoft Project, qui sont lourds, complexes et mal adaptés. Cela rappelle aussi Apple, pour qui l'ennemi était IBM et son informatique terne et sclérosée.

Donc si vous devez définir votre activité, faites-le en vous comparant avec un produit similaire. Trouvez-en les faiblesses, les points sur lesquels vous allez être différent, et faites-en un objectifs clair. Cela deviendra une direction à suivre, un but qui doit motiver vos équipes. Cela facilitera aussi le positionnement de votre produit ou service ; il sera plus évident à comprendre si sa définition même explique en quoi il se démarque des concurrents bien connus.

Planifier = supputer

Il s'agit d'une remarque qui pourrait en faire bondir plus d'un. Quoi ? Faudrait-il virer les plannings ? Hérésie !

En fait, la question se pose différemment. Souvenez-vous que 37signals est un éditeur de logiciels. Les contraintes ne sont pas les mêmes suivant que l'on soit son propre client, ou qu'on ait des comptes à rendre à un client externe.
Dans Getting Real, ils exposent leur manière de fonctionner : dans un processus itératif, plutôt que de vouloir à tout prix planifier les développements, ils préfèrent établir des deadlines, et de découper les fonctionnalités ; si un développement ne sera pas prêt à temps pour la date prévue, ils l'écartent et sortent une version parfaitement fonctionnelle, et gardent la fonctionnalité manquante pour la prochaine version.

C'est une manière de travailler qui a fait ses preuves. Elle a le mérite d'être simple à comprendre, facile à appliquer, et de garantir la sortie de logiciels stables. Par contre, ce n'est pas une méthode de travail qui est utilisable lorsqu'on s'est engagé sur un périmètre fonctionnel et sur une date de livraison. Dans ce cas-là, il faut mettre en place des méthodes de travail plus stricts et procédurières.

L'inspiration est périssable

J'ai du mal à vraiment comprendre cette phrase. J'imagine qu'elle peut être interprétée de plusieurs manières différentes... Je peux en imaginer 2 pour le moment :

• Un logiciel qui a été imaginé un jour, puis développé sur une période plus ou moins longue, est forcément le reflet d'une époque. Son idée fondatrice ne serait plus la même si le même logiciel était développé plusieurs années plus tard, aussi il est important de l'améliorer constamment. Les tableurs modernes n'ont plus grand-chose à voir avec VisiCalc ni Multiplan ; ils ont su évoluer avec le temps. Les traitements de texte actuels sont bien loin du premier WordPerfect ; mais surtout, les utilisateurs ont désormais une relation au "document" qui a bien changé. L'approche itérative n'est donc pas uniquement valable pour le développement pur, mais aussi pour la recherche d'innovations fonctionnelles.
• L'inspiration qui pousse à imaginer des nouveaux produits, de nouveaux services, n'est que la première étape d'un processus créatif. Si elle n'est pas suivi d'un travail passionné et efficace, elle en restera toujours à l'état d'idée vaporeuse. Et si une idée est valable à un instant donné, sa valeur intrinsèque − ce qui fait qu'elle vaut la peine d'être développée concrètement − risque de chuter au fur et à mesure que le temps va passer. Entre les concurrents qui vont prendre position au fil du temps, l'apparition de nouvelles technologies, les changements d'habitudes des consommateurs... Quand on a une bonne idée, il faut se lancer et la faire fructifier avec qu'elle ne soit devenue totalement caduque.