Finanziamento di progetti agili

La società in cui lavoro si sta muovendo provvisoriamente verso una strategia di gestione del progetto Agile - avendo sperimentato le "gioie" di cascata una volta per molte. La chiave di ciò è uno spostamento dell'enfasi verso la fornitura di funzionalità rispetto al rispetto di scadenze rigide.

Mentre il processo di sviluppo e la relazione con il cliente sono certamente migliorati dalle versioni iterative promosse tramite Agile, sta dimostrando in qualche modo più difficile applicare la stessa logica alle strategie di finanziamento del progetto. I clienti spesso non sono abituati a concetti come Agile ed esprimono grande preoccupazione per ciò che percepiscono come un caso di "sarà pronto quando sarà pronto".

Mi piacerebbe ascoltare i pensieri e le esperienze delle persone nel finanziamento di progetti Agile

modifica: voglio sottolineare che non sto chiedendo alla gente di spiegarmi i pro e i contro del metodo Agile , né che credo che Agile equivalga a "sarà pronto quando sarà pronto", questa è una paura espressa dal clienti / aziende con cui ho lavorato per sostenere le pratiche di sviluppo Agile.

Quello che mi interessa sono le esperienze che le persone hanno avuto nel risolvere i conflitti tra i metodi "tradizionali" di budget a cascata radicati nelle relazioni / clienti aziendali e metodi di sviluppo più progressivo - e le strategie di budget che hanno adottato per supportare tale evoluzione.

Se sei stato in grado di dare un preventivo su un progetto con una data finale esatta su tutte le funzionalità, perché sei passato ad un approccio agile? Tu e tutti gli altri lottate con questo e un approccio agile sta affrontando questo fatto. Usalo come propaganda contro la concorrenza. La Southwest Airline non ti promette un posto in isola come tutti gli altri che lo fanno e poi lo dà a qualcun altro.

Naturalmente il cliente vuole una data di fine esatta. Vogliono un software economico e privo di bug consegnato in anticipo, indipendentemente da eventuali modifiche alla richiesta originale. Dì al tuo team di vendita di imparare come vendere un progetto usando principi agili. Più interazioni passerai, più sarai in grado di sapere quando il progetto sarà finito. Il cliente impara anche a valutare gli effetti delle richieste di modifica.

I progetti agili non funzionano come "sarà pronto quando sarà pronto". Questa è una linea classica dall'ingegneria delle cascate.

I progetti agili sono completi quando il cliente decide di non voler spendere più soldi per funzionalità aggiuntive. Questo potrebbe essere convertito in un punto di vendita chiave dai tuoi venditori. Invece di impegnarsi in un set fisso di funzionalità (la cui necessità può o non essere nota in anticipo) per un importo fisso di denaro, il cliente può iniziare con un importo iniziale per un set di funzionalità iniziale e poi prenderlo per fasi. Ciò garantirà un paio di cose:

• Fintanto che l'elenco delle funzionalità è correttamente prioritario, il cliente riceve sempre le funzionalità più importanti successive, massimizzando così il suo beneficio dalla sua spesa (ottiene "il miglior rapporto qualità-prezzo").
• Se il cliente esaurisce i soldi, ha massimizzato il suo investimento E tu sei stato pagato per quello che hai consegnato. Nessuno si fa male, tutti traggono profitto.
• Il cliente può cambiare idea su priorità e caratteristiche ad ogni giro della ruota (ogni estremità di un'interazione). Un netto vantaggio rispetto ai normali contratti a prezzo fisso.

Probabilmente c'è di più, ma quanto sopra dovrebbe essere sufficiente per far andare i tuoi venditori nella giusta direzione.

Bene, non lo vedo nel caso di "Sarà pronto quando sarà pronto". La metodologia agile promuove l'offerta di risultati su base regolare, come ogni due settimane. Ecco perché il cliente è una parte importante e molto attiva del progetto per tutta la sua vita in quanto fornisce una guida in termini di come le caratteristiche del tuo prodotto prenderanno forma. Semmai, un cliente inizierà a vedere i risultati prima, piuttosto che verso la fine di un progetto, come nell'approccio a cascata.

Finché si ribadisce che il cliente sarà una parte attiva del progetto e che vedrà il progetto iniziare a prendere forma presto, ciò potrebbe assicurare loro che non si tratta di aspettare fino a quando non è finito.

Sebbene il posto in cui lavoro faccia un'orribile bastardizzazione di Agile, penso che i clienti preferiscano lo sviluppo del software nelle iterazioni rispetto alle versioni complete.

Le iterazioni si prestano a richieste individuali da parte dei clienti, in quanto richiedono qualcosa e lo ottengono quando la funzionalità è implementata, non una volta che è stata eseguita e anche tutte le altre cose che sono state raggruppate con essa per una versione.

Non ho mai visto un cliente dire "Vogliamo questa funzione e vogliamo aspettare 8 mesi per essere consegnata con un sacco di altre funzionalità che non ci interessano".

Che ne dici di stabilire un ciclo di pagamento in sintonia con le iterazioni? L'idea di agile è che puoi davvero pianificare e stimare solo a scatti brevi, e la spinta e l'impegno sono ancora forti per questi brevi cicli. Quindi perché non indirizzare i finanziamenti allo stesso modo: i clienti contribuiscono al lavoro con $$ mentre stanno contribuendo con la guida. Dopotutto, se non ottengono ciò che vogliono, non dovrebbero pagare per questo.

E poi capire cosa succede al termine di un progetto - ad esempio, il client possiede il codice o solo l'eseguibile? Ma ciò sarebbe in linea con i precedenti progetti a cascata.

L'idea di Agile è quella di iterare velocemente e stabilire esattamente cosa consegnerai alla fine di ogni sprint, quindi quando le 2/3/4 settimane del tuo sprint sono terminate, hai caratteristiche tangibili nella tua applicazione / progetto che puoi presentare al tuo cliente e ottenere feedback.

ETA: è possibile raggruppare gli "sprint" in "pietre miliari", con risultati consolidati e ricevere pagamenti per traguardo.

Non sono convinto che dovresti vendere un progetto fisso e gestire Agile dalla tua parte, ma piuttosto vendere iterazioni al tuo cliente.

Le iterazioni sono chiare da capire e non mescoli i due concetti.

I seguenti due documenti ti forniranno alcune informazioni sulla gestione agile e sulle interazioni dei processi di vendita:

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