Ist die Schätzung eines Projekts ohne Grundanforderungen oder User Stories eine gute Idee für einen Fixkostenvorschlag?

Ich versuche gerade, einen Kostenvoranschlag für einen Softwarevorschlag zu erstellen.

In diesem Zusammenhang bitten wir um einen festen Kostenbeitrag.

Ich persönlich tendiere zu agilen Entwicklungspraktiken. Ich finde jedoch keine Möglichkeit, einen Vertrag ohne Fixkosten auszuhandeln.

Ich habe einige Empfehlungen erhalten, das Projekt nicht anhand von Benutzergeschichten und „erledigten Bedingungen“ zu bewerten. (BDD-Stil)

Mein Bauchgefühl sagt mir, dass es zu viel Risiko bedeutet, nicht alle Anforderungen im Voraus zu haben. Ich persönlich möchte wissen, wie "fertig" aussieht.

Arbeite ich mit meinem Kunden zusammen, um User Stories zu dokumentieren, um den Projektumfang zu definieren? Oder sollten wir das Projekt nur auf der Grundlage sehr vager Feature-Anfragen bieten.

Vielen Dank im Voraus.

Was Ihr Bauchgefühl Ihnen nicht sagt, ist, dass alle Anforderungen im Voraus nur das Risiko verschleiern . Es ist immernoch da.
Es dauert doppelt so lange und kostet dreimal so viel - verwenden Sie diese Heuristik in "vagen" Phasen :)

Antworten (10)

Beginnen wir mit einer offensichtlichen Beobachtung: Der Moment, in dem wir am wenigsten über ein Projekt wissen, ist ganz am Anfang . Leider ist es bei Festpreisprojekten auch ein Moment, in dem wir normalerweise darum bitten, zu sagen, wie viel es kosten wird, also um zu schätzen.

In einer solchen Situation würde ich mich mehr auf die Verbesserung der Schätzqualität konzentrieren als auf die Wahl dieser oder jener Schätztechnik. Mit anderen Worten, ich verstehe nicht, warum Sie den BDD-Stil nicht schätzen sollten (wenn das für Sie funktioniert hat).

Apropos Verbesserung der Schätzungsqualität:

  • Verwenden Sie Mehrpunktschätzungen (als Zbigniew-Punkte; +1). Dieser Ansatz wird in vielen Methoden verwendet, zB PERT , auch wenn wir am Ende eine Ein-Punkt-Schätzung erhalten. Es gibt eine Falle im Zusammenhang mit der Mehrpunktschätzung. Wenn Sie mit einem Festpreisvertrag arbeiten, haben Sie keine Mehrpunktpreise, also müssen Sie schließlich die Mehrpunktschätzung in einen Einzelpunktpreis umwandeln. In jedem Fall ist es immer noch besser, sich der Bandbreite möglicher Schätzungen bewusst zu sein als nur einer einzigen.

  • Wahrscheinlichkeit. Alternativ können Sie, anstatt einen Bereich zu wählen, zB von 80 bis 120 Manntagen, die Wahrscheinlichkeit verwenden, zB sind wir zu 60 % sicher, dass es 100 Manntage dauern wird. Sehen Sie sich an, wie die Monte-Carlo-Analyse in Evidence Based Scheduling verwendet wird , um mehr darüber zu erfahren, wie Sie diese Technik anwenden können.

  • Verwenden Sie historische Daten. Wahrscheinlich der größte Spielveränderer in Bezug auf die Schätzung. Das Beste, was wir tun können, um unsere Schätzungen zu verbessern, ist zu überprüfen, wie wir in der Vergangenheit mit unseren Schätzungen verglichen wurden. Was Sie brauchen, um diese Technik anzuwenden, ist, dass Sie Daten sammeln müssen, wie Sie geschätzt haben und wie es schließlich gelaufen ist. Dann können Sie erfahren, wie sehr Sie sich normalerweise irren, und dieses Wissen nutzen, um Ihre aktuellen Schätzungen anzupassen. Denn wenn Sie Ihre Aufgaben ständig um die Hälfte unterschätzen, warum erwarten Sie plötzlich, diesmal genau am Ziel zu sein?

  • Vermeiden Sie überhaupt Schätzungen. Das ist radikal, ich weiß, aber es ist nicht weit von dem entfernt, was ich oben vorgeschlagen habe. Wenn Sie Ihr Projekt in etwa gleich große Teile aufteilen können (siehe z. B.: Features in Standardgröße ) und Sie über zuverlässige historische Daten verfügen, die Sie verwenden können, um Ihre Bereitstellungsrate zu ermitteln, dh wie oft Sie ein solches Feature bereitstellen können, können Sie sich darauf stützen Werte, um den Arbeitsaufwand abzuschätzen, der zum Abschluss des Projekts erforderlich ist. Sehen Sie sich dieses Beispiel an, um zu erfahren, wie Sie das tun können.

