La compassion au travail

Je suis récemment tombé sur l’émission Brain Games, et l’expérience que j’ai vue m’a semblé intéressante à partager. L’épisode tournait autour de la compassion.

L’expérience se déroulait en trois parties.

Première partie

La première partie avait pour but de définir si les êtres humains sont compatissants de nature.

Des candidats sont conviés un à un dans une pièce. Une fois assis, le candidat peut voir une autre personne assise dans la pièce d’à côté, à travers une glace sans tain. Un scientifique lui explique d’un ton neutre (c’est-à-dire froid, factuel, «scientifique» ; c’est important pour la suite) que la personne en face recevra une somme d’argent s’il peut manger un bol de soupe en entier. Le bol de soupe en question est posé devant le candidat, qui doit y ajouter une sauce ; il a devant lui trois flacons de sauce, étiquetés « doux », « moyen » et « mortel ».

Sur un échantillon assez large pour être représentatif, la grande majorité des candidats choisissent la sauce douce. Par défaut, ils font preuve de sympathie et d’empathie pour la personne qu’ils ont en face d’eux, et même si cette personne ne peut pas les voir à travers le miroir, ils n’ont pas de raison de lui faire un coup vache. Continuer la lecture de « La compassion au travail »

Les pompiers pyromanes

L’un des profils de collaborateur les plus difficiles à manager sont les « pompiers pyromanes ». Voyons à quoi on reconnait un tel profil, les dangers qu’ils peuvent représenter et les solutions qui existent pour les gérer.

C’est quoi un pompier pyromane ?

Peut-être que vous vous êtes déjà retrouvés dans cette situation. Vous assignez des tâches à vos développeurs (ou ils se les répartissent eux-mêmes dans le cas d’une équipe auto-organisée) ; ces tâches sont souvent en deux groupes : les nouveaux développements d’un côté, et les débuggages ou micro-évolutions de l’autre.

Pour schématiser, les nouveaux développements prennent du temps, plusieurs jours voire plusieurs semaines, alors que les débuggages ont des durées qui se comptent en heures la plupart du temps. L’investissement nécessaire est donc très différent, que ce soit au niveau de la réflexion technique à mener que dans la durée de concentration à avoir sur son travail.

Un pompier pyromane, c’est avant tout un « pompier », c’est-à-dire quelqu’un qui se sent bien dans le rôle de sauveur. A chaque fois qu’il résout un bug, il est remercié chaudement par la ou les personnes qui étaient impactées au quotidien. Plus il est rapide dans la résolution de problèmes, plus sa valeur semble augmenter aux yeux de ses collègues. C’est normal, il leur facilite la vie, il résout leurs soucis.

Au fur et à mesure, ce genre de personne va vouloir de moins en moins travailler sur de nouveaux développements. Après tout, pourquoi vouloir bosser dans l’ombre pendant plusieurs jours, à se casser la tête à résoudre des enjeux techniquement complexes ? Quand un nouveau projet est mis en production, les développeurs qui ont travaillé dessus sont rarement acclamés ; ils reçoivent peut-être des félicitations par leur hiérarchie, mais pour les collègues des autres services c’est au final assez peu visible. Dans le pire des cas, c’est même une source de nouveaux bugs. C’est tellement mieux d’être vu comme celui qui corrige les bugs plutôt que d’être celui qui les crée, non ? Continuer la lecture de « Les pompiers pyromanes »

Application concrète des méthodes agiles

J’ai déjà parlé de plusieurs méthodes de travail sur ce blog, depuis le cycle en cascade jusqu’aux méthodes agiles en passant parle cycle en V et les cycles itératifs. Pour illustrer tout ça, je vais vous parler de la manière dont nous gérons les projets dans mon entreprise.

Le contexte

Pour situer un peu les choses, il est nécessaire que je vous parle un peu de l’entreprise elle-même.

