Architekt vs Projektový manažér - spojenci, či nepriatelia?

Tie­to ro­ly exis­tu­jú v kaž­dom väč­šom pro­jek­te, ale na­priek to­mu ich spo­lup­rá­ca čas­to nep­re­bie­ha tak hlad­ko ako by sa oča­ká­va­lo. Je dô­vod v sa­mot­ných ro­lách, ale­bo le­ží úpl­ne in­de?

Pred­stav­me si po­čia­toč­nú fá­zu pro­jek­tu, kde ar­chi­tekt pri návr­hu zis­tí, že no­vý mo­dul mu­sí čí­tať časť dát z pro­prie­tár­ne­ho sys­té­mu XY. Ten­to sys­tém však ne­pos­ky­tu­je žiad­ne štan­dar­dné on­li­ne roz­hra­nia. Ar­chi­tekt pre­to navr­hne od­tie­niť sys­tém na ESB vrstve, čo zna­me­ná tvor­bu no­vých roz­hra­ní. Roz­po­čet je ako tra­dič­ne veľ­mi ob­me­dze­ný a inter­ný zá­kaz­ník si ne­mô­že do­vo­liť za­pla­tiť tie­to no­vé roz­hra­nia. Pro­jek­to­vý ma­na­žér (PM) pre­to žia­da od ar­chi­tek­ta al­ter­na­tív­ny návrh. Veď pred­sa už te­raz sys­tém AB čí­ta dá­ta zo sys­té­mu XY. Ar­chi­tekt ar­gu­men­tu­je, že dáv­no v mi­nu­los­ti vznik­la pria­ma in­teg­rá­cia na da­ta­bá­zu sys­té­mu XY, ale ten­to smer nie je žia­da­ný do bu­dúc­na. Hlav­ne keď v bu­dúc­nos­ti plá­nu­je­me sys­tém XY mig­ro­vať na no­vú plat­for­mu, pre­to­že exis­tu­jú­ca je už za­sta­ra­ná. Za­dá­va­teľ však ne­má pe­nia­ze na­vy­še, a pro­jekt pot­re­bu­je kvô­li kon­ku­ren­cii do­dať čo naj­skôr.

Ďal­ším prík­la­dom je si­tuácia, keď ar­chi­tekt navr­hne na­mies­to roz­ší­re­nia exis­tu­jú­cej ap­li­ká­cie vy­tvo­riť no­vú, pre­to­že sta­rá už na to nie je veľ­mi vhod­ná. V ce­ne veľ­ký roz­diel nie je, ale zna­me­ná to znač­né ča­so­vé predĺže­nie a ri­zi­ko no­vé­ho rie­še­nia. Pro­jek­to­vý ma­na­žér pre­to opäť na­mie­ta a navr­hu­je dr­žať sa jed­no­duch­šej (zná­mej) ces­ty.

V člán­ku pod­rob­nej­šie pred­sta­ví­me tie­to dru­hy kon­flik­tov, s pred­nos­tným za­me­ra­ním na poh­ľad ar­chi­tek­tú­ry, kto­rá je pri­már­ne zod­po­ved­ná za to, akým spô­so­bom bu­de pro­jekt reali­zo­va­ný po ob­sa­ho­vej strán­ke.

Dô­vo­dy kon­flik­tov

Čo je dô­vo­dom tých­to kon­flik­tov? Zo­ber­me si kla­sic­ký tro­ju­hol­ník pro­jek­to­vé­ho ria­de­nia, kto­rý tvo­ria Ce­na, Čas a Roz­sah resp. Kva­li­ta. PM strá­ži čas, ce­nu aj roz­sah. Ar­chi­tekt mu­sí pri návr­hu brať do úva­hy všet­ky tie­to di­men­zie, av­šak čas­to sa sna­ží aj o za­me­ra­nie na kva­li­ta­tív­ne - ne­fun­kcio­nál­ne po­žia­dav­ky(napr. dos­tup­nosť, vý­kon­nosť, udr­ža­teľ­nosť ). V kri­té­riách na zá­kla­de kto­rých je pro­jekt hod­no­te­ný, tá­to pos­led­ná zlož­ka čas­to chý­ba. Tro­ju­hol­ník nám ho­vo­rí, že ak ov­plyv­ní­me je­den fak­tor (napr. ar­chi­tekt vlo­ží väč­ší dô­raz na kva­li­tu ako bol pô­vod­ne plá­no­va­ný), ov­plyv­ní­me tým auto­ma­tic­ky os­tat­né fak­to­ry - napr. ce­nu, ale­bo čas - te­da at­ri­bú­ty hod­no­te­nia pro­jek­tu. Ar­chi­tekt sna­žia­ci sa o väč­šiu kva­li­tu rie­še­nia pre­to v dis­ku­sií o sme­ro­va­ní pro­jek­tu čas­to ťa­há za krat­ší ko­niec.

