Pourquoi réduire la charge mentale des développeurs à travers la Developer Experience ?

J’ai récemment abordé la diversité des tâches que doivent traiter les développeurs au travers d’un article nommé Être développeur, c’est bien plus que développer. Il est important d’avoir conscience de cette diversité de tâches, car elle est génératrice de temps perdu. Et perdre du temps, c’est quelque chose que l’on veut éviter à tout prix.

Ce que l’on aimerai, c’est que les développeurs se concentrent sur le développement de fonctionnalités. C’est cette tâche qui est directement génératrice de valeur pour l’entreprise.

En plus d’être chronophages, nombreuses de ces tâches sont désagréables pour les développeurs. Ils ne prennent aucun plaisir à les réaliser !

La question la plus importante à laquelle nous allons essayer de répondre est donc : pourquoi les développeurs perdent-ils du temps avec la multiplicité des tâches ? Comprendre cela est crucial. Le temps, c’est de l’argent. Et une entreprise doit être rentable.

Cela peut paraitre fou mais 100 tâches d’une heure prendront plus de temps à réaliser qu’une seule tâche de cent heures. La multiplicité des tâches induit un effet secondaire. Plus il y a de tâches à réaliser, plus il y a de temps passé à changer de tâche.

C’est ce que l’on appelle le context switching.

Pour chaque tâche que l’on arrête, il y a un temps de mise en pause qui est fixe. Pour chaque tâche que l’on démarre, il y a un temps de préparation qui est fixe.

C’est comme lorsque devez choisir une file d’attente à la caisse du supermarché. Le plus important n’est pas tant la quantité d’articles en attente à scanner. Le plus important, c’est surtout le nombre de clients qui attendent. Pourquoi ? Car l’hôtesse de caisse doit réaliser, pour chaque client, un nombre identique de tâches dont la durée est toujours la même : dire bonjour, annoncer le montant à payer, demander le mode de règlement, attendre le règlement, [rendre la monnaie], donner le ticket de caisse, dire au-revoir…

Pour un développeur, c’est la même chose : lire les spécifications demandées, créer une nouvelle branche git, remettre à 0 son jeu de données de tests, sauvegarder son travail git, mettre en ligne sa fonctionnalité…

Ces temps fixes peuvent être de l’ordre de plusieurs minutes à chaque fois. Et plus un développeur change de tâches, plus ces temps vont s’additionner. À la fin de la journée cela peut représenter plusieurs dizaines de minutes.

Sur l’ensemble de votre équipe, cela représente des heures de perdues chaque jour.

Mais il y a encore plus chronophage. Lorsqu’il change de tâche, le développeur (comme tout le monde) perds soudainement son état de concentration. Ce qui peut sembler anodin ne l’est pas. Cette étude prouve qu’il faut 20 minutes après un changement de tâche, pour retrouver sa pleine concentration. 20 minutes durant lesquelles l’efficacité n’est plus à son apogée.

Développer est un métier de concentration. Les développeurs cherchent à atteindre l’état de flow. Un état où le temps ralenti et seule la tâche à accomplir existe. Pourtant, chacune des tâches annexes, chacune des interruptions vont interrompre cet état.

L’ensemble de ces tâches que l‘on attends des développeurs ont donc un coût. Elles les forcent à se rappeler de tout ce qu’ils doivent faire. Puis, de changer régulièrement d’activité. Perdant de fait, temps et concentration. C’est ce que j’appelle, leur charge mentale.

En tant que managers, nous avons une responsabilité. Celle de tout faire pour réduire cette charge mentale. Nous devons réduire le nombre de choses auxquelles ils doivent penser chaque jour. Ils doivent se concentrer sur ce qui importe le plus : créer de la valeur business à travers le développement.

Attention, souhaiter que les développeurs se concentrent sur le développement ne signifie pas développer tout et n’importe quoi, à n’importe quel prix. L’idée est de leur faire gagner du temps et de l’énergie pour des fonctionnalités qui ont un impact positif sur le business.

C’est dans cette quête de réduction de la charge mentale, que réside à mes yeux le concept et l’intérêt de la Developer Experience. Et ce, à travers deux questions fondamentales :

