Il est très fréquent que les équipes de développement soient très souvent interrompues dans leur travail : un chef de projet qui a une idée d’ajout dans le logiciel, une personne de l’équipe commerciale qui a une question, un client qui passe un coup de téléphone direct à un développeur qu’il connait…

Comment faire pour non seulement permettre ces interruptions nécessaires tout en en limitant l’impact sur les équipes de développement ?

C’est la question à laquelle je vais tenter de répondre ici. Ainsi, nous allons tout d’abord voir ce que coûtent réellement ces interruptions dans le quotidien des équipes, puis je vous ferai la proposition d’un cadre (ou d’un framework) pour vous permettre de répondre à ce problème : le DRIS.

C"est parti !

L’immense coût caché des interruptions

Toutes ces interruptions sont coûteuses pour l’équipe de développement et au final sont un coût pour l’entreprise. Il y a 3 coûts principaux liés à ces interruptions :

Le Changement de Contexte

C’est très pratique d’aller ainsi chercher l’information à sa source la mieux renseignée, mais toutes ces interruptions ont un coût : à chaque fois, la personne interrompue perd son contexte de travail, prend du temps pour répondre à la question (ou pire encore, renvoie le demandeur “dans les roses”) et doit se replonger dans son travail. C’est ce qu’on appelle le Changement de Contexte (ou Context Switching en anglais) et certains estiment que la perte de productivité occasionnée peut monter jusqu’à 80% !

La raison principale de cette immense perte de productivité est liée à la rupture du Flow. On ne va pas entrer dans les détails sur ce vaste sujet ici, il est largement documenté par ailleurs, mais pour résumer rapidement, le Flow est un état d’immense concentration et de productivité qui donne à celui qui est dedans un grand sentiment de satisfaction et d’hyper-productivité ; on parle à ce moment “d’être dans la Zone”. Je vous invite en particulier à lire cet article sur Mihaly Csikszentmihalyi qui fut le premier à théoriser cet état de Flow :

Une fois interrompu, retrouver le Flow est long (et douloureux) et il faut selon certains jusqu’à 15 minutes pour se retrouver dans un état similaire (et c’est parfois impossible, quelque chose s’est définitivement brisé). Pour bien comprendre ce dont il s’agit, faisons une petite analogie (avec les limites que cela comporte) : entrer dans un Flow, c’est comme s’endormir, cela prend du temps. Si vous êtes interrompu/réveillé pendant cette phase d’endormissement, même à quelques secondes du sommeil profond, il vous faudra tout recommencer depuis le début. Tout ce temps est définitivement perdu, et c’est pareil pour rentrer dans le Flow à nouveau.

Je trouve que ceci est remarquablement illustré par le très juste strip This Is Why You Shouldn’t Interrupt a Programmer (source).

Le manque de partage de connaissances

J’ai également souvent observé que la personne interrompue est toujours la même, “celui qui sait le mieux”. C’est non seulement très embêtant pour lui parce qu’il est sans cesse interrompu et qu’il ne peut pas avancer sur son travail, mais cela l’enferme également dans cette position pour longtemps. Ainsi, il restera le seul à savoir, aucun autre membre de l’équipe ne pourra faire partie des “sachants” et on continuera à venir l’interrompre, encore et encore.

Il s’agit donc de trouver un moyen de briser ce cercle vicieux.

Avoir une équipe dont les connaissances s’améliorent sans cesse, dont l’expertise individuelle et collective grandit, c’est la garantie d’un risque moindre pour l’entreprise (au départ ou aux vacances d’un collaborateur, l’entreprise ne peut pas arrêter de fonctionner), c’est une opportunité donnée à chacun d’apprendre et de devenir meilleur. C’est pour moi une des clefs du bonheur de chacun à venir travailler dans un environnement stimulant dans lequel tout le monde apprend chaque jour. En cas de gros problème (un bug très impactant en production, une fonctionnalité importante à ajouter), plus nous sommes nombreux à avoir de la connaissance, plus nous serons capables de réagir vite avec des idées claires et originales et d’aboutir à une bonne solution ; ce partage de connaissances est aussi un des carburants de l’intelligence collective. (Nous parlerons de ce sujet en détails dans d’autres articles, sinon nous allons nous égarer ici, mais il est de la première importance chez Deepki.)

