Ehrlich messen, selbst ausprobieren (Serienfinale)

Hinweis zu den Figuren

Miriam, Daniel, Jonas und der Bereichsleiter sind erfunden. In Folge eins stand Daniel stellvertretend für die Teilnehmenden der METR-Studie; ab Folge zwei ist er ein erfundener Kollege in Miriams Team und hat an der Studie nicht teilgenommen. Auch der Verlauf und die Ergebnisse von Miriams Versuch (die schwere Woche zwei, der kaputte Donnerstag, das Verständnisgespräch mit Daniel) sind erfunden; sie zeigen eine mögliche Auswertung, keine gemessenen oder typischen Werte. Ein echter Versuch kann ebenso keine Verbesserung oder eine Verschlechterung zeigen.

Der Versuch zum Mitnehmen

• Woche eins: nur zuschauen. Niemand ändert etwas, die Werkzeuge zeichnen auf, was sie erfassen; Arbeit außerhalb wird ergänzt, Überschneidungen nicht doppelt gezählt, Messlücken offengelegt. Ergebnis: ein Ausgangswert.
• Woche zwei und drei: Seitenwechsel (in der Forschung: Crossover-Design). Eine Person (oder Teamhälfte) arbeitet in Woche zwei mit der neuen Regel, die andere mit der alten; in Woche drei wird getauscht. Wie beim Fußball zur Halbzeit: So sind beide Regeln in beiden Wochen vertreten, und eine zufällig leichte oder schwere Woche hat weniger Einfluss. Vergleichbare Aufgaben und gemeinsame Prüfwarteschlangen (die Bedingungen können sich über gemeinsame Reviewer gegenseitig beeinflussen) müssen trotzdem berücksichtigt werden. Grenze: Lern- und Übertragungseffekte (wer eine Woche lang weniger gleichzeitig gemacht hat, verlernt es nicht über Nacht). Die Quelle empfiehlt, die Reihenfolge der Bedingungen zufällig und ausgeglichen zu verteilen.
• Woche vier: auswerten. Erfolgskriterium und Abbruchgrenzen vorher festlegen. Verteilung und Ausreißer ansehen, nicht nur Median oder Durchschnitt.
• Die neue Regel vollständig (aus Folge vier): eine komplexe Aufgabe, die ihr aktiv betreut, höchstens ein klar begrenzter, stiller Hintergrundjob, und eine feste Grenze für Änderungen, die auf Prüfung warten. Die alte Regel: so viel gleichzeitig, wie jeder will. Alles andere bleibt gleich, auch die Art, wie Reviews übergeben werden. In größeren Teams teilt man in zwei Hälften.
• Abbruchgrenzen, z. B. ein kritischer Fehler, deutlicher Verständnisverlust, eine wachsende Warteschlange. Einen allgemeingültigen Prozentwert für "Erfolg" gibt es nicht; jedes Team legt ihn selbst fest, aber vorher.
• Fairer Vergleich: nur Aufgaben ähnlicher Größe und ähnlichen Risikos miteinander vergleichen.
• Allein: eine Woche wie immer, eine Woche mit Grenze. Wer die Kraft-Skala aus Folge sieben geführt hat, hat die erste Woche schon. Im Büro: ein großes Dokument zur Zeit, Zeiten aus Kalender und Versionsverlauf.
• Vorher mit Betriebsrat und Datenschutz sprechen; nur aggregiert auf Teamebene auswerten, eine Zeile pro Änderung statt pro Name. Wer eine Änderung als "noch nicht verstanden" markiert, gilt deshalb nicht als unproduktiv. (Kein Rechtsrat.)

Das Armaturenbrett: eine Messgröße pro Anzeige

