Saines lectures

On m’a déjà demandé plusieurs fois quels étaient les bouquins que je trouvais indispensables. Pour éviter de me répéter, j’ai fais une petite liste qui ne perd rien à être hébergée ici.

Cette liste je la veux minimaliste et exhaustive. Je dis minimaliste parce que pour apparaître dans cette liste un bouquin doit m’avoir fait changer radicalement de point de vue, ou découvrir des idées fondamentales dont j’ignorais tout – c’est un critère plutôt restrictif! En fait ce sont les livres qui définissent ma manière d’appréhender le monde aujourd’hui. Les voici dans le désordre:

  • Approching Infinity : La série d’articles de Mike Masnick de Techdirt sur l’économie numérique. J’ai déjà du la linker 15 fois sur ce blog tellement je la trouve indispensable pour comprendre comment le numérique n’a rien changé à l’économie 😉 Ils avaient compilé un livre à partir de ces articles mais il n’est plus disponible. En attendant tout le contenu est disponible sur le site, tous les articles sont regroupés sur le lien.
  • ReWork de 37 Signals. Celui là aussi je l’ai déjà cité 20 fois, c’est un livre qui change complétement sa perception du monde du travail, tout simplement (dispo en FR, via Tommy)
  • Why Beautiful People Have More Daughters: la vulgarisation de référence de la psychologie évolutionniste. Ce livre permet de comprendre d’où nous viennent nos pulsions animales, nos peurs primales, et à moi ça m’a permit de mieux les vivre!
  • Life Inc de Douglas Rushkoff. Un peu plus difficile à lire que les autres, mais c’est un livre qui ouvre les yeux sur le monde corporatiste. Il repart du moyen age pour comprendre comment s’est constituée la notion d’entreprise, de corporation, c’est vraiment passionnant.
  • Starship Troopers, le livre de Robert Heinlein (et pas le film de Paul Verhoeven), qui existe en français sous le nom Etoiles, garde à vous !. C’est un livre qui a été pas mal critiqué au moment de sa sortie mais qui à mon sens renferme des trésors de philosophie.
  • Le Cycle des Dieux de Bernard Werber (enfin un auteur francais!). Alors ok, à la fin ça part en sucette, mais alors les deux premiers tomes sont juste magiques.

C’est tout pour le moment. Si je pense à autre chose, ou si j’en trouve un autre, je mettrais cette liste à jour. A votre tour maintenant, n’hésitez pas à me proposer votre liste dans les commentaires en bas 🙂

NB: Je me suis permis de mettre mon code affiliate dans les liens Amazon. Pour info ça me file une commission de 5% à utiliser sur leur site: c’est le début de la richesse!

Jason Fried sur pourquoi on ne travaille pas au bureau

Via Laughing Squid (et bien d’autres), la présentation de Jason Fried (37 Signals, co-auteur de ReWork) sur pourquoi on ne travaille pas ou peu au bureau:

Evidemment c’est en anglais, je vous propose donc une traduction en version courte:

  • Bosser c’est comme dormir: il faut du calme pour descendre dans des niveaux de plus en plus profonds. Une interruption arrête le cycle et le fait repartir de 0.
  • Aller au bureau aujourd’hui c’est être garanti d’être dérangé par des centaines d’événements qui tuent la qualité du travail.
  • Les deux pires ennemis du travail sont les managers et les réunions. Ce sont les plus grandes sources de distraction au bureau.
  • Pour sortir du cycle infernal il faut savoir privilégier les moyens d’interruptions passifs (mails, tweets…), passifs dans le sens où l’on peut éteindre le client et choisir quand on souhaite être dérangé.

Rien de nouveau si vous avez lu ReWork, mais c’est toujours sympa d’entendre le message en live.

Enfin! « Watch us Getting Real » révèle le Customer Thermometer

Pour ceux qui suivaient, de près ou de loin, les gens de Watch us Getting Real, ils viennent enfin de réveler leur produit: le Customer Thermometer.

Pour ceux qui ne suivaient pas, je vous raconte l’histoire rapidement. La société 37 Signals, avant d’éditer Rework (dont je parle tous les 3 articles), a sorti un livre intitulé Getting Real. Je n’ai lu que le premier, un ami a lu les 2, il m’a confirmé que c’était globalement la même chose, le plus récent en mieux.

Toujours est-il que le premier livre a inspiré Mark Copeman, un consultant marketing anglais, pour la création d’une application informatique jusqu’à présent tenue secrète. Là où ça devient intéressant, c’est que lui et son équipe ont essayé de suivre à la lettre les enseignements du livre, et qu’ils nous ont fait profiter de leur expérience en temps réel sur Watch us Getting Real. Ce site est devenu un véritable journal de bord d’une start-up se lançant dans le développement d’une web-app.

