Jira juurutamine fintech-ettevõtte äriarenduse- ja tugitiimides: Bondora lugu

2023. aasta sügise alguses jõudis lõpusirgele Bondora Jira juurutamise projekt. Uue tööriista kasutuselevõtuga kaasnes kaks paralleelset väljakutset – migreerida finantstehnoloogia ettevõtte 15-aastane ajalugu Asanast Jirasse ning tuua tiimid võimalikult sujuvalt ühelt platvormilt teisele.

 

Järgnevalt saame teada, kuidas juurutusprotsessi teostasime, milliseid tehnilisi lahendusi rakendasime ning millised on tiimide senised kogemused Jiraga. 

 

 

Bondorast 

2008. aastal, ülemaailmse finantskriisi haripunktis, asutati ühes tudengite ühiselamu toas Bondora ühel kindlal eesmärgil: aidata inimesi, keda pangad on alt vedanud. Bondora missioon on võimaldada inimestel elada oma unistuste elu raha pärast muretsemata. 

 

 

Miks otsustati Jira kasuks? 

Sarnaselt Jirale on Asana projekti- ja tööde haldamise tarkvara, mille abil ülesandeid planeerida, jälgida ja juhtida. Kuigi Jira Software loodi algselt eelkõige arendust toetavaks tarkvaraks, sobib see väga erinevate protsesside toetamiseks just tänu oma mitmekülgsusele.

 

Mõned Jira Software eelised Asana ees:
 

• paindlikud seadistusvõimalused töövoogude, piletitüüpide, väljade, vaadete ja õiguste näol; 
• Scrum metoodikat toetavad funktsionaalsused nagu sprint, backlog ja sprindipõhised raportid; 
• laialdased liidestusvõimalused; 
• spetsiaalne päringukeel Jira Query Language (JQL) piletite otsimiseks; 
• Advanced Roadmaps projekti portfoolio haldamiseks. 

 

Kuna Bondora tegeleb ka arendusega, mängis Jira kasuks otsustamisel muuhulgas olulist rolli ka liidestusvõimalus Azure DevOps’iga, mis ei ole Asana puhul võimalik.  

 

“Jira funktsionaalsused võimaldavad tööriista kohandada vastavalt konkreetsetele protsessidele ja nõuetele,” põhjendas arendustiimi juht Aleksandr Knjazetski migreerimise otsust.

 

 

Juurutus tiimide kaupa 

Jira juurutamisega tegi Bondora algust iseseisvalt ja esmalt võeti ette arendustiimid. Kuna mõned spetsialistid nendes tiimides olid Jira Software´iga varasemalt kokku puutunud, siis ei olnud tegemist suure väljakutsega. 

 

“Teiste tiimidega tekkis probleem, kuna puudusid kogemused protsesse toetavate Jira funktsioonide osas. Otsustasime leida eksperdid, kes aitaksid meid teiste tiimide ületoomisel ning kes jagaksid oma teadmisi Jira funktsioonide kohta ja kogemusi Jira haldamisest,” selgitas Aleksandr, kes juhtis juurutusprojekti Bondora poolelt. 

 

Koostöös jätkasime Jira rakendamist personali,- turunduse,- riski,- laienduse,- ja finantsosakonna tiimide kaupa. Tiimi ületoomise jagasime kolmeks põhietapiks: 

• sisendi kogumine – tööprotsessidega tutvumine, Asana projektide ja tahvlitega tutvumine, nõuete dokumenteerimine; 
• Jira projekti seadistamine;  
• lahenduste valideerimine ja vajadusel täiendavate muudatuste teostamine.

 

Mainitud etappidega toimus paralleelselt andmete ületoomine Asanast Jirasse. Andmete migreerimist teostas Bondora omal käel ning selle nüanssidest ja õppetundidest saad lähemalt lugeda Aleksandri blogipostitusest. 

 

Jira nõuete dokumenteerimiseks tegime iga tiimi jaoks spetsiaalse Confluence´i lehe, kuhu talletasime infot vajalike väljade, piletitüüpide, töövoogude, õiguste ja teavituste kohta.  

 

Standardne dokumentatsiooni mall, tekstisisene kommenteerimine ja kasutajate teavitamine @ märkimise teel võimaldas detaile täpsustada vahetult ja otse konteksti sees. Kiireks kommunikatsiooniks ja planeerimiseks kasutasime Slack´i kanaleid. 

 

Turundustiim 

Turundusosakonna projektide migreerimise eel selgus, et igat Asana projekti ei ole mõistlik Jirasse eraldi projektina luua, vaid otstarbekamaks osutus piletite konsolideerimine ühte projekti.  

 

“Varem kasutasime kahte Asana projekti investoritepoole sotsiaalmeedia jaoks ja Jiras liitsime need üheks projektiks. Lisaks kasutas meie copywriter Asanas eraldi projekti sotsiaalmeedia sisu jaoks, mis sai samuti Jira projektiga integreeritud,” sõnas turundus- ja müügispetsialist Suule Vill.  

 

