14 Min. Lesezeit
Sébastien Nobour
Gründer von DEVEDANOS
Festpreis oder Abrechnung nach Aufwand: Diese Frage stellt sich, sobald man eine Software entwickeln lässt. Die meisten Antworten vergleichen zwei Abrechnungsarten und setzen dabei voraus, dass ein Festpreis sowohl den Preis als auch die Funktionsliste festschreibt. Dabei gibt es zwei Arten von Festpreis. Der Festpreis mit festem Leistungsumfang bepreist ein Lastenheft. Der Festpreis mit festem Budget und flexiblem Funktionsumfang legt das Budget und das zu lösende Problem fest und lässt die Funktionen, die es lösen, sich weiterentwickeln.
Der Festpreis mit festem Leistungsumfang und die Abrechnung nach Aufwand haben eines gemeinsam: Beide beruhen auf einer Vorhersage. Der eine sagt voraus, was eine Funktionsliste kostet. Die andere sagt eine Anzahl von Tagen voraus. Und diese Vorhersage muss sich an einer einzigen Frage bewähren: Wer zahlt, wenn sich der Bedarf unterwegs ändert?
Denn der Bedarf ändert sich. Wenn Microsoft die Wirkung seiner Ideen per kontrolliertem Experiment misst, verbessert nur eine von drei die Zielmetrik. Ein Drittel hat keine Wirkung, ein Drittel verschlechtert sie (Kohavi und Thomke, Harvard Business Review, 2017). Niemand weiß im Voraus, welche. Das zeigt erst die Nutzung.
Beim Festpreis mit festem Leistungsumfang verpflichtet sich der Dienstleister, eine in einem Lastenheft beschriebene Liste von Funktionen zu einem bei Vertragsabschluss festgelegten Preis zu liefern.
Bei der Abrechnung nach Aufwand stellt der Dienstleister Personen bereit und rechnet die aufgewendete Zeit ab, pro Tag. Bei Vertragsabschluss steht nur der Tagessatz fest.
Beim Festpreis mit festem Budget und flexiblem Funktionsumfang steht der Preis fest, und das zu lösende Problem ebenfalls. Flexibel bleibt, wie es gelöst wird: die Funktionen, die entwickelt werden.
Der Festpreis mit festem Leistungsumfang schreibt also den Gesamtpreis und die Liste fest. Die Abrechnung nach Aufwand legt nur den Tagessatz fest. Der Festpreis mit festem Budget schreibt das Budget und das Problem fest, nicht die Liste. Um zu verstehen, wer das Risiko trägt, muss man sich ansehen, wie jedes Modell zu seinen Zahlen kommt.
Alles beginnt mit dem Lastenheft. Der Dienstleister zerlegt die Liste in Aufgaben und schätzt jede Aufgabe in Arbeitstagen. Er addiert. Er multipliziert mit seinem Tagessatz. Heraus kommt ein Preis.
Dieser Preis beruht vollständig auf Schätzungen. Und eine Schätzung bleibt eine Vermutung über Arbeit, die noch nicht getan ist. Vasco Duarte berichtet in NoEstimates (Kap. 1) von Daten, die er zwischen 2001 und 2003 in einem Unternehmen über siebzehn Projekte gesammelt hat. Die durchschnittliche Verzögerung gegenüber der Schätzung lag dort bei 62 %. Ein auf drei Monate angesetztes Projekt dauerte fast fünf.
Ein Dienstleister, der sich auf einen Preis festlegt, kennt dieses Risiko und rechnet es in seinen Betrag ein. Evan Leybourn sagt es in How Much Does It Cost? A Guide to Agile Contracts (Abschnitt „Fixed contracts“) ohne Umschweife: Wenn Preis und Umfang beide feststehen, wird der Risikoaufschlag erhöht, bevor das Angebot hinausgeht. Tomas Rybing beschreibt in Applied Capacity Planning With NoEstimates (S. 4-5) dieselbe Praxis von innen: einen Faktor aus dem Bauchgefühl, mit dem die Schätzung multipliziert wird, um die Hindernisse abzudecken, von denen man weiß, dass sie kommen, ohne zu wissen, welche. Er nennt Werte wie 30 % oder das Doppelte.
Duarte (Kap. 2) zeigt, wo das an seine Grenzen stößt. Ein zu großzügiger Aufschlag macht das Angebot teurer als das der Wettbewerber. Und ist die Zeit erst einmal gewährt, dehnt sich die Arbeit tendenziell so aus, dass sie sie ausfüllt: das Parkinsonsche Gesetz.
Der Zeitplan folgt derselben Logik wie der Preis. Die geschätzten Aufgaben werden in eine Reihenfolge gebracht, oft in einem Gantt-Diagramm, und zu Meilensteinen gebündelt. Jeder Meilenstein hat sein Datum. Die Abnahme kommt am Ende, wenn alles geliefert ist.
Dieser Plan ist detailliert, und genau das macht ihn schwer veränderbar. Duarte (Kap. 7) weist darauf hin: Wer in einem detaillierten Plan die Reihenfolge der Arbeit ändert, muss alles neu aufrollen, die Abfolge der Aufgaben, ihren Inhalt, ihre Zuteilung. Je einfacher der Plan, desto leichter verkraftet er Änderungen.
Nur wird die Liste geschrieben, bevor die Software existiert, an dem Tag, an dem man am wenigsten darüber weiß, wie Ihre Teams sie nutzen werden. Unterwegs verschiebt sich der Bedarf. Eine geplante Funktion wird nicht mehr gebraucht. Eine andere, an die niemand gedacht hatte, wird dringend. Jede dieser Erkenntnisse fällt aus der unterschriebenen Liste heraus. Sie wird zum Änderungsantrag, der gesondert kalkuliert wird. Sie wird zum Nachtrag, und den Nachtrag zahlt der Kunde.
Die Abweichungen können erheblich sein. Bei 4.677 IT-Projekten liegen die tatsächlichen Kosten im Schnitt beim 1,8-Fachen der geschätzten, also 80 % darüber (Flyvbjerg et al., JMIS 2022). Dieser Durchschnitt wird von einer Minderheit von Projekten mit extremen Überschreitungen nach oben gezogen: In derselben Stichprobe liegt die mediane Überschreitung nahe null. Aber niemand weiß bei Vertragsabschluss, auf welcher Seite sein Projekt landen wird.
Der Festpreis mit festem Leistungsumfang deckt also den Schätzfehler ab, in den Grenzen der unterschriebenen Liste. Einen sich ändernden Bedarf deckt er nicht ab. Leybourn geht für den Fall, in dem Preis, Umfang und Termin alle drei feststehen, noch weiter: Ein solches Projekt hat seiner Ansicht nach ohne ein gewisses Maß an Flexibilität wenig Aussicht auf Erfolg.
Bei der Abrechnung nach Aufwand ist der Preis eines Tages bekannt. Die Anzahl der Tage nicht.
Das Ausgangsbudget wird trotzdem genauso aufgestellt wie beim Festpreis mit festem Leistungsumfang: Jemand schätzt die Anzahl der benötigten Tage und multipliziert sie mit dem Tagessatz. Der Unterschied: Diese Zahl verpflichtet niemanden. Sie ist ein Planbudget. Die Rechnung folgt den tatsächlich geleisteten Tagen, jeden Monat belegt durch einen Tätigkeitsnachweis.
Dauert die Arbeit doppelt so lange wie geplant, kostet sie doppelt so viel. Das Schätzrisiko liegt vollständig beim Kunden.
Leybourn (Abschnitt „Time and material contracts“) sieht darin trotzdem den flexibelsten Vertrag. Der Kunde kann aufhören, sobald das, was der Rest kostet, das übersteigt, was er einbringt. Um die Ausgaben zu begrenzen, beschreibt er eine Variante mit Obergrenze, die hoch genug bleiben muss, damit sich die Investition noch lohnt. Das Budget wird dann wieder zu einer Grenze, allerdings zu einer, die erneut geschätzt wurde.
Das ist die Stärke der Abrechnung nach Aufwand: Die Liste bleibt veränderbar. Der Kunde ändert Prioritäten, wann er will, ohne Nachtrag. Viele Teams arbeiten dann in kurzen Iterationen, zum Beispiel von zwei Wochen. Sie schätzen jedes Element in Story Points, messen, wie viele Punkte sie pro Iteration abschließen, und leiten daraus einen Termin ab.
Duarte (Kap. 2) benennt die Schwäche dieses Mechanismus: Je besser das Team die Arbeit versteht, desto öfter schätzt es den Rest neu, und der Durchschnitt, auf dem die Vorhersage beruht, verschiebt sich ständig.
Er schlägt etwas anderes vor (Kap. 5). Die Größe der Elemente nicht mehr schätzen, sondern sie so klein schneiden, dass sie einander ähneln. Zählen, wie viele pro Woche fertig werden. Dieses Tempo fortschreiben, um den Rest vorherzusagen. Er ergänzt, dass Arbeit, die unterwegs entdeckt wird, kein Scope Creep ist: Es ist entdeckter Wert („value discovered“). Und er vertritt ein Prinzip, das den Festpreis mit festem Leistungsumfang auf den Kopf stellt (Kap. 2): Dauer und Kosten festlegen, die Liste variieren lassen.
Rybing wendet diese Idee unter dem Namen Kapazitätsplanung an (S. 2-6). Jeden Freitag zählt sein Team die auf dem Board erledigten Aufgaben, was weniger als fünf Minuten dauert. Der Durchschnitt ergibt eine Kapazität: 18 Aufgaben pro Woche in seinem Beispiel. Danach genügt eine einfache Division: 213 Fehler zu beheben, 18 pro Woche, also 12 Wochen, doppelt so viel wie die 6 Wochen im Zeitplan. Oder, innerhalb der 6 Wochen, ungefähr die Hälfte der Korrekturen.
Duarte spricht übrigens nicht mehr von Schätzung, sondern von Prognose. Diese Werkzeuge sind das Beste, was es gibt, wenn man vorhersagen muss. Sie begrenzen den Schaden und lenken hin zu einem flexiblen Funktionsumfang. Aber sie beruhen weiterhin auf einer Form der Schätzung: Sie unterstellen, dass das bisherige Tempo auch für den Rest gilt. Eine Vermutung über die Zukunft wurde gegen eine Hochrechnung aus der Vergangenheit getauscht.
Was die Abrechnung nach Aufwand schließlich verkauft, sind Tage. Nichts im Modell verpflichtet dazu, Ihren Teams jeden Monat eine nutzbare Software in die Hand zu geben. Und der Dienstleister muss die Weisungsbefugnis über die bereitgestellten Personen behalten. Steuert der Kunde ihre Arbeit im Alltag selbst, kann die Konstellation nach französischem Recht als unerlaubte Arbeitnehmerüberlassung eingestuft werden: Das französische Arbeitsgesetzbuch verbietet jedes auf Gewinn gerichtete Geschäft, dessen ausschließlicher Zweck die Überlassung von Arbeitskräften ist (Artikel L8241-1).
Für Leybourn definiert sich ein Vertrag zuallererst über das Risiko, das jede Partei zu tragen bereit ist. Der Festpreis mit festem Leistungsumfang und die Abrechnung nach Aufwand treten als Gegensätze auf. Dabei gehen sie vom selben Schritt aus: die Arbeit schätzen, bevor sie getan wird. Der Festpreis mit festem Leistungsumfang macht aus dieser Schätzung einen Preis. Die Abrechnung nach Aufwand macht daraus ein Planbudget und versucht danach, Transparenz zu wahren: Tätigkeitsnachweise, Verbrauchskontrolle, ein neu berechneter Endtermin.
Warum halten wir so sehr an diesen Prognosen fest? In seiner Schulung „Un retour à l’essence de l’Agilité“ ordnet Frédéric Leguédois die Bedürfnisse, denen Schätzungen dienen. Transparenz schaffen und beruhigen gehören dazu. Und in seinem Vortrag „Éloge de la simplicité“ (Devoxx France, auf Französisch) bezeichnet er die Planung angesichts der Unsicherheit als eine beruhigende Vorstellung: „Die Planung ist ein organisatorisches Kuscheltier“ (eigene Übersetzung).
Ein Kuscheltier beruhigt. Vor nichts schützt es. Eine Planung, die jede Woche neu berechnet wird, vermittelt den Eindruck, das Budget zu steuern. Das Budget selbst folgt weiter dem, was die Arbeit tatsächlich kostet.
Nicht der Festpreis an sich ist das Problem. Das Problem ist, Budget und Funktionsliste gleichzeitig festzuschreiben. Werden beide festgeschrieben, trägt eine der beiden Parteien das gesamte Risiko der Unsicherheit, und niemand kann sich mehr anpassen. Wird dagegen nichts festgeschrieben, läuft das Budget aus dem Ruder.
Bleibt eine Kombination, die keines der beiden Modelle bietet: das Budget und das zu lösende Problem festlegen, den Funktionsumfang, der es löst, flexibel lassen und aufhören, vorherzusagen, was sich nicht vorhersagen lässt.
Leybourn beschreibt eine verwandte Form: einen festen Preis pro Woche oder pro Iteration, einen festen Termin, eine flexible Funktionsliste. Der Preis stammt nicht mehr aus einer Schätzung: „The cost is effectively budgeted, instead of estimated“ (die Kosten werden budgetiert, nicht geschätzt). Trotzdem misst er weiter das Abnahmetempo, um vorherzusagen, wie viele Elemente in die verfügbare Zeit passen. Das ist immer noch eine Vorhersage.
An diesem Punkt weicht unser Modell davon ab. Es ist ein Festpreis: ein festes Monatsbudget, ohne dass ein Endtermin vorhergesagt oder ein Tempo fortgeschrieben werden muss. Fest stehen das Budget und das zu lösende Problem. Flexibel bleibt der Funktionsumfang, also die Funktionen, die es lösen. Jede davon ist ein Experiment unter derselben Fragestellung.
Wie das Budget festgelegt wird. Das Monatsbudget wird gemeinsam mit Ihnen aufgebaut, auf Grundlage Ihrer Zahlen und Ziele, in einem zweiten Gespräch. Es geht nicht von einer Funktionsliste aus, die kalkuliert werden muss. Es geht von der Zeit aus, die Sie in Ihre Software investieren möchten, gemessen daran, was Sie das Fehlen der Software kostet. Der Vertrag umfasst 15 Arbeitstage pro Monat und pro Teammitglied. Wir entwickeln Ihre individuelle Anwendung zu einem festen Budget, das am Ende jedes Monats für die geleistete Arbeit abgerechnet wird.
Wie die Arbeit geplant wird. Es gibt kein Gantt-Diagramm, keine terminierten Meilensteine, kein fortgeschriebenes Tempo, um einen Endtermin vorherzusagen. Der Ansatz sagt voraus, was vorhersehbar ist: das Monatsbudget und die Entwicklungstage pro Monat. Er versucht nicht, das Unvorhersehbare vorherzusagen: was Ihre Nutzer mit einer Funktion tun werden, bevor sie sie in der Hand haben. Er gehört zu dem, was Leguédois ein Arbeiten ohne Projektion nennt. Und er geht anders auf das Bedürfnis nach Transparenz und Sicherheit ein: Leguédois schlägt vor, ihm zu begegnen, indem die Arbeit kleinteilig geschnitten, schnell in Produktion gebracht und durch automatisierte Regressionstests abgesichert wird. Das ist es, was seiner Ansicht nach Vertrauen schafft. Und der Ansatz stellt eine einzige Frage: Was ist jetzt das Nützlichste?
Ihre Anwendung ist innerhalb eines Monats nutzbar. Nutzbar heißt nicht fertig: Ihre Teams arbeiten ab dem ersten Monat damit. Was wir aus der Nutzung über eine Funktion lernen, setzen wir noch am selben Tag um. Jeden Tag sehen Sie, wie die Anwendung auf Ihrer Abnahmeumgebung vorankommt.
Was passiert, wenn sich der Bedarf ändert. Das Problem bleibt dasselbe. Was sich ändert, ist der Weg zur Lösung, und nichts muss neu verhandelt werden. Die Funktion, die nicht mehr gebraucht wird, fliegt von der Liste. Die Funktion, die dringend wird, rückt nach vorn. Das Budget bleibt gleich. Was wir entwickeln, folgt dagegen dem, was Ihre Teams bei der Nutzung lernen.
Eine Abrechnung nach Aufwand ist es deshalb nicht. Was Sie jeden Monat erhalten, ist kein Stundennachweis. Es ist eine Software, die Ihre Teams nutzen.
Es ist ein Festpreis, aber keiner mit festem Leistungsumfang. Mit Ihrem Budget kaufen Sie Arbeit, die dieses Problem vom ersten Entwicklungstag an laufend abmildert. Wir streben an, es vollständig zu lösen, können das aber weder garantieren noch terminieren. Damit das Problem kleiner wird, müssen Sie nicht auf diesen Tag warten. Jeden Monat sehen Sie, was dabei herauskommt, und Sie entscheiden, ob Sie weitermachen. Sie können den Vertrag jederzeit schriftlich kündigen, ohne Begründung.
Eine Ergebnisgarantie soll einen Kunden schützen, der nicht gehen kann. Hier können Sie jeden Monat gehen.
Damit das, was im letzten Monat funktioniert hat, auch in diesem Monat noch funktioniert, wenden wir die Null-Regressions-Garantie an: Jede Regression wird behoben und durch einen automatisierten Test abgesichert, damit sie nicht wiederkehrt, ohne Aufpreis.
Beim Festpreis mit festem Leistungsumfang trägt der Dienstleister den Schätzfehler auf der unterschriebenen Liste. Der Kunde trägt den sich ändernden Bedarf, Nachtrag um Nachtrag.
Bei der Abrechnung nach Aufwand trägt der Kunde beides. Eine Änderung kostet keinen Nachtrag, aber jeder zusätzliche Tag landet auf der Rechnung.
Beim Festpreis mit festem Budget und flexiblem Funktionsumfang gibt es keine Schätzung mehr, die sich überschreiten ließe. Das Budget ist vor dem Start bekannt, und es hält, weil nichts von einer Vorhersage abhängt. Ein geänderter Bedarf ändert, was entwickelt wird, nicht, was bezahlt wird. Und der Kunde entscheidet jeden Monat selbst, ob er weitermacht. Sein technischer Partner hat also allen Grund, gute Arbeit zu leisten, damit der Kunde den Vertrag nicht im Folgemonat kündigt. Jeder nützliche Monat gibt dem Kunden einen Grund weiterzumachen und seinem technischen Partner einen Grund, den nächsten sorgfältig anzugehen: eine Aufwärtsspirale.
Der Festpreis mit festem Leistungsumfang bleibt geeignet für einen Bedarf, der sich nicht ändern wird. Arbeit, die sich immer gleich wiederholt, wird vorhersagbar. Software dagegen wird immer zum ersten Mal entwickelt.
Warum ein Preis aus addierten Schätzungen so oft das geplante Budget überschreitet: Darum geht es in unserem Artikel über Budgetüberschreitungen.
Unser Leitfaden behandelt diese Quellen ausführlich. Dort finden Sie auch die Fragen, die Sie stellen sollten, bevor Sie ein Angebot für Softwareentwicklung unterschreiben.
Möchten Sie eine Software entwickeln lassen, oder haben Sie ein Tool, das mit Ihrem Geschäft nicht mehr mithält? Sprechen wir darüber?
Was ist ein Feature Flag? Vier Arten von Toggles, was Sie versuchen sollten, bevor Sie einen hinzufügen, und sieben Anti-Patterns, durch die nie getesteter Code läuft.
App entwickeln lassen: Mit welchem Budget rechnen? Der Betrag allein reicht nicht: Setzen Sie auf ein Ziel statt auf eine Liste, mit Nutzern ab dem ersten Monat.
Prädiktiver oder adaptiver Ansatz? Die eigentliche Trennlinie verläuft nicht zwischen V-Modell und agilem Vorgehen, sondern zwischen Vorhersagen und Anpassen. Was das für Software bedeutet.