Wie lange braucht das Feature XY? Aufwandsschätzungen für Projektleiter

Die übliche Situation: Marketing, Operations und Technik sitzt zusammen in einem Raum. Die nächsten Entwicklungsschritte sollen durchgesprochen werden. Dann kommt wie immer die Frage: wie lange braucht denn das Feature XY? Kann man nicht Feature AB zusammen mit CD noch in den nächsten Meilenstein schieben? Wenn wir Feature EF schaffen vor Weihnachten dann kauft der Grosskunde G das Produkt und wir werden alle reich und berühmt.

Leider ist die Schätzung von Entwicklungszeiten gar nicht so einfach. Ein paar Gedanken dazu:

- Jemand (ich glaube es war Edward Yourdon) hat sich mal die Mühe gemacht in IT-Projekten die Diskrepanz zwischen Zeitschätzungen und der eingetretenen Realität zu vergleichen. Die Kernergebnisse: mit einer funktionalen Spezifikation sind die Aufwandsschätzungen im Durchschnitt Faktor 4 zu niedrig. Mit einer technischen Spezifikation fällt die Fehlerquote auf “nur” Faktor 1,5. Erschreckend.

- Häufig basiert eine Schätzung des Projektleiters auf: Wie lange dauert es, wenn wir dieses Feature genau so bauen wie ich es mir vorstelle, ein bisschen testen und dann gehts rund. Nicht auf: diese Änderung kommt noch rein, dies soll doch anders sein und an dieser Stelle fehlt noch die Spezifikation. Diese Art von Problemen bremsen immer. Man könnte natürlich alles vorspezifizieren lassen und erst dann losprogrammieren, NASA-style. Andererseits leben ja gerade Startups oft von der Dynamik und der schnellen Entwicklung. Was ich aber gelernt habe, ist dass man strikt verweigern muss, wenn die Entwickler a) sich das Feature selbst ausdenken sollen oder b) selbst designen sollen. Das geht meistens schief. Nicht, weil die Entwickler das nicht können. Aber was nicht im Dialog entsteht wird selten direkt akzeptiert und erfordert meistens zeitraubende Umbauarbeiten. Für solche Issues gibt es bei uns im issue tracking system übrigens den Status “crap”.

- Interdependenzen zwischen Features werden bei Schätzungen zumeist unterschätzt. Zudem erhöht sich die Komplexität bei vielen Features oft exponentiell und nicht linear. Einem grossen System ein neues Feature hinzuzufügen ist oft wesentlich schwieriger als bei einem kleinen Projekt. Gerade wenn keiner mehr so richtig überblickt, wie alles zusammenhängt, was irgendwann passiert.

- Als Projektleiter kann man an drei Stellschrauben drehen um zu bestimmen wann ein Projekt fertig wird: Features, Teamgröße und Qualität. An der Qualität kann man nur bis zu einem bestimmten Punkt schrauben. Klar, man kann testing und dokumentation vernachlässigen. Aber irgendwann rächt sich das. Man kann versuchen neue Teammitglieder einzustellen und die einzulernen. Aber bis die ausgewählt, eingelernt und produktiv sind, vergehen oft Monate. Das wichtigste Instrument ist den Feature-Umfang zu reduzieren. Am besten die Features aufteilen in “brauchen wir unbedingt”, “wäre schön” und “wenn uns dann noch langweilig ist”. Und dann schön mit den kritischen, schwierigen Features anfangen und lockere, leichte Übungen für das Ende aufbewahren.

Dann weiterhin frohes Arbeiten noch,

Jan

P.S. Ich wurde von einem Leser angesprochen, warum ich denn so selten Schreiben würde. Ich versuche mir etwas mehr Mühe mit meinen Posts zu geben, dafür gibt es halt weniger. Ich hoffe das passt so. Ich bin übrigens sehr glücklich über meine mittlerweile 100 Feed-Abonnenenten. Danke fürs Lesen!

This entry was posted on Montag, September 3rd, 2007 at 11:59 pm and is filed under Managing Teams. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.