mvp orizzontale  psm1 small  cdap  sixsigma yellow belt mini  mcpd agileiot logo  ac2 logo

  • Categoria: ALM
  • Scritto da Felice Pescatore
  • Visite: 1484

Lean Startup in a Nutshell, parte 2 - Build

Nel primo post della serie abbiamo fatto il punto su cosa sia Lean Startup e sul perché può essere utile conoscerlo ed adottarlo nell’ambito della creazione di una nuova startup.

Entriamo ora nel vivo dell’operatività della metodologia di Ries, andando ad occuparci del ciclo Build-Measure-Learn e dei tool annessi. Prima di continuare è opportuno ricordare che l’obiettivo di una startup è quello di accelerare tale loop in modo da ricevere velocemente i feedback dagli early adopters, i primi utilizzatori che condividono la Vision generale e che possono contribuire al suo raggiungimento. L’individuazione degli early adopters è fondamentale: tali utenti possono tranquillamente tollerare inefficienze e un prodotto parzialmente funzionante, perché sono “affamati” di novità e hanno “desiderio” di contribuire alla sua evoluzione.

In questo post vedremo, in particolare, come velocizzare la fase di Build, fase in cui l’idea viene codificata e presentata agli early adopters (e successivamente ai clienti) per i feedback.

build measure learn build

Build phase

Dal passaggio dell’idea alla codifica, il tool fondamentale è il Minimum Viable Product (MVP), sostanzialmente un prodotto/servizio che implementa il set minimo di funzionalità per la convalida della strategia. L'approccio di sviluppo, strutturato in termini di Validate Learning, si contrappone decisamente alla logica del “release maximum-feature”, in cui si cerca di rilasciare quante più features possibili, abbracciando la filosofia “release early, release often” che prevede di rilasciare velocemente e spesso nuove release della propria soluzione (Continuous Delivery). In tal modo si va ad abbattere quello che tipicamente viene indicato come l’8 MUDA, ovvero il sotto-utilizzo delle risorse umane, nello specifico gli early-adopters.

Ma cos’è concretamente un MVP? Possiamo immaginarlo come un qualsiasi artefatto che ci permette di verificare le nostre ipotesi e i nostri “atti-di-fede” (act of faith): dal prototipo, ad una semplice pagina web, fino anche ad un video in cui si descrive il prodotto/servizio.

Minimum Viable Product

The MVP

La fase di codifica vera e propria trova nelle metodologie Agile e Lean Software Development un ottimo strumento di riferimento, considerando anche l’estrema incertezza in cui si opera tipicamente una startup (ricordiamoci che sia il problema che la soluzione sono sconosciuti).

Attenzione, però! Il Program Backlog non va pensato in chiave standard, ovvero composto dalle Feature, bensì va popolato con le ipotesi da verificare ad ogni nuovo loop, mentre l’azione di sviluppo è gestibile attraverso un Iteration Backlog in chiave classica.

Una volta consegnato l’MVP, è possibile avere due scenari: se, quanto realizzato, non dovesse confermare le assunzioni (Innovation Accounting), è possibile ripartire dallo step precedente ed attuare le opportune azioni di PIVOT. Dualmente, se l’MVP le convalida, è possibile passare allo step successivo aggiungendo nuove funzionalità ad esso: si opera, sostanzialmente, in un’ottica di Continuous Integration, andando ad abbattere due dei MUDA di Lean: la Sovrapproduzione (over-production) e le Scorte (over-stocking). Ciò avviene concentrandosi solo su quello che è funzionale all’obiettivo imminente, integrandolo rapidamente nel nuovo MVP da consegnare agli early-adopters per le fasi successive.

Tornano alla Continuous Delivery è doveroso evidenziare che essa può diventare pericolosa nel momento in cui comincia ad essere necessario garantire una reliability di una certa robustezza, soprattutto quando si passa dagli early-adopters ai clienti di riferimento. Ad esempio: cosa accade se l’ultima modifica intacca il sistema di e-commerce? Chiaramente le revenue diminuiscono e la startup comincia a soffrire di liquidità.

Per tutelarsi da situazioni indesiderate, oltre agli strumenti di Quality Assurance tipici delle attività di sviluppo (si pensi, al TDD e al BDD, tanto per restare in chiave Agile), è possibile creare un Cluster Immune System, ovvero un sistema che monitora (Actionable Metrics) quanto accade nel sistema e ripristina la precedente situazione laddove l’ultimo deploy ha generato problemi evidenti. E’ possibile approcciare tale sistema sia in modo automatizzato che parzialmente-automatizzato, ma si tratta comunque di un percorso lungo e complesso, anche se inizia con semplici regole e best-practice. Al di là della scelta specifica, la cosa fondamentale è consentire al Team di lavorare con serenità, evitando che i fallimenti (che ricordiamo, ci saranno e devono esserci) si trasformino in qualcosa di diverso da strumento di apprendimento.

cust dev plus agile

Lean Startup & agile

Da un punto di vista tecnologico, due elementi sono particolarmente adatti alla fase di Build di Lean Startup: il primo è l’utilizzo di framework e middleware che dispongono di un’ampia community di supporto, consentendo così di velocizzarne l’apprendimento e la risoluzioni di eventuali problemi. Questo aspetto è sicuramente primario rispetto a quello tanto enfatizzato dell’open/closed source, poiché bisogna essere in grado di quantizzare il vantaggio nella sua interezza, ad esempio: se l’utilizzo di un framework open-source implica una curva di apprendimento molto ampia, ciò rallenterà l’esecuzione del loop build-measure-learn, in contrasto con l’obiettivo stesso di Lean Startup.

Il secondo elemento tecnologico è il Cloud (nelle sue varie forme IaaS, PaaS e SaaS), permettendo di non spendere praticamente nulla in infrastrutture tecnologiche grazie all’approccio pay-as-you-go. In tal modo è possibile realizzare la propria soluzione e farla testare agli early-adopters in modo estremamente conveniente, utilizzando solo le risorse effettivamente necessarie. Anche qui la scelta è eterogenea, passando per Microsoft Azure, Amazon EC2 fino ad arrivare a Heroku, tutte piattaforme con la loro specificità e adattabilità al contesto. A voler essere precisi, Lean Startup non parla in modo esplicito di Cloud, ma enfatizza il concetto di just-in-time scalability, ovvero la necessità di supportare il prodotto/soluzione con la necessaria infrastruttura, evitando di sottodimensionarla (MUDA:Attese) o sovradimensionarla (MUDA:Troppe Scorte). E’ possibile, comunque, considerare il Cloud come il naturale step evolutivo di quando previsto da Ries.

 

In conclusione, nella fase di Build, è fondamentale utilizzare strumenti snelli e dinamici che consentano di velocizzare il deploy (sicuro), abbattere i costi ed ottenere rapidamente i feedback dagli early-adopters.