Mission Statement

I am a Jack of all trades in technology and I believe in the power of prototyping to evaluate business models.

My mission is to solve hard technical or conceptual problems. Therefore I either build and operate stuff very efficient by myself or work together with startups and entrepreneurs, tackling their technical challenges.

If you are interested in my services, hire me! If it is not urgent, then you are welcome to just follow / friend me at Facebook, Twitter or LinkedIn because I post quiet some content on those topics.

Abrechnung und Vertragsarten bei agilen Softwareprojekten

Ein Thema, über das man ungerne redet: Verträge und Abrechnung. Denn wie rechnet man agile Softwareprojekte am sinnvollsten ab? Vor allem wenn der Aufwand 100 oder mehr Manntage beträgt, ist es fast unmöglich einen fairen Preis zu finden. Im schlimmsten Fall versucht man dann, ein ohnehin schon sehr komplexes Projekt, noch komplexer zu planen und geht massiv mit Konzeption in die Vorleistung. Aber dabei gibt es doch schon einige Standardsituationen, an denen man sich orientieren kann. Disclaimer: Das ist natürlich keine Rechtsberatung. Der Beitrag ist angelehnt an einen Vortrag der agilen Mayflower Profis – nur war der in der Präsentationsform etwas unübersichtlich :) Für noch mehr Lektüre sei das entsprechende Buch Der agile Festpreis* empfohlen.

Zielsetzung

Vertragsarten

Festpreis

Das ist deutsches Werkvertragsrecht aus einer Zeit, als es noch keine Softwareentwicklung gab.

T&M – Time & Materials

Das ist das andere extrem. Je nach Situation, Klarheit von Anforderungen, Möglichkeiten des Kunden, kann reines T&M Sinn ergeben. Ist aber meist für einen Erstauftrag bei uns nicht möglich.

T&M mit Abbruch

Vorteile für beide Seiten, Kooperation wird gestützt.

“T&M on Steroids”

Ergebnis: Verkettung beider Seiten in Kooperation. Der Kunde überlegt sich sehr genau, wann er einen Sprint nicht bezahlt. Der Dienstleister hat ein Interesse an guter, ergebnisorientierter Arbeit.

Agil mit Festpreis

Gewährleistung verteilt sich auf mehrere Mini-Gewerke statt auf ein großes Gewerk. Entkopplung der Bezahlung von Gewährleistung/Abnahme. Nur wenn im Nachhinein, also im Betrieb, etwas Abgenommenes nachweislich nicht stimmt, muss kostenlos gefixt werden.

Money For Nothing, Changes For Free

Lohnt sich nur bei Business-Value Optimierung! Und nur wenn klar ist, dass das Budget nicht bis zum Ende augebraucht werden soll. Lohnt sich nicht, wenn das Budget sowieso gut und sinnvoll genutzt werden kann.

Fazit

Am wichtigsten ist, dass keine Gewährleistung auf ein ganzes Produkt gegeben wird, sondern das Risiko auf einzelne User Stories / Features heruntergebrochen wird. Weil man als Dienstleister sonst in die Problematik kommt, dass ständig neue Features gewünscht sind. Ist das Budget dann mal fix definiert, können einzelne Features immer noch getauscht oder anders priorisiert werden.

01.03.2014

2 thoughts on “Abrechnung und Vertragsarten bei agilen Softwareprojekten”

  1. Es sollte im Fazit neben den User Stories / Features auch “Inkrements” (kleinteilige aber überprüfbare “Teilprodukte”) in Betracht gezogen werden.


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.