Aufwandsschätzung in der Softwareentwicklung: Worauf man achten sollte
Oftmals wird der Aufwand von vielen Seiten einfach unterschätzt (oder vielleicht auch unterbewusst oder mit Absicht):
- Vertriebler: geben meistens eine geringere Aufwandschätzung ab, um so das Projekt für sich und die eigene Firma gewinnen zu können. (“Später kann man ja noch nachverhandeln”)
- IT’ler: Softwareentwickler können den Aufwand zwar relativ gut abschätzen. Aber wenn ein Softwareentwickler und ein Kunde (oftmals ein Nicht-IT’ler) miteinander sprechen können schnell Missverständnisse entstehen. “Ich möchte sowas wie Facebook” “Oder sowas wie Amazon” kann alles und nichts bedeuten.
- Nicht-IT’ler: Oftmals ist diese die Kundenseite, die nicht weiss was für ein Aufwand Softwareentwicklung bedeutet. Schlimm ist auch, dass oftmals ein Webentwickler (als Auftraggeber einer App) nicht weiss wieviel Aufwand eine App Entwicklung mit sich bringt. Weil sich auch diese Bereiche (Web und Mobile) zum Teil komplett unterscheiden.
Zudem ist alles, besonders bei der Aufwandsschätzung von Softwareprojekten, sehr politisch.
1) Beispiel: “Kunde möchte sein Budget nicht offen legen, so dass er/ sie einen besseren Preis vom Dienstleister erhält”
Das ist ein Klassiker.
Jedoch ist es, als ob der Entwickler einen Dartpfeil auf eine Dart-Scheibe wirft und hofft die richtige Zahl zu treffen.
Da ein Grossteil der Anfragen ohne Budgetvorgabe kommt, wird der Aufwand so niedrig berechnet wir nur möglich, um so die Chance zu haben, dass Projekt zu erhalten.
Nachdem man das Projekt gewonnen hat und mitten in der Programmierung steckt, sieht man dann, dass es mehr Zeit benötigt.
Wicht ist auch: Wenn jemand 10′000 Euro hat, dann lässt sich damit eben nur sagen wir mal 100 Stunden programmieren (10′000 Euro geteilt durch 100 Euro Stundensatz). Wenn man 100′00 Euro hat, dann kann man 1000 Stunden programmieren. Dass macht einen grossen Unterschied.
Tipp: Mit dem Dienstleister eine gute und transparente Beziehung aufbauen und das Budget offenlegen.
2) Beispiel: “Softwareentwickler möchte nicht als – lazy – dastehen”
Der Chef oder der IT Leiter gibt dem Softwareentwickler eine Aufgabe.
Der Entwickler weiss, dass die Aufgabe zirka 4 Mannmonate braucht. Wenn er dass jedoch dem Management sagt, dann kommen nur negative Kommentare zurück, oder aber das Management könnte sich denken “der Entwickler schätzt doch nur soviele Stunden, damit er/ sie es ganz einfach vor sich hin programmieren kann”.
Besonders bei jüngeren Entwicklern kommt es meistens dazu, dass diese dann geringere Aufwände weitergeben. Aus den 4 Mannmonaten werden dann schnell mal 120 Stunden Aufwand.
3) Beispiel: “Der Chef gibt dem Team Vorgaben wieviel Aufwand es sein darf”
In manchen Fällen ist der Chef (zum Beispiel bei einem IT Dienstleister oder innerhalb einer IT Abteilung) nicht wirklich in der Thematik des Projektes drinnen. Jedoch hat er/ sie die Vorgabe vom Kunden, dass das Budget nur sagen wir mal 20′000 Euro (d.h. 200 Stunden Arbeit) sein darf.
Die Anforderungen werden dann an die Entwickler weitergegeben. Diese finden jedoch heraus, dass es weit mehr Stunden braucht (sagen wir mal 500 Stunden).
Der Chef wird nun Anweisungen an das Team machen, die Stunden künstlich runterzubringen (Stundensatz Verringerung, Funktionalitäten Reduzierung, etc.).
Das Projekt wird so zwar gewonnen. Im Laufe des Projektes wird dann jedoch wiederum der Kunde Einwände bringen, warum die Anforderungen nicht so erfüllt wurden, wie das anfänglich besprochen wurde.
Und so muss der Aufwand zu diesem Punkt wieder nachkalkuliert werden. Diesmal am besten mit realistischen Zahlen.
Tipp: Die Entwickler sollten das letzte Wort über den Aufwand haben. Nicht das Management, dass nicht in der Thematik ist.
Manchmal weiss man es auch gar nicht!
In manchen Fällen kann man den Aufwand auch gar nicht genau wissen. Das kann viele Gründe haben:
- a) Es ist ein relativ neues System und es gibt keine vergleichbare Software auf dem Markt: Hier müsste das Team eine elaborate Studien-Phase haben, um herauszufinden wie man das Ganze programmiert (das kann wiederum zum Zweifel über die Fähigkeiten des IT Dienstleister führen). Oder man gibt einfach eine Zahl an Stunden an, und fängt dann mit der Programmierung an.
- b) Der Kunde weiss noch gar nicht was alles Teil der Software ist: Meistens hat der Kunde zwar schon eine grobe Idee, was er/ sie haben möchte. Er wird jedoch meistens erst nach den ersten Programmierrunden feststellen “Oops, da habe ich ja was übersehen”, oder “Das habt Ihr aber vergessen mit reinzunehmen, dass wollte ich von Anfang an”.
Tipp: Bei neuen Systemen oder bei Projekten bei welchen der Aufwand nicht vorher bestimmbar ist, lohnt sich der Agile Ansatz, bei welchem man von Anfang an in kleinen Abständen (zum Beispiel monatlich) funktionierende Software abliefert. Der Aufwand ist bei Agile nicht fix, daher lohnt sich das eher für grössere Unterfangen.
Fazit
Softwareentwicklung ist zum Teil noch komplexer als zum Beispiel ein Hausbau. Beim Hausbau kennt man die Anforderungen im Detail und kann einen relativ genauen Aufwand berechnen.
Softwareentwicklung ist leider eher sowas wie das Berliner Flughafenprojekt (BER). Es gibt sehr viele Variablen (Welche Software und Technologien sollte man nutzen? Welche Funktionalitäten sollen dabei sein und welche nicht? Was ist der Kunde bereit auszugeben? Wie fähig sind die Programmierer die an dem Projekt sitzen? Wie gut wird die Kommunikation sein? Sind die Anforderungen richtig aufgenommen worden?)
Bei IT Projekten sollte man daher am besten immer nach John Gall’s Law arbeiten:
A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.
Einfach übersetzt: Klein und mit einem System geringer Komplexität arbeiten und dann aufbauend auf dem funktionierenden System weiterarbeiten.
Ich fand auch die Antwort von Joachim Pense auf Quora interessant:
Man sieht die Luftlinie und denkt nicht an die vielen kleinen Kurven und Umwege.
Oder die dortige Antwort von Peter Rainer:
Dafür gibt es mehrere Gründe – der Hauptgrund ist wohl, dass meist auf Spezifikation + Testing vergessen wird – die Entwicklung selbst macht selten mehr als 40% des Gesamtaufwandes aus.
Hier auch ein paar interessante Beiträge:
Ein paar Tipps für Entwickler im Bereich Aufwandsschätzung
Warum sich Softwareentwicklung nicht bestimmen lässt
Freue mich auf einen Austausch.
Viele Grüsse
Sascha Thattil
Der Autor: Sascha Thattil arbeitet bei YUHIRO und hilft Unternehmern und Unternehmen beim einfachen Aufbau von Programmier-Teams in Indien. YUHIRO ist ein deutsch-indisches Unternehmen welches IT Firmen, Agenturen und IT Abteilungen Softwareentwickler bereitstellt.
Schreibe einen Kommentar