De geek à directeur technique

Il y a environ un an, je vous parlais du logiciel Action Method. Il propose une fonctionnalité «nagging», qui permet de rappeler au responsable d'une tâche que celle-ci réclame une attention particulière ou une exécution rapide.
J'aime bien cette fonction toute simple mais très utile. J'ai implémenté la même chose dans l'outil de gestion de projets qu'on utilise en interne dans mon entreprise, et je pense l'inclure au projet Skriv.

Les leviers de productivité

Avec le temps, je me suis rendu compte que je me servais − et je ne suis pas le seul − du «harcèlement» comme d'une manière normale de travailler. Non pas que je harcèle les gens avec qui je bosse (c'est puni par la loi !), mais je les incite à me harceler.

Je m'explique : De par mon poste de directeur technique, je suis amené à réaliser un certain nombre de choses par moi-même, mais une part importante de mon travail est de permettre aux autres de travailler. Que ce soit en débloquant un développeur qui reste scotché sur un bug, en aidant l'administrateur sur des tâches IT, en discutant de spécifications avec un chef de projet, en organisant les procédures d'une équipe, ... je passe plus de la moitié de mon temps à “mettre de l'huile dans les rouages“.
C'est un calcul simple à faire : Cette vingtaine de personnes, si je peux faire quelque chose pour la rendre plus productive, elle générera plus de résultats que si je me concentre uniquement sur mes tâches. Et même si je ne réussis qu'à améliorer la productivité de 3 personnes, ça en vaudra la peine.

Petit aparté : Cette manière de faire peut être dangereuse si on ne la maîtrise pas. Il ne faut pas devenir le point de passage obligatoire pour toutes les réalisations, sinon on se transforme en goulot d'étranglement. Au lieu de rendre les gens plus productifs, on ralentit au contraire leur travail.

Priorités vs réactivité

Malheureusement, devenir un tel «point central» fait qu'il y a souvent un défilement incessant de personnes qui viennent me demander quelque chose. Parfois c'est juste pour avoir une info ou pour me demander mon avis avant de prendre une décision, d'autres fois c'est pour me demander de réaliser une opération qui va prendre plus de temps.

Au début, je notais les requêtes au fur et à mesure qu'elles arrivaient, en utilisant ma todo-list personnelle, ou notre buglist ou notre logiciel de gestion des tâches. Mais ça ne fonctionnait pas. Les requêtes s'empilaient sans que les demandeurs ne fassent l'effort de réfléchir aux priorités de leurs demandes. Je les traitais suivant leur ordre d'arrivée et non pas suivant leur importance ; j'étais dans la réaction et pas dans la planification.
Évidemment, j'aurais pu simplifier les choses en répondant à chaque demande «Tu as créé un ticket dans la buglist ?», et attendre le lendemain pour revoir l'ordre de priorité de toutes les tâches en attente. Mais perdre en réactivité n'est pas la bonne réponse à un problème d'identification des priorités.

Le harcèlement positif

Au final, quand quelqu'un a besoin de moi, il y a 3 scénarii :

1. Je suis occupé à faire quelque chose d'important et long. Je demande de revenir plus tard, mais je m'informe quand même de l'importance de la demande (au cas où).
2. Je suis occupé, mais je n'en ai plus que pour 2 minutes. Je demande à la personne de s'asseoir à côté de moi et d'attendre que j'ai fini. Quand les demandes ne sont pas si importantes que ça, les gens n'ont naturellement pas la patience d'attendre. Ils agissent comme si j'allais systématiquement m'arrêter de travailler pour traiter leurs requêtes dans la seconde ; mais si on leur demande à eux d'attendre, ils y réfléchissent à 2 fois.
3. Il y a déjà plusieurs personnes qui font le pied de grue pour utiliser mon «temps machine». Dans ce cas, on évalue collégialement les priorités. Mais il y a un effet naturel qui s'ajoute : Lorsque quelqu'un attend depuis longtemps, il fait ce qu'il faut pour ne pas continuer à attendre ; soit il finit par abandonner (ce n'était pas si important finalement), soit il réussit à nous convaincre de l'importance de sa demande.

Quand quelqu'un a réussi à m'atteindre (si je puis dire), je lui demande de rester assis à côté de moi pendant tout le temps que je vais prendre pour réaliser ce qu'il me demande. Ceci est valable pour toutes les tâches «normales». Si une tâche va me prendre plusieurs heures, je l'intègre à ma todo-list globale.
On pourrait s'étonner du fait que je force des non-techniciens à rester près de moi, même quand je ne fais qu'exécuter des actions techniques. Pourtant, c'est justement ce qui fait que cela fonctionne :

