Alle Jahre wieder: Aufwandsschätzung vs. Wirklichkeit

16. Dezember 2019


Softwareentwickler sollten ihren Kunden kein Release-Datum versprechen, schrieb der Entwickler Brent Simmons kürzlich in seinem Blog. Es gab viele zustimmende Reaktionen, aber auch dezente Hinweise darauf, dass diese Forderung in der Praxis der meisten Softwareprojekte nicht durchzusetzen ist. Beide Seiten haben recht, finden wir. Für uns war diese Diskussion ein Anlass zur Reflexion: Warum dauern Softwareprojekte oft länger als angenommen und was können wir dagegen tun? (Spoiler: Ehrlichkeit gegenüber sich selbst und dem Kunden, gegenseitiges Verständnis, enge Kommunikation und Pragmatismus sind die Mittel der Wahl.)

Zunächst einmal: Was genau meint Simmons eigentlich?

Simmons hat über einen ganz konkreten Anwendungsfall geschrieben: Endkunden haben auf ihrem Smartphone eine App aus dem App Store installiert und fragen nach einem neuen, zusätzlichen Feature, während sie die App bereits problemlos nutzen. Das neue Feature ist also keine Grundvoraussetzung dafür, dass die App funktioniert, sie fixt keine Bugs oder Sicherheitslücken. Die App ist bereits bezahlt oder sie war von vornherein kostenlos. In diesem speziellen Fall ist es tatsächlich ratsam, keine Schätzungen zur Entwicklungsdauer zu kommunizieren. Denn die Erfahrung zeigt, dass Softwareentwickler die Aufwände mit schöner Regelmäßigkeit zu optimistisch einschätzen und dann die angekündigte Deadline nicht einhalten können. Die Folge: Enttäuschte Erwartungen.

Ein Extrembeispiel aus einer anderen Branche ist der Schriftsteller George R. R. Martin, der das Manuskript für den sechsten Band seiner Fantasy-Reihe „Das Lied von Eis und Feuer“ ursprünglich im Oktober 2015 beim Verlag einreichen wollte. Vier Jahre und einige verflossene Deadlines später ist er – zum Leidwesen seiner Fans – dazu übergegangen, sich in seinen sporadischen Statusberichten auf ein „ist noch in Arbeit“ zu beschränken. Verglichen damit sind die Verzögerungen in Softwareprojekten praktisch nicht der Rede wert. Trotzdem gibt es sie und jede von ihnen ist ärgerlich. Für Kunden und Entwickler.

Warum es meist doch nicht ohne Deadlines geht

Von den vielen, vielen Softwareprojekten fällt nur eine überschaubare Anzahl in die Kategorie „neues Feature zu einer bestehenden App“. Simmons selbst hat das in einem Follow-up zu seinem ersten Beitrag auch noch einmal klargestellt. Wer wie wir von EsPresto ausschließlich im B2B-Bereich arbeitet, kommt aus guten Gründen nicht um Deadlines und vereinbarte Release-Daten herum.

Unsere Kunden beauftragen uns mit der Entwicklung einer Software zur Auftragsverwaltung, eines Webshops oder eines Kundenportals. Sie brauchen diese Software, um ihre eigenen Waren oder Dienstleistungen besser verkaufen zu können und/oder um ihre internen Prozesse zu vereinfachen. Sie wissen, dass ein Verzicht auf moderne Software gleichbedeutend mit einer bedingungslosen Kapitulation vor ihren Mitbewerbern wäre. Darum sind sie bereit, uns für die Softwareentwicklung entsprechend zu bezahlen.

Deswegen haben sie aber auch einen berechtigten Anspruch darauf, dass sie die bestellte Software ab einem bestimmten Zeitpunkt nutzen können. Dieser Tag X wird in der Regel auch von Faktoren bestimmt, die mit der Softwareentwicklung an sich erst mal nichts zu tun haben. Den Webshop-Relaunch eines Einzelhändlers mitten ins Weihnachtsgeschäft zu legen, ist z.B. keine gute Idee (vorsichtig ausgedrückt). Bei der Ablösung einer Standardsoftware gilt es zu beachten, für welchen Zeitraum noch Lizenzgebühren für das Altsystem bezahlt werden müssen (und wie lange das Unternehmen dazu noch bereit ist). Der Launch eines neuen Onlineportals muss von einer PR-Kampagne angekündigt werden, damit die potentiellen Kunden rechtzeitig davon erfahren – und natürlich muss das Portal an genau diesem Tag dann auch funktionieren, sonst ist die ganze Investition futsch.