Fine Media est éditeur de sites Web ; ce n’est pas une «web agency», nous sommes notre propre client. L’entreprise a officiellement commencé son activité en septembre 2007, elle existe donc depuis plus de 3 ans et demi. Nous sommes actuellement une trentaine de personnes.

Les deux premières années se sont déroulées dans un climat classique de start-up à la française, dans un joyeux mélange d’élaboration de process, de développements itératifs rapides, de recrutements stratégiques et de bonne humeur. Le cap des deux ans d’existence et de la vingtaine de personne s’est passé naturellement, l’entreprise quittant d’ailleurs à ce moment ses premier locaux (sous les toits et un peu serrés) pour un immeuble plus confortable.

L’équipe technique a évolué lentement mais sûrement. J’ai immédiatement embauché un administrateur système et une infographiste. Au départ, je réalisais l’intégralité des développements. Avec l’arrivée successive de nos développeurs, j’ai pu me recentrer sur les projets cruciaux. Nous avons désormais une équipe constituée d’un administrateur, de trois développeurs, de deux infographistes/intégrateurs et de moi-même (directeur technique). Cela reste une équipe réduite, mais qui représente quand même un quart des effectifs. Le reste de l’entreprise est constitué de référenceurs, de rédacteurs, de community managers, et de commerciaux. Les référenceurs ne sont pas considérés comme faisant partie de l’équipe technique, car ils ont un rôle très transverse, à la fois actif au niveau de la technique et de la rédaction.

Comme je le dis plus haut, nous avons longtemps abordé les développements de la même manière que dans la plupart des start-ups. En privilégiant la réactivité, nous avons réussi à mettre en place des choses relativement complexes dans un laps de temps assez court. Quand il le fallait, j’avais l’autorité nécessaire pour faire des choix structurels, soit pour réclamer plus de stabilité dans les développements, soit pour lancer les refactoring qui s’imposaient.

Ceux qui suivent le blog savent que la fin de l’année dernière a été une période un peu mouvementée, avec un énorme refactoring. En 4 mois, on a remis à plat et recodé l’ensemble de tout ce qu’on avait développé en 4 ans sur notre plate-forme principale. Le problème avec ce genre de situation, c’est qu’il est très difficile d’établir un plan de marche : On a beau tronçonner les projets en tous petits bouts, il reste toujours des zones d’ombre. Les projets développés durant la «période start-up» manquaient évidemment de spécifications, et cela s’est fait sentir le jour où on a voulu lister toutes les fonctionnalités qu’il fallait remettre au propre.
Ces 4 mois de travail ont donc été réalisés sur un mode «best-effort» qui ne peut pas durer très longtemps. Cela consiste à faire de son mieux, donc à se mettre une pression relativement forte en continu, avec les horaires et le stress qui vont de paire. Au final, cela a généré beaucoup de frustrations dans l’entreprise ; chez les informaticiens qui en faisaient beaucoup sans jamais avoir l’impression que c’était suffisant ; chez les «fonctionnels» qui avaient peur que la refonte prenne un retard incommensurable.

Refonte organisationnelle

Une fois cette période passée, le risque était grand de «rester» sur le même rythme de travail… c’est-à-dire sans revenir à de vraies méthodes de travail. Il était donc important de mettre en place une organisation stable.

Continuer la lecture de « Application concrète des méthodes agiles »

Les emails en entreprise… encore

J’ai entendu ce matin à la radio une information qui m’a fait bondir (et un peu rigoler). Atos va arrêter l’usage des emails, pour privilégier la communication directe entre ses collaborateurs, tout en mettant en place des outils de communication instantanée. L’argument utilisé est que les collaborateurs reçoivent 200 emails par jour en moyenne, et qu’ils perdent un temps incroyable à les lire (je ne me souviens plus, mais quelque chose comme une vingtaine d’heures par semaine).

Bon, vous connaissez déjà un peu mon avis sur la question (voir aussi cet article).

