Nach dem Copilot-Rollout: welche vier Zahlen zeigen, ob es wirklich besser geworden ist
Nach einem Rollout wird in der Regel das gemessen, was das Werkzeug anzeigt: wie viele Vorschläge angenommen wurden, wie viele Zeilen entstanden sind. Beides sind Aktivitätszahlen. Sie steigen zuverlässig und sagen nichts darüber, ob die Organisation schneller oder sicherer geworden ist.
Akzeptanzraten und Zeilenzahlen sind Aktivitätsmaße. Wirkung zeigen vier Zahlen: Vorlaufzeit einer Änderung bis zur Auslieferung, Änderungsfehlerrate, Wiederherstellungszeit nach einem Vorfall und Reviewtiefe (Änderungsgröße im Verhältnis zur Reviewdauer). Die fünfte und wichtigste ist der Anteil der Änderungen, die ohne menschliches Review auskommen, bei stabiler Fehlerrate. Ausgangswerte müssen vor dem Rollout erhoben werden.
Zahl 1: Vorlaufzeit für eine Änderung
Von der ersten Zeile bis zur produktiven Auslieferung. Wenn die Erzeugung schneller wird, die Vorlaufzeit aber gleich bleibt, hat sich der Engpass verschoben und liegt jetzt woanders — meist beim Review oder bei der Freigabe. Diese eine Zahl beantwortet die Frage, ob der Gewinn überhaupt beim Kunden ankommt.
Zahl 2: Änderungsfehlerrate
Der Anteil der Auslieferungen, die eine Korrektur nach sich ziehen. Steigt diese Zahl nach dem Rollout, wird schneller etwas ausgeliefert, das nicht hält. Das ist kein Argument gegen die Werkzeuge, sondern eines für die Prüfmechanismen — und es ist die Zahl, die eine Geschäftsführung am schnellsten versteht.
Zahl 3: Wiederherstellungszeit
Wie lange dauert es, einen Fehler im Betrieb zu beheben? Diese Zahl ist besonders aussagekräftig, weil sie zeigt, ob die Organisation ihren eigenen Code noch versteht. Steigt sie, ohne dass die Systeme komplexer geworden sind, ist das ein frühes Warnsignal für einen Bestand, der schneller wächst als das Verständnis darüber.
Zahl 4: Reviewtiefe
Änderungsgröße im Verhältnis zur Reviewdauer. Diese Zahl steht in jedem gängigen Werkzeug und wird fast nie ausgewertet. Sie zeigt den Übergang vom Prüfen zum Durchwinken früher als jede andere — und zwar bevor er in der Fehlerrate sichtbar wird.
Die fünfte Zahl, die meistens fehlt
Der Anteil der Änderungen, die ohne menschliches Review auskommen, weil automatische Prüfungen ausreichen. Diese Zahl ist das eigentliche Ziel: Sie soll steigen, während die Änderungsfehlerrate stabil bleibt. Genau diese Kombination ist der Beweis, dass ein Engineering-Modell funktioniert — und ohne sie bleibt jede Diskussion über Quality Gates eine Glaubensfrage.
Der Fehler bei der Messung
Nach dem Rollout zu beginnen. Ohne Ausgangswerte lässt sich später nichts belegen, und die Zahlen der Vormonate sind in der Regel noch verfügbar. Zwei Stunden Auswertung vor dem Start ersparen die Diskussion, die ein Jahr später unweigerlich kommt.
Häufige Fragen
Warum ist die Reviewtiefe so aussagekräftig?
Weil sie den Übergang vom Prüfen zum Durchwinken zeigt, bevor er Folgen hat. Wenn die durchschnittliche Änderungsgröße steigt und die Reviewdauer gleich bleibt oder sinkt, ist die Prüfung faktisch aufgegeben worden — formal aber weiterhin dokumentiert.
Was tun, wenn keine Ausgangswerte existieren?
Rückwirkend erheben, soweit die Daten reichen. Ticketsystem und Versionsverwaltung enthalten in der Regel genug Historie für Vorlaufzeit und Fehlerrate. Was fehlt, ist meist die Reviewtiefe — die lässt sich aber ab sofort messen und nach drei Monaten sinnvoll auswerten.
Sind die DORA-Kennzahlen für jede Organisation sinnvoll?
Die Definitionen sind es, die Zielwerte nicht. Ein Vergleich mit Branchenwerten führt selten weiter; der Vergleich mit dem eigenen Vorjahr fast immer. Entscheidend ist eine stabile Definition, nicht ein hoher Rang in einer fremden Skala.
Wie oft sollte man auswerten?
Monatlich reicht für die Steuerung, quartalsweise für die Berichterstattung. Häufiger zu messen erzeugt Rauschen; seltener verpasst man die Entwicklung, um die es geht.
Rechnen Sie Ihre Review-Lücke aus.
Vierzehn Fragen, fünf Minuten. Ihre Zahlen, kein Login.
Engineering-Check starten →
