Mesurer la productivité des développeurs : des cas concrets chez Google, Notion et d’autres

xguru · 2024-01-22T11:06:01+09:00

Analyse approfondie de la manière dont 17 entreprises technologiques, dont Google, LinkedIn, Peloton, Amplitude, Intercom, Notion et Postman, mesurent la productivité des développeurs 1. Indicateurs de productivité des développeurs dans 17 entreprises technologiques Mesurer la productivité des développeurs est un problème complexe, car dans l’ingénierie logicielle, qui relève d’un travail fondé sur la connaissance, la notion même de « productif » reste ambiguë Des équipes appelées productivité développeur (DevProd) ou expérience développeur (DevEx) aident les développeurs à livrer plus facilement des logiciels de haute qualité Ces équipes ont besoin d’indicateurs de productivité développeur pour mesurer la productivité des équipes d’ingénierie et leurs points de blocage, ainsi que pour suivre si leur travail a un impact réel Indicateurs de productivité des développeurs utilisés dans ces entreprises Facilité de livraison (Amplitude, GoodRx, Intercom, Postman, Lattice) Vitesse d’expérimentation (Etsy) Stabilité des services/applications (DoorDash) Indicateurs SPACE (Microsoft) Temps de concentration hebdomadaire par ingénieur (Uber) Quatre catégories selon la taille de l’entreprise Google : plus de 100 000 employés LinkedIn : plus de 10 000 Peloton : entre 1 000 et 10 000 Scale-ups (entre 100 et 1 000 ingénieurs) : Notion, Postman, Intercom, Amplitude, GoodRx, Lattice 2. L’approche de Google Google est souvent cité comme une référence en matière de mesure de la productivité des développeurs, mais certains estiment qu’imiter un tel niveau d’investissement est impossible pour la plupart des entreprises L’équipe Developer Intelligence de Google est une unité spécialisée qui mesure la productivité des développeurs et fournit des insights aux dirigeants Google estime qu’un indicateur unique ne peut pas capturer la productivité, et l’aborde selon trois dimensions : vitesse, facilité, qualité Speed : combien de temps faut-il pour terminer une revue de code ? Ease : à quel point est-il facile ou difficile pour un développeur de passer par le processus de revue de code ? Quality : quel est le niveau de qualité des retours reçus lors de la revue de code ? Google combine des mesures qualitatives et quantitatives pour calculer ses indicateurs 3. LinkedIn LinkedIn opère de manière indépendante au sein de Microsoft et emploie plus de 10 000 personnes LinkedIn dispose d’une équipe Developer Insights qui mesure la productivité et la satisfaction des développeurs, puis transmet ses enseignements au reste de l’organisation LinkedIn capture ses indicateurs à l’aide d’enquêtes trimestrielles, d’un système de feedback en temps réel et d’indicateurs basés sur les systèmes Enquêtes trimestrielles : L’équipe Developer Insights évalue l’expérience développeur sur différents outils, processus et activités via une enquête trimestrielle L’enquête comprend environ 30 questions et les développeurs peuvent y répondre en moins de 10 minutes L’enquête est diffusée via une plateforme propriétaire développée et gérée par l’équipe Developer Insights, qui permet une personnalisation avancée des questions en s’appuyant sur les données collectées par le système de feedback en temps réel et les systèmes d’indicateurs Système de feedback en temps réel : Pour recueillir du feedback entre deux enquêtes trimestrielles, LinkedIn a développé un système en temps réel qui suit les événements et actions effectués par les développeurs dans les outils de développement, puis envoie des enquêtes ciblées selon certains déclencheurs Ce système utilise un mécanisme de limitation intelligent afin d’éviter de submerger les développeurs de demandes de feedback Indicateurs basés sur les systèmes : LinkedIn utilise aussi les données système pour calculer ses indicateurs, ce qui permet des mesures très précises sur des sujets comme le temps de build ou la fréquence des déploiements L’équipe Developer Insights maintient un système global de collecte et d’analyse de ces données, appelé Developer Insights Hub, ou iHub Grâce à ce système, toutes les équipes chez LinkedIn peuvent créer des tableaux de bord et métriques personnalisés selon leurs besoins LinkedIn prend en compte des indicateurs qualitatifs et quantitatifs Developer Net User Satisfaction (NSAT) : mesure le niveau global de satisfaction des développeurs vis-à-vis des systèmes de développement de LinkedIn. Mesuré chaque trimestre Developer Build Time (P50 et P90) : mesure, en secondes, le temps d’attente des développeurs pour qu’un build se termine en local pendant le développement Code Reviewer Response Time (P50 et P90) : mesure, en heures ouvrées, le temps nécessaire à un relecteur de code pour répondre à chaque mise à jour de revue de code d’un auteur Post-Commit CI Speed (P50 et P90) : mesure, en minutes, le temps nécessaire à chaque commit pour passer le pipeline d’intégration continue (CI) CI Determinism : concept opposé à la fragilité des tests. Il désigne la probabilité que le résultat d’une suite de tests soit valide plutôt qu’erroné Deployment Success Rate : mesure la fréquence à laquelle les déploiements en production réussissent Winsorized Means : méthode permettant de reconnaître des améliorations dans des métriques affectées par des valeurs extrêmes, en remplaçant les valeurs les plus hautes et les plus basses par des nombres plus proches du centre The Developer Experience Index : indicateur spécifique fourni par LinkedIn à ses équipes. Il s’agit d’un score composite basé sur plusieurs indicateurs, comme ceux listés ci-dessus 4. Peloton Peloton est une grande entreprise d’environ 3 000 à 4 000 employés, bien plus petite que LinkedIn L’approche de Peloton a commencé par des insights qualitatifs issus d’enquêtes sur l’expérience développeur, puis a été complétée par des indicateurs quantitatifs Peloton mesure la productivité en se concentrant sur quatre grands domaines : engagement, vitesse, qualité, stabilité Engagement : score de satisfaction des développeurs Velocity : temps jusqu’à la première et à la dixième PR pour chaque nouvelle recrue, lead time, fréquence de déploiement Quality : proportion de PR de moins de 250 lignes, couverture de code, taux d’échec des changements Stability : temps de restauration des services L’enquête sur l’expérience développeur, qui sert à mesurer une grande partie de ces indicateurs, est pilotée par l’équipe support technique et expérience développeur de Peloton, intégrée à l’organisation product operations Cette équipe est aussi chargée d’analyser les résultats de l’enquête et de les partager avec les dirigeants de l’ensemble de l’organisation 5. Scale-ups et petites entreprises Plusieurs scale-ups comme Notion, Postman, Amplitude, GoodRx, Intercom et Lattice emploient entre 100 et 1 000 ingénieurs Ces entreprises se concentrent sur des « moveable metrics » Les moveable metrics sont des indicateurs que les équipes de productivité développeur peuvent « faire bouger » positivement ou négativement par leur action. Ils sont utiles pour démontrer leur impact Indicateurs communs Facilité de livraison (Ease of Delivery, moveable) : La plupart des entreprises mesurent à quel point les développeurs estiment facile ou difficile d’accomplir leur travail, via un indicateur qualitatif de facilité de livraison Plusieurs responsables DevProd expliquent que cet indicateur sert de « boussole » à leur équipe, car leur mission est de rendre la vie des développeurs plus confortable Comme cet indicateur peut fortement évoluer, il est aussi utile pour démontrer l’impact de l’équipe D’un point de vue théorique, il capture également des aspects clés de l’expérience développeur, comme la charge cognitive et les boucles de feedback Engagement Elles suivent l’engagement, qui mesure à quel point les développeurs se sentent intéressés et stimulés par leur travail En général, l’engagement est mesuré via les enquêtes RH, mais les équipes DevProd mettent elles aussi l’accent dessus pour cette raison L’engagement des développeurs et la productivité sont étroitement liés : comme le dit l’expression, « un développeur heureux est un développeur productif » Le véritable avantage de mesurer l’engagement est de pouvoir équilibrer d’autres indicateurs plus centrés sur la vitesse. Livrer plus vite est positif, mais pas au prix d’une baisse du bien-être des développeurs Perte de temps (Time Loss, moveable) GoodRx et Postman s’intéressent au volume moyen de temps perdu Il est mesuré comme la proportion du temps des développeurs perdue à cause d’obstacles dans l’environnement de travail Cet indicateur ressemble à la facilité de livraison dans la mesure où il s’agit d’une métrique actionnable sur laquelle l’équipe peut avoir un impact direct Il présente un grand avantage : il peut être converti en coût, ce qui le rend facile à comprendre pour les dirigeants métiers Par exemple, dans une organisation où la masse salariale d’ingénierie atteint 10 millions de dollars, si une initiative réduit la perte de temps de 20 % à 10 %, cela représente 1 million de dollars d’économies Taux d’échec des changements (Change Failure Rate) C’est l’un des quatre indicateurs principaux du programme de recherche DORA (DevOps Research and Assessment) C’est un indicateur de premier plan suivi par plusieurs entreprises, dont Amplitude et Lattice L’équipe DORA définit le taux d’échec des changements ainsi : « Le pourcentage de changements déployés en production ou exposés aux utilisateurs qui entraînent une dégradation du service (par exemple une panne ou une interruption) et nécessitent ensuite une correction (par exemple un hotfix, un rollback, un fix forward ou un patch). » 6. Découvertes intéressantes Les indicateurs DORA et SPACE sont utilisés de manière sélective, et toutes les entreprises combinent des mesures qualitatives et quantitatives DORA : DevOps Research and Assessment SPACE : Satisfaction and wellbeing, Performance, Activity, Communication and collaboration, Efficiency and flow Le « temps de concentration » est fortement mis en avant. Stripe et Uber ont partagé des indicateurs précis comme le « nombre de jours avec suffisamment de temps de concentration » et le « temps de concentration hebdomadaire par ingénieur » Indicateurs originaux Adoption Rate (DoorDash, GoodRx, Spotify) Design Docs Generated per Engineer (Uber) Experiment Velocity (Etsy) Developer CSAT/NSAT (Chime, LinkedIn) 7. Comment choisir ses propres indicateurs Il est recommandé d’utiliser le framework Goals, Signals, Metrics (GSM) de Google pour guider le choix des indicateurs Commencer par définir l’objectif du problème à résoudre, puis identifier les signaux qui montrent que cet objectif a été atteint, avant de choisir les indicateurs appropriés Définir l’objectif Google : « Aider les développeurs à livrer d’excellents produits rapidement et facilement. » Slack : « Offrir à chaque ingénieur un environnement de développement fluide. » Stripe : « Rendre l’ingénierie logicielle plus simple. » Définir les indicateurs principaux en remontant depuis l’objectif À quel point est-il facile pour les développeurs de livrer du logiciel ? (Ease) : Ease of Delivery, Deployment Lead Time, Build Failure Rate À quelle vitesse les développeurs livrent-ils du logiciel ? (Speed) : Perceived Delivery Speed, Perceived Productivity Quelle est la qualité du logiciel livré ? (Quality) : Incident frequency, Perceived Software Quality Si vous êtes CTO, VPE ou engineering lead Le meilleur conseil est de « reformuler le problème » Choisir des indicateurs dans trois catégories Impact business Pourquoi faut-il construire cela maintenant ? De quelle manière ce projet génère-t-il des revenus ou soutient-il les objectifs business ? Ce projet avance-t-il correctement, ou prend-il du retard ? Performance système Les systèmes d’ingénierie sont-ils rapides et stables ? L’infrastructure est-elle sûre et bien maintenue ? Les utilisateurs sont-ils satisfaits des services qu’ils utilisent ? Efficacité de l’ingénierie Le fait de combiner des indicateurs qualitatifs et quantitatifs est un point commun à toutes les entreprises Inspirez-vous de la diversité des mesures utilisées par chaque entreprise Les éléments mis en avant varient fortement selon les priorités et la culture d’ingénierie de chaque entreprise