Und vor allem lesen Sie das Buch Software Estimation von Steve McConnell .

In Bezug auf die Schätzung gibt es keine Wunderwaffe, also können Sie die Qualität der Schätzungen auf eine Weise verbessern, die in Ihrem Fall machbar ist, wenn Sie verschiedene Techniken kennen. Beispielsweise kann Ihr Team ad hoc für ein Projekt organisiert werden und es ist Ihnen möglicherweise nicht möglich, über zuverlässige historische Daten zu verfügen usw. Der Trick besteht wie immer darin, das richtige Tool für das richtige Problem zu verwenden.

+1, um Schätzungen überhaupt zu vermeiden. Siehe Ist Softwareentwicklung zum Festpreis unethisch? .
Es lohnt sich nicht, meine eigene Antwort hinzuzufügen, aber ich möchte Folgendes hinzufügen: Fixkostenschätzungen sollten am besten als "nicht zu überschreitende Kosten" angesehen werden und sollten Ihre beste Schätzung plus das Risiko / die Unsicherheit, die Sie verstehen, sowie mehr für unerwartetes / unbekanntes enthalten Dinge. Verstehen Sie, dass dies Sie aus dem Projekt herauspreisen könnte, und das ist möglicherweise die beste Antwort. Auf der anderen Seite sollten Sie niemals die Macht eines PM unterschätzen, Änderungsaufträge auszuhandeln und neue Finanzierungen zu finden, sobald das Projekt beginnt. Stellen Sie einfach sicher, dass sie wissen, dass sie sich zu Beginn des Projekts darauf vorbereiten müssen :-)
+1 für die Erwähnung von McConnells Buch. +1 für eine gute Antwort. Und +1 für das Anbieten verschiedener Optionen. Oh warte, ich kann nur einmal positiv abstimmen. Dagnabbit.

Festpreisverträge und unklarer Umfang gehören nicht zusammen ...jemals. Sie können nicht einmal den Weg einschlagen, klar zu sagen, was Sie tun werden, weil niemand weiß, was getan werden muss. Sie können nicht planen, es mit Änderungsanforderungen zu handhaben, da eine CR eine Änderung des Umfangs ist ... und Sie keinen Umfang haben.

Dies ist ein Zeit- und Materialvertrag. Dies ist nicht diskutabel. Unter diesen Umständen ist ein FP-Vertrag sowohl gegenüber dem Verkäufer als auch dem Käufer von Dienstleistungen unfair. Für den Verkäufer gehen Sie ein inakzeptables und unvermeidbares Risiko ein. Sie hätten keine andere Wahl, als den Preis mit einer Menge Eventualitäten zu belasten, was es wiederum für den Käufer unfair macht, da der Preis das Zwei-, Drei- oder Vierfache dessen beträgt, was er bei einer anderen Vereinbarung hätte sein können.

