Modul de lucru Agile a devenit din ce în ce mai popular în dezvoltarea produselor software, întrucât acesta își propune să depășească limitările modului de lucru tradițional, numit Waterfall. Agile promovează o abordare empirică și iterativă care facilitează colaborarea, livrarea mai rapidă și ajustarea constantă a livrabilelor în concordanță cu dorințele clienților aflate într-o continuă schimbare. Cu toate astea, capacitatea de a ne ajusta rapid, ținând cont de dorințele clienților, nu este întotdeauna suficientă pentru a dezvolta produse inovatoare care să vină în întâmpinarea nevoilor reale ale utilizatorilor. De multe ori, clienții au impresia că au anumite nevoi, pe care le transpun într-o serie de cerințe. Cu toate acestea, odată implementate, cerințele se transpun într-o serie de funcționalități ce ajung să nu fie niciodată folosite. Acest lucru își are cauza în faptul că utilizatorii nu pot articula întotdeauna ceea ce își doresc cu adevărat și nu pot transpune cu ușurință în idei de funcționalități problemele cu care se confrunta zi de zi.
Pentru acest lucru, conceptul Design Thinking îmbină tehnologia cu modul în care utilizatorii gândesc, ajutându-ne să ne să empatizăm și să înțelegem cu adevărat interacțiunea pe care aceștia o au cu produsul și să generăm idei cu privire la nevoile și problemele lor reale.
Mai mult decât atât, conceptul Lean Startup promovează validarea acestor idei după o perioadă foarte scurtă de timp, prin crearea inițială a unui produs ce conține un set minim de funcționalități pe care le oferim spre utilizare, pentru a ne asigura că ipotezele noastre sunt relevante și că direcția pe care am pornit este una corectă.
În dezvoltarea unui produs, Design Thinking, Lean Startup și Agile nu trebuie aplicate într-un mod secvențial. Ele sunt complementare și se suprapun pe alocuri, fiind esențiale pentru succesul produselor dezvoltate.
În cadrul acestui articol, îmi propun să descriu cum putem îmbina elemente specifice celor trei concepte în cadrul unei sesiuni de workshop de cinci zile, care să ne ajute să pornim, într-un mod eficient, procesul de dezvoltare al unui produs nou.
Abordarea tradițională folosită în dezvoltarea produselor software se numește Waterfall. Așa cum sugerează și numele modelului, folosind această metodă, produsele sunt dezvoltate într-o manieră secvențială. Procesul de dezvoltare pornește cu definirea unei imagini foarte clare cu privire la modul în care trebuie să arate produsul la final, incluzând toate detaliile necesare. Acest pas este urmat de implementarea propriu-zisă a produsului, testarea acestuia și de livrarea sa către utilizatorul final. Vorbind despre o abordare secvențială, este clar că implementarea produsului nu începe până când procesul de analiză și de preluare a tuturor cerințelor nu este finalizat. Odată preluate cerințele în faza inițială, acestea nu se mai schimbă pe parcursul implementării. Totul trebuie planificat cu atenție de la început. Interacțiunea cu clientul are loc doar în faza de preluare a cerințelor și la sfârșit, atunci când produsul este finalizat. Practic, succesul produsului este puternic corelat cu abilitatea noastră de a înțelege cerințele în faza inițială. Astfel, potențialele neînțelegeri și presupunerile greșite pe care suntem tentați să le facem în faza inițială pot conduce la dezvoltarea unor produse care nu sunt folosite niciodată, deoarece nu tratează cu adevărat nevoile clienților. Valorificând această abordare, clientul beneficiază de produs abia la sfârșit, atunci când toate etapele sunt finalizate. Acest proces poate dura ani de zile, în funcție de complexitatea produselor dezvoltate.
Având în vedere viteza cu care tehnologia avansează în ziua de azi, ne mai permitem oare luxul de a petrece ani pentru a crea produse care, la momentul finalizării lor, vor fi probabil extrem de învechite?
În ultimele decenii, complexitatea aplicațiilor software a crescut exponențial. În momentul în care înțelegem că furnizăm soluții complexe pentru situații complexe, ne dăm seama că identificarea tuturor cerințelor încă de la început este imposibilă. Nu putem să știm totul în faza inițială. Procesul de dezvoltare trebuie să ne ofere timp pentru a explora.
Modul de lucru Agile a venit ca răspuns la toate aceste provocări și limitări. Agile renunță la abordarea secvențială, promovând un mod de lucru iterativ și empiric. Acest lucru presupune ca munca să fie livrată către clienți în iterații scurte: începem cu funcționalitățile de bază și le lăsăm să evolueze în timp, luând în considerare lecțiile învățate în cadrul iterațiilor anterioare și părerea pe care clienții o au după fiecare iterație, după ce încep să interacționeze cu produsul.
Întrucât scopul poate suferi modificări, analiza cerințelor și planificarea se fac pentru perioade mai scurte de timp, diminuând astfel pierderile. Echipele agile sunt dispuse să se adapteze tot timpul, în funcție de potențialele schimbări ale scopului.
Având ca punct de plecare Manifestul pentru Dezvoltarea Agilă a Software-ului (2001), Agile a apărut ca un set de valori și principii care subliniază importanța colaborării, flexibilității și axarea pe nevoile clienților, considerând produsele software funcționale cel mai valoros indicator al progresului. Potrivit studiilor, primele trei motive pentru adoptarea metodologiilor agile sunt accelerarea livrării, gestionarea priorităților aflate într-o continuă schimbare și creșterea productivității. Este, totuși, capacitatea noastră de a dezvolta mai rapid elementul esențial care ne ajută să generăm produse inovatoare ce îi satisfac pe clienți cu adevărat?
Într-o industrie a schimbării constante și a incertitudinii, avantajul competitiv al companiilor dezvoltatoare de software este capacitatea lor de inova. Inovația ajută organizațiile să proiecteze soluții care să răspundă nevoilor clienților. Pentru a le furniza, trebuie să-și cunoască mai bine utilizatorii: să le identifice problemele, dorințele, profilul și comportamentele. Toate aceste activități fac parte din procesul de Design Thinking, care poate fi descris ca fiind partea umană a tehnologiei. Acest conceput creează o punte de legătură între tehnologie și modul în care oamenii gândesc și interacționează cu produsul. Astfel, soluția este creată astfel încât să ușureze modul de utilizare în concordanță cu profilul utilizatorului, realitatea și contextul acestuia. Astfel, interacțiunea cu produsul este menită să creeze o experiență plăcută și facilă.
Și totuși, chiar și după ce ne cunoaștem mai bine clienții și nevoile, procesul poate avea unele limitări. Adevărul este că lumea este prea dinamică și imprevizibilă pentru a presupune că mergem într-o direcție pozitivă, fără a o valida. Abordarea Lean Startup reduce acest risc prin dezvoltarea unei versiuni simple a produsului care este oferită clienților pentru a valida un set esențial de ipoteze. Scopul este acela de a obține informațiile necesare pentru a valida rapid dacă suntem pe drumul cel bun și dacă merită să investim resurse în dezvoltarea acelui produs.
Cum putem corela Agile, Design Thinking și Lean Startup într-un proces de inițiere a unui produs de succes?
Răspunsul îl găsim în cele ce urmează.
Înțelegerea celor trei concepte anterior menționate m-a determinat să extrag o serie de elemente de bază, pe care le-am transpus într-o serie de pași esențiali de urmat în vederea inițierii oricărui produs.
Odată urmați acești pași, nu doar că vom crește nivelul de satisfacție al utilizatorilor, dar vom influența pozitiv și nivelul de motivație al echipei ce contribuie la dezvoltarea produsului.
Aplicarea Design Thinking va ajuta echipa să înțeleagă utilitatea muncii lor, în timp ce Lean Startup scade riscul de a consuma timp și resurse pentru construirea unor soluții pe care nimeni nu le folosește.
Pașii descriși mai jos reprezintă, din punctul meu de vedere, fundația unui proces de dezvoltare a unui produs:
Elementul esențial în această etapă este înțelegerea conceptului de persona. O persona reprezintă un caracter definit pentru a descrie o tipologie de utilizatori, care folosesc produsul într-un anumit fel, având un anumit comportament.
Utilizatorii produsului sunt încadrați în mai multe persona, urmând ca pentru fiecare dintre ele să definim următoarele:
Alias;
Comportament și caracteristici demografice;
Motivul pentru care ar folosi produsul: problemele cu care se confruntă, nevoile pe care le are, scopurile pe care vrea să le atingă;
Pentru fiecare din aceste combinații (persona - problemă/nevoie/obiectiv), înțelegem contextul în care se manifestă, prin identificarea elementelor de tipul: când și unde?
Pentru fiecare din combinațiile mai sus menționate, identificăm toți pașii de parcurs în vederea rezolvării problemei/satisfacerii nevoii/atingerii obiectivului (user journey); Dintre acești pași, îi identificăm pe aceia care implică folosirea produsului pe care dorim să îl dezvoltăm;
Pentru fiecare pas ce implica utilizarea produsului nostru, generăm idei de funcționalități care pot să abordăm nevoile/problemele/obiectivele utilizatorului, încercând să răspundem la următoarele întrebări:
Pentru emoțiile de tip trist: Ce funcționalitate ar putea conține produsul pentru a elimina frustrarea utilizatorului?
Pentru emoțiile de tip neutru: Ce funcționalitate ar putea conține produsul pentru a crește nivelul de satisfacție al utilizatorului?
Pentru emoțiile de tip fericit: Ce generează această senzație și ce funcționalități putem adăuga pentru a o genera?
Acest pas presupune definirea unei fraze clare, specifice și motivante care face transparent motivul pentru care produsul este dezvoltat și care este impactul pozitiv pe care produsul îl va genera în viitor.
Observație: Roluri precum UX/UI designer pot facilita semnificativ aplicarea conceptului de Design Thinking. Ideal, informațiile mai sus menționate sunt obținute în urma unei serii de interviuri cu potențialii utilizatori, a unor cercetări de piață mai aprofundate. În cazul în care acest lucru nu este posibil, procesul mai sus descris este doar unul imaginativ. La rândul său, cea de-a doua opțiune poate genera rezultate extraordinare, fiind, însă mai riscantă decât cazul în care informațiile sunt primite direct de la potențialii utilizatori.
Aceasta sesiune presupune alegerea, din lista de funcționalități definite anterior, a acelora care ne vor ajuta să stabilim în timp redus, dacă direcția pe care pornește produsul este una corectă. Acest lucru va avea la bază părerea clienților, precum și o serie de metrici prin care vom măsura nivelul de interacțiune al clienților cu prima variantă a produsului pe care noi îl punem la dispoziție după o perioadă scurtă de timp.
Scopul este să conturăm un produs minimalist, cât mai rapid, pentru a obține informațiile de care avem nevoie pe viitor. Acesta o să fie îmbunătățit și perfecționat în timp.
Pentru a putea alege lista de funcționalități ce vor compune MVP-ul, trebuie să avem în vedere următorii pași:
Să definim o serie de ipoteze pe care vrem să le validăm odată ce MVP-ul este pus la dispoziția clienților;
Să prioritizăm lista de personas; prioritizarea va avea drept criteriu de bază nivelul contribuției fiecărei persona în definirea ipotezelor setate anterior; ne vom întreba, astfel, care este cea mai relevantă persona în validarea ipotezelor noastre;
Alegem cele mai importante personas pe care vrem să ne axăm în construirea MVP-ului; Având în vedere faptul că vrem să construim un produs minimalist în prima etapă, nu trebuie să alegem mai mult de trei personas;
Analizăm funcționalitățile definite anterior, aferente personas alese la pasul anterior; încercăm să identificăm dacă există dependențe între acestea; dacă există, le facem vizibile;
Prioritizăm aceste funcționalități folosind tehnica Moscow;
Alegem doar funcționalitățile de tipul Must have, ținând cont de posibilele dependențe identificate anterior;
Definirea modului de lucru Agil (2 zile)
Acest lucru presupune definirea unor reguli și a unui proces de lucru de care echipa de implementare va ține cont pe viitor, pentru a lucra cât mai eficient.
Pentru aceasta, avem nevoie să definim:
Rolurile și responsabilitățile în cadrul echipei;
Metodologia de lucru pe care echipa o va folosi (ex: Scrum, Kanban);
Ședințele de sincronizare la nivel de echipă și scopul acestora;
Instrumentele de lucru folosite la nivel de proces (tools);
Regulile la nivel de echipă;
Elemente specifice celor trei concepte amintite încă de la început - Design Thinking, Lean Startup și Agile - se regăsesc în activitățile propuse la cele trei puncte mai sus menționate.
Desigur, acesta este doar un punct de plecare, ce zgârie suprafața atât la nivel teoretic, cât și practic, însă este o abordare sănătoasă și eficientă pe care aș recomanda-o oricărei echipe agile, ce își propune să dezvolte produs nou de succes, ținând cont de nevoile și dorințele clienților.
Version One, "The 11th Annual State of Agile Survey," 2017. [Online]. Available: www.stateofagile.com.
E. Ries, The Lean Startup, Currency, 2011.
K. Rubin, Essential Scrum: A practical Gude to the Most Popular Agile Process, Addison-Wesley Signature Series , 2012.
T. Brown, "Design Thinking on Harvard Business Review," June 2008. [Online]. Available: https://hbr.org/2008/06/design-thinking.
S. Gibbons, "Design Thinking 101," July 2016. [Online]. Available: https://www.nngroup.com/articles/design-thinking/.
J. Gothelf, "Agile vs Lean vs Design Thinking on Medium," 2016. [Online]. Available: https://medium.com/\@jboogie/agile-vs-lean-vs-design-thinking-2329df8ab53c.
J. Schneider, "Understanding how Design Thinking, Lean and Agile work Together," September 2017. [Online]. Available: https://www.mindtheproduct.com/2017/09/understanding-design-thinking-lean-agile-work-together/.
G. Claes, "When, which...Design Thinking, Lean, Design Sprint, Agile?," 2017. [Online]. Available: https://blog.usejournal.com/when-which-design-thinking-lean-design-sprint-agile-a4614fa778b9.
T. Roach, "How to combine Design Thinking and Agile in practice," 2015. [Online]. Available: https://medium.com/startup-study-group/how-to-combine-design-thinking-and-agile-in-practice-36c9fc75c6e6.
P. Caroli, Lean Inception, Completed on January 2018.
de Ovidiu Mățan
de Ioana Negruț