(newsletter.pragmaticengineer.com)

53 points par xguru 2024-01-22 | 1 commentaires | Partager sur WhatsApp

Analyse approfondie de la manière dont 17 entreprises technologiques, dont Google, LinkedIn, Peloton, Amplitude, Intercom, Notion et Postman, mesurent la productivité des développeurs

1. Indicateurs de productivité des développeurs dans 17 entreprises technologiques

Mesurer la productivité des développeurs est un problème complexe, car dans l’ingénierie logicielle, qui relève d’un travail fondé sur la connaissance, la notion même de « productif » reste ambiguë
Des équipes appelées productivité développeur (DevProd) ou expérience développeur (DevEx) aident les développeurs à livrer plus facilement des logiciels de haute qualité
Ces équipes ont besoin d’indicateurs de productivité développeur pour mesurer la productivité des équipes d’ingénierie et leurs points de blocage, ainsi que pour suivre si leur travail a un impact réel
Indicateurs de productivité des développeurs utilisés dans ces entreprises
- Facilité de livraison (Amplitude, GoodRx, Intercom, Postman, Lattice)
- Vitesse d’expérimentation (Etsy)
- Stabilité des services/applications (DoorDash)
- Indicateurs SPACE (Microsoft)
- Temps de concentration hebdomadaire par ingénieur (Uber)
Quatre catégories selon la taille de l’entreprise
- Google : plus de 100 000 employés
- LinkedIn : plus de 10 000
- Peloton : entre 1 000 et 10 000
- Scale-ups (entre 100 et 1 000 ingénieurs) : Notion, Postman, Intercom, Amplitude, GoodRx, Lattice

