Aufwandsschätzung für Web-App-Festpreise: Drei-Punkt-Methode mit Rechenbeispiel

Eine Aufwandsschätzung trägt einen Festpreis erst, wenn drei Dinge zusammenkommen: Ein eingefrorener Scope mit schriftlichen Annahmen, drei Werte pro Position statt einem, und ein Puffer, der aus der Streuung dieser Werte berechnet wird — nicht pauschal obendrauf. Fehlt eines davon, ist der Festpreis eine Wette. Sie geht meistens zulasten dessen, der sie nicht durchgerechnet hat.

Unten steht die Rechnung dazu: Eine Beispielkalkulation über elf Positionen, die Zerlegung der Streuung auf die Module, ein Score, mit dem Sie vorab prüfen, ob Ihr Vorhaben überhaupt festpreisfähig ist — und die Stelle, an der ich selbst keinen Festpreis mehr anbiete.

Warum eine einzelne Stundenzahl keinen Festpreis trägt

Wer pro Position nur einen Wert notiert, notiert den wahrscheinlichsten Fall. Der wahrscheinlichste Fall ist aber nicht die Mitte der möglichen Ausgänge. Nach unten ist der Spielraum begrenzt — schneller als „läuft glatt durch" geht es nicht. Nach oben ist er offen: Eine undokumentierte Schnittstelle, ein zweiter Entscheider, ein Altbestand, der anders aussieht als die Beschreibung.

In der Beispielkalkulation weiter unten summieren sich die „wahrscheinlichen" Werte auf 236 Stunden. Der Erwartungswert derselben Positionen liegt bei 254,3 Stunden. Die Differenz von 7,8 Prozent ist kein Puffer und kein Risikoaufschlag. Sie ist die Korrektur eines Rechenfehlers, der vor jedem Risiko fällig wird.

Drei-Punkt-Schätzung: Das Rechenbeispiel

Beispiel ist ein Terminportal für eine Praxis: Patienten buchen selbst, das Team pflegt Sperrzeiten, Termine laufen in den vorhandenen Praxiskalender. Jede Position bekommt drei Werte — optimistisch (o), wahrscheinlich (m), pessimistisch (p). Daraus:

• Erwartungswert: E = (o + 4m + p) / 6
• Streuung der Position: σ = (p − o) / 6

Die Spanne zwischen bestem und schlechtestem Fall liegt bei Faktor 3 (144 zu 438 Stunden). Wer diese Spanne nicht kennt, kann keinen Preis dafür nehmen, sie zu tragen.

Knapp 58 Prozent der Streuung stecken in drei Positionen

Die Gesamtstreuung ist nicht die Summe der Einzelstreuungen, sondern die Wurzel aus der Summe der Quadrate: √246,2 = 15,7 Stunden. Das ist der Unterschied zwischen Bauchgefühl und Rechnung. Wer jede Position einzeln um ihre eigene Streuung puffert, addiert 49 Stunden. Die gemeinsame Reserve, die für dieselbe Trefferwahrscheinlichkeit reicht, liegt bei rund einem Drittel davon.

Interessanter ist, wo die Streuung sitzt. Kalender-UI, Kalender-Sync und Buchungslogik machen zusammen 99 der 254,3 Stunden aus — 38,9 Prozent des Aufwands. An der Varianz haben sie mit 141,6 von 246,2 einen Anteil von 57,5 Prozent.

Daraus folgt eine Reihenfolge, keine Meinung: Sortieren Sie die Positionsliste nach σ², nicht nach Stunden, und bauen Sie die obersten drei zuerst. Nach dem Prototyp des Kalender-UI und einem echten Testlauf gegen die Sync-Schnittstelle schrumpft deren p-Wert — und mit ihm der begründbare Aufschlag. Ein Vorprojekt, das mit dem billigsten Modul anfängt, weil es „schnell etwas zu zeigen gibt", reduziert genau nichts.

Vom Erwartungswert zum Angebot

Für einen Festpreis brauchen Sie nicht den Erwartungswert, sondern einen Wert mit gewählter Trefferwahrscheinlichkeit:

• 85 Prozent: E + 1,04 σ = 254,3 + 16,3 ≈ 271 Stunden
• 95 Prozent: E + 1,64 σ ≈ 280 Stunden

