Bei einem meiner frühen Beratungsprojekte wurde ich in das soeben eingeführte Qualitätsmanagementsystem des Kunden integriert und musste bzw. durfte an der Mitarbeiterschulung teilnehmen. Das System war das von Crosby & Associates und der Kernsatz dieses Systems lautet: „Lieber gleich richtig“. Mit dem Schlagwort „Null-Fehler“ bzw. „Zero-Defect“ wurde diese Strategie bekannt.
Interessant ist allerdings, dass dieser Ansatz in IT-Projekten aktuell keine Rolle spielt. In mehreren Großprojekten, die ich in verschiedenen Rollen begleitet habe, war eine Bug-Statistik selbstverständlicher Teil des Projektcontrollings. Alle Einwände von Anwendervertretern, dass die Fehlerzahl zu hoch sei, wurden als Zeichen mangelnden Verständnisses für das Wesen von Softwareentwicklung weggewischt. Es gibt keine fehlerfreie Software, das weiß man doch!
Nun lese ich gerade wieder ein Buch von Tom deMarco, das ich generell sehr empfehlen kann. Das Buch gibt es nur noch antiquarisch, das aber sehr preisgünstig und unkompliziert.
Dort berichtet er von einem Gespräch mit zwei Softwareentwicklern, die vor Jahren ein Programm entwickelt hatten, bei dem kein einziger Fehler gefunden worden war. „Ich fragte einen von ihnen, wie er sich denn diesen phänomenalen Erfolg erklärt, ein Programm ohne jeden Bug schon beim ersten Versuch auszuliefern. Er gab mir folgende Antwort: Ähhh, wir haben gar nicht gewusst, dass Bugs erlaubt sind.“ (a.a.O., S. 333). Und weiter schreibt Tom DeMarco: „Es ist unter Softwareentwicklern allgemein bekannt, dass sie niemals den allerletzten Bug aus einem Programm herausbekommen werden. Bugs werden als traurige Lebensweisheit hingenommen. Wir hoffen, sie eines Tages auszumerzen, können sie aber nie endgültig besiegen. Ich bin mehr und mehr über den Gedanken beunruhigt, dass diese fatalistische Haltung Bugs gegenüber kein produktiver Bestandteil unserer Vorgehensweise ist, wie wir an das Problem herangehen, sondern ein Teil des Problems selbst. Ich glaube, wenn wir damit aufhören, uns selbst einzureden, dass Bugs erlaubt sind, würde es weniger davon geben.“ (ebenda, S. 334).
Ich muss zugeben, dass ich von diesem Konsens der Selbstverständlichkeit und Unvermeidlichkeit von Fehlern schon weichgeklopft war und nicht mutig genug, mich hier als Außenseiter zu deklarieren. Aber es ist doch richtig, dass jeder von uns die Pflicht hat, fehlerfreie Arbeit auszuliefern. Ja, Fehler kommen vor, aber es sind Fehler und wir müssen einen Lernprozess in Gang setzen, denselben Fehler nicht zweimal zu machen. Wenn man Fehler verharmlosend als Bugs bezeichnet (als wäre das eine höhere Gewalt), anstatt zu sagen, dass es Fehler sind, die jemand gemacht hat, geht viel Zeit, Geld und Motivation verloren, um vermeidbare Fehler zu suchen, zu finden, zu melden, auszubessern und dann wieder nach Fehlern bei der Fehlerkorrektur zu suchen usw. usw. Das ist enorm teuer. Tom deMarco rechnet das vor, Philip P. Crosby hat das schon vor Jahrzehnten für verschiedene Branchen getan und das Argument ist immer noch richtig. Es gilt auch für IT-Projekte!
Ich hoffe, ich schaffe es, in den von mir begleiteten Projekten erfolgreich dagegen zu argumentieren. Und um Missverständnissen vorzubeugen: Es geht überhaupt nicht darum, Leute für Fehler niederzumachen. Aber es kann nicht sein, dass man Fehler verschleiert und schönredet. Es stimmt schon: „Wo gehobelt wird, fallen Späne“. Aber das heißt ja nicht, dass der Tischler die Späne ausliefert, weil er das Möbelstück nicht fertigbringt.
Bild: Patrick M. Pelz
Webmentions
… [Trackback]
[…] Find More here on that Topic: it-governance.blog/lieber-gleich-richtig/ […]
… [Trackback]
[…] Find More on to that Topic: it-governance.blog/lieber-gleich-richtig/ […]