2. L’approche de Google

Google est souvent cité comme une référence en matière de mesure de la productivité des développeurs, mais certains estiment qu’imiter un tel niveau d’investissement est impossible pour la plupart des entreprises
L’équipe Developer Intelligence de Google est une unité spécialisée qui mesure la productivité des développeurs et fournit des insights aux dirigeants
Google estime qu’un indicateur unique ne peut pas capturer la productivité, et l’aborde selon trois dimensions : vitesse, facilité, qualité
- Speed : combien de temps faut-il pour terminer une revue de code ?
- Ease : à quel point est-il facile ou difficile pour un développeur de passer par le processus de revue de code ?
- Quality : quel est le niveau de qualité des retours reçus lors de la revue de code ?
Google combine des mesures qualitatives et quantitatives pour calculer ses indicateurs

3. LinkedIn

LinkedIn opère de manière indépendante au sein de Microsoft et emploie plus de 10 000 personnes
LinkedIn dispose d’une équipe Developer Insights qui mesure la productivité et la satisfaction des développeurs, puis transmet ses enseignements au reste de l’organisation
LinkedIn capture ses indicateurs à l’aide d’enquêtes trimestrielles, d’un système de feedback en temps réel et d’indicateurs basés sur les systèmes
- Enquêtes trimestrielles :
  - L’équipe Developer Insights évalue l’expérience développeur sur différents outils, processus et activités via une enquête trimestrielle
  - L’enquête comprend environ 30 questions et les développeurs peuvent y répondre en moins de 10 minutes
  - L’enquête est diffusée via une plateforme propriétaire développée et gérée par l’équipe Developer Insights, qui permet une personnalisation avancée des questions en s’appuyant sur les données collectées par le système de feedback en temps réel et les systèmes d’indicateurs
