[intervju] Kako dobro lahko napovemo prihodnost naloge, ki je pred nami?

Čas branja: 8 min
17.04.2018  13:27  Dopolnjeno: 17.04.2018 13:32
Intervju s Tadejem Accettom o agilnem delu
[intervju] Kako dobro lahko napovemo prihodnost naloge, ki je pred nami?

Več iz teme:  
Obveščaj me o novih člankih:  
Tadej Accetto dodaj
Petrol dodaj
Ryanair dodaj
Coach dodaj
Sprint dodaj

Tadej Accetto je vodja upravljanja s spremembami in zagotavljanja kakovosti v Petrolu, že vrsto let pa skozi najrazličnejše izzive živi agilne metode dela, ki so se najprej pojavile v svetu programiranja in se nato razširile na mnoga druga področja. V zadnjih letih je na ta način prispeval k uresničitvi veliko projektov, ki so se nanašali na izboljševanje uporabniške izkušnje, od malih domačih primerov do uporabniških rešitev za Ryanair.

Na prihajajoči Slovenski marketinški konferenci, ki bo 29. in 30. maja letos v Portorožu, bo udeležencem predstavil svoje izkušnje in nasvete, kako delovati, da postanemo resnično usmerjeni v kupca. Nekaj prvih namigov pa je podal že v pogovoru za Akademijo Finance.

Ste 'Agile Coach' in 'Scrum Master' v marketingu Petrola. Kakšna je torej vaša vloga in kako izgleda vaš delovni dan?

V Petrolu vodim skupino v razvoju programskih rešitev, katere primarni fokus je, kako zagotavljamo, da gradimo najbolj pomembne stvari, kako pristopamo k načrtovanju in spremljanju razvoja posameznih produktov in kako zagotavljamo njihovo kakovost. Pri svojem delu poskušamo v naše razvojne napore vpeljati čim več agilnih vrednot. Organizacijsko je skupina umeščena v oddelek za informatiko, vendar pa v svojem delu poskušamo preseči to razmejitev, saj moramo imeti za uspešen prodor na trg z novimi produkti in storitvami pred očmi vsi končnega uporabnika, naš razvoj pa mora usmerjati poslovna vrednost izdelkov.

Na SMK smo že pred dvema letoma govorili o agilnih metodah delah, ko je ta tema med udeleženci požela veliko zanimanja. Po vašem vedenju, kako razširjen je tovrsten način dela v marketingu v Sloveniji danes?

Zelo me veseli, ko vidim, da tudi v Sloveniji prednosti agilnih metodologij izkoriščamo na zelo različnih področjih, ne le v kontekstu razvoja programske opreme. Tisto, kar upam, da bomo lahko v prihodnosti še poglobili, je izmenjava izkušenj in praks med panogami. Vsaka ekipa, ki se loti agilnosti, ima po eni strani na voljo že ogromno znanja okrog sebe, po drugi pa bo naletela na izzive in našla rešitve zanje, ki jih bomo drugi z zanimanjem spremljali in se iz njih učili. Učenja in izboljšav pa seveda nikoli ni konec.

Po vaših izkušnjah, za katere tipe projektov je Scrum, ena od metod agilnega vodenja projektov, prava izbira, komu to metodo najbolj priporočate?

V osnovi gre za vprašanje, kako dobro se nam zdi, da lahko napovemo prihodnost naloge, ki je pred nami. Če nam je povsem jasno, kaj želimo narediti in kako bomo to dosegli, potem je naloga dovolj preprosta v smislu, da jo lahko vnaprej v celoti opredelimo in načrtujemo. Po izkušnjah pa dandanes večina naših nalog ni takih. Pogosto se tudi pri tistih, za katere sprva mislimo, da so enostavne, po prvih povratnih informacijah izkaže, da le ni tako.

Pogosto potrebujemo sistem, v katerem spremembe tekom izvedbe ne bodo motnja, ampak sestavni del našega vsakdana. Scrum je ogrodje za sodelovanje, ki poskuša to realnost nasloviti tako, da spodbuja realizacijo naloge v inkrementih, inkremente nalog pa razvijamo v iteracijah. Inkrementi nam omogočajo, da lahko za nalogo dobimo povratno informacijo, ali dostavljena vsebina res prinaša pričakovane rezultate, iteracije pa, da dobimo jasno sliko, kako uspešno sodelujemo pri realizaciji.

Scrum priporočam kjerkoli, kjer je za realizacijo potrebna skupina ljudi in že v začetku vemo, da se bo morala ta skupina sproti še veliko naučiti o tem, kaj proizvaja in kako.

