Ausgangspunkt dieses Beitrags ist ein heise-Artikel von Golo Roden über Softwareschätzungen und ihre notorische Unzuverlässigkeit. Der Originalartikel ist hier verlinkt: Won’t fix! – Teil 1.
Kaum ein Thema sorgt in Softwareprojekten so zuverlässig für Reibung wie Aufwandsschätzungen. Kunden wollen wissen, wann etwas fertig ist und was es kostet. Teams geben Zahlen ab, obwohl sie oft wissen, dass diese Zahlen auf wackeligem Boden stehen. Später wird aus der Schätzung eine Erwartung, aus der Erwartung ein Versprechen und aus dem Versprechen ein Konflikt.
Das Problem ist nicht nur schlechte Planung
Der entscheidende Punkt: Softwareentwicklung ist keine Fertigung. Bei einer Serienproduktion kann man Abläufe messen, wiederholen und optimieren. Software entsteht anders. Sie ist ein Prozess des Verstehens, Entscheidens und Entdeckens. Am Anfang eines Projekts ist häufig noch nicht klar, worin das eigentliche Problem besteht. Genau dieses unbekannte Problem soll dann aber bereits zeitlich beziffert werden.
Das erklärt, warum selbst erfahrene Teams regelmäßig danebenliegen. Nicht weil sie unfähig sind, sondern weil sie etwas vorhersagen sollen, das sich erst während der Arbeit vollständig zeigt. Eine Spezifikation ist eher eine Karte als eine Route. Sie zeigt die grobe Richtung, aber nicht alle Hindernisse, Abzweigungen und Umwege.
Menschen schätzen systematisch zu optimistisch
Dazu kommt Psychologie. Wir unterschätzen Risiken, hängen an der ersten genannten Zahl und rechnen gern mit dem idealen Verlauf. In der Praxis fehlen in Schätzungen oft genau die Dinge, die ein Feature wirklich produktionsreif machen: Tests, Debugging, Reviews, Integration, Dokumentation und Deployment.
Auch der Reflex, verspätete Projekte einfach mit mehr Leuten zu besetzen, hilft nur begrenzt. Mehr Personen bedeuten nicht nur mehr Kapazität, sondern auch mehr Abstimmung, mehr Übergaben und mehr Reibung. Ab einem bestimmten Punkt wird das Projekt dadurch nicht schneller, sondern schwerfälliger.
Was stattdessen hilft
Schätzungen verschwinden nicht. Budgets, Termine und Prioritäten brauchen Orientierung. Aber die Form der Orientierung sollte ehrlicher werden.
- Schätzungen nicht als Zusagen behandeln: Eine Schätzung ist eine Annäherung unter Unsicherheit, kein Vertrag mit der Realität.
- Kleine Arbeitspakete schneiden: Je kleiner die Einheit, desto schneller entsteht echtes Feedback.
- Fortschritt messen statt Zukunft behaupten: Historische Durchlaufzeiten sind oft belastbarer als Bauchgefühl.
- Wahrscheinlichkeiten statt Einzeltermine nutzen: Eine Spanne mit Konfidenz ist ehrlicher als ein scheinbar exaktes Datum.
- Iterativ entscheiden: Nicht nur fragen, wann alles fertig ist, sondern regelmäßig prüfen, ob der nächste Schritt noch Wert liefert.
Mein Fazit
Softwareschätzungen sind nicht wertlos. Gefährlich werden sie, wenn Organisationen sie wie feste Zusagen behandeln. Gute Projektsteuerung beginnt nicht mit der perfekten Zahl, sondern mit einem reifen Umgang mit Unsicherheit.
Die bessere Frage lautet deshalb oft nicht: „Wann ist alles fertig?“ Sondern: „Was können wir als Nächstes liefern, das echten Wert schafft, und was lernen wir daraus?“