- Système de feedback en temps réel :
  - Pour recueillir du feedback entre deux enquêtes trimestrielles, LinkedIn a développé un système en temps réel qui suit les événements et actions effectués par les développeurs dans les outils de développement, puis envoie des enquêtes ciblées selon certains déclencheurs
  - Ce système utilise un mécanisme de limitation intelligent afin d’éviter de submerger les développeurs de demandes de feedback
- Indicateurs basés sur les systèmes :
  - LinkedIn utilise aussi les données système pour calculer ses indicateurs, ce qui permet des mesures très précises sur des sujets comme le temps de build ou la fréquence des déploiements
  - L’équipe Developer Insights maintient un système global de collecte et d’analyse de ces données, appelé Developer Insights Hub, ou iHub
  - Grâce à ce système, toutes les équipes chez LinkedIn peuvent créer des tableaux de bord et métriques personnalisés selon leurs besoins
LinkedIn prend en compte des indicateurs qualitatifs et quantitatifs
- Developer Net User Satisfaction (NSAT) : mesure le niveau global de satisfaction des développeurs vis-à-vis des systèmes de développement de LinkedIn. Mesuré chaque trimestre
- Developer Build Time (P50 et P90) : mesure, en secondes, le temps d’attente des développeurs pour qu’un build se termine en local pendant le développement
- Code Reviewer Response Time (P50 et P90) : mesure, en heures ouvrées, le temps nécessaire à un relecteur de code pour répondre à chaque mise à jour de revue de code d’un auteur
- Post-Commit CI Speed (P50 et P90) : mesure, en minutes, le temps nécessaire à chaque commit pour passer le pipeline d’intégration continue (CI)
- CI Determinism : concept opposé à la fragilité des tests. Il désigne la probabilité que le résultat d’une suite de tests soit valide plutôt qu’erroné
- Deployment Success Rate : mesure la fréquence à laquelle les déploiements en production réussissent
- Winsorized Means : méthode permettant de reconnaître des améliorations dans des métriques affectées par des valeurs extrêmes, en remplaçant les valeurs les plus hautes et les plus basses par des nombres plus proches du centre
- The Developer Experience Index : indicateur spécifique fourni par LinkedIn à ses équipes. Il s’agit d’un score composite basé sur plusieurs indicateurs, comme ceux listés ci-dessus

