af83

Remote: office not required

La sortie du nouveau livre de 37signalsRemote: Office not required” est une bonne excuse pour se pencher sur la pratique du télétravail.

Cela fait un certain temps qu'af83 emploie des télétravailleurs, et on espère continuer sur cette lancée. Malgré des bureaux spacieux, agréables, et remplis de bisounours, certains décident de ne pas s'y attacher toute l'année, et ce de façon plus ou moins engagée :

  1. l'impromptu pour prendre rendez-vous avec votre électricien préféré qui a promis de passer entre 9h et 18h,
  2. le pratique qui travaille à distance quelques jours par semaine, ou quelques semaines par mois,
  3. et le complet qui travaille à distance toute l'année ou plusieurs mois par ans : cela inclut des développeurs en France comme à l'étranger (ce billet est écrit depuis le Mexique).

Évidemment, plus loin on habite de nos bureaux parisiens, plus on tend à se retrouver dans la catégorie "complet" pour des raisons pratiques.

Le livre de 37signals donne plusieurs exemples d'entreprises américaines fonctionnant ainsi, mais il me semble naïf de croire que les pays européens sont tous à la traîne. Si cette façon de travailler est séduisante pour tous et existe depuis plusieurs années, alors pourquoi ce regain d'intérêt seulement maintenant ? Simplement parce qu'on a depuis peu les technologies permettant de le faire efficacement.

Il serait naïf de vouloir condenser tout le bouquin dans un seul petit billet. Néanmoins, il est intéressant de rappeler quelques idées qui pourraient encourager d'autres à se lancer :

  • Vous gagnerez en productivité
  • Vous ferez plus attention à ce qui est produit, plutôt qu'à ce que raconte votre pointeuse.
  • Vous trouverez des compétences partout lorsqu'elles ne sont pas disponibles sur place.
  • Vous économiserez les transports jusqu'au bureau ; et potentiellement, vous n'aurez plus besoin de bureaux aussi grands.
  • Vous pourrez vivre loin de La Grande Ville si cela vous chante.
  • Vous utilisez probablement déjà des outils prévus pour le travail à distance et asynchrone (e-mail, Github, Dropbox, IM, etc.).

Auto-critique parfaitement objective

Plus qu'une révélation pour nous, le livre a été l'occasion de comparer nos pratiques avec certains conseils donnés par ces messieurs Jason Fried et David Heinemeier Hansson. Je propose ici une petite séance d'auto-critique, parfaitement objective évidemment.

facepalm

Partager toute l'information avec tout le monde

Difficile de dire que l'on s'en tire bien. Certes, tout notre code source est versionné sur des dépôts Git, et l'on partage tout au long de nos projets sur les supports préférés de nos clients (de Trac, à Trello, en passant par Basecamp).

Mais nous utilisons aussi beaucoup Dropbox pour partager d'horribles formats de documents non-libres. C'est là que le bât blesse car tous n'ont pas le même accès au service. On semble parfois privilégier l'attitude militaire need to know qui consiste à réserver l'accès au strict minimum au plus petit nombre possible.

C'est un frein au travail asynchrone que de devoir attendre l'accès aux ressources nécessaires au moment opportun. Sans parler du plaisir égoïste qu'ont certaines personnes à détenir ce genre de clefs…

Communiquer plus avec vos collègues à distance

Même le plus grand des introvertis a une vie de bureau, il rencontre ses collègues (sans le vouloir) autour de l'imprimante (en panne), ou face à la machine à café, etc.

Ce n'est plus le cas lorsque l'on travaille à distance. Papoter avec vos télé- collègues (par téléphone, ou Google Hangouts, ou …) est un bon moyen de désamorcer d'éventuels problèmes sans devoir attendre un entretien annuel souvent plus formel.

Certes nous sommes tous connectés sur IRC tout au long de la journée, et on dispose tous de numéros VOIP personnels, mais il nous manque encore le déclic qui fait qu'on passera 20 minutes à "socialiser".

Recouper les horaires