Oui, devoir lire plusieurs centaines d’emails par jour empêche de travailler efficacement. Mais le problème vient de l’utilisation qui en est faite. Comme je le disais dans un précédent article, les emails ne doivent pas servir de support de gestion de projet, ni de partage de fichiers, ni de liste de tâches. Je ne peux pas concevoir de travailler correctement en étant noyé sous 200 emails quotidiens. Impossible. C’est pour ça qu’on utilise dans mon entreprise des outils correspondant à chaque usage (et c’est pour ça que ceux qui s’amuse à spammer inutilement se font rappeler à l’ordre).

À la radio ce matin, quelqu’un expliquait à un moment qu’il se retrouvait parfois à envoyer des emails à des gens qui sont dans le même bureau que lui, parfois qui sont assis en face de lui. Hum… Il faudrait peut-être commencer par là ? Non quand on a un truc à se dire, on commence par lever notre cul de notre chaise. Ça a l’air bête, hein, mais c’est tellement plus productif !

La réponse technologique m’étonne aussi. Vouloir remplacer les emails par des «outils sociaux» me laisse songeur. La messagerie électronique et la messagerie instantanée sont complémentaires, mais pas en concurrence ; ils correspondent à des usages et des besoins différents. Les forums de discussion peuvent être très utiles en entreprise, pour mener à bien des prises de décision par des équipes projet qui sont dispersées géographiquement. Est-ce pour autant qu’il faut abandonner les emails ?
En plus, j’espère que vous serez d’accord avec moi : la plupart du temps, il est plus rapide et efficace d’avoir une bonne discussion en face à face ou par téléphone, plutôt que de perdre du temps à taper au clavier. Cette remarque est valable aussi bien pour les emails que pour le “tchat” ou les forums de discussion.
Vouloir remplacer l’email, qui est non-intrusif, par de la visio-conférence ou par la messagerie instantanée  ? Cela restera un effort aussi vain que d’avoir voulu remplacer le téléphone par ces mêmes outils. Ils sont tous voués à se développer en parallèle, s’enrichissant les uns les autres sans pour autant se remplacer les uns les autres.

Je me pose une question : Comment les commerciaux et les chefs de projets d’Atos vont faire pour discuter avec leurs clients ? Ils vont systématiquement imposer leurs outils de communication ? Sans rire ?

Alors évidemment, il y a des choses à améliorer dans le courrier électronique. Aussi bien dans son aspect technique que dans son utilisation :

  • Le simple fait de voir les messages comme une discussion, tel que le fait Gmail, évite les redites inutiles.
  • Les entreprises peuvent définir des règles d’écriture des messages internes, avec des normes concernant les titres des messages, pour s’y retrouver plus facilement.
  • Et évidemment, il faut mettre en place des passerelles entre les différents moyens de communication, pour aider les utilisateurs à monter en compétence sur les outils les plus adaptés à chaque besoin.

Ça vaut ce que ça vaut, mais j’ai travaillé dans des entreprises qui ont fait des tentatives d’utilisation de messagerie instantanée. Le résultat était simplement que 80% des messages échangés n’avaient absolument rien de professionnels, et que ces outils étaient majoritairement utilisés pour prolonger les discussions entamées durant la pause-café sans se faire attraper par la hiérarchie. Un peu comme ceux qui gardent une fenêtre ouverte sur Facebook dans un coin pour discuter tout au long de la journée…

Améliorer les flux d’information

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.

Continuer la lecture de « Améliorer les flux d’information »

Citation : «Vendredi 17h, ça veut dire lundi»

