- Cet article explique comment une tentative de mesurer la productivité d’une équipe a échoué
- Il a été décidé d’introduire des indicateurs de performance individuels à des fins d’évaluation personnelle et de développement
- Le nombre de lignes de code ou de bugs a été écarté en raison de son fort potentiel de manipulation, et il a été décidé de mesurer la performance à la place avec les story points ou le nombre de stories livrées
La performance de Tim Mackinnon est de « 0 »
- La performance de tous les membres de l’équipe a été mesurée à l’aide d’outils de mesure de productivité d’équipe (Jira, etc.)
- Le score de performance de Tim était de 0 → parce qu’il n’avait enregistré aucun story point
- Le manager a demandé à remplacer Tim au motif que sa performance était nulle
Pourquoi Tim Mackinnon ne produisait pas de performance
- Tim ne prenait pas directement en charge les stories
- À la place, il se concentrait sur le pair programming avec les membres de l’équipe
- Il travaillait avec des développeurs moins expérimentés et les amenait à résoudre les problèmes
- Au lieu de résoudre lui-même, il les aidait à faire émerger des solutions par le questionnement
- Avec les développeurs seniors, il réfléchissait aux problèmes avec eux et améliorait les solutions
- Tim n’écrivait pas directement du code, mais améliorait la performance globale de l’équipe
La véritable contribution de Tim Mackinnon
- La contribution de Tim ne peut pas être mesurée par un score de performance individuel
- Grâce à Tim, la productivité globale de l’équipe et la qualité du code se sont améliorées
- Quand Tim travaillait avec eux, il était possible d’obtenir des résultats plus rapides et de meilleure qualité
Changement de méthode d’évaluation vers la productivité de l’équipe
- La contribution de Tim a été expliquée au manager, et une occasion d’observer lui a été donnée
- Après avoir constaté que la performance de l’équipe entière s’améliorait, la méthode de mesure de la performance individuelle a été abandonnée
- Le mode d’évaluation a été réorienté non plus vers la performance individuelle, mais vers la performance de l’équipe et l’impact business
Résumé (tl;dr)
- La productivité doit être mesurée à l’aune des résultats business (ex. réduction des coûts, génération de revenus, etc.)
- Dans des systèmes complexes, mesurer la performance individuelle n’a pas de sens
- Les DORA Metrics et autres sont des outils de mesure de la performance du système, pas des outils de mesure de la contribution individuelle
- Si vous avez l’occasion de travailler avec Tim Mackinnon, ne la laissez pas passer
5 commentaires
En réalité, une fois qu’on dépasse le niveau senior pour arriver vers celui de staff engineer, on s’éloigne de plus en plus du code réellement déployé en production... À la place, on finit par faire davantage de coaching auprès des seniors et des juniors. Il faut aussi écouter les doléances des managers... et quand un problème éclate, on est appelé de partout pour proposer une solution....
Quand le travail ressemble à ça, il est impossible de quantifier ça avec des tickets Jira et des points.
En tant que tech lead, je fais assez souvent ce genre de travail. C’est un peu similaire au fait d’essayer de quantifier sur la base des story points, mais heureusement l’entreprise n’est pas très grande, donc les membres de l’organisation, y compris les dirigeants, ont conscience du rôle que je joue, et pour l’instant il ne semble pas y avoir de problème.
Si l’organisation grandit, il faudra sans doute réfléchir aussi à une méthode de quantification.
J’avais l’impression d’avoir déjà vu cette histoire… mais c’est un article de 2023.
Le même article avait déjà été publié il y a 2 ans : https://fr.news.hada.io/topic?id=10680
On dirait quelqu’un comme GitHub Copilot....
Avis Hacker News
Mesurer la productivité d’un développeur individuel est absurde. Mesurer les lignes de code ou les story points va à l’encontre de la productivité. L’important est qu’un développeur crée plus de valeur avec moins de code.
Ils ont trouvé un moyen de résoudre le problème en mettant le nom de Tim sur le ticket. Les membres de l’équipe aideront volontiers.
Heureux que Tim soit resté dans l’équipe et ait aidé à orienter le processus dans la bonne direction. Il faut un manager à l’écoute.
Le modèle où un programmeur aide tout le monde sans avoir de travail individuel est étrange.
Le fait que Tim n’ait pas de travail individuel est étrange. Pour maximiser la productivité de l’équipe, il faut un équilibre entre contribution individuelle et collaboration d’équipe.
Si Tim ne contribue pas à l’équipe, je lui dirais de commencer le travail et de livrer des stories. C’est bien qu’il aide les autres, mais il doit aussi faire son propre travail.
Tout ne doit pas devenir une activité de groupe. Si un développeur moyen ne peut pas livrer une fonctionnalité sans l’aide constante de Tim, il y a un problème dans l’équipe.
Les meilleures équipes ont toujours quelqu’un comme Tim. L’aide de Tim se diffuse aux autres et fait progresser toute l’équipe.
Mesurer la productivité des développeurs avec les story points n’est pas une bonne idée. Un développeur nommé Zero n’avait pas de stories assignées et aidait l’équipe.
Il est difficile de quantifier la valeur du support. Mais le support est essentiel. Il faut faire confiance aux leaders pour juger correctement.