(Microsoft Word - Magistrsko delo, Janez Ko\232ir - lektorirano.doc)

Transkripcija

1 UNIVERZA V MARIBORU FAKULTETA ZA ORGANIZACIJSKE VEDE Management kakovosti Management kakovosti storitev Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih Mentor: red. prof. dr. Tomaž Kern Kandidat: Janez Košir Kranj, maj 2010

2 Zahvala Zahvaljujem se mentorju red. prof. dr. Tomažu Kernu za njegovo pomoč pri izdelavi magistrskega dela. Zahvaljujem se tudi lektorici Katji Kobe, ki je lektorirala moje magistrsko delo.

3 Povzetek Pri prenovi procesov lahko informacijska tehnologija odigra zelo pomembno vlogo. Res pa je, da lahko nepravilna uporaba informacijske tehnologije pripelje do rešitev, ki so delne, ki ne upoštevajo celote in dajejo v splošnem zelo slabe rezultate. Pravi pristop pri reševanju težav je tako dvostopenjski. Na prvi stopnji je treba opredeliti potrebne značilnosti poslovnega procesa, ki poteka v organizaciji, in ga temeljito prenoviti. Na drugi stopnji pa je treba prenovljenemu poslovnemu procesu zagotoviti organizacijsko in informacijsko podporo. V magistrskem delu je predstavljen model nadgradnje informacijskega sistema za vodenje projektov v IT podjetjih z metodologijo CMMI in Scrum. Teoretični del magistrskega dela je namenjen raziskavi in obdelavi teoretičnih spoznanj o prenovi poslovnih procesov, informatizaciji poslovnih procesov, projektnem vodenju, sestavljenemu modelu zrelostnih nivojev - metodi CMMI (Capability Maturity Model Integrated), agilni metodologiji razvoja programske opreme - metodologiji Scrum in povezovanju teh dveh metodologij. Ugotovitve teoretičnega dela so uporabljene v aplikativnem delu raziskave, kjer je opisan potek prenove projektnega informacijskega sistema Prosis. Zaključki raziskave nas pripeljejo do ugotovitve, da lahko na podlagi uporabljenih teoretičnih in metodoloških izhodišč, sestavimo model informacijskega sistema za vodenje projektov, ki ga je možno učinkovito vpeljati v IT podjetja, ki imajo omejeno število zaposlenih. Pri tem je nadgrajeni informacijski sistem za vodenje IT projektov v skladu z tretjim zrelostnim nivojem modela CMMI in z modelom Scrum. Z upoštevanjem navodil za izboljšave lahko podjetje pristopi k formalni uvedbi modela CMMI in Scrum ter tako pridobi večjo dodano vrednost na že zasičenem in vse zahtevnejšem svetovnem trgu izdelave programske opreme. Ključne besede projektni informacijski sistem prenova poslovnih procesov metoda CMMI metodologija Scrum

4 Abstract When reengineering a process the information technology plays an important role. Incorrect use of this information technology can bring us to only partial solutions that are not whole and give in general bad results. A better approach to reengineer a process must be a two level approach. The purpose of first level is to define the necessary characteristics of the business process and renew the process. The intention of level two is to assure organisational and information support to the renewed process. In this master s thesis will be presented a model of upgrading information system with methodologies CMMI and Scrum in project management in IT companies. The theoretical part of the thesis is used for research and processing theoretical comprehension in reengineering business process, information of business process, project management, composed model of maturity levels- method CMMI and agile methodology of software developing- method Scrum. We need to compare the connection between these two methods. Findings gathered in theoretical part of the thesis were used in application section where description of reengineering an information system is given. On the basis of theoretical and methodological starting-points described in theoretical part we can create information system model for project management. This model can be efficiently introduced into IT companies in which number of employees is limited. The renewed information system for managing IT projects is conformable with third maturity level of CMMI model and also Scrum model. A company can be formally introduced to CMMI and Scrum model when considering all possible improvements. It gives a company an additional value. Keywords Project Information system Business Process Reengineering CMMI method Scrum method

5 1 Uvod Izhodišča in delovna hipoteza Cilji in namen raziskave Predpostavke in omejitve raziskave Utemeljitev in prispevek k znanosti Metode dela - metodologija Teoretična in metodološka izhodišča Poslovni procesi Osnove prenove procesov Informatizacija poslovnih procesov Projektno vodenje Projekt Projektne organizacijske strukture Značilnosti projektnega vodenja Model CMMI ali sestavljen model zrelostnih nivojev Zgodovina CMM(I) Podmodeli CMMI Komponente CMMI Zrelostni nivo CMMI Napredovanje po nivojih Zahtevane, pričakovane in informativne skupine komponent modela Procesna področja Kategorizacija procesnih področji modela CMMI Metodologija Scrum Zgodovina Karakteristika in pravila Scrum-a Sestavine Scrum-a Ogrodje metodologije Vloge pri metodologiji Scrum Dokumenti metodologije Scrum Proces razvoja z metodologijo Scrum Analiza delovanja metodologije Scrum Razširjena uporaba Scrum-a Povezovanje metod CMMI in Scrum Scrum kot meta model Model merjenja Informacijski sistem za podporo upravljanju in vodenju IT projektov Zahteve za informacijski sistem za podporo upravljanju in vodenju projektov Informacijska podpora projektu in uporabljene informacijske tehnologije Projektni informacijski sistem Prosis Dokumentacijski in informacijski podsistem Prosis-a Arhitektura sistema Prosis... 57

6 3 Aplikativni del Mikro in mala IT podjetja Osnovni podatki o podjetju IT projekti Posnetek trenutnega stanja razvoja informacijskih rešitev Posnetek trenutnega stanja vodenja projekta pri razvoju informacijskih rešitev Pobuda projekta Projekt Življenjski cikel projekta Projektna mapa Poročanje Analiza trenutnega stanja Splošne smernice za prenovo informacijskega sistema Priložnost za nadgradnjo Predlogi rešitev Uvedba principov agilnih metodologij Prenovljeni življenjski cikel projekta Prenova procesa izvajanja projekta Dnevnik izdelka/projekta Dnevnik teka Rezultati merjenja Evidenca dela Urne postavke Hitri pregled (ang. Quicklist) Vnos novih zahtevkov Prilaganje dokumentov Vodenje evidence o nedelovnih dneh Rezultati merjenja Lastnosti Scrum kazalnikov in metrik po metodologiji CMMI Spremljanje izvedbe Scrum projektov na podlagi interesnih skupin Zaključki in posplošitev Strnjeni odgovori na raziskovalna vprašanja Ali je mogoče s takšnim nadgrajenim informacijskim sistemom povečati učinkovitost projektov? Ali je mogoče s takšnim nadgrajenim informacijskim sistemom povečati učinkovitost podjetja? Ali je takšen nadgrajen informacijski sistem primeren za vse vrste projektov? Nadaljnji razvoj, raziskave in možnosti Literatura in viri Kazalo slik Kazalo tabel Pojmovnik Kratice in akronimi... 96

7 1 Uvod V skladu z načelom TQM-a je vsak proizvod rezultat enega ali več procesov. Zato je najbolj učinkovit način za izboljšanje kakovosti proizvoda izboljšati proces, ki se uporablja za proizvodnjo izdelka ali storitve. Proces daje rezultate. Proizvod je odvisna spremenljivka procesa, zato se je potrebno osredotočiti predvsem na proces (Marolt, 2005). Procesi se izvajajo v vsaki organizaciji oz. sistemu. Vodstvo je odgovorno, da so nedvoumno določene usmeritve in cilji organizacije ter zagotovljeni potrebni viri za učinkovito izvajanje procesov. Rezultati procesov morajo izpolnjevati zahteve in pričakovanja kupcev, saj so le zadovoljni kupci zagotovilo za dolgoročen in uspešen razvoj organizacije. Zato vodstvo v procesnem pristopu ugotavlja priložnosti za nenehno izboljševanje in na tej osnovi proizvode, procese in sisteme nenehno izboljšuje. Podjetje mora preiti od sedanjega k prihodnjemu poslovanju. Zamisliti si mora poti, ki ga bo pripeljala iz sedanjosti v prihodnost. Tako kot je mogočih več ciljev, obstaja tudi več poti v prihodnost. Ključne dolgoročne poti so strategije, ki so v bistvu premik med sedanjim stanjem in cilji. Modeli pa so opisne strukture strategij, s katerimi strategije načrtujemo. Strategije nadalje vodijo v strateški poslovni načrt podjetja, leta pa bi moral voditi v strateško načrtovanje informatike. Informacijska tehnologija prinaša nove priložnosti. Če jih hočemo razumeti in izrabiti, moramo poznati tehnologijo, ki bo na voljo v prihodnjih letih. Ker jo bodo ljudje uporabljali več in na nove načine, se bodo organizacije spreminjale. Spoznanja o smereh in obsegu sprememb bodo koristna zato, da bo mogoče izrabiti uporabo informacijske tehnologije za zavestno preoblikovanje organizacije, da bodo bolj učinkovite, uspešne in prilagodljive in da se bodo ljudje v njih bolje počutili. Podoben obseg sprememb informacijske tehnologije, kakršen je bil v minulih tridesetih letih, je mogoče pričakovati v naslednjih desetih do petnajstih letih. V pol krajšem času bodo nastale spremembe na višji stopnji spirale sprememb (Možina 2002:623). Podjetja se danes srečujejo s kruto realnostjo: predvidevati, odzivati se in reagirati na vedno večje zahteve trga ali pa propasti. V tem konkurenčnem okolju poslovna strategija ne samo, da določa in zagotavlja vire, ampak zagotavlja tudi preživetje podjetja. Danes se bolj kot kdajkoli doslej učinkovita poslovna strategija osredotoča na agresivno in učinkovito uporabo informacijske tehnologije. Celovite programske rešitve (ERP Enterprise Resource Planning) so skupek poslovnih programskih orodij, ki omogočajo podjetjem, da učinkovito obvladujejo in zagotavljajo vire (material, človeški viri, finančni viri, idr.) z uporabo celovite in integrirane rešitve za informacijsko procesne potrebe podjetja. Le-ta zagotavlja procesni vidik tako na poslovanje kot tudi na poslovne procese, ki so standardizirani znotraj podjetja. Najpomembnejši atributi ERP sistema so: avtomatizacija in integracija organizacijsko poslovnih procesov; zagotavljanje enotnih podatkov v celotnem podjetju; Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 6

8 pridobivanje in dostop do informacij v realnem času (Nah, 2001:285). Celovite rešitve ERP podpirajo celovito poslovanje vključno s podporo procesu projektnega vodenja. Z učinkovitim izvajanjem delovnih procesov s pomočjo informacijske podpore se zagotavlja uspešno poslovanje z najnižjimi možnimi stroški, v časovno opredeljenih rokih izvedbe in z optimalno izkoriščenimi viri ter v skladu s standardi kakovosti. V magistrski nalogi je prikazana nadgradnja informacijskega sistema za vodenje IT projektov. Informacijski sistem je nadgrajen tako, da organizacija deluje po modelu CMMI in Scrum, pri tem pa komunikacije tečejo preko nadgrajenega informacijskega sistema, ki to omogoča. Izhajali smo iz sestavljenega modela zrelostnih nivojev (CMMI Capability Maturity Model Integrated), ki temelji na ideji, da za izboljšanje učinkovitosti razvoja programske opreme (PO) ni dovolj uporaba novih tehnologij in orodij, temveč je potrebno poskrbeti predvsem za kakovosten, dobro definiran in nadziran proces razvoja PO. Model je bil razvit za potrebe ameriškega obrambnega ministrstva in velikih softwerskih hiš, ki zanj razvijajo PO, zato je predvsem uporaben v velikih organizacijah. Velja mnenje, da uvajanje modela CMMI v majhnih organizacijah pomeni preveč režije, ki si je te ne morejo privoščiti. Ker pa imajo tako majhne kot tudi velike organizacije pri razvoju podobne primere, smo v magistrski nalogi prikazali način, kako CMMI model prilagoditi tudi majhni organizaciji. V nadaljevanju magistrske naloge smo model CMMI poskušali nadgraditi s Scrum metodo. Scrum je primarni iterativni proces razvoja programske opreme in je ena izmed agilnih metod razvoja PO. Scrum je skelet procesa, ki vsebuje niz praks in vnaprej določene vloge. Scrum omogoča ustvarjanje samoorganizirajočih se skupin s spodbujanjem kolokacije za vse člane ekipe. Hkrati spodbuja tudi govorno komunikacijo med vsemi člani ekipe in disciplinami, ki so vključene v projekt. Scrum deluje na empiričnem pristopu, torej na predpostavki, da problema ni mogoče v celoti razumeti in opredeliti. Tako se namesto osredotočanja na maksimiranje zmožnosti ekipe, osredotoča na hitro odzivanje na nastajajoče zahteve. Uvajanje praks CMMI za merjenje in analizo procesov z metodo Scrum je opisano z namenom spremljanja in izboljševanja procesa razvoja programske opreme. 1.1 Izhodišča in delovna hipoteza Hipoteza: Model CMMI z nadgradnjo Scrum metode je mogoče učinkovito uporabiti tudi v majhnih podjetjih, pod pogojem, da je podprt z ustreznim projektnim informacijskim sistemom. Pri tem predpostavljamo, da informacijski sistem za vodenje projektov postane orodje za izmenjavo informacij na vseh organizacijskih nivojih. Informacijski sistem tako ni namenjen le razvijalcem, da ti vnesejo ure opravljenih del na posameznih projektih, ter projektnim vodjem, da pregledujejo status opravljenih del. Informacijski sistem za vodenje projektov postane nujno orodje v organizaciji, ki deluje po modelu Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 7

9 CMMI in Scrum. V magistrski nalogi smo na podlagi testiranja v realnem okolju pridobili odgovore na naslednja raziskovalna vprašanja: Ali je mogoče s takšnim nadgrajenim informacijskim sistemom povečati učinkovitost projektov? Ali je mogoče s takšnim nadgrajenim informacijskim sistemom povečati učinkovitost podjetja? Ali je takšen nadgrajen informacijski sistem primeren za vse vrste projektov? 1.2 Cilji in namen raziskave Namen naloge je preučiti upravljanje in vodenje izvajanja projektov ter analizirati teoretična izhodišča metod CMMI in Scrum. V praktičnem delu je predstavljen predlog implementacije teh metod v obstoječi model konkretnega podjetja. Prikazan je posnetek stanja upravljanja in vodenja projektov v danem informacijskem sistemu za vodenje IT projektov. Z vpeljavo metod CMMI in Scrum želimo dokazane slabosti odpraviti, a ne na račun obstoječe funkcionalnosti. Prvi cilj magistrske naloge je, da ob prikazu teoretičnih spoznanj o upravljanju in vodenju izvajanja projekta, sestavimo model, ki se ga lahko učinkovito vpelje v IT podjetja, ki imajo omejeno število zaposlenih. Drugi cilj pa je, da se nadgradi informacijski sistem za vodenje IT projektov, ki je v skladu z tretjim zrelostnim nivojem modela CMMI in z modelom Scrum. 1.3 Predpostavke in omejitve raziskave Naloga je omejena na mikro in mala IT podjetja. 55. člen Zakona o gospodarskih družbah navaja (Uradni list RS, št. 42/2006), da se družbe pri uporabi tega zakona razvrščajo na mikro, majhne, srednje in velike družbe z uporabo naslednjih meril na bilančni presečni dan letne bilance stanja: povprečno število delavcev v poslovnem letu; čisti prihodki od prodaje in vrednost aktive. Mikro družba je družba, ki izpolnjuje dve od teh meril: povprečno število delavcev v poslovnem letu ne presega deset; čisti prihodki od prodaje ne presegajo evrov in vrednost aktive ne presega evrov. Mala družba je družba, ki ni mikro družba po prejšnjem odstavku in ki izpolnjuje dve od teh meril: Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 8

10 povprečno število delavcev v poslovnem letu ne presega 50; čisti prihodki od prodaje ne presegajo evrov in vrednost aktive ne presega evrov. V nalogi smo se pri prenovi procesov omejili na klasično organizacijo, ki zadostuje kriterijem malega IT podjetja (primeri so vzeti iz praks). Potrditev hipoteze je dokazana teoretično, iz obstoječih praks in izkušenj. Dokazano je, da je model CMMI z nadgradnjo Scrum metode vpeljiv v informacijski sistem za vodenje IT projektov. 1.4 Utemeljitev in prispevek k znanosti Sodobna organizacija procesov temelji na vnovičnem združevanju nalog, timskem delu, celovitem vodenju in upravljanju procesov, integrirani informacijski podpori in partnerski povezavi s kupci in dobavitelji. Pri prenovi poslovnih procesov je treba upoštevati dejavnosti, s katero se podjetje ukvarja ter kulturo in okolje, v katerem deluje. Od tega je odvisen način prenove posameznih procesov (klasični reinženiring, kjer procese in povezave med njimi postavimo popolnoma na novo, ali postopne izboljšave obstoječih poslovnih procesov). Funkcijska in procesna oblika organiziranosti sta le dve skrajnosti, med katerima je treba iskati optimalno obliko organiziranosti za podjetja, kjer nameravamo izpeljati prenovo poslovnih procesov. Procesna organiziranost je laže izvedljiva v organizacijah z enotnim sistemom dela, kar se odraža v celovitem procesu. V primeru organizacij z več sistemi dela oziroma z delavniškim načinom dela je uvajanje in izvajanje procesne organiziranosti bolj zapleteno. To pa seveda ne pomeni, da je procesna organiziranost nemogoča. Izvesti jo je mogoče z ustrezno računalniško podporo, ki iz enega mesta omogoča nadzor nad izvedbo posameznih faz v procesu (Vila, 1997; Tavčar, 2002). V magistrski nalogi je s pomočjo študija teoretičnih osnov metod CMMI in Scrum ter povezave obeh metod predstavljen model vpeljave, ki naj bi predstavljal prispevek k teoriji in praksi na področju prenove poslovnih procesov, s poudarkom na uvajanju oziroma nadgraditvi celovite informacijske podpore v mala in mikro IT podjetja, za katera je značilen hiter tehnološki razvoj. 1.5 Metode dela - metodologija Pri izdelavi magistrske naloge je bil osnovni pristop študij literature, povezane z eno in/ali drugo metodo. Predvsem smo si želeli izhajati iz novejših izsledkov raziskav, kar pomeni, da je večji poudarek na tuji literaturi. V teoretičnem in metodološkem delu magistrske naloge so uporabljene metode analiza (razčlenitev pridobljenih spoznanj), komparacija (primerjava različnih virov in pogledov), sinteza (združitev oziroma izdelava zaključkov) in deskripcija (opis doseženega stanja in predlogi za izboljšanje stanja). Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 9

11 V aplikativnem delu magistrske naloge pa je izdelana nadgradnja informacijskega sistema za vodenje IT projektov. Ta nadgradnja temelji na teoretičnih spoznanjih iz teoretičnega dela te magistrske naloge. Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 10

12 2 Teoretična in metodološka izhodišča 2.1 Poslovni procesi Nova organizacijska paradigma zagovarja sodobno reklo:»nič ni stalnega, razen sprememb«, zato moramo s svojim delom vzpostavljati pogoje, v katerih bomo uspeli izkoristiti nove priložnosti. Že leta 1862 je v sporočilu ameriškemu kongresu na to opozoril Abraham Lincoln, ko je rekel, da so dogme mirne preteklosti neprimerne za viharno sedanjost in da je potrebno ustrezno novim situacijam spremeniti obstoječi način mišljenja in dela (Stanonik, 2000:296). Živimo v obdobju velikih sprememb na področju poslovanja, ki jih prinaša napredek informacijske tehnologije. Klasične strategije so samo delno uporabne ali pa sploh neuporabne, še posebej za vse tiste gospodarske in javne organizacije, v katerih je informacija pomemben ali celo prevladujoč gradnik predmeta trženja in nastopa na trgu. Dogajajo se siloviti procesi, ki izbrana podjetja zavihtijo med uspešna, ostala pa»zavržejo«. Vse bolj se zdi, da močni informacijski tokovi podjetja, ki ne ujamejo zadnjega vlaka v informacijsko družbo, izrivajo na stranpoti, kjer praviloma samo še usahnejo. Učinkovito izvajanje strateških ciljev lahko podjetje izpelje le skozi pregledno in učinkovito izvajanje poslovnih procesov. Eno izmed ključnih vlog pri tem v današnjem času zagotovo igra informacijski sistem podjetja, ki mora po funkcionalni in tehnološki plati primerno podpirati izvajanje temeljnih poslovnih procesov in strateških usmeritev podjetja. Izraba informacijske tehnologije je vir konkurenčne prednosti za vse organizacije, zato je ključnega pomena, da se informacijsko tehnologijo vgradi v teorijo poslovanja zaradi vsaj treh razlogov (Stemberger, 2001): Sposobnost in potenciali informacijske tehnologije se nenehno povečujejo; ta kot vir konkurenčnih prednosti organizacije doživlja najhitrejšo rast in najbolj dramatične spremembe. Informacijska tehnologija igra ključno vlogo v učinkovitejšem izvajanju operative neke organizacije in je temelj boljšega managementa organizacije na naslednje načine: - skrajšuje čase (ciklične, razvojne, proizvodne, tržne), - zmanjšuje potrebo po odvečnem premoženju (zalogah, opremi, denarju) in ljudeh, - izboljšuje delo s strankami in hitreje sledi njihovim potrebam, - povečuje možnost delegiranja na najnižje organizacijske nivoje, - povečuje znanje organizacije ter ustvarja pogoje za učenje in - delitev znanja. Doba interneta je vpeljala nova pravila naročanja, procesiranja naročila in dobavljanja proizvodov oziroma storitev, s tem da je organizacijam omogočila prenos dela poslovanja ali celotnega poslovanja kar na spletne strani. Internet omogoča popolnoma nove temelje organiziranosti neke organizacije, razvoja in proizvajanja nekega izdelka oziroma storitve. Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 11

13 V različnih strokovnih literaturah, imamo na vprašanje kaj je poslovni proces, več različnih odgovorov oziroma opredelitev: Hammer in Champy opredeljujeta poslovni proces kot seštevek dejavnosti, ki zahteva eno vrsto ali več vrst vložkov in ustvarja rezultat, ki za odjemalca pomeni neko vrednost (Hammer, 1993:45). Davenport ga opredeli kot strukturiran in merjen set aktivnosti, ki so oblikovane tako, da zagotovijo nek izdelek ali neko storitev za določenega kupca na tržišču (Davenport, 1993:5). Smith definira poslovni proces kot nabor aktivnosti, ki kupcu predstavljajo neko vrednost. Predstavlja tok materiala, informacij in poslovnih obveznosti od zasnove do prodaje izdelka ali storitve. Proces navadno traja dolgo in je podprt z informacijskimi tehnologijami. Njegove aktivnosti se lahko izvajajo avtomatsko ali ročno (Smith, 2002:44). Kovačič opredeli poslovni proces kot skupek logično povezanih izvajalskih in nadzornih postopkov ter aktivnosti, katerih posledica oziroma izid je načrtovani izdelek ali storitev (Kovačič, 2005:29). Mikeln pa opredeljuje poslovne procese kot zaokrožene samostojne celote v okviru celotnega poslovnega dogajanja, ki jih je mogoče ločiti od drugih in jih samostojno obravnavati. Imajo svoje cilje v okviru celotnega podjetja in v svojem toku spreminjajo vložke v rezultate, preko katerih se povezujejo z drugimi procesi v okviru poslovanja podjetja (Mikeln, 1996:103). Bistvo zgoraj navedenih opredelitev je skupen vhod in izhod ter ustvarjanje dodane vrednosti. Poslovni procesi so kompleksni, dinamični, distribuirani in prilagojeni. Prehajajo skozi različne oddelke in različne informacijske sisteme. Tako so dejanski procesi v organizacijah (Smith, 2002): obsežni in zapleteni; vključujejo tok materiala, podatkov in poslovnih pravil; zelo dinamični, saj se morajo prilagajati spremembam tržišča; distribuirani in prilagojeni glede na poslovne zahteve in glede na aplikacije in tehnološke platforme; dolgo trajajoči posamezen proces lahko teče dneve, mesece, celo leta; vsaj delno avtomatizirani z informacijsko tehnologijo; odvisni od človeške presoje: ljudje delajo naloge, ki so preveč kompleksne in ne strukturirane, da bi jih računalnik lahko izvajal, ali pa so to naloge, ki zahtevajo človeško komunikacijo; na primer osebno interakcijo s stranko; velikokrat nevidni in jih je težko narediti vidne: procesi ponavadi niso eksplicitni in zavedni, ampak implicitni, nezavedni, nedokumentirani in vgrajeni v zgodovino organizacije Osnove prenove procesov Izraz»prenova poslovnih procesov«se je prvič pojavil leta 1990 v dveh publikacijah. Uporabil ga je Davenport, ki pravi, da uporaba sodobne informacijske tehnologije ne predstavlja le avtomatizacije opravil, temveč tudi neposredno vpliva na način in kakovost njihovega izvajanja (Davenport, 1993). Podobnega mnenja je bil tudi Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 12

