Entwicklerproduktivität messen: Reale Beispiele von Google, Notion und anderen

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

Eine eingehende Analyse dazu, wie 17 Technologieunternehmen wie Google, LinkedIn, Peloton, Amplitude, Intercom, Notion und Postman die Entwicklerproduktivität messen 1. Kennzahlen zur Entwicklerproduktivität in 17 Technologieunternehmen Die Messung der Entwicklerproduktivität ist ein komplexes Problem, da schon die Bedeutung von „produktiv“ in der wissensbasierten Arbeit des Software Engineerings mehrdeutig ist Teams, die als Entwicklerproduktivitäts- (DevProd) oder Developer-Experience- (DevEx) Teams bezeichnet werden, unterstützen Entwickler dabei, hochwertige Software einfach bereitzustellen Diese Teams benötigen Kennzahlen zur Entwicklerproduktivität, um die Produktivität und Hindernisse von Engineering-Teams zu messen und nachzuverfolgen, ob ihre Arbeit tatsächlich Wirkung zeigt Von diesen Unternehmen verwendete Kennzahlen zur Entwicklerproduktivität Ease of Delivery (Amplitude, GoodRx, Intercom, Postman, Lattice) Experiment Velocity (Etsy) Stabilität von Services/Apps (DoorDash) SPACE-Metriken (Microsoft) Wöchentliche Fokuszeit pro Engineer (Uber) Ausgewählt wurden vier Kategorien nach Unternehmensgröße Google: mehr als 100.000 Mitarbeitende LinkedIn: mehr als 10.000 Peloton: mehr als 1.000 und weniger als 10.000 Scale-ups (100 bis unter 1.000 Engineers): Notion, Postman, Intercom, Amplitude, GoodRx, Lattice 2. Der Ansatz von Google Google wird oft als Best Practice für die Messung von Entwicklerproduktivität genannt, allerdings gibt es auch die Ansicht, dass es für die meisten Unternehmen unmöglich ist, Googles Investitionsniveau nachzuahmen Googles Developer Intelligence Team ist eine spezialisierte Abteilung, die Entwicklerproduktivität misst und Führungskräften Erkenntnisse liefert Google ist überzeugt, dass keine einzelne Kennzahl Produktivität vollständig erfassen kann, und betrachtet Produktivität daher entlang der drei Dimensionen Geschwindigkeit, Einfachheit und Qualität Speed Geschwindigkeit: Wie lange dauert es, bis ein Code Review abgeschlossen ist? Ease Einfachheit: Wie leicht oder schwer ist es für Entwickler, den Code-Review-Prozess zu durchlaufen? Quality Qualität: Wie gut ist das Feedback, das über Code Reviews eingeht? Google berechnet Kennzahlen durch eine Mischung aus qualitativen und quantitativen Messungen 3. LinkedIn LinkedIn operiert innerhalb von Microsoft unabhängig und beschäftigt mehr als 10.000 Mitarbeitende Bei LinkedIn gibt es ein Developer Insights Team, das Entwicklerproduktivität und -zufriedenheit misst und Erkenntnisse an den Rest der Organisation weitergibt LinkedIn erfasst Kennzahlen über vierteljährliche Umfragen, ein Echtzeit-Feedback-System und systembasierte Metriken Vierteljährliche Umfragen: Das Developer-Insights-Team bewertet über vierteljährliche Umfragen die Developer Experience über verschiedene Tools, Prozesse und Aktivitäten hinweg Die Umfragen enthalten etwa 30 Fragen und können von Entwicklern in ungefähr 10 Minuten beantwortet werden Die Umfragen werden über eine proprietäre Plattform bereitgestellt, die vom Developer-Insights-Team entwickelt und betrieben wird; auf Basis von Daten aus dem Echtzeit-Feedback- und Kennzahlensystem lassen sich die Fragen weitreichend anpassen und personalisieren Echtzeit-Feedback-System: Um zwischen den vierteljährlichen Umfragen Feedback zu sammeln, hat LinkedIn ein Echtzeit-Feedback-System entwickelt, das Ereignisse und Aktivitäten verfolgt, die Entwickler in ihren Entwicklungstools ausführen, und auf Basis bestimmter Trigger gezielte Umfragen versendet Das System verwendet einen intelligenten Throttling-Mechanismus, damit Entwickler nicht mit Feedback-Anfragen überhäuft werden Systembasierte Metriken: LinkedIn verwendet außerdem Systemdaten, um Kennzahlen zu berechnen, und erhält so hochpräzise Messwerte zu Dingen wie Build-Zeiten und Deployment-Häufigkeit Das Developer-Insights-Team betreibt ein globales System zum Erfassen und Analysieren dieser Daten, das als Developer Insights Hub (oder iHub) bezeichnet wird Über dieses System können alle Teams bei LinkedIn benutzerdefinierte Dashboards und Metriken passend zu ihren Anforderungen erstellen LinkedIn berücksichtigt sowohl qualitative als auch quantitative Kennzahlen Developer Net User Satisfaction (NSAT): Misst, wie zufrieden Entwickler insgesamt mit den Entwicklungssystemen von LinkedIn sind. Wird vierteljährlich gemessen Developer Build Time (P50 und P90): Misst in Sekunden, wie lange Entwickler während der Entwicklung darauf warten, dass Builds lokal abgeschlossen werden Code Reviewer Response Time (P50 und P90): Misst, wie lange Code Reviewer benötigen, um auf jedes Update eines Autors in einem Code Review zu reagieren (basierend auf Arbeitszeiten) Post-Commit CI Speed (P50 und P90): Misst in Minuten, wie lange jeder Commit benötigt, um die Continuous-Integration- (CI) Pipeline zu durchlaufen CI Determinism: Das Gegenkonzept zu Test-Flakiness. Gemeint ist die Wahrscheinlichkeit, dass das Ergebnis einer Test-Suite ein gültiges Resultat und kein Fehler ist Deployment Success Rate: Misst, wie häufig Deployments in die Produktionsumgebung erfolgreich sind Winsorisierte Mittelwerte (Winsorized Means): Eine Methode, Verbesserungen innerhalb von Metriken mit Ausreißern zu erkennen. Berechnet, indem die höchsten und niedrigsten Werte durch Zahlen näher an der Mitte ersetzt werden The Developer Experience Index: Eine spezielle Kennzahl, die LinkedIn Teams bereitstellt. Dieser Index ist ein zusammengesetzter Score auf Basis mehrerer Kennzahlen wie den oben genannten 4. Peloton Peloton ist ein großes Unternehmen mit rund 3.000 bis 4.000 Mitarbeitenden, aber deutlich kleiner als LinkedIn Pelotons Messansatz begann damit, qualitative Erkenntnisse über Umfragen zur Developer Experience zu gewinnen, die später zusammen mit quantitativen Kennzahlen verwendet wurden Peloton misst Produktivität mit Fokus auf vier Kernbereiche: Engagement, Geschwindigkeit, Qualität und Stabilität Engagement: Entwicklerzufriedenheits-Score Velocity: Zeit bis zum ersten und zehnten PR für alle Neueinstellungen, Lead Time, Deployment-Häufigkeit Quality: Anteil von PRs mit weniger als 250 Zeilen, Line Coverage, Change Failure Rate Stability: Zeit bis zur Wiederherstellung eines Services Die Umfrage zur Developer Experience, über die ein großer Teil dieser Kennzahlen gemessen wird, wird von Pelotons Team für Technical Enablement und Developer Experience geleitet, das Teil der Produktoperationsorganisation ist Das Team für Technical Enablement und Developer Experience ist auch dafür verantwortlich, die Umfrageergebnisse zu analysieren und mit Führungskräften in der gesamten Organisation zu teilen 5. Scale-ups und kleinere Unternehmen Mehrere Scale-up-Unternehmen wie Notion, Postman, Amplitude, GoodRx, Intercom und Lattice beschäftigen zwischen 100 und 1.000 Engineers Diese Unternehmen konzentrieren sich auf „bewegliche Kennzahlen (Moveable Metrics)“ Bewegliche Kennzahlen sind Kennzahlen, die Teams für Entwicklerproduktivität durch positiven oder negativen Einfluss ihrer Arbeit „bewegen“ können. Sie sind nützlich, um den eigenen Einfluss sichtbar zu machen Häufige Kennzahlen Ease of Delivery (beweglich): Die meisten Unternehmen messen Ease of Delivery, also ein qualitatives Maß dafür, wie leicht oder schwer Entwickler die Erledigung ihrer Arbeit empfinden Mehrere DevProd-Leads sagen, dass dies die „North Star“-Kennzahl ihrer Arbeit ist, weil das Ziel ihrer Teams darin besteht, das Leben der Entwickler einfacher zu machen Diese Kennzahl eignet sich auch gut, um Wirkung zu zeigen, weil sie sich vergleichsweise gut beeinflussen lässt Aus theoretischer Sicht erfasst sie außerdem zentrale Aspekte der Developer Experience wie kognitive Belastung und Feedback-Loops Engagement Erfasst wird auch Engagement, also wie interessiert und motiviert Entwickler ihre Arbeit erleben In der Regel wird Engagement über HR-Umfragen gemessen, aber auch DevProd-Teams fokussieren sich aus diesen Gründen darauf Entwickler-Engagement und Produktivität hängen eng zusammen; frei nach dem Motto „glückliche Entwickler sind produktive Entwickler“ kann Entwickler-Engagement als Indikator für Produktivität gesehen werden Der eigentliche Vorteil der Engagement-Messung besteht darin, dass sie andere, geschwindigkeitsorientierte Kennzahlen ausbalancieren kann. Software schneller auszuliefern ist gut, aber nicht auf Kosten sinkender Zufriedenheit der Entwickler Time Loss (beweglich) GoodRx und Postman achten auf den durchschnittlichen Zeitverlust Dieser wird als Anteil der Zeit von Entwicklern gemessen, die durch Hindernisse in ihrer Arbeitsumgebung verloren geht Diese Kennzahl ähnelt Ease of Delivery insofern, als sie eine bewegliche Kennzahl liefert, auf die das Dev-Team direkt Einfluss nehmen kann Ein großer Vorteil ist, dass sie sich in Kosten übersetzen lässt und daher von Business-Führungskräften leicht zu verstehen ist Wenn etwa in einer Organisation mit 10 Millionen Dollar Engineering-Personalkosten der Zeitverlust durch eine Initiative von 20 % auf 10 % sinkt, entspricht das einer Kostenersparnis von 1 Million Dollar Change Failure Rate Dies ist eine der vier zentralen Kennzahlen des Forschungsprogramms DORA (DevOps Research and Assessment) Sie ist eine Top-Level-Kennzahl, die von mehreren Unternehmen verfolgt wird, darunter Amplitude und Lattice Das DORA-Team definiert die Change Failure Rate wie folgt: „Der Prozentsatz von Release-Änderungen in Produktion oder für Nutzer, die zu einer Beeinträchtigung des Services führen (z. B. Service-Ausfall oder Serviceunterbrechung) und anschließend eine Behebung erfordern (z. B. Hotfix, Rollback, Fix Forward, Patch).“ 6. Interessante Erkenntnisse DORA- und SPACE-Metriken werden selektiv genutzt, und alle Unternehmen verwenden sowohl qualitative als auch quantitative Messungen DORA: DevOps Research and Assessment SPACE: Satisfaction and wellbeing, Performance, Activity, Communication and collaboration, Efficiency and flow Es gibt einen starken Fokus auf „Fokuszeit“, und Stripe sowie Uber teilten konkrete Kennzahlen wie „Anzahl der Tage mit ausreichend Fokuszeit“ und „wöchentliche Fokuszeit pro Engineer“ Ungewöhnliche Kennzahlen Adoption Rate (DoorDash, GoodRx, Spotify) Design Docs Generated per Engineer (Uber) Experiment Velocity (Etsy) Developer CSAT/NSAT (Chime, LinkedIn) 7. So wählen Sie Ihre eigenen Kennzahlen aus Es empfiehlt sich, die Auswahl von Kennzahlen mit Googles Goals, Signals, Metrics (GSM) Framework zu leiten Definieren Sie zuerst das Ziel des zu lösenden Problems, suchen Sie dann nach Signalen, die anzeigen, dass dieses Ziel erreicht wurde, und wählen Sie anschließend passende Kennzahlen aus Ziel definieren Google: „Wir unterstützen Entwickler dabei, großartige Produkte schnell und einfach auszuliefern.“ Slack: „Wir schaffen für jeden Engineer eine reibungslose Entwicklungsumgebung.“ Stripe: „Wir machen Software Engineering einfacher.“ Vom Ziel rückwärts arbeiten, um Top-Level-Kennzahlen zu definieren Wie einfach ist es für Entwickler, Software auszuliefern? (Ease): Ease of Delivery, Deployment Lead Time, Build Failure Rate Wie schnell liefern Entwickler Software aus? (Speed): Perceived Delivery Speed, Perceived Productivity Wie hoch ist die Qualität der ausgelieferten Software? (Quality): Incident Frequency, Perceived Software Quality Wenn Sie CTO, VPE oder Engineering Lead sind Der beste Rat ist, „das Problem neu zu rahmen (reframe the problem)“ Wählen Sie Kennzahlen aus drei Bereichen Business Impact Warum muss das jetzt gebaut werden? Wie generiert dieses Projekt Umsatz oder unterstützt Unternehmensziele? Läuft dieses Projekt planmäßig oder verzögert es sich? System Performance Sind die Engineering-Systeme schnell und stabil? Ist die Infrastruktur sicher und gut gewartet? Sind Nutzer mit den verwendeten Services zufrieden? Engineering-Effizienz Die Kombination aus qualitativen und quantitativen Kennzahlen ist in allen Unternehmen ein gemeinsames Muster Lassen Sie sich von den verschiedenen Messgrößen inspirieren, die einzelne Unternehmen nutzen Je nach Prioritäten und Engineering-Kultur unterscheiden sich die Schwerpunkte bei den gemessenen Kennzahlen erheblich

