Rework

Rework

Rework — Jason Fried, David Heinemeier Hansson


J’ai découvert le livre Rework par l’intermédiaire de Tim. Je dois dire que depuis que je l’ai lu, je repense souvent à certaines idées qu’il présente.

Pour la petite histoire, les auteurs Jason Fried et David Heinemeier Hansson sont les fondateurs de 37signals. Cette entreprise propose des outils collaboratifs web à usage professionnel (ils appellent ça des productivity tools, des outils pour être productifs).

Mais on doit surtout à ces deux acolytes la création du framework Ruby on Rails, qui a créé une vraie rupture dans le développement web depuis sa sortie. Après avoir été le framework qui monte, il est devenu celui qu’il faut connaitre.

Jason Fried a également donné une conférence TED sur le thème Pourquoi on ne travaille pas au travail (Why work does not happen at work), thème extrait de Rework.

Rework: le livre

Les auteurs présentent leur recette du succès d’un produit, d’une entreprise, basée sur leur expérience d’entrepreneurs du web. Si leur précédent livre, Getting Real (nous y reviendrons) était clairement axé sur la création d’une application web ; Rework couvre un champ plus large.

It’s time to rework work. Let’s get started.


Il est temps de repenser le travail. C’est parti.

Le livre est organisé autours de chapitres contenant un nombre variable d’idées. Chaque idée est présentée par une phrase d’accroche et par une ou deux pages d’explications. Rework est donc très rapide à lire, mais cela ne veut pas dire qu’il ne soit pas dense.

Beaucoup d’idées sont présentées en peu de mots, mais ils font mouche.

Ce que je retiens

Rework est un livre qu’on est amené à feuilleter et re-feuilleter, lire et relire assez souvent au fil du temps. Une situation au travail nous rappelle quelque chose qu’on a lu, et tout d’un coup l’idée expliquée dans ce livre fait mouche alors qu’on l’avait survolé auparavant. Il est probable que ce que je retiens aujourd’hui soit légèrement différent de ce que je retiendrais de ce livre dans quelques années.

Moins, c’est un plus

Les auteurs de Rework prônent la frugalité à plusieurs niveaux : une petite équipe, un temps et des ressources limitées, et en faire peu (le faire bien).

Les trois idées sont étroitement liées : avec une équipe plus petite, et pas d’argent/de temps, il faut en faire moins. Sauf que plutôt que d’accepter cette situation comme une contrainte, Jason et David nous présentent cette approche comme un choix assumé.

Une petite équipe permet de s’adapter, de réagir aux imprévus, de se réorganiser pour faire face aux événements. Bref, une petite équipe est agile, ses membres communiquent plus facilement, et comme chacun doit faire un peu de tout, l’équipe en entier est plus impliquée dans le produit final. Cette idée se décline de plusieurs manières, et par exemple sur les recrutements.

Hire when it hurts

The right time to hire is when there’s more work than you can handle for a sustained period of time. There should be things you can’t do anymore. You should notice the quality level slipping. That’s when you’re hurting. And that’s when it’s time to hire, not earlier.


Embauchez quand ça fait mal

Le bon moment pour embaucher est quand il y trop de travail par rapport à ce que vous pouvez gérer pendant une période prolongée. Il devrait y avoir des choses que vous ne pouvez plus faire. Vous devriez remarquer que le niveau de qualité baisse. C’est à ce moment que ça fait mal. Et c’est qu’il est temps d’embaucher, pas avant.

Cette approche m’a assez étonné à la première lecture. Mais en y repensant, et en repensant aux expériences du monde professionnel, ce conseil est précieux.

L’autre point appuyé dans ce thème « Less is More  », est tout simplement d’en faire moins. Sous entendu: « mais le faire bien ».

Build half a product, not a half-assed product

You can turn a bunch of great ideas into a crappy product real fast by trying to do them all at once. You just can’t do everything you want to do and do it well. You have limited time, resources, ability, and focus. It’s hard enough to do one thing right. Trying to do ten things well at the same time? Forget about it


Créez un demi produit, pas un produit foireux

Vous pouvez très rapidement transformer un tas d’idées géniales en un produit merdique en essayant de toutes les réaliser à la fois. Vous ne pouvez pas faire tout ce que vous voulez et le faire correctement. Vous avez un temps, des ressources, des compétences et une concentration limités. Il est suffisamment difficile de faire une seule chose correctement. Essayer d’en faire dix à la fois ? Oubliez.

Et là, c’est du vécu. Même si ça semble tomber sous le sens, dans « la vraie vie » c’est très difficile à faire passer. Toutes ces choses qui semblent indispensables sur le moment ne le sont pas, et on s’en rend compte souvent trop tard.

Réduire l’étendue d’un projet implique de savoir dire non à beaucoup de personnes, et de le dire. Dire non à ses propres idées, dire non aux futurs clients qui ont « absolument » besoin de telle ou telle chose, dire non aux demandes d’améliorations des clients actuels. Même si on peut accepter le principe d’un produit limité, quand vient le temps de dire non l’expérience montre que cette posture est difficilement tenue.