Tu je vhod­né pou­ká­zať na je­den pa­ra­dox. IT pro­jekt je re­la­tív­ne krát­ko­do­bá en­ti­ta, kto­rá do­dá­va sys­té­my s väč­ši­nou dl­hotr­va­jú­cou pô­sob­nos­ťou. A prá­ve kva­li­ta návr­hu má čas­to vplyv na ce­nu i čas ďal­ších úp­rav tý­ka­jú­cich sa da­né­ho sys­té­mu, po­čas je­ho cel­ko­vé­ho ži­vot­né­ho cyk­lu. Pre­to hod­no­tiť pro­jekt iba na zá­kla­de krát­ko­do­bých cie­ľov nie je správ­ne. Vy­spe­lé or­ga­ni­zá­cie už pri hod­no­te­ní vy­šli z hra­níc štar­tu a ukon­če­nia pro­jek­tov a sle­du­jú aj napl­ne­nie sľu­bo­va­ných prí­no­sov v dl­ho­do­bom ho­ri­zon­te. Tu je však kri­tic­ké ne­po­rov­ná­vať nap­rík­lad vý­no­sy z pre­da­ja no­vé­ho pro­duk­tu s ce­nou pro­jek­tu, ale brať do úva­hy cel­ko­vú nák­la­do­vú po­lož­ku bu­si­ness ca­se, vrá­ta­ne vzni­ka­jú­cich ope­ra­tív­nych nák­la­dov a do­da­toč­ných in­ves­tí­cii po ukon­če­ní pro­jek­tu. Ak PM vie už na za­čiat­ku pro­jek­tu, že to čo do­dá bu­de na­ďa­lej sle­do­va­né a hod­no­te­né aj po "go-li­ve" je­ho čin­nosť a zmýš­ľa­nie na­do­bú­da­jú úpl­ne iný roz­mer. Veľ­mi po­dob­ná si­tuácia je aj v rám­ci ar­chi­tek­tú­ry. V or­ga­ni­zá­ciách s niž­šou vy­spe­los­ťou sa ar­chi­tek­ti za­me­ria­va­jú hlav­ne na návrh rie­še­nia, kto­ré napl­ní fun­kčnosť, čas a roz­po­čet. Vo vy­spe­lej­ších je ar­chi­tekt zod­po­ved­ný za roz­voj "svo­jich" ap­li­ká­cii z dl­ho­do­bé­ho hľa­dis­ka, na­prieč rôz­ny­mi pro­jek­tmi, kto­ré ich pos­tup­ne me­nia. Tá­to zod­po­ved­nosť mô­že byť pre­miet­nu­tá do je­ho MBO, bo­nu­so­vých schém atď. Prob­lé­my pri­ro­dze­ne vzni­ka­jú ak sú vy­spe­los­ti jed­nej ale­bo dru­hej ob­las­ti roz­diel­ne. Aj tu je pre­to dô­le­ži­té klásť dô­raz na ria­de­ný ce­loor­ga­ni­zač­ný roz­voj IT (IT Go­ver­nan­ce).

Pred­chá­dzanie kon­flik­tom

Vráť­me sa k prob­lé­mo­vej si­tuá­cii uve­de­nej na za­čiat­ku. Ako jej mož­no pre­dísť?

