Aspettative e requisiti

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:

  1. 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.
  2. 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.

PMP vs. Agile

Anche di recente mi sono ritrovato coinvolto in una discussione in cui le metodologie Agile sono state definite come destrutturate e prive delle caratteristiche necessarie al raggiungimento di un obiettivo. Diciamo come una piuma la vento, che si fa trasportare in tutta leggerezza e svolazza senza meta. Dall’altro lato qualcuno ha descritto le dottrine PMI come qualcosa di farraginoso e talmente strutturato da fornire alibi a chiunque per il mancato raggiungimento degli obiettivi. Credo che per entrambe le posizioni la verità sta nel giusto equilibrio.

La gestione dei progetto con metodologie tradizionali si presta bene quando c’è una buona conoscenza del dominio applicativo oggetto del progetto. Se devo asfaltare una strada, con tutte le difficoltà che posso incontrare il perimetro è ben definito e la conoscenza è ben consolidata. Una delle prime lezioni del PMBOK, il libro che descrive i processi PMI, dice che è compito del PM con il team di progetto individuare quali di tutti i processi sono necessari per il progetto e con quale livello di implementarli. Ad esempio per un progetto privo di rischi (o pochi e noti) non predispongo un registro dei rischi. Per usare una metafora, la gestione progetti tradizionale è come una vacanza in macchina, pianifico le tappe, le soste, gli alberghi. Posso ri-pianificare se un posto non mi piace e voglio scappare, avrò da affrontare degli imprevisti, una gomma bucata, lo sciopero dei benzinai, ma in un modo o nell’altro riuscirò a visitare i posti che mi sono prefissato.

Agile si applica quando l’incertezza è tale da richiedere costanti variazioni a piani di progetto con eventuale rivisitazione del perimetro. Di fatto è come separare il progetto in tanti piccoli progetti di poche settimane (sprint) che consentono di verificare costantemente se si procede nella direzione giusta mantenendo sotto controllo i tempi. In ogni sprint ho tutte le fasi tipiche gestione progetti tradizionle, compresse nel tempo e quindi con formalismi più snelli. Mi azzardo a dire, irritando i puristi) che per alcuni versi “Agile” è più strutturato delle metodologie PM tradizionali, direi che si aggiunge alle metodologie tradizionali come un add-on. Anche usando metodologie Agile posso avere un piano dei rischi un registro degli stakeholder o qualsiasi altro strumento PM che ritengo utile. Sempre usando una metafora, “Agile” è come una vacanza in barca a vela, quando sono in navigazione devo fare il punto nave ogni due ore per correggere la rotta e se il vento e corrente non sono favorevoli rispetto a dove voglio arrivare, può essere che debba cambiare destinazione. Ma la cambusa devo averla pianificata bene secondo un approccio “tradizionale”.

Riassumo:

  • se ho un vincolo forte sul perimento di progetto ma posso variare i tempi e costi di progetto adotterò un approccio tradizionale.
  • se ho un vincolo forte sui tempi ma ho la possibilità di variare il perimetro e i costi adotterò un approccio agile. (Questo approccio è tipico delle newco e dei progetti innovativi perché essendo “nuovi” è molto improbabile riuscire a definire a priori il dettaglio delle caratteristiche)

L’ultima osservazione, nel mondo ideale esiste un progetto che rispetta tempi, costi, perimetro e qualità, nel mondo reale non ne ho mai visti. Ma ho visto molti progetti di successo, sono quelli che soddisfano le aspettative del cliente.

Essere Agile con Agile

Spesso si parla di “Agile”, metodologie, approcci, strumenti, che dir si voglia. I maggiori estimatori ritengono che l'”Agile” deve essere adottato in tutti i sui aspetti per essere efficace, diversamente non si ottengono i risultati attesi.

Credo che occorre essere “Agile” anche nel “Agile”, ho letto quest’articolo che condivido appieno Being Agile with Agile.

WP to LinkedIn Auto Publish Powered By : XYZScripts.com