Možno odmerať kvalitu vášho IT riešenia?

Zá­kaz­ník si po­čas pro­jek­tu po­lo­ží jed­no­du­chú otáz­ku: „Je do­dá­va­né rie­še­nie dos­ta­toč­ne kva­lit­né?" Ob­dob­ne sa opý­ta do­dá­va­teľ: „Bu­de zá­kaz­ník po­va­žo­vať rie­še­nie za kva­lit­né? Bu­de s ním spo­koj­ný?" Ako to už bý­va, na jed­no­du­ché otáz­ky ne­bý­va­jú jed­no­du­ché od­po­ve­de. Čo všet­ko tre­ba zvá­žiť ale­bo od­me­rať, aby sme ve­de­li re­le­van­tne od­po­ve­dať?

Ak chce­me kva­li­tu od­me­rať, mu­sí­me mať is­to­tu, že sme do me­ra­ní za­kom­po­no­va­li všet­ky pot­reb­né čas­ti. Pre­to je na za­čiat­ku vhod­né dob­re po­ro­zu­mieť pod­sta­te ve­ci - vý­zna­mu poj­mu kva­li­ta. Poz­ri­me sa na zná­me de­fi­ní­cie. ISO de­fi­nu­je kva­li­tu ako úpl­ný zoz­nam fun­kčnos­tí a zá­klad­ných, resp. ur­če­ných cha­rak­te­ris­tík pro­duk­tu, pro­ce­su, služ­by ale­bo sys­té­mu, vzťa­hu­jú­cich sa na schop­nosť preu­ká­zať, že oča­ká­va­nia ale­bo špe­ci­fi­ko­va­né pot­re­by a po­žia­dav­ky bo­li do­siah­nu­té. Agil­ný Scrum de­fi­nu­je kva­li­tu ako schop­nosť kom­plet­né­ho pro­duk­tu spl­niť ak­cep­tač­né kri­té­riá a do­siah­nuť biz­ni­so­vú hod­no­tu oča­ká­va­nú zá­kaz­ní­kom.

Ak sa chce­me uis­tiť (a nes­kôr zá­kaz­ní­ko­vi preu­ká­zať), že rie­še­nie bu­de dos­ta­toč­ne kva­lit­né, je pot­reb­né za­bez­pe­čiť ak­ti­vi­ty sme­ru­jú­ce k to­mu­to sta­vu. Ho­vo­rí­me te­da o pot­re­be pro­ce­su.

Me­ra­nie kva­li­ty pro­ce­su

Väč­ši­na naj­zná­mej­ších me­to­dík pro­jek­to­vé­ho ma­naž­men­tu (PM) sa pod­rob­ne za­obe­rá pro­ce­som ma­naž­men­tu kva­li­ty v rám­ci pro­jek­tu, te­da tým, aké ty­py ak­ti­vít je pot­reb­né vy­ko­nať, aby sme kva­li­tu do­siah­li. Ten­to prís­tup k ria­de­niu kva­li­ty mož­no ta­kis­to sle­do­vať a me­rať. Nap­rík­lad s vy­uži­tím met­rík, ako je po­čet vy­ko­na­ných kon­trol kva­li­ty, ús­peš­nosť za­pá­ja­nia rôz­nych sta­ke­hol­de­rov, po­čet vy­tvo­re­ných ar­te­fak­tov sú­vi­sia­cich s kva­li­tou atď.

Vzhľa­dom na ich všeo­bec­né za­me­ra­nie me­to­di­ky PM neob­sa­hu­jú od­po­rú­ča­nia pre kva­li­tu pro­duk­tu, te­da ne­ho­vo­ria o tom, kto­ré as­pek­ty IT rie­še­nia tre­ba skú­mať, resp. ma­jú do­sah na kva­li­tu. Za­ve­de­nie pro­ce­su však sa­mo ose­be nie je dos­ta­ču­jú­ce. Ak pe­čiem tor­tu pod­ľa re­cep­tu, ale pou­ži­jem sta­ré vaj­cia, vý­sle­dok ne­bu­de zod­po­ve­dať oča­ká­va­niam. Rov­na­ko dô­le­ži­té je pre­to ok­rem pro­ce­su dbať aj na prís­tup ku kva­li­te pro­duk­tu a je­ho sú­čas­tí.

Me­ra­nie kva­li­ty pro­duk­tu