Tvor­ba Road­ma­py - Otáz­kam ďal­ších in­ves­tí­cii ale­bo spô­so­bov roz­ši­ro­va­nia sys­té­mu XY sa mož­no vy­hnúť, ak by exis­to­val jas­ný plán je­ho roz­vo­ja. Ten mu­sí za­hŕňať ako poh­ľad zá­kaz­ní­ka ( napr. plá­no­va­nie no­vých fun­kcio­na­lít do bu­dúc­na) tak aj poh­ľad IT do­dá­va­te­ľa (napr. pod­po­ra do­dá­va­te­ľov pre tech­no­lo­gic­kú plat­for­mu, vý­voj štan­dar­dov na tr­hu atď.). Ak tie­to dva poh­ľa­dy ne­bu­dú nav­zá­jom zla­de­né, sa­mé o se­be mô­žu v road­ma­pe vy­tvá­rať ďal­šie kon­flik­ty. Ces­tou k zla­de­niu sú pra­vi­del­né stret­nu­tia zá­stup­cov IT a biz­ni­su(napr. vo for­me špe­ciál­nej ko­mi­sie), kde dis­ku­tu­jú a potvr­dzu­jú zme­ny s do­pa­dom na road­ma­py, ako aj sa­mot­né por­tfó­lio pro­jek­tov.

Sko­rý návrh ar­chi­tek­tú­ry - Dru­hým spô­so­bom je ar­chi­tek­to­nic­ký návrh prip­ra­ve­ný v čo naj­skor­šej fá­ze pro­jek­tu. Ideál­ne pri je­ho ini­cia­li­zá­cii keď sa eš­te len for­mu­je pred­sta­va o roz­poč­te a cel­ko­vom plá­ne. Tie by ma­li byť v ideál­nom prí­pa­de vy­tvo­re­né prá­ve na zá­kla­de hru­bé­ho návr­hu ar­chi­tek­tú­ry. Exis­ten­cia road­máp vie v tom­to oh­ľa­du veľ­mi na­po­môcť. Sa­moz­rej­me pla­tí, že v tej­to fá­ze čas­to nie je mož­né poz­nať všet­ky po­žia­dav­ky, a te­da ani rá­tať v návr­hu so všet­ký­mi ne­že­la­ný­mi si­tuácia­mi.

Zvy­šo­va­nie vy­spe­los­ti - rôz­ne úrov­ne vy­spe­los­ti pri­ro­dze­ne pod­po­ru­jú vznik kon­flik­tov. Tak ako di­eťa ne­vie čas­to po­cho­piť roz­mýš­ľa­nie dos­pe­lé­ho, ne­vie ani jed­na ne­vys­pe­lá ob­lasť pl­ne spo­lup­ra­co­vať s inou viac vy­spe­lou. Rie­še­ním je už spo­mí­na­né zvy­šo­va­nie a zla­ďo­va­nie ma­tu­ri­ty pro­jek­to­vé­ho ma­naž­men­tu aj ar­chi­tek­tú­ry. Ak sa obo­je bu­dú sna­žiť ak­tív­ne hľa­dať kom­pro­mis me­dzi napĺňa­ním krát­ko­do­bých aj dl­ho­do­bých cie­ľov, kon­flik­ty sa mô­žu pre­me­niť na hľa­da­nia no­vých príl­eži­tos­ti.

Rie­še­nie kon­flik­tov

Ak vy­ššie uve­de­né pred­pok­la­dy nie sú napl­ne­né, ale­bo ne­fun­gu­jú správ­ne, vzni­ká kon­flikt, kto­rý je pot­reb­né rie­šiť.
Es­ka­lá­cia a do­ho­da - Naj­čas­tej­ším spô­so­bom je vy­uži­tie kla­sic­ké­ho es­ka­lač­né­ho me­cha­niz­mu k spon­zo­ro­vi resp. zá­kaz­ní­ko­vi pro­jek­tu. V prí­pa­de sna­hy o ne­že­la­né pre­sa­de­nie krát­ko­do­bých cie­ľov by si mal ar­chi­tekt pri ko­mu­ni­ká­cii uve­do­miť, že zá­kaz­ník je vlas­tne je­ho spo­je­nec. Pre­to­že je to prá­ve on, kto ži­je s da­ným sys­té­mom dl­ho­do­bo a cí­ti na vlas­tnej ko­ži do­pa­dy nes­práv­nych roz­hod­nu­tí. Je pre­to viac ochot­ný chá­pať po­žia­dav­ky na kva­li­tu, ako PM kto­rý je hod­no­te­ný za do­da­nie v ča­se, roz­poč­te a do­hod­nu­tom roz­sa­hu. Sa­moz­rej­me aj tu exis­tu­je ri­zi­ko neús­pe­chu. Zá­kaz­ník na stra­ne biz­ni­su je tak­tiež čas­to hod­no­te­ný na zá­kla­de kvar­tál­nych ale­bo polroč­ných cie­ľov, kto­ré ho trá­pia viac, ako to, či sa mu zvý­šia nák­la­dy za 2-3 ro­ky. No ak pres­ved­čí zá­kaz­ní­ka o pot­re­be zme­ny, po­tom ani PM ne­má dô­vod na ne­súh­las­ný pos­toj.