Die Aufwandsschätzung: Wie lange wird es dauern?

Bevor Softwareentwickler wie wir dem Kunden ein Angebot schreiben und ein Release-Datum nennen, müssen sie eine Anforderungsanalyse mit Aufwandsschätzung machen: Was will der Kunde (und wozu)? Welche Komponenten muss die Software haben (z.B. Anzahl der Dashboards und Menüs, Nutzerrollen, Eingabeformulare, Schnittstellen zu anderen Anwendungen, PDF-Erstellung, Exportfunktionen, Rechnungserstellung, E-Mail-Benachrichtigungen, …)? Welche Technologie verwenden wir? Wie lange brauchen wir für die einzelnen Komponenten? Auf dieser Grundlage wird das Angebot kalkuliert und die Umsetzungszeit berechnet.

Kalender in Nahaufnahme

Nehmen wir mal an, Entwickler schätzen den Entwicklungsaufwand für ein zusätzliches Features einer bestehenden Anwendung. Keine Kleinigkeit, die man so eben ins Programm einfügt, aber in fünf Tagen kriegt man das hin. „Fünf Tage“ in einer Aufwandsschätzung heißen „fünf Personentage“, also „fünf mal acht Stunden“. Das entspricht zwar einem Arbeitstag, aber niemand verbringt seinen Arbeitstag ausschließlich mit der Arbeit an einem einzigen Projekt. Innerhalb der Arbeitszeit lesen Entwickler auch E-Mails, sitzen in Besprechungen, halten einen kleinen Plausch neben der Kaffeemaschine, helfen einem Kollegen bei einem Problem oder arbeiten die Hälfte des Tages noch an einem anderen Projekt. Sprich: Mit einem Entwickler allein ist das Projekt nicht innerhalb einer Woche zu schaffen. Doch in der Regel arbeiten sowieso mindestens zwei Entwickler gemeinsam an einem Projekt, und damit scheint die Umsetzung innerhalb einer Woche doch realistisch zu sein. Oder?

Warum es dann doch länger dauert

Das entscheidende Wörtchen an dieser Stelle ist „scheint“. Zwei Entwickler setzen ein Projekt eben nicht doppelt so schnell um wie ein einzelner Entwickler. Schneller, ja, aber nicht doppelt so schnell. Zwar können sie teilweise parallel arbeiten, d.h. Entwickler A kümmert sich um Feature X und Entwickler B entwickelt währenddessen Feature Y. Doch wenn X die Voraussetzung für Y ist, dann kann B erst loslegen, wenn A fertig ist. Klar, so etwas kann man bei der Berechnung des voraussichtlichen Release-Datums berücksichtigen, aber nie zu 100%, weil so manche Abhängigkeit erst während der Entwicklung sichtbar wird. Das gilt erst recht für Projekte zur Ergänzung, Verbesserung oder Integration bestehender Softwarelösungen. Je komplexer das Programm, desto mehr Abhängigkeiten verstecken sich im Code – es ist praktisch unmöglich, sie alle von vornherein zu bedenken. Das Ergebnis: es dauert länger.

Hinzu kommt noch ein sehr wichtiger, wenn nicht der wichtigste Faktor, der das Projekt in die Länge zieht: Alle Beteiligten in einem Softwareprojekt – Entwickler und Kunden – sind Menschen, keine Roboter. Menschen haben ab und zu Urlaub oder werden krank. Sie haben gute und schlechte Tage. Menschen neigen zu Betriebsblindheit: Sie denken nicht immer daran, dass andere Menschen andere Prozesse und Abläufe gewohnt sind. Entsprechend vergessen Kunden wichtige Kleinigkeiten in ihren Anforderungen und die Softwareentwickler denken bei der Aufwandsschätzung wichtige Details nicht mit. Dinge funktionieren nicht so wie gedacht. Es gibt Missverständnisse in der Kommunikation. Das Ergebnis: es dauert länger.

Wie können wir besser schätzen?