• Si la personne s'en va, il y a de gros risques que quelqu'un d'autre arrive juste derrière et me fasse travailler immédiatement sur une tâche plus urgente. Cela a moins de chances d'arriver si je suis visiblement occupé avec une autre personne.
• Si la personne qui me demande quelque chose ne peut pas rester avec moi, si elle a plus important à faire que de s'assurer que je m'en occupe rapidement, c'est sûrement que ce qu'elle me demande n'est pas très important. Ou en tout cas, cela veut dire que j'ai moi aussi d'autres tâches plus importantes dont il faut que je m'occupe.
• En gardant les requérants auprès de moi, je peux leur donner les informations qui leur permettront d'être indépendants la prochaine fois. Si par contre je m'en charge toujours de A à Z, tout seul dans mon coin, il n'y a aucune chance qu'ils montent en compétence.
• Au moment où la tâche est terminée, ils en ont aussitôt un statut exact et complet. Il n'y a pas de tergiversation, il n'y a pas de perte d'information à cause d'une communication incomplète.

Qu'en penser ?

Je suis conscient de l'aspect complètement empirique de cette manière de travailler. Peut-être qu'elle ne peut pas s'appliquer à toutes les personnes ni à toutes les situations. Mais je l'ai vu fonctionner à maintes reprises, et ça fonctionne dans mon entreprise.

D'une certaine manière, cela me rappelle certains aspects de la méthode Getting Real de 37signals. Entre autres son paragraphe Start With No. On peut y retrouver des notions similaires :

• On doit parfois ajouter des contraintes pour devenir plus efficace.
• Les idées importantes finissent toujours par se faire entendre. Sans système de filtrage, c'est la cacophonie.

Il y a quelques heures, j'ai écrit un commentaire en réponse à un billet du blog Entreprise 2.0. Ce billet, intitulé Peut-on envisager une entreprise sans email ? a pour thème l'abolition de l'usage de la messagerie électronique en entreprise. Son auteur estime que les nouveaux outils et les nouvelles pratiques permettent de se passer de l'email, et qu'il serait plus efficace de se concentrer sur l'emploi de plate-formes collaboratives, de messageries instantanées, de blogs d'entreprise, de micro-blogging, ...

J'ai donc écrit un commentaire assez long pour donner mon avis sur la question. Je vais le reprendre ici en le développant un peu, parce que je pense qu'il s'agit d'un débat intéressant, qui est loin d'être clos.

Les outils de communication utilisés en entreprise

Avant de disserter sur l'évolution des communications intra- et inter-entreprises, passons déjà en revue les différents moyens de communication qui sont à notre disposition.

• Le téléphone. Parfait pour les échanges rapides d'information entre deux personnes, il remplace la discussion en face-à-face en éliminant les barrières géographiques. Les discussions orales ont le grand avantage d'être rapides, contrairement aux échanges écrits − qu'ils soient instantanés ou non.
• Le courrier postal et le fax. Encore très largement utilisés pour les échanges de documents écrits ayant une signification juridique, particulièrement lorsqu'il faut y apposer une signature. Je ne connais pas d'entreprise qui envoie ses contrats par email.
• Les emails. C'est un moyen simple et très généralisé d'envoyer des messages textuels à des individus ou des groupes d'individus. La réception de messages se fait de manière non intrusive (contrairement au téléphone), même si cela peut être modifié par divers alertes visuelles et/ou sonores.
• Les blogs d'entreprise. Ils permettent aux collègues d'une même structure d'échanger des idées utiles à l'avancement de leur travail ou de l'entreprise elle-même, dans un cadre où la réactivités des réponses aux idées n'est pas une nécessité forte. Ils permettent de suivre les différentes idées au fil du temps.
• Lespartages de fichier (au sens NFS ou Samba/CIFS). Ils servent à stocker et partager tous types de fichiers, avec deux buts différents mais pas antinomiques : 1) la pérennité des données, 2) l'édition par plusieurs personnes.
• Les wikis. Servent à stocker des données textuelles, avec les mêmes buts qu'un partage de fichiers (pérennité et accès multiple), en y ajoutant une facilité d'accès et des capacités d'édition collaborative accrues (historique des modifications, gestion des révisions).
• Les forums d'entreprise et les messageries instantanées (ou les outils similaires comme Campfire). Ils sont utiles pour une collaboration orientée temps réel. Surtout utile pour les équipes qui sont “éclatées” géographiquement, comme succédané aux discussions de travail habituelles au bureau.
• Le micro-blogging (popularisé par Facebook et Twitter). Sert à donner fréquemment des informations succinctes quant à l’avancement de ses projets.
• Les outils de liste (todo-list, buglist). Ils servent à gérer les tâches à traiter.
• Les lecteurs de flux RSS. Ils facilitent la veille technologique en permettant un accès centralisé rapide à un grand nombre de sources d'information.

On peut remarquer que j'ai aussi bien listé les moyens de communication stricto sensus (comparables au rôle de la voix dans une conversation entre deux personnes), que les moyens d'archivage des communications et des idées (comparable au rôle que les livres tiennent depuis qu'ils ont remplacé les traditions de mémoire orale).

Certains outils regroupent de manière centralisée certains de ces moyens de communication. La plupart des «logiciels de gestion de projet» intègrent au minimum un wiki et une liste de tâches, parfois en y ajoutant un forum et un partage de fichiers.