• Tacho = Minuten pro Änderung. In der Grundlage der Serie heißt die Größe "menschliche Aufmerksamkeitsminuten je akzeptierter Änderung" (HAMAC), ausdrücklich eine Arbeitshypothese. Gezählt wird nur menschliche Zeit (klären, erklären, eingreifen, prüfen, nachbessern). Details, die im Audio wegfallen: Es sind Personenminuten (zehn Minuten zu zweit = zwanzig Minuten); auch verworfene Versuche zählen mit, etwa ein Agentenlauf in die falsche Richtung, sonst verschwinden die teuersten Irrwege. "Fertig" (akzeptiert): Kriterien erfüllt, Prüfungen bestanden, ein Mensch übernimmt die Verantwortung. Eine fachlich zusammenhängende Änderung bleibt eine Einheit, auch wenn sie in mehrere Änderungsvorschläge zerlegt wird.
• Tankanzeige = die Kraft am Abend. Skala eins bis fünf, fünf = viel Kraft (wie in Folge sieben). Lokales Signal, keine Diagnose. NASA-TLX erfasst subjektive Arbeitsbelastung in sechs Dimensionen. Das ergänzt die Abendkraft-Skala, misst aber etwas anderes (siehe Quellen).
• Warnlampe = das Verständnisgespräch. Regelmäßig eine zufällig gezogene Änderung besprechen: Was ist der kritische Pfad? Was darf nie passieren? Was geschieht bei einem Fehlerfall, den kein Test abdeckt? Selbstvertrauen allein genügt nicht. Eine fachlich richtige Erklärung ist ein Hinweis auf Verständnis; das Gespräch ist ein vorgeschlagener Prüfversuch, kein validierter oder vollständiger Nachweis.
• Weitere sinnvolle Signale (im Audio weggelassen): Nacharbeit, also wie oft eine Änderung wieder aufgeht und was die Reparatur kostet. DORA zählt seit 2024 etwas Ähnliches als fünfte Kennzahl, die Deployment Rework Rate (ungeplante Auslieferungen infolge eines Produktionsvorfalls); sie beginnt später als interne Nacharbeit. Und Qualität: Den schweren Vorfall in Miriams erfundenem Versuch prüft das Team gegen die vorher vereinbarte Abbruchregel, bevor es weitermacht; er bleibt Teil der Qualitätsbilanz. Über seltene Fehler erlaubt ein so kurzer Versuch keine verlässliche Aussage.
• Warum mehrere Anzeigen: Das SPACE-Rahmenwerk (Microsoft Research, GitHub, Universität Victoria) beschreibt Produktivität in fünf Dimensionen (von Zufriedenheit und Wohlbefinden über Leistung, Aktivität, Kommunikation und Zusammenarbeit bis Effizienz und Arbeitsfluss) und empfiehlt wenige Kennzahlen aus mindestens drei Dimensionen, bewusst in Spannung zueinander, mit mindestens einer Wahrnehmungsmessung, und Auswertung nur aggregiert auf Teamebene. Auch DORA warnt, die Kennzahlen zu Zielvorgaben zu machen oder Teams gegeneinander antreten zu lassen.
• Gefühl und Folge eins: Das Gefühl ist ein schlechter Tacho (deshalb dokumentierte Zeiten aus Werkzeugen, ergänzt um Tätigkeiten außerhalb und mit offengelegten Messlücken), aber eine brauchbare Tankanzeige (deshalb Kraft und Verständnis von den Menschen selbst).

Werkzeug-Tipp: Zeiten automatisch erheben

• Claude Code Monitoring über den offenen Standard OpenTelemetry: Aktivierung mit der Umgebungsvariable CLAUDE_CODE_ENABLE_TELEMETRY=1 plus Exporter-Konfiguration (standardmäßig aus). Die Metrik claude_code.active_time.total misst aktive Zeit in Sekunden, mit dem Attribut type = user (Tastatureingaben) oder cli (Werkzeugausführung und KI-Antworten). Weitere Metriken u. a. für Sitzungen, Commits und Pull Requests. https://code.claude.com/docs/en/monitoring-usage
• Hinweis: Ein Zeitstempel misst gebundene Zeit, nicht Aufmerksamkeit oder Belastung. Claude Code erfasst aktive Nutzung nur in seiner eigenen Oberfläche. Git liefert Commit-Zeitpunkte, Reviews stehen im Pull-Request-System (z. B. über gh). Zusammen mit dem Kalender ergibt das noch keine vollständigen aktiven Personenminuten: Arbeit außerhalb ergänzen, Überschneidungen nicht doppelt zählen, Messlücken offenlegen. Fehler können in beide Richtungen gehen.

Sich nicht selbst täuschen (im Audio gekürzt)

• Beobachtung verändert Verhalten. Wer weiß, dass gemessen wird, arbeitet vielleicht aufmerksamer. Die berühmte Fabrikgeschichte dazu (Hawthorne-Effekt) ist allerdings wackliger als ihr Ruf, siehe Levitt und List.
• Kleine Zahl. Zwanzig Aufgaben einer Person sind keine zwanzig unabhängigen Versuchspersonen. Das Ergebnis ist ein Lernsignal für dieses Team.
• Auch große Versuche bleiben vorsichtig. Bei Google bekamen 96 Entwickler, zufällig mit oder ohne KI-Werkzeuge, dieselbe anspruchsvolle Aufgabe; mit KI nach bester Schätzung etwa ein Fünftel weniger Zeit, die Autoren betonen große Unsicherheit und eingeschränkte Übertragbarkeit.
• Ersparnis nicht sofort in mehr Output umwandeln. Bei gleichem tatsächlichem Durchsatz und stabilen Mittelwerten bedeutet mehr Arbeit im System eine längere mittlere Durchlaufzeit (Gesetz von Little, Folge vier).
• Goodhart im Original. Charles Goodhart schrieb Mitte der Siebzigerjahre über Geldpolitik: Eine statistische Regelmäßigkeit bricht gern zusammen, sobald man sie zur Steuerung benutzt. Die bekannte Kurzform stammt von Marilyn Strathern.