(newsletter.pragmaticengineer.com)

53 Punkte von xguru 2024-01-22 | 1 Kommentare | Auf WhatsApp teilen

Eine eingehende Analyse dazu, wie 17 Technologieunternehmen wie Google, LinkedIn, Peloton, Amplitude, Intercom, Notion und Postman die Entwicklerproduktivität messen

1. Kennzahlen zur Entwicklerproduktivität in 17 Technologieunternehmen

Die Messung der Entwicklerproduktivität ist ein komplexes Problem, da schon die Bedeutung von „produktiv“ in der wissensbasierten Arbeit des Software Engineerings mehrdeutig ist
Teams, die als Entwicklerproduktivitäts- (DevProd) oder Developer-Experience- (DevEx) Teams bezeichnet werden, unterstützen Entwickler dabei, hochwertige Software einfach bereitzustellen
Diese Teams benötigen Kennzahlen zur Entwicklerproduktivität, um die Produktivität und Hindernisse von Engineering-Teams zu messen und nachzuverfolgen, ob ihre Arbeit tatsächlich Wirkung zeigt
Von diesen Unternehmen verwendete Kennzahlen zur Entwicklerproduktivität
- Ease of Delivery (Amplitude, GoodRx, Intercom, Postman, Lattice)
- Experiment Velocity (Etsy)
- Stabilität von Services/Apps (DoorDash)
- SPACE-Metriken (Microsoft)
- Wöchentliche Fokuszeit pro Engineer (Uber)
Ausgewählt wurden vier Kategorien nach Unternehmensgröße
- Google: mehr als 100.000 Mitarbeitende
- LinkedIn: mehr als 10.000
- Peloton: mehr als 1.000 und weniger als 10.000
- Scale-ups (100 bis unter 1.000 Engineers): Notion, Postman, Intercom, Amplitude, GoodRx, Lattice

