Canaliser les flux de communication

<Paul>  Je viens en renfort sur le projet, par ou est-ce que je commence ?
<Stephane>  2 minutes, je t'envoie toutes les informations par e-mail.
<Jerome>  Je t'envoie aussi les infos que j'ai.

Qui n'a jamais rencontré cette situation ? C'est malheureusement un cas d'école de choses à éviter :

  • malgré ses bonnes intentions, Stéphane va oublier quelque chose, ou bien se tromper ;
  • ce qu'il corrigera dans d'autres e-mails, après qu'un problème eût été détecté ;
  • les informations envoyées par Jérôme seront différentes ;
  • on peut prédire que le prochain collaborateur obtiendra aussi des informations différentes ;
  • dans 6 mois il sera très difficile de retrouver ces informations ;
  • si tous les membres de l'équipe partent, alors la connaissance est perdue en même temps que leurs archives e-mail ;
  • et bien d'autres désagréments...

Pourtant, l'information est là, et les membres de l'équipe font l'effort de transmettre cette information. Une hypothèse fort plausible, c'est qu'ils utilisent un canal de communication inadapté à leur besoin. Ici, une documentation projet paraîtrait bien plus pertinente.

Des exemples comme celui-ci, on en rencontre beaucoup au cours de notre travail quotidien. Si on fait la somme, on se rend compte qu'ils peuvent générer de nombreux soucis.

Cet article est une réflexion sur les canaux de communication au sein d'une équipe projet. L'objectif est de partager des observations à propos de patterns plus ou moins adaptés, pour ensuite suggérer des solutions.

Note

Oups ! le sommaire est un tantinet conséquent... Qu'importe ! Piochez dans les exemples les cas qui vous sont les plus familiers, et ne lisez pas le reste ;)

Cet article n'est pas une documentation

"Eat your own food", dit-on.

L'objectif de cet article est de sensibiliser sur la problématiques des canaux de communication. Il pourra servir de base pour lancer et nourrir une discussion à propos de la communication au sein d'une équipe.

Par contre, cet article de blog n'est pas adapté pour servir de référence :

  • adapté pour communiquer une information, un point de vue à une date donnée ;
  • ne sera vraisemblablement pas mis à jour ou maintenu ;
  • n'est pas rédigé de manière collaborative ;
  • il a donc vocation à être obsolète, partial, incomplet...
  • ... j'essaye d'en tenir compte en le rédigeant, utilisez-le comme tel ;)

Caractériser les flux d'information

Quelques critères

Voici quelques critères qui peuvent faciliter l'aiguillage d'une information :

  • quelle est la durée de vie de l'information ? Faut-il qu'elle soit archivée ?
  • à qui s'adresse l'information ? Qui devrait la recevoir ? Qui ne doit pas la recevoir ?
  • l'information est-elle spécifique au produit ? concerne-t-elle un produit tiers ?
  • quel retour attend-on ? une réponse immédiate ? une action ?
  • quelle est la valeur de la communication ? Qu'apporte-t-elle ? A-t-elle une répercussion directe sur le produit ?

Flux d'échange et flux de production

On peut souvent classer des flux de communication dans des canaux d'échange ou de production.

Canaux d'échange

Discussions, démonstrations... Ces communications se réalisent autour duproduit. Elles le guident, l'accompagnent, l'enveloppent.

Deux exemples :

  • les discussions de vive voix ;
  • les messages e-mail.

Quelques-unes de leurs caractéristiques :

  • Communications privées, le nombre de protagonistes est limité ;
  • Elles sont ponctuelles, inadaptées pour ce qui doit perdurer ;
  • Le "bruit" peut y être très important ;
  • De même que la dispersion (plusieurs sujets).

Canaux de production

Le produit est le support de communication.

Deux exemples :

  • le code ;
  • la documentation du projet : à partir du moment où on l'intègre dans le dépôt avec le code, la documentation est partie intégrante du produit au même titre que le code.

Une approche pragmatique est de diriger au maximum les communications dans les canaux de production, dans la mesure où cela ne nuit pas à la qualité du produit.

Pour un projet

Ce qui suit est une liste non exhaustive de cas d'utilisation observés sur les projets sur lesquels je travaille. Ces "cas d'utilisation" s'avèrent généralement liés à des ressources, voire à des services.

Pour chacun, j'essaye d'indiquer le contexte, la problématique et de proposer des outils.

Point d'entrée

C'est l'exemple énoncé en introduction de cet article.

Échec

  • Demander où trouver les informations sur un projet.
  • Ne pas obtenir de réponse, ou ne pas trouver ces informations.
  • Envoyer un e-mail pour fournir les liens utiles pour démarrer sur un projet.

Succès

  • Savoir chercher les informations sur un projet de manière autonome.
  • Trouver ces informations : tous les liens utiles pour démarrer.
  • Les explications sont les mêmes pour tous.

Outils

  • Un "point d'entrée" standard. Le consulter est un réflexe. Son rôle est d'abord d'orienter, pas de documenter en détail.

Contenu du point d'entrée

  • des références vers les autres ressources du système d'information : dépôt pour le code source, documentation, bugtracker, ERP, CRM, ...
  • de quoi trouver le projet lors d'une recherche. Par exemple des mot-clés.
  • contenu pérenne uniquement. Le contenu du point d'entrée doit nécessiter le moins de maintenance possible. Une stratégie est d'y limiter le contenu et de déporter les informations dans les autres ressources.

Utilisation ponctuelle, forte valeur

Le point d'entrée n'est pas utilisé au quotidien dans le cadre d'un projet. Il est surtout utilisé ponctuellement pour démarrer une action sur un projet qu'on ne connaît pas encore.

Sa valeur n'en est pas moins importante. Notamment parce que le point d'entrée est réputé pérenne, contrairement à l'équipe qui travaille actuellement sur le projet : que sera devenue l'équipe dans 1 an ?

Découverte autonome de projets, contributions spontanées

Le point d'entrée devrait aussi favoriser la découverte de projets. Par exemple, un développeur affecté à un autre projet pourrait à partir du point d'entrée observer de manière autonome le projet, s'en inspirer, voire proposer une contribution si l'une ou l'autre des problématiques lui est familière.

Une problématique à rapprocher de celle de contribution dans le monde de l'open-source. Si un projet est visible et que sa documentation est claire, alors on favorise l'entrée de nouveaux contributeurs.

Implémentation

Le point d'entrée peut être implémenté de diverses façons, par exemple :

  • un service de marque-pages : un ensemble de liens (une catégorie ?) par projet ;
  • un wiki : une page par projet ;
  • une documentation : une page par projet.

Les critères importants me semblent être :

  • moteur de recherche efficace. Si on n'y trouve pas les projets qu'on cherche, alors l'utilité du point d'entrée est sérieusement remise en cause.
  • collaboratif. Même si c'est ponctuel, le point d'accès doit être maintenu. Il est conseillé qu'un maximum de personnes puissent assumer cette maintenance.
  • permissions d'accès adaptées à la politique de permissions choisie. S'il est question d'ouvrir l'accès à une page projet au product owner, il sera peut-être question de lui fermer l'accès aux pages d'autres projets (autres clients).
  • flux RSS ou autres logs et/ou triggers permettant de se tenir informé des changements.

Code source

Le code source est généralement un élément important dans un projet. C'est aussi un flux de communication en soi :

  • commentaires, documentation du code ;
  • tests unitaires, fonctionnels ;
  • messages de commit...

