Productivité des développeurs – comment la mesurer

Les êtres humains sont par nature des avares cognitifs et nous avons tendance à résoudre des problèmes complexes de la manière la plus simple avec le moins d'effort. C'est ainsi que nous avons mesuré la « productivité des développeurs » en utilisant la méthode la plus simple disponible.

Quelle est la première chose qui vous vient à l’esprit lorsque vous entendez « productivité des développeurs » ?

Je parie que c'est négatif et il ne fait aucun doute que c'est presque un tabou dans les équipes de développement, car les dirigeants craignent souvent que parler de ce problème donne l'impression à l'équipe qu'elle est microgérée ou qu'elle manque de confiance. Deux raisons :

1. La façon dont les développeurs sont productifs est abusée par les leaders de l'ingénierie et comme nous l'appelons.

2. La « productivité des développeurs » n'est pas une formule et nous ne prospérons pas dans l'incertitude, nous choisissons donc soit de prendre le chemin le plus facile, soit de nous en éloigner.

Pensez-y : des milliards de dollars sont dépensés chaque année pour les équipes de développement. S'il existait une méthode universelle pour mesurer la productivité des développeurs, serait-elle encore un mystère ? Ou allez-vous lire ce blog ?

PS : Si vous lisez ce blog avec l'intention de mesurer vos développeurs les plus productifs ou d'obtenir un chiffre qui vous aidera à promouvoir et à licencier des développeurs, détournez-vous car vous serez déçu.

Alors faut-il essayer de mesurer la productivité des développeurs ?

Oui, c'est vrai ! ! Parce que la productivité des développeurs ne consiste pas seulement à améliorer les résultats de l'ingénierie, il s'agit également d'assurer la satisfaction et le bien-être de l'équipe. Souvent, les mesures de productivité aident également à identifier les goulots d'étranglement dans le processus de développement et les défis liés à l'environnement de travail et à la culture de l'équipe.

Phil Jackson, l'un des entraîneurs de basket-ball les plus talentueux, l'a magnifiquement exprimé :

"La force de l'équipe réside dans chaque membre. La force de chaque membre est la force de l'équipe." Dans le contexte d'une équipe de développement, le succès de chaque équipe dépend de la capacité de chaque développeur à faire de son mieux et à contribuer continuellement au succès de l'équipe.

D'accord, maintenant, comment dois-je mesurer la productivité des développeurs ?

Deux piliers fondamentaux pour maximiser vos chances de réussite dans la mesure de la productivité des développeurs.

1. Ne réduisez jamais la productivité à une seule mesure

Mesurer la productivité des développeurs est difficile car nous essayons de mesurer les personnes impliquées dans des tâches à la fois logiques et créatives. Et nous, en tant qu’avares cognitifs, essayons de réduire la productivité à une mesure – laissez-moi être clair, ce modèle échouera.

Au lieu de cela, essayez de capturer la productivité dans plusieurs dimensions et d'exploiter quelque chose comme le cadre SPACE (S-Satisfaction et bonheur, P-Performance, A-Activity, C-Communication et Collaboration, E-Efficiency et Processus) peut aider les équipes de développeurs à mesurer la productivité des développeurs de la bonne manière.

2. Communiquer avec l'équipe

Il existe un malentendu très courant : la productivité des développeurs ne convient qu'aux managers. Cela ne pourrait pas être plus éloigné de la vérité. La recherche montre qu’il existe des différences significatives entre les perceptions des développeurs et des managers sur la productivité des développeurs. La plupart des développeurs associent une plus grande productivité à une activité plus élevée, tandis que la plupart des gestionnaires associent la productivité à la performance et à l'efficacité.

Cette nette différence de perception ne peut être éliminée que lorsque les équipes de développement communiquent sur ce que la productivité signifie pour elles et quelles sont leurs véritables intentions en matière de suivi de la productivité. Cela permet de clarifier pourquoi cela est important et comment nous devrions le mesurer, et supprime également les réserves de la plupart des équipes de développement. Est-ce le chiffre qui détermine notre note ? Ou faisons-nous cela parce que les dirigeants ne croient pas que nous pouvons faire le travail ?

Choses à faire

Utilisez le framework SPACE pour suivre la productivité des développeurs sur plusieurs dimensions.

1. Communiquer les intentions à toute l'équipe.
2. Utilisez des indicateurs de productivité pour identifier les domaines à améliorer et éliminer les goulots d'étranglement.
3. Ce qu'il ne faut pas faire