La démotivation

Le corolaire des interruptions permanentes et du non partage des connaissances, c’est la perte de motivation.

Comment me réaliser si je ne progresse pas ? Comment avancer dans mon travail si je ne peux pas me concentrer ? Serais-je un jour en position d’aider quiconque dans mon entreprise ? Toutes ces questions (la liste n’est pas exhaustive) sont le signe qu’un ingrédient très important vous manque : les journées deviennent longues, la vie semble perdre son sens, vous allez voir ailleurs après 3 ans de travail dans votre entreprise. La perte est immense pour l’entreprise, et les effets négatifs à titre individuel (sentiment d’échec, syndrome de l’imposteur, voire dépression) sont encore plus grands.

Chez Deepki nous voulons construire un environnement de travail où chacun peut se réaliser, venir avec bonheur tous les matins au travail pour réussir la mission que nous nous sommes donnée : favoriser la transition énergétique. C’est pourquoi il est indispensable pour nous de tout mettre en œuvre pour obtenir ce que nous recherchons. C’est en partie pour cela que nous avons mis en place le DRIS.

Le DRIS (Développeur qui Réagit aux Interruptions de la Semaine)

Voici un extrait (largement édité) de notre wiki interne qui décrit non seulement les rôles et responsabilités du DRIS, mais aussi comment interagir avec lui : ce n’est pas une recette miracle, cela demande de la discipline de toute part (rediriger vers les DRIS lorsqu’on ne l’est pas, bien se préparer avant de venir voir le DRIS…).

L’idée principale est d’avoir un point d’entrée unique par équipe pour toutes les interruptions externes. Ce n’est pas une idée totalement neuve, cela fait maintenant 10 ans que je l’utilise sous diverses formes dans toutes les entreprises par lesquelles je suis passé et qui survivent à mon départ. Mes anciens collègues qui ont eux aussi changé d’entreprise ont transposé cette idée partout où ils sont passés.

Comme son nom l’indique, le DRIS :

• est un Développeur
• c’est lui qui Réagit
• à toutes les Interruptions
• le rôle est tournant et change chaque Semaine

Rôle(s) du DRIS

Le DRIS répond aux interruptions pendant sa semaine de responsabilité. Le but est de n’avoir qu’un seul point d’entrée dans l’équipe pour minimiser les interruptions.

Ses rôles et responsabilités sont les suivants :

• gérer les urgences de production (sécurité, bugs de production, disponibilité et maintien de l’environnement de production, etc.)
• être proactif sur la production
• s’occuper des mises en production
• répondre aux interruptions (questions), préserver le flow de son équipe
• transmettre sa façon de faire

Le DRIS met tout en oeuvre pour accomplir sa mission dans le but de préserver l’équipe. Cependant, avec ce rôle, il a également le pouvoir d’interrompre toute ou une partie de l’équipe en cas de problème insoluble ou d’urgence de production. C’est un pouvoir qu’il doit utiliser avec mesure et discernement (puisque vous le savez, un grand pouvoir implique une grande responsabilité).

Répondre aux interruptions

Son premier rôle est de répondre aux questions qu’on lui pose si il en est capable. Après recherche avec son interlocuteur, si il n’est pas capable de venir en aide seul à son interlocuteur et qu’il connait une personne qui saura répondre ou qui saura l’aider à chercher, il peut interrompre cette personne, intelligemment (en attendant qu’il soit prêt - attention à ne pas briser un flow).

Transmettre ses connaissances

Un autre rôle est d’éduquer ses interlocuteurs sur comment chercher par eux-mêmes de l’information ou comment résoudre un problème.

Il poussera son interlocuteur à mettre à jour le wiki (capitaliser est l’affaire de tous).

Accueillir et guider les nouveaux arrivants

Un des rôles du DRIS est l’accueil des nouveaux arrivants. L’idée est de binômer avec cette personne dans ses premiers pas dans l’entreprise, sa découverte de notre écosystème de travail et dans nos procédures.

Être proactif

Enfin et surtout, le DRIS a un rôle proactif avec la production. En particulier :

