Fallisci presto, impara in fretta: sii Lean!

Build, measure, learn

Il Lean è una cultura orientata a comprendere le esigenze del cliente, ridurre gli sprechi e ottimizzare i processi, una filosofia che potremmo riassumere nel motto “massimo risultato con il minimo sforzo”.

E’ una teoria di organizzazione aziendale che integra al suo interno varie metodologie gestionali.
Obiettivo del Lean è produrre di più con un minor consumo di risorse.
Il termine “lean production” – produzione snella – è stato coniato in riferimento al sistema Toyota, l’azienda automobilistica giapponese caratterizzata da processi industriali ad altissima efficienza rispetto ai principali produttori mondiali di automobili.

Tra i concetti chiave del Lean c’è l’idea del miglioramento continuo (“Kaizen”) perseguito mediante l’applicazione di un processo ciclico in 3 fasi: sperimentazione, misurazione dei risultati e apprendimento (build, measure, learn).

Nel famoso libro di Eric Ries “Lean Start-up” viene più volte ribadito che l’acquisizione di conoscenza è cruciale per il successo di un’iniziativa imprenditoriale:

“Questo è il modo giusto di pensare alla produttività in una start up: non in termini di quanta roba stiamo producendo, ma di quanto apprendimento validato stiamo incamerando per i nostri sforzi.
Ogni bit di conoscenza che raggiungiamo ci suggerisce nuovi esperimenti da fare che muovono le nostre metriche più vicine ai nostri obiettivi.”

Un processo Lean prevede i seguenti step:

  1. Identificare cio’ che vale per gli utenti 
(per cosa sono disposti a pagare un prezzo?)
  2. Identificare il flusso del valore
    definire la sequenza ottimale delle attività per creare valore
  3. Far scorrere il flusso del valore
    eseguire le attività di valore senza inutili interruzioni
  4. “Pull” e non “push”

    fare scorrere il flusso del valore in base alla domanda, non all’offerta
  5. Puntare alla perfezione come punto di riferimento in un contesto di miglioramento continuo

Se applichiamo i principi Lean al mondo del software e in generale della progettazione ritroviamo gli step ciclici di build, measure, learn.

Dobbiamo identificare un problema o un’opportunità di sviluppo e verificare che abbia davvero valore per gli utenti (per questo è necessario acquisire conoscenza dei loro bisogni e e necessità).
Modifichiamo il nostro punto di vista e proviamo a ridefinire il problema dal punto di vista degli utenti. Mettiamoci “nei loro panni”.
Solo a questo punto – quando siamo stati in grado di avere empatia nei confronti di coloro per cui stiamo progettando – siamo in grado di fare brainstorming in maniera proficua e portare soluzioni creative.

Una volta definite la nostra idea ne verifichiamo le assunzioni (cosa stiamo dando per scontato senza averne alcuna prova?) conducendo degli esperimenti.
Possiamo creare un prototipo – il più “lean” possibile – per mettere alla prova l’idea in poco tempo e con il minimo delle risorse per testare la soluzione sul campo e raccogliere feedback quanto prima.

Il confronto reale con i propri utenti ci permette di validare l’idea iniziale raffinandola ulteriormente, di aggiustare il tiro o – in alternativa – di non proseguire oltre.
Anche una soluzione che si rivela totalmente sbagliata è un insegnamento di successo: ci evita lo spreco di realizzare un prodotto/servizio che non ha valore per l’utente finale e ci offre l’opportunità di investire meglio le nostre risorse.

A conti fatti se non puoi fallire, non puoi imparare.

Build, measure, learn

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!)