Vendredi matin, un de mes collègues est venu me voir pour qu’on planifie une petite réunion de travail plus tard dans la journée. Si vous avez lu mon billet sur le harcèlement positif, vous savez déjà comment je travaille : Lorsque quelqu’un a besoin de moi pour accomplir une tâche urgente, j’impose à cette personne de rester avec moi pendant que je m’en occupe, même si elle ne fait que me regarder. Par contre, lorsqu’une tâche « externe » (comprendre : qui n’est pas une de mes tâches) n’est pas urgente, j’ai un peu tendance à la repousser jusqu’à ce qu’elle devienne plus importante que mes projets en cours − parce que sinon je ne fais que traiter les problèmes des autres, jamais les miens (et vous pouvez imaginer qu’on me confie des problèmes assez importants).

Donc là, sans réfléchir, j’ai eu le mauvais réflexe de lui proposer de venir me voir à 17h00. Et il m’a répondu très intelligemment : «Vendredi 17h, ça veut dire lundi»

Son point de vue est assez juste. Connaissant les risques de voir des choses urgentes surgir du néant le vendredi soir, qu’on est obligé de régler avant de partir en week-end (loi de Murphy, quand tu nous tiens…), placer une réunion de travail à cet horaire n’était pas très judicieux.

En plus, si ça n’allait pas être traité ce vendredi soir, cela n’aurait pas été le cas non plus le lundi matin (à cause des divers réunions hebdomadaires). Donc lundi après-midi ? Wow, ça commence à faire un gros décalage.

La solution ? On a placé la réunion à 16h30. Les urgences du moment nous ont fait commencer à 16h40, et tout s’est bien passé.

De manière plus générale, il faut toujours envisager le pire. Je reparlerai sûrement de ce sujet dans un autre billet, parce que c’est important. Mais prenons un autre exemple : comme beaucoup d’entreprises, nous ne faisons jamais de mises en production le vendredi. Le risque est trop grand qu’une évolution introduise un bug qui ne soit pas visible immédiatement, ou qu’un « retour-arrière » soit très délicat. Se donner au moins une journée de tampon est une bonne pratique.

Pour tout dire, dans les premiers mois de mon entreprise, nous nous sommes permis quelques fois de passer en production des développements le vendredi, un peu «à l’arrache». À chaque fois, nous pensions que le risque était limité, parce qu’il s’agissait d’évolutions mineures, qui touchaient une partie bien définie du code. Et pourtant, la première version était quasi-systématiquement bugguée − rien de vraiment grave, mais suffisamment pour imposer une révision correctrice.
À bien y réfléchir, on a quand même connu une ou deux sueurs froides à cause de ces mises en production mal maîtrisées et mal planifiées.

«Rien de sert de courir, il faut partir à point.» Dans certains cas, il vaut mieux devancer la planification pour réduire les risques. Et quand ce n’est pas possible, il ne faut pas hésiter à reporter. Mais dans tous les cas, il faut penser avec sa tête, pas avec sa montre.

Le «harcèlement positif» comme méthode de travail

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.

Du micro-management jusqu’à la délégation, le long parcours de la confiance

Quand on gère une équipe, on se retrouve régulièrement confronté à un dilemme : Quand et comment déléguer ?
Même si on n’est pas un control freak, on ne va pas confier “les clés de la maison” aveuglément ; mais d’un autre côté, il n’est pas possible de demander aux gens de donner le meilleur d’eux-mêmes si on est sans cesse en train de les surveiller. Alors que faire ?

Types de management

La plupart des livres et méthodes de management mettent en avant 2 points qui sont réellement importants (et qui sont liés l’un à l’autre) :

  • Il faut responsabiliser les personnes que l’on encadre. Ainsi ils gagneront en confiance, prendront des initiatives, réfléchiront par eux-même, travailleront de manière autonome, feront attention à la qualité de leur travail.
  • Le corollaire : Il ne faut pas faire de micro-management.

