„Jira“ diegimas finansinių technologijų įmonės verslo plėtros ir pagalbos komandose: „Bondora“ istorija

2023 m. rudens pradžioje užbaigėme „Jira“ diegimo projektą įmonėje „Bondora“. Diegiant naują įrankį teko įveikti du lygiagrečius iššūkius – perkelti finansinių technologijų įmonės 15 metų istorinius duomenis iš „Asana“ į „Jira“ ir užtikrinti kuo sklandesnį komandų perėjimą iš vienos platformos į kitą.

Šiame straipsnyje apžvelgsime diegimo procesą, įvairius reikalavimus ir techninius sprendimus bei komandų iki šiol sukauptą darbo su „Jira“ patirtį.

Apie „Bondora“

2008 m., pasaulinės finansų krizės įkarštyje, studentų bendrabučio kambaryje buvo įkurta "Bondora"  (opens in a new tab) turint vieną aiškų tikslą – padėti žmonėms, kuriems bankai nesuteikė reikiamos pagalbos. „Bondora“ misija – suteikti žmonėms galimybę gyventi savo svajonių gyvenimą nesijaudinant dėl pinigų.

Kodėl „Bondora“ pasirinko „Jira“?

Kaip ir „Jira“, „Asana“ yra projektų ir darbų valdymo programinė įranga, skirta užduotims planuoti, stebėti ir valdyti. Nors „Jira Software“ iš pradžių buvo sukurta būtent programinės įrangos kūrimui, dėl savo universalumo ji gali būti naudojama įvairiems procesams valdyti.

Keletas svarbiausių „Jira Software“ pranašumų, palyginti su „Asana“:

• Lanksčios konfigūravimo galimybės darbo eigoms, užduočių tipams, laukams, rodiniams ir prieigos teisėms;
• „Scrum“ metodikos palaikymas, įskaitant sprintus, darbų sąrašą (backlog) ir sprintų ataskaitas;
• Plačios integravimo galimybės;
• Speciali užklausų kalba „Jira Query Language“ (JQL) užduotims ieškoti;
• „Advanced Roadmaps“ projektų portfeliui valdyti.

Kadangi „Bondora“ taip pat užsiima programinės įrangos kūrimu, sprendimui pasirinkti „Jira“ didelės įtakos turėjo galimybė integruoti ją su „Azure DevOps“. „Asana“ tokios integracijos galimybės nesuteikė.

Programinės įrangos kūrimo komandos vadovas Aleksandr Knjazetski pabrėžė, kad sprendimą pereiti prie „Jira“ lėmė jos pritaikomos funkcijos, kurias galima konfigūruoti pagal konkrečius procesus ir reikalavimus.

Diegimas komandose

Iš pradžių „Bondora“ savarankiškai pradėjo diegti „Jira“, pirmiausia programinės įrangos kūrimo komandose. Ši užduotis buvo gana nesudėtinga, nes dalis šių komandų specialistų jau turėjo darbo su „Jira Software“ patirties.

„Su kitomis komandomis susidūrėme su sunkumais, nes jos nebuvo susipažinusios su „Jira“ funkcijomis, skirtomis konkretiems procesams palaikyti. Todėl nusprendėme pasitelkti ekspertus, kurie padėtų perkelti kitas komandas į „Jira“ ir pasidalytų žiniomis apie jos funkcijas bei administravimo patirtimi“, – aiškina Aleksandr, vadovavęs diegimo projektui iš „Bondora“ pusės.

Kartu tęsėme „Jira“ diegimą personalo valdymo, rinkodaros, rizikos valdymo, verslo plėtros ir finansų skyrių komandose. Komandų perėjimą suskirstėme į tris pagrindinius etapus:

• Pradinės informacijos rinkimas – susipažinimas su esamais darbo procesais, „Asana“ projektų ir lentų analizė, reikalavimų dokumentavimas;
• „Jira“ projekto konfigūravimas;
• Sprendimų patikrinimas ir, prireikus, papildomų pakeitimų atlikimas.

Duomenų perkėlimas iš „Asana“ į „Jira“ vyko lygiagrečiai su minėtais etapais. „Bondora“ migraciją atliko savarankiškai. Daugiau informacijos apie perkėlimo ypatumus ir įgytas pamokas rasite Aleksandr tinklaraščio įraše  (opens in a new tab).

Kiekvienai komandai sukūrėme atskirus „Confluence“ puslapius, kuriuose dokumentavome reikalavimus laukams, užduočių tipams, darbo eigoms, prieigos teisėms ir pranešimams.

Reikalavimų dokumentavimo šablonas, komentarai tiesiog tekste ir naudotojų paminėjimai naudojant @ simbolį leido patikslinti detales tiesiogiai atitinkamame kontekste. Greitam bendravimui ir planavimui taip pat naudojome „Slack“ kanalus.

Automatizavimo taisyklės, užduočių lygmens saugumas ir naudotojų patirties ypatumai

Keliose komandose reikėjo tiksliai apriboti prieigos teises, todėl įdiegėme užduočių saugumo schemą (Issue Security Scheme). Ji apima saugumo lygius, pagal kuriuos prieigos prie užduočių teisės nustatomos atsižvelgiant į „Jira“ grupę, vaidmenį arba konkretų naudotoją (nerekomenduojame teisių nustatyti atskiriems naudotojams).

Konkretų užduoties saugumo lygį galima pasirinkti rankiniu būdu arba automatiškai. Pavyzdžiui, naudodami „Jira“ automatizavimą, „Office“ projekte įdiegėme automatinį saugumo lygių priskyrimą įrangos užsakymams.

