Warum Softwareprojekte scheitern
Es war 2007, als sich ein Release für mich als Fehlschlag herausstellt: Acht Leute entwickelten ein halbes Jahr lang Features. Der Release-Termin musste mehrmals verschoben und geplante Funktionalitäten gestrichen werden. Und trotzdem war ich mit vielen der entstandenen Lösungen am Ende unglücklich.
bei Amazon kaufen und »AgilManagen.de« unterstützen
Ich war erst seit zwei Jahren Teamleiter und leitete mein erstes größeres Projekt. Wir arbeiteten es klassisch nach dem Wasserfallmodell ab, so wie es bei meinem damaligen Arbeitgeber seit Jahren praktiziert wurde und wie es heute leider immer noch sehr viele Unternehmen tun. Von agilen Methoden hatte ich am Rande schon gehört, sie aber als Ausrede von Projektleitern abgetan, die zu faul waren Projektpläne zu pflegen.
Allerdings stand nun das nächste Projekt an und ich war mir sicher, dass wir wieder scheitern würden, wenn wir genauso vorgingen wie zuvor.
Kurz bevor ich in den Herbsturlaub ging, legte mir einer meiner Top-Entwickler ein Buch auf den Tisch. »Das habe ich gerade gelesen und fand es sehr aufschlussreich. Wenn Du magst, kannst Du es Dir ausleihen.«
Also las ich das Buch und erlebte einen dieser magischen Momente, in denen der richtige Denkanstoß genau zum richtigen Zeitpunkt kam. Das Buch – das ich Dir wärmstens empfehlen kann – stammte von George Stepanek und hieß »Software Projects Secrets: Why Software Projects Fail«.
Im ersten Teil beschrieb Herr Stepanek, wo Softwareprojekte von klassischen Projekten abweichen und warum somit das Wasserfallmodell eine schlechte Wahl ist. Bei der Lektüre der typischen Probleme hatte ich ein Déjà-vu nach dem anderen. Scheinbar hatte ich so ziemlich alles erlebt, was schief laufen kann. Im zweiten Teil des Buchs ging der Autor auf mögliche Lösungen ein. Aber lass uns heute bei den Problemen bleiben.
Inhalt
Wann ist ein Projekt erfolgreich?
Je besser wir bei einem Projekt die Kenngrößen Umfang, Kosten und Zeit einhalten, desto erfolgreicher waren wir
Was macht gemäß der klassischen Definition ein erfolgreiches Projekt aus? Wahrscheinlich kennst Du das »magische Dreieck der Projektziele«, an dessen Ecken die Punkte »Umfang«, »Kosten« und »Zeit« stehen. Je näher diese Parameter der ursprünglichen Planung kommen, desto erfolgreicher waren wir.
Das wiederum setzt voraus, dass wir das Projekt im Vorhinein exakt definieren, genau so, wie das bei einem Großprojekt – wie zum Beispiel bei einem Flughafenbau – erfolgt: Hier fließen Jahre in die Planung, es werden Architekturpläne entworfen und alle Anforderungen bis ins kleinste Detail definiert. Auf dieser Basis können die Parameter vorab genau benannt und ihre Einhaltung später gemessen werden (und wir wissen ja, wie gut das im Beispiel »BER« trotz umfangreicher Voranalyse funktioniert hat).
Der Ablauf im Wasserfallmodell
Die meisten Softwareprojekte laufen aber grundlegend anders ab. Hier werden Anforderungen nur grob definiert. Selten existieren UI-Entwürfe oder werden gar Fehlersituationen genauer betrachtet. Ursachen hierfür gibt es viele:
- Der Kunde möchte die Erstellung eines ausführlicheren Lastenhefts nicht bezahlen.
- Der Autor des Lastenhefts besitzt nicht die notwendigen Kompetenzen.
- Und natürlich ist es auch wirklich aufwändig, vorab eine komplexe Software bis ins Detail zu durchdenken. Viele Fragen fallen uns erst während der Implementierung auf.
Somit starten wir mit einer unvollständigen Spezifikation in ein Projekt, gehen dann aber so vor, als wenn bereits alle Fragen geklärt wären.
Das Wasserfallmodell mit den einzelnen Phasen, Zuständigkeiten und Übergabeartefakten
Auf die Spezifikationsphase folgen die Planungs- und dann eine mehrmonatige Implementierungsphase. Daran schließen sich die Stabilisierungsphase und die Dokumentation an, bevor das Release in den Kundentest geht und der Rollout beginnt.
Die Übergabe zwischen den verschiedenen Phasen erfolgt indirekt durch Artefakte:
- Der Projektmanager »wirft« das Lastenheft in die Entwicklung, ohne dass sie an der Erstellung beteiligt gewesen wäre.
- Die Entwicklung gibt das fertige Release zusammen mit Entwicklerdokumentation in die QA und die technische Redaktion, ohne dass diese vorher Einfluss nehmen konnten.
- Am Ende erhält der Kunde das Release, ohne dass er in den Entstehungsprozess eingebunden war.
Wann Probleme sichtbar werden
Bei diesem Vorgehen treten während der gesamten Projektphase Schwierigkeiten auf. Hier einige typische Beispiele aus der Implementierungsphase:
- Nachdem mit der Implementierung eines Features begonnen wurde, stellen sich einzelne Anforderungen als unklar heraus (»wie soll sich die Software verhalten wenn … eintritt?«). Folglich muss der Entwickler die Arbeit unterbrechen, damit der Projektleiter die Frage mit dem Kunden klären und das Lastenheft aktualisieren kann.
- Die Umsetzung einer Funktion ist aufwändiger als geschätzt.
- 3rd-Party-Komponenten bieten nicht den erwarteten Leistungsumfang. Somit müssen Workarounds geschaffen werden.
- Durch die oben genannten Probleme erhöhen sich die Aufwände und der Termin für das Entwicklungsende muss verschoben werden.
- Ganze Feature-Blöcke werden gestrichen um den (bereits verschobenen) Termin halten zu können.
- Unter Zeitdruck und mit Überstunden werden die letzten Funktionen fertiggestellt.
- Entwicklertests und ‑Dokumentation werden auf später verschoben.
In der Stabilisierungsphase geht es dann munter weiter:
- Es stellt sich heraus, dass die hektisch fertiggestellten Features nicht funktionieren. Die Entwicklung beginnt nachzubessern.
- Die Tester tragen Fehler ein. Die Entwickler argumentieren, dass sich das Feature wie spezifiziert verhält. Die Tester sind anderer Meinung. Aus Zeitgründen bleibt alles, wie es ist, obwohl der Tester eigentlich Recht hat …
- Von der QA gemeldete Fehler stellen sich als konzeptionelle Probleme heraus. Eine Behebung ist aus Zeitgründen nicht mehr möglich um den (verschobenen) Liefertermin halten zu können.
- Die Behebung von Fehlern dauert unnötig lange, da der Entwickler die zugehörige Funktionalität eventuell schon vor mehreren Monaten abgeschlossen hat und sich nicht mehr an die Details erinnern kann.
Als Resultat wird eine Version mit bekannten Fehlern an den Kunden ausgeliefert, bei der diverse Funktionen noch gar nicht getestet wurden. Bei den Tests durch den Kunden treten die Probleme aus der Stabilisierungsphase nochmal auf.
Am Ende ist der Kunde mit der Lieferung und uns als Anbieter unzufrieden und wir haben viele »Frickellösungen« im Code.
Wann Probleme verursacht werden
Lass uns nun einen Blick drauf werfen, wann die Probleme verursacht werden. Das beginnt bereits in der Spezifikationsphase:
- Der Projektmanager schreibt auf, was der Kunde ihm sagt – ohne zu hinterfragen, was der Kunde eigentlich will. Eventuell würde eine bereits existierende Produktfunktionalität (gegebenenfalls mit leichter Anpassung) genügen.
- Obwohl alle Beteiligten dem Lastenheft zugestimmt haben, ist es unvollständig. (Ja, das ist immer so. Ein vollständiges Lastenheft gibt es nicht.)
Weiter geht es mit der Planungsphase:
- Abschätzungen werden auf Basis von »Erfahrungen« erstellt. Später wird sich herausstellen, dass die tatsächlichen Aufwände (meist nach oben) abweichen.
In der Implementierungsphase werden weitere Fehler gemacht:
- Der Entwickler implementiert die Spezifikation so, wie er sie versteht. Häufig ist das aber nicht das, was der Verfasser des Lastenhefts meinte (und meist erst recht nicht das, was der Kunde will).
- Wir, als Leiter der Entwicklung, ermitteln den Projektfortschritt anhand der geleisteten und noch ausstehenden Aufwände. Später wird sich aber herausstellen, dass einige der bereits als »fertig« bezeichneten Funktionalitäten noch erhebliche Mängel aufweisen. Folglich gaukeln wir uns einen zu optimistischen Fortschritt vor.
Zwischenstand
Was ist die Erkenntnis aus den beiden vorangegangenen Abschnitten? Ganz einfach: Probleme werden erst deutlich später entdeckt, als sie verursacht werden. Würde es uns also gelingen die Probleme früher zu entdecken könnten wir besser gegensteuern.
Motivation des Mitarbeiters
Damit ist es aber noch nicht getan. Schau Dir den oben beschriebenen Ablauf an und versuche Dich in die Lage der Mitarbeiter zu versetzen. Wie würdest Du Dich dabei fühlen?
Bei Projekten basierend auf einem Projektplan sind die einzelnen Entwickler meist »stupide« Aufgabenempfänger – sie bekommen von Dir als Leiter der Entwicklung gesagt wann sie welche Aufgaben zu erledigen haben, und wie viel Zeit sie dafür haben. Würdest Du Dich einer Abschätzung verpflichtet fühlen, die irgendjemand anderes Dir vorgibt? Häufig läuft man hier zunächst in eine Abwehrhaltung: »Was! In fünf Tagen schaffe ich das niemals!« Meist bewahrheitet sich das dann auch (»self fulfilling prophecy«). Hätte man den Entwickler vorher selbst gefragt, hätte er vielleicht sogar weniger abgeschätzt.
Ähnliche frustriert sind häufig die Tester: Sie sind das letzte Glied in der Kette. Sie bekommen eine Funktionalität vorgesetzt, ohne ernsthaft darauf Einfluss nehmen zu können. Häufig resultiert das in Kleinlichkeit: Wenn man schon die Features nicht mehr beeinflussen kann, versucht man wenigsten jede Winzigkeit als Bug durchzudrücken, um überhaupt etwas beizutragen. Das wiederum führt häufig zu unschönen Grabenkämpfen zwischen Entwicklung und QA.
Auch die Verteilung der Aufgaben auf die Entwickler – die für eine Kapazitätsplanung im klassischen Projektplan dringend notwendig ist – war mir stets ein Gräuel. Da versuchte ich unliebsame Aufgaben gleichmäßig auf die Entwickler zu verteilen, nur um hinterher festzustellen, dass manch einer sie gerne übernommen hätte. Die Vorlieben sind halt individuell. Ganz davon zu schweigen, dass die Aktualisierung des Projektplans nach jeder kleinen Abweichung viel Zeit in Anspruch nahm.
Fazit
Wir müssen uns mit einer Tatsache abfinden: Lastenhefte sind niemals vollständig. Natürlich gibt es kritische Bereiche – wie z.B. in der Medizintechnik oder der Luftfahrt – wo eine möglichst vollständige Definition erforderlich ist, aber in den meisten »Enterprise«-Projekten ist keiner bereit eine ewig lange Spezifikationsphase voranzustellen.
Mit dieser Erkenntnis müssen wir auch das »Dreieck der Projektziele« hinterfragen: Wenn der Umfang nicht bis in kleinste Detail klar ist, können wir keine exakte Abschätzung der Parameter »Zeit« und »Kosten« erwarten. Somit müssen wir uns ein neues Ziel suchen, anhand dessen wir den Erfolg eines Projekts beurteilen können.
Um bei der Durchführung besser zu werden, müssen wir in erster Linie Probleme früher sichtbar machen. Das ermöglicht es uns, den Projektfortschritt realistischer einzuschätzen und rechtzeitig Gegenmaßnahmen ergreifen.
Wir sollten unsere Zeit nicht mit unnötigen Dokumenten verschwenden, die nur dem Austausch zwischen den Abteilungen oder – noch schlimmer – lediglich der Befriedigung irgendwelcher Prozesse dienen. Direkte Kommunikation ist effizienter und vermeidet Unklarheiten und Frust.
Und, am allerwichtigsten, wir müssen unseren Mitarbeitern mehr Entscheidungsbefugnisse einräumen, um aus unmotivierten Aufgabenempfängern selbstständige Projektteilnehmer zu machen, die mit vollem Einsatz auf das Projektziel hinarbeiten.
Zeit also, dass wir uns überlegen, wie wir das konkret umsetzen können. Genau das werde ich Dir im nächsten Beitrag »So lösen agile Methoden die Probleme des Wasserfallmodells« zeigen.
Trackback von deiner Website.
