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.
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.
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.
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.
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:
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.
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.
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:
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.
Lunivore
Promotion