Vy­uži­tie prin­cí­pov a štan­dar­dov - Chce­me pri tvor­be no­vej ap­li­ká­cie pou­žiť kra­bi­co­vé rie­še­nie, ale­bo open sour­ce? Je or­ga­ni­zá­cia prip­ra­ve­ná na obid­va va­rian­ty? Na tie­to a ob­dob­né otáz­ky by ma­li dá­vať od­po­veď za­de­fi­no­va­né ar­chi­tek­to­nic­ké prin­cí­py, kto­ré vzni­ka­li do­ho­dou IT aj biz­ni­su. Tým­to spô­so­bom mož­no ošet­riť množ­stvo čas­to sa opa­ku­jú­cich sce­ná­rov a ušet­riť si čas aj ener­giu v rám­ci pro­jek­tu. 

Evi­den­cia dl­hu - sú si­tuácie, ke­dy kva­li­ta­tív­ny poh­ľad ne­zís­ka väč­šiu vá­hu, a vy­hra­je pot­re­ba rých­le­ho a lac­né­ho rie­še­nia. Kvô­li pot­re­be rých­lej reak­cie na zme­ny na tr­hu to do­kon­ca mô­že byť v da­nej chví­li správ­ny prís­tup. Tie­to si­tuácie je však pot­reb­né dôs­led­ne evi­do­vať. Dô­vo­dy sú dva. Pr­vý je pot­re­ba náp­ra­vy v bu­dúc­nos­ti s kto­rou by sa ma­lo rá­tať už v rám­ci reali­zá­cie "ne­čis­té­ho" rie­še­nia. Dru­hý je vy­tvá­ra­nie ar­gu­men­tá­cie pre ob­dob­né prí­pa­dy do bu­dúc­nos­ti. Čím viac má­me in­for­má­cii o zlých rie­še­niach v mi­nu­los­ti, tým ľah­šie im vie­me pred­chá­dzať v bu­dúc­nos­ti. Pr­vý z dô­vo­dov vy­ža­du­je aj ur­či­tú zme­nu kul­tú­ry or­ga­ni­zá­cie a nie je ľah­ko reali­zo­va­teľ­ný. Dru­hý je však re­la­tív­ne bez­prob­lé­mo­vý, a na­priek to­mu sa na ne­ho v or­ga­ni­zá­ciách za­bú­da. Tu je dô­le­ži­té po­dot­knúť, že ten­to dlh by mal byť evi­do­va­ný cen­trál­ne, a sa­mos­tat­ne - mi­mo pro­jek­to­vej do­ku­men­tá­cie (napr. v re­gis­tri ri­zík), kto­rá sa po ukon­če­ní pro­jek­tu už čas­to vô­bec nes­le­du­je.

Zá­ver

Krát­ko­do­bé cie­le pro­jek­tu sú dô­le­ži­té, ale čas­to sa nep­reu­ka­zu­jú ako to naj­pod­stat­nej­šie. Stav­ba Ope­ry v Syd­ney tr­va­la o nie­koľ­ko ro­kov dlh­šie op­ro­ti plá­nu, a roz­po­čet bol prek­ro­če­ný viac ako de­sať­ná­sob­ne. Nad­ča­so­vá ar­chi­tek­tú­ra pri­ná­ša­la po­čas reali­zá­cie množ­stvo prob­lé­mov. Te­raz je to jed­no z naj­nav­šte­vo­va­nej­ších tu­ris­tic­kých miest a veľ­ká pý­cha Aus­trá­lie. Je te­da pro­jekt mož­né po­va­žo­vať za neús­peš­ný, pre­to­že zly­hal v krát­ko­do­bých cie­ľoch, ale pri­nie­sol dl­ho­do­bý a znač­ný prí­nos?

