Klassische Software-Projekte - auch solche, die mit modernen Methoden wie V-Modell XT oder RUP umgesetzt werden - zeigen häufig bestimmte Krankheitssymptome, die meiner Meinung nach nicht am Versagen der Projektleiter im Bezug auf die Anwendung ihrer jeweiligen Methodologien liegen. Die Ursache sitzt tiefer und steckt in den Vorgehensmodellen selbst, weil diese oftmals zu unflexibel und bürokratisch sind und das gesamte Team unnötigerweise in ein Korsett zwängen, welches ihre Beweglichkeit (=Agilität!) einschränkt. Würden Sie mit einem Gipsbein zum 100-Meter-Sprint antreten?
Das Hauptproblem liegt in der realitätsfremden - nichtsdestoweniger erstaunlich weit verbreiteten - Vorstellung, man könne ein großes Software-Projekt zunächst komplett im Vorhinein analysieren, spezifizieren und die Aufwände genau vorhersagen. Dies führt zwangsläufig zur wohlbekannten
Patt-Situation zwischen Kunde und Anbieter
-
Der Kunde will Preis und Dauer für das Gesamtprojekt wissen und erst dann einem Anbieter den Auftrag erteilen.
-
Der Anbieter kann - in Ermangelung einer magischen Kristallkugel - erst nach gründlicher Analyse vernünftig den Gesamtaufwand und damit den Preis schätzen, sofern er kein Scharlatan ist.
Folgen
-
Der Kunde bezahlt, um zu bekommen, was er will (Preis und Fertigstellungsdatum), die Analyse, um anschließend jedoch evtl. gar keinen Auftrag zu erteilen, weil der (vom umsichtigen Anbieter "mit Airbag" geschätzte) Aufwand das Budget sprengen würde.
-
Oder ein billigerer Anbieter gewinnt den Auftrag, auch wenn er nicht realistisch geschätzt hat und hauptsächlich beim Kunden "den Fuß in die Tür bekommen" möchte, um in einem erhofften Folgeauftrag seine vertriebliche Investition wieder wettmachen zu können. Das sind dann aus Anbietersicht die sog. "strategischen Projekte".
-
In jedem Fall gilt jedoch: Das Angebot des Anbieters bleibt nur stabil, wenn sich später die spezifizierten Anforderungen nicht mehr ändern, denn es fußt ja auf eben dieser Spezifikation, welche gespickt von Annahmen, Festlegungen und technischen Konzepten ist.
Sonstige Defizite (kleine Auswahl)
-
Zu große Entwicklungs-Inkremente: einmalige Lieferung ganz am Ende oder zu umfangreiche Meilensteine. Wenn das Projekt scheitert oder in die falsche Richtung läuft, bemerkt man es zu spät.
-
Anforderungs-Änderungen werden als Problem wahrgenommen, sind unerwünscht.
-
Fachbereich und Entwicklung haben kaum direkten Kontakt, kommunizieren über Projektleiter oder Software-Architekten.
-
Effizienzverluste durch Prozeß-Overhead (Meetings, Analyse, Dokumentation)
-
Dokumentation dient oft nur der gegenseitigen Absicherung bzw. Schuldzuweisung ("Diese Anforderung steht so nicht im Pflichtenheft.", "Das hätten Sie wissen müssen, weil es auf Seite 137, Abschnitt 4.2.1 steht.") und interessiert nach Abnahme keinen mehr.
| < Zurück |
|---|