Tecniche di prioritizzazione: 5 spunti per iniziare

prioritizzazione

Recentemente ho visto girare in rete un articolo molto interessante che presentava le tecniche di prioritizzazione attraverso la metafora della tavola periodica degli elementi (a cura di Folding Burritos).

Le 20 tecniche proposte venivano classificate in base a due criteri principali:
– quantitativo vs. qualitativo
– interno vs. esterno

Alcune di queste – come il Kano model, il MoSCoW, lo story mapping e l’opportunity scoring – le conoscevo bene, altre di nome ma non di fatto (ad esempio le tecniche di analisi finanziaria che non ho mai avuto modo di sperimentare in prima persona), altre ancora erano una novità assoluta.

Nell’articolo trovate un link per scaricare – previa registrazione – un ebook in cui le 20 metodologie sono analizzate in dettaglio (ne vale la pena!).
Da questa lettura ho ricavato qualche consiglio su come approcciarsi alle varie tecniche di prioritizzazione, che riporto qui sotto.

1. Non esiste uno strumento infallibile per definire le priorità

Prima di iniziare una doverosa premessa: tutti i metodi sono validi ma nessuno è un oracolo. Pensiamo ad esempio ai metodi quantitativi e qualitativi.

Le persone tendono ad associare i metodi quantitativi ai numeri, quindi alla precisione e alla confidenza nella stima, ma non esistono strumenti infallibili!
E’ vero che le tecniche quantitative si basano su metriche, classificazioni, voti o ranking, ma si fondano pur sempre su assunzioni ed ipotesi che devono essere validate nella realtà.

Allo stesso modo le metodologie qualitative non sono da ritenersi “inaffidabili” in quanto non oggettive. Sono per loro natura più esplorative che confermatorie e possono offrire molto velocemente insight importanti.

2. Qual è il criterio migliore in assoluto? Dipende dal contesto…

Abbiamo capito che non esiste la bacchetta magica quando si parla di tecniche di prioritizzazione, ma la buona notizia è che abbiamo tante frecce al nostro arco.
Le metodologie sono diverse ed è opportuno verificare l’ambito al quale devono essere applicate e le condizioni di contorno.

Come sceglierle? Applichiamo il buonsenso e cerchiamo di capire quale strumento può essere più utile – o più accessibile – in relazione al nostro prodotto, al suo ciclo di vita, al team di lavoro e all’azienda.

Torniamo alla distinzione precedente: le metodologie qualitative possono essere più utili nel momento in cui il prodotto è ancora ad una fase iniziale, quando l’esigenza più importante è raccogliere feedback dal mercato e costruire un modello dei propri utenti. In questo caso sceglieremo tecniche che ci consentano di raccogliere un ampio ventaglio di informazioni e di esplorare i bisogni più in profondità.

Le metodologie quantitative sono più adatte ad un prodotto in una fase più matura quando è richiesto un minimo di base dati da cui partire. Consentono di verificare le ipotesi di partenza e garantiscono maggiore oggettività delle analisi.
Le tecniche orientate verso l’esterno esplorano meglio obiettivi e funzionalità di alto livello; quelle interne funzionano meglio per problemi concreti.

3. Parti ad alto livello e non perderti nei dettagli

Tutte le tecniche proposte funzionano bene quando si tratta di dare priorità ad epiche, temi ed obiettivi dell’utente; a più basso livello tendono a perdere di efficacia e di significato.

L’obiettivo è di arrivare a definire cosa ha valore per l’utente e cosa non ne ha, non decidere se un criterio di ordinamento per rilevanza è più o meno importante di quello per prezzo.
Il mio consiglio è di partire a prioritizzare le macro-funzionalità tenendo ben presente la visione strategica di prodotto e confrontandosi – se possibile – con gli utenti.
Alcune delle tecniche proposte – ad esempio lo story mapping, il MoSCoW, il Kano model o Buy a feature – si prestano perfettamente a questo scopo.

Una volta definite le priorità ad alto livello si può pensare di approfondire i dettagli principali di un tema attraverso altri strumenti quali Opportunity scoring, Score card, Theme screening e Valore vs. Costo/Rischio.
Esplorate le possibili declinazioni di un tema, ma tenetevi a distanza dalle minuzie.

