Ein neuer Kunde bittet uns, ein komplexes Softwareprodukt zu entwickeln (in time and budget). Sie stellten uns geschäftliche Anforderungen zur Verfügung. Diese Geschäftsanforderungen sind ein Text, der logisch in (nicht nummerierte) Kapitel und Unterkapitel unterteilt ist. Es gibt natürlich keine Identifikatoren für Anforderungen.
Sie stellten uns auch ein grundlegendes Diagramm der Softwarearchitektur zur Verfügung, das die Aufteilung des gesamten Systems in Softwaremodule und die Funktionalität, die diese Module bieten sollten, zeigt.
Im Allgemeinen sieht das Geschäftsanforderungs- und Architekturdiagramm gut aus. Aber es gibt viele offene technische Fragen, zum Beispiel:
All diese Fragen könnten wir natürlich mit dem Kunden erarbeiten, aber das erfordert wochenlange Zeit, die wir nicht haben.
Also erstellten wir für jedes Modul einen kurzen PSP und schätzten den Arbeitsaufwand (basierend auf grundlegenden architektonischen und technischen Annahmen). Nicht alles scheint in die Zeit zu passen, die wir für die Entwicklung haben, so dass der Kunde nur einen Teil aller Funktionen haben wird.
Jetzt denke ich darüber nach, wie ich einen Vertrag abschließen kann. Wie soll ich einen Vertrag abschließen, wenn ich keine klar definierten Anforderungen habe – alle Anforderungen sind über den gesamten Text verstreut, der das Produkt aus geschäftlicher Sicht beschreibt.
Welche Funktion soll ich versprechen, wenn es keine klar definierten Funktionen gibt?
Ein FFP ist weder für Ihren Kunden noch für Sie geeignet. Wenn Sie das verfolgen, müssen Sie es mit einer Menge Geld und Zeit belasten, die es für einen normalen Kunden undurchführbar machen würde. Und es würde Ihren Ruf ruinieren.
Ein T&M ist für dieses Szenario perfekt geeignet. Bestehen Sie darauf oder gehen Sie weg.
Ohne detaillierte und vollständig vereinbarte Anforderungen haben Sie eine Menge Annahmen. Ich schlage vor, dass Sie die Annahmen so vollständig wie möglich dokumentieren und dann einen Vertrag auf Zeit- und Materialbasis mit klar formulierten Annahmen strukturieren. Anschließend können Sie die Annahmen testen und bei Bedarf als Risiken oder Probleme dokumentieren.
Alternativ dazu können Sie es vorziehen, einen Festpreis für einen sehr begrenzten (vereinbarten) Basisumfang festzulegen, der aus den Ergebnissen mit der höchsten Priorität besteht, und einen vereinbarten Prozess für die Abrechnung weiterer, später priorisierter Umfänge aufzubauen. Dieser zusätzliche Umfang ist möglicherweise leichter abzuschätzen, da Sie mehr Klarheit über den Ansatz und ein besseres Verständnis der Anwendungs- / Geschäftsanforderungen haben.
Keiner dieser Ansätze ist perfekt, aber in dieser Situation müssen Sie sicherstellen, dass Sie nicht das gesamte Risiko für Änderungen des Umfangs oder fehlerhafte Annahmen tragen. Ebenso möchte Ihr Kunde auch nicht das gesamte Risiko tragen, sodass möglicherweise ein gewisses Maß an Kompromissen und Schutz auf beiden Seiten erforderlich ist.
Einer der zu berücksichtigenden Faktoren ist, ob der Kunde über ausreichende Erfahrung mit dieser Art von Engagement verfügt. Es macht nur Sinn, so etwas anzugehen, wenn beide Parteien bereit sind, später über Spielräume zu verhandeln, sonst geht einer oder beide unzufrieden davon. Der Kunde sollte verstehen, dass ein „fester“ Preis bedeutet, dass er eine Prämie zahlt, damit der Auftragnehmer einen Teil des Risikos übernimmt, und dass er für Dinge, die als außerhalb des Umfangs liegen, extra zahlt. Angesichts der Unbekannten ist der „nicht feste“ Teil des Projekts wahrscheinlich genauso wichtig wie der feste Teil, und der Vertrag sollte dies explizit machen.
Wenn Sie den Festpreis aushandeln, können Sie auch einen (günstigeren) Kostenvoranschlag zum Vergleich angeben. Angenommen, Sie liefern in Iterationen und rechnen durchgehend regelmäßig ab, dann können Sie dem Kunden die Möglichkeit einräumen, jederzeit auf einen T&M-Preis umzusteigen, dh wenn sich herausstellt, dass der undefinierte Umfang dies wünschenswert macht.
Hans-Martin Mosner
Hansenrik