14 Michael Hammer v članku»re-engineering work: Don t Automate, Obliterate«. Oba sta bila mnenja, da morajo organizacije, kadar razmišljajo o prenovi poslovnih procesov, razmišljati o uporabi informacijskih tehnologij, ki bodo pomagale povezati poslovne procese. Bistvo prenove poslovnih procesov je diskontinuirano razmišljanje. Hammer in Champy (Hammer, 1995:12 15) trdita, da je potrebno pozabiti, kako smo delali včeraj, pomembno je, kako želimo podjetje organizirati danes glede na zahteve in želje današnjih trgov in zmogljivosti današnjih tehnologij. Potrebno je prepoznati in opustiti zastarela pravila. Podobno meni tudi Kovačič, ki pravi, da to zahteva korenite spremembe v poslovanju podjetij in mora vodstvo najprej zavreči neuporabna, uveljavljena pravila in postopke ter opustiti neprimerna sedanja organizacijska in izvedbena načela. Šele nato je mogoče začeti s ponovnim načrtovanjem organizacije (Kovačič 1998:84). V tuji in domači literaturi se uporablja več različnih izrazov za prenovo poslovnih procesov. Hammer in Champy sta prenovo poslovnih procesov opredelila kot vnovični premislek o poslovnem procesu in njegovo korenito preoblikovanje, da bi s tem dosegli velike izboljšave kritičnih kazalcev učinkovitosti, kot so stroški, kakovost in hitrost. Avtorja menita, da se je treba prenove lotiti temeljito, radikalno in dramatično. To so tudi ključni pojmi, s katerimi sta avtorja opredelila prenovo poslovnih procesov (Hammer, 1995:42): Temeljni: pri prenovi poslovnega procesa si moramo zastavljati vprašanja o svojem načinu dela:»zakaj delamo to, kar delamo?«,»zakaj to delamo?«. Zastavljena vprašanja prisilijo ljudi, da razmišljajo o nenapisanih pravilih in pravilih, ki se skrivajo v načinu vodenja poslovanja. Pogosto se izkaže, da so pravila zastarela, napačna in neustrezna. Prenova se začne brez predpostavk. Ugotoviti moramo, kaj naj podjetje naredi in kako bo to naredilo. Pozabiti je treba na obstoječe stanje in misliti na to, kako bi moralo biti. Radikalni (koreniti): proces želimo raziskati do temeljev. Ne želimo le površno spreminjati tistega, kar že imamo, ampak oblikovati povsem nove procese in načine opravljanja dela. Dramatični: ne gre le za drobne in postopne izboljšave, ampak za preskok. Tako kot Hammer in Champy zagovarjata radikalne spremembe pri prenovi poslovnih procesov, enako tudi Davenport vidi v radikalnih spremembah edini način doseganja potrebnih izboljšav oziroma prenove poslovanja, kar utemeljuje z dejstvom, da v obdobju intenzivne konkurence kakovostne spodbude in neprestane postopne izboljšave procesov, čeprav nujne, ne bodo več zadostne. Pri prenovi poslovnih procesov je moč prepoznati štiri ključne prvine, ki tvorijo jedro prenove poslovnega procesa. Te so naslednje: Prenova prinaša radikalne ali vsaj zelo pomembne spremembe. Enota prenove je celovit poslovni proces, ki se na primer razteza od naročila do dostave izdelka, kot nasprotje poslovnim procesom po oddelkih. Prenova skuša doseči pomembne cilje ali dramatične napredke v uspešnosti poslovanja organizacije. Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 13

15 Informacijska tehnologija je ena izmed ključnih pospeševalcev prenove. Prenova poslovnih procesov ni namenjena zgolj podjetjem, ki so na robu preživetja, temveč jo izvajajo tudi in predvsem najuspešnejša podjetja. Hammer in Champy sta uvrstila podjetja, ki se lotevajo prenove, v naslednje tri skupine (Hammer, 1995:44): Podjetja, ki so zašla v hude težave in nimajo nobene druge izbire. Podjetja morajo prenoviti svoje poslovanje, kadar so njihovi stroški bistveno višji od stroškov tekmecev, kadar jih odjemalci odkrito kritizirajo glede njihovega poslovanja in je situacija tako kritična, da potrebujejo vrsto izboljšav. Podjetja, ki niso v težavah, vendar njihovo vodstvo vidi, da vanje bredejo. Njihovi poslovni rezultati so trenutno še zadovoljivi, vendar se že pojavljajo prvi konkurenti, spreminjajo se zahteve glede izdelkov ali storitev ter obstajajo nevarnosti, da podjetja zabredejo v resne težave. Taka podjetja bi morala začeti izvajati prenovo poslovnih procesov. Podjetja, ki so med najuspešnejšimi v svoji dejavnosti, vendar pa vodstvo in zaposleni vidijo v prenovi priložnosti za večanje prednosti pred konkurenti Informatizacija poslovnih procesov Prenova poslovnih procesov, ki temelji na jasno oblikovani strategiji podjetja na najvišjem nivoju, lahko služi za temeljit zasuk k uspešnemu in učinkovitemu delu. Informacijska tehnologija pa je tista, ki omogoča spremembe in prilagajanja organizacij, saj postajajo razpoložljive informacijsko-tehnološke zmogljivosti vse temeljnejše za izvajanje informacijskega procesa v poslovnem sistemu. Informacijska tehnologija je lahko le podpora poslovni strategiji podjetja in potrebna podlaga ter merilno orodje predvsem za finančni vidik uspešnosti. Informatizacija poslovnih procesov še zdaleč ne pomeni le nakup drage računalniške opreme, pač pa današnji moderni pristopi zahtevajo povsem drugačno razmišljanje in zanemarjajo dejstva iz preteklosti. Nepravilna uporaba tehnologije vodi do slabih ali delnih rešitev, ki ne prinašajo neposrednih koristi. Zato je v podjetju ali organizaciji najprej treba opredeliti in razumeti značilnosti obstoječih poslovnih procesov ter jih nato v sodelovanju s strateškim načrtovanjem in ob upoštevanju vizije podjetja temeljito prenoviti. V naslednjem koraku pa je potrebno prenovljene poslovne procese informatizirati in jim zagotoviti tudi ustrezno organizacijsko in kadrovsko podporo. Sodobni načini prenove in informatizacija poslovanja se v zadnjem obdobju pri prenovi poslovanja usmerjajo k uporabi tehnoloških in procesnih možnosti ter najboljše prakse celovitih programskih rešitev (ERP Enterprise Resource Planning). Celovite programske rešitve lahko opredelimo kot povezan in na poslovnem modelu organizacije temelječ sistem, ki z uporabo sodobne informacijske tehnologije vsem poslovnim procesom, tako same organizacije kot tudi z njo povezanih poslovnih partnerjev, zagotavlja optimalne možnosti načrtovanja, razporejanja virov in ustvarjanja dodane vrednosti. Uvajanje celovitih rešitev temelji na konceptu prenove poslovanja oziroma na prenosu najboljše prakse, zajete v teh rešitvah v posamezno organizacijo in v njeno neposredno okolje. Menimo, da takšna rešitev bistveno vpliva na čas, kakovost in stroške projekta prenove (Kovačič, 2005). Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 14

16 Če bo podjetje informacijsko tehnologijo in ostale sodobne koncepte kot sredstvo za upravljanje strateških prednosti želelo uporabljati tudi v prihodnosti, bo moralo uporabiti številne prihajajoče tehnologije in se spopasti s številnimi novimi koncepti in paradigmami. 2.2 Projektno vodenje Projektno vodenje oziroma projektni management najenostavnejše opišemo kot usklajevanje aktivnosti, ljudi in razmerji med njimi, in sicer z namenom učinkovitega doseganja cilja projekta (Meredith, 2000) oz. ga opišemo kot aplikacijo znanja, veščin, tehnik in orodij v aktivnostih projekta za dosego zastavljenih ciljev (PMBOK, 2008) Projekt Podjetja izvajajo svoje delo, da bi dosegla zastavljene cilje. Načini dela se med seboj razlikujejo. Glede na število ponovitev istega dela ga lahko razdelimo na procesno delo in projekt. Ti kategoriji se med seboj lahko tudi prepletata, saj imata podobne značilnosti, ki pa so v projektu bistveno bolj opazne. Skupne značilnosti procesnega dela in projekta so: oba izvajajo ljudje; omejena sta s sredstvi ter sta načrtovana, izvedena in nadzorovana. Projekt je začasno prizadevanje za uresničitev edinstvenega izdelka, storitve ali rezultata.»začasno«pomeni, da ima vsak projekt določen začetek in določen konec. Konec dosežemo, ko so uresničeni cilji projekta, ali ko postane jasno, da cilji projekta ne bodo ali ne morejo biti doseženi, ali ko ni več potrebe po projektu in je projekt končan.»začasno«ne pomeni nujno, da projekt traja kratek čas; mnogo projektov traja več let. Kakorkoli že, v vsakem primeru je trajanje projekta končno. Projekti niso del tekočega oz. operativnega poslovanja. Projekt uresničuje edinstvene izdelke oz. delne rezultate (ang. deliverables), ki so lahko izdelki (ang. products), storitve ali rezultati. Edinstvenost je pomembna značilnost izdelkov oz. delnih rezultatov projekta. Na primer, na tisoče poslovnih zgradb je že bilo zgrajenih, toda vsak posamezen objekt je edinstven različni so lastniki, različne lokacije, različni pogodbeniki ipd. Ponovljive prvine ne spreminjajo temeljne edinstvenosti projektnega dela (PMBOK, 2008). Kaj je projekt, lahko prikažemo še z različnimi definicijami tega pojma, kot ga navaja strokovna literatura o projektnem vodenju; te definicije se v večini primerov med seboj ne izključujejo. Hauc (2002:26-28) je zbral nekaj definicij, ki opredeljujejo pojem»projekt«in jih povzemamo v nadaljevanju: Kerzner (1992:2) obravnava projekt kot vsak sklop aktivnosti in nalog, ki imajo določen cilj, opredeljen s konkretnimi značilnostmi, s točno opredeljenim Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 15

17 začetkom in koncem, z omejenimi finančnimi viri, za izvedbo pa potrebuje različne vire; po Clelandu (1999:5) je projekt kombinacija organizacijskih potencialov, ki želijo ustvariti določeno novost, ki bo podjetju zagotavljala sposobnost oblikovanja in uresničevanja strategije; vsi projekti imajo določen življenjski ciklus in potekajo kot zaporedje posameznih faz; po Lewisu (1998:8) je projekt delo, ki se izvede samo enkrat; imeti mora jasen začetek in konec ter opredeljen proračun in načrt, kako naj bo izveden; čeprav so te zahteve teoretično idealne, jih je treba v praksi pri usmerjanju prizadevanj postaviti v izhodiščni cilj; Turner (1993:36) opredeljuje projekt kot prizadevanje, v katerem so ljudje, material in finančni viri organizirani na izviren način z namenom izvedbe znotraj omejenih stroškov in časa edinstvenega obsega nalog, s poudarjenimi specifikacijami, s katerimi se dosežejo ugodne spremembe, ki se kažejo v količinskih in kakovostnih ciljih; Andersen (2004:24) navaja, da je projekt edinstveno, časovno omejeno delo, t.j. naloga, ki se formira za dosego specifičnega rezultata in veže različne vire; po definiciji, ki sta jo objavila Lienz in Rea (1999:12), je projekt delo, pri katerem se z ustreznim razporejanjem virov dosegajo specifični cilji in preko njih definiran namen projekta; cilji projekta so lahko ozko usmerjeno definirani in se nanašajo na določen sistem ali tehnologijo, lahko pa so širši in se nanašajo na izboljšave poslovnih procesov. Navedene definicije projektov, bi lahko združili v enotno misel, saj se definicije med seboj ne izključujejo se kvečjemu dopolnjujejo, tako bi se skupna definicija glasila, da projekt lahko opredelimo kot enkraten, neponovljiv proces, ki je sestavljen iz povezanih in med seboj odvisnih aktivnosti, za katerimi stojijo ljudje in sredstva. Aktivnosti se izvajajo tako, da nas vodijo od enega do drugega vmesnega cilja in nato do končnega cilja, to je zaključka projekta. Končni cilj vsakega projekta je, da je le-ta izveden znotraj finančnih in časovnih načrtov, da zagotavlja zahtevano kakovost in da je izveden znotraj v dogovorjenem obsegu. Projekt ima nek začetek in vnaprej določen datum zaključka (ang. deadline). Projekt mora biti vodljiv, to pa zahteva organiziranje in vodenje izvajanja skozi celotno trajanje projekta. Organiziranje se mora prilagoditi vrsti projekta in organizacijski strukturi, v kateri se projekt izvaja Projektne organizacijske strukture V strokovni literaturi najdemo različno tipologijo organizacijskih struktur. Pri razvrščanju tipov organizacijske strukture vsi avtorji menijo, da ni organizacijske strukture, ki bi bila najprimernejša za vse vrste organizacij v vseh časih in v vseh okoljih (Kavčič, 1991:184). Diferenciranje v organizacijah se dosega s pomočjo delitve celotne naloge na naslednjih podlagah: funkcijah, proizvodih, geografskih področjih, trgih, proizvodnih procesih in proizvodni opremi. Takšne so tudi temeljne razdelitve organizacijske strukture (Kavčič, 1991:186): funkcijska organizacijska struktura; Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 16

18 produktna organizacijska struktura; organizacijska struktura na podlagi geografskih področij; tržna organizacijska struktura; procesna organizacijska struktura; struktura na podlagi opreme; časovna organizacijska struktura; linijska organizacijska struktura; linijsko štabna organizacijska struktura; funkcionalizirana linijsko štabna organizacijska struktura in matrična organizacijska struktura. V projektnem delu je vrsta projekta tisti element, ki v praksi vpliva na raznolikost in kompleksnost potrebne organizacijske strukture in s tem projektne organizacije. Prednosti projektne organizacijske strukture, v primerjavi s klasično, so (Urh, 2003:13): organizacija skrbi samo za realizacijo dejavnosti, ki so povezane s projektom; zagotovljeno je centralno zbiranje in vrednotenje informacij v projektu; visoka stopnja fleksibilnosti razvoja zaposlenih iz zunanjih in notranjih virov; motiviranost zaposlenih, ker sodelujejo pri zanimivih nalogah, idr. Kljub predstavljenim prednostim pa projektna organizacija prinaša nekatere težave oz. nevarnosti, kot so nevarnost vodstvene hipertrofije 1, nasprotja med projektnim gledanjem in funkcijskim obravnavanjem organizacijskih problemov, nevarnost razočaranja zaradi nerealno zastavljenih ciljev, nestalnost članov projektne skupine ipd. V osnovi ločimo tri oblike projektne organizacije (Hauc, 2002: ): Čisto projektno organizacijo To je samostojna organizacija projektnega managementa. Nastopa kot vzporedna organizacija notranji organizaciji podjetja. Vodstvo te organizacije prevzame za projekt polno odgovornost. Projektni sodelavci so vključeni v to organizacijo za čas trajanja projekta. Njena notranja organiziranost se mora prilagoditi značilnostim projekta. Vplivno projektno organizacijo - Imenovana je tudi štabni projektni management oziroma funkcijska organizacijska struktura s projekti. Vodja projekta ima samo omejene naloge in pristojnosti, najpogosteje v obliki koordinacije in morebiti še načrtovanja predvsem pri pripravi zagona projekta. Nastopa kot projektna koordinacija na najvišji ravni. Problem te oblike projektne organizacije je v delitvi odgovornosti za projekt med najvišjim, funkcijskim in projektnim managementom. Ta oblika je sporna predvsem zato, ker vodja projekta ne more v celoti odgovarjati za čas, stroške in pričakovanja v zvezi s cilji projekta. Matrično projektno organizacijo Ta predstavlja združitev čiste in vplivne organizacije z razmejitvijo nalog in odgovornosti med linijsko oziroma funkcijsko organizacijo podjetja ter organizacijo projektnega vodenja. Izvajalec projekta je po eni strani odgovoren svojemu funkcijskemu vodstvu, po drugi pa tudi projektnemu ravnatelju. 1 SSKJ: knjiž. pretirano povečanje česa: hipertrofija nevažnih podatkov; hipertrofija političnih strank / hipertrofija administrativne miselnosti Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 17

19 2.2.3 Značilnosti projektnega vodenja Projektno vodenje je uporaba znanja, veščin, tehnik in orodij v aktivnostih projekta za izpolnitev njegovih (projektnih) zahtev. Projektno vodenje realiziramo z uporabo in integracijo procesov projektnega vodenja; ti so: zagon, planiranje, izvajanje, spremljanje in kontroliranje ter končanje. Projektni vodja je oseba, odgovorna za realiziranje ciljev projekta. Obvladovanje projekta vključuje: prepoznavanje zahtev; določanje jasnih in uresničljivih ciljev; uravnoteženje izključujočih (konkurenčnih) zahtev glede kakovosti, obsega, časa in stroškov; prilagajanje specifikacij, planov in prijemov kot posledica raznolikih vidikov in pričakovanj različnih udeležencev projekta (PMBOK, 2008). Procesi projektnega vodenja so si v večini projektov podobni in usmerjeni k povezovanju aktivnosti za doseganje skupnega rezultata ter predstavljajo inicializacijo, planiranje, izvedbo, opazovanje in nadzor ter zaključevanje posameznega projekta. Ti procesi predstavljajo procesne skupine projektnega vodenja, ki so medsebojno povezane v različnih oblikah. Slika 1: Načelo ponavljanja izboljševanja (Marolt, 2005) Povezanost procesov oziroma procesnih skupin v projektnem vodenju lahko najbolje ponazorimo s ciklusom PDCA, to v angleščini pomeni Plan Do Check Act oziroma v slovenščini planiraj izvrši preveri ukrepaj (PMBOK, 2008). PDCA ciklus je vedno predstavljen kot krog, ki ponazarja stalnost narave izboljševanja. Stalnosti izboljševanja ni mogoče doseči brez ponavljanja. Z večkratno ponovitvijo ciklusa postopoma dosežemo višji nivo kakovosti izdelkov in storitev (Marolt, 2005). Ideja ponavljanja PDCA ciklusa predstavlja slika 1. P Plan planiraj: analitično in kvantitativno določiti, kateri so ključni problemi pri obstoječem procesu ali obstoječi dejavnosti, in planirati dejavnost za izboljšavo. D Do izvrši: izvršiti planirane dejavnosti. C Check preveri: potrditi kvantitativno in analitično (z rezultati), da je planirana Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 18

20 izboljšava dosežena. A Act ukrepaj: dokumentirati spremenjen proces, ga standardizirati in izboljšanega v prihodnje uporabljati. Stalno izboljševanje potrebuje povratne informacije o trenutnem stanju, da bi se ugotovilo ali proces poteka skladno s predvidenim ciljem. Če se ugotovi, da dejansko stanje ni v skladu s pričakovanji, je potrebna izboljšava. Tekom poteka procesa je to potrebno storiti večkrat. Ljudje pogosto zmotno mislijo, da je dovolj narediti plan le na začetku in da bodo vse dejavnosti potekale idealno in da bo dosežen cilj brez občasnega preverjanja, analize povratnih informacij in izboljševalnih dejavnosti tekom celotnega časa izvajanja procesa proizvodnje (Marolt, 2005). Slika 2: Procesne skupine projektnega vodenja v ciklusu PDCA (PMBOK, 2008) V procesu projektnega vodenja gre za pet procesnih skupin, in sicer (PMBOK, 2008): inicializacijo (gre za procese, ki so povezani z začetkom projekta in njegovim definiranjem, s postavljanjem njegovih meja ter procesi za končno odobritev projekta); planiranje (v tej skupini so procesi povezani s postavljanjem objektivnih ciljev, z planiranjem smeri poteka projekta in s pripravo za izvedbo); izvedbo (sem spadajo vse aktivnosti, ki s pomočjo ustreznih virov pripomorejo k doseganju projektnih ciljev); spremljanje in nadzor (ta skupina združuje procese, ki redno merijo in ocenjujejo postopek izvedbe projekta ter zaznavajo morebitne odklone, tako da je možno popraviti posamezne aktivnosti in na ta način doseči zastavljen cilj projekta); zaključevanje (to so procesi, ki so namenjeni predstavitvi rezultatov in formalni zaključitvi projekta). Medsebojna povezanost procesnih skupin kljub temu ni tako enostavna, kot je to Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 19

21 predstavljeno v ciklusu PDCA, čeprav je za ponazoritev medsebojnih razmerij tak prikaz zelo primeren. Procesna skupina»planiranje«se poistoveti z delom cikla P (plan) oziroma»planiraj«, procesna skupina»izvedba«z delom cikla D (do) oziroma»naredi«, procesna skupina»opazovanje in nadzor«z delom cikla C (check) oziroma»preveri«in A (act) oziroma»ukrepaj«. Ker pa je projektno vodenje začasen proces, predstavlja»inicializacija«začetek ciklusa in»zaključevanje«njegov konec. Pri tem moramo poudariti, da je procesna skupina»opazovanje in nadzor«prepletena z vsemi drugimi procesnimi skupinami in predstavlja ogrodje ciklusa (PMBOK, 2008). Omenjeni ciklus je grafično prikazan na sliki Model CMMI ali sestavljen model zrelostnih nivojev Sestavljen model zrelostnih nivojev (ang. CMMI Capability Maturity Model Integration) je model za zagotavljanje kakovostnega razvoja programske opreme (v nadaljevanju PO) in je bil razvit na Software Engineering Institute (SEI) na univerzi Carnegie Mellon v ZDA (Chrissis, 2003). Model je bil razvit za potrebe ameriškega obrambnega ministrstva in velikih podjetji, ki zanj razvijajo PO, zato je neposredno uporaben predvsem v velikih organizacijah. V majhnih organizacijah pogosto menijo, da dosledno uvajanje modela CMMI pomeni preveč režije, ki si je same ne morejo privoščiti. Vendar pa tako v majhnih kot velikih organizacijah nastopajo pri razvoju PO enaki problemi, le da je razsežnost teh različna. Vsak razvoj PO potrebuje vsaj učinkovito obvladovanje uporabnikovih zahtev, vodenje projektov, komunikacijo z uporabnikom, jasno razdelitev zadolžitev, načrtovanje, dokumentirane procese, primerno organizacijo dela in podobno. Prav tako se tudi v majhnih organizacijah dviga zavest o nujnosti uvajanja sistemov kakovosti, saj je to temeljni pogoj za dolgoročno preživetje in razvoj. Ker model CMMI samo predpisuje aktivnosti, ki morajo biti prisotne v procesu razvoja PO, ne določa pa načina realizacije, imajo majhna podjetja dovolj manevrskega prostora, da zahteve modela prilagodijo svojim ciljem in načinu poslovanja. Model CMMI temelji na ideji, da za izboljšanje učinkovitosti razvoja programske opreme (v nadaljevanju PO) ni dovolj uporaba novih tehnologij in orodij, temveč je treba poskrbeti predvsem za kakovosten, dobro definiran in nadziran proces razvoja PO. V okviru nivojske (ang. staged) predstavitve modela je definiranih pet zrelostnih nivojev (ang. maturity levels) tega procesa. Vsak nivo ustrezno definira karakteristike procesa, ki jih mora izpolnjevati organizacija, če želi doseči ta nivo zrelosti. Za vsak nivo so določena procesna področja (ang. process areas), (splošni in posebni) cilji (ang. generic, specific goals) in (splošne in posebne) prakse (ang. generic, specific practices). Model CMMI se uporablja za ocenjevanje organizacij za razvoj PO na dva načina: z namenom izboljšanja procesa razvoja PO (s strani njih samih) ter z namenom ugotovitve zmožnosti za izvedbo naročila (s strani naročnikov). Tak pristop zagotavlja objektivnost in primerljivost rezultatov. Model zahteva vgraditev mehanizmov, ki omogočajo trajno doseganje zastavljenih ciljev. Obstaja splošno mnenje, da model primerno definira nadziran proces razvoja PO, zato pogosto služi Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 20

