Categoria: Product Management

Pubblicato il

Dalla vision al Backlog con la Vision Board

Come si procede dalla vision iniziale alla formulazione delle singole user stories?
Quali sono i passi da seguire?

Venerdì 14 marzo si è tenuto al Politecnico di Milano una conferenza dal titolo “Agile for Innovation” aperta da uno speech di Roman Pichler sulla strategia agile di prodotto.

Il primo consiglio di Pichler è di non saltare subito all’esecuzione, bensì dedicare tempo alla formulazione di una strategia, a definire il percorso verso gli obiettivi prefissati.
Abbiamo una vision, una “big picture”, un’idea sfidante che è la nostra meta.
A questo punto è importante rispondere ad alcune domande fondamentali per elaborare la strategia: chi, perché, cosa, qual è il risultato atteso?

Proviamo a chiederci:

Chi sono gli utenti?
Ma anche chi sono i clienti, ovvero coloro che pagheranno per il nostro prodotto (non è detto che chi paga coincida sempre con l’utilizzatore finale…).

Per quale motivo potrebbero essere interessati ad usare il  prodotto? 

Perché dovrebbero comprarlo?

Che cosa rende unico il prodotto? 

Esploriamo la value proposition….
Quali sono le sue caratteristiche chiave?
E’ importante rimanere ad alto livello in questa fase; definiamo 3 key features, massimo 5.

Quali sono gli obiettivi di business? 

Per quale motivo dovremmo investire in questo progetto i nostri soldi invece che in altro?

Per guidarci nella risposta a questi quesiti Pichler ha elaborato un tool semplice e potente che può essere applicato in svariati ambiti:
la Vision Board.

E’ un foglio A4 che contiene una tabella divisa in 5 aree:
– la vision
– il target
– i bisogni che il prodotto soddisfa
– le caratteristiche chiave del prodotto
– gli obiettivi di business

Una volta che la strategia è delineata siamo pronti a partire?
Non ancora!
La vision board traduce l’idea iniziale in una strategia, ma prima di arrivare al backlog e alle singole user stories è opportuno prevedere una fase di test.
La strategia contiene indubbiamente delle ipotesi.
Fate un esame di quali sono le principali assunzioni che avete fatto ed elencate i possibili rischi. Metteteli in ordine di priorità (per esempio in base alla gravità dell’effetto che possono produrre) e procedete con interviste ad utenti e clienti.

Il vero lavoro è questo: non implementare il prodotto, ma testarne il prima possibile le idee e le assunzioni (un punto di vista molto simile a quello di Eric Ries…).
In questo modo la strategia non è scolpita per sempre nella pietra, ma emerge e si arricchisce in base ai feedback degli utenti.

… e se proprio doveste accorgervi di essere fuori strada, potete sempre cambiare rotta o abortire del tutto il progetto con perdite assai contenute (comunque ben prima della fase più costosa, lo sviluppo!)

Pubblicato il

Un’idea di valore condivisa

Uno degli obiettivi primari del Product Owner è creare valore per l’utente finale e, allo stesso tempo, per la propria azienda.
Lo scopo del nostro lavoro è realizzare prodotti che rispondano ai reali bisogni degli utenti, renderli soddisfatti così da garantire all’azienda uno sviluppo sostenibile ed il raggiungimento degli obiettivi di business. Tuttavia il termine “valore” può essere interpretato in molti modi o, peggio, può non essere affatto chiaro a cosa corrisponda.

Valore per chi

Si parla tanto di valore, ma pochi si prendono il tempo di riflettere su cosa realmente sia.
Cominciamo a chiederci qual è il punto di vista che intendiamo assumere.
Il “valore” potrebbe avere un significato differente per il cliente finale, l’azienda per la quale lavoriamo, eventuali finanziatori o, ad esempio, i business partner.
Identifichiamo quali sono gli attori in campo – i cosiddetti stakeholders – e cerchiamo di definire cos’è valore per ognuno di essi. In molti casi la definizione potrebbe collimare, in altri potremmo trovarci di fronte a delle sorprese.

Valore = soldi?

La risposta può sembrare scontata, anzi spesso e volentieri lo è.
Ma stiamo davvero esaurendo l’argomento valore con l’aumento dei ricavi e la riduzione dei costi?
Vi invito a prendere il tempo che serve per analizzare più a fondo la questione.
Prendiamo il caso di un’azienda. Dobbiamo sforzarci di contestualizzare il significato di valore in riferimento al tipo di business, allo scenario di mercato, al contesto competitivo, alla maturità del settore, ecc.

Valori diversi

Facciamo qualche esempio…
Un’azienda no profit potrebbe considerare “valore” il fatto di produrre un impatto sociale positivo in un determinato ambito.
Una startup con buoni capitali alle spalle potrebbe concentrare i propri sforzi nella soddisfazione dei propri utenti chiudendo inizialmente un occhio sui ricavi.
Per un ente di ricerca il valore più rilevante è l’acquisizione di conoscenza in nuovi domini.
Ciò che intendo dire è che il guadagno potrebbe non essere l’unica dimensione rilevante anche in un contesto privato.

Valore: un significato condiviso

E’ importante che all’interno dell’azienda ci sia un’idea chiara di cosa è valore per l’azienda stessa e per il cliente finale.
Se è presente una vision può essere un ottimo punto di partenza per declinare l’idea di valore o le idee di valore.
Quando costruiamo un significato condiviso creiamo allineamento di intenti, facciamo sì che le persone abbiano piena consapevolezza degli obiettivi e possano prendere in autonomia decisioni coerenti con i criteri di valore.

Valore nel tempo