Agilni projekti naj bi naročniku dajali možnost, da kadarkoli spremeni svoje zahteve, tudi v zaključni fazi projekta. Vanje neposvečen opazovalec bi lahko sklepal, da ima to za posledico rezultat, za katerega je pravzaprav manj časa za ustrezen razmislek, podaljševanje projekta v neskončnost in/ali precejšnjo frustracijo sodelujočih?

Pogosto se pojavlja napačna percepcija, da agilne metodologije ne poznajo ali zahtevajo načrtovanja. Načrtovanje je pomembno. Tisto, kar svet okoli nas zahteva od nas, pa je za vsak posamezen projekt resen razmislek, koliko načrtovanja je smiselno in v kakšni obliki.

Klasično projektno vodenje pozna tri omejitve, strošek, čas in obseg, ki jih pri enostavnih nalogah ali projektih zamejimo med načrtovanjem. Pri kompleksnih nalogah tak pristop pogosto pripelje do tega, da smo hitro zasuti s spremembami obsega, posledično pa se celoten sistem začne boriti proti tem spremembam. Vprašati se moramo, kaj nam je v resnici pomembno - ali želimo izpeljati projekt v roku in okviru planiranih stroškov, tudi če po poti ugotovimo, da nismo najbolje zastavili želenega rezultata, ali pa nam je bolj pomembno, da v okviru določenega časa in stroškov na trg pripeljemo maksimalen rezultat. Organizacija, načrtovanje in spremljanje enega ali drugega pristopa so bistveno drugačni.

Po mojih izkušnjah veliko frustracij izhaja iz tega, da v organizaciji implementiramo Scrum ali kako drugo agilno metodologijo, ne posvetimo pa dovolj časa in energije razumevanju in spreminjanju pristopa po celotni vertikali organizacije.

S kakšnimi morebitnimi internimi izzivi ste se pri vpeljavi agilnih metod dela že srečevali in kako ste nanje odgovorili?

Ena največjih prednosti interativnega inkrementalnega razvoja je pravzaprav nekaj, kar je lahko precej boleče, a nujno. Že ko v prvi iteraciji gradimo prvi inkrement, postane jasno, kje so največje organizacijske omejitve, ki nam stojijo na poti. Kot večkrat slišimo, Scrum v resnici ne rešuje težav organizacije, z njegovo uporabo pa postanejo naše težave boleče jasne. To je seveda gromozanska prednost, ker težave odkrijemo hitro, ko jih lahko še ustrezno rešujemo, ne na koncu projekta, ko že skoraj ne vidimo več izhoda. Ker pa so te omejitve skoraj vedno organizacijske in človeške narave, so to gotovo izzivi, ki zahtevajo veliko odkritih pogovorov, poguma, samorefleksije in sprejemanja.

Bi morda Scrum lažje posvojili, če bi ga prevedli v marketinško terminologijo? Kanban tabla, User story, Sprint, Backlog ...? In koliko bi takrat bil drugačen od 'tipičnega' projektnega dela marketinške agencije?

Tipično projektno delo je morda laže usvojljivo, ker predvideva, da je delo tipično, torej ponovljivo. Če je tako, ga lahko vsakič opravimo po enakem vzorcu, ki je sicer lahko kompliciran (ima, na primer, veliko korakov), ampak je več ali manj vedno enak. Pa je res vsak projekt marketinške agencije tipičen v tem smislu?

Terminologijo je težko prirediti, saj se za enostavnimi besedami skrivajo kompleksni koncepti - Kanban tabla ni samo tabla, ampak cel sistem upravljanja toka nalog, uporabniška zgodba ni samo oblika zapisa zahteve, ampak je z zapisovanja zahtev na pogovor o zahtevah z deležniki in tako naprej. Razmišljam pa, da je morda celo bolje, če nam nekateri izmed teh terminov zvenijo malce tuje. Koncept agilnega pristopa k razvoju produktov zahteva kar nekaj sprememb vedenjskih vzorcev, ki jih imamo posamezniki in organizacije kar globoko vsajene. Z veseljem vzamem vsako malo stvar, ki nam olajša preklopiti miselnost in spremeniti kulturo na bolje.

Sami ste na ta način že pripomogli k uresničitvi veliko različnih projektov, ki so se nanašali na izboljšanje izkušnje uporabnikov. Nam lahko skozi realen primer (projekt, ki ste ga vodili oz. na katerem ste sodelovali) in precej podrobno orišete agilno pot do rešitve?

Upam, da sem uspel v prejšnjih odgovorih že malo nakazati, kaj za mene pomeni veliko prednost agilnega razvoja. Agilisti iz izkušenj vemo, da ni absolutnega zemljevida poti, ki bi veljal za vsako ekipo, je samo skupek dobrih praks, ki nam odkrijejo, kaj so najbolj pomembne reči, ki jih moramo nasloviti, če se želimo izboljšati.