• qualifie les bugs : à l’écoute des logs de tous les environnements, avec un regard particulier sur la production qualifie les bugs et crée systématiquement une carte dans l’outil de suivi des bugs (Trello, Gitlab/Github, Jira) avec le plus de contexte possible (date, environnement, version, stack trace complète). Dans l’idéal le DRIS qualifie le bug, tente de le reproduire et le corrige dans la foulée si c’est un petit bug qui ne nécessite pas de gros changements dans le code ou si cela ne constitue pas une urgence absolue de la production. La correction rapide des bugs reste une grande priorité de toute équipe qui délivre du code à des clients
• clarifier les logs : à l’écoute des logs, il n’hésite pas à clarifier les logs de tout type (et pas seulement d’erreur) en soignant leur libellé et les informations logguées : des logs efficaces donnent du contexte et permettent d’agir en cas de problème. Clarifier un log peut être aussi simplement de changer son niveau. A noter qu’il est souvent judicieux de considérer les logs dans leur ensemble, de voir si ils nous racontent une histoire de ce qui se passe en production
• développer des outils de diagnostic pour aider à comprendre ce qui se passe en production, retrouver le contexte d’un client, retarder son parcours sur nos applications. Ces outils bénéficient à tous les DRIS suivants pour la réalisation de leur travail, être plus réactifs en cas de soucis observé en production
• réaliser les mises en production : le DRIS doit porter son attention au bon respect des procédures, en particulier le respect de la validation sur chaque environnement avant le passage vers l’environnement supérieur. Ainsi, avant de mettre en production, le code doit avoir été déployé et testé dans les environnements de recette. Ce processus est une garantie de stabilité de la production et de la qualité du service rendu à nos clients.

Démarche avant d’interrompre le DRIS

Jusqu’ici nous avons décrit quels étaient les rôles et les responsabilité du DRIS. Une partie de son rôle est de répondre aux interruptions de l’équipe. Mais avant de venir interrompre le DRIS, il est de la responsabilité de celui qui interrompt le DRIS de suivre ces quelques conseils afin d’être collectivement plus efficaces :

• noter les questions pour les regrouper et minimiser l’impact d’une interruption (on peut se faire une “liste de courses”)
• chercher, c’est apprendre
  • chercher dans le wiki et la documentation
  • chercher sur google/stackoverflow
• interroger le DRIS et chercher avec lui (ne pas rester spectateur)
• noter sa façon de travailler, sa démarche, son approche et s’en inspirer plus tard dans son travail quotidien
• mettre à jour le wiki avec ce que vous avez appris

Une bonne mesure avant d’interrompre le DRIS, c’est de chercher par soi-même, au maximum 1h, ce qui laisse le temps de réfléchir, chercher, apprendre par soi-même. Réaliser une interruption avant ce délai ne vous permettra pas de bien progresser. A contrario, rester bloqué au delà de ce délai est une perte de temps pour l’entreprise.

Liste des DRISsables

À chaque semaine, au point hebdomadaire de l’équipe, on change de DRIS en prenant le suivant dans la liste triée par ordre alphabétique des noms de famille. Cela évite toute discussion inutile. Être DRIS est une immense chance pour apprendre, progresser sur de nombreuses compétences larges (en particulier la production) et devenir à terme un meilleur développeur.

Est-ce que je dois mettre en place un DRIS dans mon organisation ?

J’aurais envie de vous dire oui 😁, mais c’est à vous de prendre cette décision. Regardons ensemble les avantages et inconvénients que vous obtiendrez à cette mise en place.

Les avantages

En plus d’attaquer au coeur le soucis des interruptions de vos équipes de développeurs, mettre en place un DRIS vous apportera également les avantages suivants :

