- Erreurs couramment commises lors de la mesure de la productivité des développeurs
- Problèmes liés à la mesure des intrants
- S’appuyer sur des intrants ou des efforts, comme les « heures de travail », encourage des comportements inadaptés
- Par exemple, si la culture d’entreprise valorise et récompense le temps passé devant l’écran, les développeurs peuvent y consacrer beaucoup de temps sans que la qualité du travail soit garantie
- Dans des environnements plus toxiques, cela peut dégénérer en compétition pour « arriver le plus tôt et partir le plus tard »
- Problèmes liés à la mesure des résultats
- Les pires indicateurs, comme le nombre de lignes de code ou de commits, appartiennent à cette catégorie
- Les développeurs peuvent écrire très rapidement de grandes quantités de lignes de code, ce qui rend cette mesure facile
- Tous les indicateurs de résultat doivent être compris dans leur contexte
- Problèmes liés à la mesure des résultats et de l’impact
- Le défi de ces deux types d’indicateurs est de déterminer dans quelle mesure l’équipe DevOps en est réellement responsable
- Lorsqu’on mesure l’augmentation des revenus de l’entreprise, il est impossible de l’attribuer uniquement à la responsabilité des développeurs
12 commentaires
C’est vertigineux. J’imagine qu’il y a un écart entre le point de vue du manager et celui des personnes sur le terrain,,
On dirait vraiment le genre d’endroit où un LLM est nécessaire.
Comme il s’agit d’un texte qui ne propose pas d’alternative, le message qu’il cherche à transmettre perd en partie de sa force. Je suis d’accord avec l’idée qu’il faut exclure la quantité de livrables de la mesure des résultats, mais je ne peux pas adhérer au fait d’exclure totalement le temps de travail de la mesure des intrants, car cela ne correspond pas à la réalité. Quoi qu’il en soit, le temps s’écoule pendant le travail intellectuel, donc je pense qu’il faut impérativement en tenir compte dans la prise de décision
Je pense qu’il est plus simple à comprendre et plus efficace de discuter de la productivité des développeurs après avoir mesuré des indicateurs avancés comme : progression globale = (nombre d’exigences satisfaites / temps de travail)
Récemment, j’ai tendance à porter un regard assez critique sur ce type d’articles, car je pense qu’au final la conclusion que les gens en tirent en les lisant, c’est de choisir de ne mettre en place aucune gestion. Quel que soit l’indicateur utilisé pour piloter, on rencontre au fond des problèmes similaires. De plus, dès qu’un indicateur est utilisé pour mettre les personnes ou les équipes en concurrence ou pour les comparer, des effets pervers apparaissent. C’est pourquoi il ne faut pas piloter avec un seul indicateur, mais gérer ensemble des indicateurs complémentaires. À mon avis, les indicateurs doivent servir à aider l’équipe à s’améliorer par elle-même.
Que pensez-vous du fait de mesurer cela par le nombre de PR soumises dans des unités de travail ayant du sens ?
En réalité, il existe même, dans une grande entreprise coréenne, des endroits où la performance est mesurée au nombre de lignes de code écrites, bouhou bouhou.
Haha, moi aussi je l’ai déjà vu.
Il postait des commits où il changeait sans arrêt les noms de variables… haha
On dirait que c’est un environnement où les code reviews ne se font pas, non ?
Haha, les relecteurs de code aussi doivent faire relire leur code, vous savez.
Ils s'entraident mutuellement, en fait..
MDRRRR, oh là là...
bonjour monde de l’enfer ;)
C’est donc bien cette fameuse mesure de la productivité au nombre de lignes de code, hein... 😨