Na misel pa mi pride naslednji primer. Irsko podjetje Datalex, ki je že vrsto let razvijalo programsko opremo z 200 in več razvijalci po svetu, je prejelo naročilo za razvoj po meri, ki bi angažiralo večji del ekipe za leto in več. Dogovor s stranko je temeljil na podrobni specifikaciji želenega delovanja komponent, dogovorjenem roku in ceni. Podjetje se je iz preteklih izkušenj zavedalo, da se tekom tako kompleksnega projekta vedno pojavljajo neznanke in je izredno težko zadovoljiti vse tri parametre ter je iskalo boljši pristop k razvoju. Začeli smo z osnovnim izobraževanjem o agilnih pristopih, stilih upravljanja in tehnikah načrtovanja, vse od vodstvenega kadra (C-level) do produktnih vodij in razvojnih ekip. S produktnimi vodji smo reorganizirali specifikacije komponent v uporabniške zgodbe, kjer je bilo vodilo, da mora vsaka zgodba prinesti dokončano vrednost za uporabnike. Sestavili smo prvo “cross-functional” razvojno ekipo, torej razvojnike, ki lahko kot ekipa neodvisno pripeljejo produkt do naslednjega inkrementa, in produktnega vodjo, čigar naloga je bila kontinuirana prioritizacija zgodb. Ekipi smo dodelili dediciranega scrum masterja, da odstranjuje ovire za ekipo in jih podpira pri njihovem izboljševanju. Ko je to steklo, smo se lotili izgradnje naslednje ekipe, pri kateri je bila dodatna kompleksnost razseljenost članov po več državah. In potem še naslednje ekipe. Kar smo s temi spremembami uspeli doseči je to, da se z dostavljanjem inkrementov produkta in iskanjem povratne informacije hitro odkrijejo neznanke in se z naročnikom razrešujejo sproti, s prioritizacijo uporabniških zgodb pa smo dolgoročno zmanjševali tveganje za primer, da so bile prvotne ocene časa in stroška preveč optimistične. Ker se delo zdaj neprestano reprioritizira po trenutni percepciji poslovne vrednosti posamezne zgodbe (tako imenovani backlog), ob približevanju dogovorjenega roka ostajajo neizvedene zgodbe z najmanjšo vrednostjo. Zadovoljstvo vseh vpletenih, naročnikov, izvajalcev in uporabnikov je, ko imamo ob bližanju konca projekta vse najbolj kritične funkcionalnosti pripravljene za produkcijo, nekaj mnogo manj pomembnih pa je lahko predmet pogajanj o tem, ali lahko kako spremenimo ali izpustimo, da ujamemo rok, neprimerno večja kot pri običajnem faznem pristopu.

Na splošno lahko rečem, da je imelo zame vsako uvajanje agilnih metodologij svoje specifične izzive, saj je vsaka ekipa drugačna in vsaka organizacija drugačna. V podjetju Comtrade sem, na primer, veliko časa posvetil izvajanju Scrum delavnic za razvijalce po regiji in s tem spodbujal širjenje dobrih praks, v podjetju Ryanair sem opravljal naloge scrum masterja za eno izmed petih ekip in se ukvarjal več z iteracijami med ekipami, ki so skupaj gradile eno aplikacijo. V Petrolu pa ta trenutek veliko časa posvečamo izboljšavam, kako prioritiziramo naloge za ekipe, kako se odločamo, kaj je za skupino v tem trenutku največja poslovna vrednost, kako se za posamezen projekt odločamo, ali ga bomo peljali s pomočjo waterfall (op.ur. standarne, fazne) ali agilne metodologije.

Zelo konkretno, kako naj se direktorica marketinga, ki bo na majski konferenci razmišljala o vpeljavi agilnih metod dela, tega loti? Kaj naj bodo njeni prvi koraki in kdaj bo vedela, ali je na tej poti uspešna?

Predvsem kar pogumno in vztrajno. Prvi pokazatelj uspeha je, da se začnejo odkrivati in odstranjevati ovire, ki preprečujejo uspešno realizacijo malih inkrementov. Več težav odkrijemo in naslovimo, bolj smo uspešni pri implementaciji metodologije. Naj se ne pusti prepričati, da so težave nastale zaradi metodologije, naj bo ponosna, da vpeljuje pristop, ki jih je pomagal ujeti takoj. in da se bo lahko z njegovo pomočjo njena ekipa učila hitreje in učinkoviteje od konkurence. Predlagam tudi, da brez zadržkov povabi na kavo vsake toliko koga, ki lahko z njo deli svoje izkušnje z agilnim razvojem. Kot je, upam, razbrati iz mojih odgovorov, je zelo pomembna lastnost dobrega scrum masterja naklonjenost do servant-leadershipa, kar pomeni, da radi pomagamo.


Več iz teme: