Was Gartenpflege mit Softwareentwicklung gemein hat

- oder -

Warum ein Festpreis-Software-Projekt eine schlechte Idee ist

Denken Sie an Ihren Garten. Dieser braucht im Frühling ein wenig Pflege. Ein Beet soll angelegt, ein anderes umgegraben werden, weitere Arbeiten stehen ebenfalls an.

Obwohl Sie all dies auch selbst durchführen könnten, entscheiden Sie sich dafür eine Firma zu beauftragen: Diese hat entsprechendes Werkzeug, Erfahrung und Know-How.

Bei einem Treffen besprechen Sie die anstehenden Arbeiten, zeigen auf, was Sie sich wie in Ihrem Garten für dieses Jahr wünschen. Früher oder später kommt es dann zu Gesprächen über den Preis für die Arbeiten. Jetzt heißt es Verhandlungsgeschick beweisen: Sie möchten möglichst wenig für die Arbeiten bezahlen. Vielleicht hat ein Bekannter oder ein Nachbar von Ihnen ähnliche Arbeiten durchführen lassen und Sie wissen, wie viel dieser dafür zahlte. Die Firma möchte den Auftrag von Ihnen erhalten und wird daher vermutlich versuchen ein möglichst günstiges Angebot zu machen.

Festpreis = gut. 

Soweit, so gut. Aber sobald man sich auf einen Festpreis geeinigt hat, sind verschiedene Szenarien vorstellbar: Da wäre z.B. die Möglichkeit, dass die Arbeiten viel schneller als von Ihnen dem Auftraggeber erwartet erledigt werden: Wurden Sie dann übervorteilt? Vielleicht ist der Festpreis auch so niedrig, dass das Unternehmen - um rentabel zu arbeiten - Oberflächlichkeit statt Sorgfalt an den Tag legt. Oder Sie sind begeistert von den Fortschritten und beschließen direkt noch ein zweites Beet anlegen und Ihre Rosen beschneiden zu lassen. Das ganze soll, aus Ihrer Sicht, selbstverständlich noch zum vorher vereinbarten Preis geschehen - schließlich handelt es sich um den gleichen Garten, und solange noch die von Ihnen gewünschten Arbeiten nicht erledigt sind, fließt kein Geld? Vorstellbar.

Festpreis = doch nicht so gut!

Es wird deutlich, dass Festpreise verschiedene Probleme mit sich bringen - für beide Seiten der Geschäftsbeziehung. Das gilt auch für feste Preise bei Softwareentwicklung: Es ist sehr schwer, im Voraus zu überblicken und sich darauf zu einigen, was die Software tatsächlich später einmal können soll. Natürlich kann man versuchen Design-Festlegungen zu treffen und Feature-Listen zu erarbeiten, aber am Ende muss der Kunde zustimmen, dass die Software fertig ist. Das bedeutet allerdings, dass durch Festpreisvereinbarungen Entwickler und Kunde automatisch unterschiedliche Positionen in ihrer Beziehung zugewiesen werden, solche, die einer Langzeitbeziehung entgegenstehen:
Der Entwickler könnte seinen Preis zu hoch ansetzen um von vornherein mögliche Schwierigkeiten zu berücksichtigen die auftreten könnten. Nicht ungewöhnlich ist ein Preis, der dann mehrfach so hoch ist wie der tatsächliche Aufwand wäre.
Vielleicht wäre es noch schlimmer, wenn der Entwickler einen zu niedrigen Preis ansetzt, um den Auftrag unbedingt zu erhalten. Dies führt später zu Problemen, nämlich wenn der Kunde früher oder später Weiterentwicklung, Veränderungen und Verbesserungen der Software wünscht.
Der Entwickler wird auf Änderungswünsche warten und versuchen, die Extraarbeit in Grenzen zu halten - oder zumindest dafür extra bezahlt zu werden.
Der Kunde wiederum wird über Veränderungen diskutieren wollen und davon ausgehen, diese seien im Festpreisangebot enthalten gewesen. Gleiches gilt für eine Fehlerbehebung: Der Kunde erwartet eine kostenlose Fehlerbehebung was jedoch unterstellt, dass die Software vorher getestet und für gut befunden wurde bevor sie zum Einsatz kam. Solche umfangreichen Tests sind allerdings sehr aufwändig und teuer.

Entwickler als Teil des Teams

Ganz anders bei einer Abrechnung nach Aufwand: Der Entwickler ist eine Erweiterung des Teams des Kunden. Der Kunde kauft Expertise - kein Produkt. Dies bedeutet, dass jegliche angefallene Arbeit dem Kunden in Rechnung gestellt werden wird. Der Entwickler stimmt zu, Zeit effizient und effektiv zu investieren.
Der Kunde hat jederzeit volle Kostenkontrolle, da er über den Einbau von Features entscheidet. Zugleich hilft er Kosten zu reduzieren, da er Teile des Testens der Software übernimmt und Fehler und Probleme dem Entwickler mitteilt.
Steigen die Kosten, können Features niedrigerer Priorität auf später verschoben werden, um im Budget zu bleiben.
Kunde und Entwickler ziehen am gleichen Strang - die Beziehung wird länger anhalten und für beide Seiten fruchtbarer sein.

Der Ansatz der Entlohnung pro Stunde konnte viele Kunden überzeugen. Ich versuche einen möglichst realistischen Gesamtpreis in Aussicht zustellen - aber es ist und bleibt eine Schätzung. Diese Schätzung kann sich ändern - sowohl nach oben, als auch nach unten.

Ist der Umfang eines Projektes deutlich definiert und ändert sich nicht nachträglich, sind diese Schätzungen recht realistisch. Dass sich aber der Umfang eines Projektes nicht während der Entwicklung ändert, kommt allerdings selten vor:
Viele Projekte, besonders die komplexeren, werden umfangreicher, wenn der Kunde erst einmal die (neuen) Möglichkeiten erkennt und daraufhin weitere Features hinzufügen möchte. Manchmal jedoch wachsen Projekte einfach deshalb nach ihrem Start, weil erst dann entdeckt wird, dass zur Erfüllung der Wünsche des Kunden mehr notwendig ist als anfangs bekannt war. Genau wie beim Beispiel der Gartenarbeit, wo plötzlich und unerwartet Schwierigkeiten auftauchen können.

Wenn Sie das nächste Mal über eine Entwicklung zu einem Festpreisangebot nachdenken, bedenken Sie, was dies bedeutet. Nach meiner Erfahrung werden Sie, wenn Sie eine Abrechnung nach Aufwand wünschen, feststellen, dass dieses Vorgehen im Endergebnis weniger kostet und die Wahrscheinlichkeit einer erfolgreichen komplexen Projektierung dadurch steigt.

Aus diesem Grunde arbeite ich nicht für einen Festpreis, sondern rechne nach Aufwand ab.

Dieser Text wurde durch einen Artikel von Armen Stein (J Street Technology) inspiriert und ist mit seiner Zustimmung hier zu lesen. Vielen Dank.