Developer Experience Metriken

Lernziele

Nach dieser Lektion kannst du erklären, warum DORA-Metriken allein die Developer Experience nicht abbilden, was das SPACE-Framework und der DX-Core-4-Ansatz ergänzen und wie du System-Telemetrie mit Survey-Daten kombinierst. Du kannst eine Plattform-Roadmap aus Messdaten ableiten und kennst die Fallen, die DevEx-Messprogramme diskreditieren — allen voran Metriken als Leistungsbewertung einzelner Personen.

Das Problem: Die Plattform behauptet, sie hilft

Dein Team hat ein Portal gebaut, Self-Service-Provisioning eingeführt, Golden Paths versioniert. Im nächsten Budget-Review fragt die Geschäftsführung: Hat sich das gelohnt? „Die Entwickler sind zufriedener” ist keine Antwort, die eine zweite Finanzierungsrunde trägt. Und intern ist die Lage genauso vage: Ist die Onboarding-Zeit wirklich gesunken? Welcher Pain Point sollte als Nächstes auf die Roadmap?

Ohne Messung wird die Plattform-Roadmap von den lautesten Stimmen bestimmt — und Platform as a Product (Lektion 2) bleibt ein Slogan. Developer-Experience-Metriken sind das Gegenstück zur Produkt-Haltung: Sie machen aus „wir glauben” ein „wir wissen”. Die Schwierigkeit: Entwicklungsarbeit ist kein Fließband, und naive Messung (Lines of Code, Anzahl Commits) misst Aktivität statt Wirkung.

DORA: notwendig, aber nicht hinreichend

Der etablierte Startpunkt sind die vier DORA-Metriken aus der State-of-DevOps-Forschung: Deployment Frequency (wie oft deployt ihr?), Lead Time for Changes (Commit bis Produktion), Change Failure Rate (Anteil der Deployments, die Incidents auslösen) und Time to Restore (wie schnell ist ein Ausfall behoben?). Ihre Stärke: Sie sind aus Systemdaten automatisierbar (Git, CI, Incident-Tooling), sie balancieren Tempo gegen Stabilität, und die Forschung dahinter zeigt, dass gute Werte mit Unternehmenserfolg korrelieren.

Ihre Grenze ist genauso wichtig: DORA misst die Delivery-Pipeline, nicht die Erfahrung davor. Ein Team kann täglich deployen und trotzdem an einer 40-Minuten-Local-Build-Zeit, flakigen Tests und unauffindbarer Doku verzweifeln. Außerdem sind DORA-Metriken Team- bzw. Service-Metriken — auf einzelne Personen heruntergebrochen werden sie sinnlos und schädlich.

SPACE und DX Core 4: das vollständigere Bild

Das SPACE-Framework (Forsgren, Storey u. a.) erweitert den Blick auf fünf Dimensionen: Satisfaction & Well-being, Performance, Activity, Communication & Collaboration, Efficiency & Flow. Die Kernaussagen für die Praxis: Erstens gibt es die eine Produktivitätsmetrik nicht — wähle Metriken aus mehreren Dimensionen. Zweitens gehören wahrgenommene Größen (Zufriedenheit, empfundene Reibung) gleichberechtigt neben Systemdaten, denn vieles, was Entwickler bremst, taucht in keinem Log auf: Kontextwechsel, unklare Anforderungen, Meeting-Zerstückelung.

DX Core 4 (von den DORA/SPACE-Forschern um Abi Noda und Nicole Forsgren) destilliert das in vier praxistaugliche Kennzahlen: Speed (z. B. Lead Time), Effectiveness (ein Developer Experience Index aus Survey-Fragen), Quality (z. B. Change Failure Rate) und Impact (Anteil der Zeit, die in neue Features statt in Reibung und Wartung fließt). Das Muster dahinter solltest du dir merken, unabhängig vom Framework-Namen: Telemetrie und Befragung kombinieren, mehrere Dimensionen gegeneinander balancieren.

Für die Plattform kommen produkt-spezifische Metriken dazu:

• Adoption: Wie viele Teams nutzen den Golden Path freiwillig? (Erzwungene Nutzung zählt nicht als Signal.)
• Time to First Deployment / Onboarding-Zeit: Tage vom ersten Arbeitstag bzw. Projektstart bis zum ersten produktiven Deployment — die ehrlichste Einzelmetrik für Plattform-Wirkung.
• Ticket-Volumen pro Capability: Wo Self-Service existiert, sollten Tickets messbar sinken; tun sie es nicht, wird der Self-Service umgangen.

Surveys, die Entwickler nicht hassen

Der Survey ist das Instrument für alles Wahrgenommene — und wird trotzdem oft schlecht gemacht. Was sich bewährt hat:

Kurz und regelmäßig statt lang und jährlich. Ein quartalsweiser Survey mit 10–15 Fragen schlägt den jährlichen 80-Fragen-Marathon, weil er Trends zeigt und die Teilnahmequote hält. Kernformat: Aussagen mit Zustimmungsskala („Ich finde die Dokumentation, die ich brauche”, „Lokales Bauen und Testen ist schnell genug”) plus ein bis zwei Freitextfragen („Was hat dich diese Woche am meisten aufgehalten?”).

Reibungspunkte abfragen, nicht Zufriedenheit im Allgemeinen. „Wie zufrieden bist du?” liefert ein Gefühl; „Wie viel Zeit hast du letzte Woche durch Warten auf CI verloren?” liefert eine Priorität.