1. Quelles sont les tâches sans valeur ajoutée, qui font perdre du temps aux développeurs ?
2. Comment pouvons-nous faire pour qu’ils perdent moins de temps sur ces tâches ?

David Heinemeier Hansson, le fondateur de Basecamp, a écrit The Musk Algorithm, un article qui tente de décrypter la méthode Elon Musk. Loin de me positionner sur ces deux personnages controversés, la méthode proposée me semble hyper-pertinente.

Celle-ci repose sur le fait de supprimer tout ce qui est inutile au quotidien. Puis, de simplifier ce qu’il reste et qui est donc utile. N’hésitez pas à challenger régulièrement l’ensemble de votre organisation, vos processus ou vos rituels. Le moindre ajout, la moindre suppression, peut remettre tout le reste en question. L’objectif est de toujours avoir le minimum nécessaire pour répondre à vos enjeux du moment.

C’est l’erreur que l’on voit le plus lorsqu’une entreprise veut devenir “agile” du jour au lendemain. Elle prends l’ensemble des rituels recommandés par un framework et les impose tous immédiatement. Hors, chaque rituel répond à une problématique précise. Si vous n’avez pas la problématique, épargnez-vous le rituel ! Ce dernier ne fera qu’alourdir votre quotidien.

De même, il faut être pragmatique. Nous avons vu que chaque processus, chaque rituel, a un coût (temps, charge mentale…). Si le gain obtenu grâce au processus est supérieur au coût du problème initial, alors ce processus mérite d’être conservé. Mais si le gain n’est pas là, inutile d’en payer le coût.

Dernièrement, Google a mené une étude qui s’appelle Build Latency, Predictability, and Developer Productivity. Celle-ci démontre que le temps anticipé pour la réalisation d’une tâche automatique, influence les développeurs dans le choix de ce qu’ils vont faire en attendant que cette tâche se termine.

Prenons l’exemple d’un développeur qui doit attendre que des tests automatisés se terminent pour mettre en ligne sa fonctionnalité. Il ne fera pas la même chose si ces tests s’exécutent en une ou vingt minutes. Si les tests mettent une minute à s’exécuter, il y a fort à parier que le développeur se contentera d’attendre. Si les tests mettent 20 minutes à s’exécuter, le développeur cherchera autre chose à faire en attendant.

Nous pourrions penser que c’est une bonne chose. Que chaque minute de son temps est utilisée à bon escient. Or, c’est justement en changeant de tâche que se produit le phénomène de context switching. C’est à ce moment-là que le développeur commence à perdre temps et concentration. Une fois plongé pleinement dans sa nouvelle tâche, il risque d’oublier qu’il attendait la fin de la première. Il le remarquera plus tard, mettant en ligne sa fonctionnalité avec du retard. Tout en ayant subi 2 changements de tâche.

C’est là ou la phase d’accélération du Musk Algorithm prends tout son sens. En accélérant chaque étape d’un processus, nous réduisons le temps total de son ensemble. Ce faisant, nous décourageons le context switching, ce qui est bénéfique pour l’efficacité de l’équipe.

Des fois, attendre est la meilleure des chose à faire.

Il est légitime de vouloir rendre certaines tâches obligatoires dans le quotidien de votre équipe. Que ce soit des tests à réaliser ou de la Code Review à faire, toutes ces tâches ont leur intérêt et leurs inconvénients. Si elles sont pertinentes pour vous, si vous en acceptez le coût pour bénéficier de leur gain, alors, une seule chose est importante. Supprimer la charge mentale associée à ces tâches.

Pour faire simple, vous devez les automatiser pour que plus personne n’ait à y penser. Puis, vous devez les accélérez pour que les développeurs attendent leur déroulement, sans changer de sujet.

Investir dans la Developer Experience, c’est investir dans l’efficacité de votre équipe technique. En plus de perdre moins de temps, vos développeurs travaillent dans de bonnes conditions. Investir dans le moral de vos collaborateurs, c’est réduire votre taux de turnover.