Una volta identificato cos’è il valore non sediamoci sugli allori!
Ciò che consideriamo oggi un valore primario potrebbe non avere la medesima importanza in futuro.
In fase di crescita potremmo considerare valore l’acquisizione di conoscenza sul mercato e sui potenziali utenti, la riduzione del rischio d’ingresso da parte di potenziali competitor o l’aumento della customer base.
In una fase più matura l’azienda focalizza di norma i propri sforzi sulla monetizzazione… e quindi da più peso alla dimensione economica del valore.

E voi?
Cos’è per voi valore?

Pubblicato il

Come pianificare una release a partire dalla velocity

Pianificare una release di prodotto

“Quando rilasciamo?” Ecco la domanda con la quale convivono da sempre i Project Manager e la stragrande maggioranza dei Product Manager.
Anche lavorando in Scrum questa è domanda ricorrente per i Product Owner. 

I progetti inseriti in roadmap hanno un orizzonte temporale che può variare dai 3 ai 6 mesi e necessitano di una pianificazione accurata.
Diciamo allora che è necessario pianificare a livello di release per avere una stima della data di rilascio.

Per fare questo dovremo innanzi tutto stimare la dimensione del progetto da portare a termine (il size di tutte le user stories) e poi fare riferimento alla velocity del team.
Un’altra raccomandazione utile è esprimere la data di rilascio mediante un range di date (dopotutto si tratta di una stima, non di un calcolo matematico!).

Le situazioni che si possono presentare pianificando una release possono essere variegate, a seconda del tipo di mercato in cui è attiva l’azienda, il tipo di contratti utilizzati e l’organizzazione interna delle risorse.
Vediamo alcuni dei casi più frequenti.

Progetto interno, senza vincoli forti su date

Diciamo che il team ha già lavorato su altri progetti.
E’ questo il caso più semplice per effettuare delle stime.
Se il team è già struttuato e lavora su un domino noto con tecnologie conosciute abbiamo confidenza nel fatto che la velocity pregressa sia un buon indicatore del comportamento futuro.

Prendiamo le velocity degli ultimi 6 sprint (o più se sono disponibili ulteriori dati), eliminiamo il valore massimo ed il minimo e facciamo una media delle restanti velocity. Questo è il riferimento per la nostra stima.
Ricordate l’idea di esprimere la stima in un range? Teniamo conto del valore più alto e più basso che rimangono dopo la sottrazione iniziale.

Esempio: 

  •  il team negli ultimi 8 sprint ha avuto la seguente velocity:
    20 + 25 + 31 + 29 + 18 + 34 + 30 + 38
  • eliminiamo i valori 20 e 38 (il più basso ed il più alto)
  • prendiamo 34 come valore superiore e 25 come valore inferiore
  • se il backlog vale 150 story point in totale il progetto sarà terminato in un periodo che varia da 4,4 sprint (nel migliore dei casi) a 6 (nel peggiore).

Per molti un intervallo così ampio non è un’informazione utile… né comunicabile agli stakeholder.
In questo caso vi suggerisco di usare il buon senso.
Comunicare una durata di 4 sprint e mezzo significa  non lasciare respiro al team e non prevedere alcun intoppo o contingenza (ferie, malattia, formazione, ecc.). Sei sprint potrebbero tuttavia risultare poco “digeribili” dai committenti.
Se mi trovassi in una situazione di questo tipo punterei su 5 sprint sapendo sin dall’inizio che alcune funzionalità potrebbero essere oggetto di descoping.

Progetto con data di rilascio fissa

In questo caso il vincolo è dato dal timing, quindi sarà lo scope di progetto a rappresentare la variabile.
Il team parte col chiedersi: “Quante iterazioni abbiamo da qui al rilascio?”

Esempio: 

  • la data ultima di rilascio è fissata per il 1° giugno (oggi è il 15 marzo)
  • il team lavora con sprint di 2 settimane
  • le velocity nelle iterazioni precedenti sono: 20 + 25 + 31 + 29 + 18 + 34 + 30 + 38
  • eliminiamo – come prima – i valori 20 e 38 (il più basso ed il più alto)
  • prendiamo 34 come valore superiore e 25 come valore inferiore
  • se il backlog di progetto vale complessivamente 150 story point per la data del primo giugno (5 sprint) saranno completati da un minimo di 125 ad un massimo di 170 story points.

Abbiamo quindi una buona confidenza che il progetto completo di tutte le sue funzionalità possa essere terminato per la data prevista.
O, per la precisione, garantiamo che 125 story points saranno completati per la data concordata e che i restanti 25 hanno buona probabilità di esserlo.
… ma attenzione! Potrebbero presentarsi casi in cui il calcolo evidenzi sin dall’inizio l’impossibilità di terminare per la data concordata.

Progetto con ambito fisso

Abbiamo un “capitolato” vincolante, è quindi la variabile tempo che può cambiare. Il team si chiede “Quanto tempo ci mettiamo a completare tutto?”

Esempio:

  • dobbiamo necessariamente realizzare un progetto di 150 story points
  • le velocity precedenti: 20 + 25 + 31 + 29 + 18 + 34 + 30 + 38
  • eliminiamo i soliti valori 20 e 38
  • prendiamo 34 come riferimento superiore e 25 come inferiore
  • il progetto sarà terminato in un periodo che varia da 4,4 sprint (nel migliore dei casi) a 6 (nel peggiore).

In questo caso dato che lo scope è fisso per contratto comunicheremo che il progetto terminerà al più tardi in 12 settimane (6 iterazioni), ma prevediamo che possa anche essere chiuso prima (ad esempio nel corso dell’undicesima o della decima settimana).

Per chi fosse interessato ad approfondire il tema della pianificazione delle release sul sito di Mike Cohn sono disponibili diversi video sull’argomento.

Proudly powered by WordPress