arrow for title

USER STORY MAPPING: alla ricerca della Comprensione Condivisa

03 Giu, 2019 Metodologie
USER STORY MAPPING: alla ricerca della Comprensione Condivisa

Lo User Story Mapping è quella tecnica, semplice ma estremamente potente, per definire la roadmap da seguire nella realizzazione di un prodotto/progetto. È la chiave per raggiungere la ”Shared Understanding".

"Quanto ci metti? E quanto costa?"

La fatidica domanda, incubo di ogni programmatore.

Una pena obbligatoria da scontare all'inizio di ogni nuovo progetto, alla quale rispondere sempre in modo piuttosto fantasioso e con immotivato ottimismo. Da questa risposta, infatti, deriveranno numerose sofferenze, notti e weekend passati a lavorare, software pieni di funzionalità inutili, email dagli avvocati di manager e clienti.

Per anni ho affidato la mia risposta alla 'tecnica del dado'. Sì, avevamo un grosso dado arancione di gomma in ufficio: bastava tirarlo, leggere il risultato e aggiungere un numero di zeri a piacere. Ma non si è mai rivelata molto efficace.

Per fortuna dall'altra parte dell'oceano c'era chi, già da anni, stava cercando di risolvere questo problema. Anche per me.

Le metodologie che fanno capo al mondo Lean e Agile hanno reso palese che la realtà intorno a noi cambia di continuo e non siamo in grado di prevedere il futuro: è quindi meglio procedere a piccoli step incrementali, verificando ogni volta i risultati ottenuti e riadattando il nostro piano.

Nonostante questa impostazione ci aiuti già notevolmente, chi detta il budget continuerà sempre a fare 'la domanda'. E con tutto il diritto, direi.

Ma è proprio grazie allo User Story Mapping che, da alcuni anni, anche se con le dovute approssimazioni, ho iniziato a dare risposte che avessero un senso.

L'idea

Nel 2008 Jeff Patton, informatico e product manager americano molto attivo nel panorama Lean/Agile, pubblica un articolo dal titolo "The New User Story Backlog is a Map".

Introduce una nuova tecnica, semplice ma estremamente potente, per definire la roadmap da seguire nella realizzazione di un prodotto/progetto, avendo chiaro il quadro generale e costruendo quella ”Shared Understanding", la comprensione condivisa, fondamentale per avere successo.

In cosa consiste?

Tutte le persone coinvolte nel progetto devono capire cosa si vuole ottenere, cosa va fatto e con che priorità: la visione d'insieme di tutti i passaggi per raggiungere il nostro obiettivo ci aiuta, tra le altre cose, a farci un'idea di quali potrebbero essere, all’incirca, i costi e i tempi.

Il backlog dunque, cioé la lista di task (User Stories) da fare, diventa a due dimensioni ed è molto più utile.

Come funziona

1. La conversazione

Lo User Story Mapping è sostanzialmente una conversazione tra chi ha in mente il prodotto da realizzare - diciamo il cliente - e chi dovrà realizzarlo. 

Durante questa conversazione si analizzano tutti gli step, in ordine logico, che il nostro utente ideale dovrà eseguire per ottenere un certo obiettivo. Ricordiamoci quindi che il punto di vista di queste 'storie' è proprio quello dell'utente - da cui il nome User Stories - e non è interessante solo cosa fa, ma anche chi è e perché deve o vuole compiere una certa azione. Solo conoscendolo approfonditamente - grazie a metodologie come il Customer Development, argomento del recente articolo di Mirko Maiorano - saremo in grado di immaginare il suo punto di vista.

Questi step li appuntiamo su dei post-it, in modo da ricordarli in futuro, e li incolliamo su una parete o un tavolo in ordine, in modo che, leggendoli da sinistra verso destra, si possa ripercorrere tutto il viaggio dell'utente: da quando entra in contatto col nostro prodotto, a quando ottiene il risultato desiderato.

Personalmente non ero un amante dei post-it, ma devo riconoscere che durante queste riunioni sono molto comodi: si spostano, si cambiano, le persone li indicano, e tutto ciò non sarebbe possibile su un monitor o un foglio di carta. Ovvio che in un secondo momento nessuno ci vieta di riportare il tutto su un software.