Sortir un produit, maintenant

Là encore, on retrouve dans ces idées abordées par Jason et David des principes du développement agile. Celui-ci est également très appuyé : il faut sortir quelque chose.

Cette idée vaut pour la mise sur le marché du produit, comme pour les phases de recette. Le principe est simple : confronter le plus rapidement possible le produit à ses utilisateurs.

Pourquoi ? Parce qu’il y a toutes les chances qu’en écoutant ceux-ci vos priorités changent, et que votre produit s’améliore plus efficacement.

Launch now

Don’t hold everything else up because of a few leftovers. You can do them later. And doing them later may mean doing them better, too.

Don’t mistake this approach for skimping on quality, either. You still want to make something great. This approach just recognizes that the best way to get there is through iterations. Stop imagining what’s going to work. Find out for real.


Lancez-le maintenant

Ne retenez pas tout à cause de quelques points restants. Vous pouvez les faire plus tard. Et les faire plus tard signifie aussi mieux les faire.

Ne confondez pas non plus cette approche avec une reduction de la qualité. Vous voulez toujours quelque chose de grand. Cette approche reconnait seulement que le meilleur moyen d’y arriver est en itérant. Arrêtez d’imaginer ce qui va marcher. Découvrez-le pour de bon.

Autres idées

Je ne vous ai donné qu’un petit aperçu des idées abordées dans Rework. On y parle aussi beaucoup de recrutement, d’organisation du travail, de gestion de crise, et j’en passe. Le livre est très intéressant, et on se plait à parcourir de temps en temps son contenu à la recherche d’un chapitre dont on se souvient.

Par exemple, un petit point qui plaira beaucoup en France (avec cette culture de rester tard au bureau pour montrer qu’on bosse). Je précise que 37signals est une entreprise à Chicago, on ne peut pas dire que ça soit la culture 35 heures.

Send people home at 5

When people have something to do at home, they get down to business. They get their work done at the office because they have somewhere else to be. They find ways to be more efficient because they have to. They need to pick up the kids or get to choir practice. So they use their time wisely.


Renvoyez les gens chez eux à 5h

Quand on a quelque chose à faire à la maison, on va droit au but. On finit ce qu’on a à faire au bureau parce qu’on a ailleurs où aller. On trouve des moyens d’être plus efficace, parce qu’on n’a pas le choix. Il faut aller chercher les enfants ou se rendre à la chorale. On utilise donc notre temps judicieusement.

Je pourrai continuer encore longtemps comme ça, mais mon article risque de reprendre l’intégralité du (très court) livre.

C’est le genre de livre qu’on aimerait prêter, et en tout cas qu’on aime conseiller !

Liens

Commentaires

3 Comments sur « Rework »

  1. ReQ dit :

    Effectivement le livre a l’air intéressant, j’espère que certaines entreprises s’en inspireront…! Le « Hire when it hurts » n’est vraiment pas une réalité, les entreprises sont pilotées fortement à la productivité, et la rime productivité et embauche est compliquée! (mais cependant possible, 1 convaincu, 1!).
    Le dernier point est également intéressant (pour avoir expérimenté le concept du « je pars tôt, ha? tu as pris ta journée? »…), mais avant de crier au scandale n’oublions pas que les américains commencent leur journée de travail généralement plus tôt que les français et ont également moins de congés!

    Bref, si le livre n’est pas trop axé informatique (le framework ne me parle guère oO), I’m in!

  2. Ghusse dit :

    Non, ça ne parle pas du tout d’informatique, mais d’entreprise, de produit, d’équipe, de réunions, de managers.

    Tu peux trouver un extrait sur amazon pour t’en convaincre.

  3. Franck Mée dit :

    Yep, très intéressant. Il est arrivé que certains soient surpris que, arrivant vers 9h-9h30, je parte rarement après 18h. Outre que ça fait déjà plus que les 37h de mon contrat, c’est surtout un constat personnel qui me l’impose : quand j’ai plus de boulot, je reste plus tard, mais ça ne sert grosso modo à rien.
    Je sais pas pour les autres, mais personnellement, il y a deux phénomènes qui s’accumulent et s’aggravent mutuellement :
    — je sais que je vais devoir rester tard, qu’il va falloir que je tienne longtemps, donc j’ai plus tendance à prendre un moment pour me détendre, boire un café ou causer avec les collègues ;
    — je fatigue en fin de journée, donc mon rendement diminue et il me faut plus longtemps pour faire le même boulot. Le pire cas, c’était une brève quasi-finie à 19h15, que j’ai bouclée à 20h30 parce qu’en la relisant, je passais quatre fois sur la même phrase sans comprendre ce que je venais d’écrire.

    Donc, oui, send people home at 5. 😉

Laisser un commentaire