Enterprise Change Management

JIRA – Change Performance

Na úvod je­den po­zi­tív­ny pos­treh. V pos­led­ných ro­koch už pri pro­jek­toch nep­rev­lá­da ná­zor, že kaž­dá zme­na je v pod­sta­te zlá a tre­ba ju eli­mi­no­vať. Dy­na­mi­ka biz­ni­su, a te­da aj IT pro­jek­tov, kto­ré naň pria­mo nad­vä­zu­jú, nú­ti pro­jek­to­vé tí­my aj lí­nio­vé štruk­tú­ry pod­ni­kov pre­mýš­ľať o tom, ako sa so zme­na­mi nau­čiť lep­šie vy­chá­dzať. Nie na­dar­mo sta­ré po­re­kad­lo ho­vo­rí, že zme­na je ži­vot.

En­terpri­se Chan­ge Ma­na­ge­ment - Excel ale­bo „dos­pe­lý" sys­tém?

Prak­tic­ky všet­ci kor­po­rát­ni klien­ti, s kto­rý­mi som sa za pos­led­né ro­ky stre­tol, nie­ke­dy vy­skú­ša­li pri ria­de­ní zmien viac či me­nej jed­no­du­chú ta­buľ­ku v MS Excel. Ta­kis­to všet­ci pos­tup­ne priš­li na to, že Excel je sí­ce dob­rý na zoz­na­my po­žia­da­viek, ale je už o poz­na­nie hor­ší, len čo má mať kaž­dá po­žia­dav­ka ur­či­tý workflow (či­že is­té pra­vid­lá sprá­va­nia sa po­žia­dav­ky v da­nom ča­se), štruk­tú­ro­va­né dá­ta (te­da dá­to­vé pra­vid­lá), prí­pad­ne ak pot­re­bu­je­me evi­do­vať od­pra­co­va­ný čas na jed­not­li­vých po­žia­dav­kách (te­da or­ga­ni­zač­né pra­vid­lá).

O pot­re­be šir­šej ko­la­bo­rá­cie nad kaž­dou po­žia­dav­kou (nap­rík­lad vy­jad­re­nie os­tat­ných pod­ni­ko­vých út­va­rov) ani ne­ho­vo­riac. A to sme len na za­čiat­ku to­ho, čo všet­ko by agen­da ria­de­nia zmien ale­bo chan­ge ma­na­ge­men­tu (CHM) ma­la za­bez­pe­čo­vať. Na rad te­da lo­gic­ky pri­chá­dza úva­ha o ne­ja­kom so­fis­ti­ko­va­nej­šom nás­tro­ji ale­bo in­for­mač­nom sys­té­me, kto­rý mô­že­me naz­vať „dos­pe­lým" (a nie je to pre­to, že by sme všet­ky sys­té­my v MS Excel po­va­žo­va­li bez uvá­že­nia za „ne­dos­pe­lé").

Od špe­cia­li­zo­va­né­ho sys­té­mu na chan­ge ma­na­ge­ment ne­bu­de­me chcieť „len" evi­den­ciu zme­no­vých po­žia­da­viek, ale pl­no­hod­not­ný nás­troj: je­ho pou­ží­va­teľ­mi mô­žu byť všet­ci za­mes­tnan­ci aj ob­chod­ní par­tne­ri, vý­stu­py bu­de sle­do­vať vr­cho­lo­vý ma­naž­ment a v ne­pos­led­nom ra­de sa v zlo­ži­tej štruk­tú­re po­žia­da­viek bu­de­me chcieť ľah­ko orien­to­vať.

JI­RA

Tou­to té­mou sa za­ča­la za­obe­rať už v ro­ku 2002 spo­loč­nosť At­las­sian, kto­rá dod­nes vy­rá­ba súp­ra­vu nás­tro­jov pod­po­ru­jú­cich sof­tvé­ro­vý vý­voj. Pr­vý z nich bol nás­troj na is­sue ma­na­ge­ment naz­va­ný JI­RA, nes­kôr sa pri­da­li nás­tro­je Con­fluen­ce (pro­jek­to­vá wiki), Fis­hEye (ma­na­žér­ska nad­stav­ba nad úlo­žis­kom zdro­jo­vých kó­dov) a ďal­šie. Väč­ši­na tých­to nás­tro­jov je cie­le­ná na vý­vo­jár­ske tí­my, JI­RA sa však uchy­ti­la na pro­jek­toch, kde je dô­le­ži­tá spo­lup­rá­ca IT a biz­ni­su, čo je v kor­po­rát­nom pros­tre­dí prak­tic­ky vždy.