+1 Das scheint noch schlimmer zu sein, als nicht zusammen zu gehen. Ist Softwareentwicklung zum Festpreis unethisch? Dies scheint ein geeigneter Fall zu sein, um einfach nein zu sagen.
Stimme zu 100 % zu „Festpreisverträge und uneindeutige Reichweiten gehören nicht zusammen … niemals“. Das wäre, als würde man 10.000 Dollar für ein Auto bezahlen, ohne zu wissen, um was für ein Auto es sich handelt, wie es aussah oder sogar, ob es anspringt und läuft! +1
Aus über 15 Jahren Erfahrung ist dies eine viel bessere Antwort als die Empfehlung besserer Schätztechniken. Bauen Sie eine variable Komponente in den Vertrag ein.

Wenn Sie ohne Auflagen kalkulieren müssen, müssen Sie sehr genau angeben, was Sie für die von Ihnen beantragte Festkostenzahlung tun werden. Anstatt also "den Job" anzunehmen (was eine lockere Handwinkspezifikation ist), werden Sie spezifische Ergebnisse auflisten, die Sie erfüllen können. Machen Sie deutlich, dass die Ergebnisse nur das enthalten, was geschrieben wurde, und zusätzliche Arbeit mit zusätzlichen Kosten verbunden ist.

Das ist ein toller Rat. Ich denke auch, dass dies eine Grundlage für die Zusammenarbeit mit dem Kunden sein kann, um eine noch solidere Vorstellung davon zu bekommen, wie die Abschlusskriterien aussehen könnten.
+1 für "Abschlusskriterien". Nehmen Sie den Job nicht einfach an, wenn die Anforderungen wohl oder übel passen – geben Sie genau an, was Sie tun werden, und nicht mehr zu einem festen Preis.

Willkommen bei PMSE!

Lassen Sie uns Ihre Frage in Unterfragen aufteilen ...

Ist es eine gute Idee, ein Projekt ohne grundlegende Anforderungen oder User Stories zu schätzen?

Nein, das ist überhaupt keine gute Idee, aber manchmal müssen wir zur Musik tanzen.

Mein Bauchgefühl sagt mir, dass es zu viel Risiko bedeutet, nicht alle Anforderungen im Voraus zu haben. Ich persönlich möchte wissen, wie "fertig" aussieht.

Ihr Mut hat Recht, fürchte ich. Das Projektrisiko ist direkt proportional zum Fehlen klarer Anforderungen ... was in Ihrem Fall bedeutet, dass das Risiko enorm ist.

Was kann ich also tun?

Da es keine klaren Anforderungen, aber ein klares Budget (und Fristen, nehme ich an) gibt, glaube ich, dass Sie viel mit dem Kunden besprechen müssen, um das Projekt so weit wie möglich aufzuschlüsseln . Definieren Sie mit einem ersten PBS grobe Schätzungen für jede zu erledigende Arbeit, ihre Abhängigkeiten und definieren Sie auch klar die Prioritäten zwischen den einzelnen Arbeiten.

Die Schätzungen werden im Laufe des Projekts aktualisiert, ihre Abhängigkeiten helfen Ihnen, den Projektpfad für die Zukunft zu definieren, und die Prioritäten werden verwendet, falls die Dinge aus dem Ruder laufen und Sie Dinge abbrechen müssen. Tut uns leid, wenn wir uns mit Projekten befassen, müssen wir immer auf Worst-Case-Szenarien vorbereitet sein.

Also kurz:

  • Seien Sie ehrlich zu Ihrem Kunden und erklären Sie, dass Sie beide umso weniger Risiko haben, je klarer das Projekt wird (hier würde ich vorschlagen, zu vermeiden, zu sagen: „Je unklarer das Projekt wird, desto mehr Risiko haben wir“, da es gehen kann einen schlechten Eindruck);
  • Entwerfen Sie mit dem Kunden eine grobe PBS ;
  • Stimmen Sie die Prioritäten des Stücks mit dem Kunden ab , bevor Sie Ihre Schätzungen abgeben (nur um eine Voreingenommenheit bei der Entscheidung des Kunden zu vermeiden);
  • Vereinbaren Sie formell (per Post, Vertrag, wie Sie es nennen) alles oben Genannte und achten Sie besonders auf die Details darüber, was geliefert wird und was nicht.

