Kas sinu ettevõtte Jira ei täida ärivajadusi ning tekitab kasutajates vastumeelsust? 4 võimalikku põhjust koos soovitustega

Jira peakasutaja on rakenduse administraator, kellel on ulatuslikud Jira administreerimise õigused, et rakendust seadistada ning hallata.

Klassikaliselt on peakasutaja ülesanneteks näiteks:

• Jira projektide loomine ja seadistamine lähtuvalt headest praktikatest;
• süsteemsete seadistuste haldamine (näiteks globaalsed õigused, versiooniuuendused, meiliserverid, andmebaasi seire jm);
• kasutajate haldamine;
• rakenduste ja liidestuste haldamine;
• lõppkasutajate õpetamine, abistamise ja vajaduste täpsustamine.

Et Jirast saadav kasutegur sõltub paljugi projektide ülesehitusest, siis on seadistamise juures oluline jälgida parimaid praktikaid, et tekiks võimalus projektides jätkusuutlikult planeerida, mõõta ning analüüsida.

Teisalt on süsteemsete seadistuste, rakenduste ja liidestuste ning kasutajate haldamine oluline ka keskkonna jõudluse ja turvalisuse perspektiivist.

Hea peakasutaja omab rakendusest ja selle nüanssidest süvaarusaama, tehnilisi teadmisi ning kogemusi.

Oleme näinud, et kiirelt arenevates organisatsioonides hakatakse Jira haldamist teostama põhitöö kõrvalt.

Sageli tähendab see, et administraatori õigustega inimesel puuduvad pädevad teadmised rakenduse haldamise parimatest praktikatest või oskused seadistuselementide haldamiseks.

Spetsiaalse Jira peakasutaja puudumine päädib sageli ka sellega, et seadistusi teostatakse niiöelda jooksvalt eesmärgiga kõik lõppkasutaja vajadused kiirelt täita, et projektidega liikvele minna.

Selline praktika toimib küll lühikeses perspektiivis, ent pikemas perspektiivis tagatakse hea Jira hügieen ja jätkusuutlikud lahendused läbi teadliku ja korrapärase tegutsemise.

Haldusstandardite all peame silmas kindlaks määratud tegutsemisviise ja kokkuleppeid, mida peakasutaja järgib Jira haldamisel.

Haldusstandardite järgimine aitab:

• vältida peakasutajate halduskoormust
• luua täpseid ning tegelikkust peegeldavaid raporteid ning analüütikat
• tagada jätkusuutlikku süsteemi toimimist.

Täpsed standardid võivad organisatsiooniti erineda, ent alustuseks tasub mõelda aspektidele, millel on ulatuslik mõjuala, nagu näiteks:

Millist tüüpi projekte süsteemi luuakse?

Atlassian pilveplatvormil on esindatud kaks erinevate projektitüüpi - team managed ja company managed.

Team managed projektide loomine on kiire ja mugav, ent tasub arvestada, et seda tüüpi projektid on isoleeritud ning piiratud seadistusvõimalustega.

Team managed projektitüübid võivad saada kiirelt komistuskiviks, kui soovitakse luua projektideüleseid raporteid, vaateid või analüütikat.

Milliseid seadistuselemente on võimalik taaskasutada?

Uut Jira projekti saab luua teise projekti ja selle seadistuste baasil, (taas)kasutades seeläbi juba süsteemis olemasolevaid seadistusi.

Sisuliselt on tegemist mall-projektidega, kus pileteid ei hallata, vaid eesmärgiks ongi nende projektide alusel uute loomine.

Näidisolukord: tarkvaraarenduse teenust pakkuv ettevõte eristab oma arendusprojektides suurarendust ja väikearendust. Ettevõte soovib Jirat juurutada projektijuhtimiseks.

Mistahes protsessi juurutamine Jirasse võiks alata protsessi kaardistamisest.

Antud näite puhul kaardistatakse suurveebi ning väikeveebi arendusprotsess, mille tulemusena tekib sisend nii töövoo, aga ka andmeväljade seadistamiseks.

Sisendi põhjal luuakse kaks read only mall-projekti ning uue arendusprojekti juhtimiseks luuakse spetsiaalne Jira projekt mallprojekti põhjal.

Nii väheneb Jira peakasutaja halduskoormus märkimisväärselt, kusjuures süsteemi ei tekitata liigselt seadistuselemente, mis sisult üksteist duplitseerivad.

Kui tihti Jirat puhastatakse?

Regulaarne Jira puhastamine tagab hea selle hügieeni.

Tasub juhinduda põhimõttest, et mida suurem on ettevõtte ning mida rohkem on Jira projekte, seda sagedamini tasuks puhastustöid läbi viia.

Soovituslik regulaarsus Jira puhastustöödeks on 1-2 korda aastas.

Mis keeles seadistuselemente nimetatakse?

Oleme näinud Jira keskkondi, kus seadistuselemendid nagu töövoo staatused, kohandatud väljad ja piletitüübid on loodud mitmes keeles.

Kuigi üks keelevalik ei pruugi alati võimalik olla, tasuks siiski kokku leppida esmane ning teisane keelevalik, et lõppkasutajale oleks Jiras töötamine võimalikult korrapärane ja intuitiivne.

Grupid või rollid

Grupid ja rollid leiavad kasutust eelkõige õiguste, teavituste ja piletipõhiste turvatasemete seadistamisel.

Nii gruppidel aga ka rollidel on omad eelised, ent tasub arvestada, et rollid võimaldavad paindlikumat haldust.

Jira süsteemsete seadistuselementide all mõistame kõike, mille abil luuakse projekti alustalad. Need on elemendid, mis seotakse skeemidega, millest viimased seotakse projektiga.

Organisatsiooni arenedes luuakse Jira projekte sageli agiilses vormis, kus pannakse suurt rõhku lõppkasutaja vajaduste kiirele täitmisele.

Seejuures võib tekkida olukord, kus süsteemi tekib aja jooksul hulk seadistuselemente, mis sisuliselt üksteist duplitseerivad.

Kahjuks ei ole Jira tagasüsteemis piirangut, mis keelaks Jira administraatoril luua juba olemasoleva nimega seadistuselementi.

Näiteks oleme sageli näinud, et süsteemis on mitu kohandatud välja, mis kannavad sama nime või on sisult samatähenduslikud, ent nimetatud veidi erinevalt.

Kuigi duplikaat seadistuselemendid pruugi koheselt tekitada jõudluskoormust, võivad need üsna kiirelt tekitada segadust ning meelehärmi lõppkasutajale.

Näidisolukord: kasutaja soovib luua päringu, et leida kõik piletid projektist A, millel on täidetud väli “Country” väärtusega “Estonia”.

JQL moodulit kasutades küll näidatakse välja nime kõrval välja ID kood, ent tüüpiliselt ei ole selline metadetail info, mida lõppkasutaja teab või peaks teadma.

Samanimelised väljad seega ummistavad süsteemi ning pärsivad tõhusat ja meeldivat Jira kasutuskogemust. Ent miks üldse võib süsteemi “tekkida” mitu sama nimega välja?

Sageli luuakse süsteemi mitu sama nimega välja (näiteks mitme valikvastusega väli) olukorras, kus välja soovitakse kasutada erinevates projektides, ent kus ka valikvastused peavad erinevates projektides olema erinevad.

Duplikaatide loomise asemel soovitame sellise olukorra lahendada kohandatud välja seadistamise abil.

Näidisolukord: kasutaja soovib leida kõik piletid projektist A, B ja C, mis on staatuses “In analysis”. Projektid A ja B kasutavad ühte ja sama töövoogu, ent projekt C kasutab teistest erinevat töövoogu.

Ülaltoodud näidisolukord on lihtne ja sageli esilekerkiv, kus komistuskiviks võivad saada staatused, mis on erinevalt nimetatud, ent sisult samatähenduslikud.

Aja jooksul koguneb Jirasse palju projekte ning pileteid, mis teatud hetkest enam kasutust ei leia.

Ärinõuete perspektiivist on mõistetav, et projekte ja pileteid kustutada ei tohi, ent nende Jirasse “jätmine” ummistab süsteemi ning aeglustab piletiotsingut.

Arhiveeritud projekt ning selle piletid eemaldatakse Jira indeksist; neid ei kuvata otsingumootoris, tahvlitel ega töölaudadel.

Lõppenud projektide arhiveerimine aitab keskkonna liigsest infomürast puhtana hoida ning tagab kiiremad vasted päringutele. Projektide arhiveerimine võiks olla osa regulaarsest Jira puhastustööst.