22 kot vodilo za izboljševanje kakovosti procesa razvoja PO. Modeli CMMI s postopno zastopanostjo odražajo zrelostne nivoje zasnov in vsebin. Zrelostne nivoje sestavljajo povezane posebne in splošne prakse za vnaprej določene postopke področji, ki izboljšujejo splošno delovanje organizacije. Zrelostne nivoje organizacije podajajo način za predvidevanje uspešnosti organizacije v določeni disciplini ali nizu disciplin. Izkušnje so pokazale, da organizacije dajo od sebe najboljše takrat, ko osredotočijo svoja prizadevanja za izboljšanje procesa na obvladljivo število procesnih območjih in to na tistih področjih, ki zahtevajo povečanje razvitosti kot izboljševanje organizacije (Chrissis, 2003). Zrelostni nivo je opredeljen kot evolucijska raven za organizacijske procesne izboljšave. Vsak zrelostni nivo stabilizira pomemben del organizacijskih procesov, z namenom, da se pripravi predpogoj za na naslednji zrelostni nivo. Zrelostni nivoji se merijo z dosego posebnih in splošnih ciljev povezanih z vsakim predhodno določenim nizom procesnih območji. Obstaja pet nivojev zrelosti, vsak je temelj za stalno izboljševanje procesa, ki jih določimo s števili od 1 do 5 in ponazarjajo zrelost celotne organizacije. Vsak nivo predstavlja skupina procesnih področij, ki se pojavi v enem nivoju samo enkrat. Zrelostni nivo organizacije omogoča načrtovanje bodočih zmožnosti združbe ali organizacije znotraj ene ali znotraj skupine dejavnosti. Zrelostni nivoji so: 1. Začetni ali kaotični (ang. Initial) 2. Voden (ang. Managed) 3. Definiran (ang. Defined) 4. Kvantitativno voden (ang. Quantitatively Managed) 5. Optimizirajoč (ang. Optimizing) Zgodovina CMM(I) Na začetku 80.let prejšnjega stoletja so se letalske sile ZDA (US Air Force) srečale z ogromno težavo pri izbiri programskih rešitev za podporo svojih sistemov. Ker ministrstvo za obrambo ZDA ni moglo sestaviti skupine za izdelavo programske opreme, ki bi zagotavljala maksimalno kakovost in zanesljivost programske opreme, je bila ena izmed rešitev dodeliti naloge izbranim združbam iz ZDA. Izkazalo se je, da je izbor teh družb zelo zahtevna in odgovorna naloga, zato so po neuspešnih poskusih uvajanja TQM l razpisali natečaj za izbiro univerze, ki bi pomagala pri projektu. Ta naloga je bila dodeljena univerzi Carnegie Mellon, ki je za ta namen leta 1984 ustanovila SEI (Software Engineering Institute, ang. kratica za Inštitut za računalniško inženirstvo). Inštitut SEI je kmalu pokazal, da so se letalske sile ZDA ukvarjale z napačnim problemom: Osredotočili so se na izbiro usposobljenih ljudi, a so kmalu opazili, da so vsi projekti hitro zašli v težave, ne glede na to, kdo je pri njih sodeloval. Nato so se odločili, da se raje posvetijo izboljšanju ocenjevanja načina izdelave programske opreme pri združbah kot ocenjevanju ljudi.«tako je leta 1987 nastala prva verzija CMM (ang. Capability and Maturity Model), ki Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 21

23 je bila narejena na principu vprašalnika. Ta je bil narejen z namenom, da izloči družbe, ki so imele dobre prakse v organizacijskih pri izdelavi PO. Hitro se je ugotovilo, da so združbe, ki so si zelo želele tako dobro plačanih projektov, začele "zlorabljati" te vprašalnike. Izpolnjevale so jih tako, da so ugodile naročniku (Ministrstvu za Obrambo ZDA) in si s tem zagotovile zmago na natečajih. Da bi se izognili takim situacijam, je SEI l izdelal novo in izboljšano različico "najboljših praks" (ang. best practices). Med drugim je bila izboljšava te verzije tudi v tem, da je izboljšala način preverjanja resničnosti trditev združb, ki so hotele napredovati znotraj CMM. V ta namen je bila določena skupina nadzornikov napredka (ang. appraisers). Le-te je najprej izbral, nato pa še dodatno usposabljal SEI. Njihova naloga je bila preverjati, ali to, kar združbe trdijo, da delajo, res naredijo. Leta 1993 je nastala verzija CMM v1.1. Veliko število dobrih praks je bilo hierarhično organiziranih v 18 ključnih področij (ang. key process area), 52 ciljev (ang. goal), 316 značilnih praks (ang. key practices) in podpraks (ang. subpractices). Model je bil opisan na 500 straneh dokumentacije. CMM je bil predstavljen na dva načina, nivojsko (ang. staged) in zaporedno (ang. continuous). Prva predstavitev je bila namenjena ocenjevanju zrelosti procesov celotne organizacije, druga pa je bila bolj primerna za ocenjevanje zrelosti posameznih ključnih področij organizacije. Prva verzija CMMI nastane leta Njeni predhodniki, Software CMM (l. 1992) in Systems Engineering CMM (l. 1994), so sicer bili narejeni v okviru CMM, vendar se pri obravnavi zgodovine štejejo med osnove za model CMMI. Leta 1997 je bilo delo na modelu CMM uradno ustavljeno in leta 1998 je nastala prva verzija CMMI Product Suite. Za njo sta nastali eni izmed pomembnejših verzij CMMI-SE/SW v1.0 (l. 2001) in CMMI-SE/SW/IPPD/SS v1.1 (l. 2002), ki v obeh različicah (zaporedno in nivojsko) obsega več kot 700 strani Podmodeli CMMI Skupina izdelkov CMMI (ang. Product suite) je narejena iz ogrodja (ang. framework). Le-to omogoča sestavljanje v celoto različnih podmodelov in učinkovito povezuje gradivo za izobraževanje ter napredovanje v CMMI. Podmodeli omogočajo znanja s področij, ki se jih organizacija odloči uporabiti. Odločitev je izbira organizacije na podlagi profesionalnih razsodb. Obstajajo štirje podmodeli glede na znanje, ki ga vsebujejo: sistemsko-inženirski model (ang. System engineering); inženirstvo programske opreme (ang. Software engineering); integriran izdelčni in procesni razvoj (ang. Integrated product and process development), v nadaljevanju IPPD; model sodelovanja s podizvajalcem (ang. Supplier sourcing). Podmodeli bodo v nadaljevanju imenovani discipline, in sicer discipline kot panoge in ne kot nekaj, kar zahteva dosledno upoštevanje pravil. Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 22

24 Sistemsko-inženirska disciplina Ta disciplina pokriva razvoj celotnih sistemov, ki lahko vsebujejo programsko opremo, ali pa je tudi ne. Sistemsko inženirstvo, kot je znano, pretvarja strankine potrebe in pričakovanja v izdelčne rešitve in podporo teh rešitev v času uporabljanja izdelka. Opis te discipline vsebuje področja CMMI iz procesnega vodenja (ang. Process management), projektnega vodenja (ang. Project management), podpore (ang. Support) in inženirstva (ang. Engineering process area). Ojačevalniki disciplin (ang. Discipline amplifiers), ki so značilni za to disciplino, so na voljo zaradi lažjega razumevanja specifičnih praks. Disciplina inženirstva programske opreme To je disciplina, ki se osredotoča na uporabo sistematskih, discipliniranih in izmerljivih pristopov za razvoj, proizvodnjo in vzdrževanje programske opreme. Pri izbiri te discipline bo model vseboval naslednja področja CMMI: procesno vodenje, projektno vodenje, podporo in inženirstvo. Tudi za to disciplino obstajajo specifični ojačevalniki disciplin, ki bodo opisani v nadaljevanju. Integriran izdelčni in procesni razvoj IPPD je sistematičen pristop, ki omogoča popolno sodelovanje interesentom (ang. stakeholders) v celotnem življenjskem ciklu izdelka. Ti subjekti sodelujejo z namenom, da izboljšajo zahteve in potrebe strank. Procesi, ki podpirajo IPPD v CMMI, so vsebovani v drugih procesih, ki jih združba ali organizacija uporablja. Samo področja CMMI, specifični cilji (ang. specific goals) in specifične prakse znotraj CMMI ne morejo brez sodelovanja drugih procesov v združbi. Če združba izbere IPPD CMMI, se je dejansko odločila za izbiro vsaj dveh ali več disciplin v CMMI. Integriran izdelčni in procesni razvoj vsebujeta naslednja področja CMMI: procesno vodenje, projektno vodenje, podporo in inženirstvo, ki se v tem primeru nanašajo na vse izbrane discipline. Tudi za to disciplino obstajajo specifični ojačevalniki disciplin, ki so namenjeni za lažjo razlago specifičnih praks. Sodelovanje s podizvajalcem V zadnjem desetletju je bilo opaziti veliko povečanje kompleksnosti izdelkov, kar je imelo posledice tudi v poslovnem svetu, v katerem so se začele uveljavljati prakse podizvajalcev in zunanjih izvajalcev. Če mora združba opraviti delo na tak način, je nujno, da vsi izvajalci, ki so vpleteni v izdelavo izdelka, upoštevajo merila, ki jih predvideva CMMI. Pri izbiri te discipline bo model vseboval naslednja področja CMMI: procesno vodenje, projektno vodenje, podporo in inženirstvo. SEI priporoča združbam, ki si želijo izbrati sistemsko inženirstvo ali inženirstvo programske opreme, naj izberejo oboje. Razlog za to je v majhni razliki med modeloma, ki je vidna samo pri ojačevalnikih disciplin. V vseh drugih kategorijah sta ta dva modela enaka Komponente CMMI Komponente CMMI so procesna področja, specifične prakse, generični cilji, generične prakse, značilen izdelek dela, podprakse, opombe, ojačevalniki disciplin, elaborati in reference. Nivojska predstavitev modela CMMI združuje procesna področja v petih zrelostnih Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 23

25 nivojih. Nivojska predstavitev sestavlja procesna področja v skupine, ki predstavljajo, vsaka zase, en zrelostni nivo. Od izpolnjevanja pogojev, opisanih v procesnih področjih, je odvisno napredovanje v naslednji zrelostni nivo. Zrelostni nivoji, opisani v nadaljevanju, ponazarjajo pot za izboljšanje procesov v napredku celotne organizacije. Zrelostni nivoji pri nivojski predstavitvi priporočajo vrstni red doseganja izboljšav po nivojih. Kot je razvidno iz slike 3, so procesna področja organizirana v zrelostne nivoje. Procesna področja vsebujejo generične in specifične cilje ter generične in specifične prakse. Skupne lastnosti (ang. Common features) se iz generičnih ciljev pozneje združijo v generične prakse. Preden se združba odloči za model CMMI, je nujna preslikava lastnih procesov v procesna področja CMMI. Preslikave omogočajo nadzor izboljšanj in lažje sledenje pripravljenosti organizacije za napredek. Slika 3: Glavne komponente modela CMMI (Chrissis, 2003) Komponente modela: Procesna področja (ang. Process areas) so skupek medsebojno povezanih praks (v enem procesnem področju), ki zadovoljujejo množico ciljev, pomembnih za napredek. V nivojskem modelu se področja združujejo v zrelostne nivoje. Specifični cilji (ang. Specific goals) se nanašajo na procesno področje in naslavljajo enotne značilnosti, ki opisujejo, kaj je treba izvesti v procesnem Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 24

26 področju. Služijo kot pomoč pri ocenjevanju izpolnjenosti vseh pogojev, ki jih procesna področja morajo zadovoljiti. Specifične prakse (ang. Specific practices) so dejavnosti, pomembne v doseganju specifičnih ciljev. Opisujejo aktivnosti, ki so pomembne za doseganje specifičnih praks v procesnem področju. Specifične prakse so pričakovane komponente modela CMMI. Skupne lastnosti (ang. Common Features). Za opisovanje vseh generičnih praks v procesnem področju se uporabljajo štiri skupne lastnosti: - predanost izvedbi (ang. Commitment to perform (CO)) - zmožnost izvedbe (ang. Ability to perform (AB)) - narekovanje uvajanja (ang. Directing implementation (DI)) - preverjanje uvajanja (ang. Verifying implementation (VI)) Značilni izdelki dela (ang. Typical work products), so informativne komponente dela, ki ponazarjajo primere "izhodov" specifičnih in generičnih praks. Obstajajo seveda še drugi izdelki dela, ki so mogoče pomembni, če nanje gledamo iz drugega zornega kota. V primeru CMMI so našteti samo tisti, ki so povezani s specifičnimi in generičnimi praksami. Podprakse (ang. Subpractices) so podrobni opisi, ki omogočajo lažje razvrščanje ter razumevanje specifičnih in generičnih praks. Podprakse so tudi informativna komponenta modela. Ojačevalniki disciplin (ang. Discipline amplifications) so tudi informativne komponente modela. Uporabljajo se pri podrobnejših opisih procesnih področij glede na disciplino, ki je opisana v modelu. Na primer ojačevalnik discipline za model CMMI-SE/SW. Generični cilji (ang. Generic goals) so generični zato, ker ti opisi ciljev nastopajo in so definirani splošno za več procesnih področij. Pri nivojskem opisu modela ima vsako procesno področje en generični cilj. Generični cilji so zahtevane komponente modela. Generične prakse (ang. Generic practices) omogočajo, da so vsi procesi, povezani s procesnimi področji, učinkoviti, ponovljivi in trajajoči. Generične prakse so določene z generičnimi cilji in so pričakovane komponente modela CMMI. Elaborati generičnih praks (ang. Generic practices elaborations) so informativna komponenta modela, ki pove, kako se lahko generična praksa aplicira na procesno področje. Primer v generični praksi: "Potrebno je izobraževanje osebja za podporo načrtovanih procesov". V procesnem področju managementa konfiguracij (ang. Configuration management) so z elaborati generičnih praks podani primeri izobraževanj, ki so potrebni za to procesno področje. Reference (ang. References) so informativne komponente modela in so namenjene usmerjanju uporabnika k obširnejšim informacijam, ki se nanašajo na procesna področja. Primer: "Poglej procesno področje managementa konfiguracij za podrobnosti glede izobraževanja osebja za delo v tem procesnem področju" Zrelostni nivo CMMI Zrelostni nivoji organizaciji omogočajo načrtovanje bodočih zmožnosti združbe ali Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 25

27 organizacije znotraj ene ali znotraj skupine dejavnosti. Obstaja pet nivojev zrelosti (Chrissis, 2003): 1. nivo: Začetni Na prvem zrelostnem nivoju so procesi običajno ad-hoc in kaotični. Organizacija običajno ne zagotavlja stabilnega okolja za podporo procesov. Uspeh v takih organizacijah je odvisen od usposobljenosti in poguma ljudi v organizaciji in ne v uporabi predpisanih procesov. Kljub temu kaosu, organizacije 1.nivoja pogosto proizvajajo izdelke in storitve, ki delujejo oz. so nudene na trgu, vendar pa te organizacije pogosto presegajo proračune in ne izpolnjujejo rokov. Organizacije 1.nivoja ne uporabljajo (skoraj) nobenega pristopa za obvladovanje razvojnega procesa. Zato je znan le vhod in izhod, proces razvoja PO pa je naključen. Za te organizacije je značilna težnja k opustitvi postopkov v času krize, in nezmožnost, da ponovijo svoje uspehe. 2. Nivo: Voden Na drugem zrelostnem nivoju ima organizacija vzpostavljene osnovne procese vodenja projektov in je že dosegla vse generične in specifične cilje, potrebne za ta nivo. Procesi se planirajo, izvajajo, merijo in preverjajo, kar skupaj omogoča spremljanje stroškov, trajanje razvoja in uspešnosti dela. Proces je definiran do take mere, da omogoča ponovitev doseženih rezultatov na podobnih projektih. Obstoječe prakse so ponovljive tudi v kriznih obdobjih. Ko se te prakse prepoznavne, se projekti izvajajo in vodijo v skladu z njihovimi dokumentiranimi plani. Na drugem zrelostnem nivoju je status dela proizvodov in zagotavljanje storitev, managementu viden na določenih točkah (tj. pri večjih mejnikih in ob zaključku glavne naloge). Obveznosti so določene med ustreznimi interesnimi skupinami in se revidirajo, kot je potrebno. Proizvodi dela so ustrezno nadzorovani. Proizvodi dela in opravljanje storitev izpolnjujejo določene opise procesov, standardov in postopkov. 3. Nivo: Definiran Na tretjem zrelostnem nivoju so procesi v organizaciji dobro opisani in razumljeni, opisani so v standardih, postopkih, orodjih in metodah. Standardi procesov organizacije, ki so podlaga za tretji zrelostni nivo, se določujejo in izboljšalo periodično. Ti standardni postopki se uporabljajo za ugotavljanje skladnosti po celotni organizaciji. Projekti vzpostavijo opredeljene procese, s prilagajanjem organizacije sklopa standardnih procesov glede na oblikovanje smernic. Kritična razlika med drugim in tretjim zrelostnim nivojem, je področje uporabe standardov, opisi procesov in postopkov. Na drugem zrelostnem nivoju so standardi, opisi procesov in postopkov lahko zelo različni za vsak posebni primer v procesu, glede na tretji nivo. Na tretjem zrelostnem nivoju so standardi, opisi procesov in postopkov za projekt prilagojeni organizacijskemu sklopu standardnih postopkov, tako da ustrezajo določenemu projektu ali organizacijski enoti in zato so bolj dosledne razen razlik, ki jih dovoli oblikovanje smernic. Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 26

28 Drugo kritično razlikovanje je pri tretjem nivoju, da so procesi običajno opisani bolj strogo, kot pri drugem nivoju. Opredeljeni proces jasno določa namen, vložke, vstopna merila, aktivnosti, vloge, ukrepe, postopke preverjanja, rezultate in izhodna merila. Na tretjem nivoju so procesi vodeni bolj proaktivno z uporabo razumevanja razmerji med procesom dejavnosti in podrobnih ukrepov procesa, proizvodov del in storitev. Tretji zrelostni nivo je dosežen, ko organizacija izpolnjuje vse pogoje, definirane v specifičnih in generičnih ciljih za nivoja 2 in Nivo: Kvantitativno voden Četrti zrelostni nivo je dosežen takrat, ko organizacija izpolnjuje vse pogoje, definirane v specifičnih in generičnih ciljih za nivoje 2, 3 in 4. Pri četrtem zrelostnem nivoju ima organizacija pri projektih določene kvantitativne cilje za kakovost in uspešnost procesov, in jih uporabijo kot merila za upravljanje procesov. Kvantitativni cilji temeljijo na potrebah kupca, končnih uporabnikih, organizaciji in procesnih izvajalcih. Kakovost in uspešnost procesa se razume v statističnem smislu in se vodi za ves čas trajanja procesa. Za izbrane podprocese se zbirajo in statistično analizirajo podrobni ukrepi za izvedbo procesa. Ukrepi za kakovost in uspešnost procesa so vključeni v organizacije merjenja repozitorija za podporo pri odločitvah, ki temeljijo na dejstvih. Posebni vzroki za spremembo procesa so opredeljeni in, kadar je to primerno, se izvor posebnih vzrokov popravi z namenom, da se prepreči prihodnja ponovitev dogodkov. Kritična razlika med tretjim in četrtim zrelostim nivojem je predvidljivost procesa uspešnosti. Pri četrtem zrelostnem nivoju je uspešnost procesov nadzorovana z uporabo statistične in drugih kvantitativnih tehnik, in procesi so kvantitativno predvidljivi. Pri tretjem zrelostnem nivoju pa so procesi po navadi le kakovostno predvidljivi. 5. Nivo: Optimizirajoč Pri petem zrelostnem nivoju organizacija nenehno izboljšuje svoje procese na podlagi kvantitativnih razumevanj skupnih vzrokov variacij, ki izhajajo iz procesov. Peti zrelostni nivo se osredotoča na nenehno izboljševanje uspešnosti procesa prek primarnih in inovativnih procesov in tehnoloških izboljšav. Cilji so vzpostaviti kakovostne procese za izboljšanje organizacije, ki se stalno revidirajo tako, da odražajo v spreminjajočih se poslovnih ciljih, in se uporabljajo kot merila za vodenje procesov izboljšav. Učinki uvedenih procesov izboljšav se merijo in ovrednotijo glede na kakovostne procese izboljšanja ciljev. Tako opredeljene procese kot organizacijski sklop standardnih postopkov so cilji za merljivo izboljšanje dejavnosti. Kritična razlika med četrtim in petim zrelostnim nivojem je procesna obravnava sprememb. Pri četrtem zrelostnem nivoju se organizacija ukvarja z odpravljanjem vzrokov za posamezen proces in zagotavlja statistično predvidljivost rezultatov. Čeprav procesi, lahko povzročijo predvidljive rezultate, pa so rezultati lahko nezadostni za doseganje definiranih ciljev. Pri petem Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 27

29 zrelostnem nivoju se organizacija ukvarja z odpravljanjem skupnih vzrokov procesne variacije in spreminjanje procesa, z namenom da se izboljša proces in da se doseže določene kakovostno procesno izboljšanje cilje. Ta nivo je dosežen, ko organizacija izpolnjuje vse pogoje, definirane v specifičnih in generičnih ciljih nivojev 2, 3, 4 in Napredovanje po nivojih Organizacije dosežejo napredek po nivojih postopno. Najprej se doseže stabilnost na nivoju projektov, nato pa na večjih enotah do organizacijskega področja in na koncu tudi na področju celotne organizacije. Preskokov med nivoji SEI ne dovoljuje. Vse analize možnih preskokov kršijo evolucijske principe, ki jih CMMI zagovarja Zahtevane, pričakovane in informativne skupine komponent modela Komponente modela CMMI so razvrščene v tri kategorije: Zahtevane (ang. Required); Specifični in generični cilji so zahtevane komponente modela. Organizacija mora te cilje doseči v okviru planiranja in izvedbe procesov. Te komponente so nujne za oceno procesnega področja. Pričakovane (ang. Expected); Specifične in generične prakse so pričakovane komponente modela. Te komponente povedo, kaj bo organizacija dejansko naredila, da doseže napredovanje na naslednjem nivoju. Informativne (ang. Informative); Podprakse, značilni izdelki dela, ojačevalniki disciplin, elaborati generičnih praks, imena ciljev in praks, opombe praks in reference so informativne komponente. V uporabi so zaradi lažjega razumevanja ciljev in praks in za usmerjanje, kako se le ti dosežejo Procesna področja V fazni predstavitvi modela CMMI so ključna procesna področja razdeljena v pet zrelostnih nivojev, ki opisujejo razvojno pot od ad-hoc, kaotičnih procesov, do zrelih, urejenih programskih procesov. Pet zrelostnih nivojev, oštevilčenih od 1 do 5, opisuje osnovno zaporedje nepretrganega procesa izboljšav in določitev merila za merjenje zrelosti organizacijskih programskih procesov. CMMI model je sestavljen iz 22 ključnih procesnih področji. Ključna procesna področja CMMI modela lahko razdelimo na štiri razrede: procesno vodenje (ang. Process Management); projektno vodenje (ang. Project Management); inženirstvo (ang. Engineering) in podpora (ang. Support). Tabela 1 po vrsticah prikazuje zaporedje vseh petih nivojev od najnižjega, začetnega nivoja do najvišjega, optimiziranega nivoja. V stolpcih so zapisana ključna procesna področja, razdeljena v štiri razrede (razred procesno vodenje, projektno vodenje, inženirstvo in podpore). Vsakemu ključnemu procesnemu področju ustrezajo splošni cilji in postopki, s katerimi dosežemo določen nivo Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 28

