Jira adminisztrátorok, Atlassian tanácsadók – Kik ők és miért kellenek?

A Jira mellett számlatan érv szól, viszont nem árt tisztában lenni vele, hogy bonyolultabb, mint egy Excel tábla. Itt nem elég csak felvenni egy-egy feladatot valamilyen listába, majd kipipálni / zöldre színezni, ha készen van. Projekteket, workflow-kat és feladattípusokat kell összehangoltan konfigurálni – és ezek még csak az alapfunkciók. 

Ha elég jó rendszerszemlélettel vagy megáldva és még affinitásod is van ezt csinálni, akkor egy ideig te magad is el tudod tologatni. Az általánosabb viszont, hogy akinek a Jira nem a munkája, csak egy eszköze a valódi munkájához, annak egy idő után elfogy a türelme - vagy eleve nincs is neki. 

Ilyenkor jönnek képbe a Jira adminisztrátorok és Atlassian tanácsadók.

Mi a különbség?

A laikus nyelvezetben gyakorlatilag semmi. A cégvezetők, projekt menedzserek gyakran ugyanazt a tevékenységet értik mindkettő alatt. Ha viszont helyesen akarjuk használni a kifejezéseket, ezeket az alapvető különbségeket kell ismerni:

Jira adminisztrátor

Általában házon belül van, vagyis a cég alkalmazottja. Munkája inkább operatív jellegű, ő állítja be a workflow-kat, mezőket pontosan úgy, ahogy a menedzserek kérik. Kérdésekre válaszolnak, hibákat javítanak, de vagy egyáltalán nem, vagy csak kevéssé vesznek részt a stratégiai tervezésben.

Atlassian tanácsadók

Ők szinte kivétel nélkül mindig külsős szakértők és általában nem is egy konkrét ember, hanem egy vállalkozás. Projekt alapon dolgoznak és általában komplexebb helyzetekben jönnek képbe, például migrációnál, vagy amikor több Atlassian terméket kell bevezetni, összehangolni, esetleg plugineket fejleszteni. A Jira adminisztrátorokkal ellentétben ők jobban látják a “nagy képet”, több szerepük van a stratégiai irányok meghatározásában.

Egyébként a gyakorlatban általában mindkét típusú feladatot ugyanaz a munkatárs vagy ugyanaz a külsős cég végzi. Alkalmazottként a Jira adminisztrátortól fogják várni, hogy átlássa a nagy képet is, külsősként pedig az Atlassian tanácsadók fogják ténylegesen konfigurálni is a rendszert. Ritka eset az, amikor egy vállalatnak van egy belsős Jira adminisztrátor munkatársa és ezenfelül megbíz egy külsős Atlassian tanácsadó céget is. 

Emiatt az “összemosódás” miatt a cikk további részében én is egyben kezelem a kettőt és Atlassian szakértőként fogok rájuk hivatkozni. 

Most, hogy tisztáztuk a különbséget, lássuk tehát miért is kellenek a jó Atlassian szakértők:

Átmenetet képeznek a menedzserek és az IT között

Sajnos elterjedt szokás, hogy a cégek egyáltalán nem bíznak meg és nem is alkalmaznak dedikált kollégát a Jira kezelésére. Ez általában vagy egy menedzser vagy egy asszisztens, nagyobb cégeknél pedig az egyik IT-s kolléga feladata. A probléma ezzel a megközelítéssel az, hogy bárkire is “sózzuk” a Jira-t, ő mindenképp a saját munkája mellé kapja meg még ezt is. 

Ebből kifolyólag neki nem ezen lesz a fókusza és a végeredmény az, hogy “mindegy, hogy van beállítva, csak működjön”. Egy ilyen alapokra épült rendszerből nagyon nehéz később kijönni és előbb-utóbb úgyis kell valaki, aki helyreteszi. (Ez egyébként nem csak a Jira-val van így. Bármilyen rendszert el lehet rontani, ami kicsit bonyolultabb, mint egy kockás füzet.)

Ráadásul egy menedzsernek vagy asszisztensnek nem biztos, hogy megvan a kellő mértékű technikai attitűdje a Jira konfigurálásához. Hiába lennének jó ötleteik, a kivitelezés nem úgy sikerül, ahogy szerették volna és emiatt kénytelenek “megalkudni” a végeredményben. Egy IT-s szakember pedig általában kódokban és parancsokban gondolkodik. Legtöbbször szó szerint ezek vannak a szeme előtt és mivel ezt szokta meg, hajlamos figyelmen kívül hagyni azon felhasználók szempontjait, akik nem ilyen környezetben dolgoznak.

