Concludiamo la nostra serie che ha illustrato pratiche e strumenti per passare dall’idea, alla definizione e alla ‘messa in cantiere’ del prodotto da sviluppare. Sebbene siano stati trattati argomenti orientati sostanzialmente allo sviluppo di software, questo approccio funziona benissimo anche per altre aree produttive e, con piccoli aggiustamenti, può essere perfettamente adattato ai diversi contesti.

Strumenti, ma non solo…

Negli articoli fin qui visti abbiamo illustrato strumenti per svolgere uno dei compiti più difficili: trasformare un’idea in un prodotto. E se li abbiamo visti all’opera nell’arte di sviluppare software, non va dimenticato che molto di quanto raccontato nella serie è applicabile anche in altri contesti produttivi. Si tratta di un lavoro che comprende la definizione dell’idea di base, la formalizzazione dei requisiti e l’impostazione del progetto.

La condivisione e la comprensione comune dell’idea sono forse l’ostacolo più grande per far partire un progetto. Si possono trascorrere giorni e giorni in interminabili riunioni per condividere l’idea a tutti i livelli: possiamo coinvolgere ruoli direttivi e finanziari, project manager, sviluppatori, marketing, ufficio vendite e supporto clienti… per poi scoprire che la condivisione è solo superficiale e il consenso sul progetto è dato più sulla fiducia che sul contenuto. Spesso la comunicazione verbale non aiuta più di tanto, perchè molti aspetti dell’idea del prodotto in molti casi non sono facilmente condivisibili a parole.

Vantaggi e criticità della documentazione scritta

Trasmettere le informazioni per iscritto è una prassi molto comune che ha indubbi vantaggi:

• formalizza il pensiero e la comunicazione verbale, organizzando in modo logico i contenuti;
• consente di mantenere uno storico delle scelte adottate, e magari anche delle ragioni alla base di tali scelte;
• il documento scritto ben si presta a inserirsi in un processo di approvazione.

A fronte di questi indubbi vantaggi, quando si decide di scrivere un documento testuale, indipendentemente dal formalismo utilizzato, spesso si corre il rischio di concentrare l’attenzione sul “formato” e sulla compilazione del documento piuttosto che sul produrre valore per il cliente.

Il secondo punto dell’Agile Manifesto (“Il software funzionante più che la documentazione esaustiva”) [1] diventa sia un faro guida sia un punto di discussione forte. Come faccio a non scrivere documentazione? In Agile si scrive documentazione? Quanta? Quale?

Prima di rispondere a queste domande, conviene anzitutto capire quale sia l’utilità che risiede nella documentazione dal punto di vista del cliente finale.

Il valore del documento

In tal senso la documentazione prodotta, sopratutto quella realizzata nelle fasi iniziali di progetto, ha valore se è condivisa e compresa da tutte le persone coinvolte: lo scopo è quello di permettere di condividere l’idea del prodotto o servizio che si vuole realizzare.

Come già più volte detto, solo la condivisione della visione di prodotto, degli obiettivi e delle modalità per raggiungerli, consente di realizzare un prodotto che soddisfi i bisogni di business dell’utente, cosa che in definitiva è il vero scopo di un progetto software.

Quindi, lo scopo della documentazione è condividere conoscenza e permettere la collaborazione. Guardando le cose da questo punto di vista, l’obiettivo di produrre documentazione è certamente nobile e utile. Quello che ci si potrebbe chiedere è se ci possano essere strumenti più efficaci rispetto alla scrittura di documenti testuali che poi spesso non catturano la curiosità degli interessati e finiscono per rimanere in qualche remota cartella dell’hard disk.

Canvas come documentazione

Probabilmente l’uso di lavagne per disegnare ma anche e sopratutto per parlare insieme potrebbe essere una valida alternativa. In questa serie di articoli abbiamo già abbondantemente affrontato questo tema, proponendo una serie di strumenti utili per la fase di definizione dei requisiti nonchè per la successiva validazione.

Abbiamo parlato di come identificare e formalizzare la visione di prodotto (Vision Board) e di come individuare e validare successivamente il modello di business (Business Model Canvas); abbiamo affrontato il tema della traduzione dei bisogni utente in un elenco di funzionalità da implementare (User Story Mapping).

Questo mese vorremmo presentare un ultimo strumento a disposizione per comprendere meglio le caratteristiche del prodotto che si deve realizzare, ovvero la Product Canvas. A conclusione di questa serie, vorremmo anche ricapitolare il flusso della lavorazione nel suo complesso, ovvero come i vari tool che visti fin qui possano essere utilizzati per passare dall’idea al prodotto.

La Product Canvas

Una volta definita e condivisa la Vision Board, si può provare a stilare un primo elenco delle cose da fare creando una prima versione del Product Backlog; per svolgere questo compito si può utilizzare la tecnica vista in precedenza dello Story Mapping, oppure sfruttare un altro strumento come il Product Canvas. Nella figura 1 è mostrato il tipico impiego della Product Canvas, che si inserisce all’interno di un processo iterativo e incrementale e che consente di trasformare un’idea in un elenco di funzionalità, in questo caso storie utente, da implementare nella fase di lavorazione vera e propria.

Per comprendere meglio l’utilizzo di questo strumento, conviene entrare nel dettaglio di come è fatta la “lavagna”. La figura 2 riprende un modello proposto da Roman Pichler [2] e ci mostra le varie sezioni della Product Canvas.

La Product Canvas normalmente viene “compilata” in un workshop in cui il team arriva a completare le varie parti della board in forma di prima realizzazione. In genere, la durata di tale evento è quello di una giornata completa.

Vediamo di seguito le diverse sezioni e le informazioni che andranno inserite.

Nome

Si tratta del Il nome  del prodotto che si deve realizzare. Può essere il caso di specificare anche la versione del prodotto, in caso si tratti di un redesign o di una nuova implementazione di qualcosa che già esisteva.

Goal

Il goal rappresenta l’obiettivo che si vuole raggiungere con la realizzazione di questo prodotto o tramite questa nuova release di un prodotto già esistente: trovare nuovi utenti, soddisfare nuove richieste di mercato e così via. Roman Pichler, nel suo sito, propone l’uso della Go Product Roadmap [3] come strumento di pianificazione del prodotto orientata alla definizione degli obiettivi. Nel caso in cui si sia scelto di utilizzare questo strumento, per approfondire l’analisi del tema “obiettivi”, si potranno riportare nella Product Canvas le parti corrispondenti.

Metriche

La sezione metriche serve per specificare dei parametri di valutazione che possano permettere di capire quanto quello che si sta realizzando rispetta gli obiettivi prefissati. Anche in questo caso la Go Product Roadmap può essere di aiuto.

Target Group

La definizione del gruppo di utenti tipo serve per individuare chi potrebbero essere gli utilizzatori tipici di questo prodotto, e capire successivamente i loro bisogni. Per compilare questa parte si può usare il formalismo delle personas e per questo si potrebbero utilizzare le personas individuate durante la fase di visioning e che potrebbero essere qui riutilizzate in forma sintetica prendendo direttamente spunto da quanto inserito nella Vision Canvas. La Product Canvas offre infatti una visione di sintesi da un differente punto di vista, per cui non deve meravigliare che si ricavino in questa fase informazioni differenti a complemento di quanto visto durante la vision.

Visto che nella Product Canvas il focus è sulle funzionalità del sistema, potrebbe essere utile in questo momento provare a definire un ordinamento delle personas in funzione dell’importanza dell’utente: quello che paga o uno sponsor importante, o un’altra categoria importante. Si può anche ordinare le personas in funzione dell’importanza i bisogni: urgenza, funzionalità “rivendibilità”, ROI maggiore o altro. In questo modo sarà certamente più semplice poi stabilire la priorità delle funzionalità da implementare. Alle Primary Personas così individuate dovrebbero infatti corrispondere funzionalità che poi saranno in cima al backlog di prodotto.

Big Picture

La Big Picture, vale a dire il “quadro d’insieme”, descrive cosa è necessario fare per soddisfare i bisogni delle personas: dovrebbe fornire la visione di insieme del prodotto ad alto livello; concettualmente ricorda l’indice di un libro: ne descrive il contenuto senza entrare nel dettaglio.

Per questo, spesso in questa parte si inseriscono gli User Journeys ovvero la descrizione delle varie operazioni che l’utente svolge quando utilizza il prodotto: si collega, apre il menu XYZ, cerca e sceglie, compra, stampa, esce etc. Per la definizione dei “viaggi” possono usare tecniche come gli Scenari [4]  o lo User Story Mapping che abbiamo visto in una puntata precedente.

Durante questa fase, è utile anche la raccolta di informazioni relativamente alla parte non funzionale, ai requisiti tecnici e alle cosiddette constraint stories che possono in qualche modo impattare sulla esperienza utente o sulla architettura software.

Per comprendere meglio l’esperienza utente spesso si realizzano in questa fase delle immagini di interfaccia utente, che poi si “attaccano” direttamente alla board. Per questo lavoro si possono usare diverse tecniche come  design sketches e mock–up [5], oppure applicazioni per la prototipazione rapida delle interfacce che permettano di provare una versione semi funzionante in tempi rapidissimi [6].  In questa fase, è importante concentrarsi sugli aspetti strutturali del design grafico (layout di massima) e sugli aspetti critici legati all’architettura dell’informazione.

Product Details

Infine, nella sezione Product Details, si inseriscono gli elementi che dovranno essere messi in lavorazione nella prossima iterazione (lo sprint zero se siamo a inizio progetto).

Questo elenco può essere prodotto analizzando i risultati del punto precedente. Per esempio i vari passi dei diversi “viaggi utente” possono essere visti come gli elementi a grana grossa (epiche o features) del Product Backlog. Se si è utilizzata la tecnica dello User Story Mapping, il set delle storie individuate per il prossimo sprint potrebbe essere inserito così com’è in questa parte.

Personalmente trovo molto utile usare la Product Canvas in congiunzione con la tecnica dello User Story Mapping perchè consente di produrre contenuti interessanti tramite un lavoro strutturato e rigoroso. Nella figura 3, infine è riportato un esempio di una Product Canvas per un progetto mobile.

L’utente prima di tutto

La canvas è progettata per permettere che il processo relativo alla generazione delle varie parti si traduca in un flusso di informazione da sinistra a destra, ossia dalle personas ai dettagli del prodotto. In questo, modo si pone sempre l’utente al centro del proprio lavoro concentrando quindi gli sforzi sui suoi bisogni e sui suoi desideri, permettendo la realizzazione di un prodotto che li possa soddisfare.

Il flusso di informazioni

Interessante notare come questo flusso di informazioni non si realizzi solamente all’interno della board, ma sia lo stesso tipo di percorso che si ritrova più in grande nel processo di lavorazione (vedi la figura 1): in quel caso, grazie al processo iterativo e incrementale messo in atto, ogni incremento nella realizzazione del prodotto finito permette di ricavare informazioni direttamente dagli utenti finali e quindi di migliorare la conoscenza del dominio, delle esigenze da soddisfare, ossia, in definitiva di quello che si deve fare. Si realizza quindi una sorta di circolo virtuoso in cui la Product Canvas può essere vista come una sorta di strumento di apprendimento utile sia per abbozzare le idee iniziali che per raffinarle in un secondo momento.

Per questo motivo non deve stupire se la Product Canvas subisce un processo di correzione e modifica per inserire nuovi dettagli, nuove informazioni o per cambiare quanto già inserito, man mano che si scoprono nuove cose. Per questo spesso le board sono piene di foglietti, scritte, scarabocchi: sono la brutta copia del tema in classe, dove continuamente si fanno correzioni, si aggiungono parti e se ne cancellano altre.

Un riassunto sulle canvas: “from vision to backlog… and back”

Come promesso, dopo aver presentato i diversi strumenti che si possono utilizzare per le varie fasi di envisioning e impostazione del progetto, passiamo a vedere quale è il corretto approccio per utilizzarli insieme.

Il lavoro di costruzione di un prodotto complesso è infatti frutto di un processo iterativo e incrementale in cui continuamente si parte dalle premesse per realizzare una parte del prodotto finito e, tramite la prova sul campo delle funzionalità inserite, si prova a rivedere, aggiungere e modificare le premesse.

La frase “from vision to backlog… and back” rappresenta perfettamente questo approccio: la parte del “back”, del “ritorno”, ossia l’approccio iterativo e incrementale, permette di trasformare un processo tipicamente sequenziale (dalla vision al modello di business alla definizione dell’elenco delle cose da fare) in un processo iterativo incrementale tipicamente agile.

Di fatto senza il cortocircuito che, dalla fase di realizzazione, ci fa ritornare ciclicamente a quella di vision e raccolta dei requisiti, quanto visto finora non sarebbe altro che una forma rivista e corretta  del caro vecchio waterfall…

Le varie canvas in azione…

…ossia un approccio iterativo, incrementale e complementare.

Come riportato nella figura 1, per passare dall‘idea al prodotto, la prima cosa da fare è lavorare sulla visione tramite il workshop con la Vision Canvas: lo scopo è capire perchè si vuole fare questo prodotto, per chi è il prodotto, quali bisogni si vogliono risolvere etc.

Aiutarci a capire in che modo il nostro prodotto “funzioni” in termini di sostenibilità economica e possibilità di guadagno, e come gli utenti saranno interessati a continuarne l’uso, magari pagando per certe funzioni, è compito della Business Model Canvas, che si occupa, appunto del modello di business.

Quando infine si arriva a entrare nello specifico delle funzionalità del prodotto, la Product Canvas può rappresentare un interessante punto di congiunzione fra le due attività che si sono svolte parallelamente in precedenza.

Da un lato la Product Canvas permette di approfondire in modo molto efficace un aspetto solamente accennato nella Business Model Canvas, ossia quello della Value Proposition; dall’altro la parte di raccolta delle varie personas offre una visione di sintesi di quello che nella Vision Canvas è invece analizzato nell’elenco degli utenti e dei bisogni.

Tre strumenti, un solo processo

Vision Canvas, Business Model Canvas e Product Canvas sono quindi tre strumenti che offrono una vista complementare del sistema che si deve realizzare. Tipicamente, la corretta maniera di usarli è in modo continuativo, iterativo e incrementale:

• in genere si parte dall’impostazione della vision;
• si passa subito dopo alla definizione del modello di business;
• appena si hanno sufficienti informazioni, si può iniziare a impostare lo studio del prodotto tramite la Product Canvas;
• da questa, direttamentee o tramite l’ausilio dello User Story Mapping, si può ricavare una prima versione del Product Backlog Items
• e “infine”, grazie a una metodologia iterativa e incrementale come Scrum, si potrà arrivare alla realizzazione di una prima versione del prodotto che implementi in forma minimale una prima risposta ai bisogni degli utenti individuati (il cosiddetto MVP).

È a questo punto che, grazie alla raccolta del feedaback degli utenti che hanno modo di provare una prima release di prodotto, si potrà procedere alla revsione o al completamento delle varie canvas

Se il progetto è gestito tramite Scrum, ad esempio, le informazioni raccolte durante le sprint demo  potranno fornire spunti per completare o modificare sia la parte di vision, sia quella di business. E, molto probabilmente forniranno dati interessanti anche per completare la raccolta delle funzionalità da implementare o per apportare modifiche alla modalità di interazione dell’utente con il sistema (i cosiddetti user journeys).

Questo flusso di lavorazione iterativo e incrementale, in cui i diversi strumenti sono messi in relazione complementare, sono mostrati in figura 5. L’idea si condivide e si elabora con l’aiuto della Vision Canvas, e una volta che la vision è chiara e condivisa si possono creare in parallelo Business Model Canvas [7] e Product Canvas; a partire da quest’ultimo, poi si può creare il Product Backlog del prodotto. E poi, con il feedback degli utenti, è possibile apportare le necessarie modifiche ai vari strumenti.

Conclusione

Termina con questa puntata la serie dedicata al tema “Dall’idea al prodotto”. Questo argomento spesso viene trattato con titoli differenti, come Lift Off, From Vision to Backlog e altri ancora, ma i concetti e gli strumenti sono quelli trattati in questi articoli. I contenuti di questa serie, opportunamente riveduti e adattati, andranno a far parte del libro “Guida Galattica per Agilisti” che stiamo scrivendo in questo periodo.

E di questi temi, inoltre, si parlerà proprio il prossimo martedì 3 marzo 2015 si terrà a Milano presso il Politecnico di Milano (DEIB: Dipartimento di Elettronica, Informazione e Bioingegneria) nell’ambito della conferenza Agile For Innovation [8]. In tale occasione, Marco Calzolari e lo scrivente (entrambi coach di Agile Reloaded) presenteremo un workshop dal titolo “Decollo verticale” dove i partecipanti potranno lavorare, sperimentando direttamente molti degli strumenti e delle metodologie descritte in questa serie. Vi aspettiamo.