30 zrelosti. Za prehod iz enega nivoja na drug nivo je potrebno doseči vse zahtevane cilje prejšnjih nivojev. Vsak nivo višji od prvega vsebuje vse prvine prejšnjega oz. jih nadgradi z novimi. CMMI nivo Procesno vodenje Projektno vodenje Inženirstvo Podpora 1. Začetni Ad-hoc procesi 2. Voden Projektno planiranje Management zahtev Management konfiguracij Projektno spremljanje in nadzor Kakovost procesov in proizvodov 3. Definiran Procesni vidik v organizaciji Definiranje procesov v organizaciji Usposabljanje v organizaciji Integriran management proizvodov Management pogodb dobaviteljev Razvoj zahtev Tehnične rešitve Integracija proizvoda Verifikacija Validacija Meritve in analiza Analiza odločitev in rešitev Management tveganj 4. Kvantitativno voden Kvantitativno vodenje projektov Izvedbene zmogljivosti organizacije Tabela 1: Ključno procesno področje (Sajko, 2002:62) Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 29

31 2.3.8 Kategorizacija procesnih področji modela CMMI Procesna področja znotraj enih kategorij se zaradi lažje predstavitve medsebojnih razmerij med njimi delijo na: osnovna in napredna. Procesna področja v procesnem vodenju so: osnovna: organizacijsko osredotočenje na procese (ang. Organizational process focus) organizacijska procesna definicija (ang. Organizational process definition) organizacijsko izobraževanje (ang. Organizational training) napredna: organizacijske procesne zmožnosti (ang. Organizational process performance) organizacijske inovacije in postavitve (ang. Organizational innovation and deployment) Procesna področja v procesnem managementu vsebujejo medsebojno povezane aktivnosti pri opredelitvi, planiranju, omogočanju virov, razporejanju, uvajanju, sledenju, nadzoru, napredovanju, merjenju in izboljšanju procesov. Procesna področja v projektnem vodenju so: osnovna: projektno planiranje (ang. Project planning) projektno sledenje in nadzorovanje (ang. Project monitoring and control) management dogovorov z dobavitelji (ang. Supplier agreement management) napredna: integrirano projektno vodenje za IPPD (ang. Integrated project management for IPPD) management tveganj (ang. Risk management) integrirano delo v skupinah (ang. Integrated teaming) integriran management dobaviteljev (ang. Integrated supplier management) kvantitativno projektno vodenje (ang. Quantitative project management) Procesna področja v projektnem vodenju vsebujejo medsebojno povezane aktivnosti pri planiranju, sledenju in nadzoru projektov. Procesna področja v inženirstvu so: razvoj zahtev (ang. Requirements development) management zahtev (ang. Requirements management) tehnične rešitve (ang. Technical solution) integracija izdelkov (ang. Product integration) preverjanje (ang. Verification) validacija (ang. Validation) Procesna področja v inženirstvu vsebujejo medsebojno povezane aktivnosti pri Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 30

32 razvoju in vzdrževanju sistemov. Procesna področja pri podpori so: osnovna: management konfiguracij (ang. Configuration management) zagotavljanje kakovosti procesov in izdelkov (ang. Process and product quality assurance) meritve in analize (ang. Measurement and analysis) napredna: organizacijsko okolje pri integracijah (ang. Organizational environment for integrations) odločitvena analiza in rešitve (ang. Decision analysis and resolution) običajna analiza in rešitve (ang. Casual Analysis and resolution) Procesna področja pri podpori vsebujejo medsebojno povezane aktivnosti pri podpori razvoja in vzdrževanju izdelkov. 2.4 Metodologija Scrum V zadnjih nekaj letih so se kot odgovor na problem nenehnih sprememb ter na togost in birokratkost tradicionalnih "težkih" pristopov k razvoju programske opreme pojavijo t.i. "lahke metodologije". Leta 2001 so se s skupno izjavo 2 najbolj znanih avtorjev s tega novega področja preimenovale v agilne metodologije. Ideja za agilnimi pristopi razvoja je, da je lahko razvojna skupina bolj učinkovita v odzivanju na spremembe, če: zmanjšamo strošek toka informacij znotraj skupine in zmanjšamo čas med odločitvijo in vidnimi posledicami te odločitve (povečamo odzivnost) (Cockburn, 2001). Za agilni razvoj je značilno, da se osredotoča na talente in veščine razvijalcev in oblikuje ter prilagaja proces specifični situaciji in razvojni skupini in ne obratno, kot je pogosta praksa v tradicionalnih metodologijah. Glavni cilj agilnih metodologij ni ustvarjanje prekomerne količine dokumentacije ampak razvoj kvalitetne programske opreme s čim manj porabljenimi sredstvi pri čemer stranke aktivno sodelujejo v samem procesu razvoja. Osnovne vrednote agilnih metodologij so (Beedle, 2001): Osebe in medsebojni odnosi namesto procesov in orodij. Delujoča programska oprema namesto nerazumljive dokumentacije. Sodelovanje s strankami namesto pregovorov za pogodbe. Odzivanje na spremembe namesto sledenje načrtu. Poznamo več vrst agilnih metodologij razvoja programske opreme med katerimi naj glede na (Cockburn, 2001) omenim: 2 Ta je v krogih podpornikov agilnih metodologij znana kot agilni manifest (agile manifesto). Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 31

33 Scrum (1993); DSDM Dynamic System Development Method (1995); FDD Feature Driven Development (1995); XP extreme programming (1995); JITS Just-In-Time Software (1995); Pragmatic programming (1998); ASD Adaptive Software Development (2000); Crystal (2000); EAP (1999); Scrum je ena od agilnih metodologij dela, ki se v zadnjih časih vedno bolj uveljavlja v svetu informacijske tehnologije, saj s seboj prinaša drugačen način dela, ki je zelo različen od tradicionalnih metodologij. Hkrati pa omogoča večjo učinkovitost in cenejšo izvedbo s tem pa tudi višje dobičke organizacij. Za razliko od tradicionalnih metodologij je eden izmed glavnih ciljev metodologije Scrum donosnost naložbe (ROI Return On Investment) in kako to donosnost povečati. V svetu informacijske tehnologije oziroma v svetu razvoja programske opreme gre seveda za čim cenejšo in pravočasno proizvodnjo programske opreme, ki zadovoljuje dejanske potrebe naročnika oziroma stranke. V primerjavi s tradicionalnim slapovnim 3 načinom razvoja programske opreme, ki predvideva korake: analiza, načrtovanje, kodiranje, testiranje in vzdrževanje, Scrum narekuje iterativen in inkrementalen pristop, ki vodi do čim večje poslovne vrednosti. Ko govorimo o poslovni vrednosti mislimo predvsem na ustvarjanje programske opreme v obliki manjših zaključenih enot, ki se v končni fazi združijo v celovito rešitev. Če upoštevamo še dejstvo, da so rezultat metodologije Scrum vedno najbolj pomembne funkcionalnosti, to pomeni, da stranka že zelo zgodaj lahko začne uporabljati programsko opremo Zgodovina Leta 1986 sta Hirotaka Takeuchi in Ikujiro Nonaka opisala nov celosten pristop, ki povečuje hitrost in fleksibilnost pri razvoju novih komercialnih proizvodih (Takeuchi, 1986). Primerjala sta nov celosten pristop, v katerem se faze odločno prekrivajo, in celoten postopek se izvede z eno navzkrižno funkcionalno skupino skozi različne faze. Kot pri rugby 4 -ju, kjer se celotna ekipa trudi kot enota in podaja žogo naprej in nazaj Karakteristika in pravila Scrum-a Scrum enkapsulira tisto, kar pri uspešnih ponudnikih programske opreme deluje. Osnovne značilnosti metode Scrum so sledeče: velike in zahtevne produkte razbije na manjše a bolj obvladljive dele nekaj funkcionalnosti, ki jih razvojna skupina lahko izvede v nekaj mesecih, 3 Klasični razvojni cikel (ang. Waterfall), katerega koraki so analiza, načrtovanje, kodiranje, testiranje in vzdrževanje. 4 Scrum je v angleškem rugby-u formacija obrambnih igralcev. Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 32

34 omogoča sistematično delo na projektu kljub morebitni nezmožnosti dobrega definiranja arhitekture produkta ob začetku projekta, omogoča velikim razvojnim skupinam, da delujejo kot majhne razvojne skupine, s tem da deli delo na manjše dele, nato pa majhne razvojne skupine delujejo vzporedno, a se sočasno neprestano medsebojno usklajujejo. Z vsakim povečanjem količine funkcionalnosti se stvari stabilizirajo, vseskozi pa se pojavljajo in rešujejo problemi. Scrum ponuja mehanizem, ki nam omogoča zajemanje in upoštevanje zahtev strank, določanje prioritet, izvrševanje najbolj pomembnih funkcionalnosti in spreminjanje ter morebiti zavračanje manj pomembnih funkcionalnosti. Scrum sledi naslednjim pravilom: vedno naj bo na voljo produkt, ki ga je teoretično možno predati; govori naj se v skupnem jeziku na eni lokaciji razvoja; produkt naj se nenehno testira. Osnovni principi Scrum razvojnega procesa so: majhne razvojne skupine, v katerih se zelo veliko komunicira, nepomembnosti naj je čim manj, prav tako pa se preprosto prenaša formalno znanje, torej gre znanje pridobljeno s prakso; sposobnost prilagajanja spremembam, ki so bodisi tehnične narave bodisi so posledica želja stranke, z namenom zagotovitve najboljšega možnega produkta; pogosto izvajanje gradnje kode v izvajalno obliko, ki jo lahko preverjamo, testiramo, spreminjamo, dokumentiramo in nadgrajujemo; razbijanje dela na manjše dele, ki predstavljajo neko smiselno celoto; nenehno testiranje in dokumentiranje produkta takšnega, kakršen v nekem trenutku je; možnost, da v nekem želenem trenutku lahko trdimo, da je produkt zaključen (bodisi je konkurenca objavila produkt, bodisi da podjetje potrebuje denar, bodisi stranka potrebuje funkcionalnosti ali pa je enostavno prišel datum, ko naj bi produkt bil objavljen oziroma končan). Scrum in empirični način razvoja programske opreme sta priporočljiva za razvoj produktov, ki so objektno orientirani. Manjši podsistemi so razdeljeni v pakete in potem vsaka manjša razvojna skupina dobi enega ali več paketov v obdelavo in tako lahko razvojne skupine delujejo neodvisno. Scrum je uporaben za projekte vseh velikosti Sestavine Scrum-a Scrum je sestavljen iz razvojnih procesov in meritev, ki omogočajo nadzorovanje teh procesov. Ključ uspeha metodologije Scrum je ravno v uporabi meritev, ki omogočajo maksimilizacijo fleksibilnosti in tveganja, hkrati pa ohranjajo nadzor. Večina projektov se seveda izogiba tveganjem, vendar so le ti sestavni del razvoja programske opreme. Scrum pa tveganje upošteva in ga poskuša nadzorovati tako, da lahko zgradimo najboljši možni produkt. Pri Scrum-u projekt nadzorujemo preko Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 33

35 uporabe nadzornih parametrov, ki postanejo kritični v trenutkih, ko razvoj programske opreme pride do neznane situacije oziroma do nepredvidenega obnašanja in kaosa. Uporaba teh nadzornih parametrov je osnova za Scrum razvojni proces. Spremenljivke v razvoju projekta so: tveganje; funkcionalnost; cena; čas; kvaliteta. Za te spremenljivke lahko ob začetku projekta podamo neko grobo oceno, nato pa se vrednosti spremenljivk neprestano spreminjajo od tistega trenutka naprej, ko se projekt začne. Spreminjajo se lahko tako, da se ena vrednost povečuje na račun drugih (npr. izboljševanje kvalitete funkcionalnosti pomeni več porabljenega časa in s tem tudi več porabljenega denarja). Nadzorni parametri Scrum-a so: Seznam zahtev (ang. Product Backlog) vsi zahtevki, ki morajo biti izpolnjeni v končanem produktu; dejansko gre za funkcionalnost končnega produkta; Objekti/komponente; Paketi skupina objektov, znotraj katere bo implementiran nek element iz seznama zahtev; povezanost objektov znotraj paketa je velika, med paketi pa majhna; Težave (ang. issues) problemi, ki morajo biti razrešeni preden nek element iz seznama zahtev dodelimo nekemu paketu; Rešitve težav; Spremembe aktivnosti, katerih posledica je rešitev problema oziroma težave; Tveganja tveganja, ki so povezana s problemom, težavo ali elementom iz seznama zahtev. Te parametre merimo, povezujemo med seboj in jih dopolnjujemo. Glavna parametra sta seznam zahtev in tveganje. Seznam zahtev bo na začetku obsežen. Med planiranjem bo postal še obsežnejši. Ob koncu projekta pa mora postati prazen. Tveganje bo naraščalo s pojavitvijo novih elementov v seznamu zahtev, težav ali problemov, vendar se bo znižalo na sprejemljiv nivo, ko bo programska oprema končana in dostavljena stranki Ogrodje metodologije Glavna značilnost metodologije Scrum je, da razvoj poteka v več ciklih, od katerih vsak poveča funkcionalnost izdelka (ang. Iterative incremental process). Proces je prikazan na sliki 4. Eni izvedbi cikla pravimo tek (ang. Sprint) in običajno traja 30 koledarskih dni. Znotraj vsakega cikla se na dnevnem sestanku, imenovanem dnevni Scrum (ang. Daily Scrum), preverja stanje pri vsakem razvijalcu posebej in po potrebi prilagaja razvoj spremembam. Naloge, ki jih je potrebno izvesti, so zapisane v dnevniku izdelka (ang. Product Backlog). Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 34

36 Slika 4: Ogrodje metodologije Scrum (Chrissis, 2003) Smisel takega procesa je dvojen: razvojna skupina sama pregleda in določi (glede na lastna znanja in sposobnosti), koliko je sposobna narediti ter razvoj se dnevno spremlja in spreminja (v primeru težav, presenečenj ali nepredvidenih zapletov). Ker metodologija prepušča odločitev o vsebini in načinu dela razvojni ekipi, se spodbuja kreativno delo razvojne ekipe in povečuje učinkovitost dela Vloge pri metodologiji Scrum Pri metodologiji Scrum poznamo po Schwaberju in Beedlu naslednje tri vloge, ki jih Mahnič definira: Skrbnik metodologije (ang. Scrum Master) - Vzdržuje procese in deluje podobno kot vodja projekta. Odgovarja za skladnost celotnega procesa z metodologijo Scrum. Skrbnik metodologije uči metodologijo vse, ki sodelujejo na projektu. Skrbi, da se metodologija vklaplja v kulturo organizacije, a še vedno daje pričakovane rezultate. Zagotavlja, da vsi upoštevajo pravila in prakso, ki jo predpisuje metodologija. Lastnik izdelka (ang. Product Owner) - Predstavlja vse, ki so zainteresirani za projekt in njegove rezultate. Skrbi za zagotavljanje sredstev in upravičenost projekta (ROI - Return On Investment). Vzdržuje seznam zahtev (Product Backlog), tako da izdela začetni seznam, določa prioriteto posameznih zahtev in planira predajo posameznih verzij izdelka (release) v obratovanje. Razvojna skupina (ang. Team) - Odgovarja za razvoj novih funkcij znotraj vsakega teka (iteracije). Razvojna skupina deluje na principu samoorganizacije. Člani razvojne skupine sami izberejo način, kako realizirati posamezne zahteve Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 35

37 in so kolektivno odgovorni za uspeh posameznih tekov in projekta v celoti (Mahnič, 2006). V zgoraj naštetih vlogah se nahajajo ljudje, ki so s projektom tesno povezani. Metodologija Scrum striktno loči med ljudmi, ki so na projekt vezani (Schwaber in Beedle (Schwaber, 2001) jih imenujeta "prašiči" 5 ), ter ljudmi, ki so samo prisotni ("piščanci"). Prašiči neposredno razvijajo in so odgovorni za potek projekta, medtem ko so piščanci prisotni le v določenih fazah projekta, pa še tam le kot opazovalci in na potek razvoja nimajo neposrednega vpliva. Te piščančje vloge niso del dejanskega Scrum procesa, vendar pa jih je treba upoštevati. Pomemben vidik agilnega pristopa v praksi je, da se vključujejo uporabniki, podjetja in interesne skupine v delo procesa. Pomembno je, da ti ljudje, ki so vključeni, zagotavljajo povratne informacije o izdelku na koncu vsakega teka in sodelujejo pri načrtovanju naslednjega teka. Uporabniki (ang. Users) - Programska oprema je zgrajena za nekoga. Če se programska oprema ne uporablja, je enako, kot da ni bila nikoli napisana. Interesne skupine - kupci, prodajalci (ang. Stakeholders customers, vendors) - So ljudje, ki bodo na koncu omogočili zaključek projekta in ljudje, za katere bo projekt imel dogovorjene koristi. Interesne skupine neposredno sodelujejo samo v delovnem procesu pri pregledih tekov. Gospodarji (ang. Managers) So ljudje, ki bodo vzpostavili okolje za razvojni produkt organizacije Dokumenti metodologije Scrum Metodologija Scrum je po definiciji agilna metodologija razvoja in zato med procesom razvoja potrebuje majhno število dokumentov. V bistvu Scrum potrebuje le dva dokumenta: dnevnik izdelka (ang. Product Backlog) in dnevnik teka (ang. Sprint Backlog). Dnevnik izdelka je (po pomembnosti) urejen spisek vseh funkcionalnih in nefunkcionalnih zahtev, ki se jih v sklopu projekta želi izvesti. Sestava, dopolnjevanje in popravljanje dnevnika izdelka je odgovornost lastnika izdelka. Dnevnik izdelka vsebuje tudi razporeditev izdelave funkcij po tekih in omogoča enostaven pregled deleža že dokončanih funkcij projekta. Primer dnevnika izdelka je prikazan v tabeli 2. 5 Imeni prašiči in piščanci prihajata iz šale o prašiču in piščancu, ki se dogovarjata o odprtju skupne restavracije z imenom "Šunka z jajci". Iz imena restavracije je razvidno, da bo prašič za hrano dejansko žrtvovan, piščanec pa bo samo prisoten. A pig and a chicken are walking down a road. The chicken looks at the pig and says, "Hey, why don't we open a restaurant?" The pig looks back at the chicken and says, "Good idea, what do you want to call it?" The chicken thinks about it and says, "Why don't we call it 'Ham and Eggs'?" "I don't think so," says the pig, "I'd be committed but you'd only be involved." Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 36

38 Zahteve iz dnevnika izdelka se razlikujejo od projekta do projekta, vključujejo pa lahko od razvoja posameznih funkcij projekta, odprave napak, tehnoloških nadgradenj do zahtev po pohitritvi delovanja ali izboljšanja izgleda uporabniškega vmesnika. Te zahteve niso stalne, ampak predstavljajo le začetne želje, ki se lahko spreminjajo med razvojem projekta. Večinoma so spremembe zahtev odvisne od sprememb v okolju (npr. nova tehnologija, sprememba potreb naročnika, itd.) ter sposobnosti in hitrosti razvoja razvojne skupine. Dnevnik izdelka obstaja tako dolgo, dokler obstaja projekt. Prvi stolpec določa ime zahteve. V drugi stolpec se vpiše predvideno število ur za izvedbo zahteve. To oceno se lahko obteži še s korekcijskim faktorjem iz tretjega stolpca. Rezultat predstavlja četrti stolpec, ki vsebuje popravljeno oceno števila ur za izvedbo zahteve. S korekcijskim faktorjem se upošteva tudi stanje razvojne skupine (npr. dopust enega člana). Ostali stolpci so koristni, ker omogočajo pregled, koliko časa je še potrebno za dokončanje zahteve. Ti stolpci so podrobneje razdeljeni po tekih in pri vsakem začetem teku se v polje trenutnega teka zapiše, koliko časa (število ur) je še potrebnih za dokončanje zahteve. Dokončanje zahteve iz prejšnjega teka dobijo vrednost 0 torej so končane. Če se pri pregledu delovanja zahteve ugotovi pomanjkljivost, se v dnevnik izdelka dopiše nova zahteva z ustreznimi ocenami potrebnega časa za nadgradnjo. Zahtevo je mogoče tudi prenesti iz trenutnega teka v enega od naslednjih tekov, kjer se vodi enako kot vsaka druga zahteva. V vrsticah tabele se beležijo tudi oznake tekov in seštevek časa, ki je potreben za dokončanje teka. Ker se planira izdelavo zahtev samo za trenutni tek, se lahko v dnevniku izdelka pojavljajo tudi zahteve, ki ne pripadajo nobenemu teku. Te so prosto naštete na koncu tabele. Iz obstoječega dnevnika izdelka se za vsak tek posebej izdela dnevnik teka (ang. Sprint Backlog). Ime zahteve Ocena dela (št.ur) Korekcijski faktor Popravljena ocena Izdelava prijavne strani Določitev varnostne politike Funkcija A Funkcija B Tek Čas potreben za dokončanje Iskalnik po strani 32 0,1 35,2 35,2 35,2 Funkcija C 104 0,1 114,4 114,4 114,4 Dopolnitev funkcije A s stranjo za pomoč 8 0,1 8,8 8,8 Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 37

39 Tek ,1 158,4 149,6 158,4 Izpis podatkov funkcije A v različnih formatih Verzija ,6 206,4 Funkcija D 120 0, Verzija Tabela 2: Primer dnevnika izdelka prirejeno po viru (Schwaber, 2001) Dnevnik teka izdela razvojna skupina in vsebuje tiste zahteve iz dnevnika izdelka, ki bodo realizirane v trenutnem teku. Čeprav je vpogled v dnevnik dovoljen vsem sodelavcem projekta, ima pravico določanja in spreminjanja vsebine le razvojna skupina. Dnevnik teka (primer je prikazan v tabeli 3) vsebuje podrobne naloge znotraj izbranih zahtev, ki so namenjene za izdelavo v trenutnem teku. Zahteve so vzete iz dnevnika izdelka in se jih za potrebe izvajanja razdeli na naloge. Veljavna naloga znotraj zahteve je definirana kot opravilo, ki ga lahko razvojna skupina naredi v času od 4 do 16 ur. Daljše naloge se ob začetku izvajanja razdelijo na manjše naloge, ki se jih ravno tako beleži znotraj dnevnika teka. Opis naloge Tvorec Odgovorni Status Dnevi izvajanja teka Izdelava prijavne strani Mehanizem preverjanje gesla Prebiranje podatkov certifikata Izdelava mehanizma za klice posameznih funkcij Določitev varnostne Andrej končano Branko končano Darko V delu Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 38

40 politike Določitev tabel za hranjenje uporabnikov Določitev in implementacija varnostnih pravil Andrej, Branko Andrej, Branko, Darko končano Preverjanje nivoja varnosti Andrej Funkcija A Določitev potrebnih tabel Računanje rezultata Branje potrebnih podatkov Popravljanje izgleda funkcije Funkcija B Določitev potrebnih tabel Zajemanje podatkov Izdelava povpraševanja Kontrola vhodnih podatkov Povezava na funkcijo A Andrej končano Darko Branko Andrej Darko Prikaz podatkov Tabela 3: Primer dnevnika teka prirejeno po viru (Schwaber, 2001) Vsebina dnevnika teka se dopolnjuje vsak dan na dnevnem sestanku Scrum. Poleg spiska nalog vsebuje dnevnik teka še podatke o tem, kdo je sprožil delo na tej nalogi, kdo je za izdelavo naloge odgovoren, kakšen je status naloge in koliko časa (v urah) je še potrebno do zaključka naloge. Število ur za dokončanje je plod ocene razvijalca, ki je pristojen za reševanje naloge. Ocene potrebnih ur se dnevno postopoma zmanjšujejo, čeprav to ni nujno. V primeru, da razvijalec naleti na nepredvideno oviro, ki za rešitev zahteva več časa, se število ur lahko tudi ustrezno poveča. Na koncu izvajanja teka morajo biti vse naloge končane, torej mora biti število enako 0. Grafičnemu prikazu, ki ponazarja preostalo delo v dnevniku teka Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 39