Eine gewisse Diskrepanz zwischen dem geschätzten Aufwand und der Realität des Projekts ist also praktisch unvermeidbar (das gilt übrigens nicht nur für Softwareprojekte und Fantasyromane). Entscheidend ist es, die Abweichung möglichst gering zu halten. Wie das geht? Simmons hat dazu das wesentliche schon geschrieben: „Pay attention to history and avoid wishful thinking. Don’t assume perfect productivity. Allow for the unexpected, because there’s always something.“

Die erste und wichtigste Maßnahme lautet: Vorsichtiger schätzen. Selbst wenn eine komplexe Komponente wie z.B. eine Rechteverwaltung schon mal in einem früheren Projekt enthalten war, bedeutet das nicht automatisch, dass sie im neuen Projekt ein Sonntagsspaziergang wird. Viel wahrscheinlicher ist es, dass die Umsetzung ähnlich viel Haareraufen und Zähneknirschen mit sich bringt wie beim letzten Mal.

Im nächsten Schritt sollte man bei der Umrechnung der Personentage in einen Zeitplan für die Umsetzung ausreichend Puffer mitdenken. Sind bald wieder Schulferien (Urlaub!) oder Feiertage? Können bei Bedarf weitere Kollegen einspringen oder sind in den anderen Kundenprojekten demnächst ebenfalls größere Aufwände zu erwarten?

Zeit ist Geld und Zeit ist Qualität

Für den Kunden bedeutet eine solche sehr vorsichtige Schätzung allerdings, dass das Angebot eine deutlich längere Wartezeit auf die Einsatzfähigkeit der Software beinhaltet als gedacht. Außerdem schlagen sich mehr Personentage natürlich auch im Angebotspreis nieder. Das ist für den Softwareentwickler ein Dilemma: Ist der Angebotspreis zu hoch, entscheidet sich der Kunde womöglich für den Mitbewerber, der das Projekt schneller und günstiger umzusetzen verspricht (höchstwahrscheinlich wird dieser Mitbewerber doch länger brauchen (s.o.), aber er ist trotzdem derjenige, der den Auftrag bekommen hat). Geht er aber mit dem Angebotspreis wieder runter, wird das Projekt für ihn selbst mit jedem zusätzlichen Tag unwirtschaftlicher. Wie lässt sich das lösen?

Die gute Nachricht an dieser Stelle ist: Die allermeisten Kunden wissen, dass Softwareentwicklung eine komplexe Angelegenheit ist und Qualität ihren monetären und zeitlichen Preis hat. Je mehr der Kunde davon überzeugt ist, dass die Softwareentwickler seinen konkreten Bedarf verstanden haben, desto mehr wird er ihrer Aufwandsschätzung vertrauen. Offenheit und Ehrlichkeit schaffen dieses Vertrauen – besonders dann, wenn die Entwickler von sich aus Vorschläge machen, wie sich die Komplexität und damit Aufwand und Kosten wieder reduzieren lassen. Eine Anforderung kann vielleicht mit weniger ausgefeilten Funktionalitäten als angefragt zufriedenstellend umgesetzt werden. Müssen es wirklich Push-Benachrichtigungen sein oder reichen fürs erste automatische E-Mails?

Bei besonders umfangreichen Projekten kann es sinnvoll sein, sie in kleinere Teilprojekte aufzusplitten. Das hat mehrere Vorteile: Zum einen erhält der Kunde zu einem früheren Zeitpunkt eine einsatzfähige Software, die die am dringendsten benötigten Funktionalitäten abdeckt; weitere Funktionalitäten kommen in der Folgezeit etappenweise hinzu. Zum anderen lassen sich so auch die Kosten für die Softwareentwicklung über einen längeren Zeitraum und ggf. mehrere Jahresbudgets verteilen.

__

Noch eine gute Nachricht: In der Zukunft wird alles besser. Im 24. Jahrhundert laufen die Aufwandsschätzungen nämlich grundsätzlich folgendermaßen ab: „Mister La Forge, wann haben Sie den Warp-Antrieb wieder online?“ „Geben Sie uns zehn Stunden, Captain.“ „Sie haben fünf Stunden Zeit.“ „Aye, Captain!“ Natürlich dauert es dann weder fünf noch zehn Stunden, sondern nur knapp 45 Minuten, bis die Enterprise wieder mit Warp 5 durch die unendlichen Weiten fliegt. 😉