Horst Walther[1]

Aus dem Umgang mit unseren Schwächen eine Stärke machen.[2]

Als ich neulich auf der Suche nach einem verschollenen Kollegen aus fernen Projekttagen im schönen Wien durch das Internet "browste", stieß ich auf dieses provozierende Motto. "Von der Lösung zum Fehler?" Wenn das nicht genau anders herum gemeint war, dann musste ich den Gesuchten gefunden haben. Etwas kauzig war er schon immer - aber unterhaltsam.

Zustimmen muss ich ihm allerdings schon, wenn er weiter schreibt:

Capability Maturity Model des SEI

Wir alle machen Fehler, täglich. Die persönliche Fehlerrate mag statistisch streuen, im Durchschnitt aber ist jede 7. unserer Entscheidungen falsch. Zugeben mag das jedoch kaum jemand. So wie wir alle einmal sterben müssen, aber nach Möglichkeit Niemand darüber spricht.

Spaß-Mails sind häufig ein Ärgernis. Manchmal verraten sie aber auch ungemein viel über die Befindlichkeit einer ganzen Branche. So auch der Vorschlag von BSOD’s mit Bierwerbung. BSOD (blue screen of death), ist der allen Microsoftgeschädigten bekannte rien ne va plus Bildschirm, der meist weit nach Mitternacht auftritt, wenn die Vorstandspräsentation für den nächsten morgen fast fertig, aber noch nicht gedruckt oder gesichert ist. Auf geheimnisvoll blau schimmernden Hintergrund sind seltsame hexadezimale Zahlenfolgen abgebildet, ein Geheimcode, der unter den beschriebenen Umständen angeblich Halluzinationen hervorrufen kann - vielleicht noch verbunden mit der hämischen Aufforderung einen imaginären "Systemoperator" zu Hilfe zu rufen. Was liegt also näher als einen Bildschirm mit so hohem Aufmerksamkeitswert als Werbefläche für ein kühles Bier oder auch Schärferes situationsadäquat zu nutzen.

Für die Betroffenen ist das eher schwarzer Humor. "Kann denn die Kiste nicht einfach nur funktionieren?" Kann sie nicht. Denn hier hat der Entwickler wieder stramm Richtung Lösung geblickt und dabei die Fehler nicht gesehen. Dabei sollte doch alles ganz einfach sein: "Quality is free" sagte die TQM-Ikone Philip B. Crosby. Das mag von der übergeordneten Sicht einer langfristigen Kosten-Nutzen-Balance stimmen. In der konkreten Arbeitssituation ist die Forderung nach Qualität aber zunächst eher schmerzhaft: jeder weiß (auch der Autor), dass er sein Dokument 5 mal lesen kann und dann immer noch "Kinken" drin hat, wegen derer ihn auch gutmütige Leser mitleidigen Blickes betrachten werden.

Noch schlimmer sind Software-Entwickler dran. Dass sie nach Hochschulstudium und jahrelanger Praxis noch immer so viele völlig überflüssige Fehler machen wie "pointer to nowhere" oder "exception not caught" ist offenbar so schwer zu ertragen, dass sie dazu Bug sagen - Käfer, heimtückisches kleines Ungeziefer, das sich von außen eingeschlichen hat. Dafür kann keiner etwas.

Dabei sind wirklich fehlerfreie - zero defect - Ergebnisse nur in wenigen Fällen erforderlich. Good enough Software heißt die Devise, in getreuer Umsetzung der Definition "Quality is meeting the customers expectation". Zielqualität ist gefordert, eine Punktlandung also. Overengineering hat zwar einen viel besseren Ruf als eine Minderleistung. Unternehmerisch ist sie aber genauso unangemessen - weil möglicherweise für das Unternehmen tödlich.

Kleiner Exkurs: Auch Informationssicherheit ist letztlich ein - wenngleich komplexes - Qualitätsmerkmal. So klagte unlängst einer meiner Kunden, Beauftragter für Informationssicherheit in einer Bank: Wie soll ich hier für Informationssicherheit sorgen, wenn noch nicht einmal die Prozesse beschrieben sind.

Stimmt irgendwie: Wenn Sie etwas verändern wollen, müssen Sie das Ziel kennen. Wenn Sie den Weg dahin bestimmen wollen, müssen Sie wissen, wo Sie stehen. Und dann sollten Sie noch sagen können, wie sehr sich dabei vernavigiert haben.

