Alkusyksystä 2023 saimme päätökseen Jiran käyttöönottoprojektin Bondoralla. Uuden työkalun käyttöönottoon liittyi kaksi samanaikaista haastetta – fintech-yrityksen 15 vuoden historiatietojen siirtäminen Asanasta Jiraan sekä tiimien mahdollisimman sujuva siirtyminen alustalta toiselle.
Tässä artikkelissa tarkastelemme käyttöönottoprosessia, erilaisia vaatimuksia ja teknisiä ratkaisuja sekä tiimien tähänastisia kokemuksia Jiran käytöstä.
Tietoa Bondorasta
Vuonna 2008, maailmanlaajuisen finanssikriisin ollessa pahimmillaan, Bondora (opens in a new tab) perustettiin opiskelija-asuntolan huoneessa. Yrityksellä oli yksi selkeä tavoite: auttaa ihmisiä, joita pankit eivät olleet pystyneet palvelemaan. Bondoran missiona on mahdollistaa ihmisille heidän unelmiensa elämä ilman rahahuolia.
Miksi Bondora valitsi Jiran?
Jiran tavoin Asana on projektien ja työn hallintaan tarkoitettu ohjelmisto, jonka avulla voidaan suunnitella, seurata ja hallita tehtäviä. Vaikka Jira Software kehitettiin alun perin nimenomaan ohjelmistokehityksen tarpeisiin, sen monipuolisuus mahdollistaa erilaisten prosessien tukemisen.
Jira Softwaren merkittävimpiä etuja Asanaan verrattuna ovat muun muassa:
- Joustavat määritysmahdollisuudet työnkuluille, tikettityypeille, kentille, näkymille ja käyttöoikeuksille;
- Scrum-menetelmän tuki esimerkiksi sprinttien, tuotejonon (backlog) ja sprinttikohtaisten raporttien avulla;
- Laajat integraatiomahdollisuudet;
- Oma kyselykieli Jira Query Language (JQL) tikettien hakemiseen;
- Advanced Roadmaps projektisalkun hallintaan.
Koska Bondora harjoittaa myös ohjelmistokehitystä, päätökseen valita Jira vaikutti merkittävästi mahdollisuus integroida se Azure DevOpsiin. Asana ei tarjonnut vastaavaa integraatiomahdollisuutta.
Kehitystiimin johtaja Aleksandr Knjazetski korosti, että siirtymispäätöksen taustalla olivat Jiran mukautettavat toiminnallisuudet, jotka voidaan räätälöidä yrityksen prosessien ja vaatimusten mukaisiksi.
Käyttöönotto tiimeittäin
Bondora aloitti Jiran käyttöönoton itsenäisesti kehitystiimeistä. Käyttöönotto sujui suhteellisen helposti, sillä osalla tiimien asiantuntijoista oli jo aiempaa kokemusta Jira Softwaresta.
"Muiden tiimien kohdalla kohtasimme haasteita, sillä niillä ei ollut kokemusta Jiran toiminnallisuuksista, jotka tukevat erilaisia prosesseja. Päätimme etsiä asiantuntijoita, jotka auttaisivat meitä siirtämään muut tiimit Jiraan ja jakaisivat osaamistaan Jiran toiminnallisuuksista sekä kokemustaan Jiran hallinnasta", kertoo Aleksandr, joka vastasi käyttöönottoprojektista Bondoran puolella.
Jatkoimme yhdessä Jiran käyttöönottoa henkilöstöhallinnon, markkinoinnin, riskienhallinnan, liiketoiminnan laajentamisen ja talousosaston tiimeissä. Jaoimme tiimien siirtymisen kolmeen päävaiheeseen:
- Lähtötietojen kerääminen – nykyisiin työprosesseihin tutustuminen, Asana-projektien ja -taulujen tarkastelu sekä vaatimusten dokumentointi;
- Jira-projektin määrittäminen;
- Ratkaisujen validointi ja tarvittaessa lisämuutosten tekeminen.
Tietojen siirtäminen Asanasta Jiraan tapahtui samanaikaisesti edellä mainittujen vaiheiden kanssa. Bondora toteutti tietojen siirron itsenäisesti. Lisätietoja siirron yksityiskohdista ja sen aikana saaduista opeista löytyy Aleksandrin blogikirjoituksesta (opens in a new tab).
Loimme jokaiselle tiimille omat Confluence-sivut, joille dokumentoimme kenttiä, tikettityyppejä, työnkulkuja, käyttöoikeuksia ja ilmoituksia koskevat vaatimukset.
Vaatimusmäärittelyjen mallipohja, tekstin sisäiset kommentit ja käyttäjien merkitseminen @-maininnoilla mahdollistivat yksityiskohtien tarkentamisen suoraan asiayhteydessä. Hyödynsimme myös Slack-kanavia nopeaan viestintään ja suunnitteluun.
Automaatiosäännöt, tikettikohtaiset käyttöoikeudet ja käyttökokemukseen liittyvät yksityiskohdat
Useissa tiimeissä oli tarve rajoittaa käyttöoikeuksia tarkasti, joten otimme käyttöön tikettien suojausmallin (Issue Security Scheme). Suojausmalli sisältää suojaustasoja, joiden avulla tikettien katseluoikeudet voidaan määrittää Jira-ryhmän, roolin tai yksittäisen käyttäjän perusteella (emme suosittele käyttöoikeuksien määrittämistä yksittäisille käyttäjille).
Tietyn suojaustason valinta voidaan tehdä manuaalisesti tai automaattisesti. Esimerkiksi toteutimme Jira-automaation avulla suojaustasojen automaattisen määrittämisen laitetilauksille "Office"-projektissa.
Vaatimuksena oli, että kaikilla yrityksen työntekijöillä on oltava oikeus luoda tikettejä Office-projektiin. Muiden työntekijöiden luomien tikettien katseluoikeuksia oli kuitenkin rajoitettava.
Paras ratkaisu tähän oli automaatiosääntö, joka määritti tiketille automaattisesti suojaustason sen luomisen yhteydessä. Jotta tiketit eivät näkyisi koko tiimille, määritimme suojaustasolla katseluoikeudet vain "Reporter"-roolille (tikettien ilmoittajille) ja Office-tiimin ryhmälle.
Automaation avulla yksinkertaistimme prosessia, sillä tiketin luojan ei enää tarvinnut valita suojaustasoa manuaalisesti.
Kiireellisten tikettien hallinta taulunäkymässä
Toteutimme eri projekteissa automaatiosääntöjä erilaisiin tarpeisiin, mutta päätavoitteena oli edelleen tikettien tehokas hallinta.
Esimerkiksi liiketoiminnan laajentamisesta vastaavassa Expansion-tiimissä hyödynsimme automaatiota vaatimukseen, jonka mukaan tiketti siirtyy automaattisesti Backlog-tilasta To do -tilaan, kun sen "Due date" (määräpäivä) on seuraavien 30 päivän aikana. Tämän seurauksena tiketti siirtyy erillisestä Backlog-näkymästä Kanban-taululle, joka toimii tikettien hallinnan ensisijaisena näkymänä.
Lisäksi oli tarpeen erottaa kiireelliset tiketit taulunäkymässä nopeasti ja helposti.
Vaatimuksena oli, että tiketit, joiden "Due date" (määräpäivä) on seuraavien seitsemän päivän aikana, näkyvät Jira-taululla keltaisina. Tikettien, joiden määräpäivä on jo mennyt, tuli puolestaan näkyä punaisina. Toteutimme värilogiikan taulun asetuksissa JQL-kyselykielen avulla.
Kuva 1. Esimerkki Kanban-taulusta, jossa korteilla on eri värit.
Tikettien massakloonaus
Useat tiimit toivat esiin tarpeen kloonata tikettejä, sillä tietyt vakiotehtävät toistuvat kuukausittain (esimerkiksi kirjanpidon raportointi) tai neljännesvuosittain.
Koska Jira ei oletusarvoisesti tue tikettien massakloonausta, yritimme ensin ratkaista tarpeen Jira Automationin avulla. Massakloonausratkaisu oli teoriassa toimiva, mutta koska myös luotujen tikettien kenttiä oli voitava muokata, tämä vaihtoehtoinen ratkaisu olisi edellyttänyt lisätyötä tikettien massamuokkauksen muodossa.
Ratkaistaksemme tämän haasteen päätimme ottaa käyttöön Deep Clone for Jira (opens in a new tab) -lisäosan. Sen avulla tikettejä voidaan kloonata nopeasti ja helposti suuria määriä sekä muokata niiden kenttiä jo kloonauksen yhteydessä.
Uuden ohjelmiston käyttöönotto kattavan tuen ja koulutuksen avulla
Siirtyminen ohjelmistosta toiseen on vaiheittainen prosessi, jossa on huomioitava huolellisesti erilaiset tekniset näkökohdat ja samalla pidettävä loppukäyttäjien tarpeet mielessä.
"Suurin kohtaamamme haaste oli tiimien ja koko yrityksen ajattelutavan muuttaminen Jiran toimintalogiikkaan sopivaksi", Aleksandr kertoo.
"Kuten kaikissa merkittävissä muutoksissa, myös asiakaspalvelijoidemme kouluttaminen ja uuteen järjestelmään tottuminen vievät aikaa. Suurin haaste oli se, että jokainen tiimi käyttää Jiraa eri tavalla, joten meidän piti tutustua niiden taulujen asetuksiin, tehtäväkenttiin ja muihin käytäntöihin. Aluksi tämä aiheutti paljon hämmennystä, ja jouduimme käyttämään ylimääräistä aikaa luotujen tehtävien tarkistamiseen ja prosessien sujuvoittamiseen. Tilanne on kuitenkin parantunut huomattavasti, ja todennäköisesti pystymme pian hyödyntämään ohjelmiston kaikkia toiminnallisuuksia, kuten henkilökohtaisia tehtäviä", Lisette kertoo.
Jotta tiimit saatiin mukaan muutokseen ja luottamus uuteen ohjelmistoon vahvistui, järjestimme projektin alkuvaiheessa loppukäyttäjille lähikoulutusta. Peruskoulutuksessa opettelimme ohjelmiston käyttöä teorian ja käytännön harjoitusten avulla sekä kävimme läpi tärkeimmät käsitteet ja termit.
Uuteen ohjelmistoon totuttautuessa käyttäjille herää usein lisäkysymyksiä ja uusia ajatuksia. Tämä on tärkeää huomioida resursseja suunniteltaessa, jotta koko siirtymävaiheen ajan voidaan tarjota tehokasta ja toimivaa tukea. Jaoimme Bondoran Jira-pääkäyttäjille teknistä osaamista Jiran hallinnasta sekä parhaita käytäntöjä ylläpitokoulutuksen avulla.
Tulevaisuudennäkymät
Huolellisesti suunniteltu projektirakenne luo pohjan strategisen tason suunnittelun kehittämiselle tulevaisuudessa. Bondora on tällä hetkellä asettanut Jiran Advanced Roadmaps -toiminnallisuuden käyttöönoton etusijalle. Tavoitteena on yhdistää yrityksen kehityshankkeiden ja strategisten tavoitteiden hallinta samaan järjestelmään.
Ota yhteyttä
Pysy ajan tasalla uutisistamme ja kiinnostavista projekteistamme
Jaamme tarinoita työstämme ja asiakkaistamme, kerromme designin ja teknologian uusista suunnista ja esittelemme tiimimme ihmisiä. Sisältömme on sekoitus hyödyllistä tietoa, inspiraatiota ja välillä myös hyvää huumoria.