Misurare il valore durante il progetto

Nella puntata precedente abbiamo parlato del concetto di misurazione del valore rilasciato durante la creazione di un prodotto e di come questo possa essere usato per tenere sotto controllo lo stato di avanzamento del progetto.

Se in una serie di articoli passati avevamo parlato di quanto fosse importante misurare il valore rilasciato da un prodotto “dopo” la sua uscita sul mercato [1], qui parliamo invece di come provare a valutare il valore prodotto da un item nel backlog, proprio per poter disporre di un differente sistema di misurazione dell’avanzamento del progetto, tarato sul totale del valore da rilasciare invece che sul numero di funzionalità da produrre.

L’obiettivo è di disporre di un sistema di “controllo” sull’avanzamento — non voglio usare il termine “previsionale”, di fatto non corretto — che usi strumenti classici come il burndown chart, ma con metriche differenti: i punti valore al posto dei punti effort. Proviamo a suggerire qualche idea.

Usare lo User Journey per individuare i passi importanti

Durante l’attività di envisioning di un progetto spesso si usano gli user journey per individuare i flussi che un utente svolge per soddisfare i propri “business needs”. Un user journey spesso viene rappresentato come una serie di step, ognuno dei quali rappresenta un’azione o un’interazione dell’utente con il prodotto, qualunque esso sia.

Un User Journey può essere utilizzato per mappare i vari passi necessari per svolgere un determinato compito. Un esempio visuale è rappresentato in figura 1.

Sebbene tipicamente in un User Journey il bisogno viene completamente soddisfatto al termine del “microviaggio”, è pensabile che ogni step possa già di per sé fornire valore o soddisfazione utente. Per questo, a fianco di ogni passo del flusso, è utile raccogliere note e indicazioni circa il valore — economico o di altra natura — e la ipotetica soddisfazione utente che si provoca in quel determinato punto. Il template riportato consente infatti di tener traccia di questi aspetti.

Nella figura 2 abbiamo usato dei simboli (emoticons e dollaro) per rappresentare la soddisfazione utente e il ROI passo per passo: in questa simulazione si è immaginato che lo step 3 sia quello che può dare maggiore soddisfazione all’utente.

Se per esempio il viaggio fosse relativo a un’app per la gestione dei dati dell’allenamento — tipo Strava o simili —, lo step 3 potrebbe essere quello in cui si possono verificare i miglioramenti delle proprie prestazioni —in gergo il cosiddetto KOM o i Personal best — che in genere è una delle funzionalità più interessanti per l’atleta.

A questo punto, dato che ogni step del “viaggio” viene poi smontato in pezzetti, vale a dire funzionalità da implementare, che diverranno item del backlog, possiamo facilmente identificare gli item relativi allo step 3 come quelli con maggior valore utente.

Anche se il viaggio non sarà completato senza tutti gli altri elementi, potremmo considerare maggiore il contributo all’avanzamento del progetto per gli item dello step indicato.

Usare la prospettiva end to end

Volendo estendere il ragionamento appena fatto, passando dal singolo User Journey a tutto il processo End to End, potremmo isolare quei pezzi — unzionalità o, meglio, user stories — che rappresentano le parti più importanti dell’intero processo.

Se provassimo a mappare l’intero processo tramite uno strumento come lo User Story Mapping, potremmo facilmente delineare il cosiddetto Minimum Viable Product e individuare in questo modo le storie con i maggior punti effort, quelle che compongono il cosiddetto Walking Skeleton.

Prospettiva dei differenti utilizzatori

Ogni elemento del backlog dovrebbe fornire la risposta a un preciso bisogno di business. Il formato delle user stories (“in qualità di…” “vorrei…” “affinché…”) è pensato proprio per esprimere in modo chiaro tale bisogno.

Ordinare per valore o priorità i bisogni di un utente potrebbe non essere sufficiente quando il prodotto è pensato per risolvere le necessità di utenti differenti, per esempio con fasi differenti del processo: ci potremmo ritrovare per esempio con due o più liste di needs da soddisfare con elementi di pari importanza o urgenza.

Un aiuto potremmo averlo tramite l’uso dello story mapping, ma potrebbe non bastare.

Generalizzando il ragionamento, potremmo dire che, per capire la priorità fra item differenti, il PO spesso si ritrova a dover prendere in considerazione vari aspetti: importanza per l’utente, peso o priorità fra utenti differenti, ma anche direttive legate alla strategia aziendale, indicazioni derivanti dalle logiche del mercato e altro ancora.

In alcuni casi, può essere utile mettere insieme tutte queste indicazioni e provare a pesarle tramite un meccanismo di media pesata multidimensionale (Scored Balanced Matrix) [2]. In un esperimento che abbiamo fatto di recente con i miei colleghi, abbiamo proposto di usare una matrice che sommasse i vari pesi su cui avevamo precedentemente concordato con il PO (figura 5).

In questo caso abbiamo usato un approccio forse un po’ troppo meccanicistico e semplicistico, ma che è risultato comunque utile per il PO per avere un’idea del valore dei vari item. Anche se i voti sono stati dati in modo piuttosto intuitivo, questo ha permesso di ottenere due risultati: assegnare i punti valore per ogni item del backlog e trovare una posizione relativa di ogni item nel backlog stesso.

Conclusione

In questo breve articolo, quasi una appendice del precedente pubblicato il mese scorso, abbiamo visto alcuni esempi di tecniche o “razionali” con i quali provare ad assegnare un punteggio valore agli item del backlog. Molte altre soluzioni possono essere adottate: qui abbiamo solamente provato a fornire alcune idee.

Ricordiamo che assegnare i punti valore a un item nel backlog corrisponde di fatto a fare una stima del valore che si potrà rilasciare con quell’item. Ma non è una valutazione oggettiva, né è basata sul feedback derivante dall’utilizzo del prodotto da parte dell’utente, tema quest’ultimo che invece abbiamo affrontato approfoditamente nella già citata serie di articoli [1] scritti l’anno scorso con la collega Ilaria Mauric.