Dystopische Software-Entwicklung

Bild: Pixabay / Crow Imagenes - Lizenz

Wer in Familie oder Bekanntenkreis passionierte Computerspieler hat wird in der Weihnachtspause um ein Thema nicht herumgekommen sein: die verheerend verlaufene Markteinführung des dystopischen Rollenspiels Cyberpunk 2077. Angekündigt als Meilenstein seines Genres und mit hohen Erwartungen begrüsst erwies es sich als so unausgereift und fehleranfällig, dass es auf vielen Endgeräten praktisch nicht spielbar war. Die damit für den Hersteller verbundenen Geld- und Reputationsverluste dürften kaum abzuschätzen sein.

Zahlreiche Medien haben über die Geschichte hinter diesem Fehlschlag geschrieben, unter anderem die New York Times, die Washington Post, Slate, der Guardian, die Zeit und Heise. Der Tenor dieser Berichterstattung ist, dass er durch lang bekannte systemische Ursachen herbeigeführt wurde, die typisch für die Computerspiel-Branche sind. Ich würde sogar noch weitergehen und sagen, dass diese Ursachen (mehr oder weniger stark ausgeprägt) in den meisten grossen Software-Projekten vorkommen. Sie alle sind mir schon mehrfach begegnet. Hier sind sie:

Unrealistische Zeitplanung

Nicht nur einer der frühesten Fehler sondern auch einer der schwerwiegendsten. In sehr vielen Firmen werden grosse IT-Projekte zu optimistisch geplant, sei es aus Selbstüberschätzung, aus Wunschdenken, wegen fehlendem Sachverstand oder um sie überhaupt genehmigt zu bekommen. Schlimmstenfalls werden diese Planungen noch mit weiteren verknüpft, von den Karriereplänen des Managements bis zur Ressourcenplanung des nachfolgenden Projekts.

Keine Anpassung der Zeitpläne während des Projekts

Aus den gerade genannten Gründen, aber auch weil Neuplanungsprozesse in der Regel sehr aufwändig gestaltet sind, versuchen viele Organisationen eine Anpassung der Zeitpläne so lange wie möglich zu vermeiden - selbst dann wenn allen Beteiligten klar ist, dass sie unrealistisch sind. Gerade bei langlaufenden Projekten kommt noch ein weiterer Faktor dazu: gelingt es die Anpassungen weit genug in die Zukunft zu schieben ist man selbst nicht mehr betroffen.

Frühes Aufbrauchen des Zeitpuffers

Eine Auswirkung des letzten Punkts. In praktisch jedem grossen Vorhaben wird ein Zeitpuffer eingeplant, mit dem es möglich ist Verspätungen zu kompensieren. Wenn aber selbst in frühen Projektphasen erkannte Planabweichungen nicht zu Neuplanungen führen sondern nur zum Aufbrauchen des Puffers, dann ist die Flexibilität die er liefert zum Projektende hin nicht mehr gegeben - gerade dann wenn sie am dringendsten gebraucht würde.

Aufwändige Vermarktung des unrealistischen Zieldatums

Egal ob es Werbekampagnen für B2C-Produkte sind, Messeauftritte für B2B-Produkte oder sonstige Marketing-Massnahmen - man kann hier erstaunliche Summen investieren. Eine Markteinführung für die die Vermarktung bereits begonnen hat lässt sich daher meistens nur gegen massive Widerstände verschieben, da dieses Geld dann abgeschrieben werden müsste. Dabei ist es dann auch egal ob der Marketing-Verantwortliche wusste wie realistisch das Zieldatum ist oder nicht.

Qualitätssicherung erst kurz vor der Veröffentlichung

Eine weitere Folge unrealistischer Zeitplanung. Um länger an der Fertigstellung von Features arbeiten zu können wird versucht die nachfolgenden Schritte zu komprimieren. Im Fall von Software-Test eine folgenschwere Entscheidung - entweder müssen sie unter hohem Zeitdruck stattfinden und sind dann unvollständig und schlampig oder es werden zeitgleich zu ihnen noch Features gebaut, worurch vor allem frühe Integrations- und Regressionstests wertlos werden.

Massive Überstunden in der Schlussphase

Im Grunde schon das erste Anzeichen dafür, dass die Planungen fehlgeschlagen sind. Das was in der normalen Arbeitszeit nicht zu schaffen ist soll jetzt nachts und am Wochenende stattfinden, was zu Überarbeitung, Fehlern und weiterer Mehrarbeit führt. Eine in diesem Zusammenhang häufige Dysfunktion: sobald Überstunden in Projekt-Schlussphasen normal werden, werden sie oft von Anfang an schon verplant, wodurch es nicht mehr möglich ist sie am Ende zum Aufholen von Rückständen einzusetzen.

Kurzfristiges Ausbauen von Features

Irgendwann kommt der Moment in dem auch der letzte sich die Situation nicht mehr schönreden kann und allen klar ist, dass zum Lieferzeitpunkt nicht alles fertig wird. Auch hier gibt es einen häufigen Reflex: alles was nicht Kernfunktion ist wird auf den letzten Metern wieder ausgebaut, selbst wenn das auf Kosten von Usability, Lastfähigkeit, einheitlicher Benutzererfahrung oder Systemstabilität geschieht und für gründliches Testen keine Zeit mehr da ist. Hauptsache irgendetwas wird fertig.

Ausliefern unvollständiger und fehlerhafter Ergebnisse

Man mag es nicht glauben, aber auch das geschieht immer wieder - Produkte die zum Teil noch unfertig sind gehen raus an den Benutzer. Der stellt dann die inzwischen sprichwörtlichen "Kinderkrankheiten" fest, die durch Hotfixes, Patches und Updates nach und nach behoben werden. Das bedeutet aber auch, dass die Überstunden und die halbgare Qualitätssicherung hinter den Kulissen weitergehen - mitsamt der damit verbundenen negativen Effekte.

---

Soweit die Problembeschreibung, wie so oft gefolgt von der Frage wie es besser gehen soll. Die wichtigste Antwort darauf: durch die Verabschiedung von der Illusion komplexe und neuartige Grossvorhaben im Voraus genau planen zu können. Jeder Versuch es doch zu tun wird in die hier beschriebene Dystopie führen. Stattdessen ist es nötig in kurzen, regelmässigen Abschnitten den Fortschritt zu überprüfen und alle Strukturen und Prozesse darauf zu optimieren, dass Änderungen schnell, einfach und ohne das Verschieben von Problemen in die Zukunft möglich sind. [Werbeblock für Agilität bitte hier einfügen]