V tom­to sme­re pos­ky­tu­je po­moc­nú ru­ku štan­dard ISO. Od­nož zná­mej vet­vy ISO 9000 pod kó­do­vým ozna­če­ním ISO 9126 (nes­kôr nah­ra­de­ný ro­di­nou ISO 250xx) sa špe­cia­li­zo­val na kva­li­ta­tív­ne cha­rak­te­ris­ti­ky sof­tvé­ru. Pos­led­ná ver­zia ho­vo­rí, že kva­li­tu sof­tvé­ro­vé­ho pro­duk­tu mož­no hod­no­tiť na zá­kla­de nas­le­du­jú­cich cha­rak­te­ris­tík:

  • Fun­kčná pri­me­ra­nosť - pl­ne­nie im­pli­cit­ných a expli­cit­ných po­trieb pri pou­ží­va­ní pro­duk­tu
  • Spo­ľah­li­vosť - pos­ky­to­va­nie špe­ci­fi­ko­va­ných fun­kčnos­tí v rám­ci sta­no­ve­ných pod­mie­nok a ča­su
  • Pou­ži­teľ­nosť - schop­nosť sof­tvé­ru byť at­rak­tív­ny pre pou­ží­va­te­ľov, kto­rí mu ro­zu­me­jú a naučia sa ho pou­ží­vať
  • Vý­kon­nos­tná efek­ti­vi­ta - schop­nosť sof­tvé­ru pos­ky­to­vať pot­reb­nú vý­kon­nosť vzhľa­dom na pou­ží­va­né zdro­je
  • Bez­peč­nosť - ochra­na in­for­má­cií a dát pred nech­ce­ným prís­tu­pom ale­bo pou­ži­tím
  • Kom­pa­ti­bi­li­ta - schop­nosť dvoch ale­bo via­ce­rých kom­po­nen­tov vy­mie­ňať in­for­má­cie a vy­ko­ná­vať fun­kcio­na­li­tu zdie­ľa­ním to­ho is­té­ho har­dvé­ro­vé­ho ale­bo sof­tvé­ro­vé­ho pros­tre­dia
  • Udr­žia­va­teľ­nosť - schop­nosť sof­tvé­ru po­dlie­hať zme­nám (úp­ra­vám, zlep­še­niam...)
  • Pre­ná­ša­teľ­nosť - schop­nosť pro­duk­tu na tran­sfor­má­ciu z jed­né­ho pros­tre­dia do dru­hé­ho

Kaž­dá z tých­to hlav­ných ob­las­tí sa de­lí na via­ce­ro po­dob­las­tí, kto­rých je do­ved­na viac ako 30. Pre kaž­dú po­dob­lasť je de­fi­no­va­ná mno­ži­na met­rík, z kto­rých si mož­no vy­brať, prí­pad­ne sa len in­špi­ro­vať a us­pô­so­biť na vlas­tnú pot­re­bu. ISO na­vy­še eš­te de­fi­nu­je dopĺňa­jú­ce cha­rak­te­ris­ti­ky pre me­ra­nie kva­li­ty pou­ží­va­né­ho pro­duk­tu, ako nap­rík­lad efek­ti­vi­ta a bez­peč­nosť je­ho pou­ží­va­nia atď. Z toh­to poh­ľa­du te­da mož­no potvr­diť, že kva­li­ta pro­duk­tu sa dá od­me­rať, resp. zhod­no­tiť.

Ne­tech­no­lo­gic­ký vplyv na kva­li­tu

Uve­de­né cha­rak­te­ris­ti­ky sa za­me­ria­va­li na tech­no­lo­gic­kú pod­sta­tu pro­duk­tu/rie­še­nia. Tech­nic­ký poh­ľad však nie je je­di­ný, kto­rý má do­sah na vní­ma­nie kva­li­ty. Nev­hod­ne zvo­le­ná li­cen­čná po­li­ti­ka pro­duk­tu mô­že v bu­dúc­nos­ti znač­ne zvý­šiť je­ho ce­nu. Rov­na­ko ne­ga­tív­ne mož­no vní­mať nek­va­lit­nú pod­po­ru zo stra­ny do­dá­va­te­ľa. Pre­to je vhod­né dopl­niť štan­dard aj o ne­tech­no­lo­gic­ký poh­ľad na kva­li­tu. Tu už neexis­tu­je zho­da na spo­loč­ných cha­rak­te­ris­ti­kách, naj­čas­tej­šie sa však pou­ží­va­jú nas­le­du­jú­ce:

  • Do­dá­va­teľ - poh­ľad na je­ho po­zí­ciu na tr­hu, re­pu­tá­ciu ale­bo spô­sob, ako pos­ky­tu­je pod­po­ru pro­duk­tom
  • Ce­na - li­cen­čná, resp. cel­ko­vá ce­no­vá po­li­ti­ka do­dá­va­te­ľa
  • Pro­dukt - vy­spe­losť pro­duk­tu, vlas­tníc­tvo atď.

Dopl­ne­ním ne­tech­no­lo­gic­kých cha­rak­te­ris­tík dos­tá­va­me kom­plex­ný preh­ľad fak­to­rov vplý­va­jú­cich na kva­li­ta­tív­ne vní­ma­nie pro­duk­tu zá­kaz­ní­kom. Sta­čí nám však fakt, že tie­to cha­rak­te­ris­ti­ky pro­duk­tu mož­no od­me­rať?

Reál­na ap­li­ko­va­teľ­nosť

Úspeš­nosť spl­ne­nia via­ce­rých cha­rak­te­ris­tík (nap­rík­lad efek­tív­nosť mo­di­fi­ká­cií, pou­ži­teľ­nosť, mo­du­lár­nosť, adap­ta­bi­li­ta atď.) mož­no me­rať až po dl­hšom ča­se pou­ží­va­nia pro­duk­tu. V ča­se do­da­nia sa dá za­me­rať len na in­di­ká­to­ry, kto­ré tú­to ús­peš­nosť bu­dú na­po­má­hať iden­ti­fi­ko­vať. Dru­hý fak­tor je ce­na kva­li­ty, te­da to, do akej mie­ry sa za­obe­rať tes­to­va­ním všet­kých cha­rak­te­ris­tík pro­duk­tu, aby sa eli­mi­no­va­li mož­né ri­zi­ká v bu­dúc­nos­ti. Má­lo­ke­dy sa po­da­rí vy­hra­diť zdro­je na pod­rob­né de­fi­no­va­nie kva­li­ta­tív­nych kri­té­rií pre všet­ky de­fi­no­va­né ob­las­ti aj ich reál­ne otes­to­va­nie. Tre­ba za­ujať viac realis­tic­ký pos­toj. Ok­rem lo­gic­kej prio­ri­ti­zá­cie a iden­ti­fi­ká­cie naj­viac re­le­van­tných ob­las­tí je pod­ľa skú­se­nos­tí a od­po­rú­ča­ní vhod­né vy­brať z kaž­dej zos­tá­va­jú­cej ob­las­ti as­poň jed­nu met­ri­ku a tú po­čas pro­jek­tu sle­do­vať.

Vní­ma­nie kva­li­ty

Uve­de­ným prís­tu­pom vie­me de­fi­no­vať a kon­tro­lo­vať kva­li­tu ce­lé­ho do­dá­va­né­ho IT rie­še­nia. Tak­že te­raz nám to už za­bez­pe­čí spo­koj­nosť zá­kaz­ní­ka?

Spl­ne­nie oča­ká­va­ní

Jed­na z naj­väč­ších nez­ná­mych v úvod­nej de­fi­ní­cii je po­jem oča­ká­va­nia zá­kaz­ní­ka. Tie sa roz­li­šu­jú pod­ľa za­de­fi­no­va­ných po­žia­da­viek. Do­dá­va­teľ mô­že lo­gic­ky na­mie­tať, že nie je mož­né, aby ošet­ril všet­ky po­ten­ciál­ne (nie expli­cit­ne de­fi­no­va­né) pot­re­by zá­kaz­ní­ka, a pre­to sa up­ne na to, čo je za­chy­te­né „čier­ne na bie­lom".

Na jed­nej stra­ne je to správ­ny prís­tup, pre­to­že tre­ba mať ne­ja­kú zá­klad­nú hra­ni­cu, na dru­hej stra­ne sku­toč­ná spo­koj­nosť zá­kaz­ní­ka má má­lo spo­loč­né­ho s tým, čo je uve­de­né v zmlu­ve ale­bo do­ku­men­tá­cii. Agil­né prís­tu­py to rie­šia čias­tko­vý­mi vý­stup­mi a čas­tým za­pá­ja­ním zá­kaz­ní­ka, čím po­má­ha­jú iden­ti­fi­ko­vať aj vop­red ne­de­fi­no­va­né oča­ká­va­nia a zvy­šu­jú šan­cu na je­ho sku­toč­nú spo­koj­nosť.

Na dru­hej stra­ne vzni­ká väč­šie ri­zi­ko zmien sme­ru pro­jek­tu, ako aj opo­me­nu­tia dô­le­ži­tých cha­rak­te­ris­tík kva­li­ty (nap­rík­lad tech­nic­ké­ho cha­rak­te­ru) pre ne­dôs­led­né plá­no­va­nie a návrh. A pre­to tre­ba pri ria­de­ní pro­jek­tu neus­tá­le hľa­dať kom­pro­mis me­dzi vy­tvo­re­ním rie­še­nia so sku­toč­nou pri­da­nou hod­no­tou, spl­ne­ním oča­ká­va­ní a dodr­ža­ním špe­ci­fi­ká­cie.

Zú­čas­tne­né stra­ny

Dru­hý otáz­nik je po­jem zá­kaz­ník, kto­rý má byť spo­koj­ný. Väč­ši­nou pla­tí, že rôz­ne sku­pi­ny sta­ke­hol­de­rov ma­jú rôz­ne pot­re­by, a te­da aj poh­ľa­dy na kva­li­tu. Me­ra­nie kva­li­ty je zá­vis­lé od to­ho, vo­či kto­ré­mu zá­kaz­ní­ko­vi ho me­ria­me. Čo ak rie­še­nie spl­ni­lo všet­ky de­fi­no­va­né kri­té­riá a je vy­bu­do­va­né pres­ne tak, ako ho chcel spon­zor a na­de­fi­no­val pro­jek­to­vý tím, ale uká­že sa, že je­ho vý­voj or­ga­ni­zá­cii pri­nie­sol len mi­ni­mál­nu pri­da­nú hod­no­tu, pre­to­že sa ne­zoh­ľad­ni­li pot­re­by ďal­ších sta­ke­hol­de­rov? Je to na­priek to­mu kva­lit­né rie­še­nie?

Mi­ni­ma­li­zo­vať ta­ké­to ri­zi­ká je naj­mä v zod­po­ved­nos­ti or­ga­ni­zá­cie zá­kaz­ní­ka, kto­rá by ma­la po­mo­cou za­ve­de­ných a vzá­jom­ne in­teg­ro­va­ných pro­ce­sov (napr. en­terpri­se ar­chi­tek­tú­ra, ma­naž­ment por­tfó­lia, stra­te­gic­ké plá­no­va­nie) eli­mi­no­vať vy­tvá­ra­nie izo­lo­va­ných pro­jek­tov, kto­ré nie sú v sú­la­de s or­ga­ni­zač­ným sme­ro­va­ním a pot­re­ba­mi.

Zá­ver

Ako vi­dieť, poh­ľad na kva­li­tu je znač­ne re­la­tív­ny. Kva­li­ta je rov­ni­ca s množ­stvom pre­men­ných, no na­priek to­mu ob­lasť, kto­rej tre­ba ve­no­vať vy­so­kú prio­ri­tu. Zá­kaz­ník ča­som ľah­šie za­bud­ne na prek­ro­če­ný čas ale­bo zvý­še­ný roz­po­čet pro­jek­tu ako na nek­va­lit­ný pro­dukt.

Na zod­po­ve­da­nie pô­vod­nej otáz­ky, či je kva­li­ta môj­ho rie­še­nia dos­ta­toč­ná, da­jú met­ri­ky a kri­té­riá len prib­liž­nú od­po­veď, kto­rá mô­že slú­žiť ako in­di­ká­tor. Ale na­priek to­mu, že kva­li­tu v jej pl­nom vý­zna­me mož­no od­me­rať len veľ­mi ob­ťaž­ne, nez­na­me­ná to, že by sa tá­to sna­ha ma­la opo­mí­nať. Prá­ve nao­pak. Tre­ba vy­užiť všet­ky dos­tup­né pros­tried­ky na to, aby sme zá­kaz­ní­ko­vi preu­ká­za­li, že dos­tal to, čo pot­re­bo­val.

Je dô­le­ži­té si uve­do­miť roz­diel me­dzi do­hod­nu­tou kva­li­tou (spl­ne­nie zmluv­ných pod­mie­nok a špe­ci­fi­ká­cie) a sku­toč­nou kva­li­tou (spl­ne­nie reál­nych po­trieb zá­kaz­ní­ka) a sna­žiť sa o ich zjed­no­te­nie. Ces­tou k to­mu­to sta­vu nie je len za­ve­de­nie pro­ce­sov, ro­lí a me­ra­ní pod­ľa kri­té­rií, ale roz­ší­re­nie vní­ma­nia kva­li­ty ako neod­de­li­teľ­nej sú­čas­ti všet­kých ak­ti­vít. Ako ho­vo­rí ci­tát jed­né­ho z ot­cov ma­naž­men­tu kva­li­ty E. De­min­ga, „kva­li­ta je zod­po­ved­nosť všet­kých". A potvr­dzu­je to aj vý­rok H. For­da: „Kva­li­ta je ro­be­nie správ­nych ve­cí, aj keď sa nik­to ne­po­ze­rá." Pre­to sa snaž­me ne­ro­biť z do­sa­ho­va­nia kva­li­ty len ak­ti­vi­tu ale­bo po­vin­nosť, ale zvyk.

Autor: Sta­nis­lav On­dáč, En­terpri­se Ar­chi­tect, Tat­ra ban­ka, a. s.

Zdroj: IW 11-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