Šiuolaikinės organizacijos, siekdamos būti konkurencingomis savo rinkoje ir įgyti didesnį konkurencinį pranašumą, nuolat tobulina teikiamų paslaugų / produktų kokybę. Į šį procesą įsitraukia skirtingi įmonės darbuotojai: produktų vadovai, operacijų ir IT padalinių darbuotojai. Tobulinant produktus dažnai susiduriama su problema, kad verslo atstovai negeba konkrečiai išsakyti savo poreikių IT atstovams, tad yra sukuriami lūkesčių neatitinkantys produktai. Šiai problemai spręsti organizacijos pokyčių projektus pradeda įgyvendinti remiantis Agile, o spragų tarp IT ir verslo atstovų mažinimui samdo verslo analitikus, kuriuos neretai galima sutikti kaip procesų analitikus, verslo architektus, duomenų analitikus, produktų vadovus ir t.t. (Pratt, White, 2019). Taigi kyla klausimas, kokį vaidmenį atlieka verslo analitikas (toliau tekste – BA), dirbdamas Agile principais?

Tradicinėje verslo analizėje BA, remiantis verslo analizės žinynu BABOK, yra apibrėžiamas kaip asmuo „atliekantis verslo analizę <…>, atsakingas už informacijos iš įvairių šaltinių, įskaitant įrankius, procesus, dokumentus ir suinteresuotąsias šalis, atradimą, sintezę ir analizę.“ (BABOK, 2015). Verslo analizės metu yra nustatomi vertę organizacijai kuriantys suinteresuotųjų šalių poreikiai ir inicijuojami pokyčių projektai. Taigi BA identifikuoja verslo problemas ir tikslus, analizuoja poreikius ir siūlo galimus sprendimus, kuria strategijas, specifikuoja reikalavimus, inicijuoja pokyčius ir padeda suinteresuotosioms šalims bendradarbiauti (BABOK, 2015).

Photo by Bonneval Sebastien on Unsplash

Analizuojant Agile pastebėta, kad joje nėra išskiriama atskira BA pozicija. Pasak I. Pavlichenko (2018) ir A. Mersino (2018), Agile, o konkrečiau Scrum, apibrėžia tik 3 roles: produkto savininko (toliau tekste – PO), Scrum master ir vystymo komandos. Autorių teigimu, Agile atsisako rolių tam, kad eliminuotų galimybę atsirasti butelio kakliukui (žmogiškųjų išteklių kontekste) ir paskatintų komandą ieškoti sprendimų siekiant bendro tikslo. Tačiau nepaisant to, kad Agile BA, kaip atskira, rolė neegzistuoja, verslo analizės veiklos yra įgyvendinamos. BA Agile sutinkamas 4 perspektyvose:

• BA kaip PO;
• BA kaip vystymo komandos narys;
• BA kaip PO asistentas;
• BA kaip verslo treneris.

BA kaip PO. Scaled Agile Framework PO apibrėžia, kaip Agile komandos narį, atsakingą už vartotojo istorijų (angl. user stories) rašymą, komandos darbų (angl. backlog) prioretizavimą, iteracijų planavimą, bendradarbiavimą su Agile komanda ir produkto suinteresuotomis šalimis, sprendimų priėmimą, priėmimo kriterijų ir vartotojų testų įvertinimą (SAFe, 2020). D. Yurevich (2019) teigia, kad PO turi užtikrinti, kad reikalavimais virtę suinteresuotųjų šalių poreikiai sukurtų produktui maksimalią vertę ir atitiktų produkto viziją. R. Stewart (2018), S. Kumar (2020) nuomone, BA gali tapti PO ir tai yra viena iš karjeros galimybių BA, nes jis geba identifikuoti poreikius, formuluoti reikalavimus, bendradarbiauti su suinteresuotomis šalimis. Tačiau autoriai pastebi, kad tampant PO, BA gali susidurti su sunkumais: PO ne tik identifikuoja poreikius, specifikuoja reikalavimus, bet ir nubrėžia produkto viziją, priima sprendimus, kurie turėtų būti nukreipti į produkto vertės kūrimą ir jos didinimą. Teigiama, kad didžiausia problema BA tampant PO yra ta, jog BA ir toliau gali likti tik reikalavimų surinkėju, nors, kaip pastebėjo minėti autoriai, turėtų kurti produkto strategiją, bendradarbiaujant su suinteresuotomis šalimis gebėti argumentuoti savo poziciją / sprendimus, orientuotus į produkto vertės kūrimą.

BA kaip vystymo komandos narys. A. Mersino, SoftwareTestingHelp (2020) teigia, kad geriausiu Agile filosofijoje BA vaidmeniu yra įvardinamas jo buvimas vienu iš vystymo komandos narių. Tokiu būdu Agile komanda gali paprastai ir patogiai BA užduoti klausimus, susijusius su atliekamais darbais. Žvelgiant iš BA perspektyvos, jis gali identifikuoti atvejus, kai reikalavimai yra nutylėti arba jų realizavimui trūksta duomenų; numatyti, kaip diegiami atnaujinimai gali paveikti kitas sistemas ar pan. SoftwareTestingHelp išskiria tai, kad PO ne visada geba taisyklingai ir aiškiai surašyti / prioretizuoti vartotojų istorijas, tad vystymo komandoje esantis BA gali, besitikslindamas su PO ir / arba suinteresuotomis šalimis, tinkamai pakoreguoti vartotojų istorijas / priėmimo kriterijus. Taip pat pabrėžiama, kad vystytojų komandoje yra rekomenduojama turėti bent vieną narį, atitinkantį BA vaidmenį. Be to, S. Kumar pažymi, kad vystytojų komanda, tai viso labo Scrum rolės pavadinimas, kuris nereiškia, jog toje komandoje dirbantys asmenys yra programuotojai.

BA kaip PO asistentas. Kaip jau buvo pastebėta, BA neturi sprendimo priėmimo teisės. K. J. Mcdonald (2016) akcentuoja, kad dirbdami kartu BA ir PO gali sukurti puikią produkto viziją. BA padeda PO nustatyti, ar suinteresuotųjų šalių reikalavimai yra naudingi ne tik projekto įgyvendinimo laikotarpiui. Atlikęs verslo analizę, BA iš gautų duomenų (verslo taisyklių, procesų ir t.t.) padeda PO detalizuoti vartotojų istorijas ir suformuoti reikalavimus, kuriuos realizavus produktui bus sukurtas vertę kuriantis funkcionalumas. U. Eriksson (2017) teigimu, BA taip pat parengia ir detalizuoja priėmimo kriterijus vartotojų istorijoms. K. J. Mcdonald ir Eriksson pažymi, kad BA talkina PO skaidant darbų sąrašą į mažesnes dalis – tokiu būdu yra detalizuojami ir prioretizuojami darbai, nustatant, kurių sprinto apimtyje bus realizuojami suinteresuotųjų šalių reikalavimai. R. Pichler (2010) išryškina, kad BA kaip PO asistento vaidmuo dažnai pasireiškia tuo atveju, kai PO yra paskiriamas skyriaus vadovas, tačiau jam trūksta analitinių ir darbų prioretizavimo gebėjimų.

BA kaip ekspertas. K. J. Mcdonald BA Agile filosofijoje įvardina ne tik kaip PO, bet ir kaip verslo trenerį. Autoriaus teigimu, iteracijų metu BA sąveikauja su komanda: padeda bendradarbiauti su suinteresuotomis šalimis (nukreipia komandos narius į tikslingus asmenis, kuriems skirtas klausimas), šalims bendradarbiaujant perima vertėjo rolę, t.y. Agile komandai kalba technine kalba, o suinteresuotoms šalims – verslo kalba. Tokiu būdu BA padeda užtikrinti, kad visi dirbtų dėl vieno bendro tikslo. Be to, BA įgyvendinamą pokyčio projektą mato visos organizacijos strategijos kontekste, tad gali Agile principais dirbančiai komandai perduoti naudingų žinių, susijusių su vertės kūrimu produktui. K. J. Mcdonald teigia, kad geriausias būdas dalintis žiniomis su komanda – įtraukti komandos narius į verslo analizės ir darbų sąrašo sudarymo procesą. Tačiau jeigu tokios galimybės nėra, autorius siūlo šią informaciją patalpinti viešai prieinamoje vietoje. Galima teigti, kad minėtos informacijos viešinimui yra tinkami šie Atlassian įrankiai: Jira ir Confluence. Taip pat galima paminėti ir tai, kad K. J Mcdonald nuomone, BA gauna galimybę padėti Agile komandos nariams ir susidarius butelio kakliukui padėti jį panaikinti (atliekant numatytus darbus).

Taigi apibendrinant galima teigti, kad BA, dirbdamas Agile pagrindais, atlieka skirtingą vaidmenį. BA gali būti įvardinamas PO, PO asistentu, vystytojų komandos nariu, savarankišku ekspertu. Remiantis SoftwareTestingHelp pateikiama informacija, formuojamos šios galimos BA atsakomybės Agile filosofijoje:

• PO paliepimu prižiūrimas ir prioretizuojamas komandos darbų sąrašas;
• Analizuojami suinteresuotųjų šalių poreikiai ir jiems realizuoti skirti sprendimo būdai;
• Jei vartotojų istorijos buvo suformuotos PO, tai BA turi jas peržiūrėti ir užtikrinti, kad yra atsižvelgiama į poreikius ir verslo taisyklės, o suformuluoti priėmimo kriterijai atitinka aprašytus reikalavimus;
• Dirbant su PO ir suinteresuotomis šalimis suprasti reikalavimų apimtį ir pasiūlyti jiems galimų patobulinimų;
• Pagal poreikį parengti verslo analizės dokumentus.

Photo by Clark Tibbs on Unsplash