Ako sme už spo­me­nu­li, JI­RA je nás­troj na is­sue ma­na­ge­ment - to zna­me­ná, že si zna­me­ni­te po­ra­dí v si­tuáciách, keď má­me veľ­ké množ­stvo rôz­ne sú­vi­sia­cich po­žia­da­viek, kto­ré ma­jú rôz­ny workflow, rôz­ne at­ri­bú­ty, a chce­me v nich mať pre­dov­šet­kým po­ria­dok, aby sa s ni­mi da­lo pra­co­vať. Me­dzi hlav­né vlas­tnos­ti JI­RA pat­rí:

  • Evi­den­cia po­žia­da­viek vzhľa­dom na ich workflow,
  • Ria­de­nie po­žia­da­viek pro­jek­to­vým spô­so­bom,
  • Zdie­ľa­nie in­for­má­cií - nás­ten­ky, e-mai­lo­vé no­ti­fi­ká­cie,
  • Re­por­ty po­žia­da­viek, filtrov cez rôz­ne at­ri­bú­ty,
  • Mož­nos­ti in­teg­rá­cie s ďal­ší­mi sys­té­ma­mi nie­len od At­las­sia­nu.

At­las­sian JI­RA je v sú­čas­nos­ti kor­po­rát­ny štan­dard aj v ta­kých spo­loč­nos­tiach, ako sú NA­SA, Twit­ter, eBay, Cis­co, Ado­be, BNP Pa­ri­bas, BWM a ďal­šie. JI­RA je v po­rov­na­ní s kon­ku­ren­ciou re­la­tív­ne ľah­ko im­ple­men­to­va­teľ­ný nás­troj (pri dodr­ža­ní ro­zum­ných pod­mie­nok im­ple­men­tá­cie) a na­šim klien­tom tak mô­že slú­žiť chví­ľu po in­šta­lá­cii. Spra­vid­la sa dá JI­RA spus­tiť v pi­lot­ných pro­jek­toch už v prie­be­hu pr­vých 3 týž­dňov od za­ča­tia im­ple­men­tá­cie, čo je v kor­po­rát­nom pros­tre­dí veľ­mi sluš­ný vý­sle­dok.

JIRA_2-1 copy.jpg

Workflow ako ta­jom­stvo ús­pe­chu

Ak je reč o chan­ge ma­na­ge­men­te a špe­ciál­ne o JI­RA, ako nás­tro­ji vhod­nom pre tú­to dis­cip­lí­nu, ne­mož­no obísť po­jem workflow. U väč­ši­ny klien­tov si pred im­ple­men­tá­ciou JI­RA ujas­ňu­je­me poj­my a skú­se­nosť je ta­ká, že kaž­dý na za­čiat­ku chá­pe po­jem workflow od­liš­ne, aj keď v pod­sta­te správ­ne.

Workflow je orien­to­va­ný graf - sú­bor sta­vov, kto­rý­mi po­žia­dav­ka prej­de po­čas svoj­ho vir­tuál­ne­ho ži­vo­ta, a sú­bor pre­cho­dov me­dzi tý­mi­to stav­mi. Pre­cho­dom ho­vo­rí­me na zjed­no­du­še­nie „workflow úlo­hy" ale­bo len „úlo­hy" - spl­ne­ním ta­kej­to úlo­hy sa po­žia­dav­ka po­su­nie vo workflow do nas­le­du­jú­ce­ho sta­vu. Z jed­né­ho sta­vu mô­že ply­núť viac al­ter­na­tív­nych workflow úloh, kaž­dý z nich do iné­ho nás­led­né­ho sta­vu - tým sa workflow vet­ví. Niek­to­ré úlo­hy pl­nia ľu­dia, kto­rým je po­žia­dav­ka prá­ve pri­ra­de­ná, iné mô­žu byť auto­ma­ti­zo­va­né sys­té­mom. Kaž­dá úlo­ha mô­že mať pod­mien­ky, za kto­rých ju mož­no pou­ží­va­te­ľo­vi sprís­tup­niť, kon­tro­ly správ­nos­ti za­da­ných dát a tzv. pos­tfun­kcie (nap­rík­lad auto­ma­tic­ké pre­ra­de­nie na iné­ho pou­ží­va­te­ľa).