Le micro-management consiste à être continuellement sur le dos des membres de son équipe, de surveiller leurs moindres faits et gestes. C’est une mauvaise pratique pour plusieurs raisons :

  • Une surveillance constante induit un climat pesant et génère du stress. Personne n’aime travailler dans ces conditions, la qualité du travail ne peut pas être optimale.
  • Quand on est à l’affut de la plus petite erreur, et qu’on signale chaque maladresse, on place la personne dans une situation d’échec continuel qui est fortement démoralisante.
  • Tous les processus d’apprentissage comportent des cycles erreur-réessai qui ne peuvent pas se faire si on est paralysé par la hantise de l’échec.
  • Dans une moindre mesure, quand on surveille les autres, on ne fait rien de réellement productif soi-même.

Donc nous sommes d’accord, il faut éviter le micro-management.
Mais l’excès inverse est tout aussi néfaste. Je connais des gens dont la technique de management est «Laisser les gars se débrouiller» ; cela a pour résultat de “laisser les gars dans la merde” et non pas de créer des gars débrouillards.

La confiance

On en vient au point essentiel : la confiance
Il est impossible de confier des responsabilités à quelqu’un si on ne fait pas confiance à cette personne.

Continuer la lecture de « Du micro-management jusqu’à la délégation, le long parcours de la confiance »

L’email n’est pas mort

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.

Continuer la lecture de « L’email n’est pas mort »

Communication et productivité : synonymes ou antonymes ?

Je suis assez étonné et amusé de remarquer qu’il existe des « courants de pensée » assez contradictoires concernant les méthodes à employer pour maximiser sa productivité personnelle. Certaines solutions proposées sont un peu extrêmes dans leur propos et revendiquent leur manque de nuance. Qu’elles soient le résultat d’une démarche personnelle et la dernière méthode à la mode, il semblerait que leur adoption doit être obligatoirement sans demi-mesure…

La sur-communication

Je vais commencer par vous parler de ce qu’on appelle l’«Entreprise 2.0». Derrière ce terme un peu brumeux (et repompé du «Web 2.0») se cache un ensemble de pratiques qui ont pour but d’amener les plate-formes de travail en entreprise vers des pratiques plus participatives, plus “organiques” − quoi que cela veuille dire.

Si on regarde bien, cette démarche a été entamée il y a un bon nombre d’années déjà, lorsque les entreprises ont commencé à migrer leurs gestions documentaires simplistes (partage de documents en réseau) ou difficiles d’accès (GED de premières générations) par des intranets intégrant wikis, blogs et bookmarks partagés. Et il faut bien avouer qu’en procédant ainsi, l’accès à l’information est devenu plus facile et leur mise à jour est plus fréquente.
Rapprocher l’information de ceux qui en ont besoin, tout en leur permettant de la modifier facilement, permet de rendre celle-ci moins « monolithique ».

C’est un bon exemple de cas où ce sont les outils qui ont amené un changement d’utilisation en douceur, ce qui n’aurait pu être fait par un changement d’organisation et de process.

Certains partisans de l’«Entreprise 2.0» veulent pousser ce concept beaucoup plus loin. Pour faire simple, Facebook et Twitter sont des outils super géniaux (et surtout particulièrement à la mode en ce moment), il faut à tout prix généraliser et codifier leur utilisation. Ils théorisent donc sur le fait que la prochaine étape est d’avoir des collaborateurs qui communiquent de manière proactive, informent leurs collègues de ce qu’ils font et à quoi ils réfléchissent, en utilisant des canaux de micro-information propres à l’entreprise.

La sous-communication

A contrario, un bon nombre de méthodes d’organisation personnelle obligent à fermer les vannes de l’information entrantes. Qu’il s’agisse du téléphone (toujours laisser le répondeur gérer les appels), des emails (à ne lire qu’une à deux fois par jour) ou des réunions (à éviter comme la peste), l’idée est la même : Ce sont des sources de distraction qui empêchent de se concentrer sur les tâches qui réclament notre attention. Éliminer les sources de distraction permet donc, par un effet mécanique, de consacrer plus de temps à faire du travail « utile », et donc de devenir plus productif.

Continuer la lecture de « Communication et productivité : synonymes ou antonymes ? »