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.

Caro Product Owner, di cosa sei realmente owner?

Avete presente la differenza tra un prodotto, una specifica funzionalità ed un componente di prodotto?
Questa distinzione – magari non immediata per tutti – è alla base della classificazione che Roman Pichler adotta per chiarire l’ambito di intervento del Product Owner.
Ancora oggi infatti c’è una certa confusione su questa figura perché si tratta di un ruolo complesso, sfaccettato e che può essere applicato in modo differente a seconda dei contesti organizzativi e della dimensione dell’azienda.

Ma partiamo dalle basi…
Di cosa si occupa il Product Owner?
Il Product Owner è colui che gestisce il prodotto per conto dell’organizzazione.
Avrà quindi due referenti principali: da una parte gli utenti o clienti, dall’altra l’azienda stessa che commercializza il prodotto.
Il prodotto è un mezzo per creare valore.
Qualcosa in grado di risolvere un problema o generare un beneficio per gli utilizzatori e i clienti, ma anche un asset tangibile dell’azienda in grado di generare revenue o stimolare la vendita di altri prodotti/servizi.

Secondo questa definizione è legittimo chiedersi se il Product Owner gestisca uno o più prodotti e se ciò che gestisce sia davvero un prodotto.
L’ambiguità è data dal fatto che spesso le funzionalità e i componenti – che sono parti del prodotto – vengano considerati essi stessi prodotti, pur non essendo in grado di generare valore da soli.

Analizziamo più nel dettaglio questi concetti.
Una funzionalità è un attributo del prodotto con cui l’utente può interagire.
Parliamo ad esempio di una funzione di ricerca e navigazione, del log-in o del check-out per effettuare un acquisto.
Tutti questi sono step dello user journey, non prodotti essi stessi.
Il valore per l’utente è dato dall’esperienza complessiva, non dalla singola funzionalità (avete mai sentito discorsi di questo genere? “Non sono riuscito ad acquistare il prodotto che volevo, ma sono rimasto soddisfatto del semplicissimo processo di registrazione”. Mai visto!).
Colui che gestisce singole funzionalità di prodotto è un Feature Owner.

D’altra parte un componente è un building block del prodotto, un elemento della sua architettura come ad esempio un database management system, un data access layer o la user interface stessa.
Anche in questo caso si tratta di una parte del prodotto (uno strato a ben vedere), non del prodotto nell’accezione di veicolo di valore.
Qui il concetto nella testa dell’utilizzatore finale si fa sempre più labile. Come è organizzato tecnicamente il prodotto non ha alcun importanza per il cliente (“Basta che funzioni!”).
Chi gestisce singoli elementi dell’architettura del prodotto è un Component Owner e di norma ha un background tecnico dato l’ambito specializzato di intervento.

Anche a livello della product ownership vera e propria è possibile fare una distinzione.
Un conto è gestire un prodotto a livello strategico, altra cosa è gestirne l’evoluzione day-by-day.
Pur essendo questi due livelli intercomunicanti, le skill e le competenze richieste sono profondamente diverse.
Pichler parla in questo caso di “Big Product Owner” e “Small Product Owner”.

Il Big Product Owner è responsabile sia della strategia sia della tattica, ma delega l’esecuzione della seconda ad altre figure.
E’ colui che elabora la vision di prodotto e ne definisce gli obiettivi. Deve sapere come il prodotto crea valore, chi sono i clienti, qual è la sua value proposition distintiva e come si differenzia rispetto ai competitor.
Il Big Product Owner definisce la roadmap di prodotto, gestisce gli stakeholders, interagisce con i customer e gli user, produce forecast e tiene traccia delle performance.

Lo Small Product Owner è responsabile di attività di tipo tattico.
Gestisce e prioritizza il backlog, scrive le user stories, si occupa del release planning, partecipa alle cerimonie Scrum e lavora a diretto contatto con il team di sviluppo e lo Scrum master avendo prevalentemente a che fare con i vincoli di prodotto (tempi, costi e ambito).

Ovviamente il tipo di Product Owner adottato in un determinato contesto è in stretta correlazione con l’organizzazione dei team di lavoro e la dimensione dell’azienda.
Se l’azienda adotta component team avremo dei Component Owner, se utilizza feature team potremo avere sia Feature Owner sia Product Owner.
La differenza tra Big e Small Product Owner può dipendere anche dalla dimensione dell’azienda: in start-up, realtà medio-piccole e aziende grandi dove sono stati adottati framework di scaling sono più facilmente presenti Big Product Owner (figure più vicine all’ambito del product management classico); in realtà di medie dimensioni dove sono presenti più prodotti o prodotti maturi la responsabilità è più spesso ripartita tra Small Product Owner, mentre il vero controllo del prodotto è tenuto dal management o da figure dedicate (es. Head of Product, Business Owner, ecc.).

E voi che tipo di Product Owner siete? Avete sperimentato questi diversi livelli di gestione? Avete preferenze a riguardo? Mi piacerebbe confrontarmi con chi ha esperienze di prima mano su questo tema.