JI­RA ako nás­troj na en­terpri­se chan­ge ma­na­ge­ment

Te­raz sa poz­ri­me na niek­to­ré dô­le­ži­té de­tai­ly kor­po­rát­ne­ho ria­de­nia zmien, zvlášť po­kiaľ sa roz­hod­ne­te pou­žiť At­las­sian JI­RA. Jed­na z vlas­tnos­tí kor­po­rát­ne­ho chan­ge ma­na­ge­men­tu je pot­re­ba zbe­ru po­žia­da­viek na­prieč fir­mou a zá­ro­veň mož­nosť, aby sa (po­ten­ciál­ne ku všet­kým) po­žia­dav­kám vy­jad­ri­li všet­ky od­de­le­nia, pre kto­ré sú tie­to po­žia­dav­ky re­le­van­tné. Sku­toč­nosť mô­že byť aj ta­ká, že prv než sa k za­da­nej po­žia­dav­ke vy­ja­dria všet­ky stra­ny, je ta­ká­to po­žia­dav­ka zre­lá na kom­plet­ný re­di­zajn.

V po­riad­ku, zme­na je ži­vot - ale v nás­tro­ji na chan­ge ma­na­ge­ment tre­ba mať na to prip­ra­ve­nú dos­ta­toč­ne ro­bus­tnú dá­to­vú štruk­tú­ru po­žia­dav­ky (kto aké po­lia vy­pĺňa a kto­ré z nich sú po­vin­né) a workflow, kto­rý zos­ta­ne zmys­lupl­ný aj po nie­koľ­ko­ná­sob­nej otoč­ke me­dzi za­dá­va­te­ľom a reali­zač­ným (nap­rík­lad IT) út­va­rom. Dá­to­vú štruk­tú­ru po­žia­dav­ky v JI­RA nas­ta­ví­me pri im­ple­men­tá­cii jed­no­du­cho a ani nie je zlo­ži­té tú­to štruk­tú­ru me­niť už pri na­sa­de­ní JI­RA naos­tro (na roz­diel od niek­to­rých iných kon­ku­ren­čných nás­tro­jov).

Ďal­šia po­lož­ka je workflow. Nie je prav­da, že workflow mu­sí byť ta­ký ro­bust­ný, aby si pa­mä­tal všet­ky even­tua­li­ty. Nao­pak, pla­tí, že čím jed­no­duch­ší je workflow, tým je men­šia sna­ha pou­ží­va­te­ľov ob­chá­dzať ho. Tre­ba si uve­do­miť, že vo workflow pra­cu­jú s da­nou po­žia­dav­kou pra­cov­ní­ci fir­my s rôz­nou zna­los­ťou prá­ve toh­to workflow - prá­ve pre­to tam vlas­tne je.

A z to­ho dô­vo­du nie je vhod­né, aby z kaž­dé­ho sta­vu bo­lo mož­né prejsť do mno­hých ďal­ších sta­vov. Ak bu­de mať pou­ží­va­teľ, kto­rý má prá­ve pri­de­le­nú úlo­hu workflow nad po­žia­dav­kou, na vý­ber 5 sta­vov, do kto­rých mô­že po­žia­dav­ku po­su­núť, s vy­so­kou prav­de­po­dob­nos­ťou zvo­lí ten nes­práv­ny. Workflow tak nepl­ní svoj účel.

