Les développeurs fantômes
Découvrez pourquoi 10% des ingénieurs de la Silicon Valley sont payés 300K$ pour "ne rien faire" et ce que cette réalité cache vraiment sur les processus d'entreprise.
Quand certains cherchent toujours, d'autres ont des postes pour ne rien faire.
Dernièrement je tombais sur cet article sur medium.
Un chercheur de la Stanford Business School nous parle de ces développeurs fantômes et d'après ses chiffres de performance provenant de 100 grandes sociétés concernant 50 000 développeurs.
D'après les chiffres, 10% d'entre eux produisent 2 code changes par mois.
Des métriques assez incroyables et peu flatteuses.
Mais je tiens à partager mon expérience avec vous. Je pense qu'il faut prendre ces métriques avec des pincettes.
Effectivement je pense qu'une grosse partie de ces développeurs ne sont pas productifs, et ça ne devrait pas être difficile à démontrer.
En revanche, je sais aussi ce que c'est de travailler dans les grandes boîtes avec des flows et process répartis dans tellement d'équipes, que le process lui-même crée tellement d'inertie que de passer une modif, demande la validation de X personnes avant même de rendre possible le merge.
Après, attention, on parle de merge, pas de commit ou de push continu. Car oui, si un développeur ne push rien, c'est certain, il ne fait pas grand-chose.
C'est aussi pourquoi, il faut faire les process les plus simples et éviter au maximum de s'engouffrer dans des organisations et process politiques qui risquent de ralentir fortement votre capacité à sortir du code.
Je m'explique...
Il vous est peut-être arrivé de travailler dans des boîtes où on vous parle d'ownership sur des sujets. Que pour toucher à telle partie il faut la validation de X, que pour modifier telle autre partie, il faut la confirmation de Y, etc etc...
Je dirai que dans cette situation, par design, votre entreprise n'est pas faite pour débiter des features et innover à grande vitesse. Je suis même persuadé que le fait de laisser au maximum les droits à chacun (tout en continuant à faire de la review) permet d'aller plus vite, et aussi de s'affranchir d'avoir un unique référent par sujet.
Il faut donc recruter mieux et laisser plus de marge de manœuvre pour que ça marche efficacement.
Et je pense sincèrement, que lorsqu'il s'agit de technique, pour évaluer l'apport d'un développeur, il suffit de poser la question à ses pairs. Ce que les développeurs pensent de leur collègue en dit souvent long sur leur apport dans le projet.
FAQ
Ces développeurs fantômes font-ils vraiment rien du tout ?
Pas nécessairement. Dans les grandes entreprises, des processus lourds peuvent empêcher un développeur de merger du code pendant des semaines, même s'il travaille. L'absence de commits visibles ne signifie pas forcément une absence d'activité, mais elle reste un signal difficile à ignorer.
Pourquoi ces situations existent-elles dans des entreprises pourtant bien structurées ?
Paradoxalement, c'est parfois la structure elle-même qui bloque. Quand chaque modification nécessite la validation de plusieurs personnes ou équipes, l'inertie organisationnelle peut paralyser un développeur compétent et motivé.
Comment une entreprise peut-elle éviter de créer ce genre de situation ?
En simplifiant ses processus au maximum et en évitant les organisations trop politiques où chaque sujet a un unique référent indispensable. Donner plus d'autonomie aux développeurs tout en maintenant la revue de code permet d'aller plus vite et de réduire les goulets d'étranglement.
Comment repérer concrètement un développeur qui ne contribue pas ?
Demander directement l'avis de ses pairs est souvent le moyen le plus fiable. Les collègues qui travaillent au quotidien avec quelqu'un ont généralement une vision claire et honnête de sa contribution réelle au projet.
Alexandre P.
Développeur passionné depuis plus de 20 ans, j'ai une appétence particulière pour les défis techniques et changer de technologie ne me fait pas froid aux yeux.
Poursuivre la lecture
