Design Thinking, Scrum i MVP su teorije, no kako zapravo napraviti nešto onako… dobro?

Zapravo trebamo težiti napraviti, u ne previše vremena, nešto što je dovoljno upotrebljivo,  time i prepoznato kao korisno, istovremeno ne kompromitirajući da smo korisniku dali zaokruženu i potpuno funkcionalnu cjelinu.

U praksi smo ipak limitirani prioritetom koji rezultiraju kompromisima. Iz svog iskustva rada u RBA ću vam dati dva praktična primjera:

• Prvi je novo mobilno bankarstvo mojaRBA za koju smo se pripremili i trenirali agilni pristup. Najviši prioritet je bio kvaliteta;
• Drugi primjer je mala aplikacije za zadavanje zahtjeva za odgodu plaćanja kredita za one pogođene pandemijom, a koja je nastala pod pritiskom vrlo kratkog roka koji je bio u ovom slučaju prioritet pa smo ju dosta pojednostavili u provedbi.

Unatoč razlikama, zajedničko je da su nastale na sličnom principu!

Što bi prva verzija trebala sadržavati, a što možemo odgoditi?

Korisnik. Što bi mogao smatrati vrijednim?

Počinjemo tako da okupimo tim – ljude različitih profila i bacamo ideje što bi naša aplikacija trebala imati. Na početku nema zabranjenih ideja pa tu bude svega i ono što ima smisla i ono što ima manje smisla. Gleda se što bi korisnik mogao poželjeti, iako zapravo u tom trenu ne znamo da li je uopće izvedivo niti s koliko napora. Slijedi odbacivanje ili odgađanje svega što traži previše vremena, a istovremeno ne bi prezentiralo veliku vrijednost za samog korisnika.

Bitno je ocijeniti vrijednost funkcionalnosti za korisnika s jedne strane te napor da se to izvede s druge. Pri tomu mi se pokazalo dobro koristiti mišljenje cijelog tima, koje uglavnom daje bolju procjenu od pojedinačnog. (U ovom trenutku svakako ostavite mjesta za proučavanje metoda i tehnologija koje još niste koristili, iako su u tom trenu nezahvalne za procjenu – no čine se dobrim kandidatima.)

Za nas se dobro pokazalo da uzmemo manju cjelinu, no da je dostatno pokrijemo. Ne bi se trebalo raditi o cijeloj funkcionalnosti aplikacije, ali ne bi smjela ni biti žrtva pojednostavljivanja.

Ako smo uspjeli dobro procijeniti što će korisnika ugodno iznenaditi, ali i bez čega može živjeti, na dobrom smo putu. Zvuči jednostavno, no u praksi se tijekom raspisivanja detalja zna odlutati u previše sitnica. Dobra je metoda uzeti u obzir i završne procjene izvedbe te srezati detalje koji traže više vremena – a daju malo koristi.

Prototip aplikacije doista pomaže, jer većina nas treba vizualni doživljaj pa tako dobivamo vrijedne prve reakcije stvarnih korisnika. Pazite! Tim je do tog trena napravio što je mislio da je najbolje – pa treba znati prihvatiti drugačije mišljenje i shvatiti da stvari ipak treba korigirati. (No tomu prototip i služi.)

Ako to korisnik ne vidi – ne treba nam? Ili je ipak neophodno?

Prethodni korak se više bavi izvedivošću ideja koje se smatraju dobrima. U tom pojednostavljenom postupku se krije opasnost da neke stvari budu potisnute kao sporedne, iako bez njih ne možemo prema našim korisnicima. Naravno da se znatno razlikuje ovisno o aplikaciji koju radimo pa ćemo ovdje govoriti o aplikacijama koju će koristiti preko nekoliko stotina ili tisuća korisnika, te iza koje stoji neka organizacija, u mom slučaju banka.

Znamo dobro da je prva na listi takvih stvari – sigurnost. Istovremeno želimo čim jednostavnije korištenje no istovremeno i dovoljno sigurne aplikacije, jer sigurnosni propust osim što utječe na korisnika ili nas, može posredno napraviti i znatno veću štetu rušenjem naše reputacije.

Sljedeće u toj kategoriji je robusnost aplikacije i mogućnost praćenja njezinog rada. Vaš korisnik očekuje da u svakom trenu aplikacija radi podjednako dobro, a nama to znači da moramo kontinuirano pratiti rad te reagirati na poteškoće. Prije izbacivanja aplikacije testove funkcionalnosti uvijek nekako napravimo, no nekad bi preskočili one druge – poput sigurnosnih i performansnih.

