Softwareentwicklung produziert Datenspuren: Commits im Versionsverwaltungssystem, Tickets im Projekttool, Laufzeiten der Build-Pipeline, Kommentare in Code-Reviews. Unter dem Begriff Developer Analytics werden diese Spuren ausgewertet, um Aussagen über die Arbeit von Entwicklungsteams zu treffen. Der Reiz liegt auf der Hand: Wer ein Budget verantwortet, möchte belegen können, was daraus entsteht.

Der Haken ist ebenso naheliegend. Falsch angewendet erzeugen solche Auswertungen eine Atmosphäre der Beobachtung — und liefern zugleich Ergebnisse, die in die Irre führen. Beides zusammen ist die schlechteste aller Kombinationen: Das Team fühlt sich kontrolliert, und die Kontrolle misst nicht einmal das Richtige.

Warum Einzelkennzahlen so oft täuschen

Die verfügbaren Zahlen sind meist Aktivitätsdaten, nicht Ergebnisdaten. Sie zeigen, dass etwas passiert ist, nicht ob es der Sache genutzt hat. Eine hohe Zahl an Commits kann für kleinteiliges, gut nachvollziehbares Arbeiten sprechen — oder für Unsicherheit und viele Korrekturen. Wenige geänderte Codezeilen können ein Zeichen von Stillstand sein oder das Ergebnis einer Woche Analyse, die am Ende in einer eleganten, kurzen Lösung mündet.

Dazu kommt der Effekt, den jede veröffentlichte Kennzahl auslöst: Sobald klar ist, worauf geschaut wird, verändert sich das Verhalten in Richtung der Messung. Aufgaben werden kleiner geschnitten, damit mehr Tickets im Sprint erscheinen. Reviews werden schneller abgenickt, weil die Durchlaufzeit als Ziel gilt. Refactoring, Dokumentation und das Aufräumen technischer Altlasten tauchen in keiner dieser Zahlen positiv auf — und werden entsprechend seltener gemacht.

KI-Assistenten verschieben die Maßstäbe

Mit dem breiten Einsatz von KI-Coding-Assistenten wird das Problem größer, nicht kleiner. Wenn ein erheblicher Teil des geschriebenen Codes maschinell vorgeschlagen wird, verliert die Menge an Code als Indikator jede Aussagekraft. Gleichzeitig verschiebt sich die eigentliche Leistung: Sie liegt zunehmend im Prüfen, Einordnen und Verwerfen von Vorschlägen, im Verstehen bestehender Systeme und im Treffen von Architekturentscheidungen.

Genau diese Tätigkeiten hinterlassen kaum Datenspuren. Ein Entwickler, der einen Vorschlag des Assistenten als riskant erkennt und verwirft, produziert im Log nichts — verhindert aber möglicherweise wochenlange Fehlersuche. Wer weiterhin Output zählt, belohnt in diesem Umfeld das Übernehmen und bestraft das Prüfen.

Vom Individuum zum Ablauf

Der wichtigste Unterschied in der Praxis ist die Ebene der Betrachtung. Kennzahlen auf Personenebene erzeugen Rechtfertigungsdruck und laden zu Vergleichen ein, die fachlich nicht tragen — schon weil Aufgaben unterschiedlich schwer sind. Kennzahlen auf Ebene des Ablaufs stellen dagegen eine andere Frage: Wo bleibt Arbeit liegen, und warum?

Typische Beobachtungen aus dieser Perspektive sind gut nutzbar:

  • Wartezeiten statt Arbeitszeiten: Wie lange liegt ein Änderungspaket im Review, bevor sich jemand kümmert? Wie lange dauert es von der fertigen Umsetzung bis zum Livegang?
  • Rückläufe: Wie oft muss eine Aufgabe erneut angefasst werden, weil Anforderungen unklar waren?
  • Stabilität: Wie häufig führen Releases zu Störungen, und wie schnell ist der Betrieb wieder normal?
  • Reibung in der Werkzeugkette: Wie lange braucht ein Build, wie oft schlagen Tests ohne echten Fehler an?

Diese Größen zeigen auf Engstellen im System, nicht auf Personen. Sie sind außerdem meist mit organisatorischen Mitteln zu verbessern — durch klarere Anforderungen, feste Review-Zeitfenster, schnellere Pipelines — und nicht dadurch, dass einzelne Menschen mehr arbeiten.

Zahlen brauchen einen Kontext

Kein Datensatz erklärt sich selbst. Eine gestiegene Durchlaufzeit kann an einer Urlaubsphase liegen, an einer besonders komplexen Komponente, an einer parallel laufenden Migration oder an einem Zulieferer, der Antworten schuldet. Wer solche Auswertungen ohne Rückfrage interpretiert, kommt fast zwangsläufig zu falschen Schlüssen.

Sinnvoll ist deshalb ein einfaches Vorgehen: Die Zahl liefert den Anlass für ein Gespräch, nicht das Urteil. Das Team kommentiert die Auffälligkeit, die Erklärung wird festgehalten, und daraus entsteht gegebenenfalls eine Maßnahme. Diese Reihenfolge entscheidet darüber, ob Analytics als Werkzeug oder als Überwachung erlebt wird.

Transparenz als Voraussetzung

Vertrauen entsteht nicht dadurch, dass nicht gemessen wird, sondern dadurch, dass klar ist, was gemessen wird. Dazu gehören einige Festlegungen, die man besser vor der Einführung trifft als danach:

  1. Welche Daten werden erhoben, und in welcher Aggregationsstufe?
  2. Wer sieht die Auswertungen, und wer nicht?
  3. Welche Entscheidungen dürfen ausdrücklich nicht auf diese Zahlen gestützt werden — etwa Beurteilungen einzelner Mitarbeitender?
  4. Wie werden die Kennzahlen wieder abgeschafft, wenn sie sich als nutzlos erweisen?

Der letzte Punkt wird oft übersehen. Dashboards neigen dazu, immer weiter zu wachsen, weil das Hinzufügen einer Kachel leicht ist und das Entfernen als Eingeständnis wirkt. Ein Kennzahlenset, das niemand mehr erklären kann, richtet mehr Schaden an als gar keines.

Was Auftraggeber wirklich wissen wollen

Hinter dem Wunsch nach Produktivitätszahlen steht meist eine andere, legitime Frage: Kommt das Projekt voran, und wo liegen die Risiken? Diese Frage lässt sich oft besser ohne Metrik beantworten — durch lauffähige Zwischenstände, durch eine ehrliche Liste offener Punkte, durch sichtbare Entscheidungen und deren Begründung.

Demonstrierbare Ergebnisse in kurzen Abständen sind das stärkste Vertrauenssignal, das ein Entwicklungsteam liefern kann. Kennzahlen ergänzen das sinnvoll, wo es um Trends über längere Zeiträume geht: Werden Releases zuverlässiger? Sinkt die Zeit, bis eine Änderung beim Nutzer ankommt? Nimmt die Zahl der Störungen ab?

Für Web- und Softwareprojekte heißt das: Messen Sie den Ablauf, nicht die Personen, und behandeln Sie jede Zahl als Ausgangspunkt für eine Rückfrage. Gerade weil KI-Assistenten die Menge an erzeugtem Code entkoppeln von der tatsächlichen Wertschöpfung, verlieren Output-Kennzahlen weiter an Bedeutung — während Durchlaufzeit, Stabilität und Nachvollziehbarkeit von Entscheidungen wichtiger werden. Wer diese Verschiebung im Vertrag und im Reporting berücksichtigt, bekommt belastbare Steuerungsinformationen und behält gleichzeitig ein Team, das offen über Probleme spricht.

Quellen