Die Verbindung von Kosten und Preis in der Softwareentwicklung ist zwar gängige Praxis, basiert aber auf einem, meines Erachtens nach, falschen Verständnis dessen, was wir dort verkaufen.
Das Business-Modell der Auftragsarbeit für Softwareentwicklung ist, schaut man genauer hin, von den Professional Service Firms abgeschaut. Dort wird auch nach dem Modell der Stundenverrechnung gezahlt. Ganz wie bei einem Handwerker. Spannenderweise, ist auch in der Professional Service Firm, exakt das gleiche Problem für den Unternehmer zu erkennen. Wie kann man als Professional Service Firm die Marge erhöhen, wenn der Kunde doch weniger Geld zahlen will? Das geht in den großen Unternehmensberatungen dieser Welt immer nach dem gleichen Schema. Verkaufe günstige Ressourcen zu hohen Tagessätzen und verkaufe möglichst viele Tage. Exakt das gleiche versuchen IT-Dienstleister. (Alleine der Name verrät in welchem Business, sich diese Firmen wähnen.)
Dieses Business-Modell ist aber nur ertragreich, wenn ich nicht die Leistung liefere, die der Kunde erwartet. Denn sonst wäre es tatsächlich nur kostendeckend.
Faszinierenderweise haben es die meisten Firmen, die Software Entwicklung anbieten geschafft, in einem wachsenden Markt ein Business-Modell zu etablieren, das niemand in anderen Bereichen der Wirtschaft akzeptieren würde. [1] Erpressung und Täuschung, Qualitätsdefizite und Applikationen, die erst nach Jahren der Weiterentwicklung stabile Zustände erreichen.
In einem Scrum Entwicklungsprojekt ist time-and-material gerade nicht sinnvoll, weil:
1) Wie soll denn ein Kunde wissen, was er kauft, wenn sich während des Projektes alles ändern kann. Bleiben wir beim Hausbau. Stell dir vor, du könntest während des Baues mit dem Architekten vereinbaren, dass du noch mehr Zimmer haben willst. Das geht alles, aber würdest du anfangen, bevor du nicht mindestens weißt, was für ein Haus du bauen willst? Wo es stehen soll? Aus welchem Material es bestehen soll? Wie das grobe Design deines Hauses sein soll?
Ich nicht … NATÜRLICH MUSS ES EIN PFLICHTENHEFT GEBEN UND NATÜRLICH MUSS KLAR SEIN, WOVON WIR DA REDEN. AUCH BEI SCRUM!!!!!!!! UND unser PFLICHTENHEFT IST KEINE DETAILBERSCHREIBUNG JEDES EINZELNEN ZIMMERS, SONDERN EINE KLARE AUSSAGE DARÜBER, WOHIN WIR UNS BEWEGEN. Und ja, dann kann man sehr wohl einen Festpreis anbieten.
2) Wieso soll ich denn meine Kapazitätssteigerung an den Kunden weitergeben? Mal ehrlich, erklärt mir das mal. Ich habe von 2002 bis 2005 jahrelang versucht, herauszufinden, warum es sinnvoll sein soll, das zu tun. Erfolglos!
Es macht aus Unternehmersicht, aus Sicht des CTOs, aus der Sicht des IT Entwicklungsleiters nämlich keinen Sinn. Wieso soll er denn seinen Produktivitätsgewinn, seine Effizienzsteigerung durchreichen? Das ist irre! Das wäre wirtschaftlicher Unsinn. Toyotas werden doch auch nicht billiger, obwohl die Firma effektiver und effizienter wird. Big Macs kosten auch jedes Jahr mehr, obwohl der Laden ständig effizienter wird. (Jetzt kann man schon selbst am Terminal bestellen. Geht schneller, kostet keine Arbeitszeit.)
Einer meiner Kunden hat jetzt genau dieses Problem. Er erarbeitet mit weniger Arbeitsstunden für seinen Kunden MEHR Applikation. Aber sein Umsatz geht jetzt, (wegen Scrum) zurück. Wahnsinn! Lasst uns Scrum sofort wieder abdrehen!! Das wäre und ist die einzige logische Reaktion in diesem Business-Modell.
Wir erzeugen Produkte, also müssen wir auch Produkte und nicht Dienstleistung verkaufen! Und zwar möglichst zu dem Preis, der in genau unserer Nische, in unserem Marktsegment der richtige ist.
Ein letztes Beispiel. Ich habe mir nach Jahren endlich einen Traum erfüllt. Ich bin beim Maßschneider gewesen und habe mir einen Maßanzug machen lassen.
Was glaubt ihr, was ihr bezahlt? Nein, nicht die Arbeitsstunde, sondern irgendeinen Preis, den ihr bereit seid zu zahlen. Er selbst lässt die Dinger in Deutschland bei einem Zulieferer nach Maß nähen. Dann kommt der Anzug und dann wird er noch einmal angepasst.
Preis und Kosten haben NICHTS miteinander zu tun. Der Markt bestimmt den Preis, nicht der Anbieter. [3]
[1] Im Bereich des Handwerks kann man darüber noch einmal streiten: “Handwerker werden nachträglich bezahlt, wenn sie fertig sind. (Hier gibt es übrigens auch ähnliche Probleme, werden aber z.B. von guten Architekten eingegrenzt.)”
[2] Dieser Artikel ist als Reaktion auf Theos Antwort am 24.12. entstanden.
[3] Das ist sehr sehr schmerzlich für viele viele Firmen zu verstehen. Scrum erzwingt ein neues, verändertes Business-Modell. Scrum macht genau das aber auch erst möglich.
Related posts:
kann diesen Ausführungen nur 100%ig zustimmen…
Was spricht aber dagegen, wenn man den Stundensatz so gestaltet, dass einfach jede Stunde provitabel ist? Das ist doch weitaus sicherer als ein Prokjekt mit einem Pflichtenheft (ungleich Lastenheft!) zu beginnen, da sich die Anforderungen so und so immer im Projekt ändern. Außerdem kann man ja auch einzelne Sprints zu einem Festpreis anbieten. Auch hier können die Preise so gestaltet werden, das ein Sprint (mehr als) provitabel ist.
Gerade für kleinere Unternehmen ist das Risiko doch meist deutlich zu hoch, sich bei größeren Projekten (natürlich in Realtion zur Unternehmensgröße) zu verkalkulieren, wenn man diese von Anfang an Überschauen muss und meist der Kunde nicht mal genau weiß, was die Software alles können soll…Lieber habe ich jede Arbeitsstunde gut bezahlt als am Projektende wegen Änderungen die sich im Projekt ergeben draufzuzahlen. Und wenn man davon ausgeht, dass Veränderung die einzige Konstante ist (auch in Projektgeschäft) wird der Kunde auch nie zu Beginn an genau wissen, was es kostet und was der gesamte Funktionsumfang ist, denn auch er wird weitere Funktionen wärend dem Projektverlauf wünschen, die dann nachberechnet werden müssen (oder nicht, je nach Vertragsgestalung, aber dann geht das deutlich zu lasten des Entwicklers, was bei Scrum nicht so wäre). Daher verstehe ich die Diskkussion nicht richtig und muss Theo in den meisten Punkten Recht geben. Aber ich lass mich natürlich auch gerne vom Gegenteil überzeugen.
Schneller durch Scrum und Festpreise « Stefan Roock // Jan 6, 2010 at 11:45
[...] } Boris Gloger hat zwei Blogeinträge zu Festpreisen und Scrum geschrieben (hier und da) und dabei interessante Thesen vertreten. Die Abrechnung nach Time&Material könne [...]
Nunja, wenn ich mal einen Kunden haben sollte, bei dem nicht klar wie Klosbrühe ist, das er seine eigenen organisatorischen Unzulänglichkeiten und die eigene Ahnungslosigkeit, wie das am Ende aussehen soll, mit einem Festpreis absichern will, dann mach ich einen Festpreis. Hab ich in 10 Jahren Projektgeschäft aber noch nicht angetroffen. G*
Die Frage ist ja, was ich für Ziele verfolge. Wenn ich möglichst viele Stunden an einen Kunden verkaufen will, dann ist ein Festpreis natürlich nicht das Richtige. Was habe ich dann aber bspw. für ein Interesse daran, Mitarbeiter auf Fortbildungen zu schicken, damit sie schneller werden? Ich müsste dann ja eher dafür sorgen, dass sie langsam bleiben. Das erzeugt aber unmotivierte Mitarbeiter, die sich dann schnell mal interessantere Arbeitgeber suchen.
Der Weg zwischen Festpreis und Aufwandspreis ist das, was ich als “Money for nothing” gelernt habe. Ich vereinbare also einen groben Leistungsumfang zu einem Festpreis, der damit aber auch gedeckelt ist (Risikominimierung). Dieser Festpreis hat einen entsprechenden Risikoaufschlag, so dass mir nicht die Kosten weglaufen können. Will der Kunde neue Anforderungen umgesetzt haben, gibt es die nur im Tausch gegen andere Funktionen, die ihm nicht mehr so wichtig sind. Und sollte, weil die Produktivität super war, das Produkt vor Erreichen des vereinbarten Festpreises (=Zeitbudgets) fertig werden, wird das übrig bleibende Budget geteilt, etwa die Hälfte behalte ich, die Hälfte spart der Kunde.
Das setzt natürlich ein gewisses Maß an Vertrauen zwischen Kunde und Lieferant voraus, und muss für den Kunden transparent sein.
Beispiel: Produkt A wird grob mit den gewünschten Features geplant und geschätzt. Die Schätzung ergibt 100 Personentage + Risikoaufschlag = 120 Personentage. Pro Tag werden dem Kunden 500 Euro berechnet, ergibt einen Festpreis von 60.000 Euro. Der Kunde stellt fest, dass ihm ein Feature fehlt. Diese wird geschätzt und kann gegen ein gleichwertiges kostenlos getauscht werden (Vorteil für den Kunden!). Wenn er nicht bereit ist, auf ein anderes Feature zu verzichten, muss er den Zusatzaufwand bezahlen (Sicherheit für Lieferanten).
Da nach Scrum die wichtigsten Features zuerst realisiert werden, kann der Kunde zu einem Zeitpunkt sagen: “Super, das reicht mir.” Nun sind aber nur 100 PT verbraucht worden. Die übrigen 20 werden geteilt, der Kunde bezahlt also nur 110 PT und ist glücklich, der Lieferant hat für 100 PT 110 bezahlt bekommen und ist auch glücklich, da er sich schneller um andere Aufträge kümmern kann.
So kann Scrum mit Festpreis funktionieren, und beide Seiten haben einen Vorteil davon, wenn die Produktivität besser als erwartet ist.
Wie gesagt, ist die Grundlage dafür auch das Vertrauen, dass die ursprünglichen Schätzungen realistisch sind. Wenn ich 200 PT schätze und bin nach 100 fertig, ist der Kunde vermutlich nicht bereit, mir 150 zu bezahlen. Also das muss schon nachvollziehbar sein.