În lumea startup-urilor, mișcarea Lean Startup a fost o revoluție deși a pornit de la o observație simplă. Modelul standard de creare a unui startup era până de curând "Build, Measure, Learn" adică:
Problema acestui model este că la momentul la care produsul poate trece testul pieței, el a fost deja construit, deci s-au investit bani și efort în el. Din punct de vedere tehnic, se întâmplă adesea ca produsul să fi fost grăbit, programatorii să lucreze sub presiune și rezultatul să fie un cod greu de modificat și plin de bug-uri.
Steve Blank și Eric Ries au venit cu ideea de a inversa acest ciclu și de a folosi "Learn, Measure, Build", adică:
Experimentul poate include crearea unui prototip funcțional al unei aplicații, dar nu este neapărat necesar. Arta constă în a identifica minimul de investiție pentru a putea valida ipoteza. Experimentele cele mai întâlnite, în special pentru produsele online, sunt de tip "A/B testing": două posibilități sunt puse în competiție și "votate" de utilizatorii potențiali. Cea mai populară este de obicei aleasă ca fiind câștigătoare.
La nivel tehnic, Lean Startup presupune o agilitate foarte mare determinată de lucrul într-un mediu necunoscut și în curs de descoperire. Dacă în modelul standard de dezvoltare de produs presupunem că știm care este viziunea, care sunt funcționalitățile și care sunt următoarele cerințe, în modelul lean startupviziunea se poate modifica în funcție de piață (prin pivotare), funcționalitățile sunt descoperite pe parcurs, iar cerințele următoare pot fi extrem de surprinzătoare.
Un exemplu clasic este Flickr, serviciul de stocare de imagini care a fost cumpărat de yahoo. Inițial, viziunea produsului era de a face un joc numit "Game Neverending" în care adăugarea de fotografii era una dintre funcționalități. După un timp, echipa și-a dat seama că jocul nu era foarte bine primit, dar serviciul de stocare de poze era foarte interesant pentru utilizatori. Ca urmare, au decis să se concentreze pe flickr.com și să oprească dezvoltarea jocului.
Literatura de Lean Startup menționează doar în treacăt aspectele tehnice ale metodei. Motivele sunt două: revoluția trebuia făcută în primul rând la nivel business și presupunerea autorilor a fost că programatorii își vor da seama ce practici tehnice trebuie să folosească.
Imaginați-vă însă contextul în care lucrează multe din startup-urile online de azi. Multe dintre ele fac deployment al unei versiuni noi în producție de sute de ori pe zi. Fiecare deployment este fie un experiment de tip A/B testing, fie implementarea unei funcționalități deja validate.
Acest ritm de dezvoltare necesită abilități de programare precum:
În plus, aceste echipe folosesc fluxuri de lucru clare care includ adesea: monitorizare, revenirea la versiuni care funcționează corect în caz de bug-uri majore, porți de validare înainte de deployment.
Dar poate nu este nevoie de sute de puneri în producție pe zi. Poate ajunge ca ciclul de feed-back să fie de o săptămână sau câteva zile. Chiar și atunci, abilitățile necesare pentru programatorii care lucrează la produs sunt aceleași. Singura diferență este că își pot împărți munca în incremente mai mari.
Dacă legătura cu Software Craftsmanship nu este clară încă, o vom explora în continuare. După cum spuneam în articolul despre Software Craftsmanship, mișcarea a apărut pentru a permite reducerea costului de schimbare al codului prin aplicarea anumitor practici cunoscute și prin descoperirea altor practici noi. Câteva dintre practicile pe care le cunoaștem acum sunt:
Întrebarea care se pune este când merită investit în aceste practici într-un startup și când nu. Pentru cei care urmează modelul lean startup, răspunsul ar trebui să fie simplu: atât timp cât suntem la început și încercăm să dezvoltăm clienții prin experimente, nu are rost să investim mai mult decât este necesar. Cele mai bune experimente sunt cele care nu necesită cod scris. Dacă totuși trebuie scris cod, este important să îl scriem cât mai repede cu putință, chiar dacă pot scăpa greșeli.
Imediat ce o funcționalitate a fost validată, codul trebuie scris, sau rescris, astfel încât să poată fi ușor de modificat. Altfel, riscăm să nu putem beneficia îndeajuns de rapid de pe urma lucrurilor pe care le aflăm prin experimente.
Trebuie să menționăm că programatorii care au exersat îndeajuns aceste tehnici pot termina mai repede implementarea dacă le folosesc. Acesta este de fapt idealul Software Craftsmanship: a-ți dezvolta atât de bine abilitățile încât să devină modul implicit și cel mai rapid de lucru, mai ales atunci când viteza de implementare este extrem de importantă.
Lean Startup se bazează pe artizani software (craftsman). Experimentele cele mai bune sunt cele care nu necesită cod. Uneori, este nevoie și de implementarea unor experimente. Un artizan software va fi capabil să le implementeze rapid și fără a introduce probleme.
Dacă în faza de descoperire putem trăi și fără a aplica practici precum TDD, testare automată sau refactoring, faza de implementare are mare nevoie de ele pentru a permite punerea cât mai rapidă în producție a functionalităților validate de experimente. Cu cât sunt puse mai rapid în producție cu atât crește probabilitatea de a avea clienți plătitori, asigurând supraviețuirea startup-ului și crescându-i șansele de succes.
de Ovidiu Mățan
de Roland Szabo