2. Der Ansatz von Google

Google wird oft als Best Practice für die Messung von Entwicklerproduktivität genannt, allerdings gibt es auch die Ansicht, dass es für die meisten Unternehmen unmöglich ist, Googles Investitionsniveau nachzuahmen
Googles Developer Intelligence Team ist eine spezialisierte Abteilung, die Entwicklerproduktivität misst und Führungskräften Erkenntnisse liefert
Google ist überzeugt, dass keine einzelne Kennzahl Produktivität vollständig erfassen kann, und betrachtet Produktivität daher entlang der drei Dimensionen Geschwindigkeit, Einfachheit und Qualität
- Speed Geschwindigkeit: Wie lange dauert es, bis ein Code Review abgeschlossen ist?
- Ease Einfachheit: Wie leicht oder schwer ist es für Entwickler, den Code-Review-Prozess zu durchlaufen?
- Quality Qualität: Wie gut ist das Feedback, das über Code Reviews eingeht?
Google berechnet Kennzahlen durch eine Mischung aus qualitativen und quantitativen Messungen

3. LinkedIn

LinkedIn operiert innerhalb von Microsoft unabhängig und beschäftigt mehr als 10.000 Mitarbeitende
Bei LinkedIn gibt es ein Developer Insights Team, das Entwicklerproduktivität und -zufriedenheit misst und Erkenntnisse an den Rest der Organisation weitergibt
LinkedIn erfasst Kennzahlen über vierteljährliche Umfragen, ein Echtzeit-Feedback-System und systembasierte Metriken
- Vierteljährliche Umfragen:
  - Das Developer-Insights-Team bewertet über vierteljährliche Umfragen die Developer Experience über verschiedene Tools, Prozesse und Aktivitäten hinweg
  - Die Umfragen enthalten etwa 30 Fragen und können von Entwicklern in ungefähr 10 Minuten beantwortet werden
  - Die Umfragen werden über eine proprietäre Plattform bereitgestellt, die vom Developer-Insights-Team entwickelt und betrieben wird; auf Basis von Daten aus dem Echtzeit-Feedback- und Kennzahlensystem lassen sich die Fragen weitreichend anpassen und personalisieren
