Festpreis Vertrag
 
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern

Ein FestpreisVertrag vereinbart die Lieferung einer definierten Software (Umfang, Qualität) zu definierten Bedingungen (Termin, Preis).


In der Praxis ergeben sich oft
Probleme:

Was ist hier genau mit Qualität gemeint ?
Nur ein qualitativ hochwertiges Entwicklungsteam wird diese Probleme in den Griff bekommen.

Vorteile FestpreisVertrag für den Lieferanten:

Nachteile FestpreisVertrag für den Lieferanten:

ExtremeProgramming verspricht diese Probleme unter Verzicht auf einen FestpreisVertrag in einem Entwicklungsteam "normaler" Qualität durch eine Methodologie zu lösen.

Gedanken dazu:

Falsch: Der Lieferant versucht dem Kunden zu vermittelt, dass es bei Abschluss eines Vertrages kein Risiko gibt. Erfahrene Entwickler liefern bewährte Qualität. Es gibt keine Probleme.
Weshalb so kategorisch "Falsch" ? Ich kann mir auch Kunden vorstellen, die mit ihrer zusätzlichen Gestaltungsfreiheit nicht umgehen können, bzw. die von Ihnen geforderten Entscheidungen (Feature A oder B) ohne Blick auf evtl. weitreichenden Konsequenzen fällen.
Da hast du völlig recht, vielleicht habe ich die obige Formulierung - aus Sicht der Projektaquisition und Verkaufspsychologie - überinterpretiert. Was ich meinte ist, dass es für den Kunden im FestpreisVertrag kein wichtiges Motiv sein kann, das Risiko zu verlagern. Wenn er ein Risiko sieht, wird er mit dem Abschluss zögern oder einen anderen Lieferanten wählen. Deshalb wird der Lieferant auch vermeiden, von Risiken zu sprechen. Das gilt für den Entwicklungsbereich ebenso wie für den Kundenbereich (weil er damit die Kompetenz des Kunden anzweifeln würde). Vermutlich muss jemand, der erfolgreich Projekte verkaufen will, Worte wie "Risiko" oder "Problem" aus seinem Wortschatz streichen.
Ich hoffe nicht ! Ich denke es ist die Kunst, trotz "Risiko" und "Problem" genügend Vertrauen zu erzeugen. Ich hoffe weiterhin, dass zufriedene, ehemalige Kunden diesem Vertrauensvorschuss dienlich sind :-). Ist dieses Vertrauen vorhanden, ist ein Festpreis eine Richtgrösse, für die der Kunde ein lauffähiges & zufriedenstellendes Produkt bekommt. Die Detailfunktionalität kann dabei genauso im Fluss bleiben, wie das in XP vorgeschlagen wird.

Das Problem:

Von den VierVariablen lassen sich Umfang und Qualität des Produktes schwer eindeutig festhalten und somit Raum für Interpretation. Insbesondere wenn sich die Realisierung als schwerer als erwartet herausstellt, ist das Entwicklungsteam praktisch gezwungen, die Anforderungen zu Ungunsten des Kunden auszulegen. Anstatt des innerhalb der zur Verfügung stehenden Resourcen bestmöglichen Produktes, bekommt der Kunde ein minderwertiges, bei dem an allen möglichen, vom Kunden nicht mehr beeinflussbaren Ecken gespart wurde. Die Verlagerung des Risikos ist so im Großen und Ganzen eine Illusion.

Würde ich so nicht unbedingt sagen. Solche Projektverläufe kommen zwar vor, die oben beschriebenen Probleme können aber anders gelöst werden. Das Versagen eines Festpreis Projekts hat die gleichen Gründe, die auch zum Versagen eines Dienstleistungs Projekts führen. Für mich hat ein FestpreisVertrag folgende Daseinsberechtigung:
Ich will nicht sagen Festpreis ist um jeden Preis zu bevorzugen, aber ich will nicht aus Glaubensgründen darauf verzichten muessen.
Selbstverständlich geht es nicht um Glaubensgründe oder darum, den FestpreisVertrag zu verteufeln. (Habe ich den Eindruck erweckt?) Es geht lediglich darum, einige potentielle Probleme aufzuzeigen und Alternativen anzubieten.
:-) Ack. Weisst du, ich glaube, ich meckere nur, weil ich hier die Alternativen noch nicht entdeckt / gelesen habe. Gibt's irgendwo schon eine Zusammenfassung mit Vor- und Nachteilen der jeweiligen Prozessspezifischen Methoden ?
Die einzige mir bewusste Abhandlung über eine Alternative ist WardsWiki:OptionalScopeContracts.

Ein Alternative, die RobertCMartin in letzter Zeit häufiger erwähnt, ist eine Kombination aus TimeAndMaterials? und Festpreis:


Ein interessanter Punkt, formuliert von RobertCMartin of news:comp.software.extreme-programming:

Contracts aren't about agreeing to everything up front, because agreeing to everything up front is simply impossible. Contracts are about establishing a framework within which the parties can trust each other. There will always be exceptions and oversights. If the relationship is built on trust, then these situations are dealt with accordingly. If the relationship is not built on trust, then the contract should not be signed.

(Gibt es eine bessere Stelle für dieses Zitat?)
Siehe
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern
Text dieser Seite ändern (zuletzt geändert: 14. Januar 2004 12:18 (diff))
Suchbegriff: gesucht wird
im Titel
im Text