41 pravimo diagram obsega preostalega dela (ang. Burn Down chart, slika 5). Graf se posodablja dnevno in daje preprost pogled na napredek teka. Slika 5: Diagram obsega preostalega dela (Mann, 2005) Proces razvoja z metodologijo Scrum Slika 6 prikazuje celoten proces metodologije Scrum. Razvoj projekta se začne z idejo oziroma vizijo delovanja sistema. Vizija je lahko na začetku nedorečena in se nad ponovitvami razvoja počasi izkristalizira. Nekatere zahteve postanejo med razvojem odvečne in se jih znebimo, druge se pokažejo kot koristne in jih dodamo med spisek potrebnih funkcionalnosti. Lastnik izdelka skupaj s skrbnikom metodologije Scrum (Scrum Master) pripravi dnevnik izdelka. V njem so zabeležene vse potrebne zahteve, ki jih je pri tem projektu potrebno narediti. Razvrščene so po pomembnosti (od najbolj pomembne do najmanj pomembne), pri čemer se najprej izdela tiste zahteve, ki se jih lahko najhitreje vgradi v končno verzijo in takoj prinesejo vračilo investicije. Ves razvoj poteka v več zaporednih tekih, ki so dolgi 30 zaporednih koledarskih dni. Vsak tek se prične s sestankom začetka teka (ang. Sprint Planning Meeting), kjer se izbere zahteve za trenutni tek, določi podroben potek vsake zahteve posebej in razporeditev zapiše v dnevnik teka. Izbira zahtev in določitev podrobne izvedbe sta vsak posebej navzgor omejena na največ 8 ure. Na prvem delu sestanka lastnik izdelka, skrbnik metodologije Scrum in razvojna skupina začrtajo plan razvoja za trenutni tek. Lastnik izdelka predstavi najbolj pomembno zahtevo iz dnevnika izdelka in kaj bi bilo potrebno narediti. Razvojna skupina si z vprašanji razjasni zahtevo, predstavi lasten pogled nanjo ter predvidi, kolikšen del zahteve lahko izdela v trenutnem teku. Običajno se izbere tak del Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 40

42 zahtev, ki bodo po koncu teka predstavljale zaključeno celoto ter bodo rezultati pripravljeni za prenos v uporabo. Pogovor na sestanku lahko zaide tudi na tehnične podrobnosti izdelave zahteve, vendar to ni priporočljivo, ker je namen sestanka določitev dela in ne razmišljanje o izdelavi. Na drugem delu sestanka si razvojna skupina podrobneje načrta potek dela. Skupina se samo-organizira po najboljših močeh za dosego cilja in pri tem izdela dnevnik teka (ang. Sprint Backlog). Začetne naloge zahtev se dodeli posameznim izvajalcem znotraj razvojne skupine in tek se lahko začne. Naloge iz dnevnika teka se lahko (glede na spremembe okolja in tehnologije) spreminjajo, vendar le toliko, da na koncu teka še vedno dosežemo zadan cilj. Ko se na prvem delu sestanka določi glavni cilj teka in se tek začne, poseganje in spreminjanje dela ni več dovoljeno. V izrednem stanju (če se recimo opazi napako planiranja) se lahko celoten tek prekine in začne nov tek; torej se ponovi sestanek teka in začne celoten tek znova. Vsak dan se razvojna skupina in skrbnik metodologije Scrum srečajo na dnevnem sestanku Scrum (ang. Daily Scrum). Na njem vsak član razvojne ekipe odgovori na naslednja tri vprašanja: Kaj si napravil od prejšnjega dnevnega sestanka Scrum do sedaj? Kaj nameravaš napraviti do naslednjega sestanka Scrum? Ali imaš težave, ki te ovirajo pri uresničevanju tvojega cilja? (Naloga skrbnika metodologije je, da te ovire odstrani.) Namen tega sestanka je dnevna sinhronizacija dela razvojne ekipe, da bi lahko sproti reševali težave, s katerimi se srečujejo posamezni razvijalci. Na sestanku se odgovarja le na zgoraj napisana vprašanja, vsa ostala vprašanja (podrobnosti) se rešujejo na kasnejših sestankih individualno. Za dnevni sestanek Scrum veljajo posebne smernice: Sestanek se začne točno ob dogovorjenem času. Pogosto skupine same določijo kazen za zakasnelost (npr. denar, sklece, viseči gumijasti piščanec okoli vratu) Vsi so dobrodošli, vendar samo»prašiči«lahko govorijo. Sestanek je časovno omejen na 15 minut ne glede na velikost skupine. Vsi udeleženci morajo stati (to pomaga ohranjati sestanke kratke). Sestanek se izvede na istem mestu in ob istem času vsak dan. Na koncu tega teka se izvede sestanek za pregled rezultatov teka (ang. Sprint Review Meeting). Ta sestanek je dolg največ 4 ure. Na njem razvojna skupina predstavi rezultate teka lastniku izdelka in drugim zainteresiranim uporabnikom s posebnim poudarkom na novi funkcionalnosti, ki jo je že mogoče prenesti v uporabo. Nedokončanih del se ne predstavlja. Tukaj lahko lastnik izdelka pregleda rešitev, njene posledice ter spozna tehnološke možnosti za nadaljnji razvoj. Pregled izdelane rešitve lahko povzroči tudi spremembo prioritet razvoja posameznih funkcionalnosti. Po sestanku, ki je namenjen pregledu rezultatov, je še pred naslednjim uvodnim sestankom teka še en sestanek z razvojno ekipo, ki ga vodi skrbnik metodologije Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 41

43 Scrum. Ta retrospektiven sestanek (ang. Sprint Retrospective Meeting), je dolg največ 3 ure in je namenjen izboljšanju uporabe Scrum-a v razvojni skupini ter izboljšanju delovnih razmer pri projektu. Na tem sestanku vsi člani skupine razmislijo o preteklih tekih. Dela se na nenehnem procesu izboljšav. Na sestanku se zastavita dve glavni vprašanji: Kaj je bilo dobrega v teku? Kaj bi lahko izboljšali v naslednjem teku? Slika 6: Celoten proces Scrum (Schwaber, 2002) Analiza delovanja metodologije Scrum Metodologija Scrum je uporabna predvsem pri manjših projektih (do 10 razvijalcev), kjer je veliko razvojnih neznank. Obnese se predvsem zaradi hitrega razvojnega cikla, zahteve po delujoči rešitvi ob zaključku vsakega razvojnega cikla, prisotnosti naročnika, pa tudi zaradi stalnega spremljanja razvoja in odgovornosti celotne razvojne ekipe za uspeh (ali neuspeh). Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 42

44 Kratek razvojni cikel omogoča sprotno preverjanje pravilnosti odločitev že med razvojem projekta, saj naročnik redno pregleduje delujočo kodo na koncu razvojnega cikla. S tem pridobi razvojna skupina oceno rešitve, kar upošteva pri naslednjih razvojnih ciklih. Zahteva po delujoči kodi na zaključku vsakega razvojnega cikla to oceno še dodatno podpre. Naročnik lažje oceni delujočo kodo, ker jo testira v okolju, v katerem bo sistem deloval. Nedelujoča koda je le zaporedje ukazov programskega jezika, ki naročniku običajno pove zelo malo ali nič. Kratek razvojni cikel zahteva razbitje sistema na zaporedje manjših in lažje vodljivih delov, ki se lahko izvajajo tudi v primeru, ko za celoto še ni določena tehnična izvedba. Prisotnost naročnika, ki je tipična za vse agilne metodologije, je nujna pri določanju vsebine dnevnika teka in pri ocenjevanju rezultatov teka. Njegovo mnenje določa smernice razvoja in njegova je zadnja beseda pri ocenjevanju primernosti rešitev. Sodelovanje z naročnikom je s strani metodologije podrobno določeno tako, da naročnik ne sme vplivati na način razvoja, temveč le na vsebino razvoja. Po začetku teka naročnik nima več pravice spreminjati zastavljenih ciljev teka, kar pomeni, da ima razvojna skupina mir pred nadležnimi naročniki, ki bi nenehno izboljševali izdelek in s tem motili potek razvoja. Kontrola napredovanja razvoja se izvaja med vsakim dnevnim sestankom. Sestanek s tremi ključnimi vprašanji je namenjen hitremu in natančnemu pregledu stanja na projektu. S stalnim nadzorom se pridobiva informacije o tem ali razvoj teče po načrtih. V primeru odstopanja je mogoče hitro ukrepati in sprejeti odločitve, ki pripeljejo razvoj nazaj v planirani časovni okvir. Sestanek omogoča tudi seznanitev vseh prisotnih (običajno celotne razvojne skupine) z opravljenim delom na projektu. To preprečuje nekoristno prekrivanje razvoja in krepi povezanost razvojne skupine. Sestanek mora biti hitro končan (največ 15 minut), kar preprečuje dolge in neproduktivne sestanke, na katerih sodeluje le manjši del skupine, ostali pa ne uspejo priti do besede. Razvojna skupina je znotraj vsakega teka prepuščena sama sebi in mora navzven delovati kot utečena celota. Izdelava projekta je zaupana celotni skupini, ki sama razdeli naloge med člane glede na njihove sposobnosti in želje. Uspeh ali neuspeh projekta je stvar celotne skupine. Ne podpira se določanja krivde posameznikov znotraj razvojne skupine. Skupna odgovornost krepi skupinski duh in prisili razvijalce k večjemu sodelovanju. Težave med osebjem razvojne skupine se najprej rešuje znotraj skupine in šele v primeru, da je razvojna skupina ne zmore rešiti težave, se vmeša skrbnik metodologije Scrum in odstrani motečega člana iz razvojne skupine. Po (Rising, 2000) so torej prednosti metodologije Scrum naslednje: razvoj poteka v lažje obvladljivih ciklih; razvoj poteka tudi pri pomanjkljivo določenih zahtevah; omogočena je preglednost razvoja; poveča se komunikacija razvojne skupine; uspehe prejema razvojna skupina kot celota; naročnik vidi postopen razvoj sistema; naročnik lahko med razvojem preverja delovanje posameznih delov sistema; komunikacija in zaupanje med naročnikom in razvijalci se izboljša; Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 43

45 vzpostavitev okolja v katerem vsi verjamejo v uspeh sistema. Med slabost metodologije, ki sta jo omenila že Schwaber in Beedle (Schwaber, 2001), sodi zahteva po spremembi obnašanja vodilnih delavcev. Skrbnik metodologije Scrum ima podobno vlogo kot vodja projekta pri drugih metodologijah s pomembno razliko, da je pri metodologiji Scrum ta vloga bolj svetovalna kot vodilna. Odločitve sprejema razvojna skupina, skrbnik metodologije Scrum jim le svetuje in ne ukazuje. Vodstveni kadri morajo upoštevati to pravilo, kar ni vedno enostavno. Po drugi strani pa mora skrbnik metodologije Scrum aktivno nadzorovati razvoj in tudi odločno nastopati v primeru nesporazumov v razvojni skupini oziroma v primeru, če hoče naročnik vplivati na razvojno skupino med izvajanjem teka. Uspeh uporabe metodologije je v veliki meri od pripravljenosti ljudi, da sprejmejo namenjeno vlogo in njene odgovornosti ter svoje naloge izvajajo v skladu s pravili metodologije Scrum. Metodologije na primer ni mogoče uporabljati, če naročnik ni pripravljen sodelovati pri razvoju sistema. Metodologija Scrum ne podpira vseh faz v razvoju programske opreme. Iz slike 7, ki je vzeta po (Abrahamsson, 2002) je razvidno, katere faze razvoja programske opreme podpira metodologija Scrum in na kakšni ravni je to podprto. Slika 7: Faze razvoja programske opreme, ki jih podpira metodologija Scrum (Abrahamsson, 2002) Metodologija Scrum podpira fazo razvoja koncepta, fazo specifikacije zahtev, načrtovanja, kodiranja, preverjanja, pregled integracije, sistemsko preverjanje, sprejemni test in nato preseli sistem v uporabo. Pri nivojih se pregleduje s treh nivojev. Prvi nivo prikazuje, če faza metodologije omogoča podporo za vodenje projekta (zagotavljanje podatkov, s pomočjo katerih se lahko usmerja projekt). Drugi nivo prikazuje, če metodologija vsebuje natančnejši opis procesa delovanja faze, medtem ko tretji označuje, če so definirane prakse, aktivnosti in orodja, ki jih Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 44

46 metodologija predlaga oziroma zahteva pri določeni fazi. Svetla (siva) barva kaže, da faza na določenem nivoju ni podprta, medtem ko temna (črna) barva označuje podporo. Slika 7 prikazuje, da je metodologija Scrum usmerjena predvsem v vodenje projekta, veliko manj pa se posveča določitvi procesov in priporočanju napotkov za izdelavo projekta. Z vidika vodenja metodologija skrbi za vse faze razvoja od specifikacij zahtev do tiste z integracijskimi testi. Preko celotne faze razvoja se namreč med dnevnimi sestanki ter sestanki na začetku in koncu teka nabirajo informacije o poteku razvoja s pomočjo katerih se lahko vodi projekt. V metodologiji Scrum sta le dve fazi podprti na vseh treh nivojih, to sta specifikacija zahtev in integracijski test. Specifikacija zahtev je potrebna za sestavo dnevnika izdelka, s katerim se projekt vodi. Natančen opis postopka sestave dnevnika je opisan v metodologiji, poleg tega pa so v definiciji metodologije predstavljeni tudi primeri sestavljanja dnevnika in aktivnosti posameznih vlog pri sestavi dnevnika. Navadno se uvede metodologijo Scrum na začetku novega projekta. Pri tem je potrebno najprej porabiti nekaj dni za pripravo prve verzije dnevnika izdelka. Ta čas se porabi tudi za izobraževanje razvijalcev, kjer se jim pojasni osnovna pravila metodologije. Tipičen cilj prvega teka je predstavitev ključnega dela projekta s pomočjo izbrane tehnologije ter možnosti za nadaljnji razvoj. Vse ostalo se dokončno izoblikuje med izvajanjem nadaljnjih tekov razvoja. Drugi način uvedbe metodologije je uvajanje metodologije za že obstoječi projekt, kjer je razvojno okolje že postavljeno, razvojna skupina pa ima težave pri izvedbi projekta zaradi spreminjajočih zahtev ali zapletene uporabe tehnologije. Tukaj se Scrum vpelje postopoma, pri čemer se začne z dnevnimi Scrum sestanki. Potrebno je tudi določiti čas, do katerega bo nastal delujoč del projekta, ki ga bo mogoče oceniti. Po predstavitvi delovanja in ocenitvi s strani naročnika se sledi navodilom metodologije za normalno vpeljavo novega teka (običajno je to tek številka 2). Nekatere splošne prakse Scrum-a so sledeče: Stranka postane del razvojne ekipe (stranka mora biti resnično zainteresirana za končni izdelek). Scrum ima značilnost, da se izdelek med razvojem večkrat predstavi stranki z delujočimi funkcionalnostmi. To omogoča kupcu, da delajo s programsko opremo prej in jim omogoča, da se tokom projekta lahko odločijo za spremembo svojih zahtev v skladu s spreminjajočim se potrebami. Zmanjšano je tveganje o izdelku, ki ne bi zadoščal zahtevam, kajti na vsaki stopnji se opravi nadzor in potrditev novih nadgradenj. Preglednost je pri načrtovanju in razvoju izdelka. Vsi vedo, kdo je odgovoren za kaj in kdaj. Na pogostih srečanjih zainteresiranih strani se spremlja napredek novih posodobitev. Na voljo mora biti mehanizem vnaprejšnjega opozarjanja, t.j. prepoznavnost potencialnih odstopanj ali odstopanje od roka. Niti najmanjših problemov se ne skriva. Nihče ni kaznovan za odkritje ali poročanje o nepredvidenih težavah. Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 45

47 Delovno okolje mora biti prijazno in za delavce spodbujevalno. Več delovnih ur ne pomeni nujno izdelati več. Slika 8: Prikaz razmerja produktivnosti in števila tedenskih ur (Baird, 2002) Kratkoročno opravljanje nadur produktivnost na projektu poveča, kar kaže tudi slika 8 vzeta iz (Baird, 2002). Na njej je prikazano razmerje med produktivnostjo in številom opravljenih tedenskih ur. Iz grafa se vidi, da produktivnost še narašča po 40 tedenskih urah, vendar z zmeraj manjšim naklonom, ustavi pa se približno pri 60 tedenskih urah. Manjšanje naklona se pripiše porabi časa za odpravljanje napak, ki se pojavijo zaradi utrujenosti. Dolgoročno opravljanje nadur poveča razdraženost, ter slabša komunikacijo in odnose med ljudmi. Vse skupaj povzroči zmanjšano produktivnost in kakovost rešitve Razširjena uporaba Scrum-a Čeprav je bil prvotno Scrum uporabljen za razvoj programske opreme, se ga lahko uspešno uporablja tudi v drugih industrijah. Zdaj se na Scrum pogosto gleda kot na iterativni, primarni proces razvoja izdelkov ali opravljanja kakršnega koli dela (Schwaber, 2004). 2.5 Povezovanje metod CMMI in Scrum Številne agilne metode, ki so se pojavile v zadnjem desetletju, so v nasprotju z disciplinarnim pristopom, ki jih zagovarja model kakovosti CMMI. V agilnih metodah sta vrednost posameznikov in odnosov bolj pomembna kot so procesi in orodja, delujoči program je bolj pomemben kot celovita dokumentacija, sodelovanje strank je pomembnejše kot pogajanje okoli pogodb in odziv na spremembe je pomembnejši kot naslednji plan izvedbe. Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 46

48 Glede na raziskave iz marca 2007 (Ambler, 2007) dela 69% od 781 anketirancev v podjetjih, kjer so sprejeli eno ali več agilnih metod. Raziskava iz leta 2006 (Wailgum, 2007) poroča, da je 41% uspešnost pri agilnih projektih v nasprotju s tradicionalnim slapovnim načinom razvoja programske opreme, kjer je uspešnost 16%. Izkušnje so pokazale, da vpeljava agilnih metod izboljšuje management razvojnega procesa in odnose s strankami (Ceschi, 2005), pri tem pa se zmanjša količina nadur zaposlenih in poveča se zadovoljstvo strank (Mann, 2005). Seznam podjetji, ki uporabljajo Scrum vključuje podjetja kot so IBM, Microsoft, SAP, Google in Yahoo (Scrum Alliance, 2009). Na prvi pogled se zdijo agilni koncepti v nasprotju s disciplinarnim pristopom, ki ga zagovarja model CMMI, vendar vse več avtorjev predstavlja način, da je možno zgraditi tak organizacijski proces izdelave programske opreme, ki je v sožitju tako z agilnimi metodami kot tudi z disciplinarnim modelom kakovosti. Da sta metodi CMMI in Scrum združljivi, da se dopolnjujeta in da je njuno povezovanje koristno, opisujeta avtorja Jakobsen in Johnson v članku»mature Agile with a twist of CMMI« Scrum kot meta model Slika 9: Scrum kot meta model (Mahnič, 2007) Slovenska avtorja Mahnič in Žabkar sta vključila metode in prakse CMMI v Scrum z namero spremljanja in izboljšanja procesa razvijanja programske opreme. V svojem članku»introducing CMMI Measurement and Analysis Practices into Scrum-based Software Development Process«, podata meta entitetni model Scrum-a (slika 9), ki Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 47

49 ga nadgradita, tako da se lahko uporablja za spremljanje zadovoljstva različnih interesnih skupin (Skica modela merjenja, slika 10). Povezava CMMI in Scrum je narejena tako, da se CMMI prakse za merjenje in analizo (MA) lahko uvedejo, brez da bi se pri tem omejilo agilni proces razvoja programske opreme. Iz slike 9 je razvidno, da za vsak izdelek/projekt (ang. Product) mora obstajati dnevnik izdelka/projekta (ang. Product Backlog), ta pa vsebuje več zahtev (ang. Product Backlog Item - PBI). Za vsako zahtevo pa so podane ena ali več ocen o preostanku dela (ang. PBI Work Remaining). Vsak izdelek se izvaja prek več tekov oz. iteracij (ang. Sprint). Zaradi boljše preglednosti so dogodki: uvodni sestanek teka (ang. Sprint Planning Meeting) recenzija teka (ang. Sprint Review Meeting) retrospektiva teka (ang. Sprint Retrospective Meeting) dnevni sestanek Scrum (ang. Daily Scrum Meeting) povezani z vsakim tekom prikazani kot ločene entitete. Za vsak tek je potrebno vzdrževati dnevnik teka (ang. Sprint Backlog), da ustreza zahtevam, za katere se je razvojna skupina (ang. Team) zavezala, da jih bo izvajala tokom teka. Vsaka zahteva je razdeljena na več nalog (ang. Task) in za vsako nalogo je podana ocena o preostanku dela (ang. Task Work Remaining) temelječ na dnevni osnovi. Implementacija teka je dodeljena razvojni skupini, ki je sestavljena iz več članov (ang. Team Member), vsak od njih pa je odgovoren za več nalog. Za vsak izdelek mora biti določen lastnik izdelka (ang. Product owner, ki je bodisi eden izmed zaposlenih ali pa je predstavnik kupca) in za vsako razvojno skupino mora obstajati skrbnik metodologije Scrum (ang. Scrum Master). Več tekov je lahko vključenih v eno verzijo programske opreme (ang. Release), vendar izkušnje razvijalcev so pokazale, da razvojna ekipa dela znotraj enega teka za različne verzije, kar pomeni, da je relacija med tekom in verzijo gre lahko samo preko zahtev Model merjenja Veliko zanimanje za agilne metodologije razvoja programske opreme ni presenetljivo, saj te predstavljajo priložnost za boljši razvoj programske opreme. Ravno to pa se zelo opaža v poslovnih krogih. Scrum je še posebno zanimiv za podjetja zaradi osredotočenosti na donosnosti naložbe. Če nas je agilni način razvoja prepričal, da je boljši način od tradicionalnih, potrebujemo izboljšane načine poročanja vodstvu. Osnovni interes vodstva je seveda napredek na projektu in celostno stanje projekta (Beštek, 2007). Podatkovni model za merjenje in shranjevanje podatkov, ki se pojavijo tokom procesa razvoja programske opreme (slika 10). Podatkovni model je izpeljan iz meta modela predstavljenem v prejšnjem poglavju (slika 9) z nadgradnjo entitet, ki opisujejo ustrezna merjenja in omogočajo umestitev merilnih rezultatov. Nekatere nove entitete so uvedene, da je omogočeno beleženje opisa nalog (katera dela so bila opravljena in trenutno stanje posamezne naloge). Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 48