Per approfondimenti sull’argomento trovate a questo indirizzo la registrazione del webinar di Roman Pichler sul ruolo del Product Owner che ha ispirato questo post.

Come gestire user stories tecniche

Tre approcci ai requisiti tecnici

Capita a tutti di dover inserire tra le attività del team task di tipo prettamente tecnico.
In questo articolo vi porto l’esempio di 3 modi differenti di gestire questo tipo di richieste.
Innanzi tutto ha senso parlare di user stories tecniche?
Mhhh, dipende…
Se siamo in grado di individuare nella richiesta un soggetto, un oggetto e un beneficio esplicito è utile definirla attraverso il format della user story.
Se non è così e ci si spacca la testa per far rientrare una richiesta in un modello che non le appartiene in alcun modo meglio evitare del tutto. Non l’ha prescritto il medico che tutto ciò che entra nel backlog sia esclusivamente una user story!
Ci può essere molto altro, ad esempio task di bug fixing, attività architetturali, prototipi, spike e via così.

Ha senso tracciare queste attività tecniche?
Assolutamente sì! Il team spende del tempo su questi task così come sull’implementazione di nuove funzionalità ed è importante tenerne traccia per monitorarle e pianificare il modo migliore di gestirle nel tempo.

Come affrontare user stories tecniche

Sprint funzionali e sprint tecnici

Quando nel corso del tempo non c’è stata un’attenzione continuativa alla qualità e al refactoring possono presentarsi casi in cui il codice legacy ha raggiunto livelli decisamente problematici.
In alcuni di questi casi mi è capitato di vedere i team di sviluppo alternare sprint in cui venivano implementate nuove funzionalità e sprint tecnici dedicati soprattutto al refactoring e alla “messa in sicurezza”.
Ad esempio a 3 sprint funzionali seguiva uno sprint tecnico.
Dico subito che non sono una fan di questa soluzione perché per la mia esperienza produce più svantaggi che vantaggi.

Svantaggi
E’ di difficile “digestione” da parte del business che fatica a comprendere uno stop forzato ogni mese e mezzo; è spesso difficile individuare un chiaro obiettivo dello sprint tecnico; il product owner ha difficoltà a misurare il valore di questo tipo di interventi (che peraltro poco si prestano a demo); richiede una maturità di gestione se possibile ancora più elevata da parte del team.
Infine spesso e volentieri questo sforzo non porta comunque un miglioramento effettivo in tempi brevi del codice legacy.

Vantaggi
Il team è fortemente focalizzato sulla risoluzione degli aspetti tecnici, li gestisce in totale autonomia e non subisce interruzioni.

User stories funzionali e tecniche nel medesimo sprint

Questa modalità di gestione è piuttosto frequente.
Il tempo disponibile dello sprint è suddiviso tra sviluppi funzionali e attività di tipo tecnico. Diciamo che il team concorda con il product owner di dedicare ad esempio l’80% del tempo ai primi ed il restante 20% ai secondi.
E’ il classico esempio di “un colpo al cerchio e uno alla botte”…

Svantaggi
Il team fa contest switching all’interno dello sprint (si tratta spesso di attività a sé stanti rispetto al resto); è difficile individuare un unico sprint goal.
Richiede comunque tempi lunghi per vedere effettivi benefici a livello di legacy.

Vantaggi
E’ un compromesso più che accettabile per il business perché non richiede periodicamente uno stop delle attività; questa modalità di gestione può essere adottata in ogni sprint; al termine di ogni iterazione consente di avere workable software da mostrare durante le demo.

Aspetti funzionali e tecnici nella medesima user story

Questa è un’altra possibilità e devo dire che tra tutte è quella dalla quale sento di aver tratto maggior beneficio.
In sostanza in ogni storia il team stima una quota parte di refactoring del codice e/o dei test. Questo si traduce in prima battuta in user stories che vengono valutate con un peso maggiore (e quindi in una diminuzione iniziale della velocity del team), ma in un tempo relativamente breve la situazione torna alla normalità e – addirittura – a migliorare.
E’ importante notare che richiede grande maturità tecnica ai membri del team e la capacità di fare solo ciò che è opportuno e nulla di più (no virtuosismi se non sono necessari).

Svantaggi
Il refactoring viene effettuato sulle sole storie funzionali lavorate nel corso dello sprint; iniziale diminuzione della velocity.

Vantaggi
Non ha effetti collaterali sugli stakeholder; questa modalità di gestione può essere adottata continuativamente; aumenta da subito la qualità del software e l’attenzione del team a questo aspetto; nel tempo porta grande confidenza ai dev sulle parti che hanno toccato e maggiore velocità di sviluppo.

E voi quale tipo di approccio adottate?
Quale ritenete più utile per il vostro caso? Avete esplorato altre possibilità?
Ci sono casi in cui per risolvere problemi di legacy avete dovuto adottare approcci più radicali?
Sono curiosa di sentire le vostre esperienze…