È molto importante sottolineare che questi appunti, brevi frasi che descrivono il comportamento degli utenti, sono solo 'promesse di conversazioni', che faremo poi a tempo debito, quando sarà necessario analizzare i dettagli. Non sono dei 'requisiti'.

Per capirli a fondo, prima di implementarli, dovremo parlarne con chi li ha immaginati o meglio ancora con chi ha quell'esigenza. La loro posizione - e presenza stessa nella mappa - è sempre in discussione, e sicuramente nel corso del tempo, man mano che acquisiremo nuove informazioni, la mappa si trasformerà.

Ti propongo un esempio, ripreso proprio da Jeff. 

Prova a fare il mapping della tua mattinata: elenca tutte le azioni, da quando apri gli occhi a quando esci per andare a lavoro. E così spegnerai la sveglia, preparerai la colazione, farai la doccia, darai da mangiare al gatto, eccetera. Queste azioni, messe una dopo l'altra, descriveranno tutti gli step che tipicamente facciamo per raggiungere l'obiettivo di uscire di casa. Concentrandoci sull'intero percorso, avremo chiara la visione d'insieme, vedremo più facilmente i 'buchi', e faremo in modo di approfondire i dettagli solo quando necessario.

2. I task

A questo punto nascono i primi dubbi: che livello di dettaglio dobbiamo usare per descrivere questi task? 

È sufficiente dire che 'faccio la doccia' o devo elencare tutte le azioni da compiere, come aprire l'acqua, insaponarsi, mettere lo shampoo, eccetera? O ancora, fare la doccia è già troppo specifico, ed è sufficiente dire genericamente 'mi lavo', includendo anche il lavarsi i denti, magari farsi la barba?

Per rispondere a questa domanda chiediamo aiuto ad Alistair Cockburn, usando una metafora legata al mare. Cockburn divide i task in 3 tipi: 

Se alcuni task sono strade alternative per ottenere lo stesso 'goal', li mettiamo uno sotto l'altro: sarà, inoltre, molto utile mappare le varianti che rispondono a dei casi d'uso particolari. Se invece siamo indecisi sull'ordine orizzontale tra due, è perché probabilmente non è così importante (c'è chi prende il caffè prima della doccia e chi dopo).

Messa così, inizia a trasparire qualche criticità, ma resta comunque un esercizio piuttosto facile. Quando si parla di strutturare un software le cose si complicano un po', chiaramente, ma il livello di 'ordine mentale' che in questo modo si dà al progetto è impagabile. 

La mia esperienza personale è che dopo una sessione di User Story Mapping - solitamente un bel po' di ore - i clienti escono dalla porta con una chiarezza e una consapevolezza di cosa vogliono che non avevano mai raggiunto, nonostante, magari, ci siano alle loro spalle mesi di lunghi e complicati documenti in pdf e requisiti tecnici.

3. L'MVP

Ci ritroviamo quindi con questa fila orizzontale di task a formare una sorta di colonna vertebrale della nostra mappa, organizzata in attività, e con sotto una serie di task più dettagliati che scendono in verticale.

Inizieremo a renderci conto di quante cose ci siano effettivamente da fare, in che modo sono connesse tra loro, e potremo finalmente ragionare sulla parte di ottimizzazione.

Quali sono quelle essenziali?

Tornando alla nostra mattinata, immaginiamo che la sveglia non abbia suonato: ci svegliamo per caso, guardiamo l'ora, e subito ci rendiamo conto del disastro. Abbiamo solo 10 minuti per uscire in tempo invece di un'ora! Siamo costretti quindi a scegliere solo i task veramente essenziali per raggiungere il nostro obiettivo: rinunciamo alla colazione? Alla doccia?

È così che dovremmo ragionare quando pensiamo al nostro MVP: una scelta accurata delle cose essenziali per ottenere un obiettivo, il più rapidamente possibile. 

Non serve urlare con i nostri programmatori per dirgli di fare prima, tra l'altro a discapito della qualità. Come dice Patton