Erfolg!

Bitte versuchen Sie nicht, alles mit BDD anzugeben. Sie werden am Ende mit einem schrecklich feinkörnigen Rückstand enden, dessen Pflege ewig dauert und der immer noch keine Ähnlichkeit mit dem realen Projekt hat, das entsteht.

Etwas, das ich getan habe – und das später sehr gut mit BDD funktioniert – ist, mir die High-Level- Fähigkeiten anzusehen, die das System bereitstellen muss. Eine Fähigkeit ist etwas, das ein Benutzer tun kann oder das das System tun kann. Dies bedeutet natürlich Geschäftsfähigkeiten, kann aber auch technische Fähigkeiten wie Leistung, Integration mit Systemen von Drittanbietern usw. umfassen. Als Richtlinie hatten wir ungefähr 30 Karten für ein zweijähriges Unternehmensprojekt.

Setzen Sie als Nächstes einen großen roten Punkt auf alles, was neu oder unbekannt ist. Dies sind Ihre riskantesten Bereiche.

Wenn Sie möchten, können Sie die relative Größe der Fähigkeiten in Punkten grob schätzen, genauso wie Sie Stories schätzen würden, aber größer (verwenden Sie mindestens ein Vielfaches von 10). Ich begann mit dem kleinsten bei 20, dann dem größten bei 400, fand dann einen in der Mitte und ging von dort aus weiter.

Wenn Sie fertig sind, verdoppeln Sie alles mit einem roten Punkt, es sei denn, Sie können sich vorstellen, warum das Risiko nicht so groß ist.

Dadurch erhalten Sie eine wirklich gute Vorstellung davon, wie komplex und riskant das Projekt im Vergleich zu ähnlichen Projekten ist, die Sie durchgeführt haben, und Sie können die ungefähren Kosten viel einfacher abschätzen. Außerdem können Sie Ihr Geld und das des Kunden für die Erstellung von Software ausgeben, anstatt über den Umfang zu streiten. Wenn Sie Schwierigkeiten beim Schätzen haben, finden Sie einige Leute, die ähnliche Projekte durchgeführt haben. Sie können die Funktionen auch verwenden, um ein Mindestrelease zu definieren, das einfacher abzuschätzen ist und auch ein geringeres Risiko und eine schnellere Rückgabe an den Kunden darstellt.

Mein letzter Ratschlag ist, mit vernünftigen Kunden zusammenzuarbeiten, die lieber nützliche Dinge produzieren und gemeinsam das wirkliche Risiko angehen, als sich darüber zu streiten, wer für die Definition der nebulösen Zukunft verantwortlich ist.

Zur weiteren Lektüre ist dies ein Artikel, den ich vor einiger Zeit über diese Technik geschrieben habe (damals bezogen wir uns auf Fähigkeiten als Themen oder Feature-Sets ). Bitte lesen Sie auch die Beiträge von Dan North zu den Gefahren der Schätzung und der vorsätzlichen Entdeckung .

Wenn Sie die Projekte basierend auf dem, was Sie bisher haben, schätzen möchten, können Sie dies tun, indem Sie anstelle eines festen Datums einen Zeitraum angeben. Dies wird „ Der Kegel der Unsicherheit “ genannt. Die Grundidee ist, dass Ihre Schätzungen umso ungenauer sind, je weniger Sie wissen, also sollten Sie diesen Fehler in Ihre Daten einbeziehen. Ich verstehe aber, dass der Auftraggeber immer den Fixtermin haben möchte, also sollte man ihm erklären, woher die Reichweiten kommen.