Vienas iš reikalavimų buvo suteikti visiems įmonės darbuotojams teisę kurti užduotis „Office“ projekte. Tačiau galimybė peržiūrėti kolegų sukurtas užduotis turėjo būti apribota.

Geriausias sprendimas buvo automatizavimo taisyklė, kuri automatiškai priskirdavo saugumo lygį naujai sukurtai užduočiai. Kad užduotys nebūtų matomos visai komandai, saugumo lygyje nustatėme prieigą tik „Reporter“ vaidmeniui (užduoties pateikėjui) ir „Office“ komandos grupei.

Automatizavimas supaprastino procesą, nes užduoties kūrėjui nebereikėjo rankiniu būdu pasirinkti saugumo lygio.

Prioritetinių užduočių valdymas lentos rodinyje

Įvairiuose projektuose įdiegėme skirtingiems tikslams skirtas automatizavimo taisykles, tačiau pagrindinis tikslas išliko efektyvus užduočių valdymas.

Pavyzdžiui, verslo plėtros komandoje (Expansion) automatizavimą panaudojome tam, kad užduotis automatiškai pereitų iš „Backlog“ būsenos į „To do“, jei jos lauke „Due date“ (Atlikimo terminas) nurodyta data yra per artimiausias 30 dienų. Taip užduotis iš atskiro „Backlog“ rodinio perkeliama į „Kanban“ lentą, kuri yra pagrindinė užduočių valdymo sąsaja.

Taip pat reikėjo užtikrinti galimybę greitai ir lengvai atskirti prioritetines užduotis lentos rodinyje.

Buvo nustatytas reikalavimas, kad užduotys, kurių atlikimo terminas yra per artimiausias septynias dienas, „Jira“ lentoje būtų rodomos geltona spalva, o užduotys, kurių atlikimo terminas jau praėjo, – raudona. Šią spalvų logiką įgyvendinome lentos nustatymuose, naudodami JQL užklausas.

1 pav. „Kanban“ lentos su skirtingų spalvų kortelėmis pavyzdys.

Masinis užduočių klonavimas

Kelios komandos taip pat išreiškė poreikį klonuoti užduotis, nes tam tikros standartinės veiklos atliekamos kas mėnesį (pavyzdžiui, apskaitos ataskaitų rengimas) arba kas ketvirtį.

Kadangi „Jira“ pagal numatytuosius nustatymus nepalaiko masinio užduočių klonavimo, iš pradžių bandėme šį poreikį išspręsti naudodami „Jira Automation“. Teoriškai masinio klonavimo sprendimas veikė, tačiau reikėjo ir redaguoti sukurtų užduočių laukus. Todėl šis alternatyvus sprendimas vis tiek būtų pareikalavęs papildomo darbo masiškai redaguojant užduotis.

Šiam iššūkiui išspręsti nusprendėme įdiegti "Deep Clone for Jira"  (opens in a new tab) papildinį. Jis leidžia greitai ir patogiai klonuoti didelį kiekį užduočių bei redaguoti jų laukus klonavimo metu.

Naujos programinės įrangos diegimas užtikrinant visapusišką pagalbą ir mokymus

Perėjimas nuo vienos programinės įrangos prie kitos yra laipsniškas procesas, kurio metu būtina atidžiai įvertinti įvairius techninius aspektus, kartu atsižvelgiant į galutinių naudotojų poreikius.

„Didžiausias iššūkis, su kuriuo susidūrėme, buvo pakeisti komandų ir visos įmonės mąstymą, kad jie prisitaikytų prie „Jira“ veikimo logikos“, – pasakoja Aleksandr.

„Kaip ir bet kurių reikšmingų pokyčių atveju, mūsų klientų aptarnavimo specialistų mokymas ir pripratimas prie naujos sistemos reikalauja laiko. Didžiausias sunkumas buvo tas, kad kiekviena komanda „Jira“ naudoja skirtingai, todėl turėjome susipažinti su jų lentų nustatymais, užduočių laukais ir kitais ypatumais. Iš pradžių tai sukėlė daug painiavos, todėl teko skirti papildomo laiko sukurtoms užduotims peržiūrėti ir procesams tobulinti. Tačiau situacija gerokai pagerėjo ir tikėtina, kad netrukus galėsime išnaudoti visas programinės įrangos galimybes, įskaitant asmenines užduotis“, – pasakoja Lisette.

Siekdami įtraukti komandas į pokyčių procesą ir sustiprinti pasitikėjimą nauja programine įranga, projekto pradžioje surengėme kontaktinius mokymus galutiniams naudotojams. Pradedančiųjų mokymuose mokėmės naudotis programine įranga teoriškai ir praktiškai, taip pat išsiaiškinome svarbiausias sąvokas ir terminus.

Prisitaikant prie naujos programinės įrangos, naudotojams dažnai kyla papildomų klausimų ir idėjų. Planuojant išteklius svarbu į tai atsižvelgti, kad būtų galima užtikrinti veiksmingą ir nuolatinę pagalbą viso pereinamojo laikotarpio metu. Administravimo mokymuose „Bondora“ pagrindiniams „Jira“ naudotojams suteikėme techninių žinių apie „Jira“ administravimą ir pasidalijome geriausia praktika.

Ateities perspektyvos

Kruopščiai sukurta projektų struktūra padeda pagrindą tolesniam strateginio lygmens planavimo tobulinimui. Šiuo metu vienas iš „Bondora“ prioritetų plėtojant „Jira“ yra „Advanced Roadmaps“ diegimas, siekiant sujungti įmonės iniciatyvų ir strateginių tikslų valdymą vienoje sistemoje.