U “živom radu” praćenje što se zbiva, a posebno statistika grešaka i vrijeme odziva su vrlo bitni, a posebno ako većinu popravaka možemo prepustiti automatici. Korisniku je razumljivo da poteškoće uvijek postoje, no time nismo kupili njegovu strpljivost.

Zanimljivo je da korisnike više smeta veći broj sitnih nepravilnosti nego nekoliko većih (a koje se uvijek brzo prepoznaju i isprave) pa i kod provjere kvalitete treba provjeravati čim više detalja.

Dva potpuno različita primjera iz stvarnosti

Nekako najlakše učimo iz vlastitog iskustva. Prva verzija RBA Internetskog bankarstva bila je u produkciji za 7 mjeseci. To je bilo 2000. godine, ujedno prvo Internetsko bankarstvo u Hrvatskoj. Doba u koje sam prije toga koristio ZABA Telebanking kućno bankarstvo dostupno preko modema. Mogućnosti nije bilo previše, no niti tržište nije tražilo više u to doba. Cilj je tada više bio nagovoriti korisnike da prepoznaju prednosti ovog kanala i biti prvi je bilo dosta značajno.

Sjećam se da sam nakon nekoliko mjeseci ispisao na zid imena svih 2 tisuće korisnika te aplikacije. Ne, nije bilo GDPR-a, no pomoglo mi je da me podsjeća za koga kontinuirano poboljšavamo aplikaciju.

Za drugu generaciju, godinama kasnije, trebalo je znatno više (i ljudi i vremena). Želja je bila imati sve što i prethodna verzija, ali dodatno i puno više i jednostavnije. Smatrali smo to ispravnom odlukom i realizirali sve kao klasičan projekt. Zlatno doba waterfall projekata. No trajalo je duže nego što smo htjeli, jer korisniku nismo htjeli oduzeti čak ni sporednu funkcionalnost koju je imao, bez obzira koliko je bilo upitno je li neophodna za prvu verziju.

Nedavno je pak došlo vrijeme i za treću generaciju.

Prepoznat je problem opsega, koji u kombinaciji s brojnim tehnologijama koje smo planirali iskoristiti, ne bi ugledao svjetlo dana tako skoro da je pristup bio isti. Tako je s aplikacijom mojaRBA (novo mobilno bankarstvo) cilj bilo dati korisniku nešto bolje, no ne nužno kompletno od prvog dana.

Friends and family (Ili – friends, but not family)

Godinu dana od produkcije za prve korisnike, a neke funkcionalnosti su još bile na popisu za napraviti.

U ranoj fazi dovršenosti bitno je omogućiti prvim korisnicima upotrebu aplikacije u produkciji. Posebno ako se sami prijave da žele koristiti i dati osvrt na što vide. Osobno sam koristio princip friends but not family, no to je više stvar osobnog odabira. Najbitnije je da im omogućite slanje zapažanja te da ih ne razočarate kvalitetom. Povratne informacije su bitne jer spomenuti tim gore je tada bio prilično uvjeren da pogađa cilj, a sada ga brutalna stvarnost podsjeća da ima prostora za poboljšanje i ponovnu prioritizaciju.

Općenito, uspijete li postupno migrirati svoje korisnike umjesto big bang principa, unatoč cijeni – svi će izaći sretniji. Na manjem broju korisnika prepoznaju se njihove stvarne želje i potrebe i stignemo korigirati prije iduće grupe koja je već u startu zadovoljnija.

Naravno da postupna migracija ima svoju cijenu, jer u istom periodu se preklapaju i stara i nova aplikacija, a to traži i više razvoja i više truda na održavanju. Trebate riješiti da ostale povezane aplikacije rade istovremeno i međusobno unatoč promjenama koje ste radili zbog poboljšanja nove aplikacije. A što se tiče korisnika, njihova očekivanja su jasna – žele što bezbolniji prelazak. Big bang princip je radi niže cijene često izazovan, no kad god si možete priuštiti alternativu postupnom migracijom – iskoristite priliku.

Koliko imamo vremena za izradu aplikacije? Koliko nam je dano!

Drugi primjer je još zanimljiviji. Pogođeni pandemijom prešli smo na rad od kuće. Ne vidimo se, ne nalazimo se uživo, već se pitamo možemo li uopće biti efikasni preko Microsoft Teams sastanaka.

