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 !».

La diplomatie au travail

Quand on travaille en équipe, on doit apprendre à gérer les rapports humains. Nous ne sommes pas tous égaux face aux relations humaines. Certaines personnes se sentent à l’aise, d’autre non. Certaines personnes n’hésitent pas à imposer leurs vues, d’autres se mettent en retrait.

L’essentiel est de garder, en toute circonstance, un comportement qui permette de travailler efficacement. Si on peut se faire des amis au boulot, c’est la cerise sur le gâteau ; mais il ne faut pas se faire d’ennemis.

Les désaccords

Il existe un principe fondamental en entreprise : Critiquer les idées, pas les personnes

Quand on n’est pas d’accord avec les propositions de quelqu’un, il semble parfois plus facile de chercher à démolir la personne elle-même, plutôt que d’expliquer en quoi on est en désaccord. Ce n’est pas constructif, et vous attirera les inimitiés de vos confrères.

Les réunions

Ah, les réunions… Suivant l’entreprise dans laquelle vous êtes, vous avez l’impression de ne pas en faire suffisamment ou au contraire d’en faire trop. J’ai connu les deux.

La recette

Voici les éléments-clés d’une réunion :

  • Un ordre du jour. Tous les participants à une réunion doivent savoir quel va en être le sujet. Cela peut être formalisé dans un email, ou être implicite si c’est une réunion qui se répète régulièrement. Mais si quelqu’un ne sait pas quel est le thème de la réunion à laquelle il se rend, pour pouvez vous attendre à une belle perte de temps.
  • Des participants. Oui, ça semble un peu bête. Mais pensez bien que toutes les personnes nécessaires aux prises de décisions doivent être présentes, sinon vous serez bon pour refaire une autre réunion par la suite. Évitez aussi les réunions où est conviée la moitié de l’entreprise « au cas où on aurait besoin d’eux » ; vous risquez surtout d’avoir des discussions sans fin qui s’éloignent du sujet, et des personnes qui perdent leur temps à se demander ce qu’elles font là. Si à un moment donné vous vous rendez compte que vous avez besoin de la présence d’une personne qui n’a pas été conviée, interrompez immédiatement la réunion pour aller chercher cette personne.
  • Des décisions claires. Trop souvent, les gens quittent une réunion parce qu’ils ont l’impression d’avoir fait le tour d’un sujet, ou par épuisement personnel. Il faut que les décisions prises à la fin de la réunion soient claires pour tous les participants. Si certains avis n’ont pas été tranchés, soyez clairs aussi sur cet état de fait, en notant éventuellement les impacts que cela peu avoir, et surtout en vous accordant sur les éléments qui empêchent de prendre la décision. S’il manque une analyse, notez à quelle date elle doit être terminée, et qui en est le responsable ; si la personne qui peut prendre la décision n’était pas présente ou n’a pas pu se décider, prévoyez immédiatement une prochaine réunion.
  • Un compte-rendu. Les décisions peuvent sembler claires en sortant de réunion, il n’en reste pas moins que chacun en gardera les souvenirs qu’il aura bien voulu mémoriser (ou qu’il aura daigné noter sur son cahier). Le seul moyen de s’assurer que la réunion sera suivie des effets prévus, c’est d’en rédiger un bilan qui sera envoyé à tous les participants. Impossible alors de se rétracter derrière le « Ah ? Je ne me souviens pas qu’on ait dit ça en réunion… ».