4. Prioritizzare è un lavoro di gruppo

Il confronto è particolarmente importante in quest’ambito. Senza di esso potremmo avere un punto di vista totalmente falsato.
E’ opportuno che la prioritizzazione non sia lo sforzo di una singola persona.

Ci sono alcuni metodi estremamente semplici che potreste portare avanti da soli, ma è sempre meglio fare questo lavoro con persone che abbiano punti di vista differenti sul prodotto, siano essi clienti, utenti, stakeholders o membri del team di sviluppo.
Fate lo sforzo di mettere in discussione le vostre convinzioni e ascoltate cosa emerge dal confronto. Oltre ad avere una visione più chiara di quali siano le reali priorità questa opportunità potrebbe farvi scoprire prospettive nuove ed interessanti che non avete considerato.

5. Mix and match!

Gli strumenti sono tanti, ognuno di essi ha vantaggi e svantaggi quindi non limitatevi ad un’unica tecnica di prioritizzazione.
Sperimentatene diverse, provate a combinarle tra loro, mettetele a confronto sul medesimo set di funzionalità. Col tempo scoprirete quali vi sono più congeniali e quali sono più efficaci in un determinato contesto.

E dopo? Per ogni priorità definite degli obiettivi misurabili

Una volta che siete riusciti a definire ad alto e medio livello quali sono le priorità che porteranno maggior valore ai vostri utenti, non dimenticate di mettere alla prova questi risultati mano a mano che lo sviluppo rilascerà le funzionalità secondo l’ordine concordato.

Stiamo perseguendo lo scopo di creare valore, quindi dovremmo essere in grado di definire un cambiamento misurabile nel comportamento dei nostri utenti.
Verifichiamo l’effetto delle nostre scelte analizzandone l’impatto, il ROI, i comportamenti di utilizzo e qualsiasi kpi di business faccia al caso vostro (sul tema impatto e come misurarlo abbiamo discusso a lungo in questi post).

La finalità non è la prioritizzazione in sé, ma arrivare ad essere sempre consapevoli se ciò che facciamo sta effettivamente portando valore agli utilizzatori finali. Se scoprissimo che non è così avremo indicazioni su ciò che va ripensato.

Business Model Canvas per modellare progetti e organizzazioni

Cos’è e a cosa serve

Che cos’è un canvas?  Letteralmente è una tela, un canovaccio, un template potremmo dire per rendere l’idea.
Il business model canvas è uno schema che consente sia di mostrare il funzionamento di organizzazioni esistenti sia di progettare nuovi modelli di business da zero.
Il business model canvas descrive come un’azienda crea, produce e acquisisce valore.
Il suo valore intrinseco sta nel fatto di essere uno strumento visuale, semplice, sintetico e duttile che si rivela un mezzo molto efficace di condivisione e comunicazione delle idee.
Dimenticate quindi le presentazioni power point, i documenti di requisiti e le risme di allegati; basta uno schema su un foglio A4 per promuovere il vostro prossimo progetto.

Business Model Canvas

Business Model Canvas: il concetto di valore

Prima di iniziare ad utilizzare il canvas e tutte le sue potenzialità è necessario dedicare del tempo a queste domande:

  • Chi è il nostro cliente? O chi sono i nostri clienti
  • Di cosa ha necessità? Qual è il risultato che ha bisogno di ottenere?

Le risposte a queste domande sono le fondamenta del nostro modello di business, quindi non abbiate fretta e dedicate tutto il tempo che vi serve per sviscerare gli aspetti da tenere in considerazione.

Un concetto-chiave che sta alla base del business model è infatti la necessità di definire il valore dal punto di vista del cliente, non con gli occhi dell’azienda che eroga il prodotto/servizio.

Business Model Canvas: i 9 blocchi

Una volta individuato il nostro cliente-tipo o i nostri clienti-tipo ed i relativi bisogni siamo pronti per approfondire i 9 blocchi costitutivi dello schema, ovvero:

Clienti

Sono la ragion d’essere stessa dell’organizzazione e possono corrispondere ad uno o più profili.

Valore offerto

