Nützlicher Journalismus, um Unternehmen zu verstehen, zu führen und weiterzuentwickeln.
SuchenEin Leitfaden zur Interpretation von Kennzahlen zu Arbeitsfluss, Produktivität, Qualität und Geschäftsergebnissen – und dazu, sie zu kombinieren, ohne Aktivität mit Wert zu verwechseln.
Kennzahlen zur Softwareentwicklung machen Fortschritte sichtbar, helfen Engpässe zu erkennen und Verbesserungen gezielt anzugehen. Es gibt keine einzelne Kennzahl, die die Leistung eines Teams umfassend beschreibt: Je nachdem, welche Frage beantwortet werden soll, empfiehlt es sich, Messwerte zu Arbeitsfluss, Qualität und Geschäftsergebnissen zu kombinieren.
Ein einzelner Wert kann irreführend sein. Mehr Code zu liefern, beweist zum Beispiel nicht, dass dadurch mehr Wert geschaffen wurde, und eine höhere Testabdeckung garantiert nicht, dass das Produkt frei von Fehlern ist. Definitionen, Messzeitraum und Kontext sollten einheitlich bleiben, damit Vergleiche aussagekräftig sind.
Sie bezeichnet die Zeitspanne vom Anfordern oder Beginnen einer Arbeit bis zu ihrer Auslieferung. Der genaue Start- und Endpunkt wird je nach Organisation unterschiedlich festgelegt; deshalb sollte man sich darauf verständigen, bevor Ergebnisse verglichen werden. Die Beobachtung der Lead Time hilft, Verzögerungen zwischen einzelnen Phasen zu erkennen und einzuschätzen, wie lange das Team benötigt, um Änderungen denjenigen bereitzustellen, die sie brauchen.
Sie misst, wie lange ein Arbeitselement vom Beginn der Entwicklung durch das Team bis zu seiner Fertigstellung benötigt. Anders als die Lead Time schließt sie die Wartezeit vor Arbeitsbeginn üblicherweise aus. Wenn sie steigt, kann es sinnvoll sein, Blockaden, Abhängigkeiten oder die Größe der Aufgaben zu untersuchen, statt das Ergebnis automatisch der individuellen Geschwindigkeit einzelner Entwickler zuzuschreiben.
In Scrum und anderen agilen Frameworks bezeichnet die Velocity üblicherweise die Story Points oder die geschätzte Arbeit, die ein Team während eines Sprints abschließt. Sie dient intern als Planungsgrundlage; sie ist keine universelle Produktivitätseinheit. Die Punkte hängen von der Schätzskala des jeweiligen Teams ab, weshalb ein Vergleich der Velocity zwischen Teams irreführend sein kann. Veränderungen können außerdem durch Anpassungen des Umfangs, der Teamzusammensetzung oder der Schätzmethode entstehen.
WIP (work in progress) bezeichnet die Anzahl begonnener, aber noch nicht abgeschlossener Aufgaben. Die Beobachtung dieser Zahl hilft, Arbeitsstaus und zu viele gleichzeitig bearbeitete Aufgaben zu erkennen. Ein hoher Wert kann mit häufigeren Kontextwechseln oder Wartezeiten einhergehen, erklärt für sich genommen aber nicht deren Ursache. Falls WIP-Limits verwendet werden, sollten sie an den Arbeitsfluss und die Bedürfnisse des Teams angepasst sein.
Sie gibt an, welcher Anteil des Codes entsprechend dem verwendeten Werkzeug und den festgelegten Kriterien durch automatisierte Tests ausgeführt wird. Die Kennzahl hilft, Bereiche mit geringer Abdeckung zu finden, misst aber nicht direkt, ob die Tests wichtige Verhaltensweisen überprüfen. Sie sollte zusammen mit Testergebnissen, erkannten Fehlern und den Risiken des Systems betrachtet werden.
Sie setzt die gefundenen Fehler zu einer Größen- oder Umfangseinheit in Beziehung, etwa einem Release oder einer Komponente. Für die Interpretation muss festgelegt werden, was als Fehler gilt, welche Einheit verwendet wird und über welchen Zeitraum Daten erfasst werden. Ohne stabile Kriterien sind Vergleiche der Fehlerdichte zwischen Produkten oder Teams möglicherweise wenig aussagekräftig.
Die Kennzahl beschreibt, wie viel Code innerhalb eines Zeitraums hinzugefügt, geändert oder entfernt wird. Ein hoher Churn kann auf häufige Änderungen, Nacharbeit oder Instabilität in bestimmten Bereichen hindeuten, beweist für sich genommen aber kein Problem: Er kann ebenso die aktive Weiterentwicklung des Produkts widerspiegeln. Es empfiehlt sich, die Kennzahl zusammen mit Fehlern, Code-Reviews und dem Kontext der Änderungen zu betrachten.
Sie schätzt die Anzahl unabhängiger Ausführungspfade in einem Codeabschnitt. Damit lassen sich Komponenten finden, die schwer zu testen oder zu warten sind. Sie ersetzt weder eine Designprüfung noch liefert sie isoliert eine umfassende Diagnose der Qualität.
Die Kennzahl zählt die Codezeilen – KLOC steht für Tausend Codezeilen – und kann als grober Anhaltspunkt für die Größe einer Codebasis dienen. Für die Bewertung der Produktivität ist sie nur eingeschränkt geeignet: Mehr Zeilen bedeuten nicht zwangsläufig mehr Funktionen oder bessere Software, und Vergleiche zwischen Programmiersprachen und Programmierstilen können unfair sein. Je nach Zweck können funktionale Kennzahlen wie Function Points aussagekräftiger sein; auch dafür sind jedoch einheitliche Messkriterien erforderlich.
Finanzielle und kaufmännische Kennzahlen ergänzen technische Messwerte, wenn das Team verstehen muss, wie das Produkt mit dem Geschäft zusammenhängt. Sie beschreiben weder für sich genommen die Codequalität noch die individuelle Leistung der Entwickler.
Der MRR (monthly recurring revenue) bezeichnet die monatlich wiederkehrenden Umsätze; der ARR (annual recurring revenue) gibt diese Umsätze auf Jahresbasis an. Die Berechnungsregeln – zum Beispiel der Umgang mit Tarifwechseln oder einmaligen Einnahmen – sollten einheitlich sein, damit sich Entwicklungen vergleichen lassen.
Die Kundenbindung gibt an, welcher Anteil der Kunden oder Umsätze über einen bestimmten Zeitraum erhalten bleibt. Churn bezeichnet je nach gewählter Definition den Verlust von Kunden oder Umsätzen. Wichtig ist, Kundenbindung – manchmal als Logo-Retention bezeichnet – von Umsatzbindung zu unterscheiden: Ein Unternehmen kann Kundenkonten behalten und dennoch Veränderungen bei den damit erzielten Beträgen verzeichnen.
Die NRR vergleicht die wiederkehrenden Umsätze einer Kundenkohorte mit den Umsätzen, die dieselbe Kohorte zu Beginn des Zeitraums erzielte, und berücksichtigt dabei die Änderungen gemäß der gewählten Methodik. Die konkrete Definition kann variieren; deshalb sollten der Zeitraum und die in die Berechnung einfließenden Bestandteile angegeben werden.
Der CAC schätzt die Kosten für die Gewinnung neuer Kunden, indem üblicherweise die Vertriebs- und Marketingausgaben eines Zeitraums mit den darin neu gewonnenen Kunden in Beziehung gesetzt werden. Die CAC-Amortisationsdauer schätzt, wie lange es dauert, genügend Bruttomarge zu erwirtschaften, um diese Kosten auszugleichen. Beide Kennzahlen hängen davon ab, welche Ausgaben und Kunden berücksichtigt werden. Deshalb sollten sie nicht ohne Prüfung ihrer Annahmen verglichen werden.
Der LTV schätzt den wirtschaftlichen Beitrag eines Kunden über die gesamte Geschäftsbeziehung hinweg; der ROI setzt das Ergebnis einer Investition ins Verhältnis zu ihren Kosten, gemäß der festgelegten Formel und dem definierten Zeithorizont. Es handelt sich um Geschäftskennzahlen, nicht um direkte Messwerte technischer Produktivität. Ihr Nutzen hängt von der Datenqualität und davon ab, dass die verwendeten Annahmen offengelegt werden.
Bevor eine Kennzahl in ein Dashboard aufgenommen wird, sollte vereinbart werden, welche Frage sie beantworten soll, wie sie berechnet wird, wer sie einsehen muss und wie oft sie überprüft wird. Hilfreich ist auch, sich ergänzende Messwerte zu kombinieren: So bietet es mehr Kontext, die Lieferzeit zusammen mit Fehlern und Kundenzufriedenheit zu beobachten, als nur die Geschwindigkeit zu betrachten.
Kennzahlen sollten Gespräche über das Arbeitssystem und Verbesserungsmöglichkeiten unterstützen und nicht automatisch zu individuellen Zielvorgaben werden. Im richtigen Kontext helfen sie bei der Planung, Ressourcenzuweisung und Risikoerkennung. Werden sie dagegen als Ersatz für fachliches Urteilsvermögen verwendet, können sie sichtbare Aktivität belohnen, ohne zu belegen, dass die Software nützlicher, zuverlässiger oder wartbarer ist.
Ein praktischer Leitfaden in drei Phasen, um das wöchentliche Meeting in einen Entscheidungsraum zu verwandeln. Lernen Sie, Ziele zu definieren, die Agenda zu verwalten und Vereinbarungen mit klaren Verantwortlichen und Fristen zu dokumentieren, um Drift zu vermeiden und die Produktivität des Teams zu maximieren.
Beitrag lesen
Die spezifische Fachsprache der Bauindustrie kann kostspielige Missverständnisse zwischen Bauteams, Verwaltung und Kunden verursachen. Dieses Glossar vereinheitlicht Schlüsselbegriffe aus Planung, Kalkulation, agilen Methoden und technischem Vokabular, um die Kommunikation und Effizienz bei der Projektausführung zu verbessern.
Beitrag lesen
Ein praktischer Leitfaden, um die Notfallplanung in echte operative Kapazität zu verwandeln: Abhängigkeiten kartieren, Entscheidungsschwellen definieren und alternative Routen validieren, bevor die Krise eintritt.
Beitrag lesen