Vor jedem Auftrag stehen Anforderungen und ein Angebot. Und jedes Angebot benötigt einen Preis. In der IT-Branche sind es dann meist die Software-Entwickler, die zur Ermittlung eines Preises vorab den Aufwand zur Umsetzung der Kunden-Anforderungen schätzen, damit der Verkäufer berechnen kann, zu welchem Preis das Produkt letztlich angeboten wird.
Die Qualität und Genauigkeit eines Angebotes ist also unmittelbar von der Qualität der Anforderungen und Aufwandsschätzungen abhängig. Aus diesem Grund sollte jedes IT-Unternehmen nach einer hohen Expertise in den Bereichen Anforderungsmanagement und Aufwandsschätzung streben.
Auswirkungen ungenauer Anforderungen und Schätzungen
Verfügt ein Unternehmen nicht über diese Expertise, kann dies schnell unangenehme Folgen für die Umsetzungsverantwortlichen, das Unternehmen und dessen Kunden haben:
- Ein Projektleiter misst die Leistung eines Entwicklers an falschen Grundlagen (besonders unangenehm bei Unterschätzung). „Warum ist das immer noch nicht fertig?“
- Projekte werden in späteren Phasen unvorhergesehen teurer (so im Fall von Unterschätzung, welche zusätzlich das Risiko auf Schadensersatz mit sich bringt) oder noch vor dem Start aufgrund augenscheinlich schlechten Kosten/Nutzen-Verhältnisses gestoppt oder anderweitig vergeben (so im Fall von Überschätzung).
- Die Entwickler setzen etwas um, was der Kunde überhaupt nicht haben wollte (schlechte Anforderungsqualität)
Dem Unternehmen und dessen Kunden entsteht also ein wirtschaftliches Risiko. Die oben genannten Fälle sind dabei nur ein Ausschnitt der möglichen Folgen.
Wir müssen also „genau schätzen“. Aber wie weit ist das überhaupt möglich?
Manager-Handbuch der NASA für Softwareentwicklung und der „Cone of Uncertainty“
Bereits 1990 veröffentlichte die NASA ein Handbuch für ihre IT-Manager, in dem die Ungenauigkeit früher Aufwandsschätzungen in Softwareprojekten thematisiert wurde (siehe NASA SEL-84-101 „SOFTWARE ENGINEERING LABORATORY SERIES: MANAGER’S HANDBOOK FOR SOFTWARE DEVELOPMENT“).
Später wurde die im Handbuch genannte Abweichung als „Cone of Uncertainty“ bekannt. Die Kenntnis dieser These ist hilfreich für die Beurteilung der Belastbarkeit von Schätzungen. Je vager die Anforderungen des Auftraggebers sind und je früher die Projektphase, umso höher ist die potentielle Schätzungsabweichung.
Was entnehmen wir daraus? Ein Bauunternehmen, welches das 101. Reihenhaus bauen wird, kann relativ genau Kosten und Aufwand abschätzen. Denn: Alle Anforderungen sind bekannt und man verfügt über hohe Erfahrung mit der sich wiederholenden Tätigkeit.
Entwickler hingegen arbeiten in einem sich stetig veränderndem Umfeld. Nicht nur die Ausgangsversion (i.ü.S. der Bauplatz), die Anforderungen (i.ü.S. der Bauplan), sondern auch die Schnittstellen zu Umsystemen (i.ü.S. Anschlüsse an Elektrik, Telekommunikation, Frischwasser & Kanalisation) ändern sich vor und unter Umständen sogar während der Umsetzung der neuen Anforderungen.
Um das Chaos kontrollierbar zu machen, müssen also besondere Methoden eingesetzt werden.
Schätzungen nach der Delphi-Methode
Als Reaktion auf Probleme mit Schätzungen wurde 1963 die Delphi-Methode von der RAND-Corporation entwickelt. Einige Besonderheiten dieser Methode in Kurzform:
Es schätzen mindestens 2 (besser 3+) Personen, denn Eine Person hat nur einen Erfahrungshorizont und Wahrnehmungsfilter. Eine 1-Personen-Schätzung bietet keine Möglichkeit der Qualitätskontrolle bzw. der Diskussion der Anforderung.
Schätzwerte müssen erfasst und parallel offengelegt werden, denn Entwickler beeinflussen sich sonst gegenseitig („Gruppendenken“, „Ankern“)
Weichen zwei Schätzungen weit voneinander ab, müssen die Entwickler ihre Schätzung begründen, denn entweder liegen unterschiedliche Skills bei den Schätzenden vor (und ggf. ist daher auch ein „verdeckter Angstzuschlag“ in der Schätzung enthalten) oder die Anforderung ist nicht genau genug! Trifft letzteres zu, muss die Anforderung überarbeitet und anschließend in einer weiteren Runde erneut geschätzt werden.
Je nach Auftrag kann zwischen Single- und Wideband Delphi gewählt werden, deren Besonderheiten zu erklären an dieser Stelle den Rahmen sprengen würde. Wir kennen nun also einige Fallstricke, die bei Schätzungen umgangen werden sollten. Was aber ist, wenn Schätzungsabweichungen aufgrund schlecht erfasster Kundenanforderungen entstanden sind oder sich Anforderungen während der Umsetzung verändern?
Requirements-Engineering und -Management
Die Qualität von Schätzungen ist maximal so gut wie die Erfassungs-Qualität der zugrunde liegenden Kunden-Anforderungen. Es reicht nicht, die Anforderungen einmal detailliert zu erfassen und anschließende Abweichungen in separaten E-Mails zu diskutieren und zu dokumentieren.
Anforderungen müssen gemanaged werden. Insbesondere Änderungen an Anforderungen müssen auf Ihre Auswirkung auf andere Anforderungen und die Aufwandsschätzung geprüft werden.
Anforderungen, die (z.B. im Zuge eines IT-Projektes) in großer Anzahl zu einem Thema erhoben werden, profitieren darüber hinaus von einer Standardisierung. Ob im klassischen Projektumfeld durch Modellierung von Anwendungsfällen sowie Formulierung von Anforderungen mittels Satzschablonen oder im agilen Umfeld durch das Erheben von User Stories und der dazugehörigen Akzeptanzkriterien. Möglichst geringe Interpretierbarkeit und die konkrete Testbarkeit einer jeden Anforderung sind – neben anderen – wichtige Kriterien für deren Qualität.
genaue Anforderungen = genauere Schätzung
Die Qualität von Anforderung und Schätzung ist untrennbar miteinander verbunden, und doch wird auch nach meisterhaftem Anforderungsmanagement aus einem Entwickler kein Hellseher. Eine Schätzung bleibt immer eine Schätzung. Es gibt jedoch, wie wir gesehen haben, einige Möglichkeiten, mit Expertise das Delta zu verringern.
