Keine Zeit für Qualität

20.07.2006 Permalink

Vor einiger Zeit bin ich über die bemerkenswerte Aussage eines Projektleiters gestolpert, dass man in der augenblicklichen Lage des Projekts keine Zeit für Qualität habe. Diesem Satz wohnt die folgende Logik inne: Hohe Qualität von Arbeitsergebnissen kostet Zeit, die man spart, wenn man mit geringer Qualität leben kann.

Tatsächlich aber gilt: man kann keine Zeit (oder Kosten) sparen, indem geringe Qualität produziert wird. Ein nicht durchdachtes Konzept (oder gar keines) wird längliche Diskussionen, Missinterpretationen und Fehler verursachen. Eine unreife Software wird im Systemtest oder im Betrieb für jeden einzelnen derart spät entdeckten Defekt ein Vielfaches von dem kosten, was man für ein Code- Review gezahlt hätte. Einfach deshalb, weil die organisatorischen Wege vom Finden über das Melden zum Analysieren und Beheben und wieder zurück sehr viel länger sind als in der Entwicklung.

Alles, was man durch die naive Qualität-sparen-heißt-Zeit-sparen-Taktik erreichen kann, ist, dass die jeweils nächste Phase in der Kette Konzept- Realisierung-Test-Betrieb/Wartung massive Zusatzkosten und Verzögerungen erfahren wird.

Diese Taktik hat noch einen weiteren Nachteil: das Projekt wird unvorhersagbar. Wie soll man sich ein Bild von den Entwicklungskosten eines Release machen, wenn es keine belastbare Anforderungsdefinition bezogen auf das Release gibt? Wenn man ohne Code-Reviews und mit dünnen Unittests in die Integration und den Systemtest geht, wie soll man ein Gefühl für die Fehlerrate und die Defektbehebungskosten haben? Nicht nur, dass akurates Schätzen unmöglich ist, hinzukommen viele kleine und große Überraschungen in späten Phasen, die ungeplante Aufwände verursachen und meist bei frühen Prüfungen aufgefallen wären.

Am Ende des Tages wird der besagte Projektleiter damit also zwei Effekte erzielen: