Introduzione
Nella serie di articoli dedicata alla Product Ownership [1] abbiamo più volte sottolineato come il lavoro di Product Owner non debba limitarsi al mero controllo di tempi e costi e al compito di far terminare il progetto secondo i vincoli imposti.
Il Product Owner deve gestire il contenuto del backlog e il suo ordinamento in modo da massimizzare il valore rilasciato all’utente. In Agile il valore si misura in termini di soddisfazione utente: si introduce quindi una tematica importante che affronteremo in questa nuova serie di articoli.
Come si misura la soddisfazione utente? Come si misura il valore prodotto? In che modo il Product Owner può convalidare le sue ipotesi in tema di strategia di prodotto? Come può capire se per ogni storia che esce dal backlog quella che entra aumenta la qualità del prodotto ossia la soddisfazione utente?
Per valutare un prodotto occorre sapere… cosa è un prodotto
Un prodotto è una qualsiasi cosa in grado di soddisfare un bisogno, una necessità di un utente apportando un beneficio, un cambio di comportamento (change behaviour). Può essere quindi un oggetto fisico — un libro, una penna, un computer — ma anche qualcosa di immateriale e astratto, come un servizio, un’applicazione, una consulenza o un corso.
Un prodotto deve fornire un beneficio a un utente durante tutto il suo ciclo di vita, concetto che abbiamo già introdotto in passato [1]. Il ciclo di vita di un prodotto è un argomento strettamente collegato a quello di qualità del prodotto stesso e quindi di soddisfazione utente. Per capire il nesso potremmo porci una semplice domanda: quando un prodotto è finito? Quando lo abbiamo concepito? Quando lo abbiamo realizzato? Oppure quanto lo avremo venduto?
Thinkers vs. doers
Se prendiamo in esame il lavoro di un classico artigiano, osserviamo che egli probabilmente pensa, progetta ma anche realizza fisicamente il prodotto. Ma è anche probabile che lo segua durante il suo ciclo di vita facendolo evolvere, stando vicino ai suoi clienti, proponendo loro una nuova versione se pensa che la vecchia non sia più adatta o che risulti meno performante.
Notare che nel modernissimo mondo di piccole aziende innovative e startup velocissime, i team full stack, crossfunzionali, autonomi hanno un’impostazione molto simile a quella di un agricoltore dell’800 o di un artigiano in epoca preindustriale.
La figura 2 ci aiuta a spiegare in che modo “chi pensa” (thinkers) e “chi realizza” (doers) il prodotto sia più o meno vicino, fino a confluire nello stesso individuo. Questa immagine — comunemente definita Taylor’s bathtub per la forma “a vasca da bagno” della curva in corrispondenza dell’affermazione dell’industria di stampo taylorista (o fordista, come più comunemente diciamo) nel secolo scorso — mostra in che tipo di situazione produttiva e di mercato le due “categorie” dei “pensatori” e dei “fabbricatori” di prodotto siano strettamente collegate e unite o, al contrario, separate e distanti.
Artigianato vs. produzione di massa
Per un artigiano, così come per una piccola startup, “fare” un prodotto significa seguirlo in tutte le fasi del progetto. Considerare finito il prodotto quando esce dalla fabbrica rischia di far perdere di vista alcuni aspetti importanti: dopo che il prodotto è stato rilasciato, il cliente lo usa? Gli è utile? Con quale grado di soddisfazione? E dopo sei mesi, quante persone lo usano? Quali sono le lamentele principali? Quali funzionalità vengono usate meno? Quali sono quelle più utili? E poi, come funziona il prodotto, o meglio quali sono le performance medie per esempio per svolgere un determinato compito? Oltre a questo, stiamo osservando cosa succede al nostro prodotto quando arrivano altri concorrenti sul mercato? Infine come gestiremo il momento del ritiro dal mercato?
Ecco, pur con alcune ovvie differenze, anche in quest’epoca di mercati globali e prodotti ipertecnologici, “fare” un prodotto significa seguirlo in tutte le fasi del suo ciclo di vita, come ai tempi dell’artigianato preindustriale.
Per la definizione di una corretta strategia di gestione del prodotto, è molto importante considerare alcuni aspetti legati alla sua evoluzione. Nel corso degli anni sono stati definiti alcuni modelli pensati appositamente per questo scopo. Uno dei primi e più famosi fu il cosiddetto Product Life Cycle Model, definito verso la fine degli anni Sessanta da Levitt [2] e Cunningham [3] ma poi riportato nel mondo del marketing e del product management [4]. Abbiamo parlato di questo argomento in un articolo pubblicato qualche mese fa su MokaByte in [1].
Valore e ciclo di vita del prodotto
Il concetto di ciclo di vita del prodotto ci ha aiutato a mettere ordine e trovare un fil rouge con cui ordinare i molti aspetti che saltano fuori quando si parla di valore.
Abbiamo pensato quindi di tradurre questo filo logico in una serie di articoli e contenuti che vorremmo pubblicare affrontando il tema della valutazione del valore secondo un percorso che parta da aspetti più semplici e di superficie per proseguire con approfondimenti successivi.
La linea che abbiamo ipotizzato potrebbe essere quella riportata di seguito.
Valutazioni interne/indirette
Sono metriche che forniscono un’indicazione che è un mix fra la performance dell’organizzazione che sta gestendo il prodotto e la qualità interna del prodotto:
- Time to market: quanto tempo impieghiamo per mettere in linea un nuovo prodotto o una nuova funzionalità? È ovviamente una misura delle performance interne dell’organizzazione, più che della qualità del prodotto.
- Time to fix: quanto tempo impieghiamo per risolvere un problema? Una segnalazione?
Parleremo più dettagliatamente di questi aspetti in seguio. Per adesso possiamo assumere che si tratta di indicatori legati indirettamente alla soddisfazione dell’utente. Sono facili da misurare anche se appunto sono misure indirette.
Valutazioni esterne/dirette
Se vogliamo mettere il naso fuori dall’ufficio e capire concretamente cosa il cliente pensi realmente del nostro prodotto e dei servizi annessi, dobbiamo coinvolgere l’utente, interrogandolo, chiedendogli di contribuire al miglioramento del prodotto stesso. Ecco alcuni strumenti e tecniche che si possono utilizzare:
- Survey e NPS: cominciamo con qualcosa di semplice e chiediamo agli utenti cosa ne pensano. Questa è probabilmente la cosa più facile che si possa fare, ma spesso i risultati non forniscono informazioni utili. Con particolare riferimento a NPS (Net Promoter Score, “Quanto consiglieresti il prodotto?”) nutriamo un certo scetticismo riguardo alla sua utilità e al senso generale dell’indagine, ma ne parleremo dettagliatamente nei prossimi numeri.
- Metriche sulla usabilità: introduciamo la misurazione dell’esperienza utente. Avere informazioni sulle performance per inserire un bonifico o cambiare una password è un buon modo per iniziare a stilare un piano di miglioramento del prodotto introducendo un pizzico di oggettività. Se è vero che i dati sono importanti per decidere come migliorare il prodotto, occorre fare attenzione al fatto che i dati possono risultare “tossici” per prendere una decisione: che cosa misuriamo? Come interpretiamo tutti quei numeri? In che modo il Product Owner poi li traduce in modifiche al backlog?
- User Experience: se, da un lato, l’usabilità è facilmente misurabile e anche piuttosto semplice da sistemare, l’esperienza utente invece è un tutta un’altra storia. La UX di un prodotto è molto soggettiva, è un campo in cui entrano in gioco aspetti emotivi, valoriali, di marketing… Per misurarla serve innanzitutto una strategia precisa, che spesso non c’è; e poi servono valutazioni combinate con la brand reputation, il marketing e la comunicazione, non solo ferme sulla UX tout-court. Continuiamo a sentire aziende vacillare alle domande “Chi sono i tuoi utenti? A chi è rivolto questo prodotto o servizio? Che valori vuoi comunicare? Che cosa deve fare e che cosa non deve fare? Come stabilisci se sta avendo successo?”.
- Customer Experience e AI: l’ultima frontiera della product ownership in tema di soddisfazione utente è rappresentata dall’intelligenza artificiale. Ma può una “macchina” estrapolare in modo più efficace quello che l’utente pensa del nostro prodotto?
Vediamo adesso di entrare nel dettaglio dei differenti approcci. Iniziamo questo mese con alcune considerazioni sulle metriche interne, per passare nei mesi successivi alle altre appena elencate.
Valutazioni interne/indirette
Già in passato sulle colonne di MokaByte abbiamo avuto modo di parlare dettagliatamente del tema delle performance della fabbrica del software [6]: quanto tempo impiega il team a completare la lavorazione di un task? Quanto è complesso il prodotto oppure è difficile risolvere un problema? Quanto tempo deve attendere il cliente per vedere risolto il suo problema?
Non è questo il luogo per ripetere nuovamente tutti i concetti già ampiamente descritti in quegli articoli; vorremmo qui solo ripercorrere alcuni passaggi, per capire come alcune metriche interne del team di sviluppo possano fornire indicazioni (indirette) sullo stato di salute del prodotto.
Partiamo con un po’ di definizioni preliminari: parliamo di Lead Time (vs. Cycle Time), di Cumulative Flow Diagram, e di cosa c’entrano con il valore del prodotto. Per chi fosse interessato ad approfondire questi argomenti consigliamo l’ottima serie sulle metriche Kanban scritta a suo tempo da Mattia Battiston [5]. Lead Time e Cycle Time forniscono un’indicazione del tempo necessario per completare un task; sebbene riguardino i tempi di produzione, sono due concetti differenti fra loro.
Lead Time
In modo estremamente semplificato, possiamo dire che il Lead Time (LT) è il tempo complessivamente necessario per svolgere un determinate compito. Tiene conto delle attese e delle code. È il tempo quindi che il cliente complessivamente sperimenta sulla sua pelle. Per esempio, se consideriamo la richiesta di assistenza fatta da parte di un cliente per un problema sul proprio sito internet, il Lead Time parte dal momento in cui viene effettuata la richiesta e finisce al momento cui viene risolta, comprendendo tutto il tempo in cui la richiesta resta in coda in attesa che un tecnico la metta in lavorazione.
Il lead time è una buona metrica di soddisfazione utente in casi come quello riportato quando prodotto in sé e servizio di assistenza sono percepiti come la stessa cosa. In realtà, sebbene prodotto principale e servizio di assistenza siano a tutti gli effetti due cose differenti, sempre di più l’utente tende a valutare la bontà del prodotto in base al tipo di servizio offerto dopo la vendita.
Aziende come Apple o Dell hanno costruito la reputazione dei loro prodotti anche sull’assistenza, che è accessoria, ma che è ormai diventata tutt’uno con il prodotto. Sempre più spesso, nel mercato attuale, questi due prodotti sono venduti al cliente come una sola cosa. Il Lead Time ha anche l’indubbio vantaggio di misurare velocemente gli effetti di modifiche apportate al processo o al prodotto e quindi di guidare con feedback rapidi il processo di miglioramento continuo.
Una nota importante: il Lead Time nasce in ambito manifatturiero, ma qui noi lo stiamo usando in un contesto differente. Usare il tempo di lavorazione come metrica potrebbe addirittura portare fuori strada quando si parla di soddisfazione utente. Evadere una richiesta nel più breve tempo possibile potrebbe non essere la cosa migliore da fare in favore del cliente. Per esempio, potremmo impiegare più tempo ma curare meglio la richiesta del cliente? Potremmo addirittura affrontare insieme il problema e scoprire che in realtà il vero problema è un altro? Oppure, la cura della relazione potrebbe risolvere una preoccupazione del tutto emotiva, che non corrisponde a un effettivo problema del prodotto? Per questo il concetto di Lead Time andrebbe contestualizzato, introducendo per esempio un nuovo concetto, quello di Lead/Satisfaction Time.
Cycle Time
Il Cycle Time invece conta esattamente il tempo effettivo impiegato dal tecnico per risolvere il problema. Volendo entrare “dentro” il processo di costruzione del prodotto si può prendere in considerazione proprio il Cycle Time (CT) che, a differenza del Lead Time non tiene conto delle attese ma misura esclusivamente il tempo di lavorazione.
Il Cycle Time esprime una misurazione della complessità della lavorazione ma non del servizio in sé. È quindi una misura interna: al cliente finale non interessa tanto che il Cycle Time sia basso o alto ma interessa quanto deve aspettare in totale e cioè il Lead Time. Il Cycle Time fornisce comunque informazioni utili: se aumenta, potrebbe essere indicazione di una complessità intrinseca del prodotto forse non del tutto giustificata. Chi sviluppa software sa che un’architettura “pulita” spesso permette di mantenere lineare o addirittura stabile la crescita del Cycle Time all’aumentare del numero di righe di codice.
Cumulative Flow Diagram
Qualora si vogliano analizzare più in profondità le informazioni provenienti dal Cycle Time, si può provare a scomporre il tempo di lavorazione nelle sottofasi. Utile in questo caso è l’uso del Cumulative Flow Diagram (CFD).
Si tratta di un diagramma che mostra lo stato di avanzamento della lavorazione delle varie sottofasi. Per esempio permette di confrontare il totale delle cose da fare (la curva del backlog in blu scuro nella figura) con il numero di cose che devono essere ancora fatte nelle varie sottofasi, (curve dei vari colori, dev, test, deploy).
L’area contenuta fra la prima curva (il lavoro ancora da svolgere) e l’ultima (il lavoro finito) rappresenta il Work In Progress (WIP). Se questa area aumenta (divergenza delle due curve) significa spesso che il prodotto sta aumentando di complessità e non si riesce a chiudere in tempi rapidi i problemi.
Andando ad analizzare le “forme” delle eventuali sottoaree, possiamo comprendere meglio dove sia il problema. Per esempio se aumenta il tempo di analisi (la curva corrispondente sale poco rispetto a quella del backlog), ciò potrebbe essere indice di un prodotto complicato per il quale ogni volta è difficile capire dove mettere le mani. Se invece la divergenza si trova nella fase di test, potrebbe essere indice di regressione derivante da modifiche: e allora si potrebbe risolvere il problema introducendo sistemi di test automatici?
La distanza orizzontale fra la curva del backlog e la curva del finito a una determinata quota rappresenta il tempo necessario per evadere quel task e quindi è il Cycle Time, ammettendo in questo caso che non ci siano pause fra una fase e l’altra, fatto in realtà piuttosto raro.
Conclusioni
Per questo mese ci interrompiamo qui. Abbiamo introdotto il tema del valore del prodotto, prendendo a spunto alcuni concetti derivati da altri ambiti, come il Lead Time derivante dal mondo della manifattura Lean. Lo scopo di questo articolo era di iniziare a parlare di alcuni concetti preparatori per le trattazioni successive, nelle quali inizieremo a discutere più approfonditamente di usabilità ed esperienza utente.