50 Sledenje oviram je uvedeno zato, da se zagotovi podatke, ki so potrebni za izračun povprečnega števila ovir na nalogo/tek/razvojno skupino in povprečni čas za odpravljanje ovir na ravni naloge/teka/razvojne skupine. Vsaka ovira je zapisana v entiteti ovir (ang. Impediment) vsebujoč unikatni ključ ovire, opis, datum kdaj je ovira nastopila in datum kdaj je bila rešena. Entiteta ovira vsebuje tudi tuje ključe, ki imajo relacijo do razvojne skupine (ang. Team), ki je naletela na oviro, na tek (ang. Sprint), kjer je bila ovira zaznana in na entiteto zaposlenih (ang. Employee), kjer je navedeno kdo je odgovoren za odpravo nastale ovire. Klasifikacija na vrsto opravljenega dela je potrebna, če hočemo spremljati količino različnih vrst nalog tokom vsakega teka (npr. razvoja, testiranja, predelava zaradi napak, ki jih je posredovala stranka, predelava zaradi sprememb v zahtevah, itd.). Vsak zapis v tabeli vrsta naloge (ang. Task Type) opredeljuje enega od prej navedenih vrst nalog, tako je vsaki organizaciji omogočeno določiti svojo klasifikacijo, ki ji najbolj ustreza. Za pravilno delovanje takšnega merilnega sistema je potrebno zagotoviti, da je vsaki nalogi v dnevniku teka dodeljena ustrezna vrsta naloge. Slika 10: Modela merjenja (Mahnič, 2007) Na podoben način, kot je klasifikacija nalog, je vpeljan trenutni status naloge. Zapis v entiteti status naloge (ang. Task Status) opisuje vse možne statuse v dnevniku nalog (npr. naloga se še ni začela, je v delu, zaključena, izpuščena, prestavljena v Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 49

51 naslednji tek, itd.). Skrbnik metodologije Scrum vzdržuje statuse za vsako nalogo preko dnevnega sestanka Scrum, hkrati pa tudi vpisuje koliko časa je bilo že porabljenega in koliko časa je ocenjeno za dokončanje posamezne naloge. Vodenje evidence o nedelovnih dneh (t.j. bolniške, dopusti, študentski dopusti in dnevi za udeležbo na seminarjih), ko član razvojne skupine ni na delovnem mestu omogoča natančen izračun o opravljenih urah. Ko je član razvojne skupine odsoten (in posledično ni udeležen na dnevnem sestanku Scrum), skrbnik metodologije Scrum preprosto evidentira njegovo odsotnost z zapisov v entiteti upravni dnevi (ang. Administrative Days). Entiteta vrsta odsotnosti (ang. Absence Type) je potrebna, če hočemo spremljati različne vrste odsotnosti podrobneje. Za natančen izračun stroškov del je potrebno vnesti za vsakega člana razvojne skupine njegovo urno postavko. Ker se urna postavka lahko spreminja pri vsakem članu razvojne skupine tokom projekta, sploh če je ta daljši, je sprejemljivejša rešitev, da je urna postavka atribut entitete nalog zapisan v času, ko je naloga ustvarjenja in določena članu razvojne skupine (ang. Team Member). V praksi se izkaže, da ljudje manjšajo obseg dela, kjer imajo manjšo urno postavko in večajo obseg dela na aktivnostih, kjer imajo večjo urno postavko. Če se odločimo za različno urno postavko pri posameznem članu, to naredimo le pri aktivnostih, ki se ne prepletajo in niso povezane niti v trenutnem času, niti rezultati dela ene aktivnosti niso vključene v aktivnost druge. V kolikor to ne drži se raje odločimo za enotno urno postavko, ki je sorazmerna z obsegom del na vseh aktivnostih. Vsaka meritev je predstavljena v entiteti meritev (ang. Measure), medtem ko so rezultati meritev shranjeni v entitetah merjenja: rezultati merjenja verzij (ang. Release Measurement Result) rezultati merjenja tekov (ang. Sprint Mesaurement Result) rezultati merjenja zahtev (ang. PBI Measurement Result) rezultati merjenja nalog (ang. Task Measurement Result) Predstavljen je model merjenja, ki omogoča spremljanje in stalno izboljševanje učinkovitosti v procesu razvoja programske opreme z metodo Scrum. Vpeljano merjenje je bilo prilagojeno na značilnosti metode Scrum, ki jih predpisuje za merjenje in analizo metoda CMMI. 2.6 Informacijski sistem za podporo upravljanju in vodenju IT projektov V splošnem obstaja več oblik informacijske in dokumentacijske podpore projektom. Razlikujejo se predvsem v nivoju uporabljene tehnološke podpore. Izbira nivoja podpore je odvisna od vrste projekta, obsega projekta, sodelujočih v projektu, znanja in izkušenj članov, itd. V veliki meri je rešitev odvisna od okolja v katerem se projekti izvajajo. Projekt je lahko učinkovit in uspešen, v kolikor imajo vse skupine udeležencev v projektu v vsakem trenutku ustrezne in zadostne informacije, da opravijo svoje delo. Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 50

52 Za to je potrebno vzpostaviti organizacijski sistem, ki pa mora biti podprt s projektnim sistemom (Kern, 2003). Za vzpostavitev projektnega informacijskega sistema je treba definirati naslednje pojme: Katere so skupine udeležencev v projektu; Kaj so ustrezne in zadostne informacije za posamezno skupino udeležencev; Kateri so tisti procesi, ki zagotavljajo te informacije; Kakšna naj bo informacijska tehnologija, da bo projektni sistem uporaben. Ko obravnavamo informacijsko obvladovanje projektov, je potrebno zagotoviti dve vrsti informacij: Prve so informacije, ki podpirajo izvajanje projekta. To so informacije o vsebini projekta oziroma o objektu projekta. To so navadno tehnične informacije in so v vsaki vrsti projekta različne. To so lahko načrti, izračuni, preračuni, odločbe, recepture, informacijski modeli, rezultati analiz, ipd. Običajno jih shranjujemo v obliki dokumentov v papirni ali elektronski obliki; Druge so informacije o organizaciji projekta. Te omogočajo pripravo, vodenje in zaključevanje. Ker so namenjene obvladovanju podpornih procesov in same po sebi ne dodajajo vrednosti v projekt, jih je treba minimalizirati. V to kategorijo sodijo katera od oblik projektne listine, zapisniki sestankov, periodična poročila, poročila o napredovanju projekta, zaključna poročila, ipd Zahteve za informacijski sistem za podporo upravljanju in vodenju projektov Po tehnični plati naj bi projektni informacijski sistem vseboval naslednje lastnosti (Skok, 2006): Enkratni vnos podatkov: potreben je samo enkraten vnos podatkov, kasneje pa so le-ti na voljo vsem aplikacijam, ki jih potrebujejo; Integracija podatkov: različna orodja, ki so del informacijskega sistema, dostopajo do vseh podatkov. Podatkovna integracija zahteva, da imajo podatki enak pomen, predstavitev in enote po posameznih orodjih. Na primer, če imata dve orodji del podatkov o trajanju nalog, morata obe orodji uporabljati isti koledar in biti usklajeni glede načina prikazovanja opravljenega dela v delovnih ali koledarskih dnevih; Integracija kontrol: možnost, da določeno orodje kliče operacije na drugih orodjih npr. pošiljanje elektronske pošte, osveževanje podatkov, itd.; Oblikovna celovitost: označuje potrebo po enotnem oblikovnem in funkcionalnem izgledu in občutku v skupini orodij. Ta značilnost predstavlja ključen dejavnik za uspešno uporabljanje orodij; Zmožnost združevanja in analize: različni nivoji v organizaciji potrebujejo informacije z različnimi nivoji podrobnosti. Informacijski sistem mora biti sposoben filtriranja in združevanja podatkov; Odprtost: predstavlja zmožnost dodajanja funkcionalnosti, kot npr. modula tveganj ali podaljška za načrtovanje kritične poti, skozi pridobitev posebnih»add on«aplikacij ali makro programiranja, ali dodajanjem podatkovnih polj v bazo podatkov z namenom zagotavljanja specifičnih potreb projekta; Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 51

53 Interaktivnost: malo managerjev se pri sprejemanju odločitev zanaša samo na rezultat optimizacijskih algoritmov. Rezultat algoritma izravnavanja virov redko proizvede plan, ki ga izkušen projektni manager dejansko sprejme. Izkušeni projektni managerji pri odločanju uporabljajo sklepanje na bazi prepoznavanja, zato morajo orodja podpirati to kognitivno strategijo z zagotavljanjem rezultatov, najbolje v obliki grafov. Ob tem pa uporabnika sprašujejo še za dodatna navodila za nove prikaze. Proces se ponavlja, dokler uporabnik ni zadovoljen z rezultati; Poročanje o izjemah: informacijski sistem mora integrirati več virov podatkov in s tem zagotoviti celovit pregled nad tem, kaj se dogaja na projektih v odnosu do celotnega portfelja. Preko e-pošte mora omogočati poročanje o izjemah glede na postavljena pravila s strani uporabnikov; Varnost in pogledi: projektni in kadrovski managerji potrebujejo svojim potrebam prilagojene podatke. Informacijski sistem mora podpirati različne poglede, ki so skladni z vlogo posameznega uporabnika. Pravice dostopa (kaj lahko kdo bere, dodaja, spreminja ali briše) morajo temeljiti na vlogah uporabnikov in morajo biti centralno upravljane. Bistvene funkcionalnosti: Obvladovanje časa: pokriva področje časovnih razporedov, rokov za posamezne programe, projekte in naloge; Upravljanje z viri: vključuje alokacijo razpoložljivega osebja z uporabo zbirke profilov virov in omogoča dodeljevanje nalog virom in izravnavo; Obvladovanje stroškov: spremlja stroške virov in drugih stroškov ter sodeluje pri potrjevanju projektnih stroškov, vključno s stroški, povezanimi z zaračunavanjem, povračili, opremo in drugim materialom. Dodatne funkcionalnosti: Obvladovanje obsega: vključuje planiranje preliminarnih potreb vključno z določanjem projektnih izdelkov. Lahko vključuje tudi predloge za spremljanje ali ocene v primerjavi z dejanskimi stroški; Obvladovanje oskrbe: podpira pridobivanje zunanjih virov (npr. pogodbenih izvajalcev) in s projekti povezanimi stvarmi (vključno z informacijsko infrastrukturo); Obvladovanje komunikacij: vključuje distribucijo informacij (npr. diskusije, elektronska pošta in pogovori) in ustvarjanje projektne inteligence, ki sodelujočim omogoča sodelovanje, vzdrževanje, upravljanje in izmenjavo znanj. Orodja lahko vključujejo dokumentne sisteme in sisteme za upravljanje z znanjem kot tudi sisteme za upravljanje delovnih procesov in zbirko predlog; Obvladovanje tveganj: zavzema globalen pogled na multiprojektno okolje; Obvladovanje kakovosti: vključuje uporabo organizacijskih ali industrijskih standardov, metodologij, projektnih modelov, standardiziranih predlog, projektnega znanja in merjenja učinkovitosti definiranih procesov za zagotavljanje kakovosti, konsistentnosti projektov v izvajanju in njihovih izdelkov; Obvladovanje interakcij (portfelja) zagotavlja poslovno inteligenco z namenom usklajevanja portfelja, planiranja in realizacije projektov. Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 52

54 2.6.2 Informacijska podpora projektu in uporabljene informacijske tehnologije Obstaja več oblik informacijske in dokumentacijske podpore projektom, katere se razlikujejo predvsem v nivoju uporabljene tehnološke podpore. Izbira nivoja podpore je predvsem odvisna od vrste projekta, velikosti in obsegu projekta, sodelujočih v projektu, znanja in izkušenj članov, itd. Rešitev je v veliki odvisnosti od okolja, v katerem se projekti izvajajo. V najenostavnejšem primeru ne uporabimo za podporo projektnemu informacijskemu sistemu nikakršne informacijske tehnologije. Tovrstna "popolnoma ročna" rešitev je primerna za enostavne projekte ali za projekte, ki potekajo v okolju, kjer je tovrstno tehnologijo nemogoče dovolj hitro in poceni implementirati. Navadno sta vzrok za to pomanjkanje znanja, časa ali volje sodelujočih. Problemi, ki lahko zato nastopijo, so znani. Večinoma se nanašajo na dolgotrajno čakanje in iskanje posameznih dokumentov, predvsem pa povzročajo zamude in odvečne stroške administracije. Taka rešitev je enostavna, ni pa učinkovita (Kern, 2003). V zadnjem času je mogoče uporabiti zelo enostavno rešitev. Gre za vzpostavitev statične spletne strani, s katero je mogoče zadovoljivo obvladovati izvajanje posamičnega enostavnega projekta. Ta rešitev je primerna predvsem takrat, ko okoliščine zahtevajo izjemno hitro vzpostavitev delovnega okolja, kjer je bistvena možnost vpogleda v projektno in tehnično dokumentacijo, kjer sodeluje veliko število ljudi na različnih lokacijah v ne strukturiranem okolju in kjer je dostopna le osnovna informacijska in komunikacijska tehnologija. Slaba stran te rešitve je, da jo je potrebno izdelati vsakič znova, ne omogoča povezovanja več projektov in zahteva veliko vzdrževanja. Navadno je šibko povezana z orodji za mrežno planiranje. Problematičen je tudi avtomatski prenos dokumentacije in povezava s skupno bazo podatkov ali z orodjem za podporo mrežnemu planiranju. Ena izmed možnosti je izdelava ali uporaba dinamičnega spletnega mesta»portala«. Ta možnost je zlasti zanimiva za organizacije, kjer se večkrat pojavijo manjši projekti, vendar okolje ni dovolj strukturirano za uporabo zahtevnejših rešitev. Spletna mesta za podporo projektnemu vodenju komercialnih ponudnikov so že nekaj časa na voljo. Prednost tovrstnih rešitev je predvsem v enostavni uporabi, kljub temu pa zagotavljajo lažje vzdrževanje in določeno mero kontrole. Povezava z orodji za podporo mrežnemu planiranju je mogoča, vendar je dokaj zahtevna. Zahtevnejše specialne informacijske rešitve za podporo projektnim informacijskim sistemom uporabljajo za osnovo različne dokumentacijske oziroma»workflow«sisteme (npr. Lotus Notes, MS SP Portal Server). Prednosti tovrstnih rešitev so predvsem v tem, da podpirajo vse nivoje projektnega dela, možen je vpogled v projekt s poljubnega mesta, omogoča vodenje in upravljanje večjega števila projektov, nudijo zelo dobro zaščito podatkov, omogočajo povezavo z orodji za mrežno planiranje in o zelo prilagodljive. Slabost je predvsem v tem, da so te rešitve precej kompleksne in zato tudi drage, zahtevajo sistemsko administracijo (obvezna projektna pisarna ali projektni tajnik) in so primerna zlasti za dobro strukturirana okolja (podjetja) z ustrezno formalizacijo (npr. organizacijski predpis o projektnem delu) in za projekte, ki so si strukturno dokaj podobni. Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 53

55 Najzahtevnejše integralne rešitve so vezane na sodobne ERP sisteme v podjetjih. Iz tega sledi, da z njimi lahko obvladujemo velike projekte ali izrazito dobro strukturirane projekte v urejenem okolju. Za implementacijo potrebujemo več časa, sistemi pa so razmeroma dragi. Po drugi strani pa imajo več prednosti: so integralni del informacijskega sistema podjetja ali ustanove, omogočajo planiranje, analizo in spremljanje projektov, omogočajo sistematično obvladovanje virov, stroškov, časov, omogočajo poročanje na različne načine in povezave s celotnim poslovnim sistemom ter ostalimi procesi v poslovnem sistemu. Seveda so zato kompleksni in pogosto niso primerni za obvladovanje vseh projektov v poslovnem sistemu. Poleg tega so dokaj togi in neprilagodljivi in jih je zelo težko implementirati (Skok, 2006). Za vodenje projektov je potrebno oblikovati primeren informacijski sistem, ki mora zadovoljiti informacijske potrebe organizacijskih sistemov v projektu: glavnega sistema, skrbniškega sistema in izvajalnih sistemov. Opredeljujeta pa ga dva osnovna informacijska tokova primarni in sekundarni (Rant, 1995). Obe vrsti informacijskih tokov je treba obravnavati na nivoju pretoka informacij med skrbniškim sistemom in glavnim sistemom ter na nivoju pretoka informacij med skrbniškim sistemom in izvajalnimi sistemi. Primarni informacijski tok zajema informacije iz plana projekta in vsebinske informacije v zvezi z dejavnostmi. To so: oznaka in opis dejavnosti, časovni parametri mrežnega plana, podatki o predhodnih in naslednjih dejavnostih, popis stroškov in potrebnih virov (specifikacije tehnične dokumentacije, specifikacije opreme, ki se mora nabaviti ali izdelati, itd.) za izvedbo. Sekundarni informacijski tok zajema podatke v zvezi s potekom projekta. To so predvsem informacije o procentu realizacije, finančni situaciji projekta, omejitvah, problematiki in eventualnih spremembah. V praksi se pogosto meni, da je plan projekta (npr. mrežni plan) osnova, na kateri sloni izgradnja projektnega informacijskega sistema. Vendar graditi informacijski sistem samo na teh osnovah ni dovolj, ne glede na to, ali se pri tej izgradnji opira na ročno obdelavo ali na računalniško podprt projektni informacijski sistem. Projektni informacijski sistem se mora povezati v informacijski sistem organizacije, ki je projekt aktivirala (Kern, 1990). 2.7 Projektni informacijski sistem Prosis Projekti se v sodobnem poslovnem svetu ne izvajajo več kot samostojni in od poslovnega sveta ograjeni otoki. Praviloma potekajo znotraj enega, najpogosteje pa več podjetij oz. ustanov, so prepleteni med seboj in povezani z ostalimi poslovnimi procesi. Posebnost projektov je, da so»enkratni poslovni procesi«in zato zahtevajo vsakokrat posebno pripravo, drugačno vodenje, specifično definirane vloge Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 54

56 sodelujočih, prilagojeno informacijsko in dokumentacijsko podporo in posebej razvito organizacijsko kulturo. Vendar pa hkrati zahtevajo sodelovanje istih ljudi, ki so že angažirani v ostalih procesih, trošijo enake vire, potekajo v istem prostoru in času kot ostali poslovni procesi in pričakujejo finančna sredstva iz istih virov. Projekte torej obvladujemo na poseben način. Članom projektnih timov je potrebno pustiti pri njihovem delu veliko svobode! Obenem pa projektni sistem v nekem podjetju ali ustanovi, zahteva da vse projekte (celoten»projektni portfolio«) upravljamo in vodimo, kot celoto in hkrati skupaj z ostalimi procesi. To predstavlja ob izredni dinamiki sprememb in visokih zahtevah poslovnega okolja za mnoga podjetja in ustanove velik problem. Hkrati pa je to priložnost za tista podjetja, ki so ta organizacijski izziv sposobna sprejeti. Izkaže se, da ob vpeljavi sistemske rešitve lahko uspemo! Slika 11: Programsko orodje - Prosis Podpori takim prizadevanjem je namenjen projektni sistem Prosis. Prosis je sestavljen iz več povezanih podsistemov, ki se v podjetje ali ustanovo praviloma uvajajo postopoma, vendar vselej v celoti! Prosis ni zgolj informacijska podpora projektnemu sistemu temveč je koncipiran kot projektni sistem v celoti. Projektni sistem Prosis se uvaja fazno in v več segmentih. Vselej je uvajanje odvisno od posebnosti in potreb podjetja. V prvi fazi se vselej uredi organizacijski in kadrovski segment projektnega okolja. Nato se lotimo informacijske in dokumentacijske podpore, ki omogoča implementacijo in kasnejšo učinkovito uporabo projektnega sistema. Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 55

57 Brez ustrezne informacijske in dokumentacijske podpore obvladovanje projektov v današnjem času ni mogoče, hkrati pa izkušnje opozarjajo, da neustrezno uvajanje lahko bolj škodi kot koristi. Informacijska in dokumentacijska podpora projektom je nujna, vendar pa mora biti v celoti prilagojena potrebam projektov v podjetju in implementirana šele takrat, ko je podjetje organizacijsko in kadrovsko pripravljeno da izkoristi možnosti, ki jih tehnologija nudi (Protal, 2009). Povezani podsistemi Prosis-a omogočajo vključevanje in celovito obvladovanje projektov v poslovnem sistemu. Ti podsistemi so: organizacijski podsistem; kadrovski podsistem; informacijski podsistem in dokumentacijski podsistem Dokumentacijski in informacijski podsistem Prosis-a Organizacijski in kadrovski segment sta odvisna od specifičnih potreb posameznega podjetja. Informacijski in dokumentacijski del sta posledično podrejena. Informacijsko in dokumentacijsko jedro Prosis-a je odprto in ga je mogoče prilagoditi potrebam ter poslovnim informacijskim sistemom posameznega podjetja. Jedro Prosis-a je programska rešitev, t.i. Projektni portal Prosis, ki predstavlja informacijski in dokumentacijski segment Projektnega sistema. Informacijski podsistem Prosis-a omogoča: izrabo vseh možnosti, ki jih nudita "projektno prijazni" organizacijski in kadrovski sistem; podporo pri zbiranju, obdelavi in izboru pobud za projekte; podporo procesom inicializacije, koncipiranja, planiranja, izvajanja in zaključevanja projektov; podporo upravljavcem pri odločanju v multi-projektnem okolju ob določanju ciljev, omejitev, prioritet in pri prevzemanju rezultatov; podporo vodjem projektov pri pripravi in odrejanju dela, spremljanju napredovanja, obvladovanju sprememb in zaključevanju dela; podporo pri obvladovanju obremenitev izvajalcev, terminskega in stroškovnega vidika projekta; podporo izvajalcem pri pridobivanju potrebnih informacij za izvajanje; aktivnosti pri periodičnem poročanju in pri poročanju o rezultatih aktivnosti. Dokumentacijski podsistem Prosis-a pa omogoča: izdelavo, hranjenje in distribucijo tehnične (vsebinske) in projektne (organizacijske) dokumentacije ne glede na vsebino in obliko; obvladovanje različnih statusov dokumentacije; obvladovanje različnih verzij dokumentacije; obvladovanje arhiva vseh dokumentov; popolno varnostno shemo pri dostopu do podatkov in dokumentov za različne projektne vloge in posameznega uporabnika. Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 56

58 2.7.2 Arhitektura sistema Prosis Uporabljena je tehnologija Microsoft.NET 6. Aplikacija je povezana s centralno bazo podatkov in centralnimi strežniki. Odjemalci se nahajajo na različnih lokacijah in so povezani preko metod spletnih storitev internetnega omrežja. Podatkovni sloj uporablja strežnike Windows 2003 in DBMS MS SQLServer Vse manipulacije na podatkovnih strežnikih so izvedene preko shranjenih procedur. Transakcijski sloj uporablja en podatkovni strežnik. Dodatni SQL strežniki se uporabljajo za varnostno kopijo (backup copy) osnovne podatkovne baze. Predstavitveni sloj je Windows aplikacija, ki teče v upravljanem okolju Microsoft.Net. Uporabniški vmesnik je namenjen več uporabnikom, ki aplikacijo uporabljajo vsakodnevno za svoje osnovno delo. Uporabnik ima lahko pravico do dela na več področjih, glede na pravice, ki mu jih določi administrator. Uporabniki lahko sami v celoti oblikujejo vsebino dokumentov. Izoblikovane dokumente (predloge) je mogoče dopolniti, popraviti, vendar je za takšno delo potrebno imeti dodeljene pravice s strani administratorja. Izvorna koda za odjemalca je pisana v programskem jeziku C# 8. Aplikacija v takem okolju ne more delovati brez povezljivosti z ostalimi aplikacijami. Glede na zahteve ciljne aplikacije so uporabljeni naslednji principi: povezljivost na nivoju baze podatkov s klici shranjenih procedur druge aplikacije; povezljivost na nivoju spletne storitve. Za uspešno izvedeno povezljivost je nujen dovolj odprt sistem, ki ga prilagodimo potrebam uporabniškega vmesnika. 6 Microsoft.NET je zaščitena blagovna znamka družbe Microsoft corporation 7 DBMS je ang. kratica za Database Management System; sistem za upravljanje podatkovnih zbirk 8 C# je nizkonivojski standardizirani programski jezik Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 57

59 3 Aplikativni del 3.1 Mikro in mala IT podjetja V aplikativnem delu je obravnavano tipično mikro oz. malo IT podjetje (definicija v poglavju 1.3), ki za informacijsko podporo pri vodenju projektov uporablja projektni informacijski sistem Prosis Osnovni podatki o podjetju Takšno IT podjetje je hitro, prilagodljivo in učinkovito ter ima jasno vizijo, ki se odraža v popolni sistemski integraciji poslovnih in tehničnih rešitev na sodobnih informacijskih tehnologijah. Podjetje je zaradi znanja in odličnega poznavanja najrazličnejših tehnologij uveljavljeno pri svetovanju, načrtovanju in izvedbi celovitih rešitev. Organizacijska struktura v podjetju je matrična, kar je posledica večjega števila projektov in prisotnosti projektnega načina dela. Hierarhija avtoritete je jasno določena, prav tako so jasno opredeljene naloge posameznih delovnih mest. Komuniciranje pa poteka tako navpično kot tudi vodoravno. Pri izvajanju projektov nudi pomoč projektna pisarna, ki izvaja naslednje funkcije: razvoj metodologije projektnega vodenja, uvajanje metodologije projektnega vodenja, priprava predlog dokumentov projektnega vodenja, pomoč projektnim vodjem pri pogajanjih za potrebne člane projektne skupine, izbor ustreznega informacijskega sistema projektne pisarne za učinkovito podporo projektom v multiprojektnem okolju, uvajanje in vsebinsko vzdrževanje informacijskega sistema projektne pisarne, nadzor nad projektnimi plani in obremenjenostjo članov projektnih skupin na projektih, priprava standardnih poročil statusa projektov, pregled kakovosti izdelkov projektnega vodenja in analiza projektov ob zaključku ter priprava predlogov za izboljšave IT projekti Informacijska tehnologija (IT) je tehnologija za zajemanje, obdelovanje, shranjevanje Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 58