Das sind 6,4 beziehungsweise 10 Prozent Aufschlag auf den Erwartungswert. Nicht die 20 Prozent, die in vielen Angeboten als Pauschalpuffer stehen — und die bei einem unscharfen Scope trotzdem zu wenig wären.

Zwei Einschränkungen gehören in dieselbe Zeile wie das Ergebnis. Erstens unterstellt die Formel unabhängige Abweichungen. Das stimmt genau dann nicht, wenn eine einzige Architekturentscheidung fünf Positionen gleichzeitig trifft. Solche gekoppelten Risiken gehören einzeln benannt, einmal bepreist — oder aus dem Scope genommen. Zweitens ist die Rechnung nur so gut wie der p-Wert. Ein pessimistischer Wert, der als „m mal 1,2" entstanden ist, enthält keine Information.

Erst am Ende wird mit dem Stundensatz multipliziert. Der Satz ist Verhandlungssache und hat mit der Schätzung nichts zu tun; wer beides vermischt, kann Angebote nicht mehr vergleichen. Wie das Vertragsmodell drumherum aussieht — Abnahme, Meilensteine, Risikoverteilung —, steht in Web App Entwicklung zum Festpreis: Modell, Voraussetzungen und Risiken.

Unschärfe-Score: Ist der Scope überhaupt festpreisfähig?

Vor der Schätzung steht die Frage, ob geschätzt werden kann. Zwölf Kriterien, je 0 bis 2 Punkte, maximal 24:

0–6 Punkte: Festpreis über den gesamten Scope ist sauber kalkulierbar. 7–14 Punkte: Festpreis erst nach einem bezahlten Vorprojekt, das die 2er-Positionen auf 0 oder 1 drückt. Alles andere verlagert die Unschärfe in den Preis oder in den Streit. Ab 15 Punkten: Kein Festpreis über das Ganze. Entweder den Scope halbieren und die scharfe Hälfte fest anbieten, oder nach Aufwand arbeiten.

Der häufigste Fall in Anfragen ist ein Score zwischen 8 und 13, bei dem drei Kriterien die Punkte liefern: Textbeschreibung statt Prototyp, Fremdsystem ohne Testzugang, Abnahmekriterien offen. Alle drei lassen sich in ein bis zwei Wochen beseitigen.

Die 38 Prozent, die in keiner Feature-Liste stehen

Die Positionen sieben bis elf im Rechenbeispiel — Datenschutz-Umsetzung, Design, Tests, Deployment, Abstimmung — ergeben 97,3 von 254,3 Stunden. Das sind 38 Prozent. Die reinen Feature-Stunden liegen bei 157; multipliziert mit 1,62 ergibt sich der Gesamtaufwand dieser Kalkulation.

Diese Zahl ist kein Naturgesetz, aber ein brauchbarer Sanity-Check für fremde Angebote: Enthält ein Angebot fast nur Feature-Positionen und liegt die Summe knapp über deren Wert, fehlt Arbeit — oder sie steckt unausgewiesen in den Feature-Positionen. Fragen Sie nach, welches von beidem, und lassen Sie sich die Antwort in die Positionsliste schreiben.

Was regelmäßig fehlt:

• Leer-, Lade- und Fehlerzustände jeder Ansicht (nicht nur der glückliche Pfad)
• Zustellbarkeit der System-E-Mails inklusive SPF/DKIM-Einrichtung
• Browser- und Geräte-Matrix, gegen die abgenommen wird
• Abnahmeumgebung mit realistischen Testdaten
• Rechte-Sonderfälle: Gesperrte Nutzer, Rollenwechsel, gelöschte Datensätze mit Bezügen
• Übergabe: Zugangsdaten, Betriebsdoku, eine Einweisungssession
• Bugfix-Fenster nach Abnahme, mit Definition, was ein Bug ist und was eine Änderung

Change Requests: Die Währung sind Stunden

Ein Festpreis scheitert selten an der Schätzung und oft am ersten Änderungswunsch. Drei Regeln, die das entschärfen, bevor es passiert:

Tauschregel. Neue Anforderung rein heißt: Gleich große Anforderung raus. Gemessen in Stunden aus der Positionsliste, nicht in gefühlter Wichtigkeit.

Änderungsbudget. Ein festes Kontingent — im Beispiel etwa 20 Stunden — liegt im Festpreis und wird per Freigabe abgerufen. Vereinbaren Sie vorab schriftlich, was mit dem Rest passiert: Verfällt er, wird er gutgeschrieben oder in Wartung umgewandelt.

