Dienstag, 22. Mai 2012

Software Projekte sind wie Blumensträuße

Zugegeben ein vielleicht waghalsiger Vergleich und sicher nicht in allen Feinheiten stimmig. Aber dennoch sehe ich einige Übereinstimmungen. Denn die meisten Software Projekte sehen am Ende des Projekts anders aus als am Anfang definiert.

Wenn ich einen Blumenstrauß kaufen gehe, weiß ich ungefähr, was ich ausgeben möchte (Budget) und auch ungefähr, was ich haben möchte (Scope). Ich gehe also zum Blumenladen und werde dann natürlich gefragt, was für einen Strauß Blumen ich denn gerne hätte und wieviel er kosten darf. Ich sage also ca. 20 Euro bitte und auf jeden Fall sollen Gerbera dabei sein und etwas Grünzeug.


Die Blumenverkäuferin schnappt sich also Gerberas (wohlbemerkt gibt es mehrere Sorten) und etwas Grünzeug und fragt dann, ob ich noche gerne ein paar Fresien dabei hätte oder eine Rose. Sehr oft finde ich dann zusätzliche Blumen wirklich sehr schön und sage ja (Änderung des Scopes).
Für die Blumenverkäuferin ist es nachvollziehbar sehr schwer einen individuellen Blumenstrauß zusamenzustellen, wenn der Interessent nicht genau sagt, was er haben möchte (Pflichtenheft). Also berät Sie natürlich den Kunden/Interessenten.

Während ein Blumenstrauß zusammengestellt wird, ergeben sich Änderungswünsche und Verbesserungen. Am Ende kann es sein, dass der Strauß dann doch mehr kostet als die avisierten 20 Euro. Letztendlich war es nur eine grobe Kalkulation. Die Verkäuferin hätte mich vielleicht zwischendurch darauf hingewiesen, dass wir die 20 Euro überschreiten, wenn jetzt noch dies oder das dazukommt.

Am Ende steht eine Arbeitsleistung, die oft nicht dem Scope am Anfang entspricht, aber dennoch ein sehr gutes Endergebnis darstellt und ich als zufriedener Kunde den Blumenladen verlasse. Selbst, wenn ich 25 Euro bezahlt habe.



In der Software Entwicklung, speziell in Projekten, ändert sich der Scope meiner Erfahrung nach sehr oft im Projektverlauf. Einfach weil mit fortschreitenden Zwischenergebnissen/Prototypen die Wünsche und Ideen entstehen ("diese Funktion wäre doch noch nützlich..."). Auch hier wird dann über den Change verhandelt und eine Vereinbarung getroffen. Hier das richtige Maß zu halten zwischen Liefertermin, Kundenzufriedenheit, Qualität und Kosten ist äußerst schwierig.

Sicherlich gibt es für viele Projekte ganz spezifische Regeln und ich will nicht alles verallgemeinern. Dennoch finde ich es in vielen Software Projekten unsinnig alles im Vorfeld auf den Tag genau zu verplanen und einen ganz genauen Endtermin festzulegen. Ich halte das schlicht für unmöglich bei Größenordnungen von 6-18 Monaten sagen zu können, dass ein Projekt am 3.10.2013 fertig ist.

Gerade weil es in Software Projekten viele Changes gibt im Projektverlauf, finde ich es sinnvoller eine Grobplanung und einen Fertigstellungszeitraum zu definieren. Die Elemente der Grobplanung können dann von den einzelnen Teams nochmal detaillierter geplant werden. Auch hier finde ich agile Vorgehensmodelle deutlich erfolgsversprechender, da einfach näher an der Realität gearbeitet wird. Heutzutage wird doch keiner mehr akzeptieren, dass ein Entwicklungsteam sich 1,5 Jahre einschließt und dann etwas "fertiges" präsentiert!

Man stelle sich vor, man geht in einen Blumenladen und sagt nur "20 Euro, und was mit Gerbera. Wann soll ich zum abholen kommen?". Ich möchte nicht wissen, wieviel Ärger es gäbe bei solch einem Vorgehen. Aber denkt bei Eurem nächsten Besuch im Blumenladen nicht an IT Projekte, sondern an diejenige, die Ihr mit den Blumen erfreuen wollt.



Bildnachweis

Das Artikelbild wurde von DomiKetu unter dem Titel „Yellow Blue Green“ auf Flickr unter einer Creative-Commons Lizenz (CC BY-NC-ND 2.0) veröffentlicht.

Keine Kommentare:

Kommentar veröffentlichen