Hauptgedanke

Ein echter Defekt kann geringfügig sein: ein Button, auf den man zweimal klicken muss. Daneben kann eine fehlende Fähigkeit einen Nutzer daran hindern, eine verpflichtende Steuererklärung abzugeben.

Das Erste ist ein Defekt im strengen Sinn, das Zweite ist keiner — und doch muss das Zweite vorgehen. Die Reihenfolge der Bearbeitung folgt der Auswirkung, nie der Einordnung.

Warum das wichtig ist

Das ist die Leitplanke einer Zero-Bug-Policy. Flüchtig gelesen wird aus ihr „jeder Defekt vor jedem Feature“, und das Team behebt Ärgernisse, während ein blockierender Bedarf unbeantwortet bleibt.

Zuerst zu bearbeiten, weil etwas als Defekt etikettiert ist, heißt, die Abwägung durch das Etikett zu ersetzen: genau der Fehler, den die Regel beheben wollte, nur umgekehrt.

Nuancen und Grenzen

Der Umkehrschluss gilt nicht. Kleine Defekte endlos zugunsten eines immer dringlicheren Features aufzuschieben, ist genau der Mechanismus, der den Bestand entstehen lässt.

Und der Vergleich setzt voraus, dass man die beiden Schmerzen auf dieselbe Skala bringen kann, was nicht selbstverständlich ist, wenn der eine regulatorisch ist und der andere alltäglich.

Offene Fragen

• Auf welcher Skala vergleicht man einen punktuellen regulatorischen Schmerz mit einem alltäglichen Schmerz im Gebrauch?