Fügen Sie außerdem einen Puffer hinzu, um Änderungen einzubeziehen, und einen weiteren Puffer, um Risiken einzubeziehen.

Ich stimme den anderen Antworten zu, dass es unmöglich ist, abzuschätzen, ohne die Anforderungen zu kennen.

Was Sie auf der Grundlage der Ihnen jetzt vorliegenden Informationen tun könnten, ist, einen Festpreisvertrag nur für eine Anforderungsanalysestudie anzubieten . Sie können eine grobe oder detaillierte funktionale und sogar technische Spezifikation hinzufügen, wenn Sie mit dieser Art von Projekt vertraut sind. Fügen Sie einige wichtige Bildschirmprototypen hinzu, damit der Kunde ein Gefühl dafür bekommt, was er bekommen wird.

Wenn dies erledigt ist und es nicht so lange dauern muss, können Sie Ihren besten Preis auch für den Rest des Projekts hinzufügen.

Stellen Sie sicher, dass Sie die ganze Zeit über einen qualifizierten Kundenbetreuer haben. Nicht nur, um sicherzustellen, dass Ihre Analyse auf den Punkt kommt, sondern auch, um eine Beziehung zu diesem Kunden aufzubauen.

Die Anforderungen ändern sich im Laufe der Zeit, stellen Sie also sicher, dass dies auch Ihrem Kunden klar ist, und fügen Sie für den Rest des Projekts einen geeigneten Prozess für Änderungen hinzu.

Sie können dies dem Kunden mit der Idee verkaufen, dass das, wie DONE aussieht, für beide Parteien klar ist, aber dass er es verwenden kann, um woanders einzukaufen. Hier ist die Beziehungssache wichtig.

Ich liebe die Idee, ein Festpreisangebot anzubieten, um die Anforderungen zu studieren und stattdessen ein Konzept zu entwickeln. Ich arbeite an großen Systemen (nicht nur an Software), bei denen die Gebote mehrere zehn oder hundert Millionen Dollar betragen können. Oft ist der erste Schritt ein viel kleinerer Vertrag, um die Planung durchzuführen und eine Basislinie auf hoher Ebene festzulegen, auf der der Rest des Angebots basieren kann.

Es kann eine riskante Entscheidung sein, ein Projekt anzunehmen. Es ist ratsam, die Kundenanforderungen durchzugehen, und der riskanteste Teil ist, wenn der Kunde das Projekt in einer Zeile erklärt.

Ein Fixkostenprojekt kann unter folgenden Bedingungen akzeptabel sein - wenn die Lösung / das Projekt von der Entwicklerseite klar definiert ist - wenn Sie das starke Gefühl haben, dass der Kunde mit Ihrer Lösung / Arbeit definitiv zufrieden sein wird - wenn der Kunde Ihnen sehr bekannt ist. vorherige Arbeitserfahrung mit ihm

Ich nehme an, das ist während einer Angebotsphase, in der der Kunde bestimmt, mit welchem ​​Partner er zusammenarbeiten möchte. Sie haben ein Problem und wollen es behoben haben, so gut wie möglich für einen festen Geldbetrag.