4. Peloton

Peloton est une grande entreprise d’environ 3 000 à 4 000 employés, bien plus petite que LinkedIn
L’approche de Peloton a commencé par des insights qualitatifs issus d’enquêtes sur l’expérience développeur, puis a été complétée par des indicateurs quantitatifs
Peloton mesure la productivité en se concentrant sur quatre grands domaines : engagement, vitesse, qualité, stabilité
- Engagement : score de satisfaction des développeurs
- Velocity : temps jusqu’à la première et à la dixième PR pour chaque nouvelle recrue, lead time, fréquence de déploiement
- Quality : proportion de PR de moins de 250 lignes, couverture de code, taux d’échec des changements
- Stability : temps de restauration des services
L’enquête sur l’expérience développeur, qui sert à mesurer une grande partie de ces indicateurs, est pilotée par l’équipe support technique et expérience développeur de Peloton, intégrée à l’organisation product operations
Cette équipe est aussi chargée d’analyser les résultats de l’enquête et de les partager avec les dirigeants de l’ensemble de l’organisation

5. Scale-ups et petites entreprises

Plusieurs scale-ups comme Notion, Postman, Amplitude, GoodRx, Intercom et Lattice emploient entre 100 et 1 000 ingénieurs
Ces entreprises se concentrent sur des « moveable metrics »
- Les moveable metrics sont des indicateurs que les équipes de productivité développeur peuvent « faire bouger » positivement ou négativement par leur action. Ils sont utiles pour démontrer leur impact
Indicateurs communs
- Facilité de livraison (Ease of Delivery, moveable) :
  - La plupart des entreprises mesurent à quel point les développeurs estiment facile ou difficile d’accomplir leur travail, via un indicateur qualitatif de facilité de livraison
  - Plusieurs responsables DevProd expliquent que cet indicateur sert de « boussole » à leur équipe, car leur mission est de rendre la vie des développeurs plus confortable
  - Comme cet indicateur peut fortement évoluer, il est aussi utile pour démontrer l’impact de l’équipe
  - D’un point de vue théorique, il capture également des aspects clés de l’expérience développeur, comme la charge cognitive et les boucles de feedback
- Engagement
  - Elles suivent l’engagement, qui mesure à quel point les développeurs se sentent intéressés et stimulés par leur travail
  - En général, l’engagement est mesuré via les enquêtes RH, mais les équipes DevProd mettent elles aussi l’accent dessus pour cette raison
  - L’engagement des développeurs et la productivité sont étroitement liés : comme le dit l’expression, « un développeur heureux est un développeur productif »
  - Le véritable avantage de mesurer l’engagement est de pouvoir équilibrer d’autres indicateurs plus centrés sur la vitesse. Livrer plus vite est positif, mais pas au prix d’une baisse du bien-être des développeurs