60 in prenašanje vseh vrst informacij. V grobem se deli na strojno opremo (hardware), programsko opremo (software) in komunikacijsko tehnologijo. Zaradi specifičnih potreb in zahtev vsakega naročnika je razvoj in uvajanje IT v posamezno podjetje enkratno in unikatno delo. Podjetja za informacijsko tehnologijo zato izvajajo to dejavnost s projekti. IT projekti so projekti, ki se izvajajo na področju informacijskokomunikacijskih tehnologij. Zajemajo projekte razvoja, oblikovanja, izdelave, vpeljave v uporabo, vzdrževanja ali prilagajanja informacijskih tehnologij. IT projekti so lahko projekti s fizičnim objektom, lahko so projekti z abstraktnim, torej neoprijemljivim objektom (npr. programska oprema, organizacijska kultura ipd.), lahko pa imajo tako fizični kot tudi abstraktni objekt, saj lahko cilje projekta predstavljajo strojna oprema, programska oprema ali oboje skupaj. Tako poznamo: IT projekte, katerih objekt je izključno strojna oprema; IT projekte, katerih objekt je izključno programska oprema; IT projekte, katerih objekt je strojna in programska oprema; IT projekte, ki zajemajo poleg strojne in programske opreme še najrazličnejše storitve (npr. svetovanje, garancija, vzdrževanje itd.). Projekti IT lahko zajemajo tudi raziskave in razvoj na področju informacijskih tehnologij. Takšni projekti imajo značilnost razvojno-raziskovalnih projektov. Razvojni projekti so lahko projekti razvoja IT orodij ali projekti lastnega razvoja. Razvojne projekte delimo tudi na bazične raziskave, aplikativne raziskave in eksperimentalni razvoj (Hauc, 2002:69). IT projekti se med seboj lahko razlikujejo tudi po obsegu in kompleksnosti objekta projekta. Tako lahko razdelimo IT projekte na projekte, katerih objekt so: celoviti informacijski sistemi in rešitve; informacijski podsistemi (računovodstvo, nabava itd.); posodobitve, dopolnitve in popravki programske opreme. Podjetja za informacijsko tehnologijo v nekem trenutku tako vodijo več različnih projektov za različne naročnike, ti projekti pa se med seboj lahko bistveno razlikujejo v obsegu, kompleksnosti in objektu, obenem pa se nahajajo v različnih fazah. 3.2 Posnetek trenutnega stanja razvoja informacijskih rešitev Predpostavka je, da ima podjetje, ki uporablja programsko rešitev Prosis, pravilnik o projektnem delu po standardu ISO 9001:2000, kjer so zapisana podrobnejša navodila za delo, ki so v pomoč konkretnim izvajalcem posameznih aktivnosti znotraj projekta. Trenutni razvoj programske opreme temelji na slapovnem modelu razvoja programske opreme (slika 12). Metodologije predvidevajo podroben zajem značilnosti nastajajočega sistema, ustrezno dokumentiranje in zaporedni razvoj s pomočjo zapisane dokumentacije. Razvoj s pomočjo tega pristopa bi bil v idealnih razmerah učinkovit in primeren za vse vrste projektov, za različne velikosti razvojnih skupin in uporabljene tehnologije. Kljub temu se v literaturi pojavljajo opisi velikega števila projektov, ki so uporabljali tak pristop, a niso uspeli doseči pričakovanih Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 59

61 rezultatov. Neuspeh se večino pripisuje različnim motnjam med razvojem (tipični primer takih motenj so recimo spremembe zahtev s strani naročnika projekta). Model slapa zahteva na začetku izčrpno analizo naročnikovih zahtev in potreb. Skozi mesece intenzivne komunikacije med bodočimi uporabniki in razvijalci se sestavi množica trajnih in obširnih značilnosti ter funkcionalnih in nefunkcionalnih zahtev. Vse to je natančno dokumentirano za fazo načrtovanja, ki sledi. V tej fazi razvijalci naredijo popoln načrt razvoja, torej kaj se bo uporabilo in kako. Naslednja faza je kodiranje s pomočjo popolne dokumentacije. Po implementaciji se opravi še testiranje in po njej se izdelek pošlje v uporabo. Slika 12: Slapovni model razvoja programske opreme Ta proces se v teoriji sliši kot idealen način razvoja, vendar se med razvojem pojavljajo motnje, ki jih sistem ni sposoben optimalno razrešiti. Najpogostejša motnja je, da si uporabniki premislijo glede zahtev. Po mesecih zbiranja želja in pisanja dokumentacije si uporabniki še zmeraj niso edini, kaj točno želijo, vedo pa, da to, kar se razvija, ni tisto, kar bi oni želeli. Metodologija v takem primeru zahteva ponovno analizo in načrtovanje. Težava je, da je ob vsaki taki motnji težko ustaviti razvojni zagon in preiti nazaj na analizo. Ob vsaki spremembi je potrebno uskladiti tudi goro dokumentacije za nazaj, kar vzame veliko časa in energije, in to ravno med razvojno fazo, v kateri bi morali skrbeti samo za dosledno implementacijo dokumentiranih zahtev. 3.3 Posnetek trenutnega stanja vodenja projekta pri razvoju informacijskih rešitev Pri izvajanja projektnega dela morajo zaposleni, ki na projektu delajo, upoštevati naslednja načela: Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 60

62 načelo dokumentiranosti - za vsak projekt se mora voditi celotna dokumentacija tako o postopkih dela kot tudi o rezultatih (izdelkih); načelo nadziranja in poročanja - za vsak projekt se mora zagotoviti nadzor nad potekom izvajanja dela, nad izrabo virov in nad doseganjem rezultatov; načelo odgovornosti za rezultate - vsi vključeni v projekt so odgovorni za rezultate svojega dela; načelo učinkovitosti - vsi vključeni v projekt so odgovorni za učinkovito izvedbo nalog; načelo zagotavljanja kakovosti - vsi vključeni v projekt so odgovorni za kakovost rezultatov/storitev projekta v obsegu zahtev in pričakovanj naročnikov. Orodje za vodenje projektov oz. privzeta metoda za projektno delo in aplikacija, po kateri se izvajajo projekti, je Prosis, ki se smiselno uporablja glede na obseg projekta. Uporabo aplikacije razlagajo uporabniška navodila, ki opredeljujejo tudi postopek priprave, planiranja, izvajanja in zaključevanja projektov ter obvezne vsebinske elemente. Vodenje vsebinsko sorodnih projektov prevideva, da je vodja vsebinsko sorodnih projektov (npr. skupine izvedbenih projektov, režijski projekti,...), ki so v njegovi pristojnosti, zadolžen za koordinacijo projektov, usklajevanje potrebnih človeških virov, višine potrebnih sredstev, časa izvedbe ter tehnoloških rešitev, za povezovanje, nadzorovanje rezultatov projekta, operativno kontrolo izvajanja projektov, ipd Pobuda projekta Predpogoj za vzpostavitev projekta je pobuda, da se projekt vzpostavi. Pobudo za začetek projekta lahko poda kdorkoli od zaposlenih, navadno pa se izvedbeni projekt začne s pripravo pobud za javne razpise. V primeru režijskih projektov se pobude podajo le v primeru razvojnih projektov, medtem ko režijske projekte za podporo poslovanja družbe določi direktor oziroma namestnik direktorja. V primeru ko je projekt determinističen, pobudo projekta lahko nadomesti plan projekta. Pobude uporabnikov v vseh statusih odobravanja v Prosis-u so: Pobude v pripravi so le tiste pobude, ki jih uporabnik poda sam. Vsak, ki je prijavljen v Prosis, lahko kadarkoli s pobudo da možnost, da se odpre izvedbena aktivnost ali projekt. V ta status lahko prehajajo tudi pobude iz nadaljnjih statusov, in sicer takrat, ko je potrebno premisliti ali je bila pobuda sploh utemeljena oziroma ali ni bila prezgodnja. Pobude v usklajevanju so pobude uporabnikov, ki jih zaradi sorodnosti z drugimi pobudami, usklajuje oseba s pravicami za usklajevanje. Zaradi možnosti podvajanja vsebinsko podobnih pobud različnih uporabnikov strokovni tajnik običajno pred zasedanjem kolegija usklajuje pobude. Poleg tega izbira pobude za obravnavo na kolegiju, da zoži izbor, saj je čas trajanja kolegija omejen, pobude pa imajo večinoma tudi različno vsebinsko težo. Pobude v potrjevanju so pobude uporabnikov, ki so pripravljene za potrjevanje s strani oseb, ki imajo pravice za potrjevanje. Člani kolegija se pred samim Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 61

63 zasedanjem kolegija pripravijo na potrjevanje pobud, zaradi določanja primernosti in prioritete pobud. Odobrene pobude so pobude uporabnikov, ki so bile odobrene in se bodo realizirale v obliki projekta (manjše pobude, za katere ni smiselno odpirati projekta, se realizira v obliki naloge). Ko je pobuda odobrena kot projekt, se sklep o odobritvi avtomatsko prenese na zapisnik. Pobuda se razvrsti v inicializacijo projekta. Zavrnjene pobude so pobude uporabnikov, ki so bile zavrnjene. Strokovni tajnik običajno pred zasedanjem kolegija zavrne pobude, ki imajo neustrezno vsebino, vsebujejo napake ali so kako drugače neprimerne Projekt Projektno definicijo je dolžan definirati vodja projekta pred izvedbo projekta, kot to določa uporaba Prosis-a. Projektna definicija predpisuje izhodišča za projekt, cilje projekta, obseg in omejitve projekta, predpostavke in tveganja, organizacijsko strukturo za izvedbo projekta, nadziranje projekta in poročanje, zagotavljanje kakovosti v projektu, vodenje projektne dokumentacije in upravljanje z izdelki projekta, plan za izvedbo projekta, ipd. Planiranje projekta je najpomembnejša naloga v življenjskem ciklu projekta in je sorazmerna z obsegom in pomembnostjo projekta ter s številom informacij, ki so na voljo v času planiranja. Planiranje je podvrženo pogostim iteracijam, saj posamezne spremembe na projektu praviloma povzročijo več potrebnih popravkov plana. Glavni rezultati planiranja so: določitev časovnega in finančnega obsega projekta; določitev faz in aktivnosti poteka; določitev trajanja faz in aktivnosti; določitev zaporedja in soodvisnosti izvajanja faz in aktivnosti; določitev človeških virov potrebnih za izvedbo faz in aktivnosti; določitev finančnih stroškov potrebnih za izvedbo faz in aktivnosti. Potrjevanje projekta opravi vodja vsebinsko sorodnih projektov v okviru svojih pristojnosti, v kolikor projektna definicija in plan projekta vsebujeta vse zahtevane elemente. Če projekt še ni opredeljen do te mere, da bi bili znani vsi elementi projekta, se projekt lahko potrdi le začasno, nakar mora vodja projekt čimprej dopolniti. Po potrditvi projekta lahko začne vodja projekta bremeniti vire projekta. Izvajalci projekta so projektna skupina, ki lahko vključuje tudi osebe, ki niso zaposleni v družbi oziroma se lahko v celoti prenese na zunanjega izvajalca. V tem primeru vodja projekta skrbi za koordinacijo in kontrolo izvajanja projekta s strani zunanjega izvajalca in je za projekt odgovoren v enaki meri, kot če bi se izvajal v okviru zaposlenih. Enkrat mesečno lahko vodje projektov v skupni datoteki planirajo kadre za izvajanje projektov za naslednji mesec. Planiranje kadrov se lahko izvede tudi za več naslednjih mesecev. Rok in način planiranja kadrov določi vodja vsebinsko sorodnih projektov, ki tudi usklajuje njihovo obremenjenost. Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 62

64 Za izvajanje projekta je vodja projekta dolžan slediti planu projekta in ga redno vzdrževati skladno s spremembami projekta. Vsako spremembo, ki pomembno vpliva na vire projekta, je vodja projekta dolžan uskladiti z vodjo vsebinsko sorodnih projektov. Ne glede na dejstvo, da metodo dela lahko določi tudi naročnik, so zaposleni za evidentiranje delovnih ur in ostalih stroškov na projektu dolžni uporabljati Prosis. Prosis je povezljiv z orodjem MS Project, kjer skozi različne predefinirane poglede vidimo potek izvajanja projekta. Slika 13: Prosis je povezljiv z orodjem MS Project Obveznost sodelovanja določa, da je vodja projekta oziroma celotna izvajalska skupina dolžna redno in učinkovito sodelovati z naročnikom ter s tem zagotavljati uspešno izvedbo projekta. Vodja projekta je dolžan z naročnikom redno in skladno s planom projekta preverjati rezultate projekta in ob večjih odstopanjih poročati vodji vsebinsko sorodnih projektov. Naloge in pristojnosti vodje projekta so naslednje: Vodja projekta je v celoti zadolžen za izvajanje projekta. Vodja projekta redno vzdržuje plan projekta skladno s spremembami; vodi, spremlja in nadzoruje delo projektne skupine; kadar je projektnih skupin več, usklajuje glavne aktivnosti med njimi ter odloča o tehničnih in strokovnih zadevah, ki so pomembne za izvajanje projekta. O poteku projekta je dolžan voditi in hraniti vso projektno dokumentacijo od začetka do konca projekta. Vodja projekta je dolžan redno mesečno ali po potrebi poročati o poteku projekta, kot to določa Prosis oziroma vodji vsebinsko sorodnih projektov ter preverjati in potrjevati delovne ure izvajalcev projekta. Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 63

65 Vodja projekta je zadolžen za doseganje in kontrolo kvalitete izdelkov/storitev projekta. Če ugotovi, da kvaliteta izdelkov/storitev odstopa od načrtovane, predlaga ukrepe za odpravo pomanjkljivosti. Vodja projekta je dolžan preverjati in potrjevati vse stroške projekta na način, da se zagotovi kar največji možen dobiček projekta. V primeru nastopa okoliščin, ki preprečujejo ali bistveno ovirajo izvajanje planiranih aktivnosti, mora vodja projekta o takih okoliščinah nemudoma obvestiti vodjo vsebinsko sorodnih projektov. Projektna pisarna je pristojna za potrebe izvajanja administracije Prosis. Naloge projektne pisarne so predvsem, da: zagotavlja tekoče delovanje Prosis-a (v primeru nedelovanja aplikacije posreduje zahtevo zunanjemu avtorju oziroma vzdrževalcu aplikacije in posreduje ustrezno obvestilo zaposlenim); od vodstva družbe pridobi potrebne podatke za projektne izvajalce; izvaja redno črpanje finančnih podatkov iz poslovnega informacijskega sistema; skrbi za redno in sprotno obveščanje zaposlenih o spremembah Prosis-a; sodeluje s sistemskim operaterjem pri instalaciji in posodabljanju Prosis-a; novim uporabnikom Prosis-a posreduje potrebne informacije za takojšnjo uporabo Prosis-a in organizira morebitno potrebno usposabljanje za celovito uporabo Prosis-a; opozarja uporabnike Prosis-a na redno mesečno poročanje o poteku projekta, na vpisovanje in potrjevanje delovnih ur izvajalcev ter ostalih stroškov projekta; prevzema in arhivira projektno dokumentacijo v papirni obliki. Zaključek projekta je takrat, ko je zaključen v Prosis-u in ko je dokumentacija predana projektni pisarni za arhiviranje. Za nadzor nad popolnostjo in celovitostjo zaključka projekta je zadolžen vodja vsebinsko sorodnih projektov. Vodja projekta je dolžan urediti projektno mapo v digitalni in/ali papirni obliki in izpolniti vsa poročila v Prosis-u ter poslati obvestilo vodji vsebinsko sorodnih projektov, da je projekt zaključen. Vodja vsebinsko sorodnih projektov projekt pregleda, in v kolikor je ustrezno zaključen, ga potrdi, v nasprotnem primeru pozove vodjo projekta k dopolnitvi Življenjski cikel projekta Življenjski cikel projekta gre skozi več statusov v Prosis-u (slika 14): Naslednja stopnja od odobritve pobud je priprava projektov. Odobrene pobude prehajajo kot projekt skozi naslednje statuse: - Inicializacijo projekta (iz pobude) napravi član kolegija oz. skrbnik projektov po zasedanju kolegija, kjer je bila pobuda odobrena kot projekt. Inicializacijo projekta lahko pripravijo že na kolegiju, ali jo glede na sprejete sklepe pripravi projektni tajnik, ali oseba, katero na kolegiju zadolžijo za to nalogo. - Ko na kolegiju projektni tajnik ali iz njegove strani določena oseba vpiše podatke za inicializacijo projekta, se projektna definicija prestavi na Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 64

66 področje konceptov oziroma na področje koncipiranja projekta. Član kolegija oz. skrbnik projektov lahko koncipira projekt ali iz potrjene inicializacije ali direktno (brez pobude). - Plani projekta so v pristojnosti vodje projekta. Potem ko koncept projekta potrdijo člani kolegija, vodja projekta z MS Project-om 9 v okviru projektnega sistema Prosis oblikuje plan projekta. Naloge, ki jih je potrebno napraviti v sklopu planiranja projekta, so naslednje: Strukturiranje opravi vodja projekta, ko je projektna definicija v statusu plan v pripravi. Strukturiranje projekta na faze, podfaze in aktivnosti je smiselno predvsem zaradi lažjega obvladovanja projekta. Terminski plan začrta vodja projekta, ko je definirana struktura projekta (faze in aktivnosti). Terminski plan je potreben zaradi natančnejše in zanesljivejše določitve trajanja projekta. Terminski plan je možno pregledovati v vpogledu Ganttogram ali v vpogledu mrežni diagram. Plan virov napravi vodja projekta, ko je definiran okvirni terminski plan projekta. Planiranje projekta je potrebno zaradi pregleda nad obremenitvijo posameznih virov. Za vsako aktivnost v planu projekta je potrebno definirati, kateri viri jo izvajajo oziroma sodelujejo pri izvedbi. Pri tem se upošteva tako človeške vire kot tudi opremo in material. Posamezne vire je potrebno po tem, ko so bili ustrezno dodeljeni na aktivnost, še primerno razporediti oz. alocirati na posamezno aktivnost. Potrebno je določiti čas izvajanja aktivnosti oziroma ugotoviti, s kolikšno intenzivnostjo sodelujejo pri izvedbi aktivnosti. Plan stroškov napravi vodja projekta zaradi preglednosti nad stroški projekta. To napravi po tem, ko je bil definiran okvirni terminski plan projekta in plan virov. - Odobreni projekti, ko je na seji kolegija koncept projekta odobren, se pojavi v področju planiranja. - Zavrnjeni projekti, ko je na seji kolegija koncept projekta zavrnjen in tak projekt ne preide v naslednji status področje planiranja. Izvajanje projektov - Ko je projekt v izvajanju ima vsakdo, ki je prijavljen v Prosis, v vsakem trenutku možnost, da pregleda plana projekta, realizacijo projekta in dokumentacijo. - Projekt lahko preide v status prekinjeni. Projektu lahko spremenimo status. V tak projekt ni več možno poročati. Projekt tako preide v status mirovanja, dokler ga vodja ponovno ne aktivira. Zaključevanje projektov - Zaključevanje je postopek, ko se projektu spremeni status. V projekt ni več možno poročati. Izvede se zaključevanje projekta in nato formalni zaključek. - Zaključeni projekti so projekti, ki so čez vse faze prešli uspešno. 9 MS Project je Microsoft-ov program za vodenje projektov. Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 65

67 Slika 14: Trenutni življenjski cikel projekta Pri pripravi projektov obstaja opcija hitre priprave projekta, kjer ima član kolegija oziroma skrbnik projektov kadarkoli možnost hitre priprave projektov, zaradi hitrejšega dela pri pripravi projektne definicije. Taka priprava projekta gre direktno v status inicializacija, koncept ali plan. Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 66

68 3.3.4 Projektna mapa Ob zaključku projekta vodja projekta pregleda dosežene rezultate po vsebinski (izdelki), časovni (terminski plan), stroškovni (stroški) in kadrovski komponenti (poraba planiranih resursov) ter kompletira projektno mapo, katere vsebina se lahko razlikuje glede na velikost in pomembnost projekta. Priporočljivo je, da projektna mapa vsebuje naslednje elemente: 1. Osnovni podatki o projektu: cilj projekta; povzetek projektne naloge; opis izdelkov projekta; opis problematike pri izvajanju projekta; mnenja in priporočila. 2. Plan in realizacija projekta po posameznih projektnih elementih: členitev projekta po fazah/aktivnostih; terminski plan po fazah/aktivnostih; število ur po osebah na posameznih aktivnostih projekta; stroški po osebah; stroški po posameznih fazah/aktivnostih; stroški podizvajalcev; materialni stroški. 3. Finančno poročilo projekta sumarno poročilo glede stroškov in prihodkov; prejeti in izdani računi; dobavnice; predračuni. 4. Pogodbena dokumentacija sklep o izbiri ponudnika; kopije pogodb/aneksov; primopredajni zapisniki; poročila o opravljenem delu. 5. Dokumentacija partnerjev/podizvajalcev prejeti računi; primopredajni zapisniki; kopija pogodbe. Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 67

69 6. Razno naročnikova ocena sodelovanja (obrazec); zapiski/opombe; dopisi s strani naročnika; zapisniki sestankov; reverzi/potrdila;»print screen«sistemske datoteke projekta, iz katerega je razvidna vsebina. 7. Zaključno vsebinsko poročilo projekta Vse komponente projektne mape niso nujno del Prosis-a, ampak so samostojni dokumenti, ki so priloženi mapi Poročanje Dolžnost poročanja določa, da je vodja projekta o svojem delu dolžan na zahtevo poročati tudi vodji vsebinsko sorodnih projektov. V okviru delovanja Prosis-a, je vodja projekta dolžan poročati najmanj enkrat na mesec, izvajalci projekta pa so dolžni tekoče beležiti porabljene delovne ure. Pogostnost poročanja lahko določi vodja vsebinsko sorodnih projektov in je odvisna od obsežnosti, pomena in trajanja projekta. V tem primeru poročilo obsega opis stanja projekta in doseženo realizacijo, podatke o porabi virov, predvidena in nepredvidena tveganja ter ravnanje za preprečitev vplivov tveganj na projekt in oceno verjetnosti doseganja rokov. Poseben del poročila je informacija o bistvenem odstopanju pri izvajanju projekta glede na plan projekta. Na podlagi poročila vodja vsebinsko sorodnih projektov odloča o morebitni razširitvi projektne naloge, o določitvi novih rokov izvedbe, o dodatnih virih ali o zaključku projekta. Za dokumentacijo projekta, t.j. za vzdrževanje, hranjenje in arhiviranje dokumentacije, ki nastaja ob izvajanju projekta, je zadolžen vodja projekta. Vodja projekta je dolžan hraniti vso delovno in končno gradivo v digitalni in/ali papirni obliki. V digitalni obliki se vodi dokumentacija na skupnem disku v mapi, ki ima oznako šifre projekta, papirno gradivo pa v fasciklih pri vodji projekta. O vseh pomembnih določilih projekta oziroma pogodbe, primopredaji izdelkov, zaključku faz in/ali projekta, o izstavljenih oziroma prejetih računih, ipd. mora vodja projekta hraniti papirno različico. Prosis omogoča naslednja dela s poročili: Izvajalci poročajo vodji projekta, kako poteka izvajanje aktivnosti, in sicer koliko ur so opravili na posamezen dan in kako napreduje delo. Izvajalci lahko poročajo dnevno, lahko skladno z zahtevami projekta ali skladno s»predpisom o projektnem delu v podjetju«. Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 68