Gleiche Methode für jede Änderung. Auch ein Change Request bekommt o, m und p sowie eine eigene Annahmenzeile. Wer für Nachträge plötzlich mit einer Zahl arbeitet, hat die Disziplin genau da aufgegeben, wo sie gebraucht wird.

Fünf Anzeichen, dass eine Schätzung nicht hält

1. Eine Zahl ohne Bandbreite. Ohne p-Wert weiß niemand, wie viel Risiko im Preis steckt — auch der Anbieter nicht.
2. p = m × 1,2 in jeder Zeile. Pessimismus per Formel ist kein Pessimismus, sondern eine Verzierung.
3. Keine Zeile für Tests, Deployment, Übergabe. Die Arbeit fällt trotzdem an, nur eben nach der Abnahme und auf Kosten der Nerven beider Seiten.
4. Position „Sonstiges, 10 %". Das ist die Stelle, an der jemand nicht wusste, was er noch vergessen hat, und den Betrag geraten hat.
5. Keine Annahmenliste. Annahmen sind der Teil, der einen Festpreis verhandelbar macht: Fällt eine Annahme, ist klar, welche Position sich ändert. Ohne sie bleibt nur Nachverhandlung über alles.

Wann ich selbst keinen Festpreis anbiete

Bei einem Unschärfe-Score ab 15 nicht, bei einem Fremdsystem ohne Testzugang nicht, und dann nicht, wenn die Ausgabequalität eines KI-Features das Abnahmekriterium sein soll — Antwortqualität lässt sich vorher nicht auf eine Stundenzahl abbilden, Funktionsumfang schon. Der vierte Fall ist der ehrlichste: Wenn der Auftraggeber im Projekt erst herausfinden will, was er braucht, ist ein Festpreis das falsche Werkzeug. Er bestraft genau das Lernen, das dann stattfinden soll.

Der Ausweg ist in allen vier Fällen derselbe: Ein Vorprojekt zum Festpreis, ein bis zwei Wochen, mit definiertem Ergebnis — klickbarer Prototyp der Positionen mit der höchsten Varianz, o/m/p-Tabelle, Annahmenliste, Abnahmekriterien je Modul. Danach ist der Bauabschnitt festpreisfähig, oder er ist es nachweislich nicht. Beides ist ein brauchbares Ergebnis.

Fragen, die im Erstgespräch meistens kommen

Wie viel kostet eine Web-App zum Festpreis? Der Preis entsteht aus zwei Zahlen, die getrennt gehören: Dem Stundenerwartungswert plus begründetem Puffer und dem verhandelten Satz. Vergleichen Sie Angebote deshalb nie über die Endsumme allein, sondern über die Stunden pro Position. Welche Faktoren die Stundenseite treiben, ist in Web App Entwicklung Kosten Hannover: Faktoren und Vergleich aufgeschlüsselt.

Taugt ein Online-Kostenrechner als Grundlage? Als Sortierhilfe für die eigene Erwartungshaltung ja, als Kalkulationsgrundlage nein. Ein Rechner kennt Ihre Fremdsysteme, Ihren Altdatenbestand und Ihre Freigabekette nicht — und genau dort entsteht in dieser Beispielrechnung die Streuung, die den Preis bewegt.

Wie lange dauert eine belastbare Schätzung? Für elf Positionen mit drei Werten, Annahmen und Abnahmekriterien: Etwa ein Arbeitstag, wenn Prototyp, Zugänge und ein Ansprechpartner mit Entscheidungsbefugnis vorhanden sind. Fehlt eines davon, ist es kein Schätztermin mehr, sondern ein Vorprojekt.

Der Test für Ihre nächste Angebotsrunde

Schicken Sie allen Anbietern dieselbe Positionsliste — Ihre, nicht deren. Fordern Sie für jede Position o, m und p sowie eine Annahmenzeile. Vergleichen Sie dann nicht die Endsummen, sondern die p-Werte: Wer bei der Schnittstelle zum Bestandssystem einen p-Wert nennt, der kaum über dem wahrscheinlichen liegt, hat entweder Erfahrung mit genau diesem System — oder er hat nicht hingesehen. Fragen Sie nach, welches von beidem, und lassen Sie sich die Erfahrung an einem Projekt zeigen. Eine Vorlage für die Anfrage selbst steht in Web-App-Angebot einholen: Checkliste für Anfrage und Vergleich.