Échec

  • Le code source n'est pas versionné.
  • Le code source est versionné avec CVS.
  • Le serveur hébergeant le dépôt principal tombe en panne, pas de backup.
  • Ne pas pouvoir faire de commits hors ligne (par exemple au cours d'un trajet en train), faute de connexion au dépôt principal (subversion).

Succès

  • Le code source est versionné
  • Avantage aux systèmes décentralisés (git, mercurial, ...)
  • Un backup sur l'intranet si le dépôt principal est sur internet, et vice-versa.

Outils

  • git, mercurial
  • plateformes d'hébergement git ou mercurial, comme gitorious, github, bitbucket...

Documentation "projet"

La documentation spécifique au projet. Voir l'article à propos de la documentation projet [1].

Échec

  • Documentation rédigée avec un logiciel de traitement de texte.
  • Documentation dans un wiki, désynchronisée des releases du code. Par exemple le wiki sur Github ou Bitbucket sans tagger les versions du wiki en fonction des versions du code source.
  • Des mots de passe inscrits dans la documentation.

Succès

  • Documentation versionnée avec le code source. Pour un état du code, on a une documentation valide qui correspond (bijection).
  • Ou au moins la documentation fait l'objet de releases synchronisées avec les releases du code source.
  • Documentation au format texte (RST, markdown...) et exportée (HTML, PDF...) pour une consultation aisée par ceux qui n'ont pas accès au code source.

Documentation d'hébergement

La documentation spécifique à un déploiement ou à une infrastructure.

  • orientée sysadmin
  • hébergement (conf) + déploiement (procédures)
  • informations spécifiques à un environnement ou une infrastructure (IP, domaines...)

Échec

  • "C'est facile, tu installes une machine virtuelle CentOS et tu fais git pull." - "Quelle image de CentOS je prends ?" - "Ah tiens il faut créer des clés SSH pour accéder au dépôt privé sur Github."
  • "Je suis en train de déployer le projet sur mon poste. Je tatônne." - "Ah mince, moi aussi je galère."
  • "En PROD les sysadmins ont mis Nginx." - "Ah, nous en DEV on a Apache."
  • Se transmettre la procédure de déploiement sur la pré-production par e-mail (ou via n'importe quel autre moyen préconisé dans la méthode "rache"), faute de pouvoir l'intégrer dans la documentation du projet, car elle contient des informations sur l'environnement de pré-production que le client n'a pas à connaître.
  • Ne pas pouvoir publier le code car la documentation contient des informations (privées) sur l'infrastructure.
  • Ne pas pouvoir maintenir (support) l'installation sur certaines plateformes.

Succès

  • La procédure d'installation est complète et éprouvée.
  • Les administrateurs système et les développeurs collaborent sur la documentation d'hébergement et les procédures de déploiement.
  • Si besoin, séparer documentation fonctionnelle et documentation d'hébergement.
    • La première pourra être publiée, la seconde ne sera disponible que pour un cercle restreint d'utilisateurs.
    • La première sera maintenue par l'éditeur. La seconde pourra être maintenue par la communauté.

Dépendances

Échec

  • Reporter un bug sur un projet quand celui-ci concerne un module partagé par plusieurs projets : les autres projets n'ont pas le rapport de bug alors qu'ils sont concernés.
  • Ou à l'inverse, reporter un même bug dans plusieurs modules...

Succès

  • Packager séparément les modules à partager entre plusieurs projets, i.e. les considérer comme des projets.
  • Reporter un bug pour le module, de sorte que le fix puisse concerner tous les projets qui utilisent ce module;

Tâches, bugs, stories

Échec

  • Demander une même feature plusieurs fois.
  • Reporter un bug de vive voix.
  • Écrire "il ne faudra pas oublier de faire ceci" dans un e-mail.
  • Rédiger une TODO-list dans un e-mail.
  • Laisser traîner des "TODO" dans le code source et la documentation.
  • Ne pas avoir d'idée sur la priorité des tâches.
  • L'utilisateur se plaint au développeur, lequel reporte l'information dans des tickets.

Succès

  • Disposer d'un outil de gestion de tickets (stories, tasks, bugs...) adapté à la méthode de travail de l'équipe.
  • L'utilisateur ouvre des tickets.
  • Si un "TODO" met en péril la qualité du produit, il ne passe pas la "definition of done".
  • Sinon le "TODO" peut-être jugé secondaire et fait l'objet d'un ticket. On pourra ainsi le retrouver facilement et le prioriser.

Tâches de structure, tâches "avant-projet"

Le travail sur un projet ne démarre pas avec le développement. Avant d'arriver à la production, il y a de nombreuses étapes à franchir. Par exemple :

  • commercial ;
  • démonstration, proof of concept. Ce qui peut impliquer de la R&D ou de la formation ;
  • administratif.

Échec

  • "Où est la proposition commerciale ?"
  • "On a livré le projet il y a 6 mois. Quelqu'un a envoyé la facture ?"
  • "De quoi a-t-on besoin pour démarrer ? Un dépôt, une mailing-list." - "Des tâches dans l'ERP aussi !" - "Un bugtracker aussi !" - "J'ai l'impression d'oublier quelque chose."

Succès

  • Les ressources commerciales et administratives sont parties intégrantes du projet (et non pas du produit).
  • Une proposition technique doit être réalisée en avant-vente. Un projet est créé dans le système d'information. Différentes ressources (dépôt, ERP, mailing-list, bugtracker...) sont créées automatiquement.
  • Le projet est livré. L'état du projet change dans le workflow. Une facture est générée et soumise à validation.

Outils

Les propositions suivantes ne sont peut-être pas pertinentes, car cette activité n'est pas mon coeur de métier.

  • Un gestionnaire de workflows, connecté à d'autres composants du système d'information.
  • Un gestionnaire de tickets simplifié, un gestionnaire de tâches lié à un agenda.

Barrière culturelle ?

On constate souvent que ces tâches ne sont référencées nulle part dans le système d'information.

Il serait pourtant pertinent de pouvoir suivre ces tâches. Un outil permettant de gérer des workflows semblerait adapté.

Il y a également une barrière culturelle à passer : s'il est assez commun pour un développeur d'organiser son activité autour de tâches ou de tickets, il me semble que c'est moins évident pour une activité commerciale ou administrative.

Spécifications

Échec

  • Pas de spécifications.
  • Spécifications dans un fichier PDF.
  • Spécifications rédigées en une fois, en amont de la production (forfait).
  • Spécifications éparpillées dans plusieurs documents : le PDF original + 3 discussions e-mail + 2 commentaires sur une User Story.

Succès

  • Spécifications rédigées de manière collaborative.
  • Spécifications rédigées de manière progressive, au fil de la production, selon les besoins réels et les priorités (agilité).
  • Spécifications dans la documentation.
  • Spécifications validées par des tests.
  • Spécifications référencées dans les stories (liées aux releases et tâches).

Note

Les spécifications dans la documentation et les tests, c'est une façon de les incorporer directement dans le produit. Le produit lui-même contient les spécifications. Peut-on faire plus concret ?

Outils

  • Behaviour driven development (BDD), Acceptance test driven development (ATDD), spécifications par l'exemple...
  • Voir les outils pour la documentation [3]

Processus de production, méthodes

Ce qui est indirectement lié au produit, et davantage lié aux processus de production, aux méthodes de travail.

Échec

  • "Ce serait bien si on faisait de la revue de code automatique pour les conventions de codage" - "Oh oui, bonne idée !". Deux jours plus tard, c'est oublié.
  • Un test échoue sur le produit livré.
  • "Comment je lance les tests ?".

Succès

  • L'équipe s'engage sur une "definition of done". Elle y inclut par exemple :
    • les tests passent ;
    • les conventions de codage ont été vérifiées.
  • Une charte d'équipe est rédigée.
  • Un document de vision est rédigé.
  • La documentation contient une partie "contribute" destinée à orienter les contributeurs.

Outils

  • Une équipe stable.
  • Session(s) de travail de quelques jours réunissant l'équipe au complet en un même lieu (IRL).
  • Formation de chacun des membres de l'équipe à une méthode de travail commune. Ou tout autre expérience permettant de partager une culture.
  • Les méthodes agiles.

Discussions

Échec

  • Discussion par e-mail interposés. Rédaction lente, compréhension fastidieuse, risque de quiproquo et de non-dits. Le prochain collaborateur n'aura pas l'historique.
  • Spécifications réparties dans une multitude de documents (e-mails, IRC, PDF...).

Succès

  • Les discussions nourrissent la production. Ce qui a une valeur pérenne au cours d'une discussion est reporté dans un canal mieux adapté. Par exemple :
    • une procédure est documentée (ou encore mieux, scriptée).
    • une changement dans l'expression du besoin est reporté dans les spécifications (i.e. dans la documentation et les tests).
  • Utilisation de canaux adaptés pour les discussions. Par exemple favoriser une conversation de vive voix pour un échange maximum.

Open-space

Discussions "ouvertes", informelles...

  • au moins 1 espace pour initier les discussions de tous types. Typiquement la machine à café. Mais en télétravail, on a aussi besoin de cet espace...
  • pas nécessairement liées à des tickets (au départ en tout cas) ;
  • l'e-mail est vraiment peu adapté ;
  • un wiki est complètement inadapté ;
  • n'a pas sa place dans la documentation.

Collaboration

Échec

  • Dans un e-mail : "Voici ci-joint la procédure à suivre pour voir ce que j'ai fait..."
  • "Allô ? Tu prends le fichier toto.txt..." - "Quel fichier toto.txt ?"

Succès

  • Montrer ce qu'on a fait directement aux personnes concernées. Faire une démonstration ;
  • IRL de préférence ;
  • Avec des outils de collaboration synchrone sinon.

Outils de collaboration synchrone

  • rencontres IRL
  • outils de discussion texte, audio et vidéo
  • partage d'écran
  • sessions screen
  • partage de documents (TitanPad, etherPad, GoogleDocs...)

Outils de collaboration asynchrone

  • tout ce qui est versionné (code, documentation...)
  • paste (friendpaste, pastebin...)

Organisation

Échec

  • Dans un e-mail : "PS : je rappelle que je serai absent tout le mois de juin." => Ceux qui n'ont pas reçu le message n'ont aucune chance de s'en souvenir. Et comme on est en février, personne ne le retiendra.
  • Après une réunion : "Bon, qu'est-ce qu'on a décidé déjà ?"
  • Dans un e-mail : "Préférez-vous le thé ou le café ?"

Succès

  • Le planning est tenu dans un agenda ;
  • Les tâches et décisions sont canalisées directement pendant les réunions
  • On utilise un service de sondage pour faire un sondage

Outils

  • Des services web : agenda Google, Doodle, minutes.io...

Bookmarks

Échec

  • Par e-mail : "J'ai trouvé ces deux articles très intéressants : ... (2 liens)"
  • Par IRC : "L'URL de la PREPROD, c'est http://example.com"

Succès

  • Utiliser un service web de gestion de bookmarks.
  • Connecter ou référencer ce service dans d'autres canaux de communication, par exemple dans la documention.

Outils

  • Les services web de bookmarks.

Annuaire

Échec

  • "Tu as le numéro de téléphone de M. Dupont ?" - "Oui"

Succès

  • Le numéro de téléphone de M. Dupont est enregistré (et à jour) dans l'annuaire

Outils

  • Services d'annuaire ou de gestion de contacts.
  • LDAP, CRM.

Réflexions

Communication et agilité

On ne peut parler d'agilité sans parler de communication. Christophe Thibault l'avait d'ailleurs fort bien rappelé lors de sa conférence "Une équipe remarquable au quotidien" lors de l'agile tour 2011 à Bordeaux [4] : la bande passante entre les membres de l'équipe est un élément clé.

Ici, le postulat est le suivant : une large bande passante est inutile si les communications ne sont pas un minimum canalisées.

On pourra d'ailleurs faire un rapprochement avec les core protocols que Christophe Thibault présentait : commencer par s'accorder sur les moyens de communication pour améliorer la valeur de ces communications.

Coût de l'outillage

Dans cet article, je parle d'outils, de protocoles, de canaux de communication. Or, il n'est pas facile du tout de mettre tout cela en place dans le cadre d'un projet. Et ce n'est pas sans dangers. Il faut du temps pour former une équipe. Il faut du temps pour déployer les outils de communication.

Autrement dit, il faudra maintenir un équilibre entre l'infrastructure et la production.

Pour ce qui est de l'infrastructure, la plupart des projets ne permettent pas d'en supporter une lourde part. Il est alors de bon ton de prendre un peu de recul, de favoriser la transmission entre différents projets et différentes équipes, de répartir la charge d'infrastructure, de construire celle-ci progressivement...

Outillage et liberté

S'il est nécessaire d'avoir des protocoles et des supports de communication. Il ne faut pas pour autant dégainer une artillerie lourde et contraignante :

  • se concentrer sur les outils au lieu de se concentrer sur le métier... ce n'est pas productif.
  • consacrer le principal de l'activité à suivre des procédures... ce n'est pas intéressant.

Outillage et pragmatisme

Certains simplifient la question de l'outillage en poussant le pragmatisme à l'extrême. Par exemple :

Il n'est pas besoin d'avoir des tâches ni de tout noter. Ce qui est important est fait. Point. Et une fois que c'est fait, ce n'est plus à faire.

Évidemment cette vision pragmatique est alléchante. Elle donne l'impression d'être très claire. Selon moi, c'est tout l'inverse :

  • la notion d'importance y est complètement intuitive. Pour établir une comparaison avec d'autres éléments, il faudrait avoir une liste d'éléments.
  • on ne peut pas suivre la progression des différents sujets. On a souvent l'illusion du contraire en interne dans une équipe. Tandis que d'un point de vue externe, il n'y a pas de demi-mesure : le projet est une boîte noire.
  • l'expression des souhaits et des problèmes a au contraire une grande valeur :
    • on peut trier les besoins, les prioriser ;
    • on peut éviter les oublis ;
    • on peut éviter les doublons ;
    • on peut suivre la progression ;
    • on peut bénéficier de l'aide spontanée d'une personne qui prend connaissance de nos besoins (principe de l'open source).

À mon avis, cette technique "ce qui est important est fait" est viable lorsqu'on est en présence d'un projet géré par un chef de projet, c'est à dire un projet dirigé par une personne unique. Ce n'est à mon avis pas viable pour un projet porté par une équipe agile.

Agissez !

Si vous rencontrez souvent ces patterns, je vous suggère d'agir ! Communiquez ! Montrez que l'on peut faire autrement ! Ne vous laissez pas faire !

Références

[1] http://www.makina-corpus.org/blog/documenter-un-projet
[2] http://sphinx.pocoo.org/
[3] (1, 2) http://www.makina-corpus.org/blog/documenter-un-projet#outils-treve-de-blabla
[4] http://www.makina-corpus.org/blog/travailler-en-%C3%A9quipe-des-efforts-au-quotidien

 

Votre notation : Aucun Moyenne : 5 (2 votes)
Étiquettes:

Update : les wiki peuvent servir pour la documentation...

Suite à une judicieuse remarque d'Alexis, j'ai modéré mes propos quant à l'usage de wikis pour héberger la documentation du projet :

  • ce qui est important, c'est de pouvoir retrouver, pour un état donné du code, la documentation correspondante (supposée valide). Et réciproquement.
  • Il est donc possible, en utilisant des tags ou branches sur les wikis (Github et Bitbucket le proposent), de conserver les correspondances entre les versions du code et les versions de la documentation.
  • Un intérêt de la documentation séparée du code source serait de pouvoir définir des permissions différentes entre ces deux éléments.
  • Si vous faites ce choix, pensez aux releases de la documentation : inscrivez-le dans la procédure de release. Ou mieux, scriptez-le.