Jira ieviešana finanšu tehnoloģiju uzņēmuma biznesa attīstības un atbalsta komandās: Bondora pieredzes stāsts

2023. gada rudens sākumā mēs pabeidzām Jira ieviešanas projektu uzņēmumā Bondora. Jaunā rīka ieviešana bija saistīta ar diviem vienlaicīgiem izaicinājumiem – finanšu tehnoloģiju uzņēmuma 15 gadu vēsturisko datu migrāciju no Asana uz Jira un pēc iespējas vienmērīgāku komandu pāreju no vienas platformas uz otru.

Šajā rakstā aplūkosim ieviešanas procesu, dažādās prasības un tehniskos risinājumus, kā arī komandu līdzšinējo pieredzi darbā ar Jira.

Par Bondora

2008. gadā, pasaules finanšu krīzes kulminācijā, studentu kopmītnes istabā tika dibināts uzņēmums Bondora  (opens in a new tab) ar vienu skaidru mērķi – palīdzēt cilvēkiem, kuriem bankas nebija spējušas sniegt nepieciešamo atbalstu. Bondora misija ir dot cilvēkiem iespēju dzīvot savu sapņu dzīvi, neraizējoties par naudu.

Kāpēc Bondora izvēlējās Jira?

Tāpat kā Jira, arī Asana ir projektu un darba pārvaldības programmatūra, kas paredzēta uzdevumu plānošanai, izsekošanai un pārvaldībai. Lai gan Jira Software sākotnēji tika izstrādāta tieši programmatūras izstrādes vajadzībām, tās daudzpusība ļauj atbalstīt dažādus darba procesus.

Dažas no būtiskākajām Jira Software priekšrocībām salīdzinājumā ar Asana ir:

• Elastīgas konfigurēšanas iespējas darbplūsmām, uzdevumu tipiem, laukiem, skatiem un piekļuves tiesībām;
• Scrum metodoloģijas atbalsts, tostarp sprinti, neizpildīto darbu saraksts (backlog) un sprintu pārskati;
• Plašas integrācijas iespējas;
• Īpaša vaicājumu valoda Jira Query Language (JQL) uzdevumu meklēšanai;
• Advanced Roadmaps projektu portfeļa pārvaldībai.

Tā kā Bondora nodarbojas arī ar programmatūras izstrādi, lēmumu izvēlēties Jira būtiski ietekmēja iespēja to integrēt ar Azure DevOps. Asana šādu integrācijas iespēju nepiedāvāja.

Izstrādes komandas vadītājs Aleksandr Knjazetski uzsvēra, ka lēmumu par migrāciju noteica Jira pielāgojamās funkcionalitātes, kuras iespējams konfigurēt atbilstoši konkrētiem procesiem un prasībām.

Ieviešana pa komandām

Sākotnēji Bondora uzsāka Jira ieviešanu patstāvīgi, sākot ar izstrādes komandām. Šis uzdevums bija salīdzinoši vienkāršs, jo daļai šo komandu speciālistu jau bija iepriekšēja pieredze darbā ar Jira Software.

"Ar pārējām komandām saskārāmies ar izaicinājumiem, jo tām nebija pieredzes ar Jira funkcionalitātēm, kas atbalsta konkrētus procesus. Tāpēc nolēmām piesaistīt ekspertus, kuri palīdzētu pārcelt pārējās komandas uz Jira un dalītos zināšanās par Jira funkcionalitātēm un pieredzē tās administrēšanā," skaidro Aleksandr, kurš vadīja ieviešanas projektu no Bondora puses.

Kopā turpinājām Jira ieviešanu personāla vadības, mārketinga, risku pārvaldības, biznesa paplašināšanas un finanšu nodaļu komandās. Komandu pāreju sadalījām trīs galvenajos posmos:

• Sākotnējās informācijas apkopošana – iepazīšanās ar esošajiem darba procesiem, Asana projektu un tāfeļu izpēte, prasību dokumentēšana;
• Jira projekta konfigurēšana;
• Risinājumu pārbaude un nepieciešamības gadījumā papildu izmaiņu veikšana.

Datu migrācija no Asana uz Jira notika vienlaikus ar iepriekš minētajiem posmiem. Bondora migrāciju veica patstāvīgi. Plašāku informāciju par migrācijas niansēm un gūtajām atziņām var atrast Aleksandr bloga rakstā  (opens in a new tab).

Katrai komandai izveidojām atsevišķas Confluence lapas, kurās dokumentējām prasības attiecībā uz laukiem, uzdevumu tipiem, darbplūsmām, piekļuves tiesībām un paziņojumiem.

Prasību dokumentēšanas veidne, komentēšana tieši tekstā un lietotāju pieminēšana ar @ simbolu ļāva precizēt detaļas tieši attiecīgajā kontekstā. Ātrai saziņai un plānošanai izmantojām arī Slack kanālus.

Automatizācijas noteikumi, uzdevumu līmeņa drošība un lietotāju pieredzes nianses

Vairākās komandās bija nepieciešams precīzi ierobežot piekļuves tiesības, tāpēc ieviesām uzdevumu drošības shēmu (Issue Security Scheme). Tā ietver drošības līmeņus, ar kuru palīdzību piekļuves tiesības uzdevumiem var konfigurēt, pamatojoties uz Jira grupu, lomu vai atsevišķu lietotāju (neiesakām piekļuves tiesības konfigurēt individuāliem lietotājiem).

Konkrētu uzdevuma drošības līmeni iespējams izvēlēties manuāli vai automātiski. Piemēram, izmantojot Jira automatizāciju, projektā "Office" ieviesām automātisku drošības līmeņu piešķiršanu aprīkojuma pasūtījumiem.

Viena no prasībām bija nodrošināt, lai visi uzņēmuma darbinieki varētu izveidot uzdevumus Office projektā. Vienlaikus bija jāierobežo iespēja skatīt kolēģu izveidotos uzdevumus.

Labākais risinājums bija automatizācijas noteikums, kas uzdevuma izveides brīdī tam automātiski piešķīra drošības līmeni. Lai uzdevumi nebūtu redzami visai komandai, drošības līmenī konfigurējām piekļuvi tikai "Reporter" lomai (uzdevuma pieteicējam) un Office komandas grupai.

Ar automatizācijas palīdzību vienkāršojām procesu, novēršot nepieciešamību uzdevuma pieteicējam manuāli izvēlēties drošības līmeni uzdevuma izveides laikā.

Prioritāro uzdevumu pārvaldība tāfeles skatā

Dažādos projektos ieviesām automatizācijas noteikumus dažādiem mērķiem, taču galvenais mērķis joprojām bija efektīva uzdevumu pārvaldība.

Piemēram, biznesa paplašināšanas komandā (Expansion) izmantojām automatizāciju, lai nodrošinātu, ka uzdevums automātiski pāriet no statusa "Backlog" uz "To do", ja tā laukā "Due date" (Izpildes termiņš) norādītais datums ir nākamo 30 dienu laikā. Tādējādi uzdevums no atsevišķā Backlog skata nonāk Kanban tāfelē, kas ir galvenā uzdevumu pārvaldības saskarne.

Bija nepieciešams arī nodrošināt iespēju ātri un vienkārši atšķirt prioritāros uzdevumus tāfeles skatā.

Prasība paredzēja, ka uzdevumiem, kuru izpildes termiņš ir nākamo septiņu dienu laikā, Jira tāfelē jābūt attēlotiem dzeltenā krāsā, savukārt uzdevumiem ar nokavētu izpildes termiņu – sarkanā krāsā. Šo krāsu loģiku ieviesām tāfeles iestatījumos, izmantojot JQL vaicājumus.

1. attēls. Kanban tāfeles piemērs ar dažādu krāsu kartītēm.

Uzdevumu masveida klonēšana

Vairākas komandas izteica arī nepieciešamību klonēt uzdevumus, jo noteiktas standarta darbības tiek veiktas katru mēnesi (piemēram, grāmatvedības pārskatu sagatavošana) vai reizi ceturksnī.

Tā kā Jira pēc noklusējuma neatbalsta uzdevumu masveida klonēšanu, sākotnēji mēģinājām šo prasību īstenot ar Jira Automation palīdzību. Teorētiski masveida klonēšanas risinājums darbojās, taču bija nepieciešams arī rediģēt izveidoto uzdevumu laukus. Tādēļ šis alternatīvais risinājums joprojām prasītu papildu darbu, masveidā rediģējot uzdevumus.

Lai atrisinātu šo izaicinājumu, nolēmām ieviest Deep Clone for Jira  (opens in a new tab) spraudni. Tas ļauj ātri un ērti klonēt lielu skaitu uzdevumu, kā arī rediģēt to laukus jau klonēšanas procesā.

Jaunas programmatūras ieviešana ar visaptverošu atbalstu un apmācībām

Pāreja no vienas programmatūras uz citu ir pakāpenisks process, kurā rūpīgi jāizvērtē dažādi tehniskie aspekti, vienlaikus paturot prātā gala lietotāju vajadzības.

"Lielākais izaicinājums, ar ko saskārāmies, bija mainīt komandu un visa uzņēmuma domāšanas veidu, lai pielāgotos Jira darbības loģikai," stāsta Aleksandr.

"Tāpat kā jebkuru nozīmīgu pārmaiņu gadījumā, arī mūsu klientu apkalpošanas speciālistu apmācība un pieradums pie jaunās sistēmas prasa laiku. Lielākais izaicinājums bija tas, ka katra komanda izmanto Jira atšķirīgi, tāpēc mums vajadzēja iepazīt to tāfeļu iestatījumus, uzdevumu laukus un citas nianses. Sākotnēji tas radīja daudz neskaidrību, un mums nācās veltīt papildu laiku izveidoto uzdevumu pārskatīšanai un procesu pilnveidošanai. Tomēr situācija ir ievērojami uzlabojusies, un, visticamāk, drīzumā varēsim pilnvērtīgi izmantot visas programmatūras iespējas, tostarp personīgos uzdevumus," stāsta Lisette.

Lai iesaistītu komandas pārmaiņu procesā un veicinātu uzticēšanos jaunajai programmatūrai, projekta sākumposmā organizējām klātienes apmācības gala lietotājiem. Iesācēju apmācībās apguvām programmatūras lietošanu gan teorētiski, gan praktiski, kā arī izskaidrojām svarīgākos jēdzienus un terminus.

Pielāgojoties jaunajai programmatūrai, lietotājiem bieži rodas papildu jautājumi un idejas. Tas ir būtiski jāņem vērā, plānojot resursus, lai nodrošinātu efektīvu un nepārtrauktu atbalstu visā pārejas periodā. Administrēšanas apmācībās sniedzām Bondora Jira galvenajiem lietotājiem tehniskās zināšanas par Jira administrēšanu un dalījāmies labākajā praksē.

Nākotnes perspektīvas

Rūpīgi izstrādāta projektu struktūra veido pamatu stratēģiskā līmeņa plānošanas turpmākai attīstībai. Bondora pašlaik par vienu no Jira attīstības prioritātēm ir noteikusi Advanced Roadmaps ieviešanu, lai vienā sistēmā apvienotu uzņēmuma iniciatīvu un stratēģisko mērķu pārvaldību.