Der Cone of Uncertainty, beschrieben von Steve McConnel, zeigt, was jeder erfahrene Software-Profi weiß. Zu Beginn eines jeden Projekts wissen wir nicht genau, wie lange ein Projekt dauern wird.
Die Gründe dafür sind vielfältig. Keine zwei Projekte haben jemals:
- die gleichen Anforderungen.
- die gleichen Leute.
- den gleichen geschäftlichen Kontext.
- die gleiche Technologie.
- die gleichen Prioritäten &Zwänge.
Jedes ist einzigartig. Jede Codezeile ist handgefertigt. Und Wissensarbeit, an der kluge, kreative Menschen beteiligt sind, ist nicht so präzise wie das Graben von Gräben.
Aber genau das wird verlangt. Die Geldgeber wollen genau wissen, wann das Projekt abgeschlossen sein wird und wie viel es kosten wird.
Der Umgang mit diesem Rätsel ist fast so alt wie die Zeit selbst. Hier sind einige Möglichkeiten, wie Teams und Unternehmen mit dieser Ungewissheit umgehen.
Mit dem Kegel umgehen
Den Kostenvoranschlag erhöhen
Wenn man den Stachel der Unterschätzung spürt, besteht eine häufige Reaktion darin, den Kostenvoranschlag beim nächsten Mal zu verdoppeln oder zu verdreifachen. Das senkt zwar das Risiko im Vorfeld, aber es ist schwieriger, als es klingt.
Wenn Sie eine zu hohe Zahl angeben, werden sich die Geldgeber sträuben und Ihr Projekt nicht genehmigen. Bei einer zu niedrigen Zahl besteht die Gefahr, dass Ihnen das Geld ausgeht. Das wird doppelt brenzlig, wenn man sich an Ausschreibungen beteiligt, bei denen der Druck, die Zahlen niedrig zu halten, noch größer ist.
Die meisten Projekte fügen den endgültigen Zahlen eine Art Polsterung hinzu, um sich genügend Spielraum zu verschaffen. Außerdem können Teams dieses Projekt mit anderen vergleichen.
Das Projekt relativ dimensionieren
Menschen sind wirklich gut darin, Dinge relativ zu dimensionieren. Wir können nicht genau sagen, wie groß ein Stein ist. Aber wir können sagen, wie groß er im Vergleich zu etwas anderem ist. Das können wir auch bei der Größenbestimmung von Projekten nutzen.
Sein Sie offen und ehrlich
Agiles Standardarbeitsweise ist Transparenz und Sichtbarkeit. Es sollte also nicht überraschen, dass die agile Art, mit dem Kegel umzugehen, darin besteht, offen und ehrlich zu sein.
Sehen Sie. Wir wissen nicht, wie lange das dauern wird. Das ist unsere beste Schätzung. Aber wenn Sie uns ein paar Iterationen geben, können wir etwas bauen, messen, wie lange das dauert, und Ihnen dann ein viel besseres Gefühl dafür geben, wie groß diese Sache ist.
Ein anderer Ansatz, den einige agile Teams wählen, um die Unsicherheit zu kommunizieren, ist die Darstellung der Schätzungen als Bereich.
Dies hat den Vorteil, dass den Sponsoren die Ungewissheit, die mit dem Projekt einhergeht, deutlich vor Augen geführt wird und sie dann entscheiden können, wie viel Risiko sie auf sich nehmen können.
Inkrementelle Finanzierung
Ein weiterer Ansatz, der sehr sinnvoll ist, den ich aber leider nicht oft genug angewandt sehe, ist die inkrementelle Finanzierung.
Bei der inkrementellen Finanzierung wird nicht der ganze Geldbeutel im Voraus verlangt. Nur so viel, dass man genug von der Arbeit hat, um eine genauere Aussage darüber machen zu können, wie lange es dauern wird.
Das ist nicht narrensicher. Man kann später immer noch Probleme bekommen. Aber wenn man den Teams 30-50.000 Dollar gibt, sie etwas bauen lässt und dann sieht, wie lange es dauert, kann man die Abweichung bei dieser Zahl im Vorfeld deutlich verringern.
Mehr über diese Art der Planung und die Vorteile, die sie mit sich bringt, können Sie in Beyond Budgeting
Die eigentliche Ursache
Wir leben in einer Welt der jährlichen Budgets. Und leider ist dies der Grund für viele Spannungen und Dramen an unserem Arbeitsplatz. In gewisser Hinsicht sind Jahresbudgets natürlich (wir leben und verfolgen die Zeit in jährlichen Zyklen), aber in anderer Hinsicht sind sie schrecklich für die Planung, da ein Jahr auf dem Markt eine lange Zeit ist.
Wenn Sie sich von dem Kegel der Ungewissheit irritieren lassen, denken Sie daran, dass der Sinn der Software-Schätzung darin besteht, festzustellen, ob das Projekt überhaupt möglich ist.
Oder wie Steve McConnell sagt:
Der Hauptzweck der Software-Schätzung besteht nicht darin, das Ergebnis eines Projekts vorherzusagen, sondern festzustellen, ob die Ziele eines Projekts realistisch genug sind, um das Projekt so zu steuern, dass sie erreicht werden können.
-Steve McConnell, Software Estimation: Entmystifizierung der schwarzen Kunst