Die Erklärung der Welt

In irgendeinem Internetforum las ich neulich in einer Signatur den Spruch:

"Gott hat die Welt nicht in 7 Tagen erschaffen.
Erst trödelte er 6 Tage lang herum, und dann mußte er eine mörderische Nachtschicht einlegen, um den Termin noch zu schaffen"

und mir fiel es wie Schuppen von den Augen, denn dies erklärt für jeden vernünftigen Menschen, zumindest aber für uns IT-ler, warum die Welt so ist, wie sie ist.

Natürlich trödelte Gott nicht einfach herum. Er verbrachte die ersten 6 Tage in der Designphase, hin- und hergerissen mit der Entscheidung zwischen etlichen absolut innovativen, topmodischen und einfach geilen Konzepten und mehrmals täglich unterbrochen durch geänderte Anforderungen der Auftraggeber.

Da sich aber leider der Liefertermin als nicht verhandelbar erwies, folgte die erwähnte Nachtschicht, und unter diesen Umständen ist natürlich völlig klar, daß das Projektergebnis nicht perfekt sein konnte. Die Zustimmung zum GoLive wurde nur gegeben, weil man sonst bei verbrauchtem Budget mit ganz leeren Händen dagestanden hätte.

In Folge wurde erst einmal lange Zeit lustlos mit dem Projektergebnis herumgewurschtelt.

Vor etwa 2000 Jahren wurde deshalb ein Consultant zu einem Ortstermin geschickt mit der Zielsetzung, die Anwender zunächst noch einmal in der korrekten Benutzung zu schulen und nebenbei das Potential für ein erstes Redesign auszuloten. Leider wurde dieser von den aufgebrachten Usern dermaßen fertiggemacht, daß er danach nicht mehr in der Lage war, weiterhin seinen Beruf auszuüben.

Alle noch existierenden Protokolle zu diesem Termin sind lediglich im Nachhinein von Leuten verfasst worden, die nicht unmittelbar in das Projekt eingebunden waren, und aus der Anfangszeit existiert erst recht keine Dokumentation, weil die Dokumentationsmethodik Bestandteil des Projektes war und aufgrund des Termindruckes zunächst nicht implementiert wurde. Da sich außerdem alle Projektbeteiligten inzwischen neuen spannenden Aufgaben zugewandt haben, ist auch niemand mehr verfügbar, den man noch zu Rate ziehen könnte.

In der Folgezeit wurde versucht, wenigstens eine effiziente Supportorganisation aufzubauen. Diese hatte jedoch von Anfang an mit mangelndem Wissen über das Produkt zu kämpfen, denn sie konnte sich ausschließlich auf die oben erwähnten nachträglichen Protokolle stützen, von denen auch noch einige aus geschäftspolitischen Gründen als nicht relevant aussortiert wurden. Diese politischen Erwägungen führten ebenfalls schon bald dazu, daß die Führungskräfte der Supportorganisation eigene Ansichten und Interpretationen, die mit den ursprünglichen Projektzielen nichts mehr gemein hatten, in die Bedienungsanleitung einfließen ließen. Interne Streitigkeiten darüber führten schließlich zu einer Aufspaltung in zwei große und viele kleine Organisationen.

Je mehr die Anwender im Laufe der Zeit über die technischen Grundlagen gelernt haben, umso mehr sind sie dazu übergegangen, eigene Implementierungen der von ihnen vermißten Funktionalitäten zu bauen. Da dies aber ohne vollständige Kenntnis der Zusammenhänge und ohne Abstimmung erfolgt, gibt es dabei immer wieder Rückschläge, verbunden mit negativen Auswirkungen auf das ursprüngliche Produkt, und mittlerweile werden vermehrt Befürchtungen laut, das Projektergebnis könne durch solch unsachgemäße Behandlung irgendwann einmal komplett unbrauchbar werden.

12/2010