Réduire la productivité à une seule mesure.

1. Développez des mesures secrètes pour suivre la productivité.
2. Utilisez les métriques comme seules métriques pour déterminer votre évaluation.
3. Metriques de productivité des développeurs

Examinons maintenant quelques mesures de productivité des développeurs suivies dans toutes les dimensions spatiales.

Metriques de productivité des développeurs :

Satisfaction et bonheur

Une équipe très satisfaite est une équipe hautement productive. C’est l’un des principaux indicateurs d’une équipe et d’une culture de travail saines. Cependant, la satisfaction est un concept abstrait, et si quelqu'un vous demande « Dans quelle mesure êtes-vous satisfait ? », oubliez la mesure. Je suis sûr que vous réfléchirez quelques minutes avant de répondre à cette question, à ce que la satisfaction signifie pour vous et comment la quantifier. Nous savons que capturer numériquement cet aspect est extrêmement difficile. Ce que vous voyez ici, ce sont des mesures proxy qui tentent de capturer au mieux différents aspects de la satisfaction et du bonheur des développeurs.

• Travail terminé : chaque fois que nous accomplissons une tâche, notre cerveau libère de la dopamine, ce qui nous permet de nous sentir satisfaits et motivés immédiatement une fois la tâche terminée. Par conséquent, un taux d'achèvement des travaux élevé par rapport au travail promis rendra le développeur très satisfait car il sera en mesure de terminer le travail promis dans les délais et de contribuer au succès de l'équipe.
• Heures supplémentaires : Heures supplémentaires ≠ productivité plus élevée ; en fait, c'est le contraire qui est vrai, les heures supplémentaires sont l'un des principaux contributeurs à l'épuisement professionnel des développeurs et nuisent à leur bien-être. Le suivi des heures de travail supplémentaires, comme le week-end ou tard le soir, peut vous aider à comprendre si vos développeurs sont satisfaits et fonctionnent bien dans leur environnement de travail actuel.
  • Les affaires ne sont pas un moyen de réussite, c'est un obstacle à la réussite
    - Alex Soojung-Kim Pang
    
• Désengagement : L'indicateur le plus courant d'insatisfaction et d'épuisement professionnel est le désengagement des équipes et des activités de l'équipe. Une façon de mesurer l'engagement des développeurs consiste à mesurer les changements dans le temps de réponse général d'un développeur aux activités de l'équipe telles que les révisions de code, ou une diminution des interactions ou de la participation aux réunions d'équipe.
• Enquêtes auprès des développeurs : souvent, lorsqu'il s'agit de déterminer les meilleurs indicateurs de productivité, nous oublions le moyen le plus évident, qui consiste à interroger votre équipe et à comprendre le sentiment de votre équipe en réalisant et en analysant une enquête de satisfaction des développeurs. Posez des questions telles que « Êtes-vous satisfait ? » (Note 1-5)" est la pire façon de comprendre cela. Cependant, il peut y avoir d'autres questions qui peuvent vous aider à capturer des informations similaires de différentes manières et dimensions.
• Tenure : Un excellent moyen de suivre la satisfaction au sein de votre équipe, vous peut examiner l'ancienneté moyenne des membres d'une équipe de développement. Compte tenu de la nature des tendances des développeurs, une fourchette d'ancienneté appropriée pourrait être comprise entre 12 et 18 mois.

La meilleure façon de mesurer les performances. des développeurs et des équipes de développement est de mesurer les résultats plutôt que le résultat. Ces mesures nous aident à capturer les aspects de qualité du travail effectué par les développeurs. Le résultat idéal pour tout développeur est un minimum de fonctionnalités de retouche de développement, garantissant une livraison dans les délais et une satisfaction maximale du client.

Retravail : lorsque les développeurs doivent corriger leurs demandes d'extraction ou que des tâches sont souvent renvoyées du contrôle qualité aux développeurs pour des corrections de bugs, cela est une indication claire de ce qui a été fait. La qualité du travail n'est pas à la hauteur des normes attendues. le cycle de développement des fonctionnalités finit par s'allonger. L'idée n'est pas d'avoir zéro révision, et les retouches sont souvent dues à des changements d'exigences cependant, si un développeur est confronté aux mêmes contraintes d'équipe que les autres ; , alors c'est certainement le signe d'un écart de performance.

