Įsivaizduokite situaciją: esate vadovas, skrendate lėktuvu ir nerimaujate. Žinote, kad Agile yra puikus kelias, jūsų įmonė ir komanda palaiko jus. Visa komanda ką tik dalyvavo intensyvioje Agile stovykloje. Turite keturias komandas, bet dėl vienos iš jų jums vis tiek neramu. Kodėl taip jaučiatės? Na, vienas produkto šeimininkas kažkodėl nepatenkintas, kūrimo komanda nusivylusi, susierzinusi. Jaučiate, kad kažkas yra negerai. Lėktuvui nusileidus, turite priimti sprendimą. Galų gale, tai Agile problema. Taigi, jei tai Agile problema, gal verta šešioms savaitėms pasamdyti išorinius Agile konsultantus (angl. Agile coach) ir pažiūrėti, ką jie gali rasti, o galbūt net išspręsti.
Šiandien su jumis pasidalinsiu pirmosiomis keturiomis šio iššūkio, kurį priėmiau, savaitėmis. Tikiuosi, mano pasakojimas suteiks jums idėjų šešioms sesijoms, atskleis, kaip jos susijusios tarpusavyje ir kaip gali sukurti pagrindą jūsų komandos ėjimui į priekį.
Kontekstas
Atvejis susijęs su „SEB Global Services“ – viena iš kelių naudojamų CRM sistemų. Tai nėra naujas projektas. Iki man prisijungiant, jis jau buvo vystomas dvejus metus. CRM sistema irgi nebuvo kuo nors labai ypatinga. Komandą sudaro 12 žmonių – verslo padalinių Stokholme darbuotojai ir kūrimo komanda Vilniuje. Jie naudojo Scrum ir TFS įrankį produkto darbų sąrašui valdyti. Iteracijos truko 1 mėnesį. Šiuo atveju tai gerai, nes kiekvienos iteracijos pabaigoje komanda turėdavo įdiegti parengtą produkto prieaugį.
Žvelgiant iš šono, viskas atrodo gana gražiai. Agile stovykla buvo tikrai puiki. Produkto šeimininkas surenka ir pateikia klientų atsiliepimus, visi Scrum vaidmenys yra atlikti, žmonės kompetentingi atlikti savo darbą, produkto darbų sąrašas geras, iteracijos ir visa kita taip pat atrodė gražiai. Tiesą pasakius, jų turima autonomija maloniai nustebino. Kodėl jiems vis dėlto reikia samdytis išorinį Agile konsultantą?
Šiuo atveju buvo tikimasi, kad išorinis Agile konsultantas pateiks nešališką požiūrį į situaciją. Labai daug visko vyko ir įsigilinti į visa tai buvo gana sudėtinga. Taip pat buvo tikimasi išorinių praktikų – to, kas veikia kitur. Vadovas, turėjęs priimti sprendimą, ir taip turėjo daug atsakomybių ir darbų, todėl niekaip negalėjo sutelkti dėmesio tik į vieną komandą ir pats išspręsti šią situaciją.
Kelionė
Prisijungus prie naujos komandos ir pradėjus su ja dirbti, tikrai siūlau apsvarstyti galutinį tikslą. Būdamas Agile konsultantas žinote, kad keisite darbo būdą (angl. way of work). Kaip manote, kaip į tai reaguos žmonės, su kuriais dirbsite? Pasipriešinimas – tikriausiai vienas iš žodžių, kurie pirmiausia ateina jums į galvą. Iš tikrųjų gerai yra tai, kad „pasipriešinimas pokyčiams neegzistuoja – egzistuoja protinga reakcija į kvailus metodus“ (Nielsas Pflaegingas) ir į žmones, kurie, tiksliai nežinodami konteksto, ima daryti beprotiškus dalykus ir pan.
Nenorėjau daryti tų beprotiškų dalykų, todėl pradėjau nuo asmeninių (1:1) susitikimų su beveik visais dalyviais. Negaliu neigti, tai užtruko. Bet tikrai džiaugiausi taip pasielgęs. Susitikimuose stengiausi ne mokyti ar duoti konkrečius nurodymus. Jų tikslas buvo išklausyti ir išgirsti. Norėjau įsiklausyti, kas trukdo žmonėms, ir, žinoma, atsakyti į jų klausimus. Juk komandoje esate naujokas, todėl turite kaip nors prisistatyti. Taigi kalbėdami viską vizualizavome ir daug dirbome su piešimo lenta. Vienas pokalbis trukdavo nuo 1 iki 2 valandų. Nors vizualizavimas atrodė netvarkingas, vis dėlto jis leido mums įsigilinti ir išvengti vaikščiojimo ratais. Džiaugiuosi gana greitai priėjęs prie pirmosios išvados: apie Agile jie žinojo daug, todėl visai nereikėjo mokyti teorijos ar pagrindų. Dabar galiu tik įsivaizduoti, kaip būtų atrodę juokingai, jei per asmeninius susitikimus pradėčiau juos mokyti Agile.
1 sesija. Sprinto ilgis (angl. sprint length)
Per pirmąją sesiją „Sprinto ilgis“ pradėjome mesti iššūkį apribojimams. Su naujomis komandomis darau tai dažnai. Tikslas – mesti iššūkį sprinto trukmei, nesvarbu, kokia ji yra. Taigi dažniausiai užduodu klausimą „Kas trukdo sprinto trukmę sumažinti perpus?“ Ir tai itin įdomus klausimas, nes žmonės ima įsivaizduoti ir svarstyti visokius beprotiškus dalykus, kurie neveiks. Jie pateikia visus tuos dalykus lentoje ir šiek tiek juos aptariame. Nesiekiame išspręsti ko nors konkretaus. Šiuo atveju tikslas – nustatyti dalykus, kurių negalėsite pakeisti.
2 sesija. Darbo procesas (angl. way of work arba WoW)
Kitas dalykas, kurį padarėme, – pradėjome vizualizuoti darbą. Tai įprasta praktika norint suprasti, kaip juda elementai. Norėdami išvengti dominavimo (kai pora ar keli aktyvesni dalyviai savo nuomonėmis užgožia visos komandos diskusiją), pasidalijome į dvi komandas ir pabandėme tiksliai nupiešti, kaip ankstyvos stadijos elementas (pvz., idėja) juda per visus etapus, kol patenka į gamybą. Tada sutelkėme dėmesį į tai, kokie yra komandos susitikimai ar kitos Scrum ceremonijos. Siekėme išvengti klausimo, kas už ką atsakingas. Šis klausimas dažniausiai išprovokuoja vienas kito kaltinimus ir neduoda nieko gero.
Keletą kartų pakartojome šią procedūrą ir komandos pateikė savo matymą, kaip atliekamas darbas. Komandos pristatė tai viena kitai, o paskui vyko gera diskusija. Šios užduoties tikslas buvo padaryti tam tikras išvadas ir tęsti vizualizaciją. Taigi išvados buvo tokios:
· Darbo būdas yra gana standartinis ir niekuo neišsiskiriantis.
· Iššūkiai, su kuriais susidūrė komandos, taip pat buvo gana įprastiniai.
· Neaiškus „àtlikta“ apibrėžimas (nebuvo visiškai aišku, ką iš tiesų reiškia „atliktas darbas“). Ką reiškia būti viename ar kitame užduoties atlikimo etape?
· Kartais komanda painiojo traukimo ir stūmimo (angl. pull and push) taikymo atvejus. Dėl to, pavyzdžiui, analizės etape kaupėsi daugybė elementų, nes į analizę jie buvo įstumiami, o ne įtraukiami.
Taigi pradėjome dirbti su vizualizacijų lenta. Šią praktiką renkuosi dažniausiai, nes kiekvienas tai gali lengvai suprasti ir nėra sunku sukurti. Pradėjome piešti remdamiesi ankstesnės sesijos išvadomis. Paskui dar šiek tiek piešėme, kol pagaliau buvome patenkinti. Sukūrėme visą proceso srautą nuo idėjos iki gamybos. Scrum – tik dalis viso proceso. Dar kartą peržiūrėjome elementus, kad įsitikintume, ar yra tikrai taip ir ar taip veikia.
3 sesija. Apibrėžimas, kas yra „àtlikta“ (angl. definition of ready)
Prieš dedant visus elementus ant lentos, reikia susitarti dėl vieno dalyko – ką reiškia būti tam tikrame etape? (Pavyzdžiui, ką reiškia „parengtas kurti“? Ar reikia turėti priėmimo kriterijus? Ar reikia maketų? Ar užtenka aprašytos vartotojo istorijos?)
Ši sesija buvo labai įdomi ne todėl, kad dėl ko nors susitarėme. Turėjome tikslą pradėti kalbėti apie tai, kokie iš tikrųjų yra lūkesčiai (pavyzdžiui, „Ko aš, kaip kūrėjas, tikiuosi iš verslo analitiko?“, „Ko aš, kaip verslo analitikas, tikiuosi iš produkto šeimininko?“).
Ir iš tikrųjų, komandos nariams pradėjus atvirai dėstyti savo lūkesčius, išvados buvo gana įdomios. Rengdami tokią sesiją, nepamirškite kelių dalykų:
1. Reikia laiko. Kartais užtrunka iki 4–6 valandų, todėl galima dalinti į kelias dienas.
2. Norite sužinoti, kokia iš tikrųjų šiuo metu yra padėtis, o ne kažką įteigti. Tai bus kitos sesijos pagrindas.
4 sesija. Būsenų žemėlapio kūrimas (angl. map the state)
Kitas žingsnis – būsenų žemėlapio kūrimas. Šioje sesijoje tiesiogine to žodžio prasme imama viskas, kas yra produkto darbų sąraše, ir dedama ant lentos. Tai darant svarbu laikytis sutartų apibrėžimų. Jei susitarėte, kad produkto elementas yra parengtas vystyti tada, kai turite jo maketus ir priėmimo kriterijus, o jų dar neturite, turite grįžti į analizės etapą. Jokių išimčių, jokių pasiteisinimų. Taip iš karto sužinojome, kad analizė buvo butelio kakliukas ir ten susikaupdavo daugybė užduočių (dirbo vienas žmogus). Taip pat buvo kliūčių dėl išorinių tiekėjų.
Po šios sesijos buvome pasirengę imtis pokyčių. Ar tikrai jų reikia? Prieš imantis pokyčių, reikia apsvarstyti, kokie yra lūkesčiai:
· Ką iš tikrųjų kuriame?
· Kas yra pagrindiniai vartotojai?
· Koks yra priimtinas kūrimo laikas? (Šis klausimas užkerta kelią daugeliui nereikalingų diskusijų, todėl rekomenduoju to paklausti.)
Manau, kad šie klausimai yra tuo vertingesni, kuo konkretesni atsakymai.
Ir ką gi supratome? Verslo požiūriu kuriame lėktuvo pilotų kabiną – vietą, kurioje galite viską pamatyti ir lengvai pakeisti. Nors tai tikrai puiki vizija, kūrimo komandai nėra labai prasminga sakyti: „Prašau, sukurkite tai.“ Tai tiesiog neveikia, nes pernelyg abstraktu.
5 sesija. Istorijų žemėlapio sudarymas (angl. story mapping)
Vartotojų istorijų žemėlapio sudarymas yra senas geras būdas įsivaizduoti produkto darbų sąrašą dėliojant ant sienos. Aukščiausias lygmuo (angl. epic) – dideli darbai, kuriuos reikia atlikti. Tada jie skaidomi į mažesnes užduotis. Ir čia pradedame taikyti pagrindinio vartotojo darbo srauto analizę.
6 sesija. Pagrindinio vartotojo darbo srautas (angl. main user workflow)
Pradėję šią sesiją, turėjome 30 vartotojų tipų, taigi nežinia kiek dar atvaizdavimo ekrane variantų būtų reikėję sukurti. Pradėję segmentuoti vartotojus, supratome, kad yra daugiausia 4 vartotojų tipai, nors iš tiesų dėmesį reikia sutelkti į vieną. Supratome, kad dauguma vartotojų naudoja tik 7 skirtingus ekranus, o vieno tipo vartotojai – dar mažiau. Nors ši informacija pati savaime gali neatrodyti naudinga, bet čia ir buvo gudrybė: sujungę pagrindinių vartotojų darbo srautą su vartotojų istorijų žemėlapiu, gaunate daug įdomesnį vaizdą kalbėtis su visa kūrimo komanda. Taigi, subendrinus šias lentas, iš karto buvo akivaizdu, kad per artimiausius 2–3 mėnesius mums pirmiausiai reikia kurti vieną ekraną, o paskui labai ilgai dirbti su kitu. Dabar užuot blaškęsi tarp visų naudotojų ir ekranų, galėjome susikaupti ir sutelkti savo pastangas vienam aiškiam darbui.
Apibendrinimas
Turėdami tokią informaciją, tarpusavyje susiderinome ir tapome pasirengę tobulėti. Susitarėme dėl Scrum taikymo, būsenų, butelio kakliukų, tikslo. Šiame procese dalyvavo ir bendro tikslo pasiekė visi: kūrimo komanda, produkto šeimininkas, verslo analitikai, vadovai. Būtent tai leido priimti gana akivaizdžius sprendimus:
· Daugiau dėmesio skirti išoriniams tiekėjams.
· Sukurti antrojo lygmens klientų palaikymą, nes komanda turi daug trikdžių.
· Pasamdyti papildomą programuotoją, nes lūkesčiai yra daug didesni nei turimi pajėgumai.
· Palaikyti skaidrumo politiką.
· Investuoti į automatizavimą.
· Pradėti naudoti internetinius įrankius ir pan.
Žvelgdamas į visą nueitą kelią ir patirtis, rekomenduoju:
· Pradėkite galvodami apie pabaigą.
· Konstruktyviai ir pagarbiai meskite iššūkį esamiems apribojimams.
· Vizualizuokite darbo būdą. Tikrai norite, kad visi pamatytų, kas vyksta.
· Atskleiskite tikrąją padėtį: ne tai, kuo žmonės tiki, bet tai, kas iš tikrųjų yra tiesa.
· Galvokite apie verslą. Niekada jo nepamirškite. Tai dažna ir gana brangi klaida.
· Veikite – tobulėkite.
Grįžkime prie vadovo situacijos, kurią įsivaizdavome pradžioje. Dabar jis gali jaustis orlaivio pilotu, o ne keleiviu. Agile konsultantas yra jo šturmanas.
Danil Michailovas. „Agile Turas 2018“ pristatymas anglų kalba „Agile coaching – case study. Chapter 1“. Visą pristatymą galite peržiūrėti čia: https://youtu.be/Wzbe4KMCysc
Daugiau informacijos apie Agile konsultacijas galite rasti čia: https://www.agilecoach.lt/konsultacijos