Die 10x–100x-Regel: Was eine späte Korrektur wirklich kostet
Jeder „weiß“, dass es billiger ist, ein Problem früh zu beheben. Fast niemand weiß, wie viel billiger — und deshalb treffen Teams weiterhin die teure Wahl. Hier ist die Zahl, woher sie kommt und was man dagegen tut.
Die Kosten-zu-Beheben-Kurve
Barry Boehms Arbeiten zur Ökonomie des Software-Engineerings lieferten die klassischen Zahlen für die relativen Kosten der Behebung eines Fehlers in jeder Phase des Lebenszyklus. Ein Anforderungsfehler, der beim Schreiben der Anforderungen auffällt, kostet 1x. Derselbe Fehler, später entdeckt, kostet:
- Anforderungsphase — 1x (die Basis: ein Gespräch und ein Satz).
- Entwurf — 3–6x.
- Code — 10x.
- Test — 15–40x.
- Nach der Auslieferung — 100x oder mehr.
Warum der Multiplikator sich aufschaukelt
Die genauen Multiplikatoren schwanken je nach Studie, aber die Form ist konsistent und die Größenordnung unbestritten: Je später ein Fehler gefunden wird, desto exponentiell teurer ist seine Behebung.
Ein Anforderungsfehler ist kein isolierter Tippfehler. Er erzeugt Arbeit in jeder folgenden Phase. Die falsche Anforderung wird zum falschen Entwurf, der zu falschem Code, falschen Tests, falscher Dokumentation und einer falschen Erwartung in der Support-Warteschlange.
Wenn man ihn schließlich findet, repariert man nicht eine Zeile — man macht einen Baum von Entscheidungen rückgängig, die alle aus demselben falschen Samen gewachsen sind. Deshalb vervielfacht sich der Multiplikator, statt sich zu addieren.
Wie 100x in der Praxis aussieht
In der Anforderungsphase wird eine falsche Anforderung mit einem Satz und einer Stunde behoben. Dieselbe Anforderung, nach der Auslieferung entdeckt, wird zu: ein gestopptes Release, ein geplanter Patch, ein ausgeführtes Rollback, korrigierte Dokumentation, ein gebrieftes Support-Team und ein beruhigter Kunde — Wochen Arbeit über mehrere Teams hinweg, plus die Kosten dessen, was der Fehler in der freien Wildbahn angerichtet hat.
Das Geld ist nur die Hälfte. Die andere Hälfte ist die Gelegenheit: Solange das Team den Fehler rückgängig macht, baut es nichts Neues.
Der Hebel: Entdeckung nach links verschieben
Man kann nicht jede falsche Anforderung verhindern. Man kann aber den Moment der Entdeckung dorthin verschieben, wo er am günstigsten ist — eine Disziplin mit Namen: Shift Left. Das heißt: Anforderungen vor dem Entwurf prüfen, die riskanten vor der Festlegung prototypisieren und die harten Fragen stellen, solange sie ein Gespräch kosten statt eines Quartals.
Die Rechnung ist einfach. Eine Stunde, die man früh in das Hinterfragen einer Anforderung steckt, kauft die hundert Stunden zurück, die die späte Korrektur kosten würde. Das ist der gesamte Business Case des Anforderungsmanagements, als Zahl formuliert.