A nao­pak - po­kiaľ mu dá­me na vý­ber z dvoch va­rian­tov, nap­rík­lad „od­po­ve­dať na do­pyt" ale­bo „od­ov­zdať aj bez vy­jad­re­nia", je vy­so­ko prav­de­po­dob­né, že zvo­lí ten krok, kto­rý po­žia­dav­ku po­su­nie správ­nym sme­rom k ďal­šej úlo­he iné­mu pou­ží­va­te­ľo­vi. Klien­ti čas­to oča­ká­va­jú, že mož­no vy­tvo­riť ro­bust­ný a vy­so­ko auto­ma­ti­zo­va­ný workflow, kto­rý bu­de na zá­kla­de (čas­to veľ­mi zlo­ži­tých) kom­bi­ná­cií auto­ma­tic­ky roz­ho­do­vať, aký bu­de ďal­ší osud da­nej po­žia­dav­ky.

Sa­moz­rej­me, kaž­dá kor­po­rá­cia od nás­tro­ja na chan­ge ma­na­ge­ment oča­ká­va ove­ľa viac než len evi­den­ciu a prep­ra­co­va­ný workflow po­žia­da­viek. Dos­tá­va­me sa tak do ob­las­ti re­por­tin­gu po­žia­da­viek. JI­RA na to pos­ky­tu­je nás­ten­ky, kto­ré mož­no zdie­ľať me­dzi pou­ží­va­teľ­mi aj ce­lý­mi tí­ma­mi, pri­čom kaž­dý pou­ží­va­teľ je schop­ný si ta­kú nás­ten­ku jed­no­du­cho vy­tvo­riť. Pat­rí sem aj vy­ka­zo­va­nie a sle­do­va­nie ho­dín od­pra­co­va­ných na po­žia­dav­kách. JI­RA v zá­klad­nej kon­fi­gu­rá­cii pos­ky­tu­je evi­den­ciu od­pra­co­va­né­ho ča­su a po roz­ší­re­ní, nap­rík­lad plu­gi­nom Tem­po, zvlád­ne aj ka­pa­cit­né plá­no­va­nie a pod.

Prík­lad po­žia­dav­ky v JI­RA

Čas­to po­ža­do­va­ná fun­kčnosť je in­teg­rá­cia s MS Pro­ject. Za po­mo­ci plu­gi­nu sa dá JI­RA o tú­to fun­kčnosť dopl­niť - syn­chro­ni­zá­cia po­tom pre­bie­ha z ap­li­ká­cie MS Pro­ject na po­čí­tač pou­ží­va­te­ľa a pod­ľa kon­krét­nej kon­fi­gu­rá­cie vie s MS Pro­ject vy­mie­ňať ce­lé po­žia­dav­ky ale­bo len ak­tua­li­zo­vať ich at­ri­bú­ty, sta­vy atď.

JI­RA a ďal­šie pod­ni­ko­vé agen­dy

Z opi­su vlas­tnos­tí JI­RA vi­dieť, že ten­to nás­troj je po­mer­ne uni­ver­zál­ny na pou­ži­tie tak­mer vo všet­kých inter­ných agen­dách, kto­ré ma­jú cha­rak­ter is­sue ma­na­ge­men­tu. Stre­tá­va­me sa s im­ple­men­tá­cia­mi JI­RA v po­do­be hel­pdes­ku, žia­dos­ti o do­vo­len­ky ale­bo nás­tro­ja na tes­ty (s plu­gi­nom Zep­hyr sa JI­RA stá­va veľ­mi ob­stoj­ným nás­tro­jom na ria­de­nie tes­tov sof­tvé­ru). Pred krát­kym ča­som bol uve­de­ný na trh ori­gi­nál­ny At­las­sian plu­gin Servic­e Desk, kto­rý už pod­ľa náz­vu zvlá­da veľ­mi preh­ľad­ne ce­lú tú­to agen­du vrá­ta­ne SLA a špe­ci­fic­kých re­por­tov.

Autor: Vít Ur­ban, pra­cu­je v spo­loč­nos­ti Uni­corn Sys­tems a.s. na po­zí­cii se­nior kon­zul­tan­ta.

Zdroj: PCR 12/2014



Ohodnoťte článok:
   
 
 
  Zdieľaj cez Facebook Zdieľaj cez Google+ Zdieľaj cez Twitter Zdieľaj cez LinkedIn Správy z RSS Správy na smartfóne Správy cez newsletter