70 Periodično poročanje izvajalcev, ki so hkrati nosilci aktivnosti, poteka periodično in skladno z zahtevami projekta na 14 dni. Vpišejo se začetni in končni datumi aktivnosti, ocenijo se deleži opravljenega dela, potrdijo ali vpišejo se opravljene ure izvajalcev in komentira se napredovanje dela. Poročanje ob zaključku aktivnosti (rezultat aktivnosti) napravijo izvajalci oziroma nosilci aktivnosti ob zaključkih aktivnosti. Namenjeno je pripravi in posredovanju (objavi) rezultatov zaključenih aktivnosti v pregled in potrditev vodji projekta ali podprojekta. Pregledovanje in ocenjevanje periodičnih poročil omogoča vodji projekta ali podprojekta sprotno spremljanje napredovanja projekta in korekcijo odstopanj od plana. Pregledovanje in ocenjevanje periodičnih poročil je aktualno zlasti ob zaključku period. Pregledovanje in potrjevanje rezultatov aktivnosti opravi vodja projekta ali podprojekta ob zaključku aktivnosti, in sicer zaradi pregleda in potrditve ustreznosti rezultata aktivnosti. Pripravo poročila o projektu pripravi projektni tajnik ali vodja projekta ob zaključkih period. Priprava poročila o projektu je namenjena pripravi podatkov za vodenje oziroma za periodični sestanek. Pregledovanje poročil o projektu se izvaja ob zaključkih period, ko poročila pregleda vodja projekta ali podprojekta. Poročila o projektu pripravi projektni tajnik za pregled in potrditev dinamike izvajanja projekta. Pregledovanje zapisnikov je namenjeno pregledu vseh sklepov, ki se dotikajo projekta. Zapisnik lahko pregledujejo vsi izvajalci ob zaključkih period. 3.4 Analiza trenutnega stanja Izkušnje kažejo, da je pri razvoju programske opreme bistvena težava pomanjkljiva komunikacija med projektnim vodjo in razvojno ekipo. Metodologija Scrum poveže ravno ta dva pola, projektnega vodjo, ki je v metodi Scrum znan pod imenom skrbnik metodologije Scrum, in razvojno ekipo Splošne smernice za prenovo informacijskega sistema V nalogi smo se lotili prenove informacijskega sistema preko prenove procesov z uporabo obstoječega informacijskega sistema. Rezultat je popolnoma prenovljen informacijski sistem, ki s prejšnjim nima veliko skupnega. V obstoječem informacijskem sistemu se je poskušalo čim bolj izkoristiti možnosti, ki jih ta že ponuja oziroma se je poskušalo čim bolj približati ideji modela CMMI. Ta pravi, da za izboljšanje učinkovitosti razvoja programske opreme ni dovolj uporaba novih tehnologij in orodij, temveč je treba poskrbeti predvsem za kakovosten, dobro definiran in nadziran proces razvoja programske opreme. Cilj prenove procesov in uvedbo novih metodologij je, da bi razvijalci programske opreme bolj tesno sodelovali pri planiranju projekta in ne bi bili zadolženi zgolj za razvoj programske kode. Močnejša vpletenost razvijalcev v projekt bi pripomogla k temu, da bi gledali na problematiko širše, posledično pa bi se pojavljalo manj napak Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 69

71 zaradi nesporazumov s projektnim vodjo in med njimi samimi. Večja angažiranost razvijalcev bi tako morala vplivati na kvalitetnejšo programsko kodo. Dani projekt bi bil izpeljan prej kot sicer, na projektu bi se naredila boljša realizacija in s tem večji profit, katerega del bi pripadal razvijalcem in bi deloval povratno na še večjo motiviranost v bodoče Priložnost za nadgradnjo Slika 15: Trenutni proces izvajanja projekta Izvajanje projekta je osrednji proces projektnega dela. Priložnost za nadgradnjo sistema Prosis je v procesu izvajanja projekta. Izvajalci uporabljajo Prosis samo za beleženje ur, ne uporabljajo pa ga za izmenjavo izkušenj, niti nimajo jasne slike ali se projekt podaljšuje ali stagnira. Trenutni proces izvajanje projekta (slika 15) poteka zelo enosmerno, saj okolje, ki bi spodbujalo prehajanje znanj med razvojno skupino, ni vzpostavljeno. Tedenski Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 70

72 sestanki so bolj sami sebi namen in koristijo le temu, da zaposleni na tedenski ravni vpisujejo evidenco ur opravljenega dela. Evidenca dela je tako izpolnjena bolj ali manj idealno za projektnega vodjo, da si vzdržuje plan dela. Na tedenskem sestanku razvijalci med seboj ne komunicirajo dovolj, saj predvsem projektni vodja predstavlja svoja videnja rezultatov enih razvijalcev drugim. Prehod znanj med razvijalci je tako prepuščen njihovi samoiniciativi. Možnosti, da bi se v ta proces razvoja PO opreme vključila tudi stranka, ni. S stranko se večji del časa sodeluje na začetku projekta, ko se vzpostavljajo sistemske zahteve in načrtovanje PO. Razvoj PO opreme je stranki črna škatla (ang. black box). Vhodni parameter je zadnja potrjena tehnična specifikacija, izhod pa razvita PO. Če bi si stranka med razvojem projekta zaželela nove funkcionalnosti, bi to zmotilo razvoj projekta. Potrebno bi bilo spremeniti tehnično specifikacijo in ko bi jo stranka potrdila, bi ponovno stekel razvoj, ki bi vsaj na tem področju, kjer je prišlo do sprememb, gotovo obstal. V procesu razvoja se lahko pojavijo tudi novi zahtevki, ki se med izvajanjem projekta izkažejo za potrebne. Teh zahtevkov si razvijalci ne dodeljujejo sami, pač pa jih po svoji presoji in planu dela razvijalcu dodeli projektni vodja, in sicer tistemu, za katerega misli, da bo to delo najbolje in najhitreje opravil. Pri tem prihaja med razvijalci do nezadovoljstva, saj nekateri delajo vedno ene in iste naloge in tako nimajo možnosti za osebni razvoj. Ker jim je naloga dodeljena in jim ni dana možnost izbire, naloge ne opravljajo z veliko pripadnostjo in odgovornostjo. Ker se odda le končno verzijo PO, ki je narejena z goro prepletenih funkcionalnosti, se velikokrat zgodi, da ne delujejo tako, kot si je stranka zamislila. Razvijalci sicer testirajo programsko kodo, vendar po sklopih, ki so tehničnega značaja, niso pa testi usmerjeni tako v funkcionalnost PO. Razvijalci, ki so tudi testerji, velikokrat ne razumejo vse problematike, ki naj bi jo njihova PO obsegala. Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 71

73 4 Predlogi rešitev Po vzoru avtorjev Mahniča in Žabkarja (Mahnič, 2007), ki sta vključila metode in prakse CMMI v Scrum, je treba vzpostaviti povezavo tako, da se CMMI prakse za merjenje in analizo lahko uvedejo brez škode na račun gibčnosti Scrum procesa razvoja programske opreme. Model CMMI zahteva, da imamo vzpostavljen model merjenja in shranjevanja podatkov, ki se pojavijo tokom razvoja programske opreme. Metodologija Scrum potrebuje dva dokumenta: dnevnik izdelka/projekta (ang. Product Backlog), ki vsebuje več zahtev (ang. Product Backlog Item PBI), za katere so podane ocene o preostanku dela (ang. PBI Work Remaining); dnevnik teka (ang. Sprint Backlog), kjer obstaja za vsak tek posebej po en dokument. 4.1 Uvedba principov agilnih metodologij Da bi metodologija Scrum v posamezni organizaciji uspela, mora biti organizacija pripravljena sprejeti osnovne principe agilnih metodologij. Manifest agilnosti bolj ceni (Beedle, 2001): ljudi na projektu kot sam proces in orodja razvoja; delujoči program kot popolno dokumentacijo; sodelovanje z naročnikom kot pogajanja na osnovi pogodb; prožnost pri spremembah kot sledenje začrtanemu planu. 4.2 Prenovljeni življenjski cikel projekta Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih temelji na osrednjem procesu projektnega dela, torej na izvajanju projekta. Proces izvajanja projekta se je nadgradil z metodologijami Scrum in CMMI, tako da se je vključilo v proces vse potrebne prvine teh dveh metodologij. Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 72

74 Slika 16: Prenovljeni življenjski cikel projekta Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 73

75 4.3 Prenova procesa izvajanja projekta Slika 17: Prenovljeni proces izvajanja projekta Predpogoj, da uvedemo metodologijo Scrum v proces izvajanja projekta, ki ga Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 74

76 vodimo z informacijskim sistemom, je, da vključimo v ta informacijski sistem Prosis vodenje dveh dodatnih dokumentov: dnevnik izdelka/projekta (ang. Product Backlog) in dnevnik teka (ang. Sprint Backlog). Metodologija CMMI zahteva, da so procesi na tretjem nivoju (nivo, katerega želimo doseči) v organizaciji dobro opisani in razumljeni, da so torej opisani v standardih, postopkih, orodjih in metodah. Standardi procesov organizacije, ki so podlaga za tretji zrelostni nivo in ki se določajo ter izboljšujejo periodično, pa potrebujejo mehanizem za posredovanje povratnih informacij. Tako je potrebna definicija kazalnikov in metrik, ki bodo služile predvsem meritvam uspešnosti in nadzoru izvajanja projekta. Za prikaz teh podatkov se je uvedlo kot rezultat merjenja: rezultati merjenja verzij (ang. Release Measurement Result); rezultati merjenja tekov (ang. Sprint Mesaurement Result); rezultati merjenja zahtev (ang. PBI Measurement Result); rezultati merjenja nalog (ang. Task Measurement Result); diagram obsega preostalega dela (ang. Burndown chart) Dnevnik izdelka/projekta Prva verzija dnevnika izdelka se v Prosis prenese iz MS Projecta (slika 18), kjer v projektni definiciji zastavimo terminski plan projekta. Vse nadaljnje spremembe dnevnika izdelka pa vodimo v Prosis-u. Slika 18: Terminski plan v MS Project je osnova za dnevnik izdelka v Prosis-u Lastnik izdelka in skrbnik metodologije Scrum morata v dnevnik izdelka vnesti vse Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 75

77 funkcionalne in nefunkcionalne zahteve, ki se jih mora v sklopu projekta izvesti. Za vsako zahtevo morata definirati število dni za dokončanje. Pri ustvarjanju dnevnika izdelka težita k temu, da so zahteve urejene v takem vrstnem redu, da jih je mogoče kar najhitreje vgraditi v končno verzijo. Rezultat take razvrstitve nalog je v tem, da se lahko produkt lokalno preizkuša na posameznih področjih. Stranka tako sodeluje pri razvoju že sproti in na koncu projekta ne dobi novega in nepoznanega izdeleka, ki ne bi ustrezal sliki, kakršno je pričakovala. V Prosis-u imamo tako vse predpogoje, da se naredi dnevnik izdelka, ki bo ustrezal metodologiji Scrum. Dodelava, ki jo je potrebno narediti, je v ekranu kartica aktivnosti (slika 19). V obstoječo tabelo na tem ekranu, ki ima sledeče kolone: Projekt / Faza / Aktivnost; Dokumentacija; Poročila; Rezultati; Potrjeno trajanje; Potrjen začetek; Potrjen konec in Odgovorna oseba; je potrebno dodati naslednje kolone: Ocena dela - Lahko zamenja že obstoječo kolono Potrjeno trajanje.; Korekcijski faktor - V primeru, da se izkaže, da je bila posamezna zahteva premalo ocenjena, se to lahko naknadno spremeni s korekcijskim faktorjem. Vrednost npr. 0,1 pomeni, da se je ocena dela pri izvajanju projekta spremenila, torej povečala za 10%, zato se vrednost v koloni Popravljena ocena ustrezno spremeni.; Popravljena ocena - Na to kolono lahko posredno vplivamo preko kolone korekcijski faktor.; Čas potreben za dokončanje (v posameznem teku) Ta kolona je razdrobljena na več kolon, in sicer za vsak tek posebej: - Tek 1; - Tek 2, ; - Tek N - V vsaki koloni teka je zapisano, kolikšna je ocena časa za dokončanje projekta, faz in aktivnosti. Aktivnosti, ki so že zaključene, dobijo vrednost 0. Vsak posamezni tek ne sme trajati dlje od 30 koledarskih dni. Ko se približamo temu času, obstoječi tek zaključimo in odpremo naslednjega, če vsaj kakšna aktivnost še ni zaključena. Dnevnik izdelka v Prosis-u zadošča zahtevam metodologije Scrum, omogoča prikaz aktivnosti po tekih in omogoča enostaven pregled deleža že dokončanih aktivnosti projekta. Kolone znotraj kolone Čas potreben za dokončanje nam prikazujejo posamezne teke in iz vsakega teka je povezava do dokumenta dnevnik teka. Pri vsakem teku je zapisano, koliko časa je še potrebno za dokončanje zadeve. Te vrednosti se avtomatično osvežujejo. Ko vsak posamezni uporabnik vpiše, koliko časa je porabil na določeni zahtevi, se tej zahtevi za toliko časa zmanjša čas za dokončanje. Če izvajalec/uporabnik spozna, da bo porabil več časa, kot je Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 76

78 planirano, se ustrezno spremeni korekcijski faktor. S tem se na novo preračuna čas za dokončanje zahteve. Za določanje korekcijskega faktorja in ocene potrebnega dela se lahko opiramo na zgodovino predhodnih ocenjevanj, ki sčasoma postanejo zelo dobre. Poleg tega je potrebno oceniti tudi čas, ko ljudje ne bodo na voljo za delo na projektih. Tu gre seveda za odsotnost zaradi bolezni, izobraževanja ali dopusta. Slika 19: Predlog dnevnika izdelka v Prosis-u Dnevnik teka Na želeni dnevnik teka pridemo preko dnevnika izdelka, če kliknemo na ikono poleg želenega teka (slika 20). Razvojna skupina, ki so ji bile dodeljene zahteve iz dnevnika izdelka, skupaj s skrbnikom metodologije Scrum in lastnikom izdelka začrta plan razvoja in ga zapiše v dokument dnevnik teka. Vsako posamezno aktivnost iz dnevnika izdelka člani razvojne skupine razdelijo na naloge. Bistvo sestanka začetka teka je, da se zberejo vsi pomembni akterji projekta. Razvojna skupina si poskuša z vprašanji čim bolj razjasni celotno sliko teka, in sicer do takih podrobnosti, da lahko zapiše v dnevnik teka naloge tako podrobno, da nobena po trajanju ne presega 16 ur. Vsaka aktivnost je razdeljena na več nalog in za vsako nalogo je podana ocena o preostanku dela temelječ na dnevni osnovi. Razvojna skupina si naloge na tem sestanku medsebojno razdeli. Člani razvojne ekipe si sami izbirajo naloge, ki jih bodo opravljali tekom teka. Po končanem sestanku, ta naj bi trajal okoli 8 ur, začnejo v naslednjem delovnem dnevu z izvajanjem nalog iz teka. Vsako nalogo lahko dodelimo enemu ali več članom razvojnih skupin. V primeru, da nek član razvojne skupine postane odgovorni lastnik naloge, se mu ta tudi prikaže na domači strani pri evidentiranju delovnih ur. Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 77

79 Slika 20: Povezava iz dnevnika izdelka do dnevnika teka je preko ikone poleg vsakega teka Dnevnik teka je v Prosis-u nov ekran, do katerega pridemo preko dnevnika izdelka. Prikazan je kot tabela, sestavljena iz sledečih kolon: Faza / Aktivnost / Naloga; Tvorec - Če se je naloga dodala naknadno, je v tej koloni zapisana oseba, ki jo je dodala v tek.; Odgovorni Gre za člana razvojne skupine, ki si je nalogo izbral in je za njo odgovoren.; Status - Status naloge je npr. lahko končan, odprt, v delu, prestavljeno v naslednji tek, izpuščeno.; Vrsta naloge (razvoj, testiranje, predelava, ovira,..); Dnevi izvajanja teka - Vsak dan v teku predstavlja svojo kolono. Ker naj bi tek ne trajal dlje od 30 koledarskih dni, naj tudi tu ne bi bilo več kot toliko kolon: - 1; - 2, ; - N Vsaki nalogi v dnevniku teka mora biti po CMMI dodeljena ustrezna vrsta naloge (npr. razvoj; testiranje; predelava zaradi napak, ki jih je posredovala stranka; predelava sprememb v zahtevah; itd.). Klasifikacija na vrsto opravljenega dela je potrebna, če hočemo spremljati količino različnih vrst nalog tekom vsakega teka. Preko ikone, ki predstavlja graf (slika 21), lahko hitro dostopamo do diagrama obsega preostalega dela za izbrani tek. Gre za preprosto poročilo, ki zelo nazorno Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 78

80 prikazuje trenutni status izbranega teka. Slika 21: Dnevnik teka izhajajoč iz dela dnevnika izdelka in ikona za povezavo do Diagrama obsega preostalega dela V dnevniku teka imamo prav tako kot v dnevniku izdelka/projekta možnost prikaza grafičnega pregleda statusov posameznih nalog v procentih izvršene izvedbe. Tako je izpolnjeno zahtevi modela CMMI, da je vpeljan trenutni status naloge. Iz grafičnega pregleda se vidi ali se je naloga začela, ali je v delu, zaključena, izpuščena, ali prestavljena v naslednji tek. Dobrodošlo je, da lahko vsako nalogo poljubno razbijamo na manjše naloge, če se izkaže, da je to potrebno. Model CMMI zahteva, da mora biti omogočeno sledenje oviram, zato da se zagotovi podatke, ki so potrebni za izračun povprečnega števila ovir na nalogo/tek/razvojno skupino in povprečni čas za odpravljanje ovir na ravni naloge/teka/razvojne skupine. Oviro dodamo v dnevnik teka kot nalogo, pri čemer ima takšna naloga svojo vrsto naloge, ki se imenuje ovira. Tako je zadoščeno modelu CMMI, saj lahko prikazujemo sledenje tem oviram skozi informacijski sistem. Skrbnik metodologije Scrum vzdržuje statuse za vsako nalogo preko dnevnega sestanka Scrum. Koliko časa je bilo porabljenega za vsako posamezno nalogo, pa vpiše vsak član razvojne skupine sam preko ekrana za vodenje ur, in sicer v evidenco dela (slika 23). Če se na dnevnem sestanku Scrum izkaže, da je za posamezno nalogo potrebno več časa, kot je bilo zastavljeno, ali da je naloga preobsežna in je potrebna razdelitev na več manjših nalog, skrbnik metodologije Scrum ustrezno spremeni dnevnik teka. Razvojna skupina vsak dan tekom teka opravi dnevni sestanek teka, kjer vnašajo v dnevnik teka podatke o tem, katere naloge so opravili (lahko tudi prej preko evidence dela), in se pogovorijo med seboj o težav in izkušnjah, ki so jih prejšnji dan imeli. Začrtajo si tudi načrt o tem, kaj mislijo do naslednjega dne opraviti. Po koncu teka se izvede sestanek za pregled rezultatov teka, kamor se povabi Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 79

81 lastnika izdelka, da se mu predstavi rezultate. Lastnik izdelka naj bi na tem sestanku spoznal nove funkcionalnosti izdelka. Na tem sestanku se vidi, ali so pričakovanja in želje lastnika usmerjeni v smer, ki si jo želi, ali se pojavljajo odstopanja. Če se, so za to prisotni razvojna ekipa in skrbnik metodologije Scrum, da se razjasni, zakaj je do njih prišlo. Ko se sestanek za pregled rezultatov teka zaključi, se izvede retrospektiven sestanek, ki ga vodi skrbnik metodologije Scrum. Na sestanku se poskuša ugotoviti, kaj je bilo v tem teku tako dobrega, da bi bilo vredno to vpeljati tudi v naslednji tek, in kako bi to lahko še izboljšali Rezultati merjenja Rezultati merjenja verzij (ang. Release Measurement Result), Rezultati merjenja tekov (ang. Sprint Mesaurement Result), Rezultati merjenja zahtev (ang. PBI Measurement Result) in Rezultati merjenja nalog (ang. Task Measurement Result) prikazujejo informacije, ki so razdeljene v tri sklope: Časovne informacije o performanci projekta Te informacije nam govorijo o tem, koliko je preostalega dela na dan d za posamezno nalogo in koliko časa je bilo porabljenega na dan d za posamezno nalogo.; Informacije o izboljšavi kakovosti Gre za informacije o tem, koliko napak je bilo najdenih tekom posameznega teka, koliko napak je bilo sporočenih od stranke po izdani verziji, kolikšna je velikost programske kode in koliko nalog je bilo zaključenih, odprtih ali dodanih.; Informacije o zadovoljstvu zaposlenih So informacije o tem, koliko delovnih ur se je porabilo za projekt, koliko nedelovnih dni so razvijalci tekom projekta porabili ter kakšni so rezultati ankete retrospektivnega sestanka. Diagram obsega preostalega dela (ang. Burndown chart) je graf, ki opisuje obseg preostalega dela v nekem teku (lahko imamo tudi diagram obsega preostalega dela za celotni projekt) za razvojno skupino v odvisnosti od časa. Na osnovi tega se lahko naredi ocena datuma zaključka teka in s tem posledično projekta. Graf je zanimiv tako za razvijalce, kot tudi za ljudi na vodstvenih pozicijah, saj lahko na dnevni bazi vidijo, kako daleč so z delom prišli oziroma koliko dela jih še čaka na nalogah trenutnega teka. Povezava do diagrama obsega preostalega teka je na dnevniku teka (slika 21). Za izračun diagrama preostalega dela (slika 22) morajo biti izpolnjeni naslednji pogoji oziroma potrebujemo naslednje podatke: status naloge mora biti v stanju zaključeno; za vsako nalogo moramo poznati tek, h kateremu naloga spada; oceno potrebnega dela na nalogah. Točka v grafu se glede na formulo (1) izračuna kot vsota ocen potrebnega dela na nedokončanih nalogah na izbrani datum. Sčasoma bo v teku vedno več nalog končanih, zato se bo s časom zmanjševala tudi vrednost y spremenljivke točk grafa. Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 80

82 y = E (nedokončanih zahtev na dan X) (1) Slika 22: Diagram obsega preostalega dela v izbranem teku Evidenca dela Ko imamo za tek določen seznam nalog za realizacijo v enem teku, se lahko tek začne oziroma se lahko začne delo na nalogah. Glede na to, da so te naloge lahko precej grob opis neke funkcionalnosti, je potrebno na nalogo dodati svojo entiteto, kjer se vodi korespondenca o posamezni nalogi ali vsaj dodati novo dodatno tekstovno polje, kjer so opisane podrobnosti posamezne naloge. Ko se člani razvojne skupine lotijo dela na nalogah, ki lahko trajajo dan ali dva, jim je omogočeno, da si direktno na definicijah nalog vpisujejo čas po dnevih, ki so ga porabili za delo na izbrani nalogi. Tako je na voljo celotna zgodovina opravljenega dela na neki nalogi. Prav tako se vidi, kdo vse je na nalogi delal. Predpostavlja se, da na neki nalogi lahko dela več ljudi, kar pa ni nujno, vendar se v praksi zgodijo tudi takšni primeri, ko na isti nalogi dela več ljudi. Iz teh podatkov in iz začetnih ocen potrebnega dela na nalogah se potem računajo in osvežujejo kazalniki (npr. Diagram obsega preostalega dela), ki v vsakem trenutku podajajo informacijo o stanju projekta oziroma teka. Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 81

83 Slika 23: Vnos ur opravljenega dela evidenca dela Urne postavke Slika 24: Vnos urnih postavk v MS Project-u Metoda CMMI predpisuje za merjenje in analizo pridobitev podatkov o urnih Janez Košir: Nadgradnja informacijskega sistema za vodenje projektov v IT podjetjih stran 82