PHP-Consulting.de

Über PHP und Consulting

Das Henne-Ei-Dilemma in der Aufwandsschätzung

Die Praxis zeigt, eine realistische Aufwandsabschätzung ist eigentlich erst möglich, wenn ein Projekt schon realisiert wurde. Dann hat sie aber ihren Sinn verloren und ist auch keine Aufwandsschätzung mehr. Wir stecken somit in einem Henne-Ei-Dilemma.

Das Problem

Um Aufwand abschätzen zu können, muss natürlich erstmal der Umfang des Projekt vorliegen. Sprich: Die Anforderungen müssen klar sein.

Gerade das ist im Detail aber im Vorhinein oft nicht möglich. Aus zeitlichen oder organisatorischen Gründen oder weil die nötigen Fragestellungen eben oft erst auftreten, wenn man das Konzept im Detail umzusetzen versucht.

Somit müsste man also das Konzept so genau wie möglich fassen. In schriftlicher Form ist dies nur bis zu einem bestimmten Grad sinnvoll, denn sonst verliert sich schnell das Wesentliche in der Masse an Text.

Grafisch kann man weiter gehen: Anwendungsdiagramme (auch Use-Case-Diagramme) für die Grobstruktur, Entwürfe für Oberflächen, klickbare Mock-Ups/Wireframes oder sogar ganze Prototypen.

Ein Prototyp kann, durch seine nähe zum fertigen Produkt, schon eine Fülle von Detail-Anforderungen offenbahren. Dementsprechend hat er aber auch schon einen hohen Eigenaufwand. Wegwerf-Prototypen sind aus diesem Grund eigentlich zu schade. Mehr Sinn machen sie als Vorstufe zum Endprodukt.

Unser eigentliches Ziel war ja aber, eine genaue Aufwandsschätzung im vorhinein. Wenn nun aber, für eine perfekte Aufwandsschätzung, erst das Endprodukt ausprogrammiert werden müsste, ist die Aufwandsschätzung ja nur noch eine Aufwandsmessung und unser Ziel verfehlt. Wir stecken also im besagten Henne-Ei-Dilemma.

Schätzung bleibt Schätzung

Also muss man wohl das Wort “Schätzung” in “Aufwandsschätzung” akzeptieren. Das Ergebnis bleibt also immer eine Näherung, ermittelt aus Erfahrungswerten und Intuition.

Hat man nur eine grobe Idee als Anforderung, ist die Schätzung ungenau. Möchte man es genauer, muss schon viel Aufwand nur für Konzeption und Prototyping eingesetzt werden.

Für jede Schätzung bleibt also nur die Möglichkeit, einen dem Projekt entsprechenden Mittelweg zu wählen.

Alternativer Lösungsweg

Eine Alternative besteht darin, das Dilemma mit in die Lösung einzubeziehen.

Dabei wird bewusst die Planung flach und einfach gehalten, und konzentriert sich um so mehr auf eine schnelle Entwicklung eines, in grundzügen benutzbaren, Prototypen. Dieser wird dann in weiteren Entwicklungsschleifen laufend analysiert und erweitert.

Dieses Vorgehen, konzentriert die Entwicklungsarbeit von sich aus auf das Wesentliche, auf einen gut funktionierenden Grundprozess.

Dinge entscheidet man erst dann, wenn es nötig ist. Man vermeidet es, Details schon festlegen zu wollen, wenn sie noch gar nicht überblickt werden können. Neue Anforderungen die sich erst während der Entwicklung abzeichnen, vielleicht sogar sehr wichtig sind, kann man flexibel einarbeiten. Andere Ideen aus der ursprünglichen Planung, erweisen sich manchmal als weniger wichtig und man stellt sie zurück.

Fazit: Realistischere Weg?

Das Henne-Ei-Problem ist somit auch hier nicht gelöst. Es bleibt nur sich zu arrangieren.

Der konventionelle Weg scheint mehr Vorhersehbarkeit und Sicherheit zu bieten, diese existiert aber oft sowieso nur in der Theorie. Denn die Praxis zeigt, das der alternative Weg näher an der Realität liegt, wie Projekte durchschnittlich verlaufen. Somit kann dieser Weg im Ende sogar mehr Vorhersehbarkeit bieten, nämlich das eben gerade vieles ungeplant passiert.

Für alle beteiligten bietet dieser Weg mehr Flexibilität sich auf das Wichtigste zu konzentrieren: Ein gutes und passendes Produkt.

One Response to “Das Henne-Ei-Dilemma in der Aufwandsschätzung”

  1. Adam says:

    Kunden haben von Softwareentwicklung meistens leider keine Ahnung. Dementsprechend schwierig gestaltet sich auch die Aufwandsabschätzung.

    Ständig kommen neue Anforderungen hinzu oder bei der Entwicklung treten Fragen auf, an die der Kunde selbst vorher auch nicht gedacht hat.

    Immer wieder beobachte ich in der Entwicklung den Pareto-Effekt:

    80% des Aufwands sind in 20% der Zeit zu bewältigen.

    Umkehrschluss: für die restlichen 20% wird 80% der Zeit benötigt.

    Ich versuche also, wie beschrieben schnell einen einfachen Prototypen zu entwickeln und setze dann immer neue Meilensteine.

    Das Problem ist, dass der Kunde gerne vorab schon einen Preis für das Produkt hätte und dies ist ohne vernünftige Aufwandsabschätzung nur schwer realisierbar…

Leave a Reply