A volte con disappunto il cliente comunica che il risultato non soddisfa le aspettative, eppure tutti i requisiti tracciati nelle fasi preliminari sono stati correttamene implementati e accettati dal cliente.
Quello descritto è un rischio molto concreto dell’approccio tradizionale waterfall su progetti di carattere innovativo. Le macro fasi tipiche waterfall prevedono: analisi, disegno, implementazione e test (più altre non rilavanti per l’argomento). Nella fase di analisi dei requisiti l’interazione cliente/fornitore è molto intensa ed è il momento in cui il cliente trasmette al fornitore le proprie necessità e aspettative. Questa fase inizia con un processo più o meno formale in cui il cliente comunica “cosa” si aspetta che il sistema faccia e termina con un processo formale in cui il fornitori descrive “come” intende implementare le richieste cliente. Il documento che descrive “cosa” si aspetta il cliente, ossia le aspettative del cliente, è il documento dei requisiti. Il documento che descrive “come” viene implementato il requisito è il documento di analisi tecnico-funzionale.
Si arriva alla fine dello sviluppo e l’amara sorpresa per cliente e fornitore è che il sistema sviluppato non soddisfa le aspettative. I costi per risolvere una situazione come questa sono molto alti, occorre mettere in campo numerosi giorni uomo per smontare quanto implementato e implementare in modo diverso. La ricerca delle “responsabilità” diventa quindi una missione per cliente e fornitore.
L’origine di questa situazione è legata a queste due situazioni:
- Il cliente non ha espresso i requisiti con sufficiente dettaglio. Il livello di dettaglio dei requisiti è fondamentale e anche nella vita quotidiana e un approccio superficiale può mettere in difficoltà. Immaginate di voler comprare una macchina, descrivete ogni singolo dettaglio vi viene in mente, colore, optional, motorizzazione… ma non esprimete nulla sulla ruota di scorta. Date per scontato che arrivi il kit riparazione e invece arriva il ruotino.
- L’analisi non è sufficientemente dettagliata per consentire al cliente di capire gli impatti e le implicazione di quello che verrà implementato. Nel esempio di prima supponiamo che il cliente specifica anche che desidera il kit di riparazione, perché sa che è più pratico. Quando riceve il veicolo scopre che i tagli non possono essere riparati con il kit riparazione, si aspettava di poter risolvere qualsiasi foratura.
Al di là della responsabilità formale, ciò che vorremo è evitare che si presenti una situazione di macato soddisfacimento delle aspettative. Il problema si presenta soprattutto nei progetti waterfall e si accentua se il progetto ha carattere di innovazione per il cliente. L’innovazione infatti non consente al cliente di mettere a fuoco tutti gli aspetti del nuovo sistema, soprattutto gli impatti sui processi interni, ruoli e attività. Il requisito diventa spesso vago e molto generico con repentini cambi di idea e prospettiva. E’ qui che il fornitore dovrebbe intervenire con un approccio Agile, scomponendo il progetto in Sprint, con time frame limitati aiuta focalizzare su singole tematiche più gestibili. Inoltre al termine dello Sprint abbiamo un risultato tangibile da condividere con il cliente.
La principale critica a quest’approccio è la poca visibilità di insieme e il fatto che potrebbero essere necessari numerosi re-work con conseguente aumento dei costi. La seconda critica mossa è la difficoltà se non impossibilità ad avere una stima dei costi complessivi e del tempi necessario. In effetti entrambe le critiche sono corrette in un progetto Waterfall guida lo scope/perimetro, il tempo e i costi ne sono una conseguenza del perimetro. E’ bene ricordare sempre che un approccio Waterfall si applica bene (leggesi: rispetto tempi, costi) solo se il perimetro di progetto è ben definito, dettagliato e con poche variazioni nel tempo.
In un progetto Agile i dati certi sono la durata di uno Sprint e la composizione del team, tutto il resto è flessibile e viene determinato al proseguire delle attività. Questa flessibilità ha il vantaggio di ridurre il rischio di arrivare a fine lavoro e scoprire che la soluzione non soddisfa le aspettative, consente di effettuare cambi di direzione in corsa e rende quasi impossibile una stima del impegno complessivo a inizio lavori.
Lascia un commento