Nos horaires à Paris ont tendance osciller entre 9-10h le matin jusqu'à 18-19h l'après-midi. Par exemple, travaillant depuis le Mexique, je me suis longtemps contenté de ne recouper qu'une heure ou deux avec mes collègues français. C'était parfait pour limiter les interruptions, mais mauvais pour le travail d'équipe car travailler à distance ne veut pas dire travailler seul.

Finalement, en commençant plus tôt le matin, je travaille plus longtemps avec la France et finis plus tôt l'après-midi.


Faciliter la communication

On s'améliore toujours, mais aujourd'hui nous utilisons déjà :

  • des mailing-lists,
  • plusieurs canaux IRC plus ou moins sérieux,
  • des vidéoconférences via Skype, Google Hangout (…),
  • des salles de conférences accessibles via SIP (chacun disposant d'un numéro personnel),
  • un serveur VPN pour faciliter le pair-programming à distance,
  • des outils de gestion de projet facilitant le travail asynchrone : Github, Basecamp, Trello, etc.

Doucement sur les réunions

Toute personne invitée à une réunion est aussi invitée à se demander si elle y a sa place, et à en sortir si ce n'est pas le cas : en tout état de cause, inviter un développeur à une réunion est une chose difficile tant nous sommes résistants à la pratique. Le temps de chacun est précieux, et on évite de le gâcher.

Cinq personnes dans une réunion d'une heure, ce sont cinq heures de consommées. De façon hebdomadaire, à l'échelle d'une année, ces calculs amènent à des montants assez alarmants.

De même, nous ne faisons que très rarement de stand-up regroupant tout af83 : nous sommes trop nombreux pour pratiquer ce genre de rituel où chacun prendrait la parole, et n'y avons jamais trouvé de grande valeur.

À travail égal, salaire égal…

Les salariés en télétravail sont considérés comme les salariés au bureau. Il n'y a pas de discrimination et il n'y a pas lieu d'y en avoir : un employé génial reste génial où qu'il se trouve.

Enfin, plutôt que de penser qu'on pourrait payer moins cher un développeur de Picardie qu'un développeur d'Île de France. Il semble plutôt intelligent de payer un salaire parisien à un développeur de Picardie : non seulement il sentira qu'on lui accorde la même valeur qu'au reste de l'équipe, mais il sera beaucoup plus difficile de le débaucher.

Se rencontrer tous, plusieurs fois par an

Chez af83, on organise une fois par an ce que l'on appelait au départ une code week, avant de la renommer dernièrement af83 week (parce qu'on ne fait pas que coder).

Le principe est simple : on se retrouve tous en dehors des bureaux quelques jours parce que rien ne remplace le contact humain. C'est évidemment l'occasion de travailler sur nos projets, et de décompresser avec quelques bières.

Maîtriser l'écrit

Si vous avez lu jusqu'ici, c'est qu'on ne s'en sort pas trop mal. Plus sérieusement, le télétravail implique de savoir communiquer par écrit parce qu'une personne qui ne peut pas aligner trois phrases aura beaucoup de mal à se faire comprendre. Et quand la communication ne se fait pas correctement, comment peut on espérer avancer ?

On trouve beaucoup plus facilement de littérature en anglais sur l'art et la manière d'écrire ou la difficulté de communiquer, mais une grande partie des conseils sur la clarté du style sont valides pour le français également.


Pour conclure

Il est intéressant de comparer non pas une entreprise à une autre ici, mais plutôt d'essayer de se situer face aux pratiques du marché. Le modèle de 37signals est sans doute très adapté aux États-Unis, mais que peut on retirer de leur expérience sur notre territoire ?

Le télétravail est d'autant plus facile à mettre en place qu'une entreprise est jeune : tous les outils sont là. Les freins sont comme souvent culturels.

Certes tous les emplois ne s'y prêtent pas : il faudra bien quelqu'un pour répondre au téléphone sur le même fuseau horaire que vos clients, ou peut-être certains voudront-ils vous rencontrer en chair et en os tous les lundis à 8h30…

Il est important de ne pas faire semblant de tous avoir le même travail, et exiger de tous la même présence géographique est inutile. Prétendre que tous doivent être au même endroit pour produire quelque chose de génial est un peu idiot : l'exemple immédiat est celui du kernel Linux.

Mais c'est peut-être le sujet d'un autre article.

blog comments powered by Disqus