Übersetzt heißt das: Prozesse planen, ausführen, messen und anpassen - in der Summe also aktiv steuern. Controlling, das ist einer der bekannteren false friends für Übersetzer, heißt auf Deutsch Steuerung und nicht Kontrolle und so kennen wir diese vier Schritte auch als Controlling-Zyklus.

Er erinnert aber auch fatal an das CMM (Capability Maturity Model) das einst vom SEI (Software Engineering Institute) für die Beurteilung der Reife des Software­entwicklungs­prozesses entwickelt wurde. Sehr verdächtig ist auch dass der PDCA-Kreislauf (plan - do - check - act) aus dem TQM (total quality managment) fast das Gleiche beschreibt. Wurde hier etwa dreimal das "Rad neu erfunden"? Das lässt befürchten, dass dieser ubiquitäre Regelkreis eben noch nicht das selbstverständliche Fundament jeglichen Managements ist. Es sind offenbar nicht nur die Softwareentwickler, die nur in Richtung Lösung blicken, nur das "ausführen", das "do" im Auge haben

Jede Software ist eine größere Fehlersammlung. Sie kennen vielleicht die verzweifelt selbstkritischen Erkenntnisse der passionierten Software-Desperados …

PDCA: plan - do - check - act

Und auch Beispiele könnten noch viele folgen.

Ist also Software nichts anderes als "für die Ewigkeit eingefrorene menschliche Dummheit?". Sind wir Menschen mit der Programmierung von Computern überfordert? Dazu noch ein kleines Beispiel.

Der alte Seymur Cray, ja das war der Vater der berühmten Supercomputer, war sicher ein Vollblutunternehmer von echtem Schrot und Korn. Von ihm wird der Ausspruch kolportiert: "ich arbeite am liebsten mit Absolventen, frisch von der Uni - die wissen noch nicht, was unmöglich ist."

Diesen jungen Helden, die überall in der Branche für den edlen Wettstreit Mensch gegen Maschine Himmel und Hölle in Bewegung setzen, haben wir viel zu verdanken: Spitzentechnologie wie Supercomputer und den katastrophalen Blue Screen of Death - Himmel und Hölle eben. Diese mutigen IT-Krieger haben natürlich nichts für so unsportliche Übungen wie Test oder gar Testfallerstellung übrig, Qualitätssicherungsübungen Erbsenzählermanier sind danach bestenfalls etwas für die Versehrten vergangener Projekt-Schlachten.

Ein Pilot muss erst durch langes schmerzhaftes Training lernen, im Instrumentenflug blind den Instrumenten zu vertrauen - und nicht seinem verdammten Gefühl. In Fliegerkreisen kursieren ausreichend Geschichten von Sichtflugpiloten, die, nachdem sie doch einmal in eine große Wolke geraten waren, diese mit Höchstgeschwindigkeit senkrecht nach untern in Richtung soliden Erdbodens wieder verließen.

Diese Situation gibt es auch in IT-Projekten, nur dass viele vor dem Aufprall nicht mehr aus der Wolke herauskommen. Einige haben nicht einmal Instrumente an Bord. Dabei ist die Lösung simpel - wenngleich schwer zu erreichen. Wir müssen der unangenehmen Tatsache ins Auge sehen, dass wir Aufgaben lösen wollen und dabei zwangsläufig Fehler machen.

Die Natur arbeitet in Kreisläufen. Wir Menschen müssen ebenfalls in Regelkreisen arbeiten lernen, auch wenn wir wollen, dass unser so geliebter Fortschritt nur eine Richtung kennt.

Von der (Schein-) Lösung zum Fehler. Wenn wir Ergebnisse in der geplanten Zielqualität liefern wollen, müssen wir den Umgang mit unseren Fehlern lernen. Denn die sind "eh da". Und so lange wir sie nicht gefunden und beseitigt haben sind sie eben noch in unseren Produkten.

[1] Dr. Horst Walther ist Geschäftsführer der SiG Software Integration GmbH in Hamburg

[2] Dieser Beitrag ist in gekürzter Form als Kolumne der Ausgabe 1+2 2003 der Zeitschrift DATACOM erschienen.



Horst Walther, Hamburg