Hauptgedanke

Wörtlich genommen verspricht die Formel eine Software ohne Defekte — etwas, das kein Team je ausliefert, und schon ist der Einwand da. Das Ziel liegt woanders: null bekannte Defekte ohne Entscheidung.

Das Unbekannte bleibt außer Reichweite. Ins Visier genommen wird die dauerhafte, organisierte Hinnahme von Defekten, die man kennt. Wenn ein Signal eingeht — eine Rückmeldung des Supports, eine in einer App wie My Porsche entdeckte Regression —, entscheidet das Team: Ist das ein Defekt? Wenn ja, wird er behoben. Wenn nein, verlässt er die Defektverwaltung: Verbesserung, Feature-Anfrage, Missverständnis, interessantes Thema, aber ohne Priorität.

Was die Regel verbietet, ist der dritte Zustand: „Wir wissen, dass es ein Defekt ist, wir behalten ihn für später in einer Liste.“ Ein bekannter Defekt, den man aufbewahrt, ohne zu entscheiden, ist kein Softwaredefekt mehr, sondern ein Entscheidungsdefekt.

Warum das wichtig ist

Damit dreht sich der häufigste Einwand um. Versprochen wird keine Perfektion, verboten wird ein Zwischenzustand — und dieser Zwischenzustand lässt sich sehr wohl erreichen.

Damit verschiebt sich auch, was man misst. Gezählt werden nicht mehr die Defekte des Produkts, sondern die bekannten Defekte ohne Entscheidung. Die erste Zahl hängt vom Produktionssystem ab, die zweite allein von der Organisation.

Nuancen und Grenzen

Über die Qualität der getroffenen Entscheidungen sagt die Regel nichts. Ein Team, das massenhaft zu Nicht-Defekten umklassifiziert, erfüllt den Buchstaben und höhlt den Sinn aus.

Und sie erfasst nur das Bekannte: Ein Produkt mit wenig Messpunkten und ohne strukturierten Support weist wenige bekannte Defekte aus, ohne deshalb weniger zu haben.

Offene Fragen

• Woran erkennt man eine Gefälligkeits-Umklassifizierung, die die Entscheidung abschließt, ohne den Schmerz zu behandeln?