- Echtzeit-Feedback-System:
  - Um zwischen den vierteljährlichen Umfragen Feedback zu sammeln, hat LinkedIn ein Echtzeit-Feedback-System entwickelt, das Ereignisse und Aktivitäten verfolgt, die Entwickler in ihren Entwicklungstools ausführen, und auf Basis bestimmter Trigger gezielte Umfragen versendet
  - Das System verwendet einen intelligenten Throttling-Mechanismus, damit Entwickler nicht mit Feedback-Anfragen überhäuft werden
- Systembasierte Metriken:
  - LinkedIn verwendet außerdem Systemdaten, um Kennzahlen zu berechnen, und erhält so hochpräzise Messwerte zu Dingen wie Build-Zeiten und Deployment-Häufigkeit
  - Das Developer-Insights-Team betreibt ein globales System zum Erfassen und Analysieren dieser Daten, das als Developer Insights Hub (oder iHub) bezeichnet wird
  - Über dieses System können alle Teams bei LinkedIn benutzerdefinierte Dashboards und Metriken passend zu ihren Anforderungen erstellen
LinkedIn berücksichtigt sowohl qualitative als auch quantitative Kennzahlen
- Developer Net User Satisfaction (NSAT): Misst, wie zufrieden Entwickler insgesamt mit den Entwicklungssystemen von LinkedIn sind. Wird vierteljährlich gemessen
- Developer Build Time (P50 und P90): Misst in Sekunden, wie lange Entwickler während der Entwicklung darauf warten, dass Builds lokal abgeschlossen werden
- Code Reviewer Response Time (P50 und P90): Misst, wie lange Code Reviewer benötigen, um auf jedes Update eines Autors in einem Code Review zu reagieren (basierend auf Arbeitszeiten)
- Post-Commit CI Speed (P50 und P90): Misst in Minuten, wie lange jeder Commit benötigt, um die Continuous-Integration- (CI) Pipeline zu durchlaufen
- CI Determinism: Das Gegenkonzept zu Test-Flakiness. Gemeint ist die Wahrscheinlichkeit, dass das Ergebnis einer Test-Suite ein gültiges Resultat und kein Fehler ist
- Deployment Success Rate: Misst, wie häufig Deployments in die Produktionsumgebung erfolgreich sind
- Winsorisierte Mittelwerte (Winsorized Means): Eine Methode, Verbesserungen innerhalb von Metriken mit Ausreißern zu erkennen. Berechnet, indem die höchsten und niedrigsten Werte durch Zahlen näher an der Mitte ersetzt werden
- The Developer Experience Index: Eine spezielle Kennzahl, die LinkedIn Teams bereitstellt. Dieser Index ist ein zusammengesetzter Score auf Basis mehrerer Kennzahlen wie den oben genannten

