Améliorer les flux d’information

AmauryOrganisation d'équipeLaissez un commentaire sur 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.

Réduire les goulets d’étranglement

AmauryOrganisation d'équipe3 commentaires sur Réduire les goulets d’étranglement

Un lecteur de ce blog a fait appel à moi récemment pour l’aider à améliorer l’organisation de son entreprise. Je ne suis pas consultant et je ne cherche pas à l’être, mais j’ai grandement apprécié l’expérience. Je ne vais évidemment rien divulguer de confidentiel à ce propos, mais j’ai quand même envie de partager avec vous quelques éléments fondamentaux de notre discussion.

Il s’agit presque d’un cas d’école : Une petite entreprise qui existe depuis assez longtemps, et avec juste assez de turn-over, pour qu’une partie non négligeable de la connaissance d’entreprise (expérience des clients, expertise technique, gestion des projets) soit concentrée sur le patron. Certains projets ont beau être gérés par d’autres personnes, il continue à jouer un rôle central qui finit par ralentir l’ensemble de l’activité.

Je lui ai proposé un plan de bataille en trois étapes :

  1. Déléguer
  2. Communiquer
  3. Définir un référentiel

Déléguer

Il me semblait important de commencer par imposer une nécessité : Déléguer tous les projets. Quand on est patron d’une entreprise, il faut pouvoir avoir un œil sur l’ensemble des projets, pouvoir intervenir dessus quand il le faut ; mais il ne faut pas être la personne qui a la responsabilité de la réussite du projet.

En déléguant chaque projet, on responsabilise les membres de l’équipe, et on se ménage la possibilité d’aider chaque projet au mieux en fonction des besoins.

Pour résumer, lorsqu’une personne concentre ainsi une majorité de connaissances, elle ne peut pas se consacrer à un projet − cela aurait un impact trop négatif sur tous les autres. Il faut prendre de la hauteur.
Être un manager et non un leader.

Par contre, il faut bien comprendre que la délégation des responsabilités ne veut pas dire qu’on se lave les mains des projets. Il faut au contraire forcer les collaborateurs à découper leurs tâches le plus finement possible. Ainsi il sera facile de définir les priorités entre les tâches, d’évaluer leurs durées, bref de combattre l’effet tunnel.

Communiquer

C’est bien beau de tout déléguer, mais cela fait prendre des risques. Et quand on a pris l’habitude d’être au centre de tous les projets, c’est forcément un peu effrayant.

La plupart des entreprises organisent une réunion hebdomadaire de suivi de projets. Sauf qu’il est difficile de passer le reste de la semaine sans avoir une vision précise de l’avancement des projets, et en cas de soucis on peut rapidement se prendre une semaine entière de retard. C’est ce qui amène souvent à faire du micro-management : on passe son temps à regarder au-dessus de l’épaule des autres, pour savoir où ils en sont ; c’est inefficace et désagréable.

Les clés de la réussite

AmauryVotre carrière4 commentaires sur Les clés de la réussite

Je n’aime pas le titre de cet article, il est assez pompeux et ressemble à une « formule miracle ». Mais je n’en ai pas trouvé de meilleur.

Je me suis déjà retrouvé plusieurs fois à tenter d’expliquer à de jeunes informaticiens (hum, même à des moins jeunes, d’ailleurs) les divers principes à appliquer au quotidien pour faire avancer leur carrière ou améliorer la manière dont ils gèrent leur travail. Et avec le temps, je me suis rendu compte que ces principes peuvent au final être résumés en 3 points clés :

  1. Simplicité
  2. Communication
  3. Passion

Évidemment, ils ne suffisent pas à donner toutes les directions à suivre. Mais si, jour après jour, chaque action est guidée par ces 3 principes, on se rend compte que l’on fait naturellement de bien meilleurs choix. Je me suis surpris moi-même récemment, au moment de prendre certaines décisions, à me demander «N’est-ce pas trop compliqué ? Qui dois-je en avertir et avec quel niveau de détail ? Ai-je vraiment envie de faire ça de cette manière, y ai-je consacré l’attention nécessaire ?». Et cela m’a permis de revoir certains choix de façon éclairée.

Voyons voir en quoi tout cela consiste.

Simplicité

La simplicité est un concept important mais trop souvent sous-estimé. Pourtant, il est valable à tous les niveaux.

Quelques exemples qui seront plus parlant :

  • La modélisation d’un composant logiciel, d’une base de données, d’une API gagne toujours à être la plus simple possible. L’histoire est jonchée de technologies diverses, de protocoles réseaux, qui ont disparu par « sélection naturelle ». À chaque fois que quelque chose est trop compliqué, d’autres technologies plus simples à mettre en œuvre apparaissent. Alors réfléchissez à vos propres développements : s’ils ne sont pas aussi simples qu’ils le pourraient, c’est vous qui allez souffrir à l’avenir.
  • L’offre de produits/services de votre entreprise doit être aussi facile à comprendre que possible pour vos futurs clients. Les offres à tiroirs et les options complexes n’inspirent pas confiance, ils ne donnent pas envie d’acheter. Assurez-vous d’avoir un discours clair et limpide.
  • Vous n’arrivez pas à faire en sorte que votre équipe utilise correctement le coûteux logiciel de gestion de projet que vous avez mis en place, malgré toutes les fonctionnalités hyper-géniales qu’il offre ? Incitez-les à utiliser correctement des outils simples, pour commencer ; donnez-leur un bloc-note à chacun pour noter leurs todo-lists, et gérez vos projets à coups de post-its collés sur un mur visible par tout le monde. Puis introduisez graduellement les outils plus structurés.
  • Vous n’arrivez pas à vous faire comprendre en réunion, vos idées sont systématiquement mises de côté ou on ne vous accorde pas tout le crédit que vous méritez ? Peut-être êtes-vous un peu trop brouillon, vous n’arrivez pas à agencer votre discours. Simplifiez-le ! Ne laissez pas les idées se précipiter toutes en même temps, prenez soin de les trier dans votre tête avant d’en exprimer les grandes lignes avec des phrases courtes.

Vous connaissez l’adage : on n’a pas atteint son but quand il n’y a plus rien à ajouter, mais quand il n’y a plus rien à retirer. Adoptez une approche zen.

Communication

Une bonne communication est nécessaire en toutes circonstances. Quelques exemples :

L’email n’est pas mort

AmauryOrganisation d'équipeLaissez un commentaire sur 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.

Les premiers enseignements de Rework

AmauryOrganisation d'équipe4 commentaires sur 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 !».