Egy jó Atlassian szakértő viszont valahol a kettő között helyezkedik el. Töviről-hegyire ismeri a Jira lehetőségeit, korlátait és egy-egy ötletre sokszor már csípőből tudja a megoldást. Mindezt úgy, hogy közben nem veszik el a tekintete a parancssorokban. 

Stratégiai szempontokban is segítenek

Egy Atlassian szakértő nem csak “gombokat nyomkod”. Aktívan részt vesz például a cég belsős munkatársai és a külsős partnerek közötti kommunikáció kialakításában és a folyamatok összehangolásában is.

Ezen felül sokszor ő tereli vissza a projekt menedzsereket a helyes projekt struktúra fenntartásához is. Mit jelent ez? 

Találkoztam például olyan esettel, amikor egy menedzser azt kérte, “ha a fő feladat (főjegy) lezárul Approved státusszal, akkor jöjjenek létre automatikusan alá alfeladatok (aljegyek)”. Technikailag megvalósítható ez a kérés? Persze. Viszont logikailag is rendben van? A legkevésbé sem. 

Projektmenedzsment szempontból aranyszabály ugyanis, hogy egy főjegy csak akkor zárulhat le, amikor annak összes alfeladata is lezárult valamilyen eredménnyel. Ettől marad keretben a feladat, ettől lesz érvényes az, hogy a fő feladatot bontjuk alfeladatokra. Ha logikailag egy főjegy előbb zárulna, mint bármelyik aljegye, akkor ott már nem lebontásról beszélünk, hanem egy következő, ráépülő feladatról, amit vele egy szinten kell kezelni. 

Egy jó Atlassian szakértő ilyenkor rávilágít, hogy valójában nem alfeladatot kell létrehozni automatikusan, hanem egy másik fő feladatot, amihez egy függőségi összekapcsolást (linket) használunk az időbeli hierarchia jelzéséhez. 

Ez csak egy alap – viszont gyakran előforduló – példája volt annak, mennyire könnyű hibásan, a projektmenedzsment szabályait felrúgva kialakítani a folyamatokat. Ezeket egy Atlassian szakértő nagyrészt még csírájában el tudja fojtani. 

Rendet és következetességet hoznak a rendszerbe

Még a legkisebb csapatokban is előfordulnak apróbb következetlenségek – hát még egy nagyobb vállalatnál. Ilyen lehet például, hogy egy státusz jelzésére két projektben csak minimálisan eltérő kifejezéseket használnak. (Pl.: In Progress, Work In Progress). Ebből adódóan egy-egy feladat kimaradhat a filterekből, nem kerül bele a riportokba stb.

Sokszor a projekt gazdái egyáltalán nincsenek is tisztában azzal, hogy egy általuk használt státusz vagy mező már létezik a rendszerben valamilyen formában, ezért rengeteg Jira felépítése tele van duplikációkkal és eltérő metodikákkal. 

Egy jó Atlassian szakértőnek viszont általában van egy kis OCD-je. :) Ezek és a hasonló redundanciák, inkonzisztenciák biztos, hogy zavarni fogják és törekedni fog arra, hogy az általa “dédelgetett” rendszert minden munkatárs egységesen használja. Ráadásul minél többféle beállítás létezik egy Jira-ban, neki annál több ezekkel a dolga, szóval egyértelműen érdeke, hogy ne hozzon létre új sablonokat, ha egyszer már léteznek. 

Az egységes rendszerhasználat pedig nem csak esztétikai kérdés. Egy jól strukturált, következetes Jira-ban készült riportok és dashboard-ok megbízhatóbbak, a vezetők és a csapatok könnyebben átlátják a haladást, a problémás területeket, és gyorsabban tudnak döntéseket hozni. 

Egy Atlassian szakértő bevonása nem luxus, hanem a hatékony, zökkenőmentes munkavégzés egyik kulcsfontosságú eszköze. Jelenléte a csapattagoknak és a vezetőségnek egyaránt könnyebbséget hoz, hosszú távon pedig növeli a vállalat termelékenységét és folyamatok gördülékenységét.