Da progetti a prodotti

L’articolo che segue è il reportage dell’esplorazione della seconda tappa della nostra rotta, la città “Verso Agile”, nel paese dell’Inception. Caterina Palmiotto, agile coach esperta di facilitazione e coordinazione dei team, ci ha accompagnati con un approfondimento sul tema “da progetti a prodotti”.

Da progetti a prodotti

Il prodotto e il suo ciclo di vita

Quando parliamo di prodotto, non possiamo non considerare il suo intero ciclo di vita e anche di capire cosa vuol dire “evolvere il prodotto”. Il processo, considerato nella sua interezza, serve per comprendere se il prodotto sul quale si sta lavorando soddisfa veramente i bisogni dell’utente finale.

Un esempio del ciclo di vita di un prodotto che permette di considerare l’andamento sul mercato di tutte le fasi.

Il progetto, una parte di ciclo di vita del prodotto

Al contrario, quando si parla di progetto – nella sua accezione più classica, come contenitore che mira alla realizzazione e alla consegna del prodotto o al primo rilascio sul mercato -, si fa riferimento solo a una piccola parte dell’intero ciclo di vita.

Il progetto, in quest’ottica, non consente di capire se ciò che stiamo realizzando soddisfa veramente le necessità del cliente finale. E’ proprio quando rilasciamo la prima versione del prodotto che inizia la sfida più grande. E’ a quel punto che possiamo iniziare a raccogliere le informazioni necessarie per valutare come evolverlo nelle fasi successive.

Il punto fondamentale, dunque, non è la mera realizzazione di un prodotto. Affinché questo abbia valore per il cliente è necessario osservare ciò che accade all’immissione sul mercato e raccogliere feedback da parte dell’utente lungo tutto il processo.

Cosa accade quando termina un progetto?

Al termine di un progetto, la quasi totalità delle persone coinvolte viene allocata altrove e capita spesso di lasciare solo pochi individui a gestire correttive ed evolutive del bene prodotto.

Questi pochi “sfortunati” di solito dovranno lavorare anche ad altri progetti, magari per la maggior parte della loro capacity. Dovranno quindi gestire le evoluzioni del prodotto nei “ritagli di tempo”.

Questa dinamica potrebbe portare a sentimenti di frustrazione e a scarsi risultati in termine di performance, in quanto impedisce ai responsabili coinvolti sia di potersi concentrare su altri progetti sia di poter rispondere efficacemente alle ultime fasi del prodotto.

A dimostrazione di quanto precedentemente affermato, quando si parla di prodotto si deve considerare l’intero ciclo di vita; la consegna di progetto ne costituisce solo un elemento al suo interno.

Il prodotto e l’MVP

Diamo priorità al risultato complessivo del nostro prodotto piuttosto che alla singola consegna di progetto.

Il prodotto è un oggetto di valore. Il prodotto crea valore andando a rispondere ad una necessità dell’utente. Non è un elenco di funzionalità, bensì di un elenco di risposte ai bisogni espressi dal cliente.

L’MVP – il Minimum Viable Product – costituisce il prodotto nella sua versione più semplice e basilare (seppur nella sua rappresentazione più grezza), che permette di rispondere al bisogno primario del cliente.

A tal fine, è necessario tenere sempre l’utente al centro del processo di produzione, considerando costantemente il suo punto di vista per qualunque decisione circa il prodotto in realizzazione.

L’approccio iterativo incrementale

Per riuscire a coinvolgere l’utente e a mantenere l’attenzione sui suoi bisogni espressi, la metodologia Agile utilizza un approccio iterativo incrementale. L’ approccio iterativo incrementale consente all’azienda di ottenere costantemente un feedback dall’utente finale e di capire se ciò che si sta realizzando soddisfa realmente la sua richiesta.

Prendiamo qualche esempio e proponiamo qualche considerazione.

1. 1. 1. 1. L’approccio iterativo incrementale per la produzione di un auto.
            Nel primo caso, la soluzione sarà proporre al cliente un prodotto basilare che già soddisfi il suo bisogno principale e dal quale si potrà partire, successivamente, con correzioni e miglioramenti secondo i feedback dell’utente.
         2. L’approccio iterativo incrementale per la realizzazione di un’applicazione di prenotazione alberghi.
            Nel secondo caso, solo ricavando le funzionalità essenziali si potrà costruire lo scheletro della prima versione del prodotto che soddisfi i bisogni primari del cliente.Anche in questo caso, il bene potrà essere corretto e migliorato secondo i feedback dell’utente stesso iterazione dopo iterazione.

L’approccio iterativo incrementale permette di apportare modifiche al prodotto passo dopo passo secondo le richieste del cliente: anziché proporre un prodotto definitivo che soddisfi tutti i bisogni solo dopo la realizzazione dell’intero prodotto, viene offerto un prodotto basilare che risponde al bisogno primario dell’utente, che può così iniziare a provarlo fin da subito, e valutare quali sono i bisogni secondari da prioritizzare.

Un’ulteriore considerazione: adottando questo approccio, le priorità del cliente potrebbero cambiare e il prodotto finale potrebbe risultare diverso da quello immaginato e richiesto inizialmente.

Il valore

Durante il monitoraggio dell’avanzamento del progetto, vengono considerati due elementi:

1. 1. l’effort che l’azienda sta affrontando e, di conseguenza, l’effort rimanente per la realizzazione del prodotto immaginato inizialmente;
   2. il valore rimanente da consegnare, valutato in relazione al bisogno complessivo espresso dal cliente.

Il grafico riportato dimostra come, dando sempre priorità alle necessità del cliente nel corso della realizzazione, il valore rimanente diminuisce esponenzialmente, mentre l’effort rimanente diminuisce più lentamente nel corso delle iterazioni. Se per qualsiasi motivo la produzione dovesse venire interrotta, il cliente avrebbe comunque già ricevuto la maggior parte del valore desiderato. Quest’ultimo potrebbe anche decidere di voler interrompere la produzione per risparmiare parte del budget in quanto già soddisfatto del prodotto realizzato.

L’approccio iterativo incrementale può sfruttare:

• • user story point, per la valutazione dell’effort;
  • value points per comprendere e valutare il valore per il cliente.

Tali informazioni risultano utili per la prioritizzazione delle funzionalità da realizzare.

Il feedback

L’obiettivo principale dell’approccio iterativo incrementale – customer oriented – è quello di ottenere un feedback da parte del cliente in ogni fase del processo.
E’ necessario, quindi, attivare un ciclo di feedback, attraverso le seguenti fasi:

1. 1. definizione di una vision di prodotto;
   2. costruzione di un backlog: cioè la lista di funzionalità che possono soddisfare i bisogni del cliente;
   3. realizzazione del prodotto tramite un approccio iterativo incrementale;
   4. raccolta di feedback da parte dell’utente ad ogni interazione, per comprendere se ciò che si sta realizzando risponde alle necessità;
   5. misurazione delle metriche stabilite, per capire se il prodotto viene effettivamente utilizzato e cosa fare per migliorarne l’adozione.

Dagli ultimi due step vengono raccolti dati e informazioni che consentono di aggiornare vision e backlog per correggere la rotta e, per esempio, focalizzarsi su un target rivisto e migliorato.

Un passaggio critico: domande e metriche

Quando si definiscono la vision e la roadmap di prodotto, è opportuno immaginare anche una roadmap di domande alle quali si dovrà dare risposta lungo l’evoluzione del prodotto.

In una prima fase, dunque, ci sono dubbi e domande senza una risposta ben definita; per ognuna di queste, possono essere proposte assunzioni sulla base delle quali vengono definite delle metriche.

Le metriche hanno la funzione di misurare e valutare costantemente l’efficacia delle decisioni prese. Sulla base dei risultati ottenuti si possono scegliere e prioritizzare le correzioni da apportare al prodotto e aggiornare le metriche di conseguenza.

Una citazione e un monito: la Conway’s Law

“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.” – Melvin E. Conway
[Qualsiasi azienda che andrà a progettare un sistema, produrrà un “design” la cui struttura sarà la copia del sistema di comunicazione dell’azienda].

L’adozione di un approccio che pone l’utente al centro richiede attenzione nel riuscire a mantenere i problemi aziendali lontani dal prodotto per il cliente. Nello specifico, i problemi legati alla comunicazione.

Consideriamo un esempio di barriera comunicativa tipica dei silos.

Project Manager e team

In un approccio a progetti, l’obiettivo principale consiste nel riuscire a rispettare il budget previsto e le scadenze.

In una tale circostanza, i team spesso vivono una situazione di sovraccarico e non hanno nemmeno il tempo di chiedersi quale è lo scopo delle funzionalità, richieste generalmente da un altro dipartimento aziendale. E non gli viene nemmeno richiesto, perché devono soltanto concentrarsi a “sfornare” una funzionalità dietro l’altra il più velocemente possibile.

Difficilmente sarà possibile monitorare se ciò che viene realizzato sarà realmente utile e il Project Manager si troverà a prendere decisioni senza avere una visione completa, avrà infatti informazioni relative ai costi ma non ai potenziali ricavi del prodotto.

Product Owner e team

Al contrario, in un contesto Agile, focalizzandosi sul prodotto e su come risolvere un bisogno, la figura del Product Owner risulta essenziale per agevolare la comunicazione tra chi realizza il prodotto, altri dipartimenti aziendali, l’utente e l’ambiente esterno. Può così raccogliere e trasmettere tutte le informazioni utili per prendere decisioni sull’evoluzione del prodotto.

A livello di team, il modo in cui le persone riescono a lavorare intorno al prodotto influenzerà la realizzazione del prodotto stesso.

Per un buon risultato, il team deve poter seguire interamente il ciclo di vita del prodotto e contribuire continuamente al suo miglioramento, seguendo le varie correttive ed evolutive fino al ritiro dal mercato. Il vero team di prodotto dovrebbe comprendere tutte le persone coinvolte nel ciclo di vita del prodotto – dall’analista, a chi esegue le operazioni di rilascio, fino a chi si occupa di supporto al cliente.

Questa soluzione permetterebbe di mantenere il giusto focus su tutte le fasi del ciclo di vita e una forte motivazione a rendere il prodotto manutenibile nel tempo. Un approccio di questo tipo privilegia un’efficienza di flusso di lavoro, piuttosto che un’efficienza nell’utilizzo delle risorse.

L’estremizzazione dell’approccio a prodotti: il Caso Haier

Vediamo un caso reale che riguarda l’Haier Group Corporation, una multinazionale cinese. Con il desiderio di spingere su una forte decentralizzazione, Haier è giunta ad una estremizzazione dei team di prodotto: ha creato infatti un network di team, ognuno dei quali si comporta come una startup.

L’organizzazione agisce come un incubatore di startup, sostenendole con le risorse necessarie per farle crescere fino a quando diventano pronte per essere lanciate sul mercato.
Il loro obiettivo è quello di mantenere una “distanza zero” con il cliente, trasformando la produzione di massa in una customizzazione di massa. Vogliono infatti fornire prodotti e servizi customizzati per soddisfare qualsiasi bisogno o desiderio del cliente.

Le startup vengono lasciate autonome di prendere decisioni sul prodotto, sarà poi il mercato a stabilire se le scelte fatte erano giuste o meno. Haier ha infatti messo in piedi un meccanismo di condivisione dei profitti che assicura di ricompensare chiunque crei valore per il cliente.
Questa realtà rappresenta un sistema di co-creazione e win-win con un allineamento assoluto sull’obiettivo da raggiungere per tutte le persone coinvolte.