• un interlocuteur identifié pour toute question interne
• une personne qui réagit au moindre soucis de production, c’est un pas supplémentaire vers un production stable et efficace, des clients satisfaits
• une équipe de développeurs plus sereins qui peuvent se consacrer à leurs taches plus long terme
• des logs plus clairs, plus explicites qui vont nous permettre de réagir encore plus efficacement au prochain problème de production
• une grande diffusion de la connaissance dans l’équipe de développeurs et au-delà
• plus de connivence entre les développeurs et les autres interlocuteurs de l’entreprise : cela brise l’image d’Épinal du développeur incapable de communiquer qui reste dans son coin et qui jargonne, cela donne une meilleure compréhension de ce métier souvent perçu comme un peu mystérieux
• des développeurs qui ont conscience de l’importance de la production, qui perçoivent encore mieux à quoi sert tout ce code produit en équipe
• des développeurs qui ont progressé sur de nombreux sujets (devops, log explicite, communication, gestion de la pression) qui sera bénéfique tout le long de leur carrière

Les inconvénients

Cependant, rien n’est tout rose, cette mise en place peut aussi poser quelques défis à relever. Je vous donne ici quelques pistes pour les contourner :

• personne ne veut être DRIS, le rôle est perçu comme ingrat : cela arrive souvent au début, certains développeurs ne voient pas la valeur de voir leur logiciel fonctionner en production, quelle source d’amélioration cela représente. Ils ne voient pas non plus qu’ils apprendront énormément sur d’autres sujets dont ils ne soupçonnent même pas l’existence. C’est à vous de leur transmettre cette importance (par des ateliers dédiés, en binômant avec le DRIS…)
• personne ne respecte le principe du DRIS, tout le monde continue à interrompre l’équipe : là il faut être ferme, vivre avec l’équipe et reprendre chacun à chaque interaction. “Non le DRIS cette semaine c’est XXX, tu dois laisser YYY tranquille. Merci”. A noter que c’est aussi aux non-DRIS de signaler “Non ce n’est pas moi le DRIS cette semaine, tu devrais plutôt demander à XXX”
• il y a parfois la queue autour du DRIS. Soit cela permet de se dire “ah mon problème n’est pas aussi grave, je vais voir comment le résoudre par ailleurs”, soit tous ces problèmes sont aussi importants et nécessitent l’attention du DRIS : dans ce cas, le DRIS peut interrompre une partie de son équipe pour le seconder (rappelez-vous, un grand pouvoir…).
• corolaire/cause du point précédent : personne ne comprend l’intérêt du DRIS : il est important d’expliquer à tout le monde pourquoi on met en place un DRIS, ce qu’on cherche à éviter (les interruptions), ce qu’on cherche à obtenir. Vous ne pouvez pas mettre cela en place unilatéralement sans donner tout le contexte. N’hésitez pas à expliquer la notion de Flow qui reste encore méconnue, pointez vos interlocuteurs vers cet article.

Et chez Deepki ?

Au cours de la rédaction de cet article, nous avons eu de nombreuses discussions entre nous sur les difficultés liées à la mise en place des DRIS chez Deepki (nous avons un DRIS par équipe de développement). Nous évoquerons ces sujets dans un article à paraitre prochainement, sinon celui-ci n’en finirait pas.

Conclusion

Voilà, j’espère que cet article vous aidera dans votre quotidien de production et qu’il vous aura donné des idées. À titre personnel, cela fait presque 10 ans que je mets en place cette pratique (je commence souvent par cela tellement les bénéfices sont grands). Quand je suis arrivé chez Deepki, il y avait 2 personnes qui étaient tout le temps interrompues. J’avais commencé à compter sur mon cahier, et chacun l’était entre 20 et 30 fois dans la journée ; autant vous dire que le DRIS a été un grand soulagement pour eux !

En tout cas, chaque entreprise a son contexte particulier, son besoin d’adapter ce rôle à ses particularités, mais l’idée principale (qui n’est pas de moi) est suffisamment simple pour fonctionner partout.

Et vous ? Utilisez-vous un système similaire ? Comment s’appelle-t-il ? En quoi est-il différent ? Je serais curieux d’en apprendre plus sur d’autres façons de procéder.

Liste des références évoquées dans l’article :

• What Is Context Switching and How Does It Demotivate Programmers?
• Context switching can kill up to 80% of your productive time (here’s what to do about it)
• This Is Why You Shouldn’t Interrupt a Programmer
• 8 Ways To Create Flow According to Mihaly Csikszentmihalyi
• Developer Flow State and Its Impact on Productivity
• Flow: The Art of Getting in the Zone (and Staying There)