Una domanda che ti ho già fatto e che ti ripropongo oggi è “per fare quello che devi fare, che cosa devi fare?”. La parafrasi della famosa battuta di Totò che, trovatosi a Milano con Peppino, chiede così informazioni ad un severo vigile urbano meneghino “Scusi buon uomo, per andare dove dobbiamo andare, dove dobbiamo andare?”
Tradotto più esplicitamente: cosa devi fare, in termini di lavoro e attività, per realizzare un risultato o raggiungere un obiettivo?
Pensa di dover preparare una maratona. Sembra una cosa fuori dalla portata dei più, ma non è così. L’importante è fare le cose per gradi. Chiunque sia sano e senza particolari problemi di salute può arrivare a correre, al ritmo che gli è consono, 42 km e 195 metri. Diciamo che senza intoppi puoi farcela in 1 anno.
Se questo è l’obiettivo, il risultato da raggiungere è quello di riuscire a correre per tutta la distanza prevista. Qual è l’impegno totale che devi prevedere? In questi casi si fanno le cose con metodo, con una serie di tabelle di allenamento. La prima tabella ha lo scopo di portarti a correre 1 ora di seguito e prevederà sessioni di allenamento con “lavori” (questo è il termine tecnico) di corsa lenta di durata via via crescente.
Poi, quando hai costruito una prima base, passerai ad una seconda tabella, con lavori differenti. Alcuni tesi ad incrementare la tua resistenza, altri a potenziare il tuo “motore”, come i “lavori ripetuti”. Ad esempio, una sessione di allenamento sarà costituita da 20 km di corsa lenta e la sessione successiva, dopo il riscaldamento, da una serie di ripetizioni sui 1000 metri, da corrersi ad un ritmo superiore di una certa percentuale a quello della tua corsa lenta.
Infine, se tutto va bene, nei 3 mesi precedenti la gara seguirai una terza tabella, più specifica, che ti porterà, diversificando ulteriormente i lavori (con aggiunta di ripetute più brevi e veloci, più lunghe e lente, salite, etc.) a correre almeno circa 35 km come distanza massima, abituando il tuo organismo ad uno sforzo prolungato al ritmo che ipotizzi di tenere in gara. Non correrai in allenamento l’intera distanza dei 42 km, perché sarebbe uno sforzo eccessivo e ti logoreresti inutilmente, ma se hai fatto le cose per bene quei 5-7 km mancanti saranno un gap sormontabilissimo in gara.
Tornando alla domanda iniziale, per “fare quello che volevi fare”, cioè essere in grado di correre la distanza di maratona, “cosa hai dovuto fare?”. Semplice, basta sommare la durata e la distanza di tutte le sessioni di allenamento dei tuoi 12 mesi di preparazione. Scoprirai così di aver percorso in 1 anno circa 700 km, distribuiti tra 450 km di corsa lenta, 100 km di ripetute lunghe e lente, 100 km di ripetute medie e 50 km di ripetute veloci. Questo è tutto il lavoro che hai dovuto fare. Tutto l’impegno che ci hai dovuto mettere.
Warm up
Lo “scope” di progetto non va confuso con lo “scopo”. Qualsiasi progetto ha un perché da inseguire, lo scopo appunto, che di solito consiste nella realizzazione di un prodotto, di un servizio o di un risultato di un qualche tipo, come preparare la maratona di New York.
Lo scope è invece tutta e sola la quantità di lavoro necessaria a raggiungere lo scopo del progetto. Il termine è talmente specifico che spesso non viene tradotto e lo si lascia in inglese. Nella maggior parte dei testi in italiano di Project Management viene usata la parola “ambito”. “Questa attività è in ambito” significa che è un’attività da eseguire, assieme ad altre, per concorrere alla realizzazione del risultato (cioè dello scopo).
Più efficace di ambito è forse il termine “perimetro”, evocativo del concetto di uno spazio compreso entro determinati limiti in cui collocare tutto “quello che dobbiamo fare per fare quello che dobbiamo fare”. Dire che un’attività è nel “perimetro di progetto” dà subito l’idea del fatto che sia necessario includerla per conseguire il risultato.
Lo strumento principe per rappresentare “il lavoro all’interno del perimetro” è la WBS (Work Breakdown Structure).
Per individuare il lavoro da fare, la WBS parte da quello che bisogna realizzare e consegnare (i deliverable) per definire poi la gerarchia di attività necessarie a tale realizzazione. Ma “quello che dobbiamo fare” è caratterizzato da specifici requisiti che rappresentano in concreto le aspettative e necessità di chi quel prodotto o servizio dovrà poi utilizzare. Il ponte che stiamo costruendo deve ospitare solo la sede stradale o anche una linea ferroviaria? Il nuovo sistema di gestione informatizzata dei documenti quali funzionalità irrinunciabili dovrà garantire ai suoi utilizzatori?
Tra gli allenamenti per preparare la maratona di sicuro non figurano gli scatti brevi. Non ti servirebbero, sarebbero controproducenti rispetto ai requisiti di una gara di resistenza. Sembra così logico da rasentare l’ovvio dire che il primo passo per descrivere “quello che dobbiamo fare per fare quello che dobbiamo fare” è identificare con cura i requisiti, perché da questa attività dipende gran parte del successo del progetto.
Su questo, completato il riscaldamento, vertono i nostri esercizi di oggi.
Esercizi
Esercizio 1: definire le priorità è la tua più grande priorità
In qualsiasi progetto i requisiti di ciò che devi realizzare non possono essere tutti critici allo stesso modo. Definire però quali siano più importanti e quali meno è sempre un’operazione rischiosa, perché ha a che vedere con la tua capacità di capire le reali necessità di chi utilizzerà il tuo prodotto/servizio. Quello che devi garantire è la sicura soddisfazione di un insieme “core” di requisiti irrinunciabili (quelli senza cui il prodotto/servizio non sarebbe proprio fruibile) più altri, magari non così indispensabili ma comunque utili. E qui entri in una enorme zona grigia: come puoi decidere quanto un requisito sia davvero utile a qualcuno? Un criterio promettente potrebbe essere quello di classificare i requisiti potenziali in funzione della loro capacità di “dare valore” a chi fruisce del tuo prodotto/servizio in funzione della “vision” che lo ha ispirato.
Immagina di essere uno startupper all’inizio dell’800, in piena Industria 1.0. Durante un’apericena alla corte del Re di Prussia ti capita di assistere al pitch di un nobile tedesco, Karl Friedrich von Drais, su un innovativo mezzo di locomozione alternativo al cavallo, chiamato Velocipede. Intuisci ben prima di Casey Neistat che “Ideas are cheap and easy. Everybody has ideas [but…] EXECUTION IS ALL THAT MATTERS” e ti metti subito al lavoro con un progetto per realizzare un nuovo prodotto, per il quale il tuo socio marketeer ti suggerisce il nome evocativo di “i-Bicycle”.
Pianifichi il rilascio di una prima versione 1.0 di “i-Bicycle” costituita solo da un telaio, una sella e 2 ruote. In realtà avevi idenfiticato molti altri requisiti. La presenza di un manubrio per cambiare direzione, di freni per evitare di usare i piedi sul terreno, di pedali e di un sistema di trasmissione, di pneumatici gonfiabili per attutire le asperità, di cambio e rapporti per fare meno fatica in salita.
Tuttavia, sapevi che se avessi voluto realizzare la tua i-Bicycle completa sin da subito di tutte queste cose, probabilmente qualche concorrente ti avrebbe bruciato sul tempo uscendo sul mercato prima di te. Allora hai dovuto definire delle priorità, scegliere quali requisiti realizzare per primi e per questo sei andato alla “vision” di partenza del prodotto (se non ne avessi avuta una sarebbe stato un bel problema): un mezzo di locomozione per spostarsi più velocemente che a piedi, e per questo i requisiti davvero irrinunciabili erano telaio, sella e 2 ruote. Tutto il resto poteva venire dopo.
Un paio di secoli più tardi il metodo agile DSDM (Dynamic Sistem Development Method) avrebbe introdotto un modello di prioritizzazione chiamato MoSCOW, per classificare i requisiti di progetto in base alla capacità di dare valore al cliente.
Mo – Must Have (ciò di cui non puoi fare a mano: telaio, sella e 2 ruote)
S – Should Have (ciò che sarebbe importante ci fosse: freni e pedali)
CO – Could Have (ciò che sarebbe desiderabile ci fosse: trasmissione a catena, pneumatici gonfiabili, campanello)
W – Won’t Have (this time) (ciò che sarebbe bello ma che per adesso non ci possiamo permettere di avere: cambio Shimano a 7 rapporti e sospensioni)
Da oggi quando sei indeciso su come dare le priorità usa questo schema con onestà intellettuale e le cose si semplificheranno.
Esercizio 2: perché, perché, perché
Dimentica per il momento quella fastidiosa complicazione chiamata “cambiamento” (tecnologico, organizzativo, di business, ecc.) che rende i requisiti di qualsiasi progetto più o meno instabili e volatili. C’è un altro problema a monte. Che i requisiti non sono quello che l’utente di un prodotto/servizio vuole, ma ciò di cui ha bisogno. Se ti limiti a soddisfare solo i desideri della controparte rischi di realizzare qualcosa che poi non verrà mai usato, oppure l’utente/cliente si renderà conto in corso d’opera che ciò che gli serve davvero non è quello che aveva detto di volere all’inizio. Da qui ritardi, estensione incontrollata dello “scope”, corpose liste di richieste di modifica e varianti in corso d’opera, rework ed extra costi.
Un modo per evidenziare le reali necessità è chiedere perché, reiteratamente, come fanno i bimbi. Uno strumento, ben noto ai Project Manager nell’ambito del controllo di qualità è la “Analisi Causa-Effetto” con la “tecnica dei 5 perché”, che puoi usare per far emergere bisogni e requisiti reali dal mare delle richieste e dei desiderata. La figura ne riporta un esempio.
Identificati i bisogni, potrai definire, assieme alla controparte, il problema da cui bisogna sempre partire per poi trovare la soluzione attraverso il progetto.
Esercizio 3: parti sempre dal problema di qualcuno. Il prodotto/servizio che realizzi con un progetto ha senso se risolve i problemi di qualcuno, altrimenti non serve a nessuno. Quindi potremmo dire che un buon progetto è sempre in cerca di un problema da risolvere ed è da quello che dovresti partire, non dalla soluzione (cioè dal requisito come risposta ad un’esigenza). Immaginare soluzioni e feature è gratificante. Se ne parla volentieri con gli altri. E poi una soluzione senza un problema ha il pregio di funzionare sempre (almeno sulla carta…).
I problemi sono invece più difficili da esplicitare. Parlarne può creare disagio, far sorgere troppe domande e spingere a rivedere alcune assunzioni. Da dove cominciare? La prima cosa è parlare con l’utente per assicurarti che gli stai risolvendo un problema, anche se il prodotto/servizio è in fase embrionale e molte cose sono appena abbozzate. La seconda cosa sarà parlare ancora con l’utente. La terza cosa: parlare di nuovo con l’utente!
Solo dopo puoi ipotizzare i problemi che pensi di poter risolvere con il memorabile prodotto/servizio che il tuo progetto rilascerà.
In molti metodi agili per descrivere i requisiti si usano le “user story”, un formalismo leggero e facile da usare che esprime il requisito secondo la seguente sintassi:
Come <utente/ruolo> Condizione <che è/ha> Voglio <Obiettivo> Così che <beneficio>
In figura riporto un esempio. Il vantaggio di questa rappresentazione è che spinge a identificare subito sia un beneficio concreto apportato dalla soddisfazione del requisito che il beneficiario potenziale.
Però questa è già la soluzione. Prima dovresti identificare il problema a monte che la richiede. Per questo puoi utilizzare le “problem story” per descrivere il problema di qualcuno in funzione di una sua esperienza in uno specifico contesto. La sintassi della problem story è la seguente:
I believe <tipo di persona/soggetto interessato> Experience <tipo di problema> When doing <attività> OR Because of <limite o vincolo>
Magari non è sempre così, ma parecchie volte ad un problema corrisponde in modo più o meno naturale almeno una soluzione. Quindi se individui e descrivi 10 problem story diciamo che non dovresti avere difficoltà ad individuare almeno 10 user story e altrettanti requisiti che a questo punto rispondono davvero alle esigenze del tuo utente/cliente.
Defaticamento e stretching
Definire il perimetro di progetto, in termini di prodotti/servizi da rilasciare e lavoro per realizzarli, non è affatto semplice. Prima di parlare di attività e di WBS, alla base di qualsiasi progetto c’è la necessità di soddisfare le necessità e le aspettative di qualcuno attraverso l’implementazione di requisiti che le rappresentino.
Ci sono diversi problemi. Il primo è distinguere i requisiti davvero importanti da quelli magari utili o desiderabili ma non indispensabili. Si tratta di un’attività difficile, perché ti costringe a scelte che però puoi rendere meno incerte e dolorose applicando il modello di prioritizzazione MoSCOW. I requisiti “must to have”, quelli davvero irrinunciabili, derivano direttamente dalla “vision” del prodotto/servizio che devi realizzare. Per tutti gli altri c’è sempre tempo.
Il secondo problema è confondere ciò che qualcuno vuole con ciò di cui ha realmente bisogno. Non sempre siamo consapevoli di quello che ci serve. Possiamo convalidare meglio una richiesta sottoponendola alla prova dei “5 perchè”, applicando come un bambino la domanda “perché?” alle risposte intermedie che via via si susseguono.
Il terzo problema (ce ne sarebbero in verità anche altri ma rimandiamo ad un prossimo articolo la loro trattazione) è di partire dal problema di qualcuno e non direttamente dalla soluzione. Parlando con chi utilizzerà il nostro prodotto/servizio, dovremmo cercare di identificare i problemi che si trova ad affrontare concretamente nello scenario attuale, ad esempio attraverso la tecnica delle “problem story”. Individuati i problemi, dovrebbe essere più semplice far corrispondere almeno un requisito/soluzione a ciascuno di essi.
Tutto questo può darti una mano a indirizzare meglio il successo dei tuoi progetti, sempre però con una buona dose di umiltà perché, come diceva Tolstoj, “l’uomo saggio fissa i requisiti solo per sé stesso, l’uomo sconsiderato li fissa per gli altri”.
Facebook Comments