De geek à directeur technique

J'ai entendu récemment un échange qui m'a amusé, entre un oncle et une tante.
Elle de dire :

Mais tu ne m'écoutes pas ?

Et lui de répondre :

Je ne peux pas, tu parles tout le temps !

Derrière cette blague potache, on peut toutefois discerner une vérité universelle. Dans un flot incessant de communication, il devient difficile de faire le tri entre les informations pertinentes et celles qui ne le sont pas.

Dans le monde de l'entreprise, cela est d'autant plus vrai que le nombre d'interlocuteurs est souvent bien plus grand que dans le cadre plus restreint de la sphère familiale proche. Chaque nouvel intervenant sur un projet communique à son tour en direction de toutes les autres personnes concernées, ce qui démultiplie les échanges.

C'est toujours pareil

J'imagine que cela a dû vous arriver, d'effacer plusieurs dizaines d'emails que vous aviez reçu dans la même journée, et qui ne véhiculaient aucune information réellement utile pour vous. Et si vous réfléchissez bien, vous vous souviendrez que vous en avez vous-même envoyé un certain nombre dans la même journée.

Pourquoi envoie-t-on ce genre d'email ? Les raisons habituelles sont, en vrac :

• Pour transmettre l'information à tous ceux qui pourraient en avoir besoin.
• Pour élargir une discussion, s'assurer que notre désaccord avec Untel sera connu de tous.
• Pour faire passer ses choix en douce («Comment ça tu n'es pas au courant ? Je l'ai proposé dans un email il y a 3 semaines et tu ne m'as pas dit non !»).
• Pour se couvrir, en rejetant la faute sur les autres («Ça fait 2 mois que je vous préviens qu'on n'y arrivera pas, à raison de 15 emails par jour !»).

Et quand ce n'est pas par email, ça peut prendre la forme de blogs ou de forums d'entreprise dont le rapport signal/bruit décroit au fur et à mesure que la quantité d'information échangée augmente.

Le pire, c'est qu'on a tous fini par s'habituer à cet état de fait. On a l'impression que c'est comme ça depuis toujours, et il n'y a aucune raison pour que ça change.

Mais on peut éviter ça

Toutes les entreprises devraient pourtant essayer de contrer cette vague incontrôlée de communications inutiles. Parce que le temps perdu par le traitement de ces informations finit par générer des coûts injustifiables.

La bonne nouvelle, c'est qu'il n'y a pas obligatoirement besoin d'une politique d'entreprise globale. Chacun peut commencer par mettre en place des habitudes différentes avec juste ses collègues les plus proches ou son équipe de projet.

La méthode tient en quelques points simples :

1. Avant de transmettre une information, demandez-vous :
   1. Est-ce le destinataire en a vraiment besoin. S'agit-il d'une information nécessaire pour accomplir son travail ?
   2. Est-ce que le vecteur d'information est le plus adapté ? Les échanges d'emails ne sont pas adaptés aux assignations de tâches ni aux partages de documents.
2. Faites ce qu'il faut pour que l'information soit rapidement identifiable par son destinataire :
   1. S'il s'agit d'un email, donnez-lui un titre explicite, et préfixez-le avec le nom du projet concerné. Sur d'autres systèmes d'information, utilisez intelligemment les labels ou tags disponibles.
   2. Synthétisez le contenu de ce que vous voulez transmettre. N'imposez pas aux autres de devoir lire une prose de trois kilomètres de long, ou de devoir relire un échange de 25 emails pour comprendre de quoi il en retourne.

Mon expérience

Évidemment, ce n'est pas toujours facile de simplifier les échanges. On se retrouve parfois dans des situations cocasses, avec des personnes qui se sentent offensées de ne pas avoir été mises en copie d'un email qui ne leur servait à rien, ou d'autres qui déploient des trésors d'ingéniosité pour couvrir leurs arrières de manières nouvelles et originales (comme par exemple en utilisant la "politique de réduction" pour justifier l'absence d'information sur le retard pris par leur projet, alors que plusieurs réunions auraient permi de le faire de toute manière).

De mon côté, je demande à ce que les emails qui me sont envoyés soient préfixés par le nom de projet entre crochets (c'est une convention très répandue). Quelques exemples :

• [IT] Problème serveurs résolu
• [ComprendreChoisir] Ajout fonctionnalité de tri sur page produits ?
• [corporate] On n'a plus de PQ

Je préviens régulièrement mes interlocuteurs qu'un message mal titré sera lu avec beaucoup de retard. Ce n'est pas une volonté de ma part, c'est juste que j'ai au final assez peu de temps à consacrer à mes emails, et je me retrouve parfois plongé dans du boulot jusqu'au cou pendant plusieurs heures. Un message mal titré n'éveillera pas ma curiosité, et risquera d'être lu seulement en fin de journée.

Par ma place de directeur technique, un grand nombre de messages "informatifs" me sont envoyés, qui ne sont là que pour me permettre de garder un œil sur la progression des projets. Je n'y vois pas d'inconvénient, dans la mesure où ces messages ne sont pas prioritaires (ils ne seront peut-être pas lus) et que les mêmes informations arrivent jusqu'à moi lors des réunions quotidiennes que je fais chaque matin avec mon équipe.

Mais j'essaye d'inciter l'ensemble des personnes de mon équipe à réduire la quantité de messages échangés, et à se poser les quelques questions que j'ai cité plus haut. Cela prend du temps, mais c'est utile.

J'ai entendu cette réflexion («Si on ne peut pas l'imprimer, ça n'existe pas») durant une réunion qui avait pour thème les nouveaux tableaux de statistiques que nous sommes en train de mettre en place dans mon entreprise. Elle m'a semblé assez intéressante pour la partager ici.

Nous réfléchissions aux différentes statistiques dont nous avions besoin pour suivre efficacement l'évolution de la communauté formée par les visiteurs des sites Web que nous éditons. Nous pensions à plusieurs moyens d'organiser les choses et les chiffres, en nous demandant comment nous pourrions les exploiter au mieux.
L'un des points de discussion sur lequel nous butions était la manière de présenter les données au fil du temps. Sur des périodes glissantes ou calendaires, avec des chiffres découpés ou cumulatifs, à partir d'une date modifiable ou de la date courante....

L'une des propositions était de récupérer des chiffres relativement bruts, avec plusieurs critères de choix qui nous permettraient de croiser les recherches. Cela peut sembler assez séduisant : ainsi, il serait possible d'obtenir toutes les informations que l'on pourrait souhaiter, sans pour autant tout redévelopper à chaque fois.
Le problème avec une solution de ce type, c'est que les données doivent être consolidées "à la main". L'opérateur humain se retrouve obligé de devoir choisir lui-même différentes périodes pour obtenir les chiffres correspondant, puis porter tous ces chiffres sur des tableaux synthétiques. C'était donc clairement une mauvaise idée.

C'est finalement évident quand on y pense : un outil de statistiques doit permettre de suivre des tendances, des évolutions au fil du temps. Pour y arriver, il faut que l'information soit visible d'un coup d'œil, elle ne devrait pas nécessiter des traitements supplémentaires. Sinon, autant donner directement un accès à la base de données et laisser les opérateurs saisir des requêtes SQL !

J'en parle ici parce qu'il me semble que c'est une idée qui peut être généralisée. Tous les supports qui nous servent à travailler devraient être imprimables et collables au mur.

Dans mon entreprise, les statistiques de visites de nos sites sont imprimées et collées à un mur. Tout le monde peut voir l'évolution de notre trafic et ces courbes rattachent à la réalité, apportent un côté concret qu'il n'est pas toujours évident de percevoir quand on travaille sur des sites Web.

J'ai un ami qui me racontait que, dans son entreprise, ils ont un grand panneau sur lequel ils collent des post-it correspondant aux bugs, aux développements en cours et aux futures fonctionnalités, avec des couleurs différentes. Ça a l'air un peu idiot, très "low-tech", mais il semblerait que c'était assez efficace. Dès qu'un développeur se pose une question, il lui suffit d'aller dans la salle de réunion et de jeter un œil sur la représentation géante de l'état du projet.
L'idée est intéressante et mérite d'être creusée.

Quand on réfléchit à l'ergonomie d'un logiciel ou d'un site Web, on peut assez vite se perdre dans les méandres d'une spécification textuelle dont il est difficile de se faire une représentation en tête, et encore plus difficile à faire évoluer. J'ai vu des situations se débloquées en imprimant le wireframe d'une pages Web, permettant à tous de discuter en se basant sur une représentation partagée par tous.

J'hésite à multiplier les impressions d'indicateurs diverses. La principale raison est écologique (pour tout dire, je suis un gros consommateur de papier de brouillon, et je traque la moindre feuille à recycler ayant encore un verso blanc).