- Perte de temps (Time Loss, moveable)
  - GoodRx et Postman s’intéressent au volume moyen de temps perdu
  - Il est mesuré comme la proportion du temps des développeurs perdue à cause d’obstacles dans l’environnement de travail
  - Cet indicateur ressemble à la facilité de livraison dans la mesure où il s’agit d’une métrique actionnable sur laquelle l’équipe peut avoir un impact direct
  - Il présente un grand avantage : il peut être converti en coût, ce qui le rend facile à comprendre pour les dirigeants métiers
  - Par exemple, dans une organisation où la masse salariale d’ingénierie atteint 10 millions de dollars, si une initiative réduit la perte de temps de 20 % à 10 %, cela représente 1 million de dollars d’économies
- Taux d’échec des changements (Change Failure Rate)
  - C’est l’un des quatre indicateurs principaux du programme de recherche DORA (DevOps Research and Assessment)
  - C’est un indicateur de premier plan suivi par plusieurs entreprises, dont Amplitude et Lattice
  - L’équipe DORA définit le taux d’échec des changements ainsi :
  « Le pourcentage de changements déployés en production ou exposés aux utilisateurs qui entraînent une dégradation du service (par exemple une panne ou une interruption) et nécessitent ensuite une correction (par exemple un hotfix, un rollback, un fix forward ou un patch). »

6. Découvertes intéressantes

Les indicateurs DORA et SPACE sont utilisés de manière sélective, et toutes les entreprises combinent des mesures qualitatives et quantitatives
- DORA : DevOps Research and Assessment
- SPACE : Satisfaction and wellbeing, Performance, Activity, Communication and collaboration, Efficiency and flow
Le « temps de concentration » est fortement mis en avant. Stripe et Uber ont partagé des indicateurs précis comme le « nombre de jours avec suffisamment de temps de concentration » et le « temps de concentration hebdomadaire par ingénieur »
Indicateurs originaux
- Adoption Rate (DoorDash, GoodRx, Spotify)
- Design Docs Generated per Engineer (Uber)
- Experiment Velocity (Etsy)
- Developer CSAT/NSAT (Chime, LinkedIn)

7. Comment choisir ses propres indicateurs

Il est recommandé d’utiliser le framework Goals, Signals, Metrics (GSM) de Google pour guider le choix des indicateurs
Commencer par définir l’objectif du problème à résoudre, puis identifier les signaux qui montrent que cet objectif a été atteint, avant de choisir les indicateurs appropriés
- Définir l’objectif
  - Google : « Aider les développeurs à livrer d’excellents produits rapidement et facilement. »
  - Slack : « Offrir à chaque ingénieur un environnement de développement fluide. »
  - Stripe : « Rendre l’ingénierie logicielle plus simple. »
- Définir les indicateurs principaux en remontant depuis l’objectif
  - À quel point est-il facile pour les développeurs de livrer du logiciel ? (Ease) : Ease of Delivery, Deployment Lead Time, Build Failure Rate
  - À quelle vitesse les développeurs livrent-ils du logiciel ? (Speed) : Perceived Delivery Speed, Perceived Productivity
  - Quelle est la qualité du logiciel livré ? (Quality) : Incident frequency, Perceived Software Quality
Si vous êtes CTO, VPE ou engineering lead
- Le meilleur conseil est de « reformuler le problème »
- Choisir des indicateurs dans trois catégories
  - Impact business
    - Pourquoi faut-il construire cela maintenant ?
    - De quelle manière ce projet génère-t-il des revenus ou soutient-il les objectifs business ?
    - Ce projet avance-t-il correctement, ou prend-il du retard ?
  - Performance système
    - Les systèmes d’ingénierie sont-ils rapides et stables ?
    - L’infrastructure est-elle sûre et bien maintenue ?
    - Les utilisateurs sont-ils satisfaits des services qu’ils utilisent ?
  - Efficacité de l’ingénierie
Le fait de combiner des indicateurs qualitatifs et quantitatifs est un point commun à toutes les entreprises
- Inspirez-vous de la diversité des mesures utilisées par chaque entreprise
- Les éléments mis en avant varient fortement selon les priorités et la culture d’ingénierie de chaque entreprise

1 commentaires

demorier 2024-01-24

Cela m’intéressait depuis le précédent article lié à McKinsey, et j’ai apprécié ce résumé ainsi que ce rappel.