4. Peloton

Peloton ist ein großes Unternehmen mit rund 3.000 bis 4.000 Mitarbeitenden, aber deutlich kleiner als LinkedIn
Pelotons Messansatz begann damit, qualitative Erkenntnisse über Umfragen zur Developer Experience zu gewinnen, die später zusammen mit quantitativen Kennzahlen verwendet wurden
Peloton misst Produktivität mit Fokus auf vier Kernbereiche: Engagement, Geschwindigkeit, Qualität und Stabilität
- Engagement: Entwicklerzufriedenheits-Score
- Velocity: Zeit bis zum ersten und zehnten PR für alle Neueinstellungen, Lead Time, Deployment-Häufigkeit
- Quality: Anteil von PRs mit weniger als 250 Zeilen, Line Coverage, Change Failure Rate
- Stability: Zeit bis zur Wiederherstellung eines Services
Die Umfrage zur Developer Experience, über die ein großer Teil dieser Kennzahlen gemessen wird, wird von Pelotons Team für Technical Enablement und Developer Experience geleitet, das Teil der Produktoperationsorganisation ist
Das Team für Technical Enablement und Developer Experience ist auch dafür verantwortlich, die Umfrageergebnisse zu analysieren und mit Führungskräften in der gesamten Organisation zu teilen