Ar­chi­tekt i PM ma­jú v ko­neč­nom dôs­led­ku rov­na­ký zá­mer - napl­niť oča­ká­va­nie zá­kaz­ní­ka. V ideál­nom prí­pa­de je sna­že­nie ar­chi­tek­ta v sú­la­de s tým, čo zá­kaz­ník po­ža­du­je a PM sa sna­ží do­dať. Ten­to že­la­ný stav mož­no do­siah­nuť po­mo­cou vy­spe­lé­ho por­tfó­lio ma­naž­men­tu a pod­ni­ko­vej ar­chi­tek­tú­ry. Kon­flik­ty kto­ré po­čas pos­tup­né­ho zvy­šo­va­nia vy­spe­los­ti vzni­ka­jú net­re­ba brať ne­ga­tív­ne. Sú zna­kom to­ho, že ne­že­la­né si­tuácie sú iden­ti­fi­ko­va­né a exis­tu­je sna­ha o ich náp­ra­vu. To je pr­vý krok k ich od­strá­ne­niu. Za­me­ra­nie ar­chi­tek­ta a PM na rôz­ne as­pek­ty pro­jek­tu je tiež žia­du­ce, pre­to­že sa vzá­jom­ne dopĺňa­jú, čím pok­rý­va­jú šir­ší poh­ľad na vý­sled­né rie­še­nia a zvy­šu­jú prav­de­po­dob­nosť cel­ko­vej spo­koj­nos­ti zá­kaz­ní­ka.

Sta­nis­lav On­dáč, Tat­ra ban­ka


Ohodnoťte článok:
   
 

24 hodín

týždeň

mesiac

Najnovšie články

In­for­mač­ná bez­peč­nosť: Geog­ra­fic­ky dis­tri­buo­va­ná ochra­na dát
Ako minimalizovať výpadok IT služieb a stratu dát v dôsledku nepriaznivých udalostí. Zatiaľ čo v predošlej dekáde stačilo chrániť pred výpadkom niektoré aplikácie.  čítať »
 
Pla­te­ná rek­la­ma vs. op­ti­ma­li­zá­cia SEO – vý­ho­dy, ne­ga­tí­va, mož­nos­ti
Špecialisti na SEO tvrdia, že správnou optimalizáciou webu máte šancu získať oveľa viac ako platenou reklamou. Naproti tomu experti na platenú reklamu argumentujú dosahovaním rýchlych a merateľných výsledkov. čítať »
 
Ar­chi­tekt vs Pro­jek­to­vý ma­na­žér - spo­jen­ci, či ne­pria­te­lia?
Tieto roly existujú v každom väčšom projekte, ale napriek tomu ich spolupráca často neprebieha tak hladko ako by sa očakávalo. Je dôvod v samotných rolách, alebo leží úplne inde? čítať »
 
Ap­pli­ca­tion De­li­ve­ry – efek­tív­na ochra­na pro­ti hac­ke­rom a op­ti­ma­li­zá­cia vý­ko­nu slu­žieb
Sú vaše webové služby chránené proti hackerom? Programátori často urobia chyby, ktoré dokážu útočníci zneužiť.   čítať »
 
Cloud com­pu­ting: Oča­ká­va­nia a reali­ta, preh­ľad pos­ky­to­va­te­ľov (Ama­zon, Goog­le, IBM, Mic­ro­soft)
Cloud computing, technológia predstavujúca model zdieľania hardvérových zdrojov pomocou virtualizácie a automatizácie, v súčasnosti naberá rýchlosť pri globálnom rozširovaní sa do celého spektra sektorov poskytujúcich obrovské množstvo služieb. čítať »
 
Dá­ta nie sú len ved­ľaj­ším pro­duk­tom pre­vádz­ky IS
Na otázku, ako stručne hodnotíte informačný systém vašej organizácie, by sme dostali mnoho rôznych odpovedí. čítať »
 
BYOD pod­po­ru­je ino­vač­né ini­cia­tí­vy ta­len­to­va­ných za­mes­tnan­cov
Jeden z charakteristických atribútov trendu BYOD je možnosť vynútenia technologického pokroku v IT podpore biznisu „zdola", najčastejšie zo strany mladších používateľov. čítať »
 
Li­cen­čnú čis­to­tu je ťaž­ké us­trá­žiť
Pre licenčného manažéra je znalosť aktuálnych licenčných podmienok od dvoch až troch výrobcov softvéru na všetok využívaný softvér v spoločnosti nedosiahnuteľná méta. čítať »
 
 
 
  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