Pour ceux qui souhaitent à leur tour se lancer, c’est je pense une très saine lecture qui commence ici (la navigation est un peu foireuse, pensez à utiliser les petits liens en italiques en bas des articles pour avancer).

Comment bien choisir son équipe de développement

Un très bon article de Juin 2010 de l’excellent Derek Sivers: comment recruter un programmeur pour être sûr de terminer son projet, via 37 Signals (Rework bla bla).

Traduit à l’arrache et transposé à notre domaine ça donne:

  1. Réduire sa grande idée à une version 1.0, une version réduite au strict minimum des fonctionnalités. On met le reste de côté pour plus tard.
  2. Écrire un résumé de ce que cette version 1.0 est censée faire. Essayer de faire le plus court et précis possible, utiliser des scénarios d’usage écrit en vrai français et/ou des maquettes visuelles
  3. Préciser les actions et chemins de navigation jusqu’au moindre clic (ne pas oublier que c’est uniquement pour la version 1.0!). Cela devrait ressembler à une longue liste simple et claire d’actions.
  4. Regrouper les fonctionnalités et actions en une série de jalons. Il peut être difficile de définir un ordre, mais c’est comme pour construire une maison, d’abord les murs, ensuite le papier peint.
  5. Faire de son premier jalon un projet à part entière. C’est à dire préparer une feuille de mission qui comporte les activités de ce premier jalon, et n’en mentionner aucune autre. Rien des autres jalons, rien de la version 1.0, rien de la version complète.
  6. Faire un appel d’offres sur ce mini projet, et strictement sur ce mini-projet (étape 5). Envoyer l’AO à une dizaine d’acteurs du marché, de types différents  (petite société de conseil spécialisée, grande SSII internationale, freelances, réalisation web…), des boîtes dont vous connaissez la réputation de précédentes missions si possible.
  7. Ne visez pas le prix le plus bas, en tout cas si le but c’est de finir le projet avec succès, l’objectif ici est de recruter au minimum 2 équipes et les mettre en concurrence. Il vaut mieux ne pas prévenir les équipes qu’elles ne sont pas les seules à être retenues, donc ne pas les staffer en interne dans la même pièce…
  8. A ce point de l’aventure, il suffit d’attendre le résultat et de choisir celui que l’on a préféré pour réaliser le reste de la version 1.0, puis de l’application complète, si tout va bien.

Excellent non? Avec ça finis les concours de beauté, que le plus efficace gagne! D’autre part le surcoût financier est minime, le mini-projet devrait se résumer à 5 jours de travail, et il est largement compensé par le gain en terme de risque prestataire.

J’en profite pour copier l’équipe de 37 Signals et mettre l’emphase sur la méthode de Derek Sivers pour optimiser le filtrage des réponses à l’appel d’offre lors de l’étape 6. Au milieu de l’appel d’offre, insérer une note qui indique que pour que la réponse soit prise en compte, il est nécessaire d’inscrire « Je suis réel » en gros et gras sur sa première page. Évidemment, au moment du dépouillage, éviter consciencieusement toutes les réponses qui ne comporteraient pas cette mention 😉

NB : Concernant le blog de Derek, soyez sûr de repasser la langue du traducteur automatique à anglais si vous voulez profiter correctement du contenu. Je ne sais pas ce qu’il donne dans les autres langues, mais en français c’est pitoyable.

Mais où est Charlie?

Thomas Larock pose une bonne question: mais où sont donc passé les bons managers?

Il pose la question en réponse à l’éternelle questionnement dans le monde des bases de données: mais où sont donc passés les bons dBa? (database administrators, administrateurs de bases de données).
Pour la faire courte: pour reconnaître un dBa qui a du potentiel, l’accompagner dans son chemin d’expertise et lui poser des challenges qui le motiveront à s’investir, et bien il faut un bon manager.

Pas de bon manager, pas d’expert SQL Server. On peut même élargir: pas de bon manager, pas de bon rien du tout. Une évidence qu’il fait du bien de rappeler sous la forme d’un auto-diagnostic: si vous vous plaignez du manque de compétence de vos experts, il existe une forte chance que ce soit avant tout un problème de management, et non d’expertise technique ou de recrutement.

Pourquoi j’ajoute recrutement dans la dernière phrase? C’est David Heinemeier Hansson de 37 Signals qui nous en rappelle la raison: le talent ne s’achète pas. Et comme à chaque fois qu’on parle de 37 Signals, j’en profite pour en remettre une couche: lisez ReWork, ça change la vision du monde professionnel, il n’y a pas que moi qui le dit.