5. Scale-ups und kleinere Unternehmen

Mehrere Scale-up-Unternehmen wie Notion, Postman, Amplitude, GoodRx, Intercom und Lattice beschäftigen zwischen 100 und 1.000 Engineers
Diese Unternehmen konzentrieren sich auf „bewegliche Kennzahlen (Moveable Metrics)“
- Bewegliche Kennzahlen sind Kennzahlen, die Teams für Entwicklerproduktivität durch positiven oder negativen Einfluss ihrer Arbeit „bewegen“ können. Sie sind nützlich, um den eigenen Einfluss sichtbar zu machen
Häufige Kennzahlen
- Ease of Delivery (beweglich):
  - Die meisten Unternehmen messen Ease of Delivery, also ein qualitatives Maß dafür, wie leicht oder schwer Entwickler die Erledigung ihrer Arbeit empfinden
  - Mehrere DevProd-Leads sagen, dass dies die „North Star“-Kennzahl ihrer Arbeit ist, weil das Ziel ihrer Teams darin besteht, das Leben der Entwickler einfacher zu machen
  - Diese Kennzahl eignet sich auch gut, um Wirkung zu zeigen, weil sie sich vergleichsweise gut beeinflussen lässt
  - Aus theoretischer Sicht erfasst sie außerdem zentrale Aspekte der Developer Experience wie kognitive Belastung und Feedback-Loops
- Engagement
  - Erfasst wird auch Engagement, also wie interessiert und motiviert Entwickler ihre Arbeit erleben
  - In der Regel wird Engagement über HR-Umfragen gemessen, aber auch DevProd-Teams fokussieren sich aus diesen Gründen darauf
  - Entwickler-Engagement und Produktivität hängen eng zusammen; frei nach dem Motto „glückliche Entwickler sind produktive Entwickler“ kann Entwickler-Engagement als Indikator für Produktivität gesehen werden
  - Der eigentliche Vorteil der Engagement-Messung besteht darin, dass sie andere, geschwindigkeitsorientierte Kennzahlen ausbalancieren kann. Software schneller auszuliefern ist gut, aber nicht auf Kosten sinkender Zufriedenheit der Entwickler
- Time Loss (beweglich)
  - GoodRx und Postman achten auf den durchschnittlichen Zeitverlust
  - Dieser wird als Anteil der Zeit von Entwicklern gemessen, die durch Hindernisse in ihrer Arbeitsumgebung verloren geht
  - Diese Kennzahl ähnelt Ease of Delivery insofern, als sie eine bewegliche Kennzahl liefert, auf die das Dev-Team direkt Einfluss nehmen kann
  - Ein großer Vorteil ist, dass sie sich in Kosten übersetzen lässt und daher von Business-Führungskräften leicht zu verstehen ist
  - Wenn etwa in einer Organisation mit 10 Millionen Dollar Engineering-Personalkosten der Zeitverlust durch eine Initiative von 20 % auf 10 % sinkt, entspricht das einer Kostenersparnis von 1 Million Dollar