Livraison dans les délais : l'un des résultats qui intéresse tout ingénieur et chef d'entreprise est la prévisibilité de la livraison, car de nombreuses autres décisions commerciales sont souvent communiquées aux clients dans l'ordre. pour avoir de la prévisibilité tout au long du processus d'ingénierie, il est absolument important que chaque développeur s'imprègne également de cette qualité. Une façon de mesurer cela est d'examiner ce que les développeurs engagent lors d'un sprint/itération de développement.

• Satisfaction du client. : Il est convenu qu'il s'agit du résultat le plus important pour apporter de la valeur à toute organisation, il doit donc en être de même pour l'équipe de développement. La satisfaction du client peut signifier de meilleurs résultats pour les commentaires de l'App Store, soit le service API a une disponibilité plus élevée et. des temps de réponse plus rapides, ou pour l'équipe de la plate-forme, cela peut signifier que les bibliothèques internes utilisées par d'autres équipes sont plus faciles à utiliser et présentent un minimum de bogues signalés malgré la satisfaction des clients. Les diplômes ne sont pas uniquement pilotés par les équipes d'ingénierie, mais leur utilisation comme mesure de performance continue. les équipes de développement en contact avec les utilisateurs réels des produits qu'elles construisent et les aide à se concentrer sur les bonnes choses
• Activité
• La dimension de l'activité elle-même est globalement équivalente. Cependant, l'activité à elle seule ne peut jamais vraiment mesurer la productivité des développeurs car elle est la plus simple. dimension à suivre. Le suivi des métriques d'activité en conjonction avec d'autres dimensions de différents domaines du processus SDLC vous aidera à identifier les véritables goulots d'étranglement parmi les développeurs et les domaines à améliorer

.

• Tâches résolues : les activités de cette phase aident à déterminer à quelle fréquence et dans quelle mesure les développeurs contribuent aux tâches de développement. Étant donné que les tâches de développement sont toujours planifiées sous forme de tâches, de user stories ou de sous-tâches sur l'outil de gestion de projet, l'examen du total des tâches résolues peut aider à comprendre l'implication des développeurs dans cette partie du cycle de développement.
• Examiner les demandes d'extraction : généralement, seul le responsable technique ou le responsable de l'équipe de développement a la responsabilité d'examiner les modifications/demandes d'extraction, ce qui est un anti-modèle évident. Encourager chaque développeur à réviser de plus en plus le code de ses pairs permet d'éliminer les goulots d'étranglement en matière de révision. Cette mesure serait un excellent moyen de déterminer si un développeur contribue à la charge de révision de l'équipe.
• Fréquence de déploiement : le nombre de fois où votre équipe déploie des modifications dans le système de production peut vous aider à comprendre l'aspect rapidité de votre processus de développement. Il s'agit également de l'une des mesures DORA, dont les études montrent qu'elle est également fortement corrélée à la satisfaction client et même à la rentabilité d'une organisation, ce qui en fait une excellente mesure pour suivre les dimensions des activités de productivité dans les équipes de développement.

COMMUNICATION ET COLLABORATION

Dans toute équipe de développement, le produit final (qu'il s'agisse d'une fonctionnalité, d'un service, d'une application ou d'une amélioration) est toujours le résultat d'un effort d'équipe. Une bonne communication et une bonne collaboration sont la base de la constitution d’une équipe de développement efficace. L'inclusion de cette dimension dans la mesure de la productivité des développeurs peut promouvoir une culture de transparence et de partage d'informations. Voici quelques mesures de productivité pour aider à capturer cela :

• Temps d'attente et temps de cycle des relations publiques : si l'équipe de développement a une bonne collaboration, cela peut être clairement reflété dans son processus de révision, car il s'agit probablement du goulot d'étranglement le plus important du processus de développement, car il dépend d’une communication efficace entre les contributeurs et les réviseurs et vice versa. Une mesure qui permet de suivre le degré de collaboration d'un développeur consiste à mesurer le temps qu'il faut à ce développeur pour commencer à examiner une demande d'extraction après son attribution. Ensuite, mesurer le temps de cycle moyen des pull request peut aider à comprendre les compétences en communication d’un contributeur.
• Nombre de membres travaillant ensemble : les équipes de développement ont souvent des silos de connaissances et des groupes de développeurs qui interagissent uniquement entre eux et non avec le reste de l'équipe ; c'est un autre anti-modèle classique ; Mesurer la façon dont un développeur communique et communique avec les autres membres de l'équipe est un bon moyen de mesurer cette dimension.
• Temps d'intégration pour les nouveaux membres : chaque fois qu'un nouveau développeur rejoint l'équipe, il passe par une première courbe d'apprentissage, comprend l'environnement commercial, se familiarise avec la pile technologique et obtient généralement de l'aide pour les procédures pas à pas du code. Le temps qu'il faut à un développeur pour effectuer son premier changement impactant depuis son arrivée est une mesure de productivité importante pour la communication de l'équipe de développement. En tant qu'équipe dotée de bonnes pratiques de documentation, les développeurs disposés à déployer des efforts pour aider les nouveaux arrivants permettront aux nouveaux développeurs d'apporter des modifications percutantes le plus rapidement possible. Un bon point de référence à atteindre est le premier résultat productif d'un nouveau développeur au cours des 30 premiers jours.