S druge strane, preko noći se pojavila potreba za izradom aplikacije koja će omogućiti klijentima da bez dolaska u poslovnicu zatraže odgodu plaćanja kredita. Vrijeme izrade je bilo svega nekoliko dana. Zahtjevi su se tek smišljali i nije bilo vremena čekati da budu dovršeni. Napravljena je lista najnužnijeg i lista poželjnih stvari – takve nisu smjele biti prepreka dogovorenim rokovima.

Spomenuti “nevidljivi” zahtjevi (sigurnost, monitoriranje aplikacije i robusnost) nisu stavljeni u drugi plan. Produkcija je ostvarena na vrijeme, s urednim rezultatom funkcionalnog, penetracijskog i performansnog testiranja i dostatnim monitoringom, a koji je i poboljšan tijekom prvih dana produkcije.

No, zanimljivo je spomenuti što se dogodilo nekoliko dana prije produkcije. To je period u kojem se iznimno radi puno više sati dnevno. Naime, želimo korisnicima dati aplikaciju koja je jednostavna i jasna za korištenje. U zadnji smo tren optimizirali korištenje te smo odgovarajući na potrebe korisnika vrlo brzo implementirali korisniku prilagođene pojmove. Tako je s relativno malo napora, primjerice “Zahtjev za moratorij”, postao korisniku razumljiviji “Zahtjev za odgodu otplate kredita”. Pazili smo da su tekstovi prilagođeni ne samo da ih korisnik shvati već da i koristimo odgovarajući rod korisnika (a imamo pokrivena sva tri)!

Pojmovi koje smo htjeli izbjeći u ovom tekstu. S razlogom.

U praksi, kao i većina ovih dana, i mi koristimo Design thinking, persone, ideaciju da bi napravili backlog – svojevrstan grubo sortirani popis želja. Product Owner, kao osoba koja se smatra odgovornim vlasnikom aplikacije, prioritizira te želje, a arhitekti smisle kako pristupiti zahtjevnijim željama.

Developeri, pritisnuti kratkim sprintovima, uz pomoć svojih Scrum Mastera, moraju to realizirati. A u pozadini ekipa za infrastrukturu, testeri i svi ostali rade na onom nevidljivom, a posebno na automatizaciji i monitoriranju rada kako bi korisnici nesmetano koristili ono što smo im i pružili. Sve to pokušavamo sa što manjim troškovima, a time i znatnom zastupljenošću open source rješenja, novih tehnologija koje daju dovoljne performanse i robusnost.

Tim živi koliko dugo koliko i zainteresirana publika

Cijeli taj stroj bi se ugasio da na početku nismo dobro ocijenili – što bi to korisnik trebao i do kada. Do jučer smo radili projekt koji bi pokušao dovršiti aplikaciju prije nego ugleda svjetlo dana, no danas je jasno da je to kontinuirani rad i isto je ostvareno kroz timove koji neprestano poboljšavaju rješenja za koja su odgovorni, no znatno češće i u manjim paketima isporučuju nove stvari.

Ako pak ne uspiju – proizvod umire, radi toga i sam tim – kojem preostaje da pronađe novu ideju i bolje pazi da ne ponovi grešku. O tomu i pričamo.

Isplati li se sav taj trud

S jedne strane pitamo se – vidi li to netko? No, opet smo svjesni da svi nekako prije uočimo loše stvari, a ono dobro baš i ne. Iskreno, koristilo mi je tih dana maknuti misli od činjenice da smo doma zatvoreni radi COVID-a. No za par dana dogodila se pozitivna reakcija korisnika:

“…Toliko brzo profesionalno i jednostavno da sam oduševljena. Oduvijek volim tu svoju banku, ali sad ju obožavam.”

Odmah sam shvatio: To su plodovi našeg rada. Da, ipak su vidjeli razliku, ne shvaćajući da je taj dio napravljen s određenim rizikom kad mijenjate aplikaciju doslovno 10 minuta prije produkcije.

Ovaj primjer ponovno dokazuje činjenicu da gotovo svaku aplikaciju možete napraviti za vrijeme koje vam je dano na raspolaganje. Razliku više čini prepoznavanje najbitnijeg i pametno odbacivanje svih tereta koji stoje na putu do isporuke u zadanom roku.

Na kraju krajeva, niti Facebooka, a niti YouTubea ne bi danas bilo, da njihovi autori nisu implementirali ono što je danas smatramo kao – manji no atraktivniji dio funkcionalnosti – a na čijim krilima je porasla potreba korisnika, pa se i dalje neprestano poboljšavaju. Jer imaju za koga.