Peale migreerimist oli vaja piletites teostada sisulisi korrastustöid. “Organiseerisin ja värskendasin Asanast Jirasse üle toodud projektide piletid sobivatesse kategooriatesse ning tegin korrektuure piletite väljadel, et tagada copy ja disainide õigeaegne valmimine. Selleks lisasime projekti tavalisele “Due Date” väljale lisaks kohandatud välja “Publish Date”. Vajaliku info dokumenteerisime ka Confluence´i lehel,” lisas Suule.  

 

Teiste turundustegevuste haldamiseks tegime Jirasse eraldi projekti, mis oli algselt Jira Software´i tüüpi projekt, ent peale kasutajate tagasisidet ja täiendavat uurimist muutsime selle Jira Work Management (JWM) projektiks.   

 

Antud juhul rääkis JWM kasuks peamiselt vajadus näha pileteid kalendrivaates, mis Jira Software´i projekti siseselt ei ole võimalik. Lisalugemist Jira Software´i vs Jira Work Management´i teemadel leiad meie varasemast blogipostitusest.

 

Kliendikogemuse tiim 

Bondora kliendikogemuse (CX - customer experience) tiim teeb igapäevaselt koostööd teiste tiimidega.  

 

“Meie töö kõige väljakutsuvam osa on leida viise, kuidas kõigel silma peal hoida ja asjadega kursis olla. Oleme erinevates osakondades kasutanud erinevaid süsteeme, ent nüüd kus kõik on ühes keskkonnas, saab erinevaid ülesandeid lihtsasti siduda teiste tahvlite ja projektidega,” sõnas kliendikogemuse tiimi liige Lisette Rohunurm. 

 

Näiteks on kliendikogemuse tiimi jaoks oluline, et klientide kaebuste või tagasiside registreerimisel saaks Jira pileti linkida tootetiimi piletiga. Integratsiooni abil saavad agendid sujuvalt otse Zendeskist Jira pileteid luua ja Zendeskist pöörumisi Jira piletiga linkida. 

 

“Jira kasutuselevõtt ärgitas meid oma protsesse veelgi rohkem üle vaatama, neid ühtlustama ja üles märkima ning looma paremaid piletimalle ja eemaldama ebavajalikke välju,” selgitas Lisette uuele tarkvarale üleminekust tulenevat lisaväärtust. 

 

Pileti “Description” väljale mallide loomine oli läbiv nõue pea kõikides tiimides, mille lahendamiseks rakendasime Issue Templates Agent lisarakendust. 

 

Finants- ja raamatupidamistiim 

Bondora raamatupidamistiim kasutab Jirat igapäevaseks suhtluseks ja ülesannete jagamiseks teistele ettevõtte osakondadele, eriti klienditeenindusele.  

 

“Jira rakendamine on meil võimaldanud täiustada raamatupidamislikke protsesse ja kuluaruannete koostamist. Jira võimaldab meil kiirelt reageerida ja tegevusi koordineerida seoses kulude, arvete ning kadunud tšekke puudutavate küsimustega,” sõnas raamatupidamistiimi liige Karin Köösel. 

 

Kuluaruannete haldamisega seondus nõue, et loodud aruandeid (pileteid) peab saama üles laadida raamatupidamisprogrammi PDF formaadis.  

 

Et Jira piletite PDF eksporti vaikimisi ei võimalda, võet kasutusele Xporter lisarakendus, mille abil saab pileti eeldefineeritud malli kujul muuhulgas PDF formaati eksportida. 

 

“Lisaks kasutame raamatupidamistiimis eraldi Jira tahvleid kadunud tšekkide ja arvete jaoks. See võimaldab meil jälgida ja hallata puuduvaid dokumente ning vastavalt vajadusele luua piletid konkreetsetele isikutele,” täpsustas Karin raamatupidamislike protsesside korraldamist Jiras. 

 

 

Automaatikad, detailne õiguste piiramine ja kasutusmugavuse nüansid

Mitmes tiimis oli vajadus õiguseid detailselt piirata ja selle jaoks rakendasime Issue Security skeemi. Skeemis seadistatakse turvalisuse tasemed (security levels), millele määratakse ligipääsu õigused Jira grupi, rolli või üksikkasutaja (võimalik, kuid mitte soovituslik praktika) põhiselt. 

 

Piletile konkreetse turvalisuse taseme valimine võib toimuda manuaalselt või automaatselt. Personalitiimi “Office” projektis juurutasime seadmete tellimise protsessi, kus kasutasime automaatset turvalisuse taseme määramist Jira automation abil. 

 

Kehtis nõue, et projektis peab olema õigus pileteid luua kõigil ettevõtte töötajatel, ent näha tohib töötaja (Office tiimi väline) ainult enda poolt loodud pileteid.   

 