Ergebnisse zurückspielen. Die Abbruchkante jedes Survey-Programms ist der zweite Durchlauf, wenn auf den ersten nichts folgte. Jede Runde braucht eine sichtbare Antwort: „Ihr habt CI-Wartezeiten als Top-Problem genannt — wir haben Runner verdoppelt, Median-Buildzeit von 18 auf 7 Minuten.”

Damit schließt sich der Kreis zur Roadmap: Survey nennt die Top-3-Reibungen, Telemetrie quantifiziert sie (wie viele Personenstunden stecken in CI-Wartezeit?), die Plattform priorisiert das größte Produkt aus Schmerz × Verbreitung, und die nächste Messung prüft die Wirkung. Das ist datengetriebene Plattform-Roadmap — keine Wunschliste, keine Lautstärke-Demokratie.

Praxis: ein minimales DevEx-Dashboard

Baue für deine Organisation (oder ein fiktives Szenario mit 20 Teams) ein Mess-Setup auf einem Blatt Papier plus einem Skript:

1. Vier Metriken auswählen — je eine aus Speed, Quality, Adoption und Wahrnehmung. Definiere für jede: Datenquelle, Erhebungsfrequenz, und wer sie sehen soll.
2. Lead Time aus Git ziehen — als Startpunkt reicht die Zeit vom Merge bis zum Deployment-Tag:

# Median der Zeit zwischen Merge-Commit und zugehörigem Release-Tag
git log --merges --since="30 days ago" --format="%H %ct" main | head -20
# je Commit: Zeitstempel des nächsten erreichbaren Tags vergleichen
git describe --contains <commit-hash>

3. Survey entwerfen: Formuliere acht Aussagen-Items entlang deiner größten Vermutungen über Reibung (Build-Zeiten, Doku, Provisioning, On-Call) plus eine Freitextfrage. Prüfe jedes Item: Würde eine schlechte Antwort zu einer konkreten Maßnahme führen? Wenn nein, streichen.
4. Anti-Missbrauchs-Regel formulieren: Schreibe in einem Satz auf, was mit den Daten nicht passieren darf (Personenvergleich, Team-Ranking) — und wo das dokumentiert wird.

Typische Stolperfallen

Metriken als Leistungsbewertung: Sobald eine DevEx-Metrik in Personalentscheidungen einfließt, wird sie gegamt und ist als Messinstrument tot (Goodharts Gesetz). DevEx-Daten gehören aggregiert auf Team- oder Plattform-Ebene und dienen der Verbesserung von Systemen, nicht der Bewertung von Menschen.

Nur messen, was leicht zu messen ist: Commits, PR-Anzahl und Story Points sind verfügbar, aber bedeutungsarm. Die wichtigsten Bremsen — Wartezeiten, Kontextwechsel, unklare Ownership — erreichst du nur über Befragung.

Dashboard ohne Konsequenz: Ein Grafana-Board, das niemand in Roadmap-Entscheidungen zitiert, ist Dekoration. Jede Metrik braucht einen Entscheidungs-Kontext: Wer schaut wann darauf und was ändert sich bei welchem Wert?

Einmal-Messung als Wahrheit: Eine einzelne Lead-Time-Zahl ohne Trend und ohne Segmentierung (nach Team, Service-Typ, Pfad) verleitet zu falschen Schlüssen. Interessant sind Veränderungen und Ausreißer, nicht Absolutwerte.

Interview-Vorbereitung

Auf „Wie misst du den Erfolg einer Plattform?” antwortest du geschichtet: Warum messen (Roadmap-Priorisierung und Investitions-Nachweis statt Bauchgefühl) → Was (DORA für Delivery, SPACE/DX Core 4 als Erinnerung an Wahrnehmungsdimensionen, plattformspezifisch Adoption und Onboarding-Zeit) → Wie (Telemetrie plus regelmäßige Kurz-Surveys, kombiniert) → Leitplanke (niemals Individualbewertung, sonst Goodhart).

Wahrscheinliche Follow-ups:

• „Welche eine Metrik würdest du wählen, wenn du nur eine haben dürftest?” — Time to First Deployment für ein neues Team/einen neuen Service: Sie integriert fast alle Plattform-Capabilities. Dann anmerken, dass Einzelmetriken grundsätzlich manipulierbar sind.
• „Warum reichen DORA-Metriken nicht?” — sie messen die Pipeline, nicht die Reibung davor (Builds, Doku, Provisioning, Kontextwechsel); dafür braucht es Wahrnehmungsdaten.
• „Wie verhinderst du, dass Metriken gegamt werden?” — Aggregation statt Personenbezug, mehrere balancierte Dimensionen statt einer Zielzahl, Metriken zur Systemverbesserung statt zur Bewertung deklarieren und das auch durchhalten.
• „Survey-Müdigkeit — was tust du dagegen?” — kurz halten, Kadenz begrenzen, und vor allem: sichtbare Maßnahmen aus jeder Runde, sonst sinkt die Teilnahme zu Recht.

Zusammenfassung

DevEx-Messung kombiniert zwei Datenwelten: System-Telemetrie (DORA, Adoption, Onboarding-Zeit) für das Objektivierbare und regelmäßige Kurz-Surveys für die Reibung, die in keinem Log steht — SPACE und DX Core 4 liefern den Rahmen, der beide Welten balanciert. Die Daten gehören aggregiert, dienen der Roadmap-Priorisierung und müssen strikt von Personalbewertung getrennt bleiben, sonst zerstört Goodharts Gesetz das Messsystem.

Gemessene Reibung zeigt oft auf dieselbe Wurzel: ein unklares Interface zwischen Plattform und Teams. Wie man dieses Interface als API mit echtem Vertrag designt, ist Thema der nächsten Lektion.