In den meisten Softwareunternehmen werden Bugs gezählt und priorisiert. Fünfzig offen, acht kritisch, zwanzig major, der Rest minor. Klingt nach Kontr

In den meisten Softwareunternehmen werden Bugs gezählt und priorisiert. Fünfzig offen, acht kritisch, zwanzig major, der Rest minor. Klingt nach Kontrolle. Ist aber eine Metrik, die fast nichts darüber aussagt, was ein Bug das Unternehmen tatsächlich kostet. Ein Bug in einem selten genutzten Menü und ein Bug, der Kundendaten falsch speichert, bekommen unterschiedliche Severity-Stufen – das ist sinnvoll und richtig. Aber selbst mit klarer Severity bleibt eine Frage meistens unbeantwortet: Was kostet dieser Bug tatsächlich? Der interne Aufwand für Tracking, Analyse und Behebung ist noch halbwegs schätzbar. Was aber selten berechnet wird, ist der externe Preis – Kundenfrust, Supportlast, Reputationsschaden, verlorenes Vertrauen, das sich in keinem Ticket wiederfindet. Wer Bugs in Euro bewertet statt nur in Severity-Stufen, bekommt ein völlig anderes Bild. Was kostet dieser Bug, wenn er nicht behoben wird – in Support-Aufwand, in verlorenen Kunden, in Entwicklerstunden für den späteren Fix? Was kostet der Hotfix-Release, der jetzt nötig wird – nicht nur die Entwicklungszeit, sondern Testing, Deployment, Kommunikation an Kunden, die Unterbrechung des laufenden Entwicklungszyklus? Hotfix-Releases sind besonders aufschlussreich. Ein Unternehmen, das regelmäßig außerplanmäßige Releases fährt, hat meistens kein Pech – es hat ein strukturelles Qualitätsproblem. Aber solange niemand den tatsächlichen Preis berechnet, bleibt das Problem unsichtbar und wird als normaler Ablauf akzeptiert. Der Wechsel von Severity-Stufen zu Euro verändert aber nicht nur die Priorisierung. Er verändert das Mindset derer, die Bugs produzieren und beheben. Solange ein Bug eine Nummer in einer Liste ist, bleibt die Reaktion meistens irgendwo zwischen "das kommt vor" und "werden wir irgendwann fixen". Sobald ein Bug einen Eurobetrag trägt – sagen wir, dieser Fehler hat uns drei Tage Support-Aufwand, einen verlorenen Kunden und einen Notfall-Release gekostet, in Summe ungefähr zwanzigtausend Euro – verändert sich das Gespräch. Nicht als Vorwurf, sondern als Information. Und aus dieser Information entsteht eine Frage, die mit Nummern nie entstanden wäre: Wie hätten wir das vermeiden können? Geld macht abstrakte Konsequenzen konkret. Ein Entwickler, der versteht, dass ein mangelhaftes Review nicht nur einen Bug produziert hat, sondern einen Betrag, der aus demselben Budget kommt wie Gehaltserhöhungen, Weiterbildung und neue Hardware, denkt beim nächsten Review anders. Nicht aus Angst. Aus Verständnis. Das ist der Unterschied zwischen einer Fehlerkultur, die Bugs verwaltet, und einer, die sie systematisch reduziert. Qualitätsmanagement, das nur zählt was leicht zu zählen ist, misst das Falsche. Was leicht messbar ist, ist selten das, was wirklich zählt.