Parim lahendus antud nõudele oli automaatika reegel, mis lisas piletile turvalisuse taseme automaatselt selle loomise hetkel. Et piletid kogu kollektiivile nähtavad ei oleks, seadistasime turvalisuse tasemes ligipääsud “Reporter” ehk pileti looja rollile ja Office tiim grupile.

 

Automaatika abil välistasime ka olukorra, kus pöörduja peaks piletit luues ise turvalisuse taseme valima. 

 

Esmatähtsate piletite haldamine tahvli vaates 

Automaatikaid rakendasime erinevates projektides mitmel otstarbel, ent sisuliselt oli läbiv eesmärk võimalikult tõhus piletite haldamine, et fookuses oleksid alati kõige olulisemad tööd.

 

Näiteks lahendasime Expansion tiimis automaatika abil nõude, et kui pileti “Due date” väärtus on järgmise 30 päeva jooksul, peab pilet "Backlog" staatustest automaatselt liikuma "To do" staatusesse. Seeläbi liigub pilet ka eraldiseisvast Backlog vaatest Kanban tahvlile, mis on põhiline vaade tööde haldamisel.  

 

Ühtlasi ilmnes vajadus esmatähtsaid pileteid tahvli vaates kiirelt ja lihtsalt eristada. Kehtis nõue, et piletid mille “Due date” väärtus on järgmise 7 päeva jooksul peavad Jira tahvlil muutuma kollaseks ja sellised piletid, mille “Due date” väärtus on minevikus, peavad muutuma punaseks. Värvide loogika rakendasime tahvli seadistustest JQL abil.
 

Joonis 1. Näidis Kanban tahvlist, kus piletikaartidele on seadistatud värvid

 

Piletite kloonimine

Mitmes tiimis avaldus ka vajadus pileteid kloonida. Tegemist on standardtegevustega, mida teostatakse iga kuu (näiteks raamatupidamises aruandlus) või kord kvartalis.

 

Et Jira piletite masskloonimist vaikimisi ei võimalda, proovisime antud nõuet esmalt lahendada Jira Automation'iga. Automaatika abil loodud lahendus oli piletite masskloonimiseks teoreetiliselt toimiv, ent kuna loodavate piletite väljasid oli vaja ka muuta, tähendanuks workaround lahendus siiski täiendavat lisatööd piletite hulgimuutmise näol.

 

Vajaduse lahendamiseks otsustasime rakendada Deep Clone for Jira pluginat, mis võimaldab mugavat piletite masskloonimist ja väljade muutmist kloonimise protsessi ajal.

 

 

Uue tarkvara kasutuselevõtt läbi mitmekülgse toe ja koolituste 

Üleminek ühelt tarkvaralt teisele ei toimu üleöö - arvestada tuleb mitmete tehniliste aspektidega, ent seejuures ei tohi unustada kasutajat. 

 

“Peamine väljakutse, millega kokku puutusime, oli tiimide ja kogu ettevõtte mõtteviisi muutmine, et kohaneda Jira loogikaga,” sõnas Aleksandr. 

 

"Nagu iga olulise muudatuse puhul, võtab agentide koolitamine ja uue süsteemiga harjumine aega. Suurimaks väljakutseks oli kohaneda iga tiimi Jira projekti eripäradega - näiteks tahvli seadistuse ja väljadega. Algselt tekitasid erisused segadust ning loodud piletite ülevaatamiseks ja uue protsessiga kohanemiseks tuli võtta lisaaega. Tänaseks on aga protsess märkimisväärselt paranenud ja tõenäoliselt kasutame Jirat varsti ka suuremas mahus, näiteks isiklike piletite jälgimiseks," avaldas Lisette.

 

Tiimide pardale toomiseks ja uue tarkvara suhtes usalduse loomiseks tegime juba projekti algusfaasis kasutajatele on-site koolituse. Algaja taseme koolituse käigus õppisime läbi teooria ja praktiliste ülesannete tarkvara kasutama ning tegime selgeks olulisemad kontseptsioonid ja terminid.  

 

Sageli tekib kasutajatel uue tarkvara kasutamise käigus ka täiendavaid küsimusi ja mõtteid. Seda tasub ressursside planeerimisel arvestada, et oleks võimalus pakkuda operatiivset tuge üleminekufaasis. Tehnilise teadmuse Jira administreerimisest ja headest praktikatest tõime Bondora Jira peakasutajateni läbi administraatori taseme koolituse.

 

 

Tulevikuperspektiiv 

Läbimõeldud projektide struktuur võimaldab edasiarendusi kõrgematasemeliseks planeerimiseks. Tänaseks on Bondora Jira maailmas seadnud fookuse Advanced Roadmaps´i juurutamisele, et tuua ka ettevõtte initsiatiivide ja strateegiliste eesmärkide juhtimine ühte keskkonda.