Sie gehen fälschlicherweise davon aus, dass Sie abschätzen sollten, was es kostet, einen bestimmten Umfang bereitzustellen. Oft ist es umgekehrt: Sie haben ein Budget zur Verfügung und wollen den Anbieter, der den größten Mehrwert bietet.

  • Schlagen Sie eine (kostenpflichtige) Analysephase vor, in der Sie mit dem Kunden zusammenarbeiten, um den Umfang besser zu definieren. Verkaufsargumente:
    • Ohne dies werden wir unserem Vertrag nur eine riesige Menge an Eventualitäten hinzufügen. Alle (seriösen) Anbieter werden.
    • Indem Sie uns dafür bezahlen, erhalten Sie am Ende ein hochwertiges Anforderungsdokument. Dies ermöglicht es allen Anbietern, ihre Kontingenz zu verringern, wodurch Sie bessere Preise erzielen können.
    • Anbieter werden diese Analyse (mindestens) kostenlos durchführen, um ihr eigenes Risiko / ihren eigenen Preispunkt zu reduzieren. Sie müssen jedoch mit 5 Anbietern statt nur mit 1 sprechen.
  • Legen Sie den Umfang so genau wie möglich fest. Sie werden froh sein, dass Sie sich proaktiv bemüht haben, und deutlich sehen, dass Sie ihr Geschäft verstehen.
    • Nachteil: Sie könnten Ihre Analyse einfach verwenden und in die nächste Ausschreibung einfließen lassen. Stellen Sie sicher, dass dies nicht möglich ist, indem Sie Ihr Angebot vertraulich behandeln.
  • Schlagen Sie ein Scope-to-Budget-Projekt vor. Stellen Sie einen sehr klar definierten Proof-of-Concept bereit, um ihnen zu zeigen, was Sie wert sind. Sobald Vertrauen aufgebaut ist, werden sie erkennen, dass Sie ein gutes Preis-Leistungs-Verhältnis bieten und sich nicht mehr um das Budget kümmern.
  • Machen Sie einfach ihren Spielraum für sie, basierend auf einem einfachen Gespräch über Geschäftsziele + verfügbares Budget. Dies erfordert natürlich mehr Vertriebsaufwand, während Sie das Projekt möglicherweise immer noch nicht gewinnen.

Wir sind in unserem Unternehmen sehr oft in dieser Situation. Aber so arbeiten wir eben.

Unsere Stärke ist es, keine Details von Kunden zu verlangen, sondern selbst Vorschläge zu machen – was wir dem Kunden von seinem Geld bieten. Verwenden eines agilen Ansatzes – sogar bei Festpreisverträgen.

Was wir im Wesentlichen tun, ist Folgendes:

  1. Finden Sie das Hauptproblem der Geschäftsziele des Kunden heraus.
  2. Erstellen Sie eine PERT-Schätzung für alle Projektziele (aufgeteilt auf High-Level-Ergebnisse).
  3. Stellen Sie sicher, dass es eine Lösung gibt, die dem Budget des Kunden entspricht. Vereinfachen Sie alle Leistungen, die Sie benötigen, um das Budget einzuhalten – beispielsweise das Herunterladen von CSV-Dateien anstelle umfassender Berichte. Stellen Sie sicher, dass es Ihren Kunden immer noch zufrieden stellen kann – wenn es sein Geschäftsproblem immer noch löst.
  4. Geben Sie so viele Annahmen wie möglich zusammen mit den Ergebnissen an – dh beschreiben Sie, was Sie liefern werden. Es wird Ihnen helfen, Umfangsänderungen während des Projektverlaufs auszuhandeln.
  5. Erstellen Sie einen Zeitplan mit ungefähren Terminen für die Lieferung der zu erbringenden Leistungen. Spezifizieren Sie detaillierte Anforderungen nur für einige der ersten.
  6. Wichtig: Wenn Sie kurz vor dem Beginn der nächsten Lieferung stehen – beginnen Sie mit der Spezifikation der Details und verhandeln Sie sie mit dem Kunden. Wenn Sie feststellen, dass der Kunde etwas Größeres möchte, als Sie budgetiert haben, dann sagen Sie ihm: Sie haben weniger Budget dafür in Betracht gezogen, also gibt es jetzt zwei Möglichkeiten:
    1. An der ursprünglichen Version des Liefergegenstands festzuhalten, oder
    2. Machen Sie es größer, aber um weitere Ergebnisse noch mehr zu vereinfachen – um am Ende des Projekts die gleichen Gesamtkosten zu tragen.

Es gibt noch einige andere Tricks, die Sie verwenden, aber diese sind unerlässlich, um sowohl eine teure Vorausplanung zu vermeiden als auch das Problem des Kunden auf Festpreisbasis lösen zu können.