Il valore che il cliente percepisce nello scegliere un’azienda piuttosto che un’altra (ad es.: comodità, prezzo, design, brand/status, minori costi, minori rischi, personalizzazione, performance, accessibilità, usabilità, ecc.).

Canali

I canali di comunicazione, distribuzione e canali di vendita sono il punto di contatto principale con i clienti.

Relazioni con i clienti

Possono essere di vario tipo (e convivere tra loro): personali, automatizzate, self-service, mediante community o di co-creazione con l’utente finale.

Ricavi

Derivano600 da vendita di beni, affitto/noleggio, canoni di servizio o di abbonamento, licenze, diritti di intermediazione o advertising.

Risorse chiave

Distinte in risorse umane, materiali, intellettuali e finanziarie.

Attività chiave

Ovvero ciò che l’azienda deve fare per far funzionare il proprio business; attività di produzione, vendita, consulenza/soluzione di problemi, supporto, ecc.

Partner chiave

Soggetti terzi che permettono di rendere efficace un business model (attraverso economie di scala, risparmio costi, ecc.).

Costi

Tutte le voci di spesa necessarie per portare avanti l’attività.

Business Model: come utilizzarlo

Uno degli aspetti più interessanti del canvas è come dicevo la sua duttilità. Si può utilizzare in situazioni disparate.
Vi faccio qualche esempio:

  • descrivere il funzionamento della propria azienda, di organizzazioni esistenti, competitor, ecc.
  • studiare modelli di business alternativi
  • progettare un nuovo prodotto/servizio
  • riprogettare il proprio modello di business
  • introdurre dei cambiamenti nell’organizzazione esistente

Il successo di questo strumento ha fatto sì che il suo impiego si sia esteso anche in ambiti non strettamente business.
Lo stesso creatore del canvas – Alex Osterwalder – racconta in “Business Model You” come utilizzare questo semplice schema per cambiare lavoro o cambiare vita.

Come il canvas può essere utile al Product Owner

Anche in un caso così specifico gli impieghi possono essere svariati.
Vi do giusto qualche spunto a riguardo.
Dal mio punto di vista è un ottimo strumento di comunicazione con il management.
E’ sintetico, veloce, permette di farsi un’idea a colpo d’occhio dei punti di forza di un prodotto/servizio e può essere agevolmente modificato per esplorare alternative.

Ma la sua forza non è limitata ad essere un semplice strumento di condivisione aziendale, può essere impiegato con successo anche nella gestione delle aspettative degli stakeholder di progetto.

Nei confronti del team di sviluppo è uno strumento utilissimo di allineamento perché consente di esplorare gli obiettivi e l’ambito di progetto, favorisce la comprensione della big picture, ma allo stesso tempo invita alla discussione, all’esercizio critico e alla condivisione di idee innovative.

E’ difficile trasmettere in un post quali benefici possa portare il canvas.
Si corre il rischio di sembrare un po’ invasati (tool-addicted)… ma posso dire che vale la pena fare qualche tentativo in prima persona per sperimentarne i vantaggi.
Per iniziare potete sempre ispirarvi ai tanti esempi disponibili in rete.

Non solo user stories nel product backlog

Il backlog racconta il nostro prodotto da diverse prospettive.
Sappiamo che finché esiste il prodotto esiste un backlog e che questo è principalmente costituito da user stories, ma non tutto ciò che è contenuto nel backlog deve necessariamente essere una storia.
Lo scopo di questo artefatto è condividere cos’è il prodotto che stiamo realizzando con chi lo deve implementare, validare, utilizzare e – in generale – con tutti coloro che ne sono interessati.
In quest’ottica le user stories potrebbero non essere esaustive.

Come descrivo un’interazione complessa? E l’esperienza utente? Dove condivido i dettagli delle interfacce? Come posso dettagliare gli aspetti di performance e scalabilità del software?
Le user stories a volte non bastano. In generale tutto ciò che può aiutare ad aumentare la comprensione del prodotto e a descriverne l’utilizzo da parte dell’utente finale è un elemento utile.

Nella mia esperienza un buon backlog finisce per contenere tutti questi elementi:
user stories
interazioni
visual design
requisiti non funzionali