- Change Failure Rate
  - Dies ist eine der vier zentralen Kennzahlen des Forschungsprogramms DORA (DevOps Research and Assessment)
  - Sie ist eine Top-Level-Kennzahl, die von mehreren Unternehmen verfolgt wird, darunter Amplitude und Lattice
  - Das DORA-Team definiert die Change Failure Rate wie folgt:
  „Der Prozentsatz von Release-Änderungen in Produktion oder für Nutzer, die zu einer Beeinträchtigung des Services führen (z. B. Service-Ausfall oder Serviceunterbrechung) und anschließend eine Behebung erfordern (z. B. Hotfix, Rollback, Fix Forward, Patch).“

6. Interessante Erkenntnisse

DORA- und SPACE-Metriken werden selektiv genutzt, und alle Unternehmen verwenden sowohl qualitative als auch quantitative Messungen
- DORA: DevOps Research and Assessment
- SPACE: Satisfaction and wellbeing, Performance, Activity, Communication and collaboration, Efficiency and flow
Es gibt einen starken Fokus auf „Fokuszeit“, und Stripe sowie Uber teilten konkrete Kennzahlen wie „Anzahl der Tage mit ausreichend Fokuszeit“ und „wöchentliche Fokuszeit pro Engineer“
Ungewöhnliche Kennzahlen
- Adoption Rate (DoorDash, GoodRx, Spotify)
- Design Docs Generated per Engineer (Uber)
- Experiment Velocity (Etsy)
- Developer CSAT/NSAT (Chime, LinkedIn)

7. So wählen Sie Ihre eigenen Kennzahlen aus

Es empfiehlt sich, die Auswahl von Kennzahlen mit Googles Goals, Signals, Metrics (GSM) Framework zu leiten
Definieren Sie zuerst das Ziel des zu lösenden Problems, suchen Sie dann nach Signalen, die anzeigen, dass dieses Ziel erreicht wurde, und wählen Sie anschließend passende Kennzahlen aus
- Ziel definieren
  - Google: „Wir unterstützen Entwickler dabei, großartige Produkte schnell und einfach auszuliefern.“
  - Slack: „Wir schaffen für jeden Engineer eine reibungslose Entwicklungsumgebung.“
  - Stripe: „Wir machen Software Engineering einfacher.“
- Vom Ziel rückwärts arbeiten, um Top-Level-Kennzahlen zu definieren
  - Wie einfach ist es für Entwickler, Software auszuliefern? (Ease): Ease of Delivery, Deployment Lead Time, Build Failure Rate
  - Wie schnell liefern Entwickler Software aus? (Speed): Perceived Delivery Speed, Perceived Productivity
  - Wie hoch ist die Qualität der ausgelieferten Software? (Quality): Incident Frequency, Perceived Software Quality
Wenn Sie CTO, VPE oder Engineering Lead sind
- Der beste Rat ist, „das Problem neu zu rahmen (reframe the problem)“
- Wählen Sie Kennzahlen aus drei Bereichen
  - Business Impact
    - Warum muss das jetzt gebaut werden?
    - Wie generiert dieses Projekt Umsatz oder unterstützt Unternehmensziele?
    - Läuft dieses Projekt planmäßig oder verzögert es sich?
  - System Performance
    - Sind die Engineering-Systeme schnell und stabil?
    - Ist die Infrastruktur sicher und gut gewartet?
    - Sind Nutzer mit den verwendeten Services zufrieden?
  - Engineering-Effizienz
Die Kombination aus qualitativen und quantitativen Kennzahlen ist in allen Unternehmen ein gemeinsames Muster
- Lassen Sie sich von den verschiedenen Messgrößen inspirieren, die einzelne Unternehmen nutzen
- Je nach Prioritäten und Engineering-Kultur unterscheiden sich die Schwerpunkte bei den gemessenen Kennzahlen erheblich

1 Kommentare

demorier 2024-01-24

Seit dem früheren Artikel zu McKinsey hatte ich mich dafür interessiert; gut, dass es hier zusammengefasst und noch einmal in Erinnerung gerufen wurde.