"Il tuo lavoro non è quello di produrre più software e più velocemente: è quello di massimizzare il risultato e l'impatto che ottieni da ciò che hai scelto di costruire". 

Touché.

Tracciamo dunque una linea, e teniamo sopra di essa solo i task scelti per il nostro MVP, spostando sotto tutti gli altri. Possiamo ripetere questa scelta anche per milestones successive, anche se più passa il tempo più la possibilità che dovremo ripensare tutto e stiamo facendo un lavoro inutile salirà. 

Ricordiamoci sempre, in fondo, che la scelta di cosa sia più o meno importante fare nella prossima release, è comunque una scommessa - che dovremmo basare il più possibile su dati oggettivi e misurabili - e mai una certezza. 

Dice Eric Ries (autore di Lean Startup) che l'MVP è la cosa più piccola che possiamo creare o fare per confermare o smentire una nostra ipotesi.

Aggiungo un'ultima considerazione molto pratica su questo argomento: per raggiungere l'obiettivo di un task e nello specifico implementare una funzionalità, ci sono sempre parecchi modi alternativi. 

La nostra bravura sta nell'individuare quello che richiede il minimo sforzo: se una volta testata la funzionalità implementata nel modo base vedremo che gli utenti la usano, faremo sempre in tempo a migliorarla, guardando i dati di come è stata utilizzata. Se al contrario questo non succede, avremo risparmiato molto tempo evitando di implementare qualcosa di inutile. 

Per far effettuare un pagamento sul nostro sito, ad esempio, possiamo inizialmente solo chiedere ai nostri utenti di mandarci una mail e gestire la cosa 'a mano' tramite un bonifico. Solo se qualcuno effettivamente lo farà, varrà la pena integrare un sistema di pagamento online, partendo dal più comune, per poi supportare man mano anche quelli meno conosciuti.

4. Le stime

Arrivati a questo punto dovremmo avere chiara la struttura del nostro progetto, gran parte delle cose da fare - anche se qualcosa scapperà sempre - e soprattutto su cosa concentrarci prima. 

Stimare i vari task che ne sono nati - per quanto sempre difficile e non scordandosi che una stima è per sua natura imprecisa - diventa quindi un'operazione molto più abbordabile. Si potrà scegliere di essere un po' più precisi per le prime cose da implementare, e meno per quelle verosimilmente più lontane nel tempo. 

Stimare le singole User Story è un argomento a parte che va oltre le intenzioni di questo articolo. Esistono diverse tecniche e unità di misura: io trovo molto efficace quella del planning poker. Per approfondire questo discorso e il mondo delle User Story in generale, ti invito ad approfondire l'argomento con Mike Cohn, che insieme a Jeff Patton e Eric Ries avrei voluto come professore all'università. Forse non mi sarei trovato a dover lanciare dadi arancioni in ufficio!

Conclusioni

Per approfondire questa tecnica la risorsa principale è ovviamente il libro di Jeff Patton, uscito nel 2014, che non è solo un manuale tecnico su questa specifica pratica, ma un saggio fondamentale per la gestione dei Prodotti. 

Il mondo imprenditoriale e strategico - dove entrano in gioco le metodologie già citate del Customer Development, Lean Startup, o il Design Thinking - incontra il mondo più 'pratico' dello sviluppo software con metodologie Agili e strumenti come le User Stories, proprio grazie a queste mappe. 

Questo, almeno per me, ha rappresentato un po' la chiusura del cerchio e il tassello mancante per arrivare dall'idea iniziale alla sua realizzazione, in un modo molto logico e quasi guidato.

Sempre tenendo ben presente il fine e non il mezzo. La mappa, i post-it, sono solo strumenti per arrivare al vero obiettivo: la comprensione condivisa attraverso delle conversazioni che tengano gli utenti al centro, e ci permettano di focalizzarci sugli obiettivi e validare le nostre ipotesi.

E ora non ti resta che provare e condividere con me la tua esperienza!

Gabriele Giaccari

Blog

Potrebbe interessarti anche:

contattaci

Hai una buona idea ma non sai che pesci prendere?

Parlaci del tuo progetto