Efficacité et Processus

C'est la dimension de « l'entrée dans le processus » dont parlent souvent les développeurs. Les métriques ici aident à comprendre le nombre d'interruptions dans le cycle de développement et la fluidité d'une tâche du début à la fin. Les interruptions fréquentes ont non seulement un impact sur la productivité des développeurs, mais peuvent également entraîner une augmentation des niveaux de stress et de fatigue.

• Temps de développement ininterrompu : il est absolument important que les développeurs disposent chaque jour de suffisamment de temps ininterrompu pour se lancer dans le processus et investir du temps dans les activités de développement. L’un des plus gros obstacles réside dans les réunions d’équipe. Souvent, pour encourager des temps de développement plus longs, les équipes adoptent des journées de travail sans réunion ou adoptent des plages horaires strictes pendant lesquelles les réunions d'équipe peuvent être programmées. Un temps de développement ininterrompu plus long n’indique pas nécessairement une productivité plus élevée des développeurs. Cependant, il est certain que si les développeurs ne disposent pas de suffisamment de temps ininterrompu, le processus nécessaire au développement ne pourra pas être réalisé.
• Délai d'exécution : davantage d'interruptions dans le cycle de développement, davantage de transferts et une réouverture trop fréquente des tâches sont des indicateurs d'une efficacité et d'un flux médiocres des tâches de développement. Le délai de validation capture cela avec précision car il mesure le temps total nécessaire pour qu'un changement ait un impact sur les utilisateurs finaux. Un délai de livraison (CLT) relativement élevé signifie certainement une diminution de l'efficacité et du flux de l'équipe de développement. Le CLT est également l'un des indicateurs DORA. Plus d’informations à ce sujet peuvent être trouvées ici.
• Tickets moyens de travaux en cours (WIP) : le changement de contexte est définitivement un tueur de productivité. Faire plus de choses en même temps signifie toujours qu’il faut plus de temps pour tout faire et peut également conduire à un épuisement mental inutile.
  • Deux tâches parallèles — 20 % de perte en raison d'un changement de contexte.
  • Trois tâches parallèles — 40 % de perte en raison de changements de contexte.
  • — Gérald M. Weinberg

Les tickets WIP enregistrent parfaitement le nombre de tâches sur lesquelles un développeur travaille en parallèle. Suivre cette mesure de productivité et essayer de la maintenir en dessous de trois tâches est une bonne pratique de départ pour votre équipe de développement.

Engagement au changement

Lorsque vous examinez les mesures qui augmentent la productivité des développeurs, les actions qui vous aident à conduire le changement seront des changements dans le processus de développement. Mesurer l'implication des développeurs dans les changements conduits par l'équipe peut aider à comprendre à quel point chaque individu travaille dur pour corriger les processus de l'équipe. Chaque changement de processus peut être associé à une mesure qui capture dans quelle mesure le processus est suivi, et les classements qui suivent ces mesures peuvent vous aider à gamifier et à comprendre quels développeurs contribuent bien à votre initiative de changement de processus.

C'est tout le monde !

Nous constatons que la productivité des développeurs est souvent comprise à tort comme une mesure unique ou une mesure facile à suivre, plutôt que comme une mesure réellement importante. Il est absolument essentiel que nous suivions la productivité des développeurs et adoptions une approche globale pour améliorer la productivité des développeurs, en nous inspirant de frameworks comme SPACE. Il est préférable de commencer avec quelques indicateurs, mais il est important de choisir ces indicateurs selon au moins trois dimensions. Nous avons discuté de la liste exhaustive des dimensions et des nombreuses mesures au sein de chaque dimension, vous et votre équipe devez maintenant déterminer les bonnes dimensions et les bonnes mesures qui ont le plus d'impact.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!