Quellen

Grundlage der Serie

• Healthy AI First Software Development, Fassung 2 (01.10.2026), Kap. 12 bis 17: Teampraktiken, typische Fehlentwicklungen, Messrahmen, Experimente über zwei bis vier Wochen, Vorlagen, offene Forschungsfragen. Die Messgröße "menschliche Aufmerksamkeitsminuten je akzeptierter Änderung" (HAMAC) ist dort ausdrücklich eine Arbeitshypothese, kein etablierter Standard.

Kennzahl und Ziel

• Goodhart, C. (1975): Problems of Monetary Management: The U.K. Experience. Papers in Monetary Economics, Reserve Bank of Australia. Überblick und Originalwortlaut: https://en.wikipedia.org/wiki/Goodhart%27s_law
• Strathern, M. (1997): "Improving ratings": audit in the British University system. European Review 5(3), 305-321. Quelle der bekannten Kurzform "When a measure becomes a target, it ceases to be a good measure." https://www.cambridge.org/core/journals/european-review/article/improving-ratings-audit-in-the-british-university-system/FC2EE640C0C44E3DB87C29FB666E9AAB

Messrahmen (im Audio nicht mehr namentlich genannt)

• Forsgren, Storey, Maddila, Zimmermann, Houck, Butler (2021): The SPACE of Developer Productivity. ACM Queue 19(1). https://queue.acm.org/detail.cfm?id=3454124
• DORA: Software delivery performance metrics (fünf Kennzahlen inkl. Deployment Rework Rate; Warnung vor Zielvorgaben unter Verweis auf Goodhart, kein Wettbewerb zwischen Teams). https://dora.dev/guides/dora-metrics/
• DORA: History of the metrics. Deployment Rework Rate kam 2024 als fünfte Kennzahl hinzu. https://dora.dev/insights/dora-metrics-history/
• Mehr dazu: Noda, Storey, Forsgren, Greiler (2023): DevEx: What Actually Drives Productivity. ACM Queue. https://queue.acm.org/detail.cfm?id=3595878

Belastung messen (NASA-TLX, subjektive Arbeitsbelastung)

• Hart, S. G. (2006): NASA-Task Load Index (NASA-TLX); 20 Years Later. Sechs Dimensionen, Raw TLX als ungewichtete Variante. https://doi.org/10.1177/154193120605000909
• NASA Human Systems Integration Division: NASA TLX. https://www.nasa.gov/human-systems-integration-division/nasa-task-load-index-tlx/

Sich nicht selbst täuschen

• Levitt, S. D. & List, J. A. (2011): Was There Really a Hawthorne Effect at the Hawthorne Plant? American Economic Journal: Applied Economics 3(1). https://www.nber.org/papers/w15016
• Paradis, E. et al. (2024): How much does AI impact development speed? An enterprise-based randomized controlled trial. 96 Google-Softwareentwickler, beste Schätzung etwa 21 Prozent weniger Zeit, großes Konfidenzintervall. https://arxiv.org/abs/2410.12944

Mitbestimmung und Datenschutz

• § 87 Abs. 1 Nr. 6 Betriebsverfassungsgesetz: Mitbestimmung bei "Einführung und Anwendung von technischen Einrichtungen, die dazu bestimmt sind, das Verhalten oder die Leistung der Arbeitnehmer zu überwachen". Nach ständiger Rechtsprechung des Bundesarbeitsgerichts genügt die objektive Eignung zur Überwachung. https://www.gesetze-im-internet.de/betrvg/__87.html

Offene Fragen

• Warm, J. S., Parasuraman, R. & Matthews, G. (2008): Vigilance Requires Hard Mental Work and Is Stressful. Human Factors 50(3), 433-441. https://doi.org/10.1518/001872008X312152

Rückbezug auf Folge 1

• Becker, Rush, Barnes, Rein / METR (2025): Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. 16 Entwickler; erwartet 24 Prozent schneller, gemessen 19 Prozent langsamer, hinterher geschätzt 20 Prozent schneller. https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/