Non mi soffermo sulle user stories, di cui abbiamo già parlato a lungo, e che hanno lo scopo di descrivere le funzionalità del prodotto.

Interazioni

A volte le funzionalità che vogliamo realizzare comportano un’interazione complessa.
Sono i casi in cui l’utente deve ad esempio compiere più step per portare a termine un’operazione o casi in cui una singola azione provoca più effetti in diversi punti del sistema.
Pensiamo alle esperienze di acquisto, alle registrazioni mediante social, alla gestione delle proprie mail nella casella di posta.
In questo caso oltre alle user stories sulle singole funzionalità è necessario dettagliare il percorso che dovrà seguire l’utente.
A questo scopo ci vengono in aiuto i diagrammi di flusso, gli scenari e le storyboard.
Mediante questi strumenti possiamo descrivere visivamente i singoli passaggi attraverso cui transita l’utente, verificare di non avere omesso degli step fondamentali e calarci nel suo percorso per verificarne la logica ancora prima di aver dettagliato l’interfaccia.
Con l’interaction design rispondiamo alle domande: come si muoverà l’utente? che cosa potrà fare nel nostro servizio?

Visual Design

Il design è un componente essenziale del successo di un prodotto ed un aspetto sempre più rilevante nei criteri di scelta da parte dell’utente finale.
Nel mondo digitale ci sono aziende di successo che hanno fatto di questa caratteristica il proprio elemento distintivo (pensate a Apple!).
Per comunicare questo tipo di caratteristiche possiamo utilizzare svariati tool: mock-up, sketch e wireframes che emulano la navigazione e le principali interazioni dell’utente finale.
Il ventaglio delle possibilità è ampio, si va dal semplicissimo disegno dell’interfaccia a matita su un foglio di carta al .psd dell’art director definito al pixel (anche se questo livello di dettaglio è eccessivo e controproducente).
Con il visual design rispondiamo alla domanda: cosa vedrà l’utente in ogni singolo step?

Requisiti non funzionali

Definiscono le proprietà e i vincoli di un sistema.
Sono gli aspetti che riguardano – ad esempio – l’usabilità, la scalabilità, le performance di un prodotto, i tempi di risposta.
Sono spesso elementi essenziali per la soddisfazione degli utenti, a volte poco tangibili ma trasversali all’intero servizio e critici per il suo corretto funzionamento.
Sono di solito problemi non indirizzati a livello di MVP (minimum viabile product)  ed anche i primi aspetti che “saltano” quando il time to market è fondamentale nella strategia di prodotto.
Pur essendo così bistrattati sono tuttavia quelle caratteristiche che rendono solido e flessibile un prodotto nel tempo.
Ecco perché prima o poi vi ritroverete a fare i conti con i requisiti non funzionali.
Possono richiedere tempi di implementazione più lunghi rispetto alle funzionalità del servizio ed è opportuno definirli il prima possibile nel corso dello sviluppo in modo tale compiere scelte tecniche e di prodotto in linea con i vincoli che caratterizzeranno il sistema.
Solitamente i requisiti non funzionali non vengono espressi mediante la formula classica delle storie (attore, funzionalità, beneficio), bensì mediante enunciati.
Qualche esempio:
– l’acquisto dei prodotti mediante carrello deve essere disponibile anche  su browser Opera
– il caricamento della pagina di risultati di ricerca deve essere inferiore a 1,5 secondi
– l’area personale deve essere consultabile in mobilità da device Android vers. 4 e superiori
Con i requisiti non funzionali rispondiamo alla domanda: di quali vincoli deve tenere conto lo sviluppo del nostro prodotto?

In sintesi il mio consiglio è questo: non forzate all’interno di user stories qualsiasi tipo di dettaglio di prodotto.
Se avete difficoltà a descrivere una caratteristica mediante la formula who/what/why provate a chiedervi se non avete forse a che fare con requisiti non funzionali, interazioni o aspetti di visual design.
Tutti questi sono elementi determinanti della user experience finale e hanno la dignità di trovare posto nel product backlog.
Più in generale non esitate ad avvalervi di qualsiasi strumento possa generare maggiore chiarezza.
Sperimentate e divertitevi a farlo!