Agile Projekte finanzieren

13

Das Unternehmen, in dem ich arbeite, bewegt sich vorläufig in Richtung einer agilen Projektmanagementstrategie - nachdem ich die "Freuden" des Wasserfalls einmal zu vielen erlebt habe. Der Schlüssel dazu ist eine Verlagerung der Betonung auf die Bereitstellung von Funktionalität im Gegensatz zur Einhaltung strenger Fristen.

Während sich der Entwicklungsprozess und die Kundenbeziehung durch die durch Agile geförderten iterativen Releases sicherlich verbessert haben, erweist es sich als etwas schwieriger, die gleichen Überlegungen auf die Finanzierungsstrategien für das Projekt anzuwenden. Kunden sind häufig nicht an Konzepte wie Agile gewöhnt und äußern große Besorgnis über das, was sie als Fall von "es wird fertig sein, wenn es fertig ist" empfinden .

Ich würde gerne die Gedanken und Erfahrungen der Leute bei der Finanzierung von Agile-Projekten hören

edit: Ich möchte betonen, dass ich die Leute nicht auffordere , mir die Vor- und Nachteile der Agile-Methode zu erklären , und dass ich glaube, dass Agile mit "es wird fertig, wenn es fertig ist" gleichzusetzen ist Kunden / Unternehmen, mit denen ich zusammengearbeitet habe, als ich agile Entwicklungspraktiken befürwortete.

Was mich interessiert, sind die Erfahrungen, die die Menschen gemacht haben, um die Konflikte zwischen den in Geschäftskunden / Geschäftsbeziehungen verankerten "traditionellen" Wasserfall-Budgetierungsmethoden und den fortschrittlicheren Entwicklungsmethoden zu lösen - und die Budgetierungsstrategien, die sie zur Unterstützung dieser Entwicklung angenommen haben.

agile

— sunwukung
quelle

2

Lisa Crispin und David Norton von Gartner haben einige gute Ideen zu "Selling Agile". Schauen Sie sich an, was sie zu sagen haben: bit.ly/rlRF4U

— Agile Scout

4

Wenn Sie in der Lage waren, ein Angebot für ein Projekt mit einem genauen Enddatum für alle Funktionen abzugeben, warum haben Sie dann zu einem agilen Ansatz gewechselt? Sie und alle anderen haben damit zu kämpfen, und ein agiler Ansatz ist mit dieser Tatsache konfrontiert. Verwenden Sie es als Propaganda gegen die Konkurrenz. Southwest Airline verspricht Ihnen keinen Sitzplatz auf einer Insel wie jeder andere, der dies tut, und gibt ihn dann an einen anderen weiter.

Natürlich möchte der Kunde ein genaues Enddatum. Sie möchten eine kostengünstige, fehlerfreie Software, die unabhängig von Änderungen an der ursprünglichen Anfrage im Voraus geliefert wird. Sagen Sie Ihrem Verkaufsteam, dass es lernen soll, ein Projekt nach agilen Prinzipien zu verkaufen. Je mehr Interaktionen Sie durchlaufen, desto genauer können Sie feststellen, wann das Projekt abgeschlossen sein wird. Der Kunde lernt auch, die Auswirkungen von Änderungswünschen zu berücksichtigen.

— JeffO
quelle

"Sagen Sie

— Ihrem

5

Agile Projekte funktionieren nicht nach dem Motto "Es wird fertig sein, wenn es fertig ist". Das ist eine klassische Linie aus der Wasserfalltechnik.

Agile Projekte sind abgeschlossen, wenn der Kunde beschließt, kein Geld mehr für zusätzliche Funktionen auszugeben. Dies könnte von Ihren Verkäufern in ein wichtiges Verkaufsargument umgewandelt werden. Anstatt sich für einen festgelegten Geldbetrag auf einen festgelegten Satz von Funktionen festzulegen (dessen Bedarf im Voraus bekannt ist oder nicht), kann der Kunde mit einem anfänglichen Betrag für einen anfänglichen Satz von Funktionen beginnen und diesen schrittweise durchführen. Dies wird ein paar Dinge garantieren:

Solange die Featureliste richtig priorisiert ist, erhält der Kunde immer die nächstwichtigsten Features geliefert, wodurch sein Nutzen aus seinen Ausgaben maximiert wird (er bekommt "den größten Knall für sein Geld").
Wenn der Kunde kein Geld mehr hat, hat er seine Investition maximiert UND Sie wurden für das bezahlt, was Sie geliefert haben. Niemand wird verletzt, jeder profitiert.
Der Kunde kann seine Meinung über Prioritäten und Funktionen bei jeder Drehung des Rades (an jedem Ende einer Interaktion) ändern. Ein deutlicher Vorteil gegenüber normalen Festpreisverträgen.

Wahrscheinlich gibt es noch mehr, aber das oben Genannte sollte ausreichen, um Ihre Vertriebsmitarbeiter in die richtige Richtung zu bringen.

— wolfgangsz
quelle

Betreff: "Niemand wird verletzt, jeder profitiert" - Mit Ausnahme des Mannes, der entlassen wurde, weil er seinem Chef versprochen hatte, dass er für $ X ein Softwarepaket bekommen würde, das XYZ macht. Leider funktioniert das Softwarepaket dank Agile nur mit XY. P'd off Manager, feuert Kerl, der unterliefert. Vielleicht war ich gerade in ganz anderen Branchen als die meisten agilen Befürworter, weil sie kein Problem darin sehen können, dem Kunden nur Teillösungen zu liefern. OTOH, ich kann den Zweck nicht erkennen, eine Teillösung zu liefern, da die Chancen stehen, dass das Produkt für den Kunden ziemlich unbrauchbar wird.

— Eintauchen

Offensichtlich haben Sie noch nicht in einem angemessenen agilen Umfeld gearbeitet, sonst würden Sie diese Art von Bemerkung nicht machen. Wenn XYZ benötigt wird, wird XYZ geliefert. RST und UVQ werden möglicherweise nicht geliefert, aber da sie eine geringere Priorität haben, musste der Kunde auch nicht dafür bezahlen. Wenn Ihre Entwickler mit ihren Schätzungen so weit vom Ziel entfernt sind, dass sie nicht einmal XYZ nach eigenen Schätzungen liefern können, müssen Sie natürlich einige Lehren ziehen.

— Wolfgangsz

3

Nun, ich sehe es nicht als einen Fall von "Es wird fertig sein, wenn es fertig ist". Die agile Methodik fördert das regelmäßige Anbieten von Ergebnissen, etwa alle zwei Wochen. Aus diesem Grund ist der Kunde ein wichtiger und sehr aktiver Teil des Projekts während seines gesamten Lebens, da er Anleitungen gibt, wie die Merkmale Ihres Produkts Gestalt annehmen. Wenn überhaupt, sieht ein Kunde die Ergebnisse eher als gegen Ende eines Projekts, wie beim Wasserfall-Ansatz.

Solange Sie noch einmal betonen, dass der Kunde ein aktiver Teil des Projekts sein wird und dass er sieht, dass das Projekt frühzeitig Gestalt annimmt, kann dies sicherstellen, dass es nicht darum geht, zu warten, bis es fertig ist.

— Marlon
quelle

Nur um es klar zu sagen - ich sage nicht, dass Agile meiner Meinung nach dieser Beschreibung entspricht, aber so sehen es Kunden / Verkäufer oft. Agile ist großartig bei den Iterationen - aber macht es schwierig, das Ende des Projekts zu bestimmen, oder?

— Sunwukung

4

@sunwukung - Ihr Verkaufsteam verkauft nicht die Tatsache, dass niemand das Ende eines längeren Projekts von Anfang an genau vorhersagen kann.

— JeffO

Ich stelle mir vor, der beste Weg, um eine Idee für das Ende des Projekts zu bekommen, wäre, ein Projektplanungsgespräch mit Ihrem Kunden zu führen und alle gewünschten Funktionen aufzulisten. Dann können Sie ein vollständiges und vollständiges Projekt-Backlog erstellen. Setzen Sie sich mit Ihrem Team zusammen und fordern Sie es auf, Schätzungen für den gesamten Rückstand zu erstellen. Verwenden Sie diese Schätzungen als Anhaltspunkt dafür, wann Ihr Projekt abgeschlossen sein wird.

— JuniorDeveloper1208

1

@sunwukung - Nein, nicht wirklich, das Sitzen und Planen eines Rückstandes ist auch für Agile eine gute Idee. Es ist die Implementierung des Entwicklungsprozesses, der Agile von Waterfall unterscheidet (Agile ist iterativer). Ich denke, Ihre größte Hürde nach dem Verkauf von Agile an Ihre Kunden besteht darin, es tatsächlich umzusetzen. Ich habe dies einige Male durchlaufen, und es kann ein schmerzhafter Prozess sein.

— JuniorDeveloper1208

1

Entschuldigung - ja, ich verstehe - wir haben die Backlog-Methode verwendet, um das geschätzte Zustellungsfenster aufzurauen (mit Pivotal Tracker, großartige App übrigens). Die Spannung ergibt sich aus der Unschärfe, die diese Methode im Hinblick auf die Diskrepanz zwischen den anfänglichen Meilensteinen dieser Methode und den tatsächlichen ETAs erzeugt, sobald die Geschwindigkeit sich zu beruhigen beginnt. IMO

— dreht sich

2

Obwohl der Ort, an dem ich arbeite, eine schreckliche Bastardisierung von Agile darstellt, ist es meiner Meinung nach für Kunden wahrscheinlicher, dass sie Softwareentwicklung in Iterationen bevorzugen als vollständige Releases.

Iterationen eignen sich für individuelle Anforderungen von Kunden, da sie etwas anfordern und es erhalten, wenn das Feature implementiert wird, und nicht erst, wenn es fertig ist, und alle anderen Dinge, die für ein Release damit gruppiert wurden, werden ebenfalls ausgeführt.

Ich habe noch nie einen Kunden gesehen, der sagte: "Wir möchten diese Funktion und wir möchten 8 Monate warten, bis sie mit einer Reihe anderer Funktionen geliefert wird, die uns egal sind."

— Shawn D.
quelle

1

Dies kann von der Größe des Kunden abhängen. Ich denke, im Fall von Desktop-Software ist es nicht ungewöhnlich, dass größere Unternehmen keine Massen-Neuinstallationen / Image-Tests usw. durchführen möchten. häufig und in diesen Fällen würden sie weniger häufige "Veröffentlichungen" bevorzugen. Der Entwickler kann jedoch weiterhin intern Iterationen durchführen und diesen Kunden einfach einen offiziellen Schnitt der Anwendung in einem vom Kunden bevorzugten Intervall präsentieren.

— Adam Lear

+1 für "Wir möchten diese Funktion und möchten 8 Monate warten, bis sie mit einer Reihe anderer Funktionen geliefert wird, die uns egal sind."

— Sunwukung

2

Wie wäre es mit einem Zahlungszyklus, der mit den Iterationen übereinstimmt? Die Idee von Agile ist, dass Sie nur in kurzen Abständen wirklich planen und schätzen können und der Schub und das Engagement für diese kurzen Zyklen immer noch stark sind. Warum also nicht die Finanzierung auf die gleiche Art und Weise anstreben - die Kunden sollen mit $$ zum Job beitragen, während sie gleichzeitig mit Beratung beitragen. Denn wenn sie nicht bekommen, was sie wollen, sollten sie nicht dafür bezahlen.

Und dann herausfinden, was beim Beenden eines Projekts passiert. Besitzt der Client beispielsweise den Code oder nur die ausführbare Datei? Dies würde jedoch mit früheren Wasserfallprojekten in Einklang stehen.

— bethlakshmi
quelle

Ich stimme dem zu, ich vermute, dass ein Teil des Problems für das Unternehmen darin liegt, die jährlichen Einnahmen zu prognostizieren (was die Investoren beruhigt), mit diesen "kurzfristigen" Finanzierungsschüben.

— Sunwukung

Ich frage mich, ob Sie von einem Vertragsmodell stehlen können? Es erhöht das Risiko von Ausfallzeiten, wenn Kunden abrupt "Danke, aber nein" sagen, was dem Modell der Vertragsarbeit ähneln sollte.

— Bethlakshmi

1

Die Idee von Agile ist, dass Sie schnell iterieren und genau festlegen, was Sie am Ende jedes Sprints liefern werden. Wenn also die 2/3/4 Wochen Ihres Sprints abgelaufen sind, haben Sie greifbare Merkmale in Ihrer Anwendung / Ihrem Projekt dass Sie Ihrem Kunden präsentieren und Feedback bekommen können.

ETA: Sie könnten "Sprints" zu "Meilensteinen" bündeln, mit festgelegten Ergebnissen, und die Zahlung pro Meilenstein erhalten.

— JuniorDeveloper1208
quelle

Dies ist, was ich im Geschäft zu fördern versuche - für "Bühnentore" bezahlen. Entscheidend ist der endgültige Liefertermin - muss der Kunde auf diesen konkreten Endtermin verzichten?

— Sunwukung

Schwer zu sagen, nach ein paar Sprints sollten Sie in der Lage sein, die Geschwindigkeit Ihres Teams zu ermitteln (Arbeitsaufwand pro Sprint) und nachzuweisen, dass Sie über einen vollständigen Rückstand verfügen (Liste der Aufgaben / User Stories, aus denen sich ein zusammensetzt) Projekt abschließen) sollten Sie in der Lage sein, Ihren Endtermin vernünftig vorherzusagen, indem Sie sich Ihre Abbrände ansehen ).

— JuniorDeveloper1208

2

@sunwukung, Auch hier verpasst du den Punkt, nachdem jeder es dir so perfekt beschreibt. Agile garantiert, dass der Kunde am Ende jedes Sprints eine funktionierende Software erhält. Wenn sie immer noch ein FESTSTELLUNGSDATUM für ALLE FUNKTIONEN wünschen, dann können sie das haben, aber nur für die Funktionen, die bei der Unterzeichnung des Vertrags vereinbart wurden. Es ist unfair und unvernünftig für sie, ihre Anforderungen zu ändern und zu erwarten, dass die Frist GLEICH bleibt!

— maple_shaft

1

Sagen Sie ihnen einfach, dass sie während der Entwicklung in der Lage sein werden, ihr Projekt am Ende jedes Sprints zu sehen, immer in einem funktionierenden Zustand und bereit für Feedback, es sollte nicht schwer zu verkaufen sein, Agilität ist exzellent.

— JuniorDeveloper1208

1

@sunwukung, Es hört sich so an, als ob die Firma es besser machen würde, wenn SIE den Geschäftszweig in diesem Fall repräsentieren würden :) Ich weiß nicht, was Sie dem Geschäftszweig sagen können, um sie davon zu überzeugen, was Sie bereits wissen. Sie werden wahrscheinlich nicht auf dich hören. Es klingt leider so, als ob die technische Seite in das 21. Jahrhundert voranschreitet und die geschäftliche Seite in der Vergangenheit liegt. Dies ist kein einfaches Problem, und Sie sind wahrscheinlich nicht in der Lage, dieses Problem zu beheben.

— maple_shaft

1

Ich selbst bin nicht davon überzeugt, dass Sie ein festes Projekt verkaufen und Agile an Ihrer Seite handhaben sollten, sondern Iterationen an Ihren Kunden verkaufen sollten.

Iterationen sind klar zu verstehen, und Sie mischen die beiden Konzepte nicht.

In den folgenden beiden Dokumenten finden Sie einige Informationen zu den Interaktionen von Agile Management und Verkaufsprozessen:

http://www.nayima.be/html/fixedpriceprojects.pdf & http://www.nayima.be/html/agilefixedprice.pdf