Upload
others
View
9
Download
0
Embed Size (px)
Citation preview
Vilniaus universitetas
Matematikos ir informatikos fakultetas
Programų sistemų katedra
Valdas UNDZĖNAS
http://www.mif.vu.lt/~valund
PROGRAMŲ SISTEMŲ
PROJEKTŲ IR KOKYBĖS VALDYMAS
Mokymo medžiaga
VILNIUS – 2011
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
2
TURINYS
1. PROJEKTŲ VALDYMO ĮVADAS .......................................................................................................................................... 6
1.1. Projekto sąvokos apibrėžimas .................................................................................................................... 6
1.1.1. Kas yra IT projektas? ................................................................................................................................................... 6
1.1.2. IT projektų vadovų bendrosios pareigos ............................................................................................................ 9
1.1.3. IT projektų svarstymo kalba .................................................................................................................................. 10
1.2. Projektų valdymo apibrėžimas ................................................................................................................ 11
1.3. Bendrieji projekto vadovo įgūdžiai ........................................................................................................ 11
1.4. Projekto valdymo procesai ........................................................................................................................ 13
1.5. Projekto gyvavimo ciklas ............................................................................................................................ 15
1.5.1. IT projektų gyvavimo ciklas ................................................................................................................................... 16
1.5.2. IT projekto etapai ir kontroliniai taškai ............................................................................................................ 18
1.6. Organizacijos struktūros įtaka projektams ......................................................................................... 18
1.6.1. Funkcinio tipo organizacija .................................................................................................................................... 18
1.6.2. Matricos tipo organizacija ....................................................................................................................................... 19
1.6.3. Projektinio tipo organizacija .................................................................................................................................. 20
2. PROJEKTO INICIJAVIMAS ................................................................................................................................................ 21
2.1. Prašymas pradėti projektą ......................................................................................................................... 21
2.1.1. Reikalavimų metmenys ............................................................................................................................................ 22
2.1.2. Tiekėjų pasiūlymai ..................................................................................................................................................... 23
2.1.3. Reikalavimų metmenų dokumento rengimas ................................................................................................ 24
2.2. Projektų atranka ............................................................................................................................................ 25
2.2.1. Atrankos būdai ............................................................................................................................................................ 25
2.2.2. Atrankos kriterijai ...................................................................................................................................................... 25
2.3. Projekto akcininkai ....................................................................................................................................... 28
2.3.1. Projekto sponsorius................................................................................................................................................... 28
2.3.2. Kiti projekto akcininkai ............................................................................................................................................ 28
2.3.3. Kas yra jūsų IT projekto akcininkai? .................................................................................................................. 30
2.4. Projekto nuostatai ......................................................................................................................................... 33
2.4.1. Reikalavimų metmenys ............................................................................................................................................ 33
2.4.2. Informacija apie projekto grupę ........................................................................................................................... 33
2.4.3. Uždaviniai ir tikslai .................................................................................................................................................... 34
2.4.4. Projekto pagrindimas ............................................................................................................................................... 34
2.4.5. Formalus projekto patvirtinimas ......................................................................................................................... 35
3. PROJEKTO APIMTIES PLANAVIMAS ............................................................................................................................. 37
3.1. Projekto apimties plano struktūra .......................................................................................................... 37
3.1.1. Projekto apimties aprašas ...................................................................................................................................... 38
3.1.2. Projekto apimties valdymo planas ...................................................................................................................... 40
3.1.3. Projekto suskaidytų darbų lentelė ...................................................................................................................... 41
3.2. IT projekto apimtį įtakojantys veiksniai ............................................................................................... 42
3.2.1. IT įmonės dydis ........................................................................................................................................................... 42
3.2.2. Projekto siekiamų rezultatų apibrėžimo tikslumas ..................................................................................... 42
3.2.3. Darbo su užsakovu aplinkybės ............................................................................................................................. 43
3.2.4. Sėkmės kriterijų apibrėžimo sunkumas ........................................................................................................... 43
3.2.5. Pašaliniai ar neišsiaiškinti elementai ................................................................................................................. 43
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
3
3.2.6. Santykiai su tiekėjais ................................................................................................................................................. 43
3.2.7. Projekto grupės narių pasitraukimas ................................................................................................................ 44
3.2.8. Projekto darbų dalinimas keliems IT padaliniams ....................................................................................... 44
3.2.9. Testuojami elementai reikalauja gero apibrėžimo ....................................................................................... 44
4. DARBŲ GRAFIKO PLANAVIMAS ..................................................................................................................................... 45
4.1. Darbų eilės tvarka ......................................................................................................................................... 45
4.1.1. Darbų priklausomybių tipai ................................................................................................................................... 45
4.1.2. Darbų priklausomybės pobūdis ........................................................................................................................... 46
4.1.3. Darbų išdėstymo diagrama .................................................................................................................................... 47
4.2. Darbų trukmės vertinimas ......................................................................................................................... 47
4.2.1. Trukmės apibrėžimas ............................................................................................................................................... 47
4.2.2. Trukmės vertinimo būdai ....................................................................................................................................... 48
4.3. Darbų grafiko sudarymas ........................................................................................................................... 49
4.3.1. Kritinio kelio metodas .............................................................................................................................................. 49
4.3.2. Projekto etapai............................................................................................................................................................. 51
4.3.3. Darbų grafiko kontroliniai taškai ......................................................................................................................... 52
4.4. Projekto terminai ir tikrovė ...................................................................................................................... 52
5. PROJEKTO KAINOS PLANAVIMAS ................................................................................................................................. 54
5.1. Išteklių planavimas ....................................................................................................................................... 54
5.1.1. Išteklių tipai .................................................................................................................................................................. 54
5.1.2. Išteklių poreikio nustatymas ................................................................................................................................. 55
5.2. Išteklių kainos vertinimas .......................................................................................................................... 56
5.2.1. Kainos vertinimo būdai ............................................................................................................................................ 56
5.2.2. Vertinimo rekomendacijos ..................................................................................................................................... 59
5.3. Projekto biudžeto sudarymas ................................................................................................................... 60
5.3.1. Projekto biudžetas ..................................................................................................................................................... 60
5.3.2. Biudžeto lėšos projekto etapams ......................................................................................................................... 61
5.3.3. Biudžeto naudojimo kontroliniai taškai ............................................................................................................ 62
5.3.4. Biudžeto sudarymo įrankis - projektų valdymo programinė įranga .................................................... 62
6. PROJEKTO GRUPĖS PLANAVIMAS................................................................................................................................. 63
6.1. Projekto grupės organizacinės struktūros planavimas .................................................................. 63
6.1.1. Projekto sąsajos .......................................................................................................................................................... 63
6.1.2. Projekto grupės narių pareigos ir atsakomybės ............................................................................................ 64
6.1.3. Projekto grupės organizacinės struktūros schema ...................................................................................... 64
6.1.4. Projekto grupės valdymo planas .......................................................................................................................... 64
6.2. Projekto grupės narių atranka ................................................................................................................. 65
6.2.1. Pretendentų į projekto grupę apklausa ............................................................................................................. 65
6.2.2. Tarimasis su organizacijos funkcinių padalinių vadovais ......................................................................... 65
6.2.3. Kiti projekto grupės sudarymo scenarijai ........................................................................................................ 66
7. KOKYBĖS PLANAVIMAS ................................................................................................................................................... 67
7.1. Kokybės užtikrinimo priemonės ir būdai ............................................................................................ 67
7.1.1. Kokybės-naudos analizė .......................................................................................................................................... 68
7.1.2. Lyginamoji analizė ..................................................................................................................................................... 68
7.1.3. Struktūrinė (blokinė) projekto schema ir diagramos ................................................................................. 68
7.1.4. Kokybės kaina .............................................................................................................................................................. 68
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
4
7.2. Kokybės valdymo planas ............................................................................................................................ 69
8. RIZIKOS PLANAVIMAS ...................................................................................................................................................... 71
8.1. Rizikos veiksnių įvardinimas .................................................................................................................... 71
8.2. Rizikos analizė ................................................................................................................................................ 72
8.3. Reakcija į riziką .............................................................................................................................................. 73
8.3.1. Prevencinės priemonės ............................................................................................................................................ 73
8.3.2. Veiksmai nenumatytais atvejais ........................................................................................................................... 74
9. KOMUNIKACIJŲ PLANAVIMAS ....................................................................................................................................... 75
9.1. Komunikacijų strategija .............................................................................................................................. 75
9.2. Komunikacija su projekto grupės nariais ............................................................................................ 76
9.3. Komunikacija su akcininkais ..................................................................................................................... 77
10. PIRKIMŲ PLANAVIMAS .................................................................................................................................................. 79
10.1. Kurti patiems ar pirkti? ............................................................................................................................ 79
10.2. Sandorių tipai ............................................................................................................................................... 80
10.2.1. Fiksuotos kainos sandoriai .................................................................................................................................. 80
10.2.2. Išlaidas padengiantieji sandoriai....................................................................................................................... 80
10.2.3. Laiko ir medžiagų apmokėjimo sandoriai ..................................................................................................... 80
10.3. Darbo užduotis tiekėjams ........................................................................................................................ 81
10.4. Prašymas tiekėjams teikti pasiūlymus ............................................................................................... 81
10.5. Tiekėjų atrankos kriterijai ....................................................................................................................... 82
11. PROJEKTO BENDROJO PLANO RENGIMAS ............................................................................................................... 83
11.1. Kas yra projekto planas? .......................................................................................................................... 83
11.2. Projekto plano sudėtis .............................................................................................................................. 83
11.2.1. Bendroji dalis ............................................................................................................................................................. 84
11.2.2. Suplanuoti dalykai ................................................................................................................................................... 84
11.2.3. Šablonai ir kontroliniai sąrašai .......................................................................................................................... 85
11.2.4. Šaltinių nuorodos ..................................................................................................................................................... 85
11.2.5. Priedai .......................................................................................................................................................................... 85
11.3. Plano sudarymas ......................................................................................................................................... 86
11.3.1. Plano rašymo organizavimas ir rašymas ....................................................................................................... 86
11.3.2. Plano keitimas ........................................................................................................................................................... 86
11.3.3. Plano peržiūra ........................................................................................................................................................... 87
11.3.4. Projekto planavimo etapo užbaigimas ............................................................................................................ 87
12. PROJEKTO VYKDYMAS ................................................................................................................................................... 89
12.1. Projekto grupės sudarymas .................................................................................................................... 89
12.1.1. Darnios projekto grupės sudarymas ir valdymas ...................................................................................... 89
12.1.2. Mokymai ...................................................................................................................................................................... 91
12.1.3. Skatinimas ir pripažinimas .................................................................................................................................. 91
12.2. Santykiai su kitais akcininkais ............................................................................................................... 92
12.3. Darbų vykdymas pagal planą ................................................................................................................. 94
12.3.1. Duomenų apie projekto eigą rinkimas ............................................................................................................ 94
12.3.2. Projekto eiga pagal kontrolinius taškus ......................................................................................................... 95
12.4. Informacijos apie projekto eigą platinimas ...................................................................................... 96
12.4.1. Projekto grupės susirinkimai .............................................................................................................................. 96
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
5
12.4.2. Ataskaitos apie projekto eigą .............................................................................................................................. 97
12.4.3. Projekto apžvalgos .................................................................................................................................................. 97
12.5. Sandorių su tiekėjais priežiūra .............................................................................................................. 98
12.5.1. Tiekėjų atliekamų darbų ataskaitos ................................................................................................................. 98
12.5.2. Nesutarimų su tiekėjais aiškinimasis .............................................................................................................. 99
12.5.3. Tiekimų vėlavimai ................................................................................................................................................... 99
12.5.4. Atsiskaitymai su tiekėjais ..................................................................................................................................... 99
12.5.5. Reikalų su tiekėjais tvarkymas ........................................................................................................................ 100
13. PROJEKTO KONTROLĖ ................................................................................................................................................. 101
13.1. Integruotoji keitimų kontrolė ............................................................................................................. 101
13.1.1. Projekto apimties keitimo kontrolė .............................................................................................................. 101
13.1.2. Darbų grafiko kontrolė ....................................................................................................................................... 102
13.1.3. Išlaidų kontrolė ...................................................................................................................................................... 103
13.1.4. Kitų projekto plano elementų keitimo kontrolė ...................................................................................... 103
13.2. Kokybės kontrolė ..................................................................................................................................... 104
13.2.1. Tikrinimas (testavimas) .................................................................................................................................... 104
13.2.2. Kiti kokybės kontrolės būdai ir priemonės ................................................................................................ 105
13.2.3. Veiksmai kokybės neatitikimo atvejais ....................................................................................................... 107
13.2.4. Dokumentų kokybė .............................................................................................................................................. 107
13.3. IT projektų kokybės kontrolė .............................................................................................................. 108
13.3.1. Standartai ................................................................................................................................................................. 108
13.3.2. Standartų organizacijos ...................................................................................................................................... 109
13.3.3. Projektų valdymo kokybės gerinimas .......................................................................................................... 109
13.4. Rizikos valdymo kontrolė ..................................................................................................................... 110
13.4.1. Reakcijos į rizikos veiksnius rezultatų valdymas .................................................................................... 110
13.4.2. Naujų rizikos veiksnių įvardijimas ................................................................................................................ 111
13.4.3. Problemų sprendimo valdymas ...................................................................................................................... 111
13.4.4. Projektas pavojuje ................................................................................................................................................ 112
13.5. Projekto eigos kontrolė ......................................................................................................................... 112
13.5.1. Darbų ataskaitos ................................................................................................................................................... 113
13.5.2. Akcininkų valdymas ............................................................................................................................................. 115
14. PROJEKTO UŽBAIGIMAS .............................................................................................................................................. 118
14.1. Projektų nutraukimo priežastys ........................................................................................................ 118
14.2. Sandorių užbaigimas .............................................................................................................................. 119
14.3. Administraciniai projekto baigiamieji darbai ............................................................................... 119
14.3.1. Projektų archyvo tvarkymas ............................................................................................................................ 119
14.3.2. Formalus projekto rezultatų priėmimas ..................................................................................................... 120
14.3.3. Visapusiška projekto peržiūra (gautos pamokos) .................................................................................. 120
14.3.4. Projekto rezultatų perdavimas naudotojams ........................................................................................... 121
14.3.5. Projekto grupės narių atleidimas ................................................................................................................... 121
15. LANKSTIEJI PROJEKTŲ VYKDYMO METODAI ....................................................................................................... 122
15.1. Grumtynės (Scrum) ................................................................................................................................ 123
15.2. Aukštasis programavimas (XP) .......................................................................................................... 123
SANTRUMPOS ........................................................................................................................................................................ 125
ŠALTINIAI ................................................................................................................................................................................ 127
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
6
1. PROJEKTŲ VALDYMO ĮVADAS
1.1. Projekto sąvokos apibrėžimas
Naujiems projektų vadovams ir grupių nariams dažnai kyla tokie klausimai: kas priima
sprendimus projektams pradėti, kaip tampama projekto dalyviu, kuo darbas projekte skiriasi nuo
einamosios darbinės veiklos. Dažnai organizacijose ginčijamasi, ar turimas kuklias lėšas reikėtų
skirti sumanytam projektui ar einamajai darbinei veiklai. Tiek projektas, tiek einamoji darbinė
veikla vykdomi pagal kažkokį planą arba yra kažkokių veiksmų seka. Taigi, kuo projektai yra
ypatingi?
Projektų savybės:
- projektai pradedami tuomet, kai norima įgyvendinti (patenkinti) specifinius verslo
tikslus (poreikius). Tai susiję su naujų produktų, paslaugų ar rezultatų kūrimu (gavimu), kurie
galės būti parduodami klientams arba naudojami savo organizacijoje;
- projektai visada būna ribotos trukmės, turi apibrėžtus pradžios ir pabaigos terminus.
Projektų trukmė gali būti nuo keleto savaičių iki keleto metų. Tai priklauso nuo kuriamo
produkto sudėtingumo. Tačiau projektai nėra einamųjų darbinių veiklų rinkiniai;
- projektai turi būti pradedami tik turint aiškius tikslus ir akcininkus (suinteresuotus
asmenis). Apibrėžti tikslai turi būti patvirtinti akcininkų. Projektas baigiamas, kai įgyvendinami
šie tikslai. Žinoma, projektas gali būti ir nutrauktas, jei paaiškėja, kad pasiekti apibrėžtų tikslų
neįmanoma.
Kalbant apie projektų valdymą kartais sutinkama programos sąvoka. Programa yra grupė
susijusių projektų, kurie yra vykdomi reikiamai derinant juos. Programos sąvoka dažniausiai
naudojama gynybos ar dideliuose vyriausybiniuose užsakymuose.
Panagrinėkime informacinių technologijų (IT) srities veiklas, kad pajustume, kada jos
traktuotinos kaip projektai ir kada kaip einamoji darbinė veikla, kokie yra IT projektų ypatumai.
1.1.1. Kas yra IT projektas?
Kokia tvarka turi būti vykdomi projektai ir kaip griežtai reikėtų laikytis nustatytos
tvarkos, priklauso nuo projekto sudėtingumo. Įvairaus dydžio ir sudėtingumo projektų vykdymo
tvarka yra apibrėžta projektų valdymo žinyne [PMBOK].
Panagrinėkime keletą įvairaus pobūdžio IT projektų.
Programų sistemos (PS) kūrimo projektas. PS kūrimo projektuose reikia ne tik griežtai
laikytis projektų valdymo metodikų, bet ir gerai suprasti PS kūrimo metodologiją. Šios mokymo
medžiagos akcentas yra PS kūrimo projektai. Todėl plačiau apie specifines PS projektų valdymo
veiklas rašoma vėliau.
Infrastruktūros kūrimo/gerinimo projektas. Infrastruktūra – tai ryšio kabeliai,
kompiuterių tinklas ir jo įranga. Kartais infrastruktūra apima ir telefonų tinklus.
Pvz., keliantis į naują pastatą, kuriame dar niekas neįrengta, IT infrastruktūros
suprojektavimas ir įrengimas traktuotinas kaip projektas. Sename pastate naujų ar papildomų
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
7
ryšio kabelių nutiesimas, kompiuterių tinklo rekonstrukcija ar įrangos atnaujinimas taip pat yra
projektas.
Patalpa, į kurią ateina dauguma ryšio linijų, paprastai vadinama duomenų centru
(datacenter), o jame esanti įranga - pagrindine duomenų įranga (MDF–Main Data Facility). Ryšio
kabeliai iš duomenų centro eina į kitose pastato vietose ar net kituose pastatuose esančias
sienines ar kitaip įrengtas spintas. Tokiose spintose montuojama kompiuterių tinklo skirstančioji
ir komutuojančioji įranga (switchgear, routers), kuri vadinama tarpine duomenų įranga (IDF–
Intermediate Data Facilities). Pastate gali būti kelios IDF, tačiau MDF būna tik viena.
Duomenų centro kūrimo/tobulinimo projektas. Duomenų centras yra ta vieta, kur
talpinami serveriai, didieji kompiuteriai (mainframes), atsarginėms duomenų kopijoms saugoti
didelės talpos atminties įrenginiai, telefoninė įranga (pvz., PBX–Post Branch Exchanges). Į kitas
pastato patalpas išeinančių FR–Frame Relay, ATM–Asynchronous Transfer Mode, ISDN–
Integrated Services Digital Network ar kitokio standarto kompiuterių tinklo ryšio linijų pradžia
yra duomenų centro (MDF) riba. Duomenų centras yra atskira zona, į kurią privalu žiūrėti kaip į
ypatingą vietą, kurioje atliekami svarbiausi jūsų organizacijos skaičiavimai ar duomenų
apdorojimas.
Duomenų centrai pasižymi tokiais elementais, kaip pakeltos grindys, po kuriomis
išvedžiojami kondicionuoto oro kanalai serveriams, elektros energijos paskirstymo skydas, oro
kondicionieriai, patekimo į duomenų centrą apsaugos sistema, nepertraukiamo maitinimo
šaltiniai (UPS–Uninterrupted Power Supply), dažnai ir elektros energijos generatoriai, jei
ilgesniam laikui dingtų elektra bendrajame tinkle.
Duomenų centro kūrimo projektu gali būti tokio centro rengimas naujame pastate, jau
veikiančio centro elektros energijos tiekimo ir oro kondicionavimo pasenusios įrangos keitimas,
papildomų lentynų ar stovų rengimas naujiems serveriams, kt. Pastebėkime, kad duomenų
centro kūrimo / tobulinimo projektų nereikėtų būtinai sieti tik su serveriais. Tai daugiau susiję su
serverių laikymo vietos įrengimu.
Serverio / sistemos rengimo projektas. Be įprastų failų serverių, skirtų naudotojų failams
saugoti, rengiami ir kitokie, kurie būtini tam tikroms sistemoms funkcionuoti. Pvz., jums gali
prireikti įrengti didelę duomenų bazę arba įdiegti nupirktą gatavą programinę įrangą (COTS–
Commercial Of The Shelf) jūsų organizacijoje. Taip pat gali tekti diegti jūsų organizacijos
informatikų sukurtą sistemą, turinčią sąsajų su duomenų bazėmis arba kitomis jau
egzistuojančiomis sistemomis. Toks keleto skirtingų sistemų diegimas vadinamas sistemų
integracija ir reikalauja ypač gerų projekto vadovo žinių, kad visos dalys drauge veiktų gerai.
Apskritai, daugumai sistemų būtini serveriai, juose veikianti tinklo operacinė sistema
(NOS–Network Operating System), įvairios taikomosios programos, jungtys su tinklu, testavimo
priemonės. Sistema gali apimti kelias teritorijas, kas yra žymiai sudėtingiau ir kelia didesnius
reikalavimus jos kūrimo projektui.
Saugyklų rengimo projektas. Duomenų saugyklų (SAN–Storage Area Network) įrengimas
yra unikalus IT projektas. Tai specializuota įranga, ir ji gali apimti optinius kabelius, optinių
kanalų jungiklius, didelės talpos atminties įrenginių masyvus, kompiuterių tinklo
komutuojančiąją įrangą, kt. Vidutinio dydžio saugyklos įrengimas yra sudėtingas projektas,
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
8
kuriam gali prireikti projekto grupės keleto mėnesių darbo. Didelės saugyklos įrengimui gali tekti
ieškoti pagalbos, sudarant sandorį su atitinkama firma.
Įmonės išteklių planavimo programinės įrangos kūrimo projektas. Dideliais ir sudėtingais
IT projektais yra laikomi įmonės išteklių planavimo programinės įrangos (ERP – Enterprise
Resource Planning), kaip, pvz., SAP, Siebel, PeopleSoft, Oracle, kt., diegimo projektai. ERP
programinė įranga yra suprojektuota daugiausia įmonės darbuotojų atlyginimams, gamybos
procesams apskaityti. Ji yra sudėtinga ir mažai kam suprantama, todėl jai įdiegti dažniausia
samdomi patyrę specialistai.
ERP įrangai funkcionuoti paprastai reikia galingų serverių, sujungtų su didelėmis įmonės
duomenų bazėmis, kaip, pvz., Oracle, Microsoft SQL Server, kt. Kadangi ERP įranga gali atlikti
daug įvairių funkcijų, įskaitant portalų realizavimą, vienas žmogus negali žinoti visų jos diegimo
niuansų. Įvairioms verslo apskaitos funkcijoms realizuoti tenka kviestis keletą skirtingas veiklos
sritis išmanančių ekspertų (žinovų), kas veda prie sudėtingų projekto valdymo metodų (matrix
management) naudojimo.
Automatizuotos sistemos projektas. Kai kuriose sistemose rankinius procesus galima
automatizuoti. Imkime kad ir automobilių surinkimą. Pradžioje jie buvo surenkami rankiniu
būdu, o šiandien daug operacijų atlieka robotai.
Taip yra ir kitose pramonės srityse. Pvz., gėrimų gamybos srityje sistema automatizuotai
matuoja produkto tūrį ir pilsto į tarą, taip išlaisvindama daug darbuotojų. IT projektai, kuriais
numatoma automatizuoti rankines operacijas, reikalauja gero atitinkamos veiklos srities funkcijų
išmanymo. Tam gali reikėti nemažai mokymų.
IT projektų ypatumai
IT projekto sėkmė priklauso nuo grupės narių patirties, komunikavimo, atliekamų
procesų. Visuose IT projektuose tenka komplektuoti reikiamus aparatinės ir programinės įrangos
komponentus, išnaudoti žmonių patirtį kiekvienoje srityje ir rūpintis, kad visa įranga veiktų.
Pamąstykime, pvz., apie statybininko, vadovaujančio namo statymo projektui, atsakomybę. Jis
nebūtinai turi žinoti, kaip veikia šimtai įvairių santechnikos įrenginių (kriauklės, vonios, unitazai,
kt.), bet jis turi suprasti, kaip jie jungiami prie pagrindinių vandentiekio/nuotekų vamzdžių. Taip
pat yra ir su IT projektais. Jums nebūtinos nuodugnios žinios apie kiekvieną sistemos
komponentą, bet jūs turite suprasti, kaip jie sąveikauja tarpusavyje.
IT projektų esmei suprasti būtina žinoti procesus, vykstančius magistralėje tarp taško A ir
taško B. Pvz., kas darosi, kai interneto naudotojas atlieka veiksmus savo kompiuteryje,
norėdamas prisijungti prie kažkokios duomenų bazės? Duomenys keliauja per serverius, per
duomenų saugumą užtikrinančias priemones, kabelius, maršrutą nustatančius (routing) ir
junginėjančius (switching) komponentus. Visus šiuos elementus, ar jie susiję su jūsų projektu, ar
ne, būtina žinoti.
Taip pat labai svarbu, kad IT projektą vykdančios grupės nariai tarpusavyje palaikytų
glaudų ryšį. Neturėtų būti galimybės patirties neturinčiam programuotojui nukreipti sistemos
kūrimą neteisinga linkme. Asmens dalykinių savybių patikrinimas (pilot test) padeda išvengti bet
kokių programavimo netikėtumų.
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
9
1.1.2. IT projektų vadovų bendrosios pareigos
IT projektų vadovų darbas nėra lengvas. Jie turi turėti įvairių sričių žinias, kad gerai
suprastų projektų esmę, sugebėtų atlikti darbus laiku ir neviršydami biudžeto. Žemiau
pateikiama keletas įvairių pareigų, kurias tenka atlikti projektų vadovams.
Projektų vadovas. Kaip projekto vadovas jūs visų pirma esate atsakingas už projekto
grupės sudarymą, užduočių grupės nariams suformulavimą ir paskirstymą, vadovavimą taip, kad
projektas būtų įvykdytas laiku, kokybiškai ir nebūtų viršytas biudžetas.
Verslo analitikas. Nors projekto užsakovas paprastai paskiria savo ekspertus, kurie
padeda sukonkretinti projekto reikalavimus, jūs pats turite turėti šiokį tokį supratimą apie
užsakovo verslą, t. y. būti verslo analitikas. Taip pat jūs turite turėti žinių apie įvairius savo
organizacijos, kurioje dirbate, departamentus ir jų atliekamas funkcijas, galimybes (apribojimus
ir kliūtis) atlikti kažkuriuos darbus, jame dirbančių žmonių tipą, kaip jie yra valdomi, kokią įtaką
jie turi bendram organizacijos tikslui. Iš esmės jūs turite būti savotiškas visų savo organizacijos
departamentų (arba bent pagrindinių) veiklos ekspertas, pajėgiantis apibūdinti juos. To gali
prireikti formuojant projekto vykdytojų grupę.
Sistemų analitikas. Didesniuose projektuose sistemų analitiko funkcijas gali vykdyti ir
kitas asmuo. Nežiūrint to, jūs taip pat turite turėti gerą supratimą apie sistemų analizę ir kūrimo
būdus. Mažesniuose projektuose sistemų analitikas kartu būna ir verslo analitikas.
Derybininkas. Jums gali tekti derėtis ne tik su projekto užsakovu, bet ir su akcininkais,
pardavėjais ir kitokių įmonių vadovais, kurie gali būti projektui reikalingų elementų tiekėjai.
Biudžeto analitikas. Biudžeto analitiko vaidmuo jums tenka todėl, nes reikia sekti projekto
biudžeto eigą. Paprastai jūs gaunate tam tikro dydžio pinigų kapšą projekto tikslams pasiekti ir
būna sunku pasiaiškinti, jei viršijamas biudžetas.
Teisinių klausimų analitikas. IT projektų vadovas taip pat turi žinoti su projektu susijusius
teisės, etikos ir priežiūros klausimus. Pvz., JAV visa tai tapo ypač svarbu, kai buvo priimtas
Sarbanes-Oxley aktas [SOX], įpareigojantis organizacijas laikytis garbingo verslo taisyklių.
Technologas. IT projekto vadovui nebūtinos gilios technologinės žinios, tačiau jis turi
turėti bent minimumą žinių apie IT naudojimą. Jam nebūtina gerai išmanyti kompiuterių tinklus,
pvz., žinoti, kuo skiriasi tiltas (bridge, switch) nuo maršrutizatoriaus (router). Tinklo specialisto
nupieštų schemų jam turėtų visiškai pakakti. Svarbu, kad pokalbių metu jis suprastų minimus
projekto IT elementus. Projekto vadovui neįmanoma būti visų IT dalykų ekspertu. Tačiau, jeigu
bendraujant su kitais sutinkami nežinomi terminai ar sąvokos, būtina išsiaiškinti jų esmę.
Strategas. Ši funkcija glaudžiai susijusi su technologo funkcija. Jūs galite būti susipažinęs
su paskutinėmis IT tendencijomis. Pvz., jūs galite nerekomenduoti senesnio tipo kliento / serverio
sistemos, kai yra paplitusios naršyklėmis pagrįstos technologijos. Tačiau jūsų nauja sistema gali
turėti daugiau naudos iš įprastas komunikavimo priemones turinčių klientų. Taip elgdamiesi,
žinoma, jūs nenorite, kad projektas patektų į bėdą, panaudojus nepagrįstas naujas technologijas.
Ryšių palaikymo atstovas. Preciziškas ir rūpestingas ryšių palaikymas su suinteresuotais
asmenimis yra svarbiausias projekto vadovo darbas. Jūs turite vienų asmenų žinias perduoti
kitiems, rūpintis, kad žmonės laiku būtų informuoti apie projekto stovį. Jums turi rūpėti, kad
svarbūs asmenys, kurie gali tapti sukurto produkto pirkėjais, būtų informuoti apie projektą. Jums
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
10
teks turėti reikalų su pardavėjais ir subrangovais. Jūs turėsite vesti projekto grupės susirinkimus.
Todėl jūs turite būti geras oratorius, turėti gerus komunikavimo raštu įgūdžius, o taip pat mokėti
išklausyti kitus.
Laiko darbams atlikti vertintojas. IT projekto vadovas turi stebėti visas projekto veiklas ir
pamatęs, kad kažką padaryti vėluojama, išsiaiškinti priežastis.
Grupės sudarytojas. IT projekto vadovas turi mokėti suvaldyti labai įvairių sugebėjimų
žmones projekto tikslams pasiekti. Projekto grupėje bus programuotojai, tinklo specialistai,
serverių administratoriai, saugumo analitikai, internetinių (web) puslapių kūrėjai ir daugelio
kitokių technologijų specialistų. Kad jie tarpusavyje palaikytų tinkamus ryšius ir veiktų kaip
darni grupė, yra nelengvas uždavinys.
Kaip matome, IT projektų vadovų pareigų ratas yra labai platus. Dalis iš jų yra labai
svarbios, bet nepopuliarios. IT projektų vadovai turi žinoti „20-60-20“ taisyklę. Dvidešimčiai
procentų žmonių jūs neįtiksite ką bedarytumėte. Šešiasdešimt procentų žmonių bus neutralūs ir
neprieštaraus jums. Likę 20 procentų bus geros nuomonės apie jus ir pasiryžę drauge nuversti
kalnus. IT projekto vadovui tenka išgirsti labai įvairių nuomonių, barnių, argumentų,
persekiojimų, kt. Kai kuriais jūsų sprendimais ar veiksmais mažiausiai viena ar kita darbuotojų
grupė bus nepatenkinta. Jūs negalite būti populiarus besirungiančiame pasaulyje. Jūs turite veikti
pagal aplinkybes, kad pasiektumėte įmanomai geresnių projekto rezultatų iki numatyto termino
ir neviršydami biudžeto.
Projekto vadovui, dirbančiam su programinės įrangos kūrėjais, labai pravartu žinoti
programinės įrangos kūrimo ciklą (SDLC – Software Development Life Cycle). Taip pat būtina
išmanyti sistemų analizę ir projektavimą, duomenų vaizdavimo diagramas (DFD – Data Flow
Diagrams), objektų sąryšio diagramas (ERD – Entity Relationship Diagrams) ir kitus dalykus,
kurie padeda greičiau įdiegti sukurtas sistemas ir geriau patenkinti naudotojų poreikius.
Verslo poreikių analizės ir reikalavimų rengimo etape reikėtų vengti technologinių dalykų.
Pagrindinis dėmesys turi būti skiriamas verslo procesams.
Nagrinėdami verslo procesus jūs galite įžvelgti šių procesų keitimo galimybes, kas padėtų
palengvinti patį verslą arba leistų jame diegti paprastesnes technologijas. Tai vadinama verslo
procesų reinžinerija (BPR – Business Process Re-engineering), ko sistemų analitikas pirmiausia
turėtų imtis prieš siūlydamas technologinius sprendimus.
1.1.3. IT projektų svarstymo kalba
IT projektų vadovams tenka turėti reikalų su labai įvairiais žmonėmis. Kalbantis, pvz., su organizacijų vadovais tenka taikytis prie jų IT žinių lygio, o kalbantis su programinės įrangos kūrėjais jau tenka pasitikėti savo technologinėmis žiniomis. Pokalbiuose su vadovybe jūs tikriausiai nenaudojate specifinės techninės kalbos arba IT santrumpų. Kalbantis su programinės įrangos kūrėjais, jiems mažiau įdomūs gali būti projekto biudžeto tvarkymo klausimai. Taigi,
visada reikia turėti galvoje, su kuo turite reikalą. IT projekto vadovas turi būti lankstus ir mokėti tiksliai perteikti savo mintis. Su pašnekovais stenkimės kalbėti kiek įmanoma jiems aiškesne kalba. Venkime santrumpų, kol nesame įsitikinę, kad pašnekovai jas gerai supranta.
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
11
1.2. Projektų valdymo apibrėžimas
Šioje mokymo medžiagoje naudojami projektų valdymo ir su juo susijusių sąvokų
apibrėžimai yra paimti iš pasaulyje plačiai žinomo Projektų valdymo instituto (PMI – Project
Management Institute) parengtų standartų. Vadovaujant PMI yra parengtas Projektų valdymo
žinynas [PMBOK].
Projektų valdymo žinyne [PMBOK] projektų valdymo sąvoka apibrėžiama taip: tai žinių,
įgūdžių, instrumentų ir metodų naudojimas projekto reikalavimams įgyvendinti.
Projekto vadovas yra asmuo, kuris, naudodamas įvairius instrumentus ir metodus, stebi ir
koordinuoja visus projektui įvykdyti reikalingus darbus. Projekto valdymas apima išteklių
komplektavimą, biudžeto sudarymą, rizikos vertinimą, projekto reikalavimų tvarkymą,
komunikavimą su akcininkais, darbų grafiko laikymąsi ir produkto kokybės užtikrinimą. Visa tai
turi būti atliekama laiku. Projektų valdymo žinyne [PMBOK] žinios minėtoms veikloms valdyti
yra paskirstytos į devynias sritis. Vėliau matysime, kaip šios devynios žinių sritys yra susijusios
su penkiomis projekto valdymo procesų grupėmis.
Projekto valdymo procesų grupės turi būti pagrįstos atitinkamų sričių žiniomis.
Išvardinkime projektų valdymo žinių sritis:
1) apimties valdymas; 2) laiko valdymas;
3) kainos valdymas; 4) kokybės valdymas; 5) žmoniškųjų išteklių valdymas; 6) komunikacijų valdymas; 7) rizikos valdymas; 8) pirkimų valdymas; 9) bendrojo plano rengimo (integracijos) valdymas.
Vėliau šiuos dalykus nagrinėsime smulkiau. Priklausomai nuo IT projekto pobūdžio,
valdymo žinių sritys gali būti nevienodai svarbios. Pvz., jeigu jūsų projekte nebus sudaromi
sandoriai su išoriniais tiekėjais, tai pirkimų valdymo srities žinios nebus naudojamos.
1.3. Bendrieji projekto vadovo įgūdžiai
Projekto vadovas turi turėti įvairių gebėjimų. Svarbiausi iš jų yra: - mokėjimas vadovauti; - gebėjimas komunikuoti balsu; - gebėjimas komunikuoti raštu; - mokėjimas išklausyti kitų; - organizaciniai gebėjimai; - gebėjimas skirti laiką; - planavimo gebėjimai; - gebėjimas spręsti problemas; - gebėjimas susitarti (prieiti konsensuso); - gebėjimas spręsti konfliktus; - mokėjimas derėtis; - gebėjimas suburti projekto grupę.
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
12
Projekto vadovas turi matyti bendrą projekto vaizdą ir mokėti palaikyti ryšį su įvairiais
akcininkais. Projekto sėkmę lemia ne vien techniniai, bet ir vadybiniai projekto vadovo įgūdžiai.
Aptarkime keletą pagrindinių projekto vadovo įgūdžių ir kokią įtaką jie turi jo darbui.
Mokėjimas vadovauti. Projekto vadovas turi turėti gerus vadovavimo įgūdžius. Žmonės
kviečiami į projekto grupę tik projekto vykdymo laikotarpiui, kuris gali trukti tik keletą mėnesių.
Grupės nariai gali turėti labai įvairius gebėjimus ir patirtį. IT projektų grupėse šalia techninių
specialybių atstovų paprastai būna ir rinkodaros, prekybos, klientų aptarnavimo ar mokymo
specialistų. Grupės nariai gali būti nedirbę drauge anksčiau. Dar sudėtingiau būna, kai nariai
įsijungia į projektą ar palieka jį įvairiais laiko momentais.
Projekto vadovas yra atsakingas už projekto strategijos ir bendros plėtros krypties
perteikimą grupės nariams. Geras projektų vadovas žino, kaip reikėtų skirtingo išsilavinimo ir
patirties žmones organizuoti bendram tikslui pasiekti.
Gebėjimas komunikuoti (palaikyti ryšį). Patyrę projektų vadovai sako, kad daug laiko jie
sugaišta ryšiams su įvairiais asmenimis palaikyti. Laikytis netgi labai detalaus projekto darbų
grafiko bus sunku, jei nebus tinkamai komunikuojama.
Projekto vadovas turi parengti komunikacijų su suinteresuotais asmenimis strategiją,
kurios pagrindiniai elementai yra šie:
- kokius klausimus norima aptarti;
- su kuo norima komunikuoti;
- komunikavimo būdas;
- komunikavimo rezultatų valdymas.
Turint šiuos elementus galvoje ir iš anksto parengtą išsamų komunikavimo planą, galima
išvengti daug nesusipratimų projekto eigoje.
Gebėjimas spręsti problemas. Projektų eigoje visada iškyla problemų ir joms išspręsti
projektų vadovai griebiasi įvairių būdų.
Kuo anksčiau suvokiama, kad problemos iš tikro egzistuoja, tuo lengviau būna ateityje.
Rimtai žiūrėkime ne tik į formalias projekto grupės darbo ataskaitas, bet ir į tai, ką grupės nariai
šneka ir daro.
Jeigu jūs norite rimtai išsiaiškinti galimas problemas, skirkite tam pakankamai laiko.
Paviršutiniškas problemos išsiaiškinimas gali atvesti prie klaidingų sprendimų.
Kai problema būna aiškiai ir trumpai įvardinta, projekto vadovas drauge su projekto
grupe turi ieškoti jos sprendimo būdų ir vadovauti priimto sprendimo įgyvendinimui.
Mokėjimas derėtis. Projekto eigoje vadovui dažnai tenka dalyvauti įvairiose derybose,
kurių metu priimami asmenims arba grupėms abipusiai priimtini susitarimai. Priklausomai nuo
įmonės organizacinės struktūros, jūs galite pradėti projektą derybomis su įmonės funkciniais
padaliniais dėl išteklių projektui skyrimo. Projekto grupės nariai gali pageidauti specifinių darbo
sąlygų. Projekto akcininkai gali sumanyti keisti projekto tikslus, kas savo ruožtu pareikalauja
derybų dėl darbų grafiko, biudžeto arba dėl vieno ir kito. Projekto eigoje sumanius keisti
reikalavimus, derybos būna gana sudėtingos, nes akcininkų siūlymai dažnai būna prieštaringi.
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
13
Jeigu jūsų projektui yra reikalingi išoriniai tiekėjai, jums teks dalyvauti derybose rengiant sandorius. Tai speciali sritis, į kurios darbus įtraukiami organizacijos teisės ir pirkimų padalinių specialistai. Organizaciniai gebėjimai ir gebėjimas skirti laiką. Projekto vadovas prižiūri visus projektui įvykdyti reikalingus darbus. Tipiškos jo pareigos yra prižiūrėti kaip laikomasi darbų grafiko ir biudžeto, reguliariai šaukti projekto grupės susirinkimus, kontroliuoti tiekėjus, palaikyti ryšį su akcininkais, susitikinėti individualiai su grupės nariais, rengti formalias ataskaitas, tvarkyti prašymus pakeitimams daryti. Susirinkimams sugaištama daug laiko. Jų efektyvumas priklauso nuo pasirengimo jiems, gero planavimo. Ar tai būtų formalus grupės susirinkimas, ar individualus pokalbis, projekto
vadovas privalo apibrėžti susirinkimo tikslą ir numatyti svarstomų klausimų darbotvarkę. Labai svarbu apibrėžti kiekvieno klausimo nagrinėjimo trukmę, kad visas susirinkimas baigtųsi numatytu laiku. Projekto sėkmei nemažą įtaką turi dokumentų tvarkymas, kurie turi būti prieinami vos tik
prireikus jų. Projekto vadovas gaiš pernelyg daug laiko stebėjimui, kaip laikomasi darbų grafiko, jei neturės efektyvios dokumentų tvarkymo sistemos. Geras būdas organizaciniams ir laiko skyrimo gebėjimams įgyti yra darbas patyrusio projektų vadovo priežiūroje kažkurį laiką.
1.4. Projekto valdymo procesai
Žinyne [PMBOK] projektų valdymas apibrėžiamas kaip žinių, įgūdžių, instrumentų ir metodų naudojimas projekto reikalavimams įgyvendinti. Visi projekto valdymo procesai (veiklos) dalinami į penkias grupes. Valdymo procesų grupės yra glaudžiai susijusios, nes vienos rezultatai kitoje naudojami kaip įeities duomenys. Ryšiai tarp jų trumpai pavaizduoti 1.1 lentelėje , o plačiau - 1.1 pav. Valdymo procesų grupės persidengia, skiriasi kainos ir išteklių poreikio lygiu (žiūr. 1.2 pav.).
1.1 lentelė. Projekto valdymo procesų grupės
Duomenys gaunami iš procesų grupės
Procesų grupės pavadinimas
Rezultatai perduodami procesų grupei
Iniciatorius Inicijavimas (Initiating) Planavimas
Inicijavimas
Kontrolė Planavimas (Planning) Vykdymas
Planavimas
Kontrolė Vykdymas (Executing) Kontrolė
Vykdymas Kontrolė (Controlling)
Planavimas
Vykdymas
Užbaigimas
Kontrolė Užbaigimas (Closing) Naudotojai
Valdymo procesų grupės yra projektų valdymo pagrindas. Vadovams būtina žinoti jas ir
suprasti jų įtaką projektui.
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
14
Inicijavimo procesai. Tai veiklos, kuriomis siekiama parodyti, kad reikia pradėti projektą.
Pagrindinės iš jų yra verslo poreikių įvardinimas, reikalavimų metmenų (high-level
requirements) parengimas, kainos numatymas. Plačiau apie tai rašoma šios mokymo medžiagos
2 skyriuje „Projekto inicijavimas“.
Planavimo procesai. Planavimo metu projekto tikslai yra tikslinami ir skaidomi į dalis, kad
jiems įgyvendinti reikalingi darbai būtų lengviau valdomi. Projektų vadovai įvertina projekto
trukmę, kainą, kiekvienam darbui reikalingus išteklius.
Inicijavimas
Projekto iniciatorius /
sponsorius
Įmonės duomenys (įmonės struktūra, žmoniškieji
ištekliai, projektų valdymo informacinė sistema, kt.)
Įmonės organizaciniai dokumentai
(taisyklės, procedūros, kt.) Projekto nuostatai,
preliminari projekto apimtis
Planavimas
Projekto valdymo planas
Vykdymas
Rezultatai, prašymai daryti pakeitimus, pataisymus, šalinti defektus, informacija apie
darbų eigą
Kontrolė
Prašymų daryti pakeitimus,
pataisymus, šalinti defektus
priėmimas ar atmetimas, projekto
valdymo plano, apimties naujinimas,
korekcinių ir prevencinių veiksmų
rekomendacijos, darbų ataskaitos,
prognozės, patvirtinti rezultatai
Užbaigimas Administracinės projekto
užbaigimo procedūros
sandorių užbaigimas
Naudotojai
Galutinis produktas
1.1 pav. Projekto valdymo procesų grupių sąveika
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
15
Projektų valdyme svarbios yra ir kitos veiklos, kurias taip pat būtina suplanuoti iš anksto.
Tai kokybės, rizikos, komunikacijų, pirkimų valdymas.
Planavimo klausimai aiškinami šios mokymo medžiagos 3-11 skyriuose. Vykdymo procesai. Tai projekte numatyto produkto kūrimo darbai. Projekto vadovas turi
koordinuoti visų projekto grupės narių darbą ir kitų projektui skirtų išteklių naudojimą.
Vykdymo procesų metu vadovaujamasi projekto planu, suformuojama darbo grupė,
tikrinama atliktų darbų kokybė, akcininkams platinama informacija apie projekto eigą. Plačiau
žiūr. 12 skyriuje „Projekto vykdymas“.
1.2 pav. Procesų grupių persidengimas, kainos ir išteklių poreikio lygis
Kontrolės procesai. Kontrolės veiklų paskirtis yra stebėti projekto eigą, kad laiku būtų
pastebėti nukrypimai nuo projekto plano. Prašymų daryti projekto pakeitimus analizavimas ir
atitinkamų sprendimų priėmimas yra šios procesų grupės veiklos.
Kontrolės veiklų grupei taip pat priskiriama projekto išlaidų kontrolė, kokybės kontrolė,
ataskaitų rengimas ir rizikos valdymo kontrolė. Plačiau – 13 skyriuje „Projekto kontrolė“.
Užbaigimo procesai. Tai projekte sukurtos sistemos formalaus priėmimo (užsakovas
priima iš projekto vykdytojo) ir perdavimo einamajam darbiniam naudojimui veiklos.
Užbaigimo veikloms priskiriamas įvairių pareigūnų parašų rinkimas, projekto dokumentų
perdavimas į archyvą, sukurtos sistemos perdavimas priežiūros grupei, projekto grupės narių
atleidimas, gautų pamokų peržiūra. Kai kurios iš jų gali atrodyti labai paprastos, tačiau kitos
nusipelno rimto dėmesio. Apie projektų užbaigimą plačiau rašoma 14 skyriuje „Projekto
užbaigimas“.
1.5. Projekto gyvavimo ciklas
Kiekvienas projektas turi pradinę, viduriniąsias ir baigiamąją fazes. Projekto gyvavimo
ciklas – tai laike išdėstytų fazių rinkinys. Idealiu atveju vienos fazės rezultatai turėtų būti gauti ir
patvirtinti anksčiau nei pradedama kita fazė. Realiame gyvenime įvairios projektų gyvavimo ciklo
Kontrolė
Projekto pradžia Projekto pabaiga
Proceso lygis
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
16
fazės dažnai būna persidengiančios, t. y. vienai fazei dar nepasibaigus pradedama kita fazė.
Paprastai taip daroma norint sutrumpinti projekto darbų grafiko trukmę.
Skirtingų verslo sričių projektų gyvavimo ciklai gali skirtis. Gali skirtis netgi ciklų fazės.
Tačiau visada projekto gyvavimo ciklas turi atspindėti kiekvienos fazės rezultatus ir reikalingų
išteklių kategorijas. Ciklas turi atspindėti ir užbaigto projekto rezultatų naudojimą.
Panagrinėkime IT projektų gyvavimo ciklą.
1.5.1. IT projektų gyvavimo ciklas
Kiekvienas IT projektas turi gyvavimo ciklą, susidedantį iš kažkokio fazių kiekio.
Programų sistemų kūrimo ciklo (SDLC – Software Development Life Cycle) fazės – planavimas,
analizė, projektavimas, realizavimas, naudojimas ir priežiūra - yra glaudžiai susiję su 1.4 skyriuje
nagrinėtomis projektų valdymo procesų grupėmis. Todėl pravartu sistemų kūrimo ciklo (SDLC)
fazes prisiminti kiek plačiau.
Planavimo fazė. Ši fazė pradedama gavus prašymą sukurti naują sistemą iškilusioms
problemoms spręsti arba patobulinti jau egzistuojančią sistemą. Prašyme išdėstoma problema ir
verslo procesai, kuriems pagerinti reikėtų sukurti sistemą.
Prašymu sukurti sistemą potencialiai siekiama tokių dviejų tikslų: atlikti pirminius verslo
procesų tyrimus ir atlikti jų pagerinimo IT priemonėmis galimybių studiją (ar reikia rengti
studiją, priklauso nuo sistemos dydžio). Pirminiai verslo tyrimai iš esmės susiveda į sistemos
reikalavimų metmenų (high-level requirements) rengimą. Turint juos, gali būti inicijuota
galimybių studija, kad būtų išsiaiškinta prašymo kaina/nauda ir parengtos sistemos kūrimo
rekomendacijos trukmės, ekonominiais, techninių sąlygų ir kitokiais klausimais.
Sistemos planavimo metu gali būti siūloma keisti ir pačius verslo procesus, kad būtų
lengviau įgyvendinti siekiamus tikslus. Kartais automatizacija ir technologijos nepadeda, o
pakeitus verslo procesus norimus rezultatus galima pasiekti lengvai.
Analizės fazė. Šios fazės metu, nusipiešus verslo duomenų judėjimo schemą, rengiamas
loginis sistemos modelis, formuluojami jau detalūs sistemos reikalavimai.
Analizės metu siekiama išsiaiškinti sistemos detales. Apklausinėjant akcininkus, renkant ir
analizuojant faktus, kuriant idėjas, iš ko turėtų susidėti sistema ir ką ji turėtų daryti, kuriami
įvairūs įmonės modeliai su joje cirkuliuojančiais duomenimis. Sistemos prototipų rengimas yra
būdas supažindinti akcininkus su būsima naująja sistema.
Programų sistemų kūrimo ciklo (SDLC) Planavimo ir Analizės fazės atitinka projektų
valdymo Inicijavimo ir Planavimo procesų grupes.
Galutinis sistemos analizės rezultatas yra sistemos reikalavimų dokumentas. Jame
išdėstoma viskas, ką sakė verslo atstovai, ir ko jie nori iš naujos sistemos.
Projektavimo fazė. Šioje fazėje nurodomi visi elementai, įskaitant įvesties ir išvesties
duomenis, reikiamus procesus, kurie turi būti įtraukti į projektą. Taip pat projektavimo metu
nurodomi rankiniai ar automatiniai tikrinimo būdai, kurių reikės norint įsitikinti, ar sukurta
sistema veikia tinkamai. Jei projekte bus kuriama programinė įranga, turi būti parengta sistemos
projekto specifikacija (SDS – System Design Specification), t. y. dokumentas, kuriame
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
17
atsispindima kuriamos programinės įrangos architektūra. To reikia, kad grupės nariai galėtų
tiksliai kurti norimą sistemą.
Jeigu projekte nereikia kurti naujos programinės įrangos, bet reikia kurti ar tobulinti
duomenų bazę ar infrastruktūrą, labai svarbu, kad visi akcininkai, pradedant vadovais ir baigiant
galiniais naudotojais, suprastų, kas yra suprojektuota ir kaip tai veiks, ir kad techniniai
specialistai būtų pajėgūs sukurti norimą sistemą. Jei rengiamasi naudoti gatavą komercinę
programinę įrangą (COTS – Commercial Of The Shelf), būtina parengti jos integravimo į kuriamą
sistemą projektą.
Į sistemos projektą gali būti įtraukta infrastruktūros plėtra ar naujinimai, naujų ryšio
linijų tiesimas, naujo tipo įrenginių diegimas ir kiti dalykai. Tai gali pareikalauti ir ankstesnės
sistemos programinių elementų atnaujinimo.
Realizavimo fazė. Šios fazės metu sistema jau yra kuriama (gaminama). Bet kuriuo atveju,
ar tai būtų naujų programų rašymas, ar gatavų programų (COTS) pirkimas, ar abiejų minėtų
veiksmų kombinacija, siekiama sukurti visas numatytas funkcijas vykdančią ir gerai
dokumentuotą sistemą.
Sistemos realizavimo fazė apima tokius veiksmus, kaip senų duomenų konvertavimą į
naujo formato duomenis, testavimą, naudotojų mokymą, perėjimą prie naujos sistemos. Taip pat
rengiamas sistemos įvertinimas, kuriame atspindimi būdingi jos bruožai ir ar sistema atitinka
projekto specifikaciją (SDS).
Naudojimo ir priežiūros fazė. Ši programų sistemų kūrimo ciklo (SDLC) fazė tam tikra
prasme atitinka projektų valdymo Užbaigimo procesų grupę. Pastarosios metu sistema
perduodama einamajam darbiniam naudojimui ir pasirenkamas jos priežiūros būdas
sutrikimams šalinti. Tačiau Naudojimo ir priežiūros fazė prasideda pasibaigus projektų valdymo
Užbaigimo procesams. Be to jos metu kartais daromi sistemos keitimai, kuriais siekiama išplėsti
jos funkcijas ar atlikti kitokius patobulinimus.
Projekto koncepcija (reikalavimų metmenys)
Lyginant dvi metodologijas – Projektų valdymą ir jo procesų grupes su Programų sistemų
kūrimo ciklu (SDLC) – reikėtų neišleisti iš galvos vieno kiek kitokio tipo dokumento - projekto
koncepcijos. Projekto pradžioje sistemų analitikas, nagrinėdamas užsakovo prašymą pradėti
projektą, parengia projekto koncepciją, t. y. reikalavimų metmenis (high-level requirements). Šis
dokumentas yra impulsas pradėti projekto planavimą. Sistemų analitikas gali ir nebūti projekto
vadovas. Tam gali būti įvairios priežastys, pvz., analitikas yra kitos organizacijos atstovas arba
projektas yra labai sudėtingas. Bet kuriuo atveju kokybiškai atlikta sistemos analizė ir gerai
parengtas sistemos projektas (planas, angl. design) yra efektingos sistemos sukūrimo laidas.
Projekto koncepcija yra idealus atramos taškas pradėti projektą ir šalių derybas.
Pastebėkime, kad analitikas, tęsdamas savo darbą, iš projekto koncepcijos (reikalavimų
metmenų) rengia detalius reikalavimus, o projektų vadovas turi griežtai laikytis parengtų
reikalavimų.
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
18
1.5.2. IT projekto etapai ir kontroliniai taškai
Bet kurios programų sistemos kūrimo ciklas (SDLC) dalinamas į etapus (fazes), kas
palengvina projekto eigos stebėjimą. Pvz., el. komercijos projektų etapai yra sistemos sukūrimui
reikalingų priemonių pirkimas, instaliavimas, derinimas, serverių įrengimas. Etapą turėtų
sudaryti labai aiškią pabaigą turinčių užduočių rinkinys. Apie etapo įvykdymą projekto vadovas
turėtų duoti vienareikšmį atsakymą - taip arba ne, kad akcininkai galėtų susidaryti aiškų vaizdą
apie projekto eigą.
Projekto etapai savo ruožtu gali turėti keletą kontrolinių taškų (checkpoints). Juose
nurodomi suplanuoti terminai, iki kada turėtų būti atlikti kažkurie projekto darbai, ir
suplanuotos biudžeto išlaidos. Kontroliniai taškai padeda įvertinti projekto stovį duotais laiko
momentais.
1.6. Organizacijos struktūros įtaka projektams
Projektų valdymui didelę įtaką turi organizacijos struktūra. Nuo to priklauso projekto
vadovui suteikiami įgaliojimai ir projekto vykdymui reikalingų išteklių skyrimas.
Projektų vadovai susiduria su įvairiais rūpesčiais. Daugumos jų priežastis yra
organizacijos, kurioje vykdomas projektas, struktūra ir jos veikla. Todėl būtina suprasti, kaip jūsų
organizacijoje žiūrima į projektus, kad žinotume, kaip reikėtų elgtis sprendžiant įvairius
klausimus.
1.6.1. Funkcinio tipo organizacija
Funkcinio tipo organizacijos sutinkamos dažniausiai. 1.2 pav. parodyta jų struktūra.
Darbuotojai jose yra paskirstyti į funkcinius padalinius (departamentus), pvz., personalo, finansų,
teisės, tinklų priežiūros, IT, klientų aptarnavimo, kt. Kiekvienas padalinio darbuotojas žino, kas
yra jo viršininkas.
Funkcinio tipo organizacijose projektai atliekami kaip atskiri, padaliniams
nepriklausantys darbai. Jie netgi gali būti atskirai valdomi.
Funkcinio tipo organizacijų charakteringas bruožas yra tas, kad jose projektų vadovai turi
labai ribotus įgaliojimus, organizacijos ištekliai projektui naudojami tik dalį laiko, o sprendimus
projektų klausimais dažnai priima kurio nors padalinio vadovas.
Funkcinio tipo organizacijose projektų vadovų padėtis kartais būna kebli, nes atsakomybė
už visą projektą užkraunama jiems, bet jie negali versti projekto grupės narių būti atsakingų už
projekto rezultatus. Nuo funkcinio padalinio vadovo priklauso projekto grupės nario alga,
premijos, darbinė kategorija. Kai kuriose organizacijose projekto vadovui leidžiama teikti
pasiūlymus dėl darbo grupės narių paskatinimo ar kategorijos pakėlimo, o tokių pasiūlymų
svoris gali būti ir neproporcingas grupės nario dalyvavimo projekte laikui.
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
19
Projekto vadovas funkcinio tipo organizacijoje daugiausia laimi, jei sugeba palaikyti gerus
santykius su funkcinių padalinių vadovais. Projektui sėkmingai užbaigti dažnai tenka prašyti
papildomų išteklių ar aukštesnės kvalifikacijos specialistų. Taigi, panašių klausimų sprendimas
drauge su funkcinių padalinių vadovais yra labai svarbus.
1.6.2. Matricos tipo organizacija
Kitas organizacijų tipas – matricos – parodytas 1.3 pav. Matricos tipo organizacijos,
panašiai kaip ir funkcinio tipo organizacijos, yra padalintos į funkcinius padalinius
(departamentus), tačiau už projektui skirtus išteklius viso projekto metu yra atsakingas projekto
vadovas. Projektų vadovai dažnai sudaro atskirą organizacijos funkcinį padalinį. Projekto grupės
nariai turi du arba daugiau vadovų. Jie yra pavaldūs funkcinio padalinio vadovui ir projekto
vadovui.
Funkcinio
padalinio
vadovas
Funkcinio
padalinio
vadovas
Funkcinio
padalinio
vadovas
Funkcinio
padalinio
vadovas
Darbuotojas
Darbuotojas
Darbuotojas
Darbuotojas
Darbuotojas
Darbuotojas
Darbuotojas
Darbuotojas
Darbuotojas
Darbuotojas
Darbuotojas
Darbuotojas
1.2 pav. Funkcinio tipo organizacija (paryškintas „Darbuotojas“ – projekto grupės narys)
Organizacijos vadovas
Funkcinio
padalinio
vadovas
Funkcinio
padalinio
vadovas
Funkcinio
padalinio
vadovas
Vyriausiasis
projektų
vadovas
Darbuotojas
Darbuotojas
Darbuotojas
Darbuotojas
Darbuotojas
Darbuotojas
Darbuotojas
Darbuotojas
Darbuotojas
Projekto vadovas
Projekto vadovas
Projekto vadovas
1.3 pav. Matricos tipo organizacija (paryškinti „Projekto vadovas“ ir „Darbuotojas“ – projekto grupė)
Organizacijos vadovas
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
20
Matricos tipo organizacijų būdingi bruožai yra vidutinio lygio įgaliojimų suteikimas
projektų vadovams, leidimas jiems naudoti projekto išteklius dalį projekto laiko arba visą jo laiką,
geresnis komunikavimas tarp funkcinių padalinių. Savo ruožtu matricos tipo organizacijos
dalinamos į dvi rūšis: lengvąsias ir griežtąsias. Griežtojo matricos tipo organizacijose projektų
vadovams suteikiami didesni įgaliojimai.
Matricos tipo organizacijose projektų vadovai turi gerai išsiaiškinti su projekto grupės
nariais ir funkcinių padalinių vadovais, kuriems nariai pavaldūs, tokius dalykus: už ką projekto
grupės narys turi atsiskaityti projekto vadovui ir už ką - padalinio vadovui. Grupės narys tam
tikrais klausimais turi atsiskaityti tik vienam vadovui, kad būtų išvengta nesusipratimų. Kita
matricos tipo organizacijose rūpesčių kelianti problema yra ribotų išteklių paskirstymas. Jei
funkcinio padalinio žmogus paskiriamas 50% laiko dirbti viename projekte, tai gali turėti žymų
poveikį to funkcinio padalinio darbui arba kitiems projektams, kuriuose tas žmogus taip pat
dirba.
Išteklių paskirstymo klausimo išsprendimas projekto pradžioje padeda išvengti problemų
ateityje.
1.6.3. Projektinio tipo organizacija
Trečias organizacijų tipas – projektinis – parodytas 1.4 pav. Tai organizacijos, kurių
pagrindinis darbas yra projektų vykdymas.
Projektinio tipo organizacijų pagrindinis bruožas yra visų įgaliojimų suteikimas projektų
vadovams, leidimas jiems naudoti išteklius visą projekto laiką, projektui vykdyti reikalingos
darbo grupės sudarymas.
Projektinio tipo organizacijose projektų vadovai yra atsakingi už visus su projektu
susijusius klausimus. Grupės nariai išdėstomi taip, kad jiems būtų patogu komunikuoti ir
efektyviai dirbti.
Projektinio tipo organizacijų didelė problema, kaip elgtis su darbo grupės nariais
pasibaigus projektui. Ne visada jų laukia naujas projektas. Laiko numatymas žmoniškiesiems
ištekliams didinti ar mažinti yra sudėtingas uždavinys.
Projekto
vadovas Projekto
vadovas
Projekto
vadovas
Projekto
vadovas
Darbuotojas
Darbuotojas
Darbuotojas
Darbuotojas
Darbuotojas
Darbuotojas
Darbuotojas
Darbuotojas
Darbuotojas
Darbuotojas
Darbuotojas
Darbuotojas
1.4 pav. Projektinio tipo organizacija (paryškinti „Projekto vadovas“ ir „Darbuotojas“ – projekto grupė)
Organizacijos vadovas
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
21
2. PROJEKTO INICIJAVIMAS
Inicijavimo procesai priklauso pirmai iš penkių projektų valdymo žinyne [PMBOK]
įvardintų procesų grupių. Inicijavimas apima prašymo (užsakymo) priėmimą ir projekto aprašo
parengimą. Priklausomai nuo organizacijos, šis procesas gali būti formalus arba neformalus.
Inicijuojant projektą, užsakymą gavusi organizacija drauge su užsakovu peržiūri jo
pageidavimus, išsiaiškina tikslus ir kaip turi būti matuojamas tikslų pasiekimo lygis, apibrėžia
projekte numatomą sukurti produktą (įrangą, paslaugą ar kt.). Programų sistemų projektuose
produkto apibrėžimas vadinamas reikalavimų metmenimis (high-level requirements), nes geriau
atitinka tokios veiklos sritį.
Inicijuojamų projektų naudingumą būtina įvertinti. Tai ypač aktualu, kai siūloma keletas
projektų. Kuris iš projektų duos didžiausią naudą ir kurio reikėtų imtis visų pirma? Nutarimo
pradėti projektą priėmimui reikalingas projektų atrankos procesas ir kriterijai. Šiame mokymo
medžiagos skyriuje nagrinėjami pagrindiniai projektų atrankos metodai: išlaidų-naudos analizė,
matematiniai vertinimo modeliai, finansinė analizė, ekspertų nuomonės išklausymas.
Supažindinama su projektų rėmėjais: sponsoriumi, akcininkais ir kitais asmenimis, kurie yra
suinteresuoti ir turi įtakos projekto rezultatų pasiekimui.
Galutinis projekto inicijavimo rezultatas yra organizacijos vadovybės patvirtinti projekto
nuostatai (project chart), leidžiantys pradėti projektą, ir formalus projekto vadovo paskyrimas.
2.1. Prašymas pradėti projektą
Projektui pradėti būtinas prašymas (užsakymas). Jam rengti gali būti įvairios priežastys:
- rinkos poreikis naujai įrangai ar paslaugai;
- vidiniai organizacijos poreikiai;
- kitõs (išorinės) organizacijos užsakymas;
- naujos technologijos;
- teisės aktų reikalavimai;
- socialiniai poreikiai, pvz., šalies infrastruktūros plėtra.
Organizacijoje prašymai pradėti projektus gali būti gaunami ne tik iš jos vidinių padalinių,
bet ir iš kitų (išorinių) organizacijų. Organizacijoje gali būti IT veiklos analitikas, kuriam pavesta
rūpintis savo organizacijos padaliniais ir registruoti jų poreikius. Stambesnėse kompanijose gali
vykti keleto departamentų atstovų pasitarimai IT projektų perspektyvoms svarstyti. Vieno
departamento asmuo teikiantis prašymą kitam departamentui traktuojamas kaip klientas arba
užsakovas. Tačiau nemažai organizacijų klientu arba užsakovu laiko tik kitos organizacijos
asmenį. Todėl būtina žinoti, kaip jūsų organizacijoje ši sąvoka yra interpretuojama. Vidinis arba
išorinis užsakovas gali teikti projekto užsakymą tiesiai organizacijos vadovybei.
Nežiūrint to, kas sugalvoja ir teikia prašymą pradėti projektą, organizacijos vadovybė ar
jos įgalioti asmenys turi peržiūrėti prašymą ir priimti sprendimą. Kadangi pradinis prašymas gali
būti ne detalus, reikia surinkti tiek informacijos, kad galima būtų tiksliai įvertinti prašymą.
Vadovybės paskirtas projekto vadovas turėtų susitikti su prašytoju (užsakovu), kad išsiaiškintų
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
22
prašymo detales, tiksliau apibrėžtų numatomą kurti produktą, apsvarstytų funkcinius ir
techninius reikalavimus, parengtų projekto reikalavimų metmenis (high-level requirements).
2.1.1. Reikalavimų metmenys
Reikalavimų metmenys kitur dar yra vadinami projekto koncepcija, produkto apibrėžimu.
Jiems parengti būtina gerai suprasti problemą ar verslo (veiklos srities) poreikius, dėl kurių
prašoma pradėti projektą, ir, žinoma, savo paties funkcijas, kurių vykdymo žadate imtis.
Problemos apibrėžimas
Projektas gali nukrypti neteisingu keliu, jei projekto vadovas neskirs laiko užsakovo
problemoms ar poreikiams išsiaiškinti.
Užsakovo reikalavimai gali būti neaiškūs arba netiksliai suformuluoti. Projekto vadovo
pareiga yra išsiaiškinti, ko užsakovas iš tikrųjų nori. Tam reikia išnagrinėti užsakovo prašymą ir
išdėstyti jam, kaip jūs supratote jį. Taip gali būti parengta projekto koncepcija, kurioje jūs savais
žodžiais aprašote užsakovo reikalavimus.
Gali kilti keblumų, jei užsakovas reikalavimus išdėsto atsakymų (sprendimų) stiliumi. IT
pasaulyje tai nėra reta, ypač kai užsakovo norai yra specifiniai. Užsakovas gali būti nurodęs būdą,
kaip turėtų būti įgyvendinami jo reikalavimai. Tačiau jūs negalite būti tikri, kad užsakovo
nurodytas būdas yra teisingas. Todėl projekto vadovas turi įsitikinti, kad nurodytas būdas yra
tinkamas užsakovo problemoms spręsti.
Nepakankamas problemos apibrėžimas ir išsiaiškinimas yra viena iš IT projektų žlugimo
priežasčių. Nelaikykime užsakovo nurodyto problemos sprendimo būdo geriausiu, kol
neišsiaiškinsime verslo poreikių. Aiškiai apibrėžta problema sudaro geresnes sąlygas jums ir
užsakovui kuriamos sistemos funkciniams ir techniniams reikalavimams įvardinti.
Reikalavimų kategorijos
Funkciniai reikalavimai. Prisiminkime, kad projektais yra kuriami unikalūs produktai.
Funkciniais reikalavimais apibrėžiama, ką sukurta sistema turės daryti. Funkcinių reikalavimų
akcentas yra, kaip naudotojas sąveikaus su sistema. Užsakovo reikalavimai, kuriam versle
prireikė naujo pavidalo ataskaitų, smarkiai skiriasi nuo reikalavimų užsakovo, kuris nori įsidiegti
naują sistemą. Todėl svarbu yra apibrėžti problemą, prieš pradedant rengti specifinius
reikalavimus. Žinodami problemą jūs galėsite užduoti teisingus klausimus, kad išsiaiškintumėte
užsakovo reikalavimus. Naujo pavidalo ataskaitų atveju jūs turite žinoti, kaip ataskaita turi
atrodyti, o naujos sistemos diegimo atveju jums reikės visiškai kitokių duomenų.
Nors funkciniai reikalavimai gali būti formuluojami bendresnėmis sąvokomis nei
techniniai reikalavimai, projektų vadovas klausinėdamas turi išsklaidyti neaiškumus. Pvz., jei
užsakovo reikalavimuose rašoma, kad sukurta sistema turi būti patogi naudotojui, ar jūs
suprantate ką tai reiškia? Jei nesuprantate, vadinasi, reikalavimai yra neaiškūs ir jūs turite
išsiaiškinti, kaip užsakovas supranta sąvoką „turi būti patogi naudotojui“. Jei nesate tikri, kad
reikalavimas suformuluotas aiškiai, užduokite sau klausimą, kokį testavimo scenarijų rengtumėte
to reikalavimo įgyvendinimui patikrinti. Jei nežinote, kaip reikėtų patikrinti reikalavimo
įgyvendinimą, jūs turite gauti iš užsakovo daugiau duomenų.
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
23
Verslo reikalavimai. Užsakovo verslo reikalavimai atspindi rodiklius, kuriuos siekiama
pagerinti projektu. Verslo rodiklių pagerėjimu gali būti laikoma bet kas, pradedant pajamų
padidėjimu ir baigiant išlaidų sumažėjimu. Taip pat verslo pagerėjimą gali reikšti organizacijos
darbuotojų sumažėjimas, įdiegus projekto rezultatus.
Techniniai reikalavimai. Techniniai reikalavimai kitaip dar yra vadinami ne-funkciniais
reikalavimais. Tai produkto funkciniuose reikalavimuose išvardintų funkcijų vykdymo
charakteristikos (greitis, tikslumas, saugumas, kt.), kad produktas atitiktų kliento poreikius.
Techniniai reikalavimai būna įvairių kategorijų. Kokios kategorijos reikalavimai yra
reikalingi, priklauso nuo kuriamos sistemos. Dažniausiai sutinkamos techninių reikalavimų
kategorijos: panaudojimo galimybių (usability) reikalavimas, priežiūros patogumo
(maintainability) reikalavimas, teisiniai reikalavimai, eksploatacinių savybių (performance)
reikalavimai, veikimo (operational) reikalavimai, saugumo reikalavimai.
Jei jūs dirbate teisės aktų reguliuojamoje veiklos srityje, pasitikrinkite, kokių
vyriausybinių teisės aktų ar pramoninių standartų turite laikytis projektuodami ir pristatydami
sistemą. Nesilaikymas teisės aktų ar standartų reikalavimų gali būti rimtas nusižengimas, o
pažeidimų šalinimas gali pareikalauti laiko ir lėšų.
Pramoniniai standartai gali turėti įtakos jūsų projekto techniniams reikalavimams, jei
kuriate programinę įrangą, kuri turi turėti sąsajas su jau egzistuojančiomis sistemomis.
Programinės įrangos sąsajos gali reikalauti specifinių programavimo kalbų arba metodologijų.
Tokie reikalavimai turi būti išdėstyti projekto reikalavimų dokumente, nes tai gali būti svarbu
vėliau, planuojant projekto darbų trukmę ir kainą.
IT projektų techninių reikalavimų pavyzdžiai:
- sistemos reakcijos į užklausą laikas turi būti ne ilgesnis kaip 5 sekundės;
- sistema turi būti prieinama kiekvieną dieną nuo 7 iki 21 val.;
- sistema turėtų veikti PC ir Mac architektūros kompiuteriuose.
Jūsų užsakovas gali būti geriau pasirengęs svarstyti funkcinius, o ne techninius
reikalavimus. Todėl jūs turite būti sudarę standartinių klausimų sąrašą. Užsakovų, kuriems
kuriate sistemą, jūs galite prašyti tokių duomenų, kaip, pvz., vienu metu galinčių dirbti naudotojų
kiekis, sistemos darbo valandų kiekis per parą, aparatinės įrangos platforma ir kitų, kurie gali
būti reikalingi projektuojant ir kuriant naują sistemą. Jei organizacija, kurioje jūs dirbate, turi
reikalavimų šablonus ar katalogus, naudokite juos susitikimuose su užsakovais.
2.1.2. Tiekėjų pasiūlymai
Kartais, inicijuojant projektus, būtina atsižvelgti į tokius išorinius veiksnius, kaip tiekėjų,
kurių parduodamos įrangos ar teikiamų paslaugų gali reikėti, pasiūlymai. Dažniausiai to prireikia
diegiant naujas technologijas. Norint pasitelkti tiekėjus, tenka skelbti konkursus jiems parinkti,
rengti kvietimus teikti pasiūlymus (RFP – Request for Proposal), pasirašyti su jais sandorius.
Renkant tiekėją nurodoma darbų užduotis (SOW – Statement Of Work), kurią jis turės
atlikti sutartomis sąlygomis.
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
24
Išorės tiekėjų pasiūlymai būna įvairūs ir gali neatitikti jūsų projekto. Todėl, sudarant
sandorius, reikia būti atidiems. Sandoriai yra teisiniai dokumentai, vadovaujantis kuriais turi būti
vykdomi sutarti projekto darbai.
RFP, SOW, sandoriai yra pirkimų (procurement) planavimo dalis, apie ką plačiau rašoma
šios mokymo medžiagos 10 skyriuje.
2.1.3. Reikalavimų metmenų dokumento rengimas
Kai išsiaiškinamos užsakovo problemos, apibrėžiami funkciniai, verslo ir techniniai
reikalavimai, tuomet rengiamas reikalavimų metmenų dokumentas.
Reikalavimų metmenys yra formalus pagrindas vadovybei sprendimui dėl projekto
vykdymo priimti. Jis taip pat yra pagrindas projekto apimčiai, kainai, reikalingiems ištekliams,
darbų grafikui nustatyti.
Reikalavimų metmenyse turėtų būti tokia informacija:
1) problemos apibrėžimas:
- kas iššaukė poreikį vykdyti projektą;
- kokius specifinius verslo klausimus užsakovas nori išspręsti;
2) tikslai:
- kaip jūs suprantate sėkmingą projekto pabaigą;
- kokio galutinio rezultato siekiama;
- kokių elementų visuma (pvz., įranga, dokumentai, mokymas) sudarys galutinį
rezultatą;
- kokie tikslai;
- kaip įvertinti (išmatuoti), ar tikslas pasiektas;
3) strateginė vertė:
- kaip sistema atitinka užsakovo strateginę viziją;
- ar yra sąsajų su kitais siūlomais ar vykdomais projektais;
4) reikalavimai:
- kokias funkcijas kuriama sistema turės vykdyti;
- ar reikės sąsajų su egzistuojančiomis sistemomis;
- kokie eksploatacinių savybių (performance) kriterijai;
- kokie sukurtos sistemos palaikymo (priežiūros) reikalavimai;
5) veiksmų ir aplinkybių įvertinimas (timing): < projekto vykdytojo galimybės >
- kada projektas turi būti baigtas;
- ar reikės subrangovų (sandorių su tiekėjais);
- ar bus dideli nuostoliai, jei projektas nebus įvykdytas;
- ar turės įtakos bendrosioms pajamoms, jei projektas vėluos;
6) ankstesnė patirtis (istoriniai duomenys):
- ar buvo panašių projektų anksčiau;
- ar tie projektai buvo sėkmingi;
- ar ankstesnių projektų dalis galima panaudoti šiame projekte?
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
25
Aiškūs reikalavimų metmenys su išmatuojamais tikslais ir tinkamais duomenimis apie
strateginę vertę, veiksmų ir aplinkybių įvertinimą, ankstesnę patirtį, taip pat nuolatinis
komunikavimas projekto klausimais yra labai svarbūs vadovybei tvirtinant projektą.
2.2. Projektų atranka
2.2.1. Atrankos būdai
Projektų atrankos metu sprendžiami projektų patvirtinimo, leidimo pradėti projektą ir
finansavimo skyrimo klausimai. Tą daro organizacijos vadovybė. Kai kur šiuos klausimus gali
spręsti ir departamento ar kitokio padalinio vadovas.
Sudėtingų projektų atveju rengiamos galimybių studijos (feasibility study) ir tik jų
pagrindu priimami sprendimai dėl projekto vykdymo. Vertinama nauda, rinkos dydis, rizika,
alternatyvos. Tą daro žmonės, nesusiję su prašytojais vykdyti projektą.
2.2.2. Atrankos kriterijai
Projektų atrankos komitetas naudoja tam tikrus kriterijus siūlomiems vykdyti projektams
įvertinti ir atrinkti. Pasirinktas atrankos metodas turi būti vienodai taikomas visiems projektams,
kad priimtas sprendimas geriausiai atitiktų organizacijos strateginius tikslus ir geriausiai būtų
naudojami turimi ištekliai. Kriterijų tikslumas gali varijuoti, tačiau atrankos metodą dažniausiai
sudaro kurio nors sprendimų priėmimo modelio ir ekspertų (patyrusių specialistų) nuomonių
kombinacija.
Sprendimų priėmimo modeliai
Sprendimo priėmimo modelis yra formalus projektų atrankos metodas, padedantis
vadovams geriausiai panaudoti ribotą biudžetą ir žmoniškuosius išteklius. Prašymai pradėti
projektus gali būti susiję su labai įvairiais poreikiais, todėl projekto prioritetui nustatyti gali
reikėti prašymų palyginimo. Besivaržantiems departamentams kiekvienas jų prašymas,
tikriausiai, atrodo aukščiausio prioriteto. Tačiau dėl riboto biudžeto ir žmoniškųjų išteklių vieną
projektą tenka patvirtinti, o kitą atmesti. Priimtas sprendimas gali būti subjektyvus, jei nebus
atliktas prašymų palyginimas. Sprendimo priėmimo modelyje naudojamas kriterijų rinkinys, kurį
nustato projektų atrankos komitetas. Naudodamas tą patį modelį kiekvienam prašymui įvertinti,
komitetas gali priimti labiausiai objektyvų sprendimą. Sprendimo priėmimo modelių gali būti
įvairių, pradedant elementariai sudaroma eile ir baigiant sudėtingais matematiniais modeliais.
Yra dvi pagrindinės sprendimų priėmimo modelių kategorijos: naudą vertinantys metodai
ir dalinės optimizacijos modeliai (constrained optimization models).
Naudą vertinantys metodai. Naudą vertinantys metodai įgalina palyginti prašymų vykdyti
projektus naudą, įvertintą naudojant tokius pačius kriterijus. Jie yra naudojami žymiai dažniau,
nei dalinės optimizacijos modeliai. Yra trys naudą vertinantys metodai: kainos-naudos analizė,
vertinimo balais modelis ir ekonominis modelis.
Kainos-naudos analizės metode (CBA – Cost Benefit Analysis) įvertinama projekto kaina,
numatomi sutaupymai, numatomas pajamų padidėjimas. Praktikoje dažniausiai naudojamas toks
rodiklis: pelno ir kainos santykis (BCR – Benefit Cost Ratio). Tai dėl projekto gautų pajamų ir
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
26
investuotos į projektą sumos santykis. Jei BCR>1, projektas atsipirko. Kuo BCR didesnis, tuo
projektas patrauklesnis.
Šis metodas gerai tinka tais atvejais, kai projekto atranka remiasi tuo, kaip greitai atsipirks
investicijos į projektą, kiek sumažės organizacijos veiklos išlaidos ar padidės pajamos. Silpnoji
kainos-naudos analizės metodo vieta yra ta, kad neįvertinami kiti svarbūs veiksniai, kaip
strateginė projekto vertė. Per trumpiausią laiką atsiperkantys projektai organizacijai gali būti ir
ne svarbiausi.
Vertinimo balais modelyje naudojami iš anksto nustatyti kriterijai. Vadovaujantis jais,
projektai yra reitinguojami. Kiekvienas kriterijus turi leistiną balų kiekį ir svorio koeficientą.
Vertinimo balais modelis gali apimti finansinius duomenis, rinkos dydį, organizacinę patirtį
vykdyti projektus, inovacijas, bendrąjį organizacijos kultūros lygį. Šis modelis turi objektyvių ir
subjektyvių kriterijų. Konkretaus prašymo vykdyti projektą įvertinimo galutinis balas
apskaičiuojamas nustačius kiekvienam kriterijui balą, padauginus jį iš svorio koeficiento ir
susumavus gautas sandaugas. Kai kurios organizacijos turi nusistačiusios vertinimo balais
modelio minimalias reikšmes. Jei įvertis nesiekia minimalios reikšmės, projektas pašalinamas iš
atrankos proceso. Vertinimo balais modelio nauda yra ta, kad svarbiausiam kriterijui jūs galite
suteikti didžiausią svorį. Naudojant aukštą svorio koeficientą inovacijoms, galima gauti tokį
rezultatą, kad projektas su dviejų metų atsipirkimo laikotarpiu nurungs projektą su pusės metų
atsipirkimo laikotarpiu. Silpnoji vertinimo balais modelio vieta yra ta, kad sudaryta projektų eilė
priklauso nuo kriterijų reikšmių balais ir svorio koeficientų pasirinkimo. Gerą vertinimo balais
modelį sudaryti yra sunku. Tam reikia didelio įvairių žinybų vykdančiosios valdžios atstovų
pasišventimo.
Ekonominis modelis yra serija finansinių skaičiavimų, kurie duoda bendrus projekto
finansinius duomenis. Tai labai plati tema. Čia tik trumpai pateikiame keletą bendriausių
ekonominiame modelyje sutinkamų sąvokų:
1) diskonto norma (d). Tai pinigų nuvertėjimo bėgant laikui rodiklis. Pinigai dabar yra
vertingesni už pinigus ateityje. Diskonto norma kartais dar vadinama kapitalo kaina. Ji
apskaičiuojama taip:
d = (1+N) / (1+I) – 1 + r, kur N – rinkos palūkanų norma (pvz., 0,07. Tai atitinka 7%);
I – prognozuojama infliacija (pvz., 0,03, atitinkamai 3%);
r – rizikos koeficientas (pvz., 0,05).
Esant pavyzdžiuose nurodytoms reikšmėms, gauname d = 0,09;
2) diskontuotas pinigų srautas (DCF - Discounted cash flow). Tai diskontuotas pajamų ir
išlaidų skirtumas per tam tikrą laiko periodą (pvz., metus);
3) grynoji dabartinė vertė (NPV - Net Present Value). NPV sąlyginai parodo pinigų sumos
ateityje ekvivalentą šiandien. Projekto NPV suskaičiuojama kaip diskontuotų pinigų srautų suma
pagal tokią formulę:
NPV = Σn ( Sn / (1+d)n ), kur n = 0, 1, 2, ..., k; k – periodų (pvz., metų) kiekis, t. y. numatoma projekte sukurto produkto
gyvavimo trukmė;
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
27
Sn – n-tojo periodo pinigų srautas;
d – diskonto norma.
Kai n = 0, tuomet S0 yra išlaidos projekto pradžioje. Kuo NPV didesnis, tuo projektas yra
patrauklesnis;
4) atsipirkimo periodas (payback period). Tai numatomas laiko tarpas, per kurį projektas
atsipirks. Per šį laiką pinigų srauto (DCF) reikšmė pasidaro ir toliau išlieka teigiama;
5) vidinė grąžos norma (IRR - Internal Rate of Return). Tai investicijos arba projekto
pelningumo rodiklis, apskaičiuojamas kaip palūkanų norma, kuriai esant projekto grynoji
dabartinė vertė NPV pasidarytų lygi nuliui per projekto gyvavimo trukmę. Gaunamas pagal
formulę:
0 = Σn ( Sn / (1+IRR)n ),
kur n = 0, 1, 2, ..., k; k – numatomas projekte sukurto produkto gyvavimo periodų (pvz., metų)
kiekis; Sn – n-tojo periodo pinigų srautas.
Kuo IRR didesnis, tuo projektas rentabilesnis (pelningesnis). Pvz., jei diskonto norma d
yra mažesnė už IRR, verta skolintis pinigų ir pradėti projektą. Kitu atveju – ne;
6) atsipirkimo norma (ROI – Return On Investment). Tai gautų pajamų ir investuotos į
projektą sumos skirtumo santykis su investuota į projektą sumą. Jei ROI>0, tai projektas
atsipirko. Kuo ROI didesnis, tuo projektas patrauklesnis.
Matematinio modeliavimo metodai. Vienas iš jų yra dalinės optimizacijos modelis. Kai
kurie iš jų yra labai sudėtingi ir reikalauja gilių statistikos ir kitų matematikos žinių. Šie modeliai
naudojami labai sudėtingiems projektams įvertinti ir atrinkti.
Ekspertų nuomonė
Siūlomus projektus vertinti gali ir ekspertai. Ekspertizę gali atlikti sponsorius,
pagrindiniai akcininkai, kito departamento žmonės, konsultantai, pramonės atstovai. Ekspertų
nuomonė gali būti derinama su vieno iš sprendimo priėmimo modelio rezultatais. To dažniausiai
prireikia, kai atrankai pateiktų projektų įverčiai, gauti naudojant sprendimo priėmimo modelį,
mažai tesiskiria.
Organizacijos, kurios nenaudoja formalios projektų atrankos, gali remtis vien ekspertais.
Nors ekspertai ir gali padaryti paprastesnį projektų atrankos procesą, tačiau pavojus suklysti
išlieka. Nepanašu, kad projektų atrankos komiteto nariai gerai išmanytų visus pristatytus
projektus. Neturint duomenų, kuriuos galima būtų palyginti, projektą patvirtinantis sprendimas
gali būti priimtas remiantis tik tuo, kad projektas geriausiai buvo pristatytas arba kad pranešėjas
yra geriau žinomas.
Ekspertų nuomonei įtakos gali turėti ir politiniai motyvai. Arba, autoritetingas
administratorius gali įtikinti projektų atrankos komitetą patvirtinti tam tikrą projektą.
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
28
2.3. Projekto akcininkai
Projekto reikalavimų metmenų rengimo ir projektų atrankos metu jūs jau susiduriate su
svarbiais asmenimis – akcininkais. Kaip apskritai suprantamas akcininkas ir kodėl jūs turite
žinoti pagrindinius savo projekto akcininkus?
Akcininkas yra asmuo, kuris aktyviai įsijungia į projektą arba kuriam projektas daro įtaką.
Akcininkai kažką laimi arba praranda, todėl būtina žinoti jų lūkesčius, viltis. Akcininkai gali
susidomėti ir įsijungti į projektą skirtingais laiko momentais.
Kai kurie akcininkai gali neremti jūsų projekto. Jų veiklai didelę įtaką turintis projektas
gali būti traktuojamas kaip tam tikra grėsmė. Pokyčių gali būti bijomasi. Veiklos efektyvumą
didinantys projektai gali būti susiję su darbuotojų kiekio mažinimu. Bijodami netekti darbo, tam
tikri asmenys arba organizacijos gali prieštarauti projektui.
Bendraujant su akcininkais jums gali prireikti daugelio bendrųjų projekto vadovo įgūdžių
(žiūr. 1.3 skyrių). Kai kurie akcininkai gali turėti skirtingus jūsų projekto prioritetus, dėl ko gali
tekti vesti sunkias derybas. Konsensuso (sutarimo) tarp skirtingas nuomones turinčių akcininkų
siekimas pradedamas derybomis projekto inicijavimo etape ir tęsiasi visą projekto laiką.
Smulkiau kai kurie ryšių su akcininkais palaikymo klausimai aptariami 9 skyriuje „Komunikacijų
planavimas“.
Susitikimus su akcininkais ir jų apklausas organizuokime kaip galima anksčiau, kad
sužinotume, kas juos domina ir ko jie tikisi iš projekto. Jei pradžioje kuriuos nors akcininkų
keliamus klausimus ignoruosime, vėliau juos išspręsti bus žymiai sunkiau.
2.3.1. Projekto sponsorius
Projekto sponsorius yra ypatingas akcininkas. Nors projektas turi daug akcininkų, apie
kuriuos rašoma truputį vėliau, tačiau sponsorius yra (turėtų būti) tik vienas.
Sponsorius yra asmuo, kuris remia projektą organizacijos vardu. Jis yra kaip projekto
vadovo patarėjas. Projekto vadovas informuoja sponsorių apie projekto einamuosius reikalus,
įskaitant konfliktus ir galimą riziką. Projekto sponsorius paprastai yra atsakingas už:
- projektui reikalingų finansų gavimą;
- pagrindinių akcininkų analizę;
- derybas su pagrindiniais akcininkais dėl paramos projektui;
- projekto etapų rezultatų priėmimą;
- trukdžių ir sunkumų šalinimą;
- politinio „stogo“ teikimą projekto vadovui.
2.3.2. Kiti projekto akcininkai
Visas akcininkų sąrašas priklauso nuo projekto ir organizacijos, kurioje jūs dirbate. Kuo
didesnis ir sudėtingesnis projektas, tuo daugiau akcininkų jūs turėsite. Aukšto lygio projektuose
akcininkų kartais būna daugiau negu reikia. Todėl rekomenduojama projekto vadovui išnagrinėti,
kurie akcininkai iš tikro yra susiję su projektu, ir jų sąrašą aptarti drauge su sponsoriumi.
Sponsorius gali geriau įvardinti „politiškai“ svarbius akcininkus, t. y. įtakingus žmones tų
organizacijų, kurios išreiškė susidomėjimą projektu.
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
29
Kai kurie akcininkai yra aiškūs ir nesunku juos įvardinti. Be projekto sponsoriaus
dauguma projektų turi nemažai bendrųjų akcininkų. Išvardinkime juos.
Projekto vadovas. Tai asmuo, kuris vadovauja projekto darbams. Plačiau apie šį asmenį jau
rašyta 1.3 skyriuje.
Projekto grupės nariai. Tai ekspertai (specialistai), kurie vykdys projekto darbus.
Priklausomai nuo jūsų organizacijos struktūros tipo (funkcinė, matricos ar projektinė) šie
žmonės gali būti pavaldūs tiesiog projekto vadovui arba priklausyti kitam departamentui.
Projekto grupės nariai gali būti įdarbinti projekte visą jo laiką arba tik dalį laiko. Daugumoje
projektų vieni nariai įdarbinami visam projekto laikui, kiti – daliai laiko. Jei yra žmonių įdarbintų
tik daliai projekto laiko, jūs turite žinoti ir kitas jų pareigas, kad nebūtų persidengimų (tuo pačiu
metu žmogus negali dirbti ir čia, ir ten).
Jūsų projekto grupėje gali būti ne vien tik IT srities specialistai, bet ir pirkimų, teisės,
viešųjų ryšių, rinkodaros, pardavimų, klientų aptarnavimo specialistų.
Funkcinių padalinių vadovai. Jei projekte įdarbinami jūsų organizacijos funkcinių
padalinių žmonės, šių funkcinių padalinių vadovai, skyrę žmones projektui, yra svarbūs
akcininkai. Paprastai keletas projektų konkuruoja dėl turimų žmoniškųjų išteklių gavimo. Todėl
jūs turite stengtis palaikyti gerus santykius su funkcinių padalinių vadovais. Dokumentuoti
susitarimai dėl žmonių skyrimo projektui kažkuriam laikui ir atsiskaitymai už žmonių darbą gali
apsaugoti nuo nesusipratimų ateityje. Išankstiniai susitarimai su šiais vadovais suteikia duomenų
apie įkainius, algos dydį, žmonių skatinimo galimybes.
Funkcinio padalinio vadovas priima sprendimus minėtais klausimais. Jei jūs sutarsite su
funkcinių padalinių vadovais iš anksto, nuo to aiškesnis taps jūsų vaidmuo ir pakils autoritetas.
Pirkėjas / klientas. Pirkėjas yra projekte sukurto produkto ar paslaugos gavėjas. Kai
kuriose organizacijose šie akcininkai gali būti traktuojami kaip klientai. Pirkėju dažniausiai
vadinama grupė arba organizacija, o ne pavienis asmuo. Gali būti vidiniai pirkėjai, pvz.,
organizacijos prekybos padalinys, prašantis įrengti serverių sistemą. Išorinio pirkėjo pavyzdžiu
gali būti įstaiga, norinti įsigyti naujų sistemos savybių, funkcijų.
Galinis naudotojas. Galiniais naudotojais vadinami asmenys, kurie betarpiškai naudoja
projekte sukurtą produktą. Ši sąvoka dažnai naudojama IT projektuose, siekiant pabrėžti
skirtumą tarp projekto produktą perkančios organizacijos ir grupės žmonių, kurie produktą
naudos kasdieninėje veikloje. Pvz., organizacijos pardavimų padalinys, turintis on-line prieigą
prie sistemos, gali būti laikomas pirkėju, tuo tarpu už organizacijos ribų esantys pardavimų
konsultantai yra tokios sistemos galiniai naudotojai.
Galiniai naudotojai gali dalyvauti kai kurių projekto reikalavimų peržiūrose arba produkto
funkciniuose testavimuose.
Iš bendrųjų akcininkų sąrašo matyti, kad jie atstovauja plačiam su projektu susijusiam
funkcinių sričių, norų ir poreikių ratui. Jų įgyvendinimui stebėti, tikriausiai, norėtumėte sudaryti
akcininkų lentelę ar sąrašą (vieni stebėtų ir nagrinėtų vienus rodiklius, kiti – kitus).
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
30
2.3.3. Kas yra jūsų IT projekto akcininkai?
Tipiškai IT projekto akcininkais tampa panašia veikla užsiimančių ir prašančių pradėti
projektą verslo organizacijų atstovai. Kadangi IT naudojamos beveik kiekvienoje organizacijų
veikloje, todėl laikui bėgant jūs galite susidurti su įvairiausiais projektais. Dažniausiai
susiduriama su trijų klasių IT projektais, kuriems specifinę įtaką daro akcininkų rato sudėtis:
vienos veiklos srities (single business unit) projektais, keleto veiklos sričių (multiple business
unit) projektais ir įmonių (enterprise) projektais. Smulkiau aptarkime kiekvieną iš jų.
Vienos veiklos srities projektas. Vienos veiklos srities projektuose jums gali tekti
užmegzti glaudesnius ryšius, pvz., su rinkodaros ar pardavimų atstovais, kad jie padėtų parengti
projektą (planą, angl. design) sistemos, kuri atitiktų specifinius jų veiklos poreikius.
Tokiais atvejais, tikriausiai, jums bus pristatoma veiklos srityje naudojama sistema, tačiau
nebeatitinkanti poreikių. Daugeliu atveju veiklos srities akcininkai jau būna atlikę kai kuriuos
tyrimus, ko jie norėtų, ir turi parengę rekomendacijas dėl jau gatavos (COTS) programinės
įrangos įsigijimo, kuri jų manymu tiktų jiems. Kaip projekto vadovas jūs turėtumėte atidžiai
išnagrinėti tą programinę įrangą, nes ji gali neatitikti didesnių organizacijų reikalavimų. Taip pat
būtina įsitikinti, ar ta įranga yra vientisa, patikima, labiausiai reikalinga ir ar jūs pajėgsite tvarkyti
ją.
Kai kuriais atvejais veiklos srities atstovai tiesiog nežino, kokia programinė įranga galėtų
išspręsti jų problemas. Tuomet jie prašo jūsų padėti suformuluoti projekto užduotį. Dar didesnę
veikimo laisvę jūs gaunate štai tokiu atveju. Gatavos (COTS) programinės įrangos šiandien yra
tiek daug, kad jūs sėkmingai galite rasti pakankamai gerai tinkančią veiklos sričiai. Tačiau kai
kuriais atvejais gali būti prašoma sukurti naują programinę įrangą pagal užsakovo specifikaciją.
Tuomet jums, kaip projekto vadovui, pasitelkus sistemų analitiko gebėjimus, reikia priimti
geriausią jums žinomą sprendimą, tinkantį iškeltam uždaviniui.
Keleto veiklos sričių projektas. Kartais dvejom arba daugiau veiklos sričių gali tikti ta pati
sistema jų problemoms spręsti. Pavyzdžiu gali būti dokumentų tvarkymo sistema (DMS –
Document Management System). Keleto veiklos sričių projektas yra toks, kai dvi arba daugiau
organizacijų pareiškia, kad jos bendrai gali finansuoti joms visoms tinkantį DMS projektą.
Šiuo atveju uždavinys yra kur kas sunkesnis, nes jūs turite reikalą su įvairiais akcininkais,
kurių kiekvienas turi savo veiklos sritį, tačiau panašius interesus. Pasiekti akcininkų sutarimą yra
svarbiausias uždavinys.
Papildomas sunkumas yra tas, kad jūs turite įsigilinti į kiekvieną veiklos sritį, norint
sukurti visiems priimtiną sistemą. Vieniems gali nereikėti, pvz., gaunamų dokumentų kontrolės
DMS‘e, nes juos turi tikrinti siuntėjas, laikydamasis teisės aktų reikalavimų. Tuo tarpu kitiems
gaunamų dokumentų kontrolė gali būti reikalinga. Tokių klausimų sprendimas yra svarbus
projektų valdyme.
Įmonės projektas. Dar viena projektų rūšis yra įmonės projektas. Įmonė – tai įvairių jos
padalinių visuma.
Įmonės projektu gali būti, pvz., organizacijos el. pašto sistema arba bendras intranetas.
Visi įmonės darbuotojai naudosis šiomis sistemomis, o jas prižiūrės, greičiausiai, atskiros IT
specialistų grupės.
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
31
Įmonės projektai kelia įdomius akcininkų rato klausimus. Kas yra jūsų organizacijos
kurios nors sistemos akcininkas? Sistemą tai naudoja visi darbuotojai. Taigi, jūsų žvilgsnis gali
nukrypti į bet kurią ankstesniame šios mokymo medžiagos skyriuje įvardintą akcininkų grupę,
ieškant pagrindinio sistemos akcininko. Pvz., naujoje el. pašto sistemoje įrašai, tikriausiai, bus
tvarkomi bendrai. Todėl asmuo arba grupė, įgaliota parengti įrašų saugojimo tvarką, bus labai
svarbus akcininkas, sprendžiant el. pašto klausimus. Naujame bendrame intraneto projekte visi
naudotojai bus akcininkai, bet, greičiausiai, kiekvienos veiklos srities (organizacijos funkcinio
padalinio) duomenų (content) tvarkytojai bus pagrindiniai projekto akcininkai.
IT projekto grupės nariai. IT projektuose kai kurie grupės nariai (nepamirškime, kad ir jie
yra akcininkai) gali turėti keletą pareigų. IT projektų grupės skiriasi nuo statybų projektus
vykdančių grupių. Statybininkai dirba tik tuos darbus, kuriuos jie geriausiai moka (pvz.,
santechnikas nedirba elektriku). IT projektų grupėse būna narių, kurie specializuojasi vienoje
kurioje nors IT srityje, tačiau gerai išmano ir kitų grupės narių funkcijas. Programinės įrangos
kūrėjai turi gerai suprasti ir duomenų bazes, nes sistemos naudotojų įvedamus duomenis dažnai
tenka rašyti į duomenų bazę. Duomenų bazių administratoriai ypač gerai turi žinoti, ką daro
programuotojai, suprasti, kaip veikia serveriai ir kaip naudotojai kompiuterių tinklais jungiasi
prie duomenų bazių. Serverių administratorius turi suprasti, kad serveriai reikalingi veiklos
funkcijoms atlikti, kad nekrintanti į akis tinklo operacinė sistema (NOS – Network Operating
System) nėra suma to, ką daro serveris. Visame šitame margumyne yra ir sistemų analitikai,
verslo analitikai, atskirų veiklos sričių žinovai ir kiti, kurie drauge siekia projekto rezultatų.
Išvardinkime specialybes žmonių, kurių, priklausomai nuo kuriamo produkto, gali reikėti
IT projekto grupėje.
Programuotojai. Tai dažniausiai sutinkami darbuotojai IT projektuose. Jų kuriami
produktai yra labai įvairūs: serverių taikomosios programos, naudotojų sąsajos, mikroprogramos
(jos veikia aparatinėje įrangoje), duomenų bazėse laikomos procedūros, interneto / intraneto
specializuoti moduliai (spausdintuvams, komunikacijoms).
Serverių administratoriai. Šie grupės nariai yra atsakingi už projekto produktui
funkcionuoti reikalingų serverių įrengimą (Intel, mainframe ar kitokioje bazėje).
Duomenų bazių administratoriai (DBA). Jie yra atsakingi už duomenų bazės struktūros ir
atitinkamų reikalavimų parengimą, duomenų atsarginių kopijų darymo ir atstatymo metodikų
suplanavimą. DBA darbas apima lentelių struktūros paprastinimo greitesniam jų apdorojimui
koncepcijos parengimą. Šis procesas vadinamas normalizacija.
Interneto specialistai. Jų pareiga yra tvarkyti maršrutizatorius (routers), komutatorius
(switches), išvedžioti vietinio kompiuterių tinklo (LAN – Local Area Network) kabelius, rūpintis
jungtimis su plačiuoju kompiuterių tinklu (WAN – Wide Area Network).
Telefonijos specialistai. Žmonės, kurie organizacijoje tvarko telefonų įrangą ir jos veikimą,
vadinami telefonijos specialistais. Šiandien daug sistemų naudoja telefonijos paslaugas.
Prisiminkime telefono principu veikiančią meniu sistemą – interaktyvųjį atsakymą balsu (IVR –
Interactive Voice Response). Jos programinė įranga įgalina reaguoti į skambučius, pateikti
naudotojui meniu sistemą, ką jis gali pasirinkti, ir išduoti atitinkamą atsakymą. IVR programinė
įranga veikia serveryje, sujungtame su telefonų tinklu.
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
32
Sistemų analitikai. Sistemų analitikai yra ypač kvalifikuoti žmonės ir turintys patirtį IT
srityje. Jie, kurdami sistemos reikalavimus ir iš jų rengdami sistemos projekto (plano, angl.
design) specifikaciją, dirba funkcijų lygiu. Toliau sistemos kūrėjai (gamintojai) naudoja
specifikaciją vykdydami projektą. Šiandien sistemų analitikai turi gerus programinius
instrumentus, kurie padeda jiems greitai ir tiksliai sumodeliuoti sistemą, turint veiklos procesų
sekas.
Veiklos srities analitikai. Dažnai tas pats žmogus būna ir sistemų, ir veiklos srities
analitikas. Jis žino veiklos srities bendrąsias (high level) sąvokas, kad galėtų šnekėtis ir suprasti
veiklos srities poreikius. Tačiau jis moka bendrauti ir su IT specialistais, padėdamas jiems
suprasti, ko veiklos srities atstovai iš tikro nori. Veiklos srities analitiku gali būti IT specialistas,
dirbęs toje veiklos srityje, arba veiklos srities specialistas, dirbantis IT įmonėje.
Sistemų architektai. Sistemų architektai turi aukšto lygio žinias apie sistemas ir yra
pajėgūs parengti siūlomos sistemos planą. Kartais sistemų analitikas būna ir sistemos architektu.
Būna ir taip, kad sistemos kūrėjui (gamintojui) ir net projekto vadovui tenka rengti sistemos
architektūrą. Tačiau, kuriant dideles sistemas, projektų vadovams dažniausiai talkina tikrieji
sistemų architektai.
Biudžeto analitikas. Ypač dideliems projektams reikia biudžeto analitiko, kuris stebėtų
projekto biudžetą ir daromas išlaidas.
Saugumo analitikas. Saugumo analitikas yra palyginus naujas, tačiau būtinai reikalingas
narys daugelio sistemų projektų grupėse. Saugumo analitikas turi rūpintis, kad kuriamoje
sistemoje visos saugumo priemonės būtų įgyvendintos. Ši specialybė yra unikali ir reikalaujama,
kad saugumo analitikas, ypač vidutinio ir didelio masto projektuose, turėtų puikų išsilavinimą ir
būtų patikimas asmuo.
Techniniai redaktoriai. Dideliuose projektuose techninių redaktorių pareiga yra visų
projekto dokumentų rašymas. Tai mokymo dokumentai, naudotojų instrukcijos, pagalbos
naudotojams tarnybos (help-desk) tekstai ir kiti dokumentai.
Šie žmonės turi suprasti techninį žargoną ir santrumpas, mokėti susišnekėti visais
klausimais. Svarbu, kad techniniai redaktoriai būtų draugiški, nebijotų klausti, kas yra padaryta,
ir glaudžiai bendradarbiautų. Projekto grupė turi būti sudaryta iš žmonių, kurie supranta
projekto tikslus ir drauge siekia jų. Kitaip bus chaosas.
Projekto grupės nariai turi būti iniciatyvūs žmonės, galintys vykdyti užduotis be didelės
priežiūros, besilaikantys sistemos projekto (design) specifikacijos. Sistemos projekto grupė nėra
gera vieta tik pradedantiems dirbti, nes čia reikalingi žmonės su patirtimi.
Kaip techninio projekto grupės vadovas, jūs turite suprasti, kad teks dirbti su įvairaus tipo
asmenimis ir kažkaip reikės derinti psichologinius dalykus. Šalia tvirto supratimo apie projekto
rezultatų technologinius niuansus, jūs taip pat turite turėti supratimą apie projekto grupės
dinamiką ir kaip žmonės sąveikauja iškilus sunkumams. Jūs turite būti pasirengęs spręsti
skundus, derinti argumentus, surinkus visus drauge logiškai aiškinti savo veiksmus, kad visi
akcininkai suprastų juos, ir t. t. IT projektų valdyme būtinas aiškus, trumpas ir adekvatus
komunikavimas su akcininkais.
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
33
Akcininkų sąrašas. Jeigu yra didelis projektas ir daug akcininkų, gali būti sudaromas
akcininkų sąrašas projekto eigai stebėti. Šiame akcininkų sąraše turėtų būti tokia informacija
apie akcininkus:
- vaidmuo projekte;
- projekto poreikis;
- įsitraukimas (dalyvavimas) į projektą;
- įtakos projektui lygis.
Šis sąrašas gali būti naudingas įrankis projekto peržiūrose, kai iškyla konfliktai. Jis gali
padėti projekto vadovui suprasti ir tinkamai reaguoti į įvairias situacijas. Sąrašo reikšmė ypač
svarbi, kai jūsų projektas turi keletą politinių akcininkų.
Kadangi akcininkai gali pasitraukti iš projekto ar įsijungti į projektą skirtingu laiku, labai
svarbu, kad projekto vadovas peržiūrėtų projekto nuostatus ir projekto planą, kai tik akcininkas
įsijungia į projektą.
2.4. Projekto nuostatai
Inicijavimo procesų rezultatas yra projekto nuostatai (project chart). Tai dokumentas
leidžiantis pradėti projektą ir įgaliojantis projekto vadovą naudoti projektui skirtus išteklius.
Projekto nuostatai yra pirmas patvirtinto projekto dokumentas. Projektus paprastai tvirtina
organizacijos ar departamento vadovybė. Ši organizacija nebūtinai turi būti sponsorius.
Projekto nuostatai yra pradinis projekto planas. Galutinis projekto produktas, tikriausiai,
smarkiai skirsis nuo pradžioje sumanyto, tačiau nuostatai yra pirmosios projekto darbų gairės.
Projekto nuostatų formą ir turinį nustato organizacijos, kurioje jūs dirbate, vidiniai
standartai. Jūs, kaip projekto vadovas, turėtumėte pasidomėti, ar nėra kokio nors šablono, kurio
privalu laikytis. Bet kuriuo atveju projekto nuostatuose turi būti reikalavimų metmenys, verslo
poreikių dėstymas ir formalus patvirtinimas, leidžiantis pradėti projektą. Jei jūsų projektas
dalyvavo formaliame atrankos procese, tai, tikriausiai, būsite surinkę daugiau duomenų. Jie
įgalina parengti projekto nuostatus, kuriuose būtų reikalavimų metmenys, informacija dėl
projekto grupės, uždaviniai ir tikslai, projekto pagrindimas ir formalus projekto patvirtinimas.
Projekto nuostatų dalis apibūdinkime plačiau.
2.4.1. Reikalavimų metmenys
Reikalavimų metmenyse nurodomos pagrindinės projekte numatomo kurti produkto
charakteristikos ir tam reikalingi darbai. Remiantis šiais metmenimis vėliau, t. y. projekto
apimties planavimo metu bus rengiami detalūs reikalavimai. Projekto reikalavimų metmenys
atspindi sąryšį tarp numatomo kurti produkto ir verslo poreikių, dėl ko buvo inicijuotas
projektas. Plačiau apie reikalavimų metmenis rašyta 2.1.1 skyriuje.
2.4.2. Informacija apie projekto grupę
Projekto nuostatuose formaliai įvardinamas projekto vadovas ir jam suteikti įgaliojimai.
Aiškus įgaliojimų išdėstymas padeda ateityje išvengti nesusipratimų. Juose turi būti nurodoma:
- ar projekto vadovas galės samdyti ir atleisti darbuotojus;
- ar projekto vadovas galės įtakoti grupės narių algos dydį;
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
34
- ar projekto vadovas bus atsakingas už projekto biudžeto lėšų panaudojimą;
- pinigų suma, kurią projekto vadovas galės išleisti be sponsoriaus ar kito
administratoriaus leidimo.
Gali būti išvardinti visi žinomi projekto grupės nariai. Tačiau projekto nuostatuose
dažniausiai nurodomos tik reikiamų darbuotojų specialybės, kategorijos. Gali būti vardinami,
pvz., veiklos srities analitikas, sistemų analitikas, programuotojas, testuotojas. Projektų, kuriuose
bus sudaromi sandoriai su išoriniais subrangovais (cross-functional projects), nuostatuose
reikėtų išvardinti reikiamus grupės narius ir iš kitų departamentų, kaip produkto vadybininkas,
sandorių specialistas ar mokymų rengėjas.
2.4.3. Uždaviniai ir tikslai
Projekto nuostatuose turi būti įvardinti projekto uždaviniai ir tikslai. Šioje nuostatų dalyje
aiškiai turi būti nurodyta, kokie projekto rezultatai turi būti gauti ir kaip bus vertinama rezultatų
kokybė. Uždaviniai ir tikslai turi būti aiškūs ir suformuluoti taip, kad galima būtų įvertinti
galutinių rezultatų atitikimą iškeltiems tikslams. Pvz., vietoje formuluotės „įdiegti greitą įrašų
apie pirkėjus paieškos sistemą“ reikėtų naudoti „įdiegti sistemą, kurioje įrašų apie pirkėjus
vidutinė paieškos trukmė būtų 5 sekundės“.
Dirbant su klientais, kiekybiškai išmatuojami tikslai yra projekto sėkmės laidas. Juos
vienodai turi suprasti ir klientas, ir sponsorius, ir pagrindiniai akcininkai, ir projekto vadovas, ir
projekto grupės nariai. Neaiškūs tikslai, kurių įgyvendinimo lygį sunku įvertinti, kelia didelį
pavojų projekto sėkmei.
2.4.4. Projekto pagrindimas
Vadovybės patvirtinti projekto nuostatai reiškia ir projekto pradinio finansavimo
patvirtinimą. Pradinis finansavimas priklauso nuo projekto pagrindimo (business case). Projekto
pagrindime formaliai atspindimi elementai, naudoti projekto vertinimo metu. Tai analizės
metodų ir rezultatų aprašymas.
Projekto pagrindimas yra autonominis dokumentas. Pradžioje jo turinys būna labai
abstraktus, o projekto eigoje daug kartų tikslinamas. Projekto pagrindimas papildomas detalėmis
projekto planavimo procese. Nemažai organizacijų turi projektų pagrindimo šablonus, kurių kai
kurios dalys užpildomos projektų atrankos metu.
Projekto pagrindimas projekto nuostatuose gali turėti apytikrius kainos (išlaidų), naudos ir
atsipirkimo periodo įverčius.
Kaina (išlaidos). Projekto tvirtinimo metu turi būti nurodytas galimų išlaidų
žmoniškiesiems ištekliams išlaikyti, medžiagoms, įrangai įsigyti įverčiai. Šie įverčiai nėra tikslūs,
nes gaunami remiantis anksčiau vykdytų panašių projektų patirtimi arba ekspertų nuomone.
Tipiniame IT projekte skiriamos dvi išlaidų dalys: turtui įsigyti ir žmoniškiesiems
ištekliams išlaikyti. Turto įsigijimo išlaidas sudaro naujos įrangos, kaip serveriai, darbo
kompiuteriai ir pan., įsigijimo kaina. Žmoniškųjų išteklių išlaikymo išlaidos – tai darbuotojų algos,
komandiruotpinigiai, mokymų išlaidos.
Nauda. Pajamos yra pagrindinis naudos rodiklis. Tai pinigų srautas, gaunamas už projekte
sukurto produkto ar paslaugų teikimą išoriniam pirkėjui. Ne visi projektai generuoja pajamas,
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
35
tačiau tiems projektams, kurių rezultatai parduodami išoriniams pirkėjams, pajamos yra kritinis
rodiklis. Pradinį pajamų dydį įvertina rinkodaros specialistai, remdamiesi numatoma sukurto
produkto kaina ir pardavimų prognoze.
Pajamos yra kiekybiškai išmatuojama nauda. Pvz., gali būti projektuojama, kad per pirmus
metus po produkto sukūrimo (pabaigus projektą) pajamos bus vienas milijonas litų.
Kitus naudos rodiklius, kaip, pvz., padidėjusį pirkėjų pasitenkinimą, sunku išmatuoti
kiekybiškai. Naudą, kurios negalima įvertinti pinigais, vadina nepamatuojama (soft benefit).
Atsipirkimo periodas. Pajamas generuojantiems projektams atsipirkimo periodas reiškia
laiką, per kurį grįžta į projektą investuotos lėšos.
Atsipirkimo periodą taip pat gali turėti ir pajamų negeneruojantys projektai. Pvz., nauja
užklausų aptarnavimo sistema su geru meniu gali padidinti užklausų aptarnavimo centro
efektyvumą, nedidinant darbuotojų kiekio. Taip sutaupomų lėšų dydis gali būti panaudotas tos
sistemos atsipirkimo periodui apskaičiuoti.
2.4.5. Formalus projekto patvirtinimas
Projekto nuostatus turi pasirašyti įgaliojimus turintis administratorius. Tai gali būti
projekto sponsorius, projekto klientas arba projektų atrankos komiteto atstovas. Nuostatus
pasirašiusio asmens parašas reiškia tos organizacijos leidimą pradėti projektą.
Tokiu parašu suteikiami įgaliojimai projekto vadovui pradėti projekto darbus. Tai leidžia
jam pradėti įrangos pirkimus ir derybas su organizacijos funkcinių padalinių vadovais dėl
projektui reikalingų žmoniškųjų išteklių skyrimo.
Užbaigus projekto nuostatus, nuo inicijavimo procesų pereinama prie planavimo procesų.
Nežiūrint to, kas pasirašė projekto nuostatus, dabar pats laikas pradėti rūpintis jūsų projekto
akcininkų parama. Visiems akcininkams reikia išdalinti projekto nuostatų kopijas. Taip pat
reikėtų organizuoti susirinkimą su jais projekto nuostatams apsvarstyti, tolesniems projekto
žingsniams ir rūpimiems klausimams aptarti. Kad ateityje nekiltų ginčų dėl susirinkimo rezultatų,
pagrindiniai svarstyti klausimai ir priimti nutarimai turi būti dokumentuojami ir išsiuntinėjami
visiems akcininkams. Kuo anksčiau problemos įvardinamos, tuo lengviau jas spręsti. Ko nors
ignoravimas ar nepakankamas akcininkų informavimas gali pareikalauti aukštesnių vadovų
įsikišimo, nuvesti projektą klaidingu keliu. Labai svarbu užsitikrinti aukštesnės vadovybės
paramą, palaikant su ja nuolatinį ryšį. Projekto vadovas atsako už tai, kad projekto metu tarp
akcininkų būtų sutarimas.
IT vadovų hierarchija (chain of command). Projekto nuostatuose įvardinami žmonės,
kurie bus atsakingi už projektui reikalingų išteklių naudojimą. Projekto vadovui pravartu žinoti,
kokia yra IT vadovų hierarchija organizacijoje, kas ir kokius įgaliojimus turi. Nors dauguma IT
padalinių yra smulkūs (pvz., programuotojų, serverių administratorių, kt. grupėse yra tik po
keletą žmonių), kiekvienas iš jų turi savo vadovą, savo biudžetą, savo darbuotojus. Pvz., jūsų
projektui prireikė programuotojo, kuris yra pavaldus keturis ar penkis darbuotojus turinčiam
programuotojų padaliniui. Tas padalinys turi savo vadovą, kuris yra atsakingas už šių darbuotojų
kasdieninę veiklą. Šis vadovas turi būti nurodytas projekto nuostatuose, nes jis turi teisę skirti ar
neskirti jūsų projektui reikalingą programuotoją. Tas pats yra ir su kitų sričių specialistais. Jūs
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
36
negalite kreiptis į kitokio padalinio vadovą dėl programuotojo skyrimo jūsų projektui, nes
programuotojas nepavaldus tam vadovui. Taigi, būtų protinga žinoti organizacijos vadovų
hierarchiją, kas ir kokius technologinius darbus kuruoja.
IT vadovų hierarchija gali priklausyti nuo organizacijos, kurioje jūs dirbate, dydžio ir
išsidėstymo. Kalbant bendrai, gali būti programuotojų, tinklų priežiūros, serverių priežiūros,
telefonijos, saugumo, interneto / intraneto, duomenų bazių, kt. padalinių vadovai. Šie vadovai yra
atskaitingi aukštesnio lygio vadovams. 2.1 pav. parodytas IT organizacijos darbuotojų
hierarchijos pavyzdys, kuriame matome ir projektų valdymo skyrių (PMO – Project Management
Office). Kai kurios organizacijos (pvz., matricos tipo organizacijos) turi PMO. Jame suburiami visi
profesionalūs projektų vadovai. Toks skyrius pajėgus imtis bet kokio organizacijos projekto.
Hierarchijos laikymosi problemos. Projekto nuostatuose nurodomos projektui vykdyti
reikalingų darbuotojų specialybės (pavardžių galime ir nežinoti). Todėl pavaldumo hierarchijos
žinojimas palengvina jūsų darbą, nes žinote į ką organizacijoje reikia kreiptis dėl jūsų projektui
reikiamų specialistų. Pvz., nereikėtų reikalauti skirti programuotoją, nepasitarus su
programuotojų padalinio vadovu, atsakingu už šių žmonių panaudojimą.
IT įmonėse yra tam tikrų problemų dėl darbuotojų pavaldumo (atskaitomybės)
hierarchijos laikymosi. Ne visada pavyksta sutarti su padalinių vadovais dėl jūsų projektui
reikalingų išteklių skyrimo. Tenka įdėti daug planavimo pastangų, darbo su kiekvieno padalinio
vadovais, kad jie skirtų savo žmones projektui tinkamu laiku.
Dar sudėtingesnės problemos kyla, kai keleto mažesnių padalinių vadovai nėra atskaitingi
tam pačiam aukštesniam vadovui.
Deja, nėra idealaus būdo tokioms komplikuotoms situacijoms valdyti. Geriausia
problemas numatyti iš anksto ir projekto darbų grafike skirti papildomą laiką joms spręsti.
IT departamento direktorius
Projektų valdymo skyrius (PMO)
Programuotojų
padalinio vadovas
Tinklų priežiūros
padalinio vadovas
Infrastruktūros
padalinio vadovas
Duomenų bazės
administratorius Programuotojas Serverio
administratorius
Interneto
administratorius
2.1 pav. IT organizacijos darbuotojų hierarchijos pavyzdys
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
37
3. PROJEKTO APIMTIES PLANAVIMAS
Planavimas yra vienas iš svarbesnių projekto valdymo darbų. Gavus leidimą vykdyti
projektą, natūralu, kad vykdytojams rūpi pradėti jį kuo greičiau. Tačiau projekto vadovas gali
pastebėti, kad organizacija nėra numačiusi laiko planavimo darbams.
Geras planavimo proceso suvokimas padeda projekto vadovui pasirengti pokalbiams su
savo organizacijos vadovybe apie laiko skyrimą projekto valdymo klausimams apgalvoti dar iki
tikrųjų darbų pradžios. Projekto planavimas yra sudėtingas procesas. Jis apima daugybę
klausimų, kaip projekto apimties, darbų grafiko, kainos, darbuotojų kiekio, pirkimų, kokybės,
rizikos planavimą. Pradedant šiuo mokymo medžiagos skyriumi ir baigiant 11 skyriumi „Projekto
bendrojo plano rengimas“, nagrinėjami visi projektų planavimo klausimai. Šis skyrius skirtas
projekto apimties planavimo klausimams.
Projekto apimtis – tai įvykdyti reikalingų darbų kiekis ir dydis. Projekto vadovas turi
žinoti, kokius darbus reikės atlikti projekto eigoje. Apimties planavimas padeda apibrėžti
reikiamą išteklių kiekį ir nustatyti projekto ribas (terminus, kainą, kokybę).
Projekto apimties planavimas siejamas su šių trijų dokumentų parengimu (apimties plane
turi būti šios trys dalys):
- apimties aprašo;
- apimties valdymo plano;
- suskaidytų darbų lentelės (WBS – Work Breakdown Structure).
Apimties apraše pateikiama bendroji projekto samprata, tikslai, laukiami rezultatai
(deliverables). Apimties valdymo plane išaiškinamos procedūros, kurių reikės laikytis norint
daryti kokius nors siūlomus projekto apimties pakeitimus viso jo gyvavimo ciklo bėgyje.
Suskaidytų darbų lentelėje projektas padalinamas į smulkius darbus (užduotis), kad lengviau
būtų įvertinti jų trukmę, reikalingus išteklius, išlaidas.
3.1. Projekto apimties plano struktūra
Projektų valdyme yra savos taisyklės ir procedūros, kurios padeda projektų vadovams
apibrėžti projektų ribas. Projekto apimties planas būtent ir padeda nustatyti projekto ribas.
Prastai apibrėžta projekto apimtis gali būti neteisingų galutinių laiko terminų nustatymo, išlaidų
viršijimo ir klientų nepasitenkinimo priežastis. Geras projekto apimties planas reiškia, kad dėl
projektui įvykdyti reikalingų darbų yra susitarta su akcininkais ir tai yra aiškiai dokumentuota.
Apimties planavimo metu gimsta detalės, kuriomis papildomi inicijavimo etape parengti
projekto nuostatai. Tai darbų, reikalingų projekto nuostatuose nurodytiems tikslams pasiekti,
įvardinimas.
Priklausomai nuo projekto nuostatų detalumo, apimties planavimo metu gali būti
atliekama smulki numatomo sukurti produkto ir projekto naudos / kainos santykio analizė,
siūlomi alternatyvūs sprendimai. Dalis apimties planavimo darbo gali jau būti atlikta projekto
inicijavimo metu, rengiant projekto nuostatus.
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
38
Projekto apimties planavimo procesas gali būti iteracinis, ne visai nuoseklus, žingsniai
persidengiantys. Nežiūrint nuoseklumo, planavimo eigoje turi būti sukurtas projekto apimties
aprašas, apimties valdymo planas ir suskaidytų darbų lentelė (WBS). Apžvelkime plačiau
kiekvieną iš jų.
3.1.1. Projekto apimties aprašas
Projekto apimties aprašo rengimo metu dokumentuojami susitarimai tarp projekto
vadovo ir akcininkų dėl projekto rezultatų. Aprašas yra įeities duomenys projekto darbų sąrašui
apibrėžti ir bus atramos taškas nagrinėjant siūlymus kažką keisti projekte. Bet kuris pagrindinis
projekto rezultatas, savybė ar funkcija, kurie nebuvo užfiksuoti projekto apimties apraše,
iššaukia projekto keitimus. Dažniausiai projekto apimties aprašą sudaro tokios dalys:
- projekto poreikis;
- projekto reikalavimai;
- pagrindiniai laukiami projekto rezultatai;
- sėkmės kriterijai;
- projekto trukmės ir kainos metmenys;
- prielaidos;
- apribojimai.
Trumpai apžvelkime kiekvieną iš šių dalių.
Projekto poreikis. Šioje projekto apimties aprašo dalyje nurodomos priežastys, dėl ko yra
vykdomas projektas ir kokius organizacijos poreikius numatoma juo patenkinti. Juk turi būti
aiškios prašymo pradėti projektą priežastys. Ar juo bus kuriamas naujas produktas išorės
užsakovui, ar bus kuriama nauja sistema vidinėms organizacijos reikmėms patenkinti, ar yra
teisinis pagrindimas. Projekto poreikio dalyje išdėstomi prašymo pradėti projektą argumentai.
Labai svarbu, kad visi teisės aktai, kuriais yra paremtas prašymas pradėti projektą, būtų
išvardinti šioje projekto apimties aprašo dalyje. Tai priverčia suklusti kiekvieną apimties aprašo
skaitytoją dėl projekto būtinumo.
Projekto reikalavimai. Projekto reikalavimuose aprašomos numatomo kurti produkto
savybės ir funkcijos, akcentuojama, kas naujo bus sukurtame produkte. Tai papildyti, detalizuoti
reikalavimų metmenys, kurie buvo projekto nuostatuose (žiūr. 2.1.1, 2.1.3 skyrius). Projekto
reikalavimuose gali būti naudinga išvardinti ne vien numatomo kurti produkto savybes ir
funkcijas, bet ir kitas, jei nuo to reikalavimai tampa aiškesni. Tam gali būti panaudoti anksčiau
vykdytų projektų aprašuose esantys reikalavimai, atlikus juose pakeitimus ar patobulinimus
naujai gautos informacijos pagrindu.
Pagrindiniai laukiami projekto rezultatai. Projekto apimties aprašo pagrindinių laukiamų
rezultatų dalyje pateikiama suvestinė lentelė rezultatų, kurie turi būti gauti kuriant produktą.
Sudaryti svarbiausių rezultatų sąrašą gali būti lengva, jei turėsime galvoje tik juos. Tačiau
vardinant drauge visus projekto rezultatus, nereikėtų pamiršti galutinio produkto visumos. Pvz.,
galutinis rezultatas gali būti organizacijos pardavimų agentams skirta taikomoji programa. Bet
šalia taikomosios programos reikalinga ir programos naudojimo instrukcija (naudotojo vadovas),
naudotojų mokymas, pagalbos teikimo priemonės, kt.
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
39
Sėkmės kriterijai. Kaip sėkmės kriterijai projekto apimties apraše turi būti nurodomi
veiklos srities, kurios reikmėms yra vykdomas projektas, pagerėjimo rezultatai. Šių rezultatų
pasiekimo laipsnį turi būti galima įvertinti kiekybiškai. Tai gali būti tokie kriterijai, kaip bendras
pajamų padidėjimas, darbo našumo padidėjimas, atitikimas teisės aktams, darbuotojų kiekio
sumažėjimas. Ši apimties aprašo dalis yra svarbi tuo, kad ji gali būti panaudota kaip projekto
vertinimo instrumentas pabaigus jį. Projekto akcininkai, remdamiesi šia aprašo dalimi, gali
palyginti tikrąjį projekto poveikį jų veiklai su planuotu. Sėkmės kriterijai turėtų būti apibrėžiami
taip, kad atitikimą jiems galima būtų išmatuoti. Tokie kriterijai, kaip, pvz., „tapome pirmaujantys“
arba „teikiame aukšto lygio paslaugas“ skamba gražiai, bet nėra pamatuojami. Kur kas geriau
nurodyti pardavimų kiekio skaičių, pajamų dydį arba klientų gaištamo laiko trukmę, ką galima
išmatuoti ir palyginti su tokiais pat duomenimis, buvusiais iki projekto įvykdymo. Sėkmės
kriterijų nurodymo prasmė yra ta, kad žmonės turėtų matavimo būdus vertindami, ar projektas
buvo sėkmingas ar ne.
Projekto užbaigimo kriterijus. Projekto užbaigimo kriterijus reikalingas tam, kad galėtume
nuspręsti, kada laikysime projektą užbaigtu. Pvz., projekto apimties apraše gali būti reikalaujama,
kad pridavimo metu sistema turi veikti be jokių priekaištų. Arba, gali būti toks reikalavimas, kad
projektas bus laikomas užbaigtu, jei bandomojo periodo (mėnesio ar kelių) bėgyje visi sistemos
komponentai veiks be sutrikimų.
Projekto trukmės ir kainos metmenys. Šiame projekto apimties aprašo skyriuje nurodomi
laiko, kurio reikės visiems projekto darbams atlikti, ir dabartinės projekto kainos metmenys. Tai
labai svarbūs duomenys, kurie gaunami remiantis panašiems jau vykdytiems projektams realiai
sugaištu laiku ir patirtomis išlaidomis arba laikantis kurio nors į projektą įtraukto ir patirtį
panašiuose darbuose turinčio eksperto nuomonės. Tai nėra tikslūs įverčiai. Gali būti nurodomas
projekto trukmės ir kainos intervalas, atspindintis geriausią, blogiausią ir labiausiai tikėtiną
reikšmę.
Jeigu reikia nurodyti projekto pabaigos datą, o tiksliam jos įvertinimui jūs neturite
pakankamai duomenų, nurodykite mėnesį ar metų ketvirtį, bet ne tikslią datą. Nurodydami
projekto pabaigos datą, visada nurodykite ir numatomą projekto pradžios datą, nes gali atsitikti
taip, kad vėluojant pradėti projektą jo vykdymui liks mažiau laiko.
Projekto trukmės ir kainos metmenų tikslumu, gautu projekto apimties planavimo
laikotarpiu, gali būti abejojama. Tačiau projekto vadovas neturėtų sakyti, pvz., kad metmenimis
pasitiki 90%. Sponsorius ar klientai, žinoma, norėtų girdėti tokius patikinimus. Projekto apimties
planavimo laikotarpiu gauti kainos metmenys būna nukrypę iki 75% nuo tikrosios projekto
kainos jo pabaigoje. Tokia yra IT projektų realybė (kitų sričių projektuose taip nėra).
Prielaidos. Prielaida – tai veiksmas, sąlygos ar įvykis, kurio tikimasi. Prielaidų
problema yra ta, kad jos nėra vienodos visiems projekto grupės nariams ar akcininkams.
Prielaidos turi būti išplatintos, dėl jų susitarta ir dokumentuota. Pvz., kuriant kažkokią sistemą
projekto vykdytojai gali manyti, kad ji bus diegiama pas užsakovą jau esančiuose kompiuteriuose,
o užsakovas gali galvoti, kad ir kompiuteriai yra projekto dalis, kad kartu su programomis bus
pateikti ir kompiuteriai.
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
40
Apribojimai. Yra dviejų tipų apribojimai: taikomi visam projektui ir specifiniai projekto
apribojimai. Su pirmojo tipo apribojimais, kurie susiję su laiku, kaina, kokybe ir/ar apimtim,
susiduriama beveik kiekviename projekte. Kiekviename projekte reiškiasi mažiausiai vienas iš
šių apribojimų. Jei jūs kuriate produktą siaurai rinkai, projektui gaištamas laikas gali būti stipriai
ribojantis veiksnys. Jei turite fiksuoto dydžio biudžetą, pinigai bus ribojantis veiksnys. Jei darbus
riboja kartu ir laikas, ir pinigai, tuomet gali nukentėti kokybė. Projekto apimtį taip pat gali riboti
kartu ir laikas, ir pinigai. Kai projekto eigoje sumanoma keisti projekto apimtį, apimtis tampa
ribojančiu veiksniu (žymiai keisti apimties negalėsime), nes tai iššaukia laiko, kainos arba
kokybės pokyčius.
Antrojo tipo apribojimai yra specifiniai. Jie gali būti susiję su projekto darbų grafiku,
ankstesniais susitarimais dėl žmoniškųjų išteklių, sistemos testavimo galimybėmis.
Su apribojimų „stumdymu“ projekto vadovas susiduria viso projekto metu. Kai projekto
planavimo etape nustatomi laiko, kainos, apimties, kokybės apribojimai, reikia susitikti su
akcininkų grupe ir aptarti apribojimų poveikį projektui. Projektų vadovas turi žinoti, kokiems
apribojimams klientai teikia prioritetą, ir būti pasirengęs tinkamai reaguoti į juos. Pvz., žinodami
projekto planavimo etape numatytą kainą, klientai gali prašyti mažinti funkcionalumą, mažinti
apimtį, peržiūrėti kainą ir nustatyti jiems labiau priimtiną.
Taigi, projekto apimties apraše yra daug svarbios projekto informacijos.
Apimties aprašo peržiūra ir pritarimas jam
Baigus rengti projekto apimties aprašą, šaukiamas visos projekto grupės susirinkimas ir
išsiaiškinama, ar visi nariai pritaria aprašo nuostatoms, ar neliko neišspręstų klausimų. Pašalinus
visus nesutarimus, su aprašu supažindinami visi akcininkai ir reikia gauti sponsoriaus ir klientų
patvirtinimą. Priklausomai nuo jūsų organizacijoje esančių taisyklių, gali reikėti ir kitokių
patvirtinimų.
Jeigu sponsorius ir klientai peržiūros metu daro kokius nors projekto apimties pakeitimus,
jūs turėtumėte šaukti dar vieną projekto grupės susirinkimą ir apsvarstyti šių pakeitimų poveikį
projektui. Projekto vadovo viena iš svarbiausių pareigų yra projekto grupės narių informavimas.
Apie komunikavimą su grupe plačiau rašoma 9.2 skyriuje.
3.1.2. Projekto apimties valdymo planas
Apimties valdymo plane aprašomos procedūros, kurių reikės laikytis norint daryti bet
kokius projekto apimties pakeitimus viso jo gyvavimo laikotarpiu. Apimties valdymas yra
sudėtingas procesas, apimantis visų keitimų įvardinimą, dokumentavimą, valdymą, įvertinimą,
kontrolę ir patvirtinimą.
Apimties valdymo procesui, mažiausiai, reikalingi:
- standartinės formos prašymas keitimams daryti;
- prašomo keitimo poveikio kitiems projekto elementams (kainai, darbų grafikui,
kokybei) analizė;
- prašymo priėmimo arba atmetimo procedūra;
- akcininkų informavimo apie keitimus planas;
- projekto bendrojo (viso) plano koregavimo būdas.
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
41
3.1.3. Projekto suskaidytų darbų lentelė
Projekto suskaidytų darbų lentelėje (WBS–Work Breakdown Structure) nurodomi
pagrindiniai projekto darbai, suskaidyti į smulkesnes, lengviau valdomas dalis. WBS skaidomas į
keletą lygių tol, kad lygio darbų įvykdymo laipsnį galima būtų išmatuoti ir būtų aišku, kokio
finansavimo jiems reikėtų. Kiekvieno žemesnio lygmens darbų rezultatai naudojami aukštesnio
lygmens darbe. Žemiausią WBS lygmenį sudaro darbų paketas (work package). WBS‘e turi būti
visi darbai, kurių reikia projektui įvykdyti. Bet koks WBS‘e nenurodytas darbas laikomas
nereikalingu projekte. WBS yra vertingiausias planavimo rezultatas. WBS yra projekto trukmės ir
kainos vertinimo, reikiamų išteklių skyrimo pagrindas.
WBS struktūra. WBS lentelėje darbai turi turėti pavadinimus, gali būti ir numeruojami.
WBS su numeruojamais darbais parodytas 3.1 pav.
WBS lentelėje darbai skaidomi į lygius, kur 1 lygis – tai pats projektas (jo pavadinimas). 2
lygio darbai susiję su pagrindiniais laukiamais rezultatais, kurie išvardinti projekto apimties
apraše. Šis lygis parodo projekto etapus, į projektą įtrauktus organizacijos departamentus ar
geografinius dalykus.
WBS rengimo gairės. WBS sudarymas kartais gali atrodyti labai sunkus, neįveikiamas
darbas. Dauguma žmonių, kurie susiduria su šia užduotim, imasi didesnio darbo, nei jie gali
atlikti. Kai jūs pradedate siekiamus projekto rezultatus transformuoti į darbus, yra pagunda
dėlioti darbus iš eilės, vertinti jų trukmę. Elgiantis taip, dažniausiai pamirštami (praleidžiami)
svarbūs siekiami rezultatai arba sudaroma neteisinga darbų eilė. Kad nebūtų neproduktyviai
gaištamas laikas, siūloma vadovautis čia pateikiamomis gairėmis.
Pasitelkite išmanančius žmones. Nesistenkite sudaryti WBS patys, siekdami sutaupyti
laiko.
Visus 2 lygio punktus apgalvokite kruopščiai. Turime suprasti, kad viso projekto siekiamų
rezultatų metmenys (high-level deliverables) atspindimi šiame lygyje. Kol neįvardinti siekiami
rezultatai, tol nereikėtų pradėti jų skaidyti į smulkesnius komponentus. Visą laiką turi būti
remiamasi projekto apimties aprašu.
Projektas
2. Darbų grupė 3. Darbų grupė
1.1. Darbas
1.2. Darbas
1.3. Darbas
2.1. Darbas
2.2. Darbas
3.1. Darbas
3.2. Darbas
3.3. Darbas 2.2.1. Darbelis
2.2.2. Darbelis
1 lygis
................
2 lygis
................
3 lygis
................
t. t.
1. Darbų grupė
3.1 pav. WBS su numeruojamais darbais
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
42
Kiekvienas žemesnio lygio punktas yra aukščiau esančio lygio komponentas. Surašykime
visus darbus ir tęskime jų skaidymą į komponentus. Įsitikinkime, kad jau pasiekėme tokį lygį, kai
grupės nariai jau yra patenkinti ir kad gali būti rengiami projekto trukmės, kainos ir reikiamų
išteklių įverčiai. Darbų eilės nustatymas, išteklių numatymas, projekto trukmės ir kainos įverčių
gavimas yra atskiros veiklos, kurios vykdomos vėliau, kai baigiama rengti WBS.
Nekurkime pernelyg susmulkintų darbų lentelės. Darbų skaidymas yra pakankamo lygio,
kai jau lengvai galima numatyti konkrečiam darbui reikalingus išteklius, daryti jo įverčius ir
įvardinti siekiamą rezultatą. Kadangi WBS yra vėliau sudaromo darbų grafiko pagrindas,
nenusileiskime iki tokio lygio, kad nebegalėtume kontroliuoti tokių darbų. Pvz., jei projekte reikia
pirkti kažkokias medžiagas, WBS‘e pakanka nurodyti darbą „Medžiagų pirkimas“ ir nereikia
smulkintis iki to, kiek ir kokias medžiagas pirkti.
Patartina naudoti 8/80 taisyklę. Ji sako, kad darbai neturėtų būti trumpesni kaip 8
valandos (viena darbo diena) ir ilgesni kaip 80 valandų.
Kiekvieną punktą skaidykime į tinkamą lygių kiekį.
Naudokime skaitinius numerius kiekvienam WBS punktui. Pvz., 1., 1.1., 1.1.1.
WBS nauda. WBS yra vertingiausias planavimo rezultatas. WBS yra projekto trukmės ir
kainos vertinimo, reikalingų išteklių skyrimo pagrindas. Tai puikus instrumentas, padedantis
bendrauti projekto grupės nariams, bendrauti su užsakovu, stebėti projekto eigą, skiriamus
išteklius, t. t. Gerai parengta WBS gali pasitarnauti kaip šablonas kitiems projektams. Detali WBS
ne tik padeda išvengti neapsižiūrėjimų (užmiršimų), bet ir padeda kontroliuoti daromus projekto
apimties keitimus. Žinoma, tokiais atvejais tenka koreguoti ir WBS.
3.2. IT projekto apimtį įtakojantys veiksniai
Projektų vadovai neturėtų labai nukrypti nuo WBS‘e išvardintų darbų vykdymo. Tačiau
projektus vykdančiose IT įmonėse gali atsirasti priežasčių, verčiančių jas žymiai nukrypti nuo
originalios projekto apimties. Tos priežastys ar aplinkybės neturėtų būti pamestos iš akiračio
projekto apimties vertinimo ir planavimo metu. Panagrinėkime kai kurias iš jų.
3.2.1. IT įmonės dydis
IT įmonės dydis turi tiesioginę įtaką projekto apimčiai. Jei jūsų įmonėje yra tik keletas
darbuotojų, kurie nuolatos dirba tai viename, tai kitame projekte, tai visiškai suprantama, kad
naujo projekto apimtis smarkiai priklausys nuo darbuotojų užimtumo. Pagrindinis ribojantis
veiksnys yra žmoniškieji ištekliai. Jei įmonėje vykdomi keli projektai, mažesnį prioritetą turintys
nustumiami į antrą planą. IT projektuose, kuriuos vykdo minimalus darbuotojų kiekis, dažnai
prastai suformuluojami reikalavimai, prastai parengiama suskaidytų darbų lentelė (WBS), retai
kada prisimenamas kuriamų programų dokumentavimo klausimas. Kad to nebūtų, reikėtų
mažinti projekto apimtį.
3.2.2. Projekto siekiamų rezultatų apibrėžimo tikslumas
Tiksliai apibrėžti projekto siekiamus rezultatus, kuriems gauti yra aiškūs reikalavimai,
nėra sunku. Bet apibrėžti mažai kam suprantamus rezultatus gali būti sunku. Pvz., jūs turite
projektą, kuriuo esamą sistemą reikia pakeisti tobulesne. Kokie bus laukiami projekto rezultatai?
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
43
Tarkime, tai bus naujas serveris ir, tikriausiai, nauja programinė įranga. Tačiau nereikėtų
pamiršti ir kitų dalykų. Senus duomenis reikės konvertuoti į naują formatą, reikės parengti naują
naudotojo instrukciją, apmokyti žmones, kt. O tam juk reikia ir laiko, ir lėšų. Taigi, būtina matyti
siekiamų rezultatų visumą. Netiksliai apibrėžti siekiami rezultatai atsiliepia projekto apimties
kokybei, dėl ko projekto vykdytojas bus priverstas nukrypti nuo WBS‘e numatytų darbų.
3.2.3. Darbo su užsakovu aplinkybės
Projekto vykdytojas dažniausiai nėra užsakovo organizacijos narys, o tik aptarnauja jį. Dėl
to jis negali turėti didelės įtakos projekto apimčiai. Įsivaizduokime, kad užsakovas prarado
interesą projektu pusiaukelėje. Kadangi užsakovo organizacijos vadovas yra vienas iš projekto
sponsorių, jūs, tikriausiai, negalėsite patenkinamai atlikti darbų be jo paramos.
Arba, įsivaizduokime užsakovą, kuris dėl didelio savo užimtumo nepajėgia teikti projekto
vykdytojams reikiamos pagalbos, kad kuriamas produktas atitiktų jo poreikius. Sunku tikėtis, kad
projekto vykdytojai žinotų užsakovo poreikius, jei negauna duomenų iš tų, kurie tą darbą dirba
kasdieną. Deja, yra nemažai taip vykdomų projektų, todėl jų rezultatai būna prasti.
Būna, kad užsakovas pats ieško gatavos (COTS) programinės įrangos, randa jo manymu
jam tinkančią, tačiau paskutinę minutę persigalvoja ir kreipiasi į jus su prašymu sukurti naują
programą. Tokio užsakovo supratimas apie projekto apimtį gali labai skirtis nuo jūsiškio.
Tokioms arba panašioms situacijoms valdyti, jūs galite dėti atitinkamas nuorodas į
projekto apimties aprašo prielaidų skyrių. Pvz., „Daroma prielaida, kad užsakovas skiria projekto
grupei vieną savo atstovą, kuris dirbs visą darbo dieną pirmus 30% projekto laiko“.
3.2.4. Sėkmės kriterijų apibrėžimo sunkumas
Tarkime, jūs kuriate internetinę el. komercijos programinę įrangą. Vienas iš jos
reikalavimų yra aukštas transakcijų saugumas. Kaip įvertinti tokio reikalavimo įgyvendinimo lygį
ir įrodyti, kad sistema yra saugi? Dar daugiau, kas atsitinka, kai sistemos kūrimo įkarštyje
operacinės sistemos kūrėjas atskleidžia jos saugumo spragas, kurios turi būti pašalintos? Kokią
įtaką tokios naujienos turi jūsų kuriamai sistemai? Ar spragų užlopymas turės įtakos jūsų
sistemos darbui?
Panašūs klausimai kyla, kai reikia rengti metines ataskaitas vadovybei. Kartais sunku būna
rasti matą savo veiklos dydžiui apibūdinti. Tačiau jūs turite tiksliai nurodyti realias priežastis,
kodėl jūs vykdote projektą, kaip užsakovas tikisi panaudoti gautus rezultatus.
3.2.5. Pašaliniai ar neišsiaiškinti elementai
Didžiausios įtakos projekto apimties įverčio tikslumui turi neišsiaiškinti užsakovo veiklos
procesai, kai užsakovas neatskleidžia (ne iš piktos valios) visų savo organizacijos
automatizavimo elementų, transakcijų su kitomis sistemomis, turimų pagalbinių duomenų bazių,
programinės įrangos ar panašiai.
3.2.6. Santykiai su tiekėjais
Naudojantis tiekėjų paslaugomis, nepamirškime, kad jie gali turėti ir kitų užsakymų. Tie
užsakymai iš jų gali pareikalauti laiko, ir jie atidėlios jūsų projekto darbus. Dėl to gali nukentėti
jūsų projekto apimties įverčiai.
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
44
3.2.7. Projekto grupės narių pasitraukimas
Pagrindinio grupės nario pasitraukimas gali turėti žymų poveikį projekto apimčiai (grupė
kažko nebesugebės padaryti per numatytą laiką ar už sutartą kainą). Kai WBS užduotys būna
išdalintos, ar rasime, kas pakeistų išėjusį darbuotoją?
Vėlgi, projekto apimties aprašo prielaidų dalyje reikėtų nurodyti, kad projekto apimtis
numatyta, tikintis, kad reikiamos kvalifikacijos specialistai bus rasti.
3.2.8. Projekto darbų dalinimas keliems IT padaliniams
Didelėse organizacijose gali būti keletas IT padalinių, aptarnaujančių skirtingas veiklos
sritis. Pvz., organizacijoje gamybos departamentas gali būti toks didelis, kad turi savo IT padalinį.
Taip pat gali būti su teisės departamentu. O jūs vadovaujate dar kitam IT padaliniui. Tarkime, jūs
vykdote projektą, kurio pagrindiniai rezultatai reikalingi visiems organizacijos departamentams.
Jums reikalinga kitų IT padalinių pagalba, kad galėtumėte patenkinti visų sistemos naudotojų
poreikius.
Tokiais atvejais projekto valdymas įgyja politinį diplomatinį atspalvį, ir jūs turite įtikinti IT
padalinius bendradarbiauti, nors šiaip jie nedirba kartu. Suprantama, kad projekto apimčiai
įtakos turės kiekvieno IT padalinio prioritetai projekto atžvilgiu.
3.2.9. Testuojami elementai reikalauja gero apibrėžimo
Daugumos IT projektų elementai yra testuojami, kad įsitikintume, ar jie atitinka jiems
keliamus reikalavimus. Yra trys testavimo atvejai: atskiro vieneto testavimas, integracinis
testavimas ir priėmimo testavimas.
Atskiro vieneto testavimas. Tai sistemos modulio ar komponento, įvardinto bendrame
rezultatų sąraše, testavimas. Pvz., serverio administratorius, instaliuodamas serverį, turi atlikti
daug testų, kad įsitikintų, jog serveris dirba taip, kaip reikia. Programuotojas, užbaigę modulį, turi
leisti įvairius testus, kad įsitikintų, jog modulis dirba taip, kaip tikėtasi. Atskiro vieneto
testavimas paprastai suprantamas kaip vieno žmogaus atliekamas vieno kokio nors elemento
testavimas. Tai nėra griežta taisyklė, o tik aiškinimas, kas yra atskiro vieneto testavimas.
Integracinis testavimas. Šiuo testavimu tikrinamas tarpusavyje sujungtų elementų
visumos veikimas. Pvz., turite keletą serverių, kurie jau yra instaliuoti, tačiau jie turi veikti
drauge, kaip subalansuotų Web serverių masyvas. Šie serveriai testuojami kaip visuma, o ne kaip
atskiri vienetai. Programuotojų komanda gali testuoti keletą modulių, kurie sujungti drauge
sudaro užbaigtą programinį elementą.
Priėmimo testavimas. Tai galutinio produkto, t. y. visos sukurtos sistemos testavimas,
kurį atlieka paskirti naudotojai. Tai svarbiausias iš visų testavimų, nes jis parodo, kaip projekto
grupė atliko savo darbą, kaip naudotojams sekasi sąveikauti su sistema. Reikia būti
pasirengusiems labai griežtam jūsų sukurto produkto vertinimui.
Jei bet kuriame testavimo žingsnyje kas nors neveikia taip, kaip turėtų, atsakingi už tai
darbuotojai, žinoma, turi ištaisyti klaidą. Rimtos testavimo klaidos be abejo veda prie to, kad
reikės gaišti laiką ir leisti pinigus, stengiantis išspręsti problemą. Dėl to projektų vadovai pritaria
idėjai, kad sukurtą produktą turi tikrinti ne vienas, o keli patikimi asmenys. Taip jie būtų tikri, jog
atliktas darbas atitinka įvertinimą.
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
45
4. DARBŲ GRAFIKO PLANAVIMAS
Turint jau parengtą projekto apimties aprašą, apimties valdymo planą ir suskaidytų darbų
lentelę (WBS), planavimo etape toliau reikia rengti projekto darbų grafiką. Darbų grafike
nurodoma planuojama darbų pradžia ir pabaiga. Geram darbų grafikui parengti sugaištama
nemažai laiko. Būtina suvokti, kokių žinių reikia, kad parengtume gerą darbų grafiką. Visi darbai
turi būti įvardinti, sudėlioti reikiama eilės tvarka, kažkam paskirti, įvertinti laikai jiems atlikti.
Taip gimsta bendras projekto darbų grafikas.
Darbų grafikas projekto vadovui yra reikalingas nuolatos, kol nebus baigtas projektas.
Laikydamasis grafiko, vadovas reguliariai informuoja akcininkus apie projekto eigą.
Projekto darbų grafiko rengimo pagrindas yra WBS, kuri buvo sudaryta projekto apimties
planavimo metu. Faktiškai tuomet buvo apibrėžti darbai. Apibrėžiant juos buvo remiamasi
numatytais projekto galutiniais ir tarpiniais rezultatais.
Prisimenant WBS rengimą, atkreiptinas dėmesys į tai, kad darbų sąrašo smulkinimas, pvz.,
vardijant net 15 min. trukmės darbelius, negarantuoja sėkmingos projekto pabaigos, ir to
nereikėtų daryti. Tai tik apsunkina jų valdymą. Patartina naudoti 8/80 taisyklę. Ji sako, kad
darbai neturėtų būti trumpesni kaip 8 valandos (viena darbo diena) ir ilgesni kaip 80 valandų.
Pagrindinis darbų skaidymo tikslas yra įvardinti visas užduotis tokiu lygmeniu, kad galima
būtų lengvai įvertinti jų atlikimo trukmę ir kainą ir kad nesunku būtų juos kontroliuoti.
4.1. Darbų eilės tvarka
Projekto vadovui būtų lengva, jei visus projekto darbus būtų galima vykdyti lygiagrečiai.
Reikėtų tik kiekvienam projekto grupės nariui nurodyti darbų sąrašą, už kuriuos jis yra
atsakingas, ir kuriuos atlikęs jis galėtų grįžti prie savo ankstesnių pareigų organizacijoje.
Kiekvienas grupės narys turėtų įvertinti laiką, reikalingą jam pavestiems darbams atlikti. Tuomet
viso projekto pabaigos terminas priklausytų nuo ilgiausiai planuojančio dirbti grupės nario. Deja,
numatyti projekto pabaigos terminą nėra taip paprasta. Dalis projekto darbų negali būti pradėti
tol, kol nebus baigti kai kurie kiti darbai. Projekto grupė turi įvardinti darbų priklausomybę ir
nurodyti sąryšio pobūdį tarp dviejų darbų.
Darbų eilės tvarkos nustatymas yra priklausomybės tarp projekto darbų nustatymo
procesas. Visų pirma įvardinamas priklausomybės tipas, o po to nustatomas priklausomybės
pobūdis tarp dviejų darbų. Naudojant šiuos duomenis gaunamas visų priklausomybių vaizdas.
Pirma apžvelkime darbų priklausomybių tipus, o po to priklausomybių pobūdį.
4.1.1. Darbų priklausomybių tipai
Sudarant projekto darbų eilę, susiduriama su trimis darbų priklausomybės tipais.
Privalomoji priklausomybė atsiranda dėl projekte būtinos darbų sekos. Pvz., ryšio kabelių
tiesimo brigada negali patiesti kabelio, kol kita brigada nebus iškasusi griovio.
Laisvai pasirenkama priklausomybė yra tokia, kuriai atsirasti įtakos turi norimas gauti
darbų grafikas. Pvz., tai gali būti sprendimas vykdyti darbus specifine eilės tvarka, kad ji atitiktų
kolektyve nusistovėjusią tvarką, nors ir galima kita darbų eilės tvarka.
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
46
Išorinė priklausomybė pasireiškia tarp projekte numatyto darbo ir išorinių veiksnių,
turinčių įtakos to darbo atlikimo grafikui. Pvz., naujo serverio paleidimas gali priklausyti nuo to,
kada pardavėjas jį pristatys.
Darbų priklausomybių tipo žinojimas ateityje gali praversti ieškant būdų projekto trukmei
sutrumpinti.
4.1.2. Darbų priklausomybės pobūdis
Nepakanka žinoti, kad tarp dviejų darbų yra priklausomybė. Reikia mokėti atsakyti dar ir į
keletą kitokių klausimų: kokią įtaką priklausomybė daro kiekvieno darbo pradžiai ir pabaigai? Ar
vienas iš darbų turi būti pradėtas anksčiau? Ar galima pradėti kitą darbą, kol nebaigtas pirmasis?
Visi šie klausimai turi įtakos visam darbų grafikui.
Žinant priklausomybę tarp dviejų darbų, reikia nustatyti jos pobūdį (kokią įtaką
priklausomybė daro kiekvienam iš tų dviejų darbų), kad galėtume sudaryti teisingą darbų eilę.
Priklausomybės pobūdžiui paaiškinti įveskime keletą sąvokų.
Pirmuoju darbu (predecessor) vadinkime darbą, kuris iš dviejų priklausomybe susietų
darbų turi būti pradėtas pirma. Antruoju darbu (successor) vadinkime tą, kuris yra susijęs su
pirmuoju.
Galimi keturi pirmojo ir antrojo darbų priklausomybės pobūdžiai. Teisingo pobūdžio tarp
priklausomų darbų nustatymas yra labai svarbus, norint sudaryti tikslų darbų grafiką.
Priklausomybės pobūdis įgalina rikiuoti darbus grafike taip, kad jie būtų atliekami lygiagrečiai
arba kad antrasis būtų atliekamas tik po to, kai bus užbaigtas pirmasis. Klaidingas darbų grafikas
gali sukelti liūdnas pasekmes.
Pabaigos-pradžios priklausomybės pobūdis yra toks, kai antrasis darbas negali būti
pradėtas anksčiau, kol nebus užbaigtas pirmasis. Šio pobūdžio priklausomybės sutinkamos
dažniausiai.
Pradžios-pradžios pobūdžio priklausomybėje antrojo darbo pradžia priklauso nuo
pirmojo darbo pradžios. Tokie darbai gali būti atliekami lygiagrečiai, tačiau jei pirmasis darbas
vėluoja, antrasis negali būti pradėtas. Pvz., sistemos naudotojo instrukcijos rengimas gali būti
pradėtas tuo pačiu metu, kai pradedami rengti sistemos reikalavimai. Jei vėluojama pradėti rengti
reikalavimus, reikia atidėti ir naudotojo instrukcijos rengimą.
Pabaigos-pabaigos pobūdžio priklausomybė yra tokia, kai antrojo darbo pabaiga priklauso
nuo pirmojo darbo pabaigos. Pvz., naujo produkto kūrimas laikomas baigtu, jei yra parengti ir
produkto dokumentai. Jei vėluojama parengti dokumentus, produkto išleidimas atidedamas.
Pirmasis darbas
Antrasis darbas
Pirmasis darbas
Antrasis darbas
Pirmasis darbas
Antrasis darbas
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
47
Pradžios-pabaigos pobūdžio priklausomybė rodo, kad antrojo darbo pabaiga priklauso
nuo pirmojo darbo pradžios. Tokia priklausomybė sutinkama retai. Pvz., techninė priežiūra
negali būti pabaigta, kol nebus pradėta formuoti priežiūros grupė.
Žinodama darbų priklausomybių pobūdžius, projekto grupė gali sudaryti darbų išdėstymo
diagramą.
4.1.3. Darbų išdėstymo diagrama
Darbų išdėstymas PDM diagrama (PDM –Precedence Diagramming Method; kitur AON –
Activity On Node ) yra vienas iš būdų pavaizduoti darbų eilės tvarką (žiūr. 4.1 pav.). Joje darbai
nurodomi stačiakampiuose, o priklausomybės tarp jų - rodyklėmis.
Dar vienas darbų išdėstymo vaizdavimo būdas yra ADM diagrama (ADM – Arrow
Diagramming Method; kitur AOA - Activity On Arrow). Jis yra paprastesnis už PDM ir naudojamas
tik pabaigos-pradžios pobūdžio priklausomybės darbams. Šiame vaizdavimo būde darbai
nurodomi ant rodyklių. 4.2 pav. parodyta darbų išdėstymo ADM diagrama, atitinkanti 4.1 pav.
PDM diagramą.
4.2. Darbų trukmės vertinimas
Darbo trukmės vertinimas - tai reikalingo dienų ar savaičių kiekio darbui atlikti
nustatymas. Tačiau visų pirma patikslinkime trukmės sąvoką.
4.2.1. Trukmės apibrėžimas
Darbo atlikimo trukmė apima bendrąjį kalendorinį laiką (įskaitant laisvadienius ir švenčių
dienas). Jei darbui atlikti reikia 4 darbo dienų, bet jis pradedamas, pvz., ketvirtadienį, tai jo
pabaiga bus kitos savaitės antradienis. Taigi, darbo trukmė bus šešios dienos. Pailiustruokime tai
grafiškai.
Pirmasis darbas
Antrasis darbas
A darbas Pradžia
B darbas C darbas
D darbas
Pabaiga
4.2 pav. Darbų išdėstymo ADM diagrama
A darbas Pradžia B darbas C darbas
D darbas
Pabaiga
4.1 pav. Darbų išdėstymo PDM diagrama
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
48
Darbo trukmė perskirta savaitgaliu: 6 kalendorinės dienos, 4 darbo dienos
ketvirtadienis penktadienis šeštadienis sekmadienis pirmadienis antradienis
Nustatant darbų atlikimo terminą nereikėtų pamiršti laisvadienių, šventinių dienų ir netgi
darbuotojų atostogų.
4.2.2. Trukmės vertinimo būdai
Analogiškasis arba iš viršaus-žemyn būdas. Šis darbų trukmės vertinimo būdas remiasi
anksčiau vykdytų projektų panašiems darbams realiai sugaišto laiko perėmimu. Projekto
planavimo pradinėje stadijoje, kai apie projektą turima informacija yra ribota, tai yra dažniausiai
naudojamas darbų trukmės vertinimo būdas. Tai mažiausio tikslumo būdas, nes du projektai
nebūna tiksliai tokie patys. Todėl yra rizika, kad naujam projektui naudojami ankstesnių projektų
analogiškų darbų trukmės įverčiai gali būti netikslūs.
Analogiškojo vertinimo rezultatų tikslumas yra didžiausias, kai darbų trukmę vertinantis
asmuo yra gerai susipažinęs su dabartiniu ir ankstesniu projektais ir gali suvokti panašių darbų
trukmėms įtaką turinčių veiksnių skirtumus.
Ekspertinis būdas (rėmimasis ekspertų nuomone). Šiuo atveju darbų trukmei nustatyti
pasitelkiami projekto darbus gerai išmanantys žmonės. Tačiau gali kilti klausimas, kur tokius
žmones rasti. Nežinant tokių, reikėtų peržvelgti projekto darbo grupės narių dokumentus, gal
kuris nors yra vykdęs panašų projektą, arba ekspertams rasti prašyti akcininkų pagalbos.
Didžiausias darbų trukmės įverčių tikslumas ekspertinio vertinimo būdu gaunamas tada,
kai ekspertas yra projekto grupės narys, įgijęs patirtį anksčiau. Pastebima, kad vyresnio amžiaus
ekspertų įvertintos trukmės būna trumpesnės nei jaunesnių ekspertų.
Kiekybiškasis trukmės vertinimo būdas. Šis būdas naudojamas tuomet, kai gali būti
išmatuota tam tikro darbų kiekio trukmė ir yra formulės viso darbo trukmei įvertinti. Tam dar
būtina žinoti našumo rodiklį arba turi būti nustatytas įmonės standartas nagrinėjamam darbui.
Pvz., jei 5 km ilgio kabeliui nutiesti tipiniu atveju skiriama 1 diena, tai 50 km reikės 10 dienų.
Šis vertinimo būdas gali būti labai tikslus dažnai pasitaikantiems darbams ir kuriems yra
pakankamai našumo duomenų, kad būtų nustatyti standartiniai rodikliai.
Daugelyje projektų naudojama minėtų būdų darbų trukmei vertinti kombinacija.
Kai jau turime pasirinkę projektui geriausiai tinkantį darbų trukmės vertinimo būdą,
projekto grupės nariams, pasiėmus jau anksčiau parengtą darbų išdėstymo diagramą, belieka
įvertinti kiekvieno darbo trukmę ir pasirengti darbų grafiko sudarymui (žiūr. 4.3 pav.).
Pradžia A darbas:
3 dienos
C darbas:
8 dienos
B darbas:
5 dienos
D darbas:
12 dienų
E darbas:
6 dienos
Pabaiga
4.3 pav. Darbų išdėstymo diagramos pavyzdys
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
49
4.3. Darbų grafiko sudarymas
Darbų grafiko sudarymas – tai pradžios ir pabaigos datų nustatymas kiekvienam projekto
darbui. Grafiko sudarymas yra darbų grafiko planavimo pabaiga. Tikslus darbų grafikas yra toks,
kuriame atsispindi visi darbai, jų atlikimo eilės tvarka ir trukmės. Jis gaunamas sujungus visus
ankstesnius darbų grafiko planavimo rezultatus. Darbų grafikui sudaryti naudojami šie trys būdai
ir priemonės:
- kritinio kelio metodas (CPM – Critical Path Method);
- trukmės suspaudimas;
- projektų valdymo programinė įranga.
Išnagrinėkime juos.
4.3.1. Kritinio kelio metodas
Kritinio kelio metodas (CPM) yra vienas iš matematinio analizavimo būdų. Kritinis kelias
projekto darbų grafike yra ilgiausios darbų sekos kelias projekte, nuo kurio priklauso viso
projekto pabaigos terminas. CPM metodo tikslas yra nustatyti šį kelią. Kritinio kelio darbų
trukmės negali turėti svyravimų. Gali svyruoti (keistis) tik darbo pradžios laikas arba darbui
užbaigti papildomai skiriamo laiko trukmė, tačiau nekeičiant viso projekto pabaigos termino. Jei
kritinio kelio kuris nors darbas nebūna atliktas grafike numatytu laiku ir nėra daromi jokie kiti
grafiko pakeitimai, tai gali turėti poveikį projekto pabaigos terminui.
Be visam projektui užbaigti reikalingo laiko nustatymo CPM padeda gauti ir kitus
naudingus duomenis. Gali prireikti nustatyti darbus, kuriuos galima būtų pradėti vėliau arba
vykdyti ilgiau, negu numatyta grafike, bet nereikėtų keisti viso projekto pabaigos termino. Tokia
informacija gali būti naudinga projekto vadovui, kad jis projekto bėgyje galėtų daugiau dėmesio
skirti tiems darbams, kurie turi didesnę įtaką visam projektui.
CPM metodu darbų grafikas retai sudaromas rankiniu būdu. Tam yra nemažai
programinės įrangos. Kad tokia įranga galėtume pasinaudoti, natūralu, turime turėti projektų
valdymo žinių ir suprasti, ką gi ji daro.
Darbų išdėstymo diagrama ir darbų trukmės įverčiai, kurie gaunami ankstesnių
planavimo etapų metu, yra pagrindiniai duomenys CPM metodui.
Peržiūra pirmyn (forward pass). Kritiniam keliui nustatyti turimoje darbų išdėstymo
diagramoje visų pirma reikia rasti kelius, vedančius nuo projekto pradžios iki pabaigos. Su
kiekvienu diagramoje įvardintu darbu tenka atlikti du skaičiavimus: anksčiausiam pradžios ir
anksčiausiam pabaigos laikui nustatyti.
Anksčiausias pradžios laikas yra darbo pradžios laikas, kada jis gali būti pradėtas
anksčiausiai. Darbų išdėstymo diagramoje pirmo nurodyto darbo anksčiausias pradžios laikas
yra 0. Prie šio laiko pridėjus darbui atlikti reikalingą laiką, gaunamas to darbo anksčiausias
pabaigos laikas.
4.3 pav. parodytos diagramos A darbo anksčiausias pradžios laikas yra 0. Prie šio laiko
pridėjus šiam darbui atlikti reikalingą trukmę (3 dienos) gausime jo anksčiausią pabaigos laiką
lygų 3. Pastarasis laikas tampa su A darbu priklausomybe susieto B darbo anksčiausiu pradžios
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
50
laiku. Tęsiant skaičiavimus gaunami visų diagramos darbų anksčiausi pradžios ir anksčiausi
pabaigos laikai (žiūr. 4.1 lentelę).
4.1 lentelė. Peržiūros pirmyn iliustracija remiantis 4.3 pav. darbų diagrama
Darbas Anksčiausias pradžios laikas Anksčiausias pabaigos laikas
A 0 3
B 3 8
C 3 11
D 8 20
E 11 17
Šių peržiūros pirmyn skaičiavimų rezultate gavome, kad visas projektas gali būti baigtas
per 20 dienų.
Peržiūra atgal (backward pass). Kitas kritinio kelio nustatymo žingsnis yra peržiūra atgal.
Šiame žingsnyje darbų išdėstymo diagramos analizė pradedama nuo galo ir einama link pradžios.
Tam reikalingi taip pat du skaičiavimai: vėliausiems darbų pradžios ir pabaigos laikams nustatyti.
Vėliausias pabaigos laikas yra laikas, kada darbas gali būti užbaigtas vėliausiai. Vėliausias
pradžios laikas yra laikas, kada darbas gali būti pradėtas vėliausiai.
4.3 pav. darbų išdėstymo diagramoje D darbas yra paskutinis. Vėliausiai jis turi būti
užbaigtas po 20 dienų. Vėliausias šio darbo pradžios laikas gaunamas iš pabaigos laiko atėmus
darbo trukmės laiką ir yra lygus 8 dienoms. Vėliausias D darbo pradžios laikas yra su juo
priklausomybe susieto B darbo vėliausias pabaigos laikas. Tęsiant skaičiavimus gaunami visų
diagramos darbų vėliausi pradžios ir vėliausi pabaigos laikai (žiūr. 4.2 lentelę).
4.2 lentelė. Peržiūros atgal iliustracija remiantis 4.3 pav. darbų diagrama
Darbas Vėliausias pradžios laikas Vėliausias pabaigos laikas
A 0 3
B 3 8
C 6 14
D 8 20
E 14 20
Svyravimų dydis (float). Paskutinis projekto darbų grafiko kritinio kelio nustatymo
žingsnis yra kiekvieno darbo pradžios ir pabaigos terminų svyravimų dydžio nustatymas.
Svyravimų dydis gaunamas radus skirtumą tarp vėliausio ir anksčiausio darbo pradžios laikų
arba tarp vėliausio ir anksčiausio darbo pabaigos laikų. Naudodami 4.1 ir 4.2 lentelių rezultatus
gauname darbų pradžios ir pabaigos svyravimų dydžius, kurie pateikiami 4.3 lentelėje. Pvz., A
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
51
darbo anksčiausias ir vėliausias pabaigos laikai yra 3 dienos, todėl šio darbo pabaigos laikas
negali svyruoti, nes svyravimo dydis lygus 0.
4.3 lentelė. Darbų laiko svyravimo dydžio iliustracija
remiantis 4.3 pav. darbų diagrama
Darbas Laiko svyravimo dydis
A 0
B 0
C 3
D 0
E 3
Dabar jau esame pasirengę apibrėžti kritinį kelią. Prisiminkime, kad kritinio kelio darbų
trukmės negali turėti svyravimų. 4.3 pav. pateikto pavyzdžio C ir E darbų pradžios ir pabaigos
laikai gali svyruoti, todėl jie neturi būti kritiniame kelyje. Kritinį kelią sudaro A, B ir D darbai, nes
jų pradžios ir pabaigos laikų svyravimai lygūs 0. Jei bet kuris kritinio kelio darbas nepradedamas
laiku arba vykdomas ilgiau, visas projektas gali būti nebaigtas numatytu laiku. Todėl projekto
eigoje turėtume skirti ypatingą dėmesį kritinio kelio darbams.
Tačiau gyvenime pasitaiko atvejai, kai darbų išdėstymo diagrama, apskaičiuotas kritinis
kelias ir nustatyta projekto trukmė yra nepriimtini projekto akcininkams arba neatitinka teisės
aktų reikalavimų. Projekto vadovui atsidūrus tokioje situacijoje, tenka naudoti projektų trukmės
suspaudimo būdus.
Trukmės suspaudimas. Darbų grafiko trukmės suspaudimas atliekamas tada, kai ji yra per
ilga ir neatitinka numatytos projekto pabaigos datos. Yra du trukmės suspaudimo būdai. Vienas iš
jų yra toks, kai projektui papildomai skiriama daugiau išteklių (pvz., darbuotojų). Tai įgalina
sutrumpinti grafiką, bet pareikalauja daugiau lėšų. Čia taip pat reikėtų žinoti, kad padvigubinus
išteklius, darbo trukmės sutrumpinti dvigubai neįmanoma.
Kitas grafiko trukmės suspaudimo būdas – lygiagretus darbų atlikimas, kurie normaliai
būtų atliekami nuosekliai. Naudojant šį būdą reikia būti ypač atsargiems, tokį žingsnį gerai
apsvarstyti su projekto darbo grupe, dokumentuoti, informuoti akcininkus. Gali nukentėti
projekto kokybė.
Įrankis - projektų valdymo programinė įranga
Projektų valdymui skirta programinė įranga gali padėti sutaupyti daug laiko. Darbų
apibrėžimas, darbų išdėstymas eilės tvarka, projekto darbų grafiko sudarymas gali būti atliekami
naudojant projektų valdymo programinę įrangą (pvz., Microsoft Project).
4.3.2. Projekto etapai
Priklausomai nuo jūsų organizacijoje naudojamų metodų, egzistuojančių vidaus taisyklių,
projekto darbų grafike gali reikėti nurodyti etapus (milestones). Etapai atspindi pagrindinius
projekto gyvavimo ciklo įvykius. Jų datos nurodo, kada turi būti gauti svarbūs projekto rezultatai.
Kai kuriose metodologijose etapai atspindi vienos projekto fazės pabaigą ir kitos pradžią.
Projektų darbų grafikuose nustatant etapus labai svarbu, kad:
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
52
- etapų pabaigos laikas būtų gerai apgalvotas, o atliekamų darbų prasme jie būtų
vienareikšmiai. Neturėtų likti argumentų pasiteisinimams, kad etape buvo neįmanoma
kažko padaryti;
- etapų pabaigoje darbai turi būti vertinami tik taip: atlikti arba neatlikti. Visuose
etapuose įvardyti darbai turi būti atlikti 100 proc.
4.3.3. Darbų grafiko kontroliniai taškai
Kai projekto darbų grafikas jau būna padalintas į etapus, tuomet nustatomi dar ir
kontroliniai taškai (checkpoints), kuriuose nurodoma, kas turėtų būti padaryta iki duoto laiko.
Kontroliniai taškai sudedami pradiniame projekto darbų grafike (vėliau jis gali keistis, prireikus
daryti projekto korekcijas). Jie padeda projekto vadovui sekti projekto eigą ir valdyti jį.
Projekto vadovas su kontroliniais taškais supažindina ir akcininkus. Kiekvienam
akcininkui pateikiama tokio lygio informacija apie kontrolinius taškus, kokio jie pageidauja.
Tačiau, mažiausiai, jiems teikiamoje informacijoje turi būti kontroliniai taškai, kurių datos
sutampa su projekto etapų pabaiga.
4.4. Projekto terminai ir tikrovė
Dažnai organizacijose IT grupės būna perkrautos darbu. Todėl jos labai mažai laiko
kasdieną gali skirti projektams. Jei žmogus sutinka dirbti projekte, tą jis dažniausiai daro po
darbo valandų, t. y. pasibaigus laikui, kai iš tikro reikėtų pilnai pasinerti į projekto užduotis.
Priklausomai nuo organizacijos dydžio, IT srities darbai yra:
- padalinti atskiriems programuotojų, atvirųjų sistemų (UNIX, Linux, Windows)
serverių priežiūros, didžiųjų (mainframe) ir vidutinių kompiuterių priežiūros,
pagalbos teikimo, duomenų bazių administravimo ir kt. skyriams;
arba
- atliekami viename padalinyje, kuriame yra tik po vieną ar du kiekvienos iš paminėtų
sričių specialistą.
Reta organizacija turi specialiai projektams vykdyti skirtą grupę, kurioje būtų įvairių IT
sričių specialistai. Dauguma organizacijų laiko IT specialistus einamiesiems kasdieniniams IT
naudojimo darbams prižiūrėti, o projektų vykdymas yra tik mintyje.
Kadangi yra tokia situacija ir IT skyrių užimtumas yra didelis, norint kviesti jų
darbuotojus dalyvauti projekte, reikia suprasti, iš ko susideda IT skyrių darbuotojų darbo diena.
Serverių administratoriai. Dauguma serverių administratorių savo darbo dieną pradeda
tikrindami kiekvieno serverio log failus, kuriuose registruojama informacija apie įvairius įvykius,
ar nebuvo serverio darbo klaidų. Jei jų buvo, tuomet aiškinamasi, kas gi buvo atsitikę, ir
sprendžiama problema. Po to paprastai serverių administratorius aptarnauja naudotojų
užklausas (pvz., kažkas negali prisijungti prie serverio, nes baigėsi slaptažodžio galiojimo laikas,
kažkam užblokavo prieigą dėl kokių nors priežasčių, kt.). Atlikęs visa tai, jei dar liko laiko, jis gali
imtis projekto darbų.
Duomenų bazių administratoriai (DBAs) taip pat pradeda savo darbo dieną tikrinimu, ar
neatsitiko ko nors blogo su jų prižiūrima baze (peržiūri log‘us). Jei buvo klaidų, aiškinamasi, kas
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
53
gi buvo nutikę, ir šalinamos atsiradusios kliūtys. Po to DBAs peržiūri indeksus ir trigerius,
užklausas įtraukti ar pašalinti kolonėles ir atlieka reguliavimo darbus, kad duomenų bazė veiktų
greičiau.
Darbą projekte DBAs pradeda naujos duomenų bazės schemos kūrimu, planavimu ir
projektavimu. Visõs naujai suprojektuotos duomenų bazės komponentai gali būti per daug
išplėsti, nes įtraukiama viskas, ko pageidavo užsakovas. Todėl reikalinga duomenų bazės
normalizacija, t. y. kiekvienos lentelės joje optimizavimas, pašalinant logiškai nereikalingus
elementus. Visam tam sugaištama daug laiko, ypač jei duomenų bazė yra didelė.
Programuotojai. Dauguma programuotojų dirba kituose projektuose. Todėl jums gali būti
sunku prisivilioti juos į savo projektą.
Programuotojai gali naudoti įvairias programavimo kalbas ir turėti nevienodą patirtį. Pvz.,
jūsų projektui reikia patyrusio Java programuotojo, galinčio per trumpą laiką sukurti keletą
modulių. Aišku, kad to nesugebės padaryti nei C# programuotojas, nei mažą patirtį turintis Java
programuotojas. O laukti, kol jauni programuotojai išmoks tą daryti, jūs galite neturėti laiko.
Programinę įrangą kuriantys padaliniai ar įmonės nėra pertekę specialistais, todėl seniau
dirbantys ir patyrę programuotojai būna apkrauti darbu. Kartais jie netgi neturi laiko atsakyti į
jaunesnių bendradarbių klausimus ir palieka juos dirbti vienus. Visa tai jums, kaip projekto
vadovui, apsunkina savo projekto darbų grafiko rengimą.
Telekomunikacijų ir interneto specialistai. Labai dažnai šios srities specialistai nėra IT
įmonės darbuotojai ir būna pavaldūs visai kitiems vadovams. Kartais jiems kaip tik trūksta
projektų, o kartais jie turi kitus prioritetus arba dirba kituose projektuose.
Aukščiau aprašyti dalykai skamba niūrokai. Todėl parengti gerą projekto darbų grafiką
nėra lengva. Dalį problemų gali padėti išspręsti bendri interesai. Jei jūsų projektas yra svarbus ir
jūs esate įpareigotas pateikti rezultatus iki nustatyto laiko, tuomet jūs turite svertų paveikti jums
galinčius padėti žmones. Tačiau svarbu, kas gi suteikė jums tuos svertus. Pvz., jeigu projektą
inicijavo realizavimo (prekybos) departamentas, jus rems ir ragins šio departamento vadovai, o
kiti organizacijos departamentai nejaus tokios skubos. Kita vertus, jei projektas rūpi centrinei
organizacijos vadovybei, jūs turėsite mažiau rūpesčių formuodami projekto grupę.
Vadovauti IT projektams nėra lengva, nes jūs neturite iš anksto jums paskirtų žmonių.
Jiems surasti reikės laiko. Todėl svarbu išnagrinėti žmonių darbo krūviu pagrįstą projekto darbų
grafiką ir nustatyti realų darbų pabaigos terminą, atsižvelgiant į aukščiau aprašytas nepalankias
aplinkybes.
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
54
5. PROJEKTO KAINOS PLANAVIMAS
Projekto vadovas, turėdamas projekto apimties aprašą, suskaidytų darbų lentelę (WBS) ir
jų atlikimo grafiką, turi parengti projekto biudžetą, ir, kai jį patvirtina projekto rėmėjai, tvarkyti
jį.
Pinigai, kaip žinia, dažnai būna karštų diskusijų objektas. Iš projektų vykdytojų
reikalaujama padaryti kuo daugiau mažesnėmis sąnaudomis. Prašyti daugiau pinigų projekto
eigoje nėra malonus reikalas. Todėl projektui reikalingos lėšos turėtų būti suplanuotos kiek
galima geriau. Projekto pradžioje tą padaryti yra sunku, tačiau yra keletas būdų ir priemonių,
padedančių geriau suplanuoti projekto biudžetą.
Išteklių planavimas – tai projektui įvykdyti reikalingų išteklių tipo nustatymas ir jų
paskyrimas kiekvienam projekto darbui. Kainos vertinimas yra projektui reikalingų išteklių
kainos nustatymo procesas. Yra trys kainos įvertinimo būdai: analogiškasis, parametrinio
modeliavimo ir pavyzdinis.
Lėšos numatomos kiekvienam projekto etapui. Biudžeto išlaidoms sekti taip pat yra
naudojami kontroliniai taškai. Minėti klausimai yra nagrinėjami šiame mokymo medžiagos
skyriuje.
5.1. Išteklių planavimas
Pirmasis projekto kainos planavimo žingsnis yra išteklių planavimas. Jis apima
darbuotojus, įrangą ir medžiagas, jų kiekius (pvz., 20 žmogaus darbo valandų, 3 serveriai, kt.).
Išteklių planavimo pradžioje reikėtų peržiūrėti projekto apimties aprašą, darbų sąrašą
(WBS) ir pasidomėti, kur galima būtų gauti informacijos apie anksčiau vykdytų panašių projektų
išteklius. Tokios informacijos turėjimas gali padėti teisingai ir greičiau suplanuoti jūsų projektui
reikalingus išteklius. Taip pat gali būti naudinga peržiūrėti organizacijos specifines išteklių
skyrimo projektams taisykles (pvz., taisyklės gali reikalauti vadovybės leidimo, norint kažkuriam
laikui darbams pasitelkti kito padalinio darbuotojus).
5.1.1. Išteklių tipai
Skiriami trys išteklių tipai: žmoniškieji ištekliai, įranga ir medžiagos.
Žmoniškieji ištekliai. Tai reikiamos kvalifikacijos ir sugebėjimų žmonės. Tačiau apibūdinti
reikiamų savybių žmogų gali būti sunkoka. Ieškant tokių žmonių prašoma nurodyti konkrečius
sugebėjimus, kokiuose ankstesniuose projektuose teko dirbti, kokios trukmės stažas, kt.
Įranga. Tai gali būti pati įvairiausia įranga: specializuota testavimo įranga, serveriai,
papildomi asmeniniai kompiuteriai programuotojams, kt. Kai kurio tipo įrangos pristatymo gali
tekti laukti nemažai laiko nuo paraiškos įteikimo.
Jei kuriama nauja programinė įranga ir ją planuojama leisti organizacijoje esančiame
serveryje, reikėtų pasitikrinti tokios prielaidos teisingumu. Net jeigu serveryje duotu metu yra
laisvos erdvės, ji gali būti suplanuota kitai, o ne jūsų kuriamai programinei įrangai. Arba, jei jūs
numatote intensyvų sukurtos įrangos testavimą, pasitikrinkite, ar turėsite prieigą prie esamos
testavimo įrangos, ar jūsų projektui reikės specialios įrangos.
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
55
Kai kuriems projekto darbams, pvz., produkto kūrimo, testavimo, pristatymo gavėjui,
atlikti reikia numatyti specialios įrangos reikalingumą, ypač nesusijusios su IT. Jei projekto darbų
grafike numatytas sukurto produkto priėmimo testavimas, kurį atliks užsakovas, išsiaiškinkime,
kaip jis bus atliekamas. Ar yra nurodyta vieta, kur bus testuojama, ar toje vietoje yra testui atlikti
reikalinga įranga?
Medžiagos. Tai labai plati sąvoka, apimanti darbui reikalingą pagalbinę programinę
įrangą, el. energiją, vandenį, kitokius projektui vykdyti reikalingus išteklius ar vartojimo
reikmenis (patalpos, baldai, kompiuterių tinklas, kanceliarinės prekės, kt.).
5.1.2. Išteklių poreikio nustatymas
Projektui reikiamų išteklių dokumentas rengiamas remiantis projekto apimties aprašu,
darbų sąrašu (WBS) ir išteklių tipais. Išteklių poreikio dokumente aprašomi kiekvienam projekto
darbui reikalingi visų trijų tipų ištekliai.
Išteklių planavimo eigoje nebūtina žinoti vardus žmonių, kurie vykdys konkrečius darbus.
Reikia tik nurodyti specialybės pavadinimą ar darbo aprašą, pvz., Web programuotojas, serverio
administratorius ar kt. Kaip ir kur reikėtų ieškoti reikiamų žmonių, rašoma 6 skyriuje „Projekto
grupės planavimas“.
Pareigų aprašai. Sprendžiant projektui reikalingų darbuotojų klausimą, gali praversti
organizacijoje esantis pareigybių sąrašas, jei nėra ribojama prieiga prie jo. Tokiame sąraše yra
trumpas pareigybių aprašas ir gali būti nurodytas kiekvienos specialybės darbuotojų kiekis,
duotu metu dirbančių organizacijoje.
Jei tokios informacijos jūs negalite gauti, reikėtų panagrinėti informaciją apie panašiuose
projektuose dalyvavusius darbuotojus. Ji gali padėti jums įvardinti pareigas ar specialistus,
reikalingus jūsų projektui.
Įrangos ir medžiagų aprašai. Jūsų organizacijoje tipinio įrangos ir medžiagų sąrašo, kaip
kad pareigybių sąrašas, gali ir nebūti. Todėl įvardinti reikiamą įrangą tenka patiems projekto
grupės nariams. Pradedant projektą, jie dažniausiai turi asmeninius kompiuterius, telefonus,
kanceliarines medžiagas, kt. Kai kuriais atvejais dalį projekto grupės gali tekti perkelti dirbti į
kitą vietą. Todėl būtina žinoti, ar organizacijos taisyklės leidžia kartu su darbuotoju perkelti ir
jam skirtą įrangą, ar projekto vadovas taps atsakingas už ją. Jei projekto grupė turi būti perkelta į
kitą vietą, reikia žinoti, ar ten yra tinkamos patalpos, ar projekto biudžete reikia numatyti išlaidas
darbo vietoms įrengti kitur.
Naujos programų sistemos kūrimo projektuose gali reikėti serverių ar galingų
kompiuterių (mainframes) jai įdiegti. Jei yra nustatyta, kokios platformos kompiuteriuose ji
turės dirbti, tokio reikalavimo turi būti laikomasi. Gali būti taip, kad turima aparatinė įranga tinka
jūsų kuriamai sistemai, tačiau gali tekti pirkti ir naują. Jeigu projektas apima ir naujos aparatinės
įrangos pirkimą, jūs turite pagalvoti ir apie tos įrangos veikimui būtinus dalykus, kaip elektros
energijos tiekimą ar ventiliaciją.
Reikiamų išteklių lentelė. Išteklių poreikio apskaitai palengvinti dažnai naudojamos tam
tikros priemonės ar šablonai. Šiems tikslams rekomenduojama sudaryti reikiamų išteklių lentelę.
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
56
5.1 lentelėje pateikiamas reikiamų išteklių pavyzdys, kuriame parodyti projekto darbai, jiems
atlikti reikalingų išteklių pavadinimai ir jų kiekiai.
Kai nustatomi kiekvienam projekto darbui reikiami ištekliai, toliau vertinama šių išteklių
įsigijimo kaina.
5.1 lentelė. Projektui reikiamų išteklių pavyzdys
Darbas Programuo-
tojai Inžinieriai Ekonomistai
Techn. dokumentų
rengėjai Serveriai
A 1
B 2
C 3 1
D 4
E 1
5.2. Išteklių kainos vertinimas
Išteklių kainos vertinimas yra indėlis į projekto biudžeto formavimą. Tikslesniam
įvertinimui būtina pasitelkti visus prieinamus duomenis ir priemones.
Išteklių kainai įvertinti yra keltas būdų:
- analogiškasis (analogous estimates);
- parametrinio modeliavimo (parametric modeling);
- pavyzdinis (definitive estimates).
Toliau pateikiama keletas minčių, kurios gali praversti vertinant išteklių kainą.
5.2.1. Kainos vertinimo būdai
Aukščiau minėti kainos vertinimo būdai gali būti naudojami įvairiuose projekto planavimo
etapuose. Gali būti ir taip, kad kažkuriam etape naudojamas vienoks vertinimo būdas, o kitame -
kitoks.
Išteklių kainos vertinimo būdų tikslumas gali svyruoti ir todėl gali būti gaunami skirtingi
rezultatai. Apžvelkime tuos būdus.
Analogiškasis vertinimas (analogous estimates). Analogiškasis išteklių kainos vertinimo
būdas, kaip ir darbų trukmės vertinimo būdas projekto darbų grafiko planavimo atveju,
remiasi anksčiau vykdytų projektų patirtimi. Kitaip jis dar vadinamas iš viršaus-žemyn (top
down) arba leistinų ribų (order of magnitude) vertinimo būdu. Šitoks vertinimo būdas
projekto pradžioje naudojamas grindžiant projekto poreikį ir naudą, taip pat rengiant projekto
apimties aprašą inicijavimo etape, kai dar nėra tikslesnių duomenų apie projektą.
Analogiškasis vertinimo būdas naudoja ankstesnių projektų informaciją kartu su ekspertų,
atsakingų už vykdomam projektui reikiamų išteklių kainų įvertinimą, nuomone. Analogiškasis
vertinimo būdas gali būti naudojamas visam projektui, atskiroms jo dalims ar rezultatams.
Tačiau jis nėra naudojamas vertinant išteklių poreikį atskiriems darbams ar jų grupėms.
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
57
Neįmanoma rasti anksčiau vykdyto projekto, kuris tiksliai atitiktų jūsų dabar vykdomą. Jei
jūsų vykdomas projektas nebūtų unikalus, jis nebūtų projektas tikrąja to žodžio prasme
(prisiminkime, kad projektas – tai veiklų grupė arba veikimo planas unikaliam produktui
sukurti). Todėl analogiškasis vertinimo būdas nėra tikslus.
Analogiškojo vertinimo paklaidos gali svyruoti nuo -25% iki 75% tikrosios projekto
kainos.
Nežiūrint to analogiškasis vertinimo būdas projekto pradžioje, kol neturima tikslesnių
duomenų, gali būti geriausias. Ir labai svarbu, kad su projektu susiję asmenys suprastų, jog toks
vertinimas negali būti tikslus.
Parametrinis modeliavimas (parametric modeling). Parametriniame modeliavime
projektui reikiamų išteklių kainai apskaičiuoti naudojami matematiniai modeliai. Jo tinkamumas
kainai vertinti priklauso nuo projekto tipo. Geriausiai parametriniai modeliai tinka statybų
projektuose. Naujo namo statytojai visą jo kainą įvertina parametrinio modeliavimo būdu, kaip
vieną iš parametrų naudodami kvadratinio metro savikainą.
Programų sistemų kūrimo projektuose labiausiai paplitęs parametrinis modelis yra
konstruktyvusis kainos modelis (COCOMO – COnstructive COst MOdel). Jame naudojami tokie
parametrai, kaip sistemos sudėtingumas, darbo grupės gebėjimai, sistemos kūrimo procesai,
naudojami instrumentai.
Nemažai organizacijų turi savus parametrinius modelius. Yra ir komercinių modelių.
Parametrinio modeliavimo tikslumas priklauso nuo modeliui sukurti panaudotų duomenų
tikslumo. Dažniausiai minimas parametrinio modelio trūkumas – galimybės keisti modelio dydį
nebuvimas.
Informacijos apie COCOMO arba parametrinius modelius galima rasti internete.
Pavyzdinis vertinimas (definitive estimates). Pavyzdinis vertinimo būdas duoda
geriausią tikslumą, nes šiuo atveju vertinama projekto kiekvieno darbo kaina. Pavyzdinio
vertinimo paklaidos dažniausiai svyruoja nuo -5% iki 10% tikrosios projekto kainos. Šis
vertinimo būdas dar vadinamas vertinimu iš apačios į viršų (bottom up estimating). Suskaidytų
projekto darbų lentelė (WBS) ir reikiamų išteklių sąrašas yra pavyzdinio kainos vertinimo būdo
įeities duomenys. Vertinimas pradedamas nuo žemiausio lygmens darbų ir atliekamas
kiekvienam darbui. Šių visų darbų kainų suma yra viso projekto kainos įvertis.
Planuojant projekto darbų grafiką, reikėjo įvertinti kiekvieno darbo trukmę. Vertinant
reikiamų išteklių kainas, būtina remtis pastangų dydžiu. Tai yra ne kas kita, kaip laikas, kurį
žmogus turi sugaišti darbui atlikti. Pastangos dažniausiai matuojamos žmogaus darbo
valandomis. Pvz., planuojant darbų grafiką buvo nustatyta, kad projekto techninių reikalavimų
dokumentui parengti reikia 4 dienų. Planuojant kainas reikia žinoti, kiek valandų per dieną
žmogus skirs šiam darbui. Jei skiriamos 5 val. per dieną, tai pastangų dydžio minėtam darbui
atlikti įvertis yra 20 žmogaus darbo valandų.
Skirtumas tarp darbui atlikti reikalingo laiko ir pastangų dydžio gali atrodyti painus.
Tačiau nereikėtų pamiršti, kad čia turime reikalą su dviem iš esmės skirtingais rezultatais. Darbų
trukmės įverčiai darbų grafike padeda mums nustatyti, kiek gi kalendorinio laiko reikės projektui
užbaigti. Tuo tarpu pastangų dydžio įverčiai, kuriuos gauname projekto kainos planavimo etape,
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
58
naudojami projekto kainai nustatyti. Darbų grafikui sudaryti jūs turite žinoti, pvz., kad kažkuriam
darbui atlikti reikia 2 savaičių, o projekto kainai įvertinti jūs turite žinoti, kad tam darbui atlikti
reikia 30 žmogaus darbo valandų.
5.2 lentelėje parodytas pastangų dydžio pavyzdys, atitinkantis 5.1 lentelėje parodytus
projektui reikiamus išteklius.
5.2 lentelė. Projekto pastangų dydžio pavyzdys
Darbas Ištekliai Pastangų dydis
A Techn. dokumentų rengėjai (1) 20 val.
B Programuotojai (2) 100 val.
C Inžinieriai (3) 60 val.
C Serveriai N/A
D Programuotojai (4) 200 val.
E Ekonomistai (1) 30 val.
Dar vieni duomenys, kurių reikia pavyzdiniam kainos vertinimo būdui, yra kiekvieno tipo
išteklių kaina (įkainiai). Darbo arba nuomojamos įrangos įkainiai paprastai nustatomi valandoms
arba dienoms. Kitokių išteklių kaina gali būti išreiškiama kaip mokestis (pvz., naudojimosi kokia
nors sistema) ar vertė (pvz., el. energijos kilovatvalandės, kanceliarinės prekės).
Pasirinkti teisingas kainas yra keblus uždavinys, nes medžiagų ar įrangos kainos laikui
bėgant gali keistis. Daugelio IT projektų kainoje didžiausią dalį sudaro darbuotojų ar darbų kaina.
Šią kainą nustatyti yra sunkiausia, nes ji svyruoja priklausomai nuo darbuotojų išsilavinimo ir
patirties. Jūs galite turėti tik vidutines šių išteklių kainas ar kainų intervalą. Darbams, kuriems
reikia labiau patyrusių specialistų, pasirenkami didesni įkainiai, o kur reikia mažiau patyrusių
specialistų - mažesni įkainiai.
5.3 lentelėje parodytas projekto kainos vertinimo pavyzdys, atitinkantis 5.1 ir 5.2 lentelių
duomenis.
5.3 lentelė. Projekto kainos vertinimo pavyzdys
Darbas Ištekliai Pastangų dydis Kaina, įkainis Visa kaina
A Techn. dokumentų
rengėjai (1)
20 val. 30 Lt/val 600 Lt
B Programuotojai (2) 100 val. 50 Lt/val 5 000 Lt
C Inžinieriai (3) 60 val. 40 Lt/val 2 400 Lt
C Serveriai N/A 50 000 Lt 50 000 Lt
D Programuotojai (4) 200 val. 50 Lt/val 10 000 Lt
E Ekonomistai (1) 30 val. 60 Lt/val 1 800 Lt
Iš viso: 69 800 Lt
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
59
5.2.2. Vertinimo rekomendacijos
Šaukime projekto darbo grupės pasitarimus. Detalus projekto kainos įvertis gaunamas
nustatant kiekvieno darbo kainą ir sumuojant jas. Šiame vertinimo procese jūs galite
neapsižiūrėję praleisti kai kuriuos darbus.
Ar projekto grupei reikalingi specialūs mokymai? Jei projekte kuriama programų sistema,
ar reikia planuoti išvykas pas užsakovą, ar sukurtą sistemą galima bus diegti nuotoliniu būdu.
Projekto grupės susirinkimuose turėtų būti aptariamos įvairios projekto išlaidos. Tai
padeda išvengti galimų klaidų.
Gerai suvokime naudojamą kainos vertinimo būdą. Projekto kainos įvertis sensta labai
greitai. Kadangi nuo to apsisaugoti neįmanoma, reikėtų labai aiškiai suprasti naudojamą
vertinimo būdą.
Jeigu projekto kaina vertinama analogiškuoju būdu ir remiamasi ankstesniu panašiu
projektu, būtina gerai išsiaiškinti, kokio dydžio paklaidą galite padaryti. Būtina atkreipti dėmesį į
kiekvieną reikšmingesnio kainų skirtumo tarp jūsų planuojamo ir ankstesnio projekto, kuriuo
remiatės atlikdami vertinimus, priežastį.
Naudokime kokį nors prieinamą šabloną. Daug organizacijų turi projektų kainoms vertinti
skirtus šablonus ar lenteles. Stenkimės naudoti juos. Matydami juose visus galimus lėšų šaltinių ir
išlaidų kategorijas, būsime labiau tikri, kad viską įtraukėme į savo projekto vertinamą kainą.
Šablonai gali būti geras kainų ar įkainių šaltinis. Projekto vykdytojų algos varijuoja
priklausomai nuo pareigų ir specifinės patirties. Organizacijoje gali būti parengtos standartinės
kainos ar įkainiai projektų kainai vertinti.
Stenkimės gauti įverčius iš darbą atliekančių žmonių. Projektų kainos vertinimo
pavyzdiniu (definitive) arba kitaip vadinamu iš apačios į viršų (bottom up) būdu gero tikslumo
priežastis yra ta, kad įvertinamas kiekvienam projekto darbui atlikti reikalingas pastangų dydis
(žmogaus valandos, kt.). Gero tikslumo nebūtų, jei pastangų dydžio vertinimą atliktų žmonės,
gerai neišmanantys tų darbų. Jei projekte reikės darbų, kurie jūsų organizacijai yra nauji, jums
gali reikėti pagalbos iš išorės jų atlikimo pastangų dydžiui įvertinti.
Numatykime lėšas projekto grupės nariams skatinti. Kiekvienas projekto vadovas nori
paskatinti geru darbu pasižymėjusius grupės narius, skirti premijas, atšvęsti projekto pabaigą.
Tačiau tą sunku padaryti neturint tam lėšų. Ne visos organizacijos projekto grupei skatinti skiria
lėšas, tačiau pritarimo dėl lėšų skyrimo tokiems tikslams galima kreiptis į sponsorių.
Dokumentuokime visas prielaidas. Jei valandiniai įkainiai buvo pagrįsti vidinėmis
organizacijos taisyklėmis, projekto kainos įvertinimo dokumente nurodykime tai. IT projektams
atlikti dažnai naudojami subrangovai, kurie turi kitokius valandinius įkainius. Jei projekto eigoje
iškyla būtinumas sudaryti sandorį su subrangovu, būtina nedelsiant kreiptis į projekto
akcininkus dėl biudžeto pakoregavimo, nes atsirado kitokie kai kurių darbų įkainiai.
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
60
5.3. Projekto biudžeto sudarymas
Išteklių planavimas ir kainų vertinimas dar nepaverčia projektui numatytų lėšų tikraisiais
pinigais. Taip yra todėl, kad organizacijos privalo laikytis formalių procedūrų, skirdamos finansus
projektams.
Projekto vadovas įvertintą projekto kainą perduoda organizacijos biudžeto tvarkytojams.
Vadovybė patvirtina projektui vykdyti prašomą sumą, ir ji tampa organizacijos biudžeto dalimi.
Toliau sudaromas projekto biudžetas, kur visam projektui patvirtintos lėšos, remiantis kainų
įverčiais, darbų sąrašu (WBS) ir darbų grafiku, paskirstomos atskiriems projekto darbams.
Grupei pradėjus vykdyti projektą, tikrosios išlaidos daromos laikantis biudžete nustatytų dydžių
ir numatytu laiku.
Projekto biudžetas padeda orientuotis, kokio dydžio išlaidos leistinos kiekvieno tipo
ištekliams numatytais laikotarpiais. Dažniausiai biudžetas padalinamas mėnesiais.
Žinoti visus su projekto biudžetu susijusius klausimus nėra lengva, ypač kai esi atsakingas
už jums patikėtus išteklius. Prieš pradėdami projekto darbus susipažinkite su jūsų organizacijoje
galiojančiomis taisyklėmis. Reikėtų išsiaiškinti šiuos su projektų biudžeto tvarkymu susijusius
klausimus:
- ar visos projekto išlaidos pateiktos tvirtinti projekto vadovui?
- ar projekto vadovas turi tvirtinti grupės narių darbo tabelius (timesheets)?
- ar projekto vadovas turi gauti savaitines ataskaitas apie projekto vykdymui sugaištas
darbo valandas?
- ar yra kainų ar kiekių maksimalūs dydžiai, kada reikėtų gauti projekto sponsoriaus ar
užsakovo leidimą?
Turint atsakymus į šiuos klausimus, vėliau galima išvengti problemų.
Projekto išlaidų sekimas ne visada yra projekto vadovo pareiga. Kadangi buvo pateikti
kainų įverčiai ir sudarytas projekto biudžetas, išlaidas iš tikrųjų seka centrinis organizacijos
padalinys (buhalterija ar finansų skyrius). Kai kurios organizacijos turi projektų valdymo skyrius
(PMO – Program Management Office), kurie stebi visų tos organizacijos projektų biudžetų
vykdymą.
5.3.1. Projekto biudžetas
Projekto biudžetas rengiamas remiantis patvirtintu projekto kainos įverčiu ir darbų
grafiku. Tačiau prieš leisdamiesi į projekto biudžeto rengimo detales, atkreipkime dėmesį į du
savarankiškus fondus, kurie gali būti biudžete.
Specialusis fondas (nenumatytoms išlaidoms) ir vadovo rezervinis fondas yra du ypatingi
finansavimo šaltiniai, kurie naudojami kai kuriose organizacijose. Šie fondai skiriami ne visiems
projektams. Jeigu jūsų organizacijoje naudojamas kuris nors iš šių fondų, jūs turite žinoti jų
skyrimo ir įgaliojimų naudotis jais gavimo taisykles.
Specialusis fondas. Tai pinigų kiekis, atskirai paskirtas projektui, kuriuos galima naudoti
nenumatytoms pradinės apimties projekto išlaidoms, kurios nebuvo įvardintos planavimo metu.
Nėra taisyklių, laikantis kurių galima būtų apibrėžti specialiojo fondo dydį. Tačiau organizacijos,
pritariančios tokio fondo buvimui, perveda į jį keleto procentų nuo visos projekto kainos sumą.
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
61
Specialiojo fondo skyrimu siekiama sudaryti geresnes galimybes projekto rizikos
klausimams spręsti. Jie dažniausiai naudojami priešakiniuose projektuose. Vertinant pastarųjų
kainą nėra galimybės remtis ankstesnių projektų patirtimi (panašių projektų nėra buvę), todėl
paklaidos gali būti didesnės, be to žmonių patirtis tokiose priešakinėse srityse gali būti maža.
Dažniausiai projekto vadovui suteikiami įgaliojimai naudoti specialiojo fondo lėšas.
Vadovo rezervinis fondas. Tai pinigų suma, kurią skiria organizacijos vadovybė ateities
situacijoms spręsti (išeinant už pradinės apimties projekto ribų), kurių nebuvo galima numatyti
rengiant projekto kainos įvertį. Kaip ir specialiojo fondo atveju, vadovo rezervinio fondo dydis
yra kažkoks procentas nuo visos projekto kainos.
Skirtumą tarp specialiojo fondo ir vadovo rezervinio fondo sudaro tai, kas gi jais gali
disponuoti. Pastaruoju fondu projekto vadovas gali pasinaudoti tik gavęs vadovybės patvirtinimą.
Projekto biudžetą organizacijos finansų skyrius paprastai dalina į specifines kategorijas
(straipsnius): darbo užmokesčio, samdomo darbo, aparatinės įrangos, programinės įrangos,
kelionių, mokymo ir medžiagų.
Vienose organizacijose jų finansų skyrių atstovai padeda sudaryti projektų biudžetus.
Kitose, ypač mažesnėse organizacijose už projekto biudžeto sudarymą gali būti atsakingas
projekto vadovas. Bet kuriuo atveju projekto vadovui reikėtų susipažinti su organizacijoje
naudojamomis biudžeto dalių kategorijomis, kad žinotų kaip yra klasifikuojami projekto ištekliai.
Dažniausiai biudžetai būna lentelės pavidalo, padalinti mėnesiais ar metų ketvirčiais.
5.4 lentelėje parodytas projekto biudžeto pavyzdys. Jame panaudoti 5.3 lentelės
duomenys, laikant, kad projekto trukmė yra trys mėnesiai.
5.4 lentelė. Projekto biudžeto pavyzdys
Sausis Vasaris Kovas Suma
Darbo užmokestis 600 Lt 1 200 Lt 3 000 Lt 4 800 Lt
Samdomas darbas
(programuotojai)
5 000 Lt 5 000 Lt 5 000 Lt 15 000 Lt
Aparatinė įranga (serveris) 50 000 Lt 50 000 Lt
Iš viso: 69 800 Lt
Projekto biudžete lėšos nustatomos etapams, kas padeda valdyti projekto eigą.
5.3.2. Biudžeto lėšos projekto etapams
Sudarytą projekto biudžetą turėtų peržiūrėti projekto grupė. Priklausomai nuo to, kas iš
tikrųjų rengė biudžetą, galbūt geriau būtų, kad biudžetą peržiūrėtų organizacijos finansų skyriaus
atstovas. Projekto grupė turėtų žinoti kritinius darbų grafiko ir biudžeto taškus. Visi klausimai
dėl biudžeto lėšų skirstymo į kategorijas (darbo užmokesčiui, įrangai, kt.) ir kaip lėšos yra
paskirstytos laike turėtų būti žinomi grupės nariams.
Kai projekto grupė peržiūri biudžetą, nustatomos lėšos kiekvieno etapo pradžiai. Lėšų
etapo pradžioje žinojimas padeda projekto eigoje sekti, ar daromos išlaidos atitinka planuotąsias.
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
62
Jos taip pat naudojamos peržiūrint tolesnių (likusių etapų) projekto darbų kainas, remiantis jau
padarytomis išlaidomis ir likusių darbų planuota kaina. Lėšos etapo pradžioje atspindi visas
lėšas, kurios buvo numatytos projekto kainos vertinimo eigoje, išskyrus specialiojo fondo ir
vadovo rezervinio fondo lėšas.
Projekto vadovas turi informuoti projekto akcininkus apie panaudotas lėšas ir likusias
etapų pradžioje. Vieni akcininkai gali norėti žinoti finansinę padėtį tik viso projekto pradžioje,
kiti gali norėti žinoti kiekviename projekto etape padarytas išlaidas. Projekto etapuose išlaidos
daromos laikantis biudžeto naudojimo kontrolinių taškų (budget targets).
5.3.3. Biudžeto naudojimo kontroliniai taškai
Projektų biudžetai paprastai sudaromi taip, kad atitiktų organizacijos finansų skyriaus
reikalavimus. Biudžeto lėšų kategorijos ar mėnesinės ataskaitos teikia neblogas projekto lėšų
leidimo detales, tačiau tai ne vienintelės ar geriausios priemonės biudžetui valdyti.
Projektų vadovams kartais reikia teikti ataskaitas apie išlaidas projektų etapų metu. Todėl
reikėtų nusistatyti biudžeto naudojimo kontrolinius taškus kiekvieno etapo viduje. Kai projektas
yra pradėtas, jūs realiai stebite, kaip laikomasi darbų grafiko ir biudžeto, ir turite žinoti, ar nėra
nukrypimų. Kontroliniai taškai padeda anksčiau gauti perspėjimus apie nukrypimus. Pvz.,
imkime standartinį IT projektą, kurio gyvavimo cikle yra reikalavimų rengimo, projektavimo
(design), kūrimo, testavimo ir diegimo fazės. Planuojant darbų grafiką buvo nustatyta, kad
reikalavimams parengti reikės 4 savaičių ir darbai bus baigti kovo 31 d., o suplanuotame biudžete
tiems darbams numatyta 50000 Lt. Už kovo mėnesį gauta biudžeto ataskaita rodo, kad buvo
išleista 48000 Lt. Bet kas gali pagalvoti, kad reikalai klostosi gerai, sutaupyta truputis pinigų. Bet
pažiūrėję į darbų grafiką matome, kad kovo 31 d. numatyti atlikti darbai dar nepadaryti ir jiems
reikės dar trijų savaičių. Reiškia, jūsų projektas yra pavojuje. Išleidote visus reikalavimams
parengti skirtus pinigus, tačiau parengėte tik apie pusę reikalavimų. Štai kodėl yra svarbu
numatyti biudžeto naudojimo kontrolinius taškus.
Atsidūrę tokioje situacijoje, jūs nesate tikri, kokių veiksmų reikėtų imtis. Kartais, parengę
jūsų manymu gerą biudžetą, galite pastebėti, kad darbų kaina skiriasi nuo planuotosios. Tai
vadinama kainų nuokrypiu (CV – Cost Variance), apie ką plačiau rašoma 13.5 skyriuje.
5.3.4. Biudžeto sudarymo įrankis - projektų valdymo programinė įranga
Kaip ir projekto darbų grafikui sudaryti ar projekto kainai įvertinti, taip ir projekto
biudžetui sudaryti gali būti naudojama speciali projektų valdymo programinė įranga, pvz.,
Microsoft Project.
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
63
6. PROJEKTO GRUPĖS PLANAVIMAS
Projekto kainos planavimo metu, kalbant apie žmoniškųjų išteklių poreikį, buvo
akcentuojama darbuotojų specialybė, kokius darbus jie turėtų mokėti dirbti. Ten dar nebuvo
kalbama apie konkrečius žmones, apie jų darbo organizavimą.
Projekto grupės planavimas apima jos narių pareigų ir atsakomybių, tinkamos
atsiskaitymo už darbus grupėje schemos ir darbuotojų teisių nustatymą, žmonių įtraukimą į
projektą nustatytam laikotarpiui. Projekto grupės planavimo rezultatas – tai nustatyta grupės
organizacinė struktūra ir kur ieškosime projektui vykdyti reikiamų specialistų. Vėliau, laikui
bėgant, kartais tenka rūpintis ir darbo našumo kėlimo klausimais, spręsti darbuotojų kaitos
problemas.
6.1. Projekto grupės organizacinės struktūros planavimas
Valdyti žmonių grupę, kuriai pavesta sukurti unikalų produktą per nustatytą laiką
(prisiminkime projekto sąvokos apibrėžimą), nėra lengva užduotis. Kiekvienas projekto grupės
narys turi aiškiai suvokti savo pareigas ir žinoti, kam ir kaip jis turi atsiskaityti už savo darbą.
Taip pat grupės nariai ir projekto akcininkai turi žinoti, kokia bus grupės organizacinė struktūra.
Jei jūs turite mažą, pvz., 10 IT specialistų dydžio grupę, jos narių atsiskaitymo už darbą struktūra,
be abejo, smarkiai skiriasi nuo struktūros, kai grupę sudaro 200 žmonių ir kurie dirba skirtingose
organizacijose, įsikūrusiose keliuose miestuose.
Kitas svarbus klausimas, turintis įtakos projektui, yra reikiamų specialistų suradimas. Čia
tenka atsižvelgti į darbuotojų sąjungų susitarimus, organizacijų vidaus taisykles, projekto grupės
prioritetus, grupės narių žinias.
Projekto grupės organizacinės struktūros planavimo metu nagrinėjamos įvairios sąsajos,
kurios gali turėti įtakos grupės valdymui, nustatomos narių pareigos ir atsakomybės,
organizacinė grupės struktūra, parengiamas projekto grupės valdymo planas.
6.1.1. Projekto sąsajos
Įvairių projekto sąsajų žinojimas labai praverčia formuojant projekto darbo grupę ir
ateityje valdant ją.
Organizacinės sąsajos. Tai į projektą įtrauktų įvairių jūsų organizacijos departamentų
savitarpio santykiai, kuriuos būtina valdyti. Todėl galimi įvairūs būdai projekto grupės
susirinkimams organizuoti, grįžtamajam ryšiui su grupės nariais palaikyti, informuoti apie
projekto stovį.
Techninės sąsajos. Šios sąsajos atspindi, kaip turėtų būti atliekami projekto techniškieji
darbai. Pvz., naują programų sistemą kuriantys žmonės turi suprasti ir realizuoti sąsajas su
egzistuojančiomis sistemomis arba darbine platforma, kurioje turi veikti sukurta sistema.
Sąsajos tarp darbuotojų. Tai savitarpio santykiai tarp projekto grupės narių. Idealus
atvejis, kai darbe nekyla konfliktų ar nesutarimų. Realiai gyvenime projekto vadovas turi būti
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
64
pasirengęs šalinti nesutarimus tarp grupės narių. Žinios apie žmogaus ankstesnius konfliktus gali
turėti įtakos sudarant projekto darbo grupę.
Projekto grupės organizacinės struktūros planavimo įeities duomenys yra išteklių
planavimo dokumentai, kurie buvo parengti projekto kainos planavimo metu. Išteklių poreikio
lentelė (žiūr. 5.1 lentelę) arba kiti išteklių planavimo dokumentai gali būti naudojami nustatant
projekto grupės narių pareigas ir atsakomybes.
6.1.2. Projekto grupės narių pareigos ir atsakomybės
Pareigų ir atsakomybių dokumente surašomos kiekvienos projekto grupelės ar kiekvieno
grupės nario pareigos ir atsakomybė. Į tokio dokumento rengimą kartais įtraukiamas ir projekto
sponsorius. Tai geras būdas projekto vadovui ir sponsoriui išsiaiškinti, kada ir kaip sponsorius
bus kviečiamas į pagalbą.
Pareigų ir atsakomybių dokumento pavidalas gali būti įvairus: lentelė, sąrašas, kt. Laikui
bėgant pareigos ir atsakomybė gali keistis. Nepamirškime laiku atnaujinti šio dokumento.
Pareigų ir atsakomybių svarstymo metu reikėtų iki smulkmenų išsiaiškinti sponsoriaus
suteiktus įgaliojimus projekto vadovui, ypač jeigu projekto nuostatuose (project chart) jie buvo
neaiškūs arba iš viso nebuvo nurodyti. Bet kokie įgaliojimai projekto vadovui samdyti ar atleisti
darbuotojus, naudoti projekto biudžeto lėšas turi būti dokumentuoti.
6.1.3. Projekto grupės organizacinės struktūros schema
Tokia schema ne tik suteikia vaizdumo, bet joje galima įžiūrėti ir tai, kas kam turėtų teikti
ataskaitas. Mažose projektų grupėse ataskaitos dažnai teikiamos tiesiai projekto vadovui. 6.1 pav.
parodytas projekto grupės organizacinės schemos pavyzdys.
6.1.4. Projekto grupės valdymo planas
Šiame plane surašoma visa projektui reikalingų darbuotojų rinkimo informacija.
Nurodoma, kada žmonės bus priimti ir kada bus atleisti, taip pat ką veiks, ypač jei jie bus priimti
ne visam projekto laikui. Projektų vadovas turi žinoti savo organizacijos taisykles, susijusias su
darbuotojų priėmimu ir atleidimu.
Projekto vadovas
Diegimo darbų vedėjas
Testavimo darbų vedėjas
Programavimo darbų vedėjas
1 programuotojas
2 programuotojas
3 programuotojas
1 tikrintojas
2 tikrintojas
1 diegėjas
2 diegėjas
3 diegėjas
6.1 pav. Projekto grupės organizacinės struktūros schemos pavyzdys
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
65
Jei jūsų projekte yra sudėtingos sąsajos, nesvarbu, organizacinės, techninės ar tarp
darbuotojų, reikia dokumentuoti, kaip numatote jas valdyti. Jeigu visos kuriamos programinės
įrangos testavimas turi būti pavedamas specialiai darbo grupei, būtina tai nurodyti grupės
valdymo plane. Jeigu jūsų grupė yra išbarstyta keliuose miestuose ar keliuose jūsų organizacijos
departamentuose, plane turite nurodyti, kaip valdysite grupę esant tokioms aplinkybėms.
Projekto grupės valdymo planas gali būti įvairaus sudėtingumo. Reikėtų pasidomėti, ar
jūsų organizacijoje nėra šios srities standartų ar šablonų.
6.2. Projekto grupės narių atranka
Projektui reikiamų darbuotojų atrankos būdai, kuriuos naudoja projektų vadovai, yra
labai įvairūs. Geriausia, kai projektų vadovas apklausia pageidaujančius dirbti projekto grupėje ir
turi įgaliojimus priimti tinkančius. Tačiau dažnai projektų vadovas turi tartis su savo
organizacijos funkcinių padalinių (technikos, ekonomikos, teisės, kt.) vadovais, prašydamas skirti
atitinkamos specialybės darbuotoją į projekto grupę.
6.2.1. Pretendentų į projekto grupę apklausa
Projekto vadovo galimybės ar įtaka atrenkant reikiamus darbuotojus priklauso nuo
organizacijoje esančių taisyklių. Jei jūsų organizacija yra matricos arba projektinio tipo, projekto
vadovas turi daugiau galių pasirenkant darbuotojus. Jei numatomi pokalbiai su kiekvienu
pretendentu į projekto grupę, tai reikėtų parengti jiems klausimus ir numatyti veiksnius, kuriais
remiantis bus priimami sprendimai. Rekomenduojamos klausimų grupės ir klausimai yra tokie:
a) darbo įgūdžiai:
- ar asmuo yra mokytas ir turi patirties reikiamiems darbams atlikti;
- ar turima patirtis yra pakankama tiems darbams atlikti;
b) darbo projektuose patirtis:
- ar asmuo anksčiau yra dirbęs projektuose;
- kokio tipo projektuose teko dirbti;
- kokias pareigas užėmė ankstesniuose projektuose;
c) bendravimo su žmonėmis įgūdžiai:
- ar asmuo sugeba dirbti grupėje;
- ar geri asmens bendravimo raštu ir žodžiu įgūdžiai;
- kokios yra stipriosios ir silpnosios kandidato savybės.
Tai tik pradinis klausimų sąrašas. Priklausomai nuo projekto specifikos, galimi klausimai
ir iš kitokių sričių.
6.2.2. Tarimasis su organizacijos funkcinių padalinių vadovais
Tradicinės struktūros organizacijose projektų vadovams tenka tartis su organizacijos
funkcinių padalinių vadovais ieškant projektui reikiamų darbuotojų. Priklausomai nuo to, kaip
organizacijoje tvarkomi darbuotojų klausimai, projekto vadovas gali turėti arba neturėti
galimybės apklausti potencialių kandidatų į projekto grupę. Bet netgi tuo atveju, kai kandidatai
apklausiami, tenka tartis su funkcinių padalinių vadovais, priimant galutinį sprendimą dėl jų
skyrimo į projekto grupę.
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
66
Funkcinių padalinių vadovai nori žinoti, ar jų darbuotojas projekte reikalingas visą ar tik
dalį darbo dienos. Jeigu projekto vykdymui priimamas žmogus, kuris turi įsipareigojimų kituose
darbuose, būtina išsiaiškinti, kiek valandų per dieną jis galės skirti jūsų projektui.
Matricos tipo organizacijose, kur projekto grupės nariai gali turėti keletą viršininkų (pvz.,
funkcinio padalinio, kuriam jis priklauso, vadovą ir projekto vadovą), labai svarbu išsiaiškinti
grupės narių atskaitomybės klausimą. Grupės narys už tam tikrus rezultatus turi būti
atskaitingas tik vienam vadovui.
Darbo našumo įvertinimas yra dar viena tema, kurią, priimant darbuotojus į projekto
grupę, turi apsvarstyti projekto vadovas ir funkcinių padalinių vadovai.
Projekto vadovas turėtų inicijuoti pasitarimus su kiekvieno susijusio funkcinio padalinio
vadovu, kad aptartų darbuotojų skyrimo klausimus ir priimtų nutarimus. Funkciniuose
padaliniuose dažnai būna didelis darbuotojų kiekis, ir jų vadovai nuolatos yra prašomi skirti
žmones į projektų grupes. Projekto vadovas, eidamas į tokius pasitarimus, turi būti aiškiai
apsibrėžęs savo poreikius ir turėti derybų su funkcinių padalinių vadovais planą. Keletas
patarimų, kad šie procesai būtų sklandesni:
a) pasitarimus su kiekvieno funkcinio padalinio vadovu reikėtų rengti skirtingu laiku.
Kalbėdamasis su funkcinių padalinių vadovais atskirai, projekto vadovas gali geriau susikaupti
ties savo projekto atitinkamais poreikiais ir geriau išnaudoti padalinio vadovo laiką. Svarstomi
klausimai turi būti aiškiai suformuluoti ir jiems aptarti turi būti skirta pakankamai laiko;
b) žinokite asmenis, kurie galėtų padėti jums sudarant projekto grupę. Gerai atlikite savo
namų darbus ir susipažinkite su žmonėmis, kurie pristato medžiagą kiekvieno funkcinio
padalinio vadovui. Naudokite savo parengtą projekto grupės valdymo planą, pareigų ir
atsakomybių lenteles, kt., prašydami reikiamų specialistų;
c) numatykite asmenis, kurių prašysite kiekvieno funkcinio padalinio vadovo. Jei jums
reikia specifinių sugebėjimų žmogaus, funkcinio padalinio vadovui įvardinkite konkretų asmenį
ir priežastis, kodėl jo reikia. Būkite pasirengę trumpai pristatyti projektą, jo strateginę svarbą ir
svarbą žmonių iš to funkcinio padalinio. Turėkite atsarginį planą, jei negaunate jums reikiamų
žmonių, būkite pasirengę deryboms;
d) pirmiausia prašykite labiausiai reikalingų žmonių. Laikydamiesi aukščiau išvardintų patarimų, galbūt ne visada gausite norimus žmones į
projekto grupę, tačiau tai padeda įgyti pasitikėjimą funkcinių padalinių vadovų tarpe, jei savo prašymus teiksite kvalifikuotu lygiu. Kokie susitikimo rezultatai bebūtų, išlaikykite gerus santykius su funkcinių padalinių vadovais. Jų gali prireikti ateities projektams.
6.2.3. Kiti projekto grupės sudarymo scenarijai
Gali būti atvejų, kai galimybių derėtis dėl reikiamų darbuotojų nėra. Pvz., yra tik vienas jums reikiamų sugebėjimų žmogus. Arba projekto sponsorius gali norėti paskirti į projekto grupę tam tikrus žmones. Toks projekto grupės narių paskyrimas gali būti geras arba blogas reikalas. Dar vienas projekto grupės formavimo būdas – tai reikiamų specialistų samdymas iš išorės, jei tokių nėra jūsų organizacijoje.
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
67
7. KOKYBĖS PLANAVIMAS
Programų sistemos kokybė – tai jos atitikimas projekto apimties apraše apibrėžtiems
funkciniams reikalavimams (ką sistema turės daryti), techniniams reikalavimams (veikimo,
sąsajų su kitomis sistemomis, eksploatacinių savybių, priežiūros), kūrimo standartams.
Projekto kokybės valdymas apima tris procesus: kokybės planavimą, veiklų kokybei
užtikrinti vykdymą ir kokybės kontrolę. Šiame skyriuje nagrinėjamas kokybės planavimas, kurio
tikslas yra įvardinti projektui tinkamus kokybės standartus ir apibrėžti jų taikymą, kad projekte
sukurtas produktas atitiktų numatytus reikalavimus.
Bendrajame projekto plane kokybės valdymo klausimai dažnai pamirštami ar
ignoruojami. Projekto grupės geri norai sukurti kokybišką produktą dar nereiškia, kad taip ir bus.
Kiekvienas iš mūsų kokybę suprantame įvairiai. Jeigu iš anksto nebūsime apsibrėžę kokybės
reikalavimų, tai sunku bus įvertinti projekte sukurto produkto kokybę.
Kokybės valdymas apima kartais sunkiai suprantamus dalykus. Jie nagrinėjami įvairiose
programose ir dokumentuose, kaip, pvz., bendrasis kokybės valdymas (TQM – Total Quality
Management), „Six Sigma“, ISO 9000, ISO 25010 ir kt. standartuose.
Svarbiausias kokybės planavime naudojamas dokumentas yra organizacijoje priimtos
kokybės taisyklės (politika). Projekto vadovui reikėtų išsiaiškinti, ar toks dokumentas yra jo
organizacijoje. Jeigu yra, tai reikėtų peržiūrėti jame nurodytus kokybės standartus ir išsiaiškinti,
kaip tuos standartus reikėtų taikyti jūsų projektui. Jei remiatės organizacijoje priimtomis
kokybės taisyklėmis, peržiūrėkite jas drauge su grupės nariais, projekto akcininkais ir įsitikinkite,
kad visi tas taisykles žino. Šias taisykles būtinai nurodykite jūsų projekto kokybės valdymo plane.
Būtų nepraktiška, jei, siekdami kokybės, tikrintume kiekvieną projekto plane numatytą
darbą. Yra keletas instrumentų ir būdų, kurie padeda projektų vadovams apsispręsti, ką ir kaip
reikėtų tikrinti, kad sukurtas produktas būtų kokybiškas. Priimti sprendimai kokybės vertinimo
klausimais turi būti užfiksuoti projekto kokybės valdymo plane.
7.1. Kokybės užtikrinimo priemonės ir būdai
Natūralu, kad projektų vadovai kelia sau klausimą, kokius gi kokybės užtikrinimo darbus
reikėtų įtraukti į projektą. Tam visų pirma būtina apibrėžti tas projekto veiklas, kuriose kokybės
klausimai yra labiausiai aktualūs ir kurių įtaka galutiniam projekto rezultatui yra didžiausia.
Jūsų organizacijoje esančiose kokybės taisyklėse gali būti nurodytos priemonės ir būdai,
darbų kryptys ir pastangos, naudotini kokybiškam produktui sukurti. Tai gali būti standartinės
priemonės, sutinkamos daugelyje projektų.
Pramoniniai standartai ar vyriausybės teisės aktai yra kita sritis, kurios projektų vadovai
jokiu būdu neturėtų pamiršti. Nesilaikymas jų reikalavimų gali užtraukti baudas ar
baudžiamuosius teismų nuosprendžius. Tokie reikalavimai gali būti susiję, pvz., su darbo sąlygų
arba produkto sauga.
Jei nėra nei jūsų organizacijos kokybės taisyklių, nei kokybę reguliuojančių standartų ar
teisės aktų, jūs galite naudoti keletą savų būdų, spręsdami projekto kokybės klausimus.
Apžvelkime keturias dažniausiai naudojamas priemones ir būdus: kainos-naudos analizę,
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
68
produkto veikimo išbandymą, struktūrinę (blokinę) schemą ir proceso diagramą bei kokybės
kainą.
7.1.1. Kokybės-naudos analizė
Šis būdas yra naudingas planuojant kokybės valdymą. Reikia įvardinti tas kokybės
užtikrinimo veiklas, kurios duoda didžiausią naudą mažiausiomis sąnaudomis.
Kokybės teikiama nauda – tai patenkinti klientų poreikiai, mažesnės sąnaudos
perdarymams, mažesnė bendroji projekto kaina. IT projektai dažnai turi testavimo planus.
Kainos-naudos analizės būdas gali būti naudojamas projekto kontroliniams taškams nustatyti,
kuriuose reikėtų kažką ištestuoti, taip pat pačiam testavimo tipui įvardinti.
7.1.2. Lyginamoji analizė
Lyginamoji analizė (benchmarking) yra toks tikrinimo būdas, kuriame lyginamos panašios
veiklos. Tai labai naudingas būdas, kai yra daromi turimos sistemos pakeitimai ar naujinimai
(upgrade). Jei keičiama darbo aplinka, norisi žinoti ar naujoji aplinka yra geresnė už buvusią.
IT projektuose gali būti palyginami kuriamos sistemos ir panašių egzistuojančių sistemų
reakcijos į užklausas laikai arba atsakymų išdavimo greičiai. Lyginamoji analizė yra tinkamas
būdas kokybei nustatyti tik tuomet, kai yra teisingi duomenys apie ankstesnės sistemos
galimybes ir yra pakankamai panašumų, kad dviejų sistemų lyginimas būtų prasmingas.
7.1.3. Struktūrinė (blokinė) projekto schema ir diagramos
Proceso struktūrinė schema ir duomenų sekų diagramos (DFD – Data Float Diagram) savo
esme yra panašios, nes jomis stengiamasi grafiškai pavaizduoti proceso eigą.
Struktūrine schema paprastai vaizduojami sąryšiai tarp įvairių projekto elementų.
Sudarius struktūrinę schemą arba DFD, lengviau yra pastebėti projekte galimų problemų
atsiradimo vietą ir laiką. Jūs galite nustatyti kontrolinius taškus, kur reikėtų įvertinti tam tikrų
darbų rezultatų kokybę ir tik po jų patikrinimo daryti kitus darbus.
7.1.4. Kokybės kaina
Kokybei pasiekti reikia papildomo darbo. Kokybės kaina yra visų darbų, kuriais
užtikrinamas projekto rezultatų atitikimas nustatytiems reikalavimams, kaina. Yra trys kokybės
kainos dalys: prevencinė, įvertinimo ir neatitikimų šalinimo.
Prevencinė kaina. Ji siejama su veiklomis, kurios padeda išvengti kokybės problemų. Šią
kainą sudaro kokybės planavimo, darbuotojų mokymo ir kai kurių produktų ar procesų tikrinimo
išlaidos.
Planuojant projekto kainą, prevencinės išlaidos turi būti numatomos programų sistemų
kodų tikrinimo darbams įvairiuose projekto etapuose. Tai gali būti atskirų modulių testavimas,
integracinis testavimas, kai tikrinama keletas sujungtų modulių, o kai kuriais atvejais ir visos
sistemos testavimas. Visų testų tikslas yra kiek galima anksčiau projekto eigoje nustatyti galimas
problemas.
Įvertinimo kaina. Tai išlaidos darbams, kad defektų turintis produktas nepatektų pas
naudotojus. Jų reikia sukurto produkto inspektavimo (apžiūros), testavimo ir formalaus kokybės
audito darbams.
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
69
Sukurto produkto pridavimo užsakovui metu testavimui išleistos lėšos yra produkto
įvertinimo kaina. Projekto pabaigoje sukurtą produktą testuoja nedidelė naudotojų grupė.
Neatitikimų šalinimo kaina. Jei sukurtas produktas pridavimo užsakovui bandymų metu
neatitinka kažkurių reikalavimų, projekto grupė privalo juos pašalinti. Neatitikimų šalinimo
kainą sudaro baudos už prastovas (vėlavimą), papildoma parama naudotojams, klaidų produkte
šalinimo išlaidos, kt.
Prisiminkime, kad kokybė yra vienas iš projektą ribojančių veiksnių, todėl projekto
vadovai tam turi skirti reikiamą dėmesį. Iš tikrųjų tai yra balansavimas tarp projekto kainos,
sugaišto laiko ir kokybės. Kokybei pasiekti reikia laiko. Todėl projektų vadovai turi numatyti
atitinkamus kokybės užtikrinimo žingsnius ir būti pasirengę paaiškinti neatitikimams šalinti
reikiamų lėšų poreikį.
Specifiniai kokybės užtikrinimo darbai turi būti įvardinti ir nurodyti projekto kokybės
valdymo plane.
7.2. Kokybės valdymo planas
Kokybės valdymo plane surašomi visi projekte kuriamo produkto kokybei užtikrinti
reikalingi darbai, procedūros, kaip tie darbai turi būti atliekami ir tiems darbams atlikti reikalingi
ištekliai.
Aprašant procedūras pateikiama smulkesnė informacija apie laukiamus kokybės
užtikrinimo darbų rezultatus ir žingsnius, kurie bus daromi tikrinant kokybės standartų
laikymąsi projekto eigoje. Kokybės standartai ir tikrinimo būdai, kaip tų standartų laikomasi,
plane turi būti apibrėžti aiškiai. Tikrinimo būduose savo ruožtu naudojamos metrikos,
kontroliniai sąrašai, kriterijai.
Metrika yra išmatuojamas dydis, kuris projekto eigoje turi būti stebimas. Bet kuriai
projekto sričiai galima apsibrėžti metrikas. Pvz., kuriant kažkokią programinę įrangą, jos kokybė
gali būti vertinama matuojant jos dydį (kompaktiškumą), veikimo greitį, tikslumą, parduotų
egzempliorių kiekį (paklausą), priežiūros patogumą, kt.
Kontroliniai sąrašai (checklists) yra priemonė, kurioje nurodomas darbui atlikti būtinų
žingsnių rinkinys. Kai tik žingsnis atliekamas, jis išbraukiamas iš sąrašo. Tokia priemonė padeda
stebėti, ar žingsnis buvo padarytas, kada jis buvo padarytas, kas jį atliko.
Užsakovams testuojant produktą priėmimo metu, kontroliniame kokybės sąraše gali būti,
pvz., tokie punktai:
- testavimo darbų, kuriuos atliks 10 naudotojų, tvarkaraštis;
- 20 testavimo variantų;
- testavimo variantų peržiūra ir naudotojų pritarimas jiems;
- testavimo variantų kopijų parengimas kiekvienam testavimo dalyviui;
- mokymai 10-čiai naudotojų, kaip reikėtų testuoti, ir mokymo rezultatų registravimas;
- naudotojų pastabų peržiūra;
- testuoto produkto neatitikimų reikalavimams registravimas.
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
70
Testavimo darbams gali būti samdomos nepriklausomos tvirtinimo ir tikrinimo
organizacijos (IV&V - Independent Validation and Verification Companies). Taip elgiamasi
dideliuose IT projektuose.
Kriterijai. Kalbant apie projektų kokybės valdymą, kaip ir projekto darbų grafiko
planavime, naudojama etapo (milestone) sąvoka. Jei jūsų projektas buvo skaidomas į etapus, tai
etapų rezultatams įvertinti gali būti naudojami ir kokybės kriterijai. Tokiu atveju jūsų projekto
kokybės valdymo plane turi būti nurodyti kriterijai, kuriais remiantis bus vertinama, ar
kiekvienas projekto etapas buvo užbaigtas sėkmingai. Programų sistemų kūrimo projektuose
dažnai atliekamos testų serijos, kad patvirtintume kiekvieno etapo rezultatų kokybę.
Kokybės valdymo plane taip pat turi būti nurodyta, kaip projekto sponsoriai ir akcininkai
turėtų peržiūrėti kokybės užtikrinimo darbų rezultatus. Visa tai turi būti dokumentuota. Projekte
sukurtas produktas laikomas užbaigtu, kai priėmimo bandymų rezultatus patvirtina naudotojai
ar užsakovo įgalioti asmenys.
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
71
8. RIZIKOS PLANAVIMAS
Bet kokio projekto planavimas savo prigimtimi yra optimistinė veikla, nes daroma
prielaida, kad viskas vyks sklandžiai. Tačiau projektų metu dažnai iškyla nenumatytos
problemos. Todėl būtina valdyti riziką (įvertinti pavojus), kad išvengtume netikėtumų arba bent
jau sumažintume problemas. Rizikos valdymas, priešingai projekto planavimui, savo prigimtimi
yra pesimistinė veikla. Tai nesibaigiantis mokymasis iš patirties, tai vertinimas, kokie reikalai gali
pakrypti negera linkme ir kaip to galima būtų išvengti.
Rizika turi būti valdoma visą laiką, nuo projekto pradžios iki jo pabaigos. Viso to tikslas yra
įvertinti riziką (pavojus) anksčiau, kad ji nesukeltų problemų. Tai padeda išvengti krizių, kurioms
įveikti reikėtų mažinti projekto apimtį, daryti kitokius pakeitimus arba ilginti projekto darbų
grafiką.
Kas yra rizika? Rizika tai ne problema. Problema - tai uždavinys, reikalaujantis tyrimo,
sprendimo. Rizika - tai nepageidaujamas dalykas, kuris gali atsitikti, bet gali ir neatsitikti. Rizika
gali būti įvertinta tokiais dydžiais, kaip projekto kai kurių reikalavimų neįgyvendinimas, projekto
darbų grafiko terminų nukėlimas, kainos padidėjimas.
IT projektuose rizikos reikšmingumas yra kur kas didesnis nei kitokio tipo projektuose.
Pvz., statybų projektuose išlaidų padidėjimo 50% rizika yra retas atvejis (jei nesukčiaujama). IT
projektuose rizikos poveikis išlaidoms gali siekti net kelis šimtus procentų.
Rizikos planavimas – tai veiksmų numatymas, projekte iškilus nenumatytoms
aplinkybėms. Jos planavimas susideda iš trijų pagrindinių komponentų: potencialių rizikos
veiksnių (faktorių, priežasčių) įvardinimo, kiekvieno rizikos veiksnio potencialios įtakos
projektui analizės ir reakcijos būdo į kiekvieną rizikos veiksnį numatymo.
Autoriaus filologinė pastaba: lietuvių kalboje žodis „rizika“ turi tik vienaskaitą (pvz., kaip
ir „fizika“). Rizikos veiksnių (faktorių, priežasčių) gali būti daug.
8.1. Rizikos veiksnių įvardinimas
Visi projektai turi riziką (tikimybę neįvykdyti projekto esant nustatytiems ribojimams –
laikui, kainai, kokybei). Projekto grupės nariai gali įvardinti projekto elementus, kurie kelia jiems
abejones. Tai gali būti pernelyg glaustas darbų grafikas, grupės narių patirtis arba
nepasitikėjimas savo, kaip sukurto produkto pardavėjo, sugebėjimais. Deja, dar daug projektų
vadovų neskiria pakankamai laiko projekto rizikos veiksniams aptarti su grupės nariais ir su
akcininkais. Rizikos veiksnių įvardinimas yra procesas, kurio metu nustatomi ir plane
užfiksuojami rizikos veiksniai, dėl kurių gali sutrikti projektas.
Rizikos veiksniai gali būti globalieji, t. y. apimantys visą projektą, ir lokalieji,
atsirandantys projekto eigoje. Globaliesiems rizikos veiksniams priskiriami galimi projekto
finansavimo sutrikimai, bendrasis pagrindinių grupės narių patirties lygis, vadovavimo patirtis ar
strateginė projekto reikšmė. Dažniausiai projektų vadovai, sponsoriai ir klientai kreipia dėmesį
tik į globaliuosius rizikos veiksnius.
Lokaliuosius rizikos veiksnius grupės nariai nurodo, remdamiesi darbų grafiku ir
užduotimis, kurias jie turi atlikti nustatytu laiku ir už numatyto dydžio lėšas. Gali būti rizikos
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
72
veiksniai, susiję tik su tam tikrais projekto etapais arba su tam tikrais projekto darbais. Lokaliųjų
rizikos veiksnių, galinčių atsirasti projekto eigoje, įvardinime turi dalyvauti pagrindiniai grupės
nariai ir atitinkamų sričių ekspertai.
Projekto grupei gali būti užduota daug klausimų, susijusių su įvairiais projekto etapais ar
darbais (užduotimis). Rizikos veiksniams įvardinti grupės nariams gali būti užduodami tokio
pobūdžio klausimai:
- ar užduotis yra kritiniame projekto darbų kelyje?
- ar užduotis yra sudėtinga?
- ar užduotis susijusi su naujomis ar nežinomomis technologijomis?
- ar užduotis susijusi su viena ar keletu kitų užduočių?
- ar turėjote problemų su panašiomis užduotimis ankstesniuose projektuose?
- ar užduotis priklauso nuo išorės veiksnių (leidimų reikalingumo, kažkokių kursų
išklausymo)?
- ar yra nepatyrusių darbuotojų, paskirtų užduočiai vykdyti?
- ar pakankamo dydžio ištekliai paskirti užduočiai?
- ar užduotis susijusi su sistemų integravimu?
- ar jums žinoma aparatinė ir programinė įranga, kurią naudosite užduočiai vykdyti?
Dėl tų užduočių, kurioms į aukščiau minėtus klausimus atsakoma taip, papildomai kelkite
dar šiuos klausimus:
- kokie ginčai ar problemos gali kilti?
- kokios problemos panašiose užduotyse yra kilę anksčiau?
- kokios gali būti problemų priežastys?
Įvardinus visus galimus jūsų projekto rizikos veiksnius, pereinama prie veiksnių analizės,
kad išsiaiškintume, kokią įtaką projektui jie iš tikro turi.
8.2. Rizikos analizė
Rizikos analizės metu siekiama išsiaiškinti, kurie įvardinti rizikos veiksniai yra
pavojingiausi jūsų projektui.
Yra sukaupta daug informacijos apie rizikos analizę, ir tam gali būti naudojami įvairūs
metodai. Rizikos analizė atliekama kokybiniu ir kiekybiniu požiūriais. Kokybinė rizikos analizė
nagrinėja rizikos atsiradimo tikimybę ir jos galimo poveikio projektui dydį. Kiekybinė rizikos
analizė naudoja sudėtingus matematinius metodus rizikos tikimybei, jos poveikiui projekto
tikslams apskaičiuoti. Modernesni kiekybinės analizės metodai apima jautrumo analizę,
sprendimų priėmimo medžio analizę, modeliavimą Monte Karlo metodu, apklausas.
Organizacijos, naudojančios šiuos rizikos valdymo metodus, dažniausiai turi savus ekspertus,
kurie ir padeda projektų grupėms. Kiekybinės analizės būdų čia mes nenagrinėsime.
Kiek plačiau panagrinėkime kokybinę rizikos analizę., kuriai atlikti nereikia specialių
priemonių ar žinių. Naudodama šablonus arba kriterijų rinkinius, projekto grupė gali
susikoncentruoti ties tais rizikos veiksniais, kurie reikalauja didžiausio dėmesio.
Kokybinės rizikos analizės metu įvardinti rizikos veiksniai charakterizuojami tikimybe ir
galimo neigiamo poveikio dydžiu projektui. Tai sunku išreikšti kiekybiškai, todėl tikimybė ir
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
73
poveikis dažniausiai nurodomi taip: aukštas, vidutinis arba žemas. Laikantis tokio vertinimo,
sudaroma visų įvardintų rizikos veiksnių apibūdinimo lentelė. Kaip parodyta 8.2 lentelėje, rizikos
veiksnių apibūdinimas gali suteikti informacijos jų prioritetui nustatyti, t. y. kokiam rizikos
veiksniui bus skiriamas didesnis dėmesys, o kokiam mažesnis. Tai padeda sukurti projekto
rizikos valdymo strategiją. Apskritai, aukšto poveikio ir aukštos tikimybės rizikos veiksniams
skiriamas didžiausias dėmesys. Projektuose turi būti skiriama kažkiek išteklių rizikos
padariniams sušvelninti arba projekto reikalavimai, darbų grafikas ir kaina turi būti atitinkamai
derinami.
8.2 lentelė. Rizikos veiksnių apibūdinimo lentelė
Tikimybė
Aukšta Vidutinė Žema
Poveikis
Aukštas Veiksnys Nr. 1
Veiksnys Nr. 6
Veiksnys Nr. 4 ---
Vidutinis Veiksnys Nr. 3 Veiksnys Nr. 2
Veiksnys Nr. 5
Veiksnys Nr. 7
Žemas Veiksnys Nr.8 --- ---
8.3. Reakcija į riziką
Rizikos analizės metu rizikos veiksniai surikiuojami prioritetų tvarka. Reakcijos į rizikos
veiksnius planavimas yra toks procesas, kurio metu nustatoma, kaip reikėtų reaguoti į kiekvieną
rizikos veiksnį. Skiriami tokie keturi reakcijos į rizikos veiksnius būdai:
- rizikos vengimas yra projekto plano keitimas, šalinant iš jo rizikingus darbus.
- rizikos nukreipimas kitiems. Šiuo atveju atsakomybę už riziką stengiamasi perkelti
trečiosioms šalims;
- rizikos mažinimas, t. y. rizikos veiksnių tikimybės ir poveikio dydžio mažinimas. Tai gali
būti riziką keliančių projekto reikalavimų švelninimas. Pvz., rizika, kad sukurtas
produktas nebus priimamas, jei jis neatitinka 2% reikalavimų, gali būti sumažinta,
padidinus šį procentą iki 5%;
- rizikos prisiėmimas. Paprastai prisiimama žemesnio prioriteto rizika arba taip
elgiamasi, kai nėra kitos išeities.
8.3.1. Prevencinės priemonės
Prevencinės (profilaktinės) priemonės – tai potencialių rizikos veiksnių peržiūra, siekiant
išsiaiškinti galimus kelius problemoms išvengti arba jų atsiradimo tikimybei sumažinti.
Prevenciniai veiksmai yra rizikos vengimo ir rizikos mažinimo būdų kombinacija. Sąnaudos
šiems veiksmams atlikti priklauso nuo rizikos veiksnių galimo neigiamo poveikio projektui
laipsnio. Projekto bendrajame plane reikėtų numatyti tokius darbus ir lėšas jiems atlikti. Todėl
projekto grupės narių klausinėjama:
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
74
- ką galima būtų padaryti, kad išvengtume problemų?
- ką galima būtų padaryti, kad sumažintume problemos atsiradimo tikimybę?
- ar apsimoka daryti tuos veiksmus problemoms išvengti?
- ar yra numatyti ištekliai tokiems veiksmams atlikti?
8.3.2. Veiksmai nenumatytais atvejais
Projekto grupės prisiimama rizika apima ne tik tuos veiksnius, atsakomybę dėl kurių ji
prisiima, bet ir nenumatytus veiksnius. Jei atsiradusi problema nepriklauso projekto grupės
kompetencijai (pvz., teisės aktų pasikeitimai, streikai), veiksmų nenumatytais atvejais plane
turėtų būti nurodytas labiausiai tikėtinas problemos poveikis projektui ir ką reikėtų daryti tokiu
atveju. Reikėtų būti pasiruošusiems atsakyti į tokius klausimus:
- jeigu problema negali būti numatyta, koks galimas didžiausias jos poveikis projektui;
- ką reikėtų daryti, norint sumažinti tokios problemos poveikį projektui?
Projekto rizikos valdymo planas gali būti 8.3 lentelės pavidalo.
8.3 lentelė. Projekto rizikos valdymo plano pavyzdys
Rizikos veiksnys Tikimybė Poveikio dydis Galimos pasekmės Prevencinės arba nenumatytų atvejų
priemonės
Veiksnys Nr.1 aukšta aukštas aukštos priemonės aprašas
Veiksnys Nr. 2 vidutinė vidutinis žemos nėra
Veiksnys Nr. 3 aukšta vidutinis vidutinės priemonės aprašas
Toks rizikos valdymo planas gali būti pateiktas projekto sponsoriui, akcininkams. Jis gali
būti transformuotas ir į kitokį pavidalą, pvz., rizikos stebėjimo planą.
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
75
9. KOMUNIKACIJŲ PLANAVIMAS
Projektų vadovai didesnę savo darbo laiko dalį (50-80%) sugaišta komunikacijoms su
savo organizacijos vadovybe, darbo grupės nariais, subrangovais, tiekėjais, sponsoriais,
akcininkais. Poreikis komunikuoti atsiranda jau pačioje projekto pradžioje, kai tik parengiami
projekto nuostatai ir jūs formaliai paskiriamas projekto vadovu. Projekto nuostatai yra pirmas
dokumentas, kurį jau reikia aptarti su akcininkais. Nežiūrint to, kad projektų vadovai žino, kiek
daug laiko tenka sugaišti įvairioms komunikacijoms, tačiau retai kada projekto pradžioje
planuojamas tam reikalingas laikas.
Gera komunikacija toli gražu nėra vien raštų (el. pašto žinučių, popierinių dokumentų)
siuntinėjimas. Reikia suplanuoti, kas ir su kuo projekto eigoje turėtų palaikyti ryšį, dalintis
projekto informacija. Komunikacijų planavimas yra procesas, kurio metu nustatoma:
- asmenys ar jų grupės, kurie turi būti informuojami apie projektą;
- kokią informaciją jie turėtų gauti;
- kaip ta informacija turėtų būti perduodama.
Apžvelkime bendruosius komunikacijų principus (strategiją) projekto metu ir keletą
specifinių komunikacijų su projekto grupės nariais ir akcininkais klausimų.
9.1. Komunikacijų strategija
Kiekvienam žmogui tenka bendrauti su kitais darbo arba asmeniniais reikalais. Nežiūrint
to, kad bendrauti tenka nuolatos, komunikacijų planavimui ar organizavimui žmonės skiria per
mažai dėmesio.
Nesvarbu, su kuo mums tektų bendrauti, yra keletas paprastų žingsnių, kurie bendravimą
daro efektyvesnį. Iš anksto apgalvokite tokius dalykus, kaip:
- kokį klausimą norite aptarti;
- su kuo norite aptarti rūpimą klausimą;
- pašnekovo (informacijos gavėjo) palankumas ar šališkumas svarstytinais klausimais;
- kaip reikėtų bendrauti;
- žinutės suformulavimas ir siuntimas.
Apgalvoti diskusijų planą iš anksto yra ypač svarbu, kai reikia svarstyti jautrius arba
prieštaringus klausimus. Daug lengviau būna pradžioje gerai apsvarstyti savo siūlymus ir po to
juos išdėstyti pašnekovui, nei vėliau atsiprašinėti ar atsisakyti savo neapgalvotų siūlymų.
Rengiamame komunikacijų plane reikėtų nurodyti:
- kam reikės informacijos apie jūsų projektą;
- ryšių palaikymo su asmeniu ar grupe tikslus;
- komunikacijų būdą (susitikimai, dokumentų siuntimas, kt.);
- už ryšių palaikymą atsakingus asmenis;
- kaip dažnai turėtų būti kontaktuojama.
Komunikacijų plano pavyzdys parodytas 9.1 lentelėje.
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
76
9.1 lentelė. Projekto komunikacijų plano pavyzdys
Su kuo palaikomas
ryšys
Komunikacijų
tikslai, klausimai
Komunikacijų
būdas
Už komunikaciją
atsakingas asmuo
Komunikacijų
dažnumas
Projekto grupė Sričių funkcinė
priklausomybė,
projekto tikslai,
kontrolinius taškus
įtakojantys veiksniai,
rizika
Projekto darbų
grafikas,
grupės susirinkimai,
kontrolinis sąrašas
Projekto vadovas Kas savaitę
Projekto sponsorius Projekto eigos
pristatymas
Projekto ataskaita
Projekto vadovas Kas savaitę
Rizika Kontrolinis sąrašas
Finansai Projekto apžvalga,
biudžeto suvestinė
Funkcinės grupės
vedėjas
Kas mėnesį
Projekto vykdytojai
(subrangovai)
Kontroliniai taškai,
finansai
Darbų eigos
ataskaita
Projekto sponsorius Kas mėnesį/
kas ketvirtį
Darbų eiga Pokalbiai telefonu Projekto vadovas Kas savaitę/
kai reikia
Kiti
9.2. Komunikacija su projekto grupės nariais
Projekto vadovo pagrindinis darbas yra palaikyti ryšį su grupės nariais. Jo pareiga yra
užtikrinti, kad visi grupės nariai žinotų projekto tikslus ir savo indėlį į galutinį rezultatą.
Projekto vadovo kontaktai su grupe gali būti formalūs ir neformalūs. Formalūs kontaktai
apima projekto pradžios susirinkimo, darbo grupės planinių susirinkimų organizavimą, rašytinių
ataskaitų rengimą, grupės formavimą ir kitas veiklas, kurias tenka vykdyti su grupe. Neformalūs
kontaktai – tai telefoniniai pokalbiai ar el. laiškų siuntimas ir gavimas iš grupės narių, pokalbiai
susitikus koridoriuje ar ekspromtu (be pasirengimo) vykstantys pasitarimai.
Projekto vadovui labai svarbu mokėti pasirinkti bendravimo su kiekvienu grupės nariu
stilių. Iš grupės narių gaunama informacija gali padėti užmegzti geresnius ryšius su jais. Jeigu jūs
rengiate darbo grupės susirinkimo darbotvarkę, paklauskite narių, ar jie neturi pasiūlymų
darbotvarkei. Grupės nariai gali turėti pasiūlymų dėl susirinkimų vedimo tvarkos ir dažnumo
arba susirinkimo protokolo formato, pagrįstų savo patirtimi ankstesniuose projektuose. Projekto
vadovas gali nepriimti kai kurių pasiūlymų, tačiau laiko skyrimas jiems išklausyti ir pasiūlymams
peržiūrėti padeda suformuoti darnesnę grupę.
Kiekvienas turime labiausiai priimtinus sau bendravimo būdus. Vieni grupės nariai gali
labiau mėgti el. paštą, kiti – telefoninius pokalbius. Neformaliems kontaktams su grupės nariais
palaikyti projekto vadovas turėtų naudoti kiekvienam iš jų labiausiai priimtiną komunikacijos
būdą.
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
77
9.3. Komunikacija su akcininkais
Kad galėtume parengti komunikacijų su kitais akcininkais planą, visų pirma reikia
sužinoti kas jie yra. Šios mokymo medžiagos 2 skyriuje „Projekto inicijavimas“ nurodėme keletą
tipinių projekto akcininkų: projekto sponsorius, organizacijos funkcinių padalinių vadovai,
pirkėjai, galiniai naudotojai. Prisiminkime, kad akcininku yra tas, kas vienaip ar kitaip priklauso
nuo projekto rezultatų.
Dideliuose projektuose, apimančiuose platų naudotojų ratą, galime pamatyti akcininkų,
kurie nedalyvauja projekte arba gerai nežino savo vaidmens jame. Taip dažniausiai būna su
didelėmis programų sistemomis arba naujais produktais, kurie dislokuojami keliuose
geografiškai nutolusiuose regionuose. Jeigu akcininko atsakingasis atstovas gerai nesupranta,
kokią įtaką projektas turės jų organizacijai, būtina su juo susisiekti ir paaiškinti visa tai. Gali būti
ir taip, kad tas atstovas yra labai užimtas ir todėl nekreipia dėmesio į jūsų projektą. Todėl
žinodami, kad atstovas gali skirti jums tik 5 minutes laiko, labai svarbu išnaudoti šį laiką
protingai.
Tokiais atvejais gali būti naudinga parengti projekto pristatymo planą, kuriame būtų
aprašyti pagrindiniai klausimai, su kuriais norite supažindinti akcininko atstovą. Jame reikėtų:
- nurodyti tuos projekto plano aspektus, kuriuos norite pristatyti;
- išvardinti žinomą arba tikėtiną projekto naudą akcininkui;
- apibrėžti pagrindinę informaciją, kurią būtina perduoti visiems akcininkams.
9.2 lentelėje pateiktas projekto, skirto naujai viešųjų pirkimų sistemai sukurti, pristatymo
akcininkams planas. Šiame pavyzdyje parodyti trys projekto pristatymo variantai, besiskiriantys
savo išsamumu. Labai besidominčiam akcininkui projekto pristatymas gali trukti net porą
valandų. Taigi, toks planas naudingas šiais dviem požiūriais:
- jūs turite kruopščiai apgalvotą projekto pristatymo variantą, kai pristatymo laikas yra
labai ribotas;
- jūs esate pasirengę kitam susitikimui arba galite tęsti esamą, jei akcininkas staiga
paprašytų platesnių paaiškinimų.
Komunikacijų planą jūs turėtumėte peržiūrėti su sponsoriumi. Jeigu jūsų projekte reikia
palaikyti ryšius su darbus administruojančios (prižiūrinčios) grupės nariais, sponsorius gali
padėti parengti komunikacijų planą, įvardindamas tai grupei reikiamą informaciją, kaip ir kada
reikėtų su ja kontaktuoti. Šalia informacijos platinimo būdo komunikacijų plane gali būti
nurodyta, kaip jūs rinksite ir saugosite informaciją, kaip ją galima būtų gauti neplanuotu laiku,
kaip koreguosite komunikacijų planą.
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
78
9.2 lentelė. Projekto pristatymo akcininkams plano pavyzdys
Projektas: Viešųjų pirkių sistemos sukūrimas. Akcininkų grupė: viešųjų pirkimų specialistai.
Bendroji projekto
apžvalga
(5 minutės)
Pagrindinių projekto
punktų pristatymas
(30 minučių)
Detalus projekto
pristatymas
(1-2 valandos)
Kodėl
(vykdomas projektas)
Platus produkto panaudojimas Akcininkų išlaidų
sumažėjimas
Palanki rinkos tyrimų
prognozė
Ką
(tai reiškia
akcininkams)
Pagerės viešųjų pirkimų
procedūros, reikės specialistų
mokymo
Sistemos funkcijų
išplėtimas ir pagerinimas.
Mokymų nauda
Sistemos funkcijų
detalės.
Sistemos demonstracija
Kaip
(bus pasiekti projekto
tikslai)
Parinktuose taškuose
produktas bus įdiegtas iki
kovo 7 d.
Perkančiųjų organizacijų
tikslai. Specialistų
mokymų datos
Viešųjų pirkimų
specialistų patirtis
Kada
(sistemą pradės platinti
akcininkams)
Tiekimo grupė pradės
sistemos pardavimus lapkričio
9 d.
Mokymų rengimas.
Mokymai naudoti sistemą
Sąsaja su žmoniškųjų
veiksnių grupe, užsakovų
aptarnavimas
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
79
10. PIRKIMŲ PLANAVIMAS
Daugelyje projektų dalis darbų atliekama pasitelkus vykdytojus iš išorės. Dideliuose IT
projektuose organizacijas taip elgtis verčia tos aplinkybės, kad pasibaigus projektui nemažai
žmonių lieka be darbo ir juos reikia atleisti.
Naudojant išorinius išteklius reikia būti susipažinusiems su pirkimų procedūromis.
Pirkimų planavimas yra procesas, kurio metu įvardinamos jūsų projektui reikalingos prekės ir
paslaugos, kurias reikia įsigyti iš išorinių organizacijų. Tokiais atvejais projekto vadovas tampa
pirkėju. Prekes ir paslaugas teikiančios organizacijos vadinamos įvairiai: pardavėjais, tiekėjais,
konsultantais arba rangovais.
Pirkimo procesas yra sudėtingas, todėl į pagalbą tenka kviestis teisininkus. Didelėse
organizacijose yra netgi atskiri pirkimų departamentai.
Pirkimų planavimas prasideda nuo sprendimo pirkti prekes ar paslaugas priėmimo.
Priėmus tokį sprendimą, būtina išsiaiškinti, kokio tipo sandoris jums būtų geriausias. Toliau
būtina parengti tikslią darbo užduotį (SOW – Statement Of Work), ką atlikti prašysite išorines
organizacijas. Ši užduotis dedama į kvietimą teikti pasiūlymus (RFP – Request For Proposal) ir
išplatinama tiekėjams. Gautiems pasiūlymams įvertinti ir išrinkti laimėjusį tiekėją turi būti
parengti kriterijai.
Visų pirma apžvelkime aplinkybes, kurios gali versti jus pirkti prekes ar paslaugas iš
išorinės organizacijos.
10.1. Kurti patiems ar pirkti?
Pirkimų planui parengti visų pirma reikia atlikti vadinamąją kurti ar pirkti analizę. Tai
kompromiso tarp darysime patys ar pirksime paslaugas arba gatavą produktą iš kitur
pasiekimas. Sprendimui kurti patiems ar pirkti paslaugas arba gatavą produktą priimti įtakos turi
nemažai veiksnių. Panagrinėkime juos.
Įranga. Jeigu jūs kuriate naują programų sistemą ir jai įdiegti reikia naujos aparatinės
įrangos (AĮ, hardware), tokią AĮ jūs turite pirkti iš kitos organizacijos. Yra ir kita galimybė –
nuomoti tokią AĮ. Tačiau tokiu atveju reikia atsižvelgti į keletą kitokių aplinkybių, kaip tikėtina
jūsų sukurtos sistemos gyvavimo trukmė, ar AĮ bus galima dalintis su kitais, kad pasidalintume
nuomos išlaidas, kt.
Darbuotojų samdymas. Žmonės iš išorės gali būti samdomi visam projektui vykdyti arba
tik atskiriems projekto darbams atlikti.
Viso projekto vykdymui žmonės iš išorės dažniausiai samdomi tais atvejais, kai
organizacija neturi patirties projektams vykdyti. Jeigu jūsų programuotojai nemoka programuoti
tokia kalba, kurios reikalauja kuriamas produktas, jūs galite samdyti tokią patirtį turinčius
žmones. Tačiau reikėtų vengti samdyti visus programuotojus, kad įvykdytumėte projektą. Tik
reikiamų sugebėjimų programuotojų samdymas projekto darbams atlikti yra geresnis variantas.
Jei naujoji sistema baigus projektą bus prižiūrima savo darbuotojų jėgomis, plane būtina
nurodyti, kaip turimi darbuotojai bus mokomi arba kad priežiūros darbams bus priimami nauji
darbuotojai.
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
80
Samdyti darbuotojus iš šalies gali tekti kritinės trukmės projektuose, kai per numatytą
laiką sunku baigti projektą savo specialistų jėgomis.
Kitos prekės ar paslaugos. Projektai gali turėti specifinių tikslų, kuriuos įgyvendinti geriau
pasirengę yra kai kurie tiekėjai. Jeigu jūs diegiate naują komercinę programų sistemą, projekto
darbų grafike galite numatyti organizacijos darbuotojų mokymus savo jėgomis, tačiau galite ir
pirkti mokymo paslaugas. Jei jūs neturite mokymo kursų rengėjų ir vedėjų, matyt, geriau būtų
samdyti tokių paslaugų tiekėjus. Jums reikalingus kursus ir jiems vesti reikalingas priemones kai
kurie tiekėjai jau gali būti seniai parengę.
Projekte kuriamo produkto nepriklausomas tvirtinimas-tikrinimas (IV&V - Independent
Validation and Verification) ir testavimas yra geri samdomų paslaugų pavyzdžiai. Kol jūs
įsteigsite savo organizacijoje formalų testavimo departamentą, galintį dirbti laikantis nustatytų
procedūrų, žymiai geriau yra pasamdyti testavimo srityje jau seniai dirbančius specialistus.
10.2. Sandorių tipai
Sandoris yra teisės dokumentas, kuriame nurodomi sutarti atlikti darbai, kaip už darbą
turi būti atlyginama ir įvairios baudos už susitarimų netesėjimą. Teisininkus rengiančiose
mokyklose skaitomi ištisi sandorių valdymo kursai. Čia mes išsiaiškinkime tik sandorių tipus, nes
šių žinių dažnai prireikia projektų vadovams. Dažniausiai sutinkami šių trijų kategorijų sandoriai:
fiksuotos kainos, išlaidas padengiantieji bei laiko ir medžiagų apmokėjimo. Panagrinėkime juos
smulkiau.
10.2.1. Fiksuotos kainos sandoriai
Fiksuotos kainos sandoriuose tiekėjas pasižada atlikti darbus už fiksuotą kainą. Šio tipo
sandorius geriausia naudoti tada, kai yra gerai apibrėžtas kuriamas produktas ir yra nemažai
informacijos iš ankstesnių panašių projektų. Produktams kurti ar paslaugoms tiekti, kurios nėra
gerai apibrėžtos ar anksčiau tai dar nebuvo daryta, fiksuotos kainos sandoriai yra rizikingi abiem
sandorio pusėms: pirkėjui (užsakovui) ir tiekėjui.
10.2.2. Išlaidas padengiantieji sandoriai
Išlaidas padengiančiuosiuose sandoriuose tiekėjui padengiamos visos išlaidos, kurias jis
patiria pristatydamas produktą, įskaitant mokestį, kuris yra tiekėjo pelnas. Šio tipo sandoriai
pirkėjams yra rizikingiausi, nes jie nežino galutinės kainos. Nors pirkėjų tarpe išlaidas
padengiantieji sandoriai nėra pageidaujami, jie gali būti vienintelė galimybė produktui įsigyti, kai
nėra gero jo apibrėžimo, arba prašoma pateikti kažką, ko anksčiau nėra buvę.
10.2.3. Laiko ir medžiagų apmokėjimo sandoriai
Šio tipo sandoriai yra vidurys tarp fiksuotos kainos ir išlaidas padengiančiųjų sandorių.
Pirkėjas ir tiekėjas susitaria dėl įkainių, pvz., programuotojo darbo valandos kainos, tačiau visa
kaina yra nežinoma, kuri priklausys nuo produktui sukurti sugaišto laiko. Šio tipo sandoriai
naudojami įdarbinant papildomus žmones, kai specifiniams projekto darbams atlikti prireikia
specialistų.
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
81
Sudarant sandorius, reikiami atlikti darbai nurodomi užduotyje, kurie turi įtakos
pasirenkant sandorio tipą.
10.3. Darbo užduotis tiekėjams
Jei projekte numatoma kviestis į pagalbą tiekėjus, labai svarbu tiksliai perteikti jiems, ko
jūs norite. Darbo užduotyje (SOW – Statement Of Work) detaliai aprašomos prekės arba
paslaugos, kurias jūs norite pirkti. Daugeliu aspektų ji yra panaši į projekto apimties aprašą.
Darbo užduotyje yra projekto nuostatai, pagrindiniai tikslai, sėkmės kriterijai, kai kurios
prielaidos ir apribojimai. Joje taip pat nurodoma, kokias garantijas turi prisiimti tiekėjas ir kokios
bus atsiskaitymo sąlygos (darbų priėmimo-perdavimo aktas). Jūsų projekto apimties aprašo
dalis, susijusi su prašomais atlikti darbais, yra gera pradinė medžiaga darbo užduočiai parengti.
Netgi jei darbo užduotį yra rengęs kitas organizacijos departamentas, projekto vadovas
turi užtikrinti projekto reikalavimų tikslumą. Darbo užduotis turi būti aiški ir tiksli, nes tai gali
turėti įtakos tiekėjo siūlomos prekės ar paslaugos kainai. Bet kokie netikslumai gali būti
nepatenkinamų sandorio rezultatų priežastimi.
Daug kompanijų turi šablonus darbo užduotims rengti. Tai priemonė, padedanti perteikti
tiekėjams išsamią informaciją.
10.4. Prašymas tiekėjams teikti pasiūlymus
Kai jūs apsisprendžiate, kad kažkuriems projekto darbams atlikti į pagalbą kviesitės
tiekėjus, ir parengiate darbo užduotį (SOW), ką jie turės atlikti, reikia tai paskelbti tiekėjams.
Prašymo teikti pasiūlymus (RFP – Request For Proposal) esmė yra gauti tiekėjų pasiūlymus
užduotyje nurodytiems darbams atlikti.
Tipiškai pirkimo dokumentai rengiami tam, kad naudodami juos praneštume
potencialiems tiekėjams apie darbus. Šie dokumentai vadinami įvairiai:
- prašymas teikti pasiūlymus (RFP – Request For Proposal);
- prašymas siūlyti kainą (RFQ – Request For Quotation);
- kvietimas siūlyti kainą (IFB – Invitation For Bid).
Nesvarbu kaip pirkimo dokumentai bebūtų vadinami, juose turi būti darbo užduotis
(SOW), informacija, kaip pasiūlymai turėtų būti apipavidalinti ir pristatyti, bei data, iki kada
pasiūlymai turi būti pateikti. Potencialių tiekėjų gali būti prašoma padaryti formalius pranešimus
arba pateikti tik kainą. Priklausomai nuo to, kokioje ūkio srityje jūs dirbate, pirkimo dokumentų
detalumas gali būti įvairus.
Prieš siųsdami pirkimo dokumentus potencialiems tiekėjams, pasitikrinkite, ar jūsų
organizacijoje nėra patvirtinto tiekėjų sąrašo. Daug kompanijų turi nustatytas procedūras
patikrinti, ar tiekėjas atitinka tam tikrus reikalavimus ir ar gali būti kviečiamas jūsų darbams. Jei
jūsų kompanijoje yra tokios taisyklės, tai darbams galima kviesti tik tiekėjus iš patvirtinto sąrašo.
Jei tokio sąrašo nėra, projekto grupė arba pirkimų departamentas turi ieškoti potencialių tiekėjų
verslo asociacijose, internete arba kituose prieinamuose informacijos šaltiniuose.
Kai pirkimo dokumentai išplatinami (galima ir anksčiau), jūs turite parengti kriterijus
gaunamiems pasiūlymams įvertinti.
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
82
10.5. Tiekėjų atrankos kriterijai
Laikas, kurį projektų vadovai sugaišta atrinkdami geriausio tiekėjo atrankai, priklauso nuo
to, ar jūsų organizacijoje yra atskiras pirkimų departamentas. Jei toks departamentas yra, jo
darbuotojai patars jums, kokius dokumentus perkant prekes ar paslaugas reikia parengti, padės
atrinkti tiekėją ir prižiūrėti sandorio su juo vykdymą.
Jeigu jūs esate atsakingas už tiekėjo parinkimą, tuomet reikia parengti kriterijus, kuriais
remiantis vertinsite tiekėjų pasiūlymus. Tariantis su sponsoriumi ir akcininkais, iš anksto
numatomi žmonės, kurie bus įtraukti į tiekėjų pasiūlymų vertinimo komisiją. Būtent jie turi
parengti vertinimo kriterijus ir susitarti dėl kriterijų svorio.
Remiantis nustatytais kriterijais sudaroma tiekėjų pasiūlymų eilė. Kriterijai gali būti
objektyvūs ir subjektyvūs. Pvz., gali būti naudojami tokie kriterijai:
- visa pasiūlymo kaina;
- kokiu lygiu tiekėjas supranta užsakovo problemą;
- tiekėjo darbuotojų kvalifikacija vadybiniu ir techniniu požiūriais;
- tiekėjo patirtis dirbant su panašiais produktais;
- tiekėjo ir jūsų organizacijos kultūrinė (dalykinė) atitiktis;
- tiekėjo finansinė padėtis.
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
83
11. PROJEKTO BENDROJO PLANO RENGIMAS
Ankstesniuose skyriuose nagrinėjome įvairių projekto klausimų planavimą. Jų metu
sukaupiama daug įvairios informacijos. Ką su ja daryti ir kaip ją sekti? Todėl rengiamas bendrasis
(integruotasis) projekto planas, kuriame sujungiama visa projekto apimties, darbų grafiko,
kainos, žmoniškųjų išteklių, kokybės, rizikos, komunikacijų ir pirkimų planavimo metu parengta
informacija.
Tipiškas bendrasis projekto planas (toliau – projekto planas) turi tokias dalis: bendrąją,
planavimo, šablonų ir kontrolinių sąrašų, šaltinių nuorodų ir priedų. Truputį vėliau jos
aptariamos detaliau.
Projekto plano sudarymas nėra vien ankstesnių planavimo dokumentų surinkimas ir
sujungimas. Prasmingam projekto planui sudaryti projekto grupės nariai, sponsorius, akcininkai
turi sugaišti nemažai laiko ir įdėti nemažai pastangų. Visa tai pradedama nuo projekto plano
detalaus turinio (TOC – Table Of Contents) sudarymo.
Baigus rengti projekto planą, jis peržiūrimas, formaliai patvirtinamas. Tuo projekto
planavimo etapas baigiamas (apskritai, vienoks ar kitoks planavimas vyksta viso projekto
bėgyje) ir pereinama prie projekto esminių darbų vykdymo etapo.
11.1. Kas yra projekto planas?
Projekto planas yra dokumentas, kuriame yra sujungti visi planavimo duomenys. Projekto vadovas naudos jį kaip vadovą darbų eigai stebėti, perėjus į projekto vykdymo etapą. Apskritai, projekto planas projekto bėgyje laikas nuo laiko yra peržiūrimas ir koreguojamas. Kai kam gali atrodyti, kad sujungti visus planavimo duomenis į vieną dokumentą nėra svarbu. Tačiau, neturint jo, nuolatos tektų vartyti projekto nuostatus, projekto apimties aprašą, darbų sąrašą ir kitus planavimo dokumentus. O tai nėra patogu. Planavimo procese sukuriama daug svarbių duomenų. Jei jų kruopščiai nesutvarkysime ir nepateiksime reikiamiems asmenims, bus mažai naudos iš jų. Kokybiškas projekto planas labai padeda valdyti projektą, vykdant ir kontroliuojant jo darbus.
Projekto planas yra visų darbų eigos stebėjimo ir reikiamų korekcijų darymo pagrindas. Tai gera priemonė pagrindinei projekto informacijai perduoti akcininkams. Projekto planas yra tas šaltinis, kuris jo skaitytojams padeda išsiaiškinti, kokia yra projekto apimtis, kas yra pagrindiniai akcininkai, kokie turėtų būti pagrindiniai rezultatai, ir daugelį kitų klausimų. Toliau išnagrinėkime projekto plano tipinę sudėtį.
11.2. Projekto plano sudėtis
Daug organizacijų naudoja standartinį šabloną projektų planams. Nors jų formatas ir sudėtis gali varijuoti, tačiau projektų planuose dažniausiai yra tokios dalys:
- bendroji, kur pateikiama informacija apie organizaciją ir patį projektą;
- suplanuotų dalykų, kur talpinami visi planavimo rezultatai; - šablonų ir kontrolinių sąrašų, kurie bus naudojami projekto valdyme; - šaltinių nuorodos; - priedai.
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
84
11.2.1. Bendroji dalis
Projekto planas gali būti labai ilgas dokumentas. Kad būtų lengviau jį naudoti ir matytume
korekcijų darymo laiką, šioje dalyje paprastai būna tokie skyriai:
- informacija apie dokumentą. Šiame skyriuje nurodoma informacija apie dokumento
naujinimus ir priežiūrą. Dokumento istorijoje nurodomi versijų numeriai ir peržiūrų datos, taip
pat yra kontaktinė informacija, kur galima gauti dokumento kopijas;
- turinys. Jame, kaip ir kiekvienos knygos turinyje, atspindima dokumento organizacinė
struktūra – dalys, skyriai, poskyriai ir nuo kurio puslapio jie yra dokumente, kad skaitytojai
greičiau susirastų reikiamą dalį.
11.2.2. Suplanuoti dalykai
Tai pagrindinė projekto plano dalis. Jos svarbiausi skyriai:
- santrauka (executive summary). Ji paprastai pradedama trumpu projekto nuostatų
pristatymu (verslo poreikiai, kodėl buvo pradėtas projektas, projekto tikslai). Santraukos tikslas
– greitai ir glaustai pristatyti projekto esmę;
- reikalavimai. Šiame skyriuje išdėstomi projekto funkciniai, techniniai ir verslo
reikalavimai, kurie buvo suformuluoti projekto inicijavimo etape;
- apimtis. Čia pateikiamos projekto ribos, atitinkančios klientų sutartus siekiamus
rezultatus;
- akcininkai. Tai sąrašas asmenų, atsakingų už projekto rezultatus. Jame nurodomas
sponsorius, klientai, projekto vadovas, projekto grupės nariai, kiti, kurių paslaugų reikia
projektui sėkmingai užbaigti;
- reikiami ištekliai. Čia vardinami ne žmoniškieji ištekliai, o serveriai, programinė įranga,
kita, ko reikės vykdant projektą. Šiame skyriuje gali būti vardinami ir tiekėjai;
- prielaidos ir apribojimai. Išdėstomos planavimo etape darytos prielaidos ir žinomi
suvaržymai, galintys turėti įtakos projekto baigčiai. Pvz., gali būti tokia prielaida: tiekėjas
pristatys savo prekę iki nustatyto laiko;
- pagrindiniai rezultatai. Išvardinami ne tik laukiami galutiniai projekto rezultatai, bet ir
pagrindiniai etapų rezultatai. Ši informacija gali būti imama iš WBS aukščiausio lygio darbų
aprašų.
Gali būti reikalaujama, kad, pvz., intranete ar kitokioje el. aplinkoje būtų teikiama
informacija apie einamąją darbų grafiko versiją. Projekto darbų grafiko kontroliniai taškai gali
būti aprašyti projekto plano prieduose;
- biudžetas. Šis skyrius gali būti labai trumpas, nurodant tik visą projekto kainą arba ją
išskaidytą į išlaidų kategorijas. Visa kita – projekto plano prieduose;
- rizika. Išdėstomi rizikos veiksniai, galintys turėti įtakos projekto sėkmei, ir planai, kaip
galima būtų sušvelninti jų pasekmes arba išvengti jų;
- valdymo klausimai. Aprašoma tvarka, kaip turi būti keliami su projektu susiję klausimai,
nurodomi atsakingi asmenys už problemų sprendimą, apibrėžiamos keitimų darymo procedūros,
projekto stebėjimo ir informavimo apie jo eigą klausimai. Apibūdinama bendroji projekto
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
85
vykdymo aplinka, įskaitant kompiuterinius išteklius, politinius, geografinius, sąsajų su kitomis
sistemomis, kt. klausimus;
- komunikacijos. Projekto plano komunikacijų skyriuje nurodomas komunikacijų su
sponsoriumi, klientais, projekto grupe ir kitais akcininkais būdas ir dažnumas. Pvz., gali būti
rašoma taip: susitikimai su sponsoriumi kiekvieną pirmadienį 10 val.; visos projekto grupės
susirinkimai – kas antrą savaitę trečiadienį 14 val; individualūs susitikimai su grupės nariais arba
el. laiškai pagal poreikį viso projekto metu;
- vykdymo planas. Tai projekto darbų grafiko įgyvendinimo bendroji metodologija. Tai
jūsų planas, susijęs su kūrimo darbais, aparatine įranga, kuriamo produkto diegimu, saugumo
užtikrinimu, derinimu, testavimu, kad viskas vyktų sklandžiai pagal darbų grafiką;
- priežiūros planas. Priežiūros plane nurodoma, kaip sukurta sistema turės būti prižiūrima
užbaigus projektą. Priežiūra gali apsiriboti naujos sistemos naujinimais ar dalies aparatinės
įrangos priežiūra arba gali būti steigiama grupė, kuri teiks pagalbą naujos sistemos naudotojams;
- mokymų planas. Jame dėstoma, kaip bus mokomi sukurtos sistemos galiniai naudotojai,
administratoriai, pagalbos teikimo tarnyba ir kitos grupės.
11.2.3. Šablonai ir kontroliniai sąrašai
Jeigu jūs naudojate kokius nors kontrolinius sąrašus arba juos sukūrėte planavimo eigoje,
jų kopijas galite dėti į šį projekto plano skyrių. Kontrolinių sąrašų pavyzdžiai:
- diegimo (instaliavimo) kontrolinis sąrašas;
- testavimo kontrolinis sąrašas;
- kiti kokybės kontroliniai sąrašai.
11.2.4. Šaltinių nuorodos
Šaltinių sąraše nurodomos naudotos metodologijos, standartai, sektini pavyzdžiai (best
practices). Jame gali būti:
- projektų valdymo žinynas [PMBOK];
- jūsų organizacijos kokybės standartai;
- jūsų organizacijos sistemų kūrimo metodologija;
- jūsų organizacijos projektų valdymo metodologija;
- ISO 9000 standartai;
- kiti reikalingi reglamentai ar standartai.
11.2.5. Priedai
Prieduose talpinamos dokumentų kopijos, kurie paprastai nededami į projekto plano
tekstą (dedama tik nuoroda). Tai:
- projekto darbų grafiko kontroliniai taškai;
- projekto biudžeto kontroliniai taškai.
Projekto plano rašymas gali atrodyti sunkus pradedančiajam projektų vadovui. Tačiau
nereikėtų išsigąsti, nes yra nemažai patarimų, kaip reikėtų rašyti projekto planą, kad jame būtų
nurodyti ateityje reikalingi duomenys.
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
86
11.3. Plano sudarymas
Projekto plano rašymo žingsniai:
- plano rašymo organizavimas ir rašymas;
- plano keitimo procedūrų apibrėžimas;
- plano peržiūra;
- projekto planavimo etapo užbaigimas.
11.3.1. Plano rašymo organizavimas ir rašymas
Prieš pradedant rašyti projekto planą reikėtų visų pirma peržiūrėti turimus dokumentus
ir numatyti jų pateikimo tvarką. Priešingu atveju gali atsitikti taip, kad rašydami planą jūs tuos
pačius duomenis įtrauksite daug kartų arba praleisite svarbius dalykus.
Taip pat būtina apibrėžti dokumentų tvarkymo procedūras, jei jūsų organizacijoje nėra
standartinių. Kaip turi būti daromi dokumento pakeitimai, kokia naujų versijų numeravimo
sistema, kaip turi būti nurodomos versijų datos ir numeriai – tai klausimai, kurie turi būti
išspręsti iki projekto plano išplatinimo. Neturėdami dokumentų tvarkymo taisyklių, jūs
negalėsite tinkamai apskaityti daromų projekto plano pakeitimų.
Šiandieninės bendro naudojimo failų (file-sharing) technologijos įgalina projektų vadovus
platinti projekto duomenis elektroniniu būdu. Taip išvengiama daug rankinio darbo, spausdinant
dokumentus, platinant jų originalą, o vėliau platinant pakeistus dokumento puslapius.
Pradedant rašyti dokumentą reikia apsispręsti, kaip jis bus platinamas: atspausdintas
popieriuje ar elektroniniu būdu. Prieiga prie projekto plano bendro naudojimo faile turi savų
ypatumų. Tenka nustatyti dokumentų saugumo lygius ir sudaryti akcininkams prieigos prie
serverio, kuriame saugomas projekto planas, galimybes (naudojant slaptažodžius, kt.).
Dokumentai serveryje turi būti apsaugoti nuo nesankcionuoto pakeitimo.
Išsprendus aukščiau minėtus organizacinio pobūdžio klausimus, pradedama rašyti
projekto planą. Kadangi planą skaitys daug žmonių iš įvairių jūsų organizacijos padalinių,
ištaisykite gramatines klaidas, įsitikinkite, ar visi plano skyriai užbaigti, ar visi duomenys teisingi.
Tinkamai neperžiūrėtas ir nesuredaguotas planas kelia įtarimą, kad projektas nėra kruopščiai
apgalvotas ir suplanuotas.
11.3.2. Plano keitimas
Projekto grupės parengtą, akcininkų peržiūrėtą ir sponsoriaus patvirtintą projekto plano
pradinį variantą projekto vykdymo etape tenka ne kartą koreguoti.
Projekto plano keitimas yra iteracinis procesas. Tai reiškia, kad projekto eigoje pakeitus
pagrindinius plano komponentus, būtina pakoreguoti įvairius plano skyrius. Pvz., gali būti
keičiama projekto apimtis, gali būti įtraukti nauji akcininkai, gali būti praplėstas pagrindinių
rezultatų sąrašas. Planas, kuris tvarkomas atsitiktinai, greitai pasidaro netikslus ir netenka
projekto vykdymo kelrodžio vertės.
Šiems sunkumams įveikti būtinas projekto plano keitimų darymą reglamentuojantis
dokumentas. Turėtų būti paskirtas asmuo, kuris būtų įgaliotas daryti projekto plano pakeitimus
ir platinti tokią informaciją.
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
87
Bet kokie projekto plano pakeitimai turi būti daromi griežtai laikantis nustatytos tvarkos.
Pvz., projekto apimties pakeitimai turi būti daromi tik gavus oficialų patvirtinimą, išduotą
laikantis projekto apimties valdymo plane nustatytų taisyklių. Biudžeto ar darbų grafiko
pakeitimams daryti taip pat būtinas oficialus leidimas.
11.3.3. Plano peržiūra
Į projektą įtraukti žmonės turi turėti galimybę dalyvauti plano rengime. Projekto planas
rengiamas keliais žingsniais, palaipsniui plėtojant jį. Nuolatinė jo peržiūra, dalyvaujant
sponsoriui ir akcininkams, yra sėkmės prielaida.
Sponsoriaus peržiūra. Sponsorius įtraukiamas į projekto plano peržiūrą, kai tik
parengiami plano metmenys arba turinys. Taip suteikiama jam galimybė išdėstyti savo pastabas
dėl plano. Jei planas rengiamas pagal patvirtintą šabloną, projekto vadovo pareiga įsitikinti, ar
sponsoriui yra žinomas to šablono turinys.
Sponsorius turi peržiūrėti projekto planą periodiškai, kai tik įvairios plano sekcijos
papildomos naujais duomenimis. Jis turi savo parašu patvirtinti projekto planą, taip suteikdamas
jam oficialaus dokumento statusą. Kaip einama link galutinių rezultatų, sponsorius turi matyti
įvairiuose projekto etapuose.
Akcininkų peržiūra. Projekto plano rengimas suteikia projekto vadovui gerą galimybę
suvienyti akcininkų interesus ir įsipareigojimus. Projekto plano metmenys ar turinys turi būti
pateikiami jiems. Plano duomenys jiems turi būti žinomi, nes kiekvieno lūkesčiai gali skirtis.
Atviras klausimų ar interesų aptarimas padeda parengti geresnį projekto planą.
Sudėtingų projektų išankstinė plano peržiūra turi būti įprastas dalykas. Paprastesniais
atvejais gali pakakti susitikimų tik su atskirais akcininkais, jei jiems iškyla klausimai.
Galutinė projekto plano peržiūra yra formali procedūra, kuria užbaigiamas projekto
planavimo etapas.
11.3.4. Projekto planavimo etapo užbaigimas
Kai projekto planas baigiamas, jis išplatinamas akcininkams. Po to pereinama prie
projekto vykdymo ir kontrolės etapų.
Projekto eigoje nuolat tenka stebėti, ar projektas juda į priekį. Susirinkimas planavimo
etapo pabaigoje yra gera galimybė gauti akcininkų pritarimą projekto tikslams. Jeigu pasikeičia
verslo poreikiai, dėl kurių pradžioje buvo imtasi projekto, dabar yra pats tas laikas, kai turi būti
apsispręsta dėl projekto tęsimo.
Ši peržiūra padeda išsiaiškinti planavimo metu neišspręstus klausimus. Tikimasi, kad visi
anksčiau iškilę klausimai yra išspręsti planavimo etape. Bet nemanykime, kad tokiu klausimų
neliko. Visada klauskite akcininkų, ar jų manymu planavimo etape neliko neišspręstų klausimų.
Yra lengviau išspręsti ginčus, kol projektas dar nepradėtas.
Kitas svarbus plano peržiūros uždavinys yra išsiaiškinti, ar akcininkų lūkesčiai atitinka
detalų projekto planą. Jei kai kurie plano elementai jiems pasirodo netikėti, išsiaiškinkite, ko
akcininkai iš tikro tikėjosi. Projekto vadovo pareiga yra išsiaiškinti, ar visos į projektą įtrauktos
šalys supranta ir remia siekiamus galutinius rezultatus ir pritaria tų rezultatų siekimo būdui.
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
88
Peržiūros metu atlikus pataisymus, projekto planą formaliai patvirtina sponsorius, o kai
kuriais atvejais - klientai. Patvirtintas dokumentas išplatinamas akcininkams.
Baigiamajame projekto planavimo susirinkime taip pat gali būti aptariami rodikliai, kurie
bus naudojami valdant ir kontroliuojant projektą jo vykdymo etape. Projekto vykdymo rodikliai
yra išmatuojami dydžiai, kuriuos projekto vadovas naudos vertindamas projekto eigą, pvz., ar
nėra nukrypimų nuo darbų grafiko ar biudžeto kontrolinių taškų.
Pereidami iš planavimo etapo į vykdymo etapą, visi projekto dalyviai turi aiškiai žinoti
savo individualų vaidmenį ir stengtis sėkmingai įvykdyti projektą.
7.1 lentelėje pateikiamas projekto plano turinio pavyzdys.
7.1 lentelė. Projekto plano turinio pavyzdys
TURINYS 1. Santrauka
2. Reikalavimai (funkciniai, techniniai, verslo)
3. Apimtis
4. Akcininkai
5. Reikiami ištekliai
6. Prielaidos ir apribojimai
7. Pagrindiniai rezultatai
8. Biudžetas
9. Rizika
10. Valdymo klausimai (pareigos, stebėjimas, aplinka)
11. Komunikacijos
12. Vykdymo planas
13. Priežiūros planas
14. Mokymų planas
Šablonai ir kontroliniai sąrašai
Šaltinių nuorodos
Priedai
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
89
12. PROJEKTO VYKDYMAS
Projekto vykdymo etapas yra tas laiko tarpsnis, kuomet atliekami realūs projekto darbai.
Projekto vykdymo sėkmė priklauso nuo:
- sudarytos projekto grupės;
- kaip laikomasi projekto plano;
- kaip platinama projekto informacija;
- kaip valdomi sandoriai su tiekėjais.
Projekto vadovui tenka palaikyti ryšį su daugeliu asmenų ir projekto grupe viso projekto
metu. Kalbantis su sponsoriumi, grupės nariais, tiekėjais, klientais, išorinėmis finansinėmis ir
teisinėmis organizacijomis, tenka pasitelkti visus savo, kaip vadovo, sugebėjimus.
Projekto vykdymo sėkmė didžiąja dalimi priklauso nuo sudarytos projekto grupės.
Mokėjimas sudaryti laikinas grupes, organizuoti reikiamus mokymus, diegti tinkamą darbuotojų
skatinimo ir pripažinimo sistemą yra pagrindiniai darnios grupės sudarymo veiksniai.
Projekto sėkmingas vykdymas neįmanomas ir be gerų santykių su akcininkais. Tenka
palaikyti nuolatinį ryšį su sponsoriumi. Kad žinotume, ar projektas vykdomas pagal planą, būtina
rinkti tam tikrus duomenis, lyginti juos su tais, kurie buvo numatyti plano kontroliniuose
taškuose, rengti ataskaitas apie projekto eigą.
Sandorių su tiekėjais valdymas irgi turi įtakos sėkmingam projekto vykdymui. Projekto
vadovas turi sekti tiekėjų darbus, spręsti projekto grupės ir tiekėjų ginčus, reaguoti į tiekimų
vėlavimus, tvarkyti atsiskaitymo su jais dokumentus.
Panagrinėkime projekto sėkmingo vykdymo svarbesnius veiksnius detaliau.
12.1. Projekto grupės sudarymas
Projekto grupės valdymas skiriasi nuo funkcinės darbo grupės valdymo. Kadangi projektų
grupės būna laikinos, surinkti tinkamus žmones būna sunku. Grupėje dirbti sutinkantys žmonės
dažniausiai yra kažkurios IT srities specialistai, bet neturi platesnių žinių apie
kompiuterizuojamą verslo sritį. Projekto vadovo uždavinys yra sudarytą projekto grupę parengti
taip, kad ji galėtų dirbti efektingai ir įvykdytų projektą reikiamu kokybės lygiu, laiku ir
neviršydama biudžeto. Tai nėra lengva, ypač kai viena dalis žmonių įdarbinama puse etato, kita –
visu etatu, kai vieni yra techninio, kiti ne techninio profilio specialistai, o kai kuriais atvejais jie
būna išsidėstę geografiškai plačioje teritorijoje.
Projekto vadovo uždavinys yra, panaudojus tinkamą skatinimo ir pripažinimo sistemą,
pravedus reikiamus mokymus, sudaryti darnią projekto grupę ir valdyti ją.
12.1.1. Darnios projekto grupės sudarymas ir valdymas
Prieš pradedant nagrinėti laikinų grupių valdymo būdus, naudinga prisiminti grupės
plėtros etapus:
- grupės sudarymas. Šio etapo metu žmonės susipažįsta su projekto tikslais, projekto
vadovu ir vieni su kitais;
- kova dėl pareigų. Tai narių kovos už aukštesnes pareigas, įtaką projekto grupės
organizacinėje struktūroje laikotarpis;
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
90
- santykių nusistovėjimas. Tai etapas, kai projektas įeina į normalias vėžes ir grupės
nariai pradeda naudingai bendradarbiauti;
- našus darbas. Tai paskutinis plėtros etapas, kai darbo grupės nariai suvokia
tarpusavio santykius, pasiekia darną ir aukštą darbo produktyvumą.
Šiems etapams įveikti grupei reikia laiko ir gero vadovavimo. Viso to pradžia galėtų būti
projekto grupės pirmasis susirinkimas (project kickoff).
Projekto grupės pirmasis susirinkimas. Jei žmogus pagalvoja apie savo įgytą patirtį, dėl
kurios buvo priimtas į projekto grupę, tai visos jo mintys ko gero atsako į šiuos klausimus:
- kodėl aš esu projekto grupėje?
- kas aš ir ko iš manęs tikimasi?
- ką aš rengiuosi daryti?
- kaip darysiu savo darbą?
Projektų vadovas turėtų priminti grupės nariams būti pasirengusiems atsakyti į minėtus
klausimus. Geras pirmasis susirinkimas yra toks, kuriame atsakoma į šiuos klausimus ir
sukuriamas pagrindas grupės nariams.
Pirmasis susirinkimas yra gera proga susipažinti grupės nariams ir akcininkams, visiems
jiems išgirstant tą patį ir tuo pačiu metu. Projekto vadovas dažniausiai nepažįsta visų grupės
narių ir neturi galimybės apklausti jų, kokias pareigas jie galėtų užimti. Jis turi supažindinti grupę
su projekto tikslais ir sukurti tokią atmosferą, kad visi grupės nariai jaustųsi jaukiai. Tai būtų
gera pirmo grupės plėtros etapo – grupės sudarymo - pradžia.
Projektų grupių pirmieji susirinkimai gali būti organizuojami labai įvairiai. Štai keletas
tokių susirinkimų darbotvarkės punktų:
- pasveikinimas;
- supažindinimas (pristatomi asmenys, nurodoma jų funkcinės veiklos sritis,
išsilavinimas, pareigos projekte);
- kviestų pranešėjų - sponsoriaus, kurio nors iš akcininkų, klientų - kalbos;
- projekto apžvalga;
- projekto vadovo lūkesčiai;
- klausimai ir atsakymai;
- pasisakymai.
Grupės darbo (performance) valdymas. Projekto vadovas turi teisę įpareigoti grupės
narius daryti darbus ir reikalauti iš jų atsakomybės už rezultatus. Kad grupės nariai pasitikėtų
juo, vadovas turi būti kompetentingas, gerbiamas, sąžiningas ir atviras. Projekto vadovas visada
turi būti pasirengęs geranoriškai padėti grupės nariams, sprendžiant darbo problemas.
Valdymui svarbus yra grupės narių grįžtamasis ryšys. Vadovui nereikėtų nurodinėti
kiekvieno smulkaus darbelio ir reikalauti ataskaitų už juos. Tačiau žmonės vienus darbus moka
geriau, kitus – blogiau. Todėl, aptariant jiems pavestus darbus, reikėtų koncentruotis ties tokiais
klausimais: kokių darbo rezultatų laukiama, kokie galimi darbo nesklandumai, koks atpildas už
labai gerai atliktą darbą, kokios nuobaudos už nusižengimus, kokios specifinės vadovo
sprendimo pasekmės.
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
91
Darbų grįžtamasis ryšys turi būti savalaikis. Maža naudos, pvz., iš klaidos taisymo, jei ji
buvo padaryta prieš keletą savaičių ir spėjo persiduoti į kitus projekto komponentus. Dar blogiau,
jei žmogus ją pamiršta.
Iškilusiems konfliktams spręsti galimi įvairūs būdai: prisiderinimas, vengimas, ginimasis,
kompromisas, bendradarbiavimas. Dvi konfliktinės situacijos, kurios reikalauja išskirtinio
dėmesio, yra grupės narių ginčai (jiems išspręsti turi įsikišti trečias asmuo - projekto vadovas) ir
irzlių grupės narių, nuodijančių kolektyvo atmosferą, valdymas.
Darniai projekto grupei sukurti, jos darbo našumui didinti padeda mokymai.
12.1.2. Mokymai
Priklausomai nuo projekto pobūdžio, sudarytos projekto grupės mokymai gali būti
pravedami tik kai kuriems arba visiems grupės nariams. Kai kuriose organizacijose kaip šalutinis
tikslas gali būti projekto grupės narių įgūdžių padidinimas arba informacijos apie naujus
produktus ar procesus surinkimas.
Jei jūs kuriate produktą naudodami naują ir besiplėtojančią technologiją, projekte gali būti
numatyti grupės mokymai.
Vienas iš labiausiai paplitusių mokymų projektų grupėms yra projektų valdymo kursai.
Medžiagą jiems gali būti parengęs ir projekto vadovas, o patys kursai gali būti vedami už
organizacijos ribų. Mokymus gali rengti ir specializuotos projektų valdymo organizacijos,
naudodamos standartines metodologijas, įrankius ir šablonus.
Grupės profesinio lygio kėlimas, darbų grįžtamojo ryšio gerinimas yra labai svarbu, bet
neturėtų būti pamiršti ir darbuotojų skatinimo ir pripažinimo klausimai.
12.1.3. Skatinimas ir pripažinimas
Kai kurie projektų vadovai (greičiau ne jie, o projektų sponsoriai) gali sakyti, kad grupės
nariai tik dirba savo darbą ir papildomai už tai jiems nemokama. Tačiau daugelyje organizacijų
puikus darbas pažymimas, mokamos premijos.
Projekto grupės darbas yra sunkus ir kartais pareikalauja išradingumo, kad būtų pasiektas
projekto tikslas. Jei jūsų organizacija yra funkcinio tipo, tai projekto darbai gali ir nesusilaukti
reikiamo funkcinių padalinių vadovų dėmesio. Todėl projekto vadovas turėtų pasirūpinti, kad
projekto grupei būtų taikomos skatinimo priemonės.
Skatinimo sistema yra susijusi su projekto biudžete numatytais pinigais, kuriuos projekto
vadovas gali panaudoti pasižymėjusiems darbuotojams premijuoti arba projekto užbaigimo
pokyliui organizuoti. Priklausomai nuo organizacijos taisyklių, skatinimas gali apsiriboti garbės
raštais ar dovanomis.
Jeigu projekto biudžete arba organizacijos vadovybės specialiajame fonde yra numatytos
lėšos darbuotojų skatinimui, jūs turite būti apibrėžę nuopelnus, už kuriuos žmonės bus
skatinami. Kai žmogus skatinamas, turi būti aiškiai įvardinti darbai, už kuriuos jis nusipelnė
pagarbos.
Gali būti ir visos grupės skatinimai. Tai iškilmingi pietūs ar šventiniai renginiai.
Ne visi projektų vadovai turi lėšų darbuotojams skatinti. Tokiais atvejais reikėtų bent
padėkoti jiems už puikų darbą.
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
92
Kokia darbuotojų skatinimo ar pripažinimo forma bebūtų, projekto vadovas turi vienodai
taikyti ją visiems grupės nariams. Nevienodas skatinimas dažnai vertinamas kaip favoritizmas.
12.2. Santykiai su kitais akcininkais
Be projekto grupės sudarymo ir darbo su ja projekto vykdymo metu projekto vadovui
dažnai tenka turėti reikalus su sponsoriumi, kitais akcininkais (prisiminkime, kad pagal
akcininko sąvokos apibrėžimą, projekto vadovas ir grupės nariai taip pat yra akcininkai),
klientais. Panagrinėkime šiuos santykius šiek tiek plačiau.
Santykiai su klientais. Daugelyje organizacijų IT grupės santykiai su kitais organizacijos
darbuotojais ar klientais būna savotiškai priešiški. Tai nėra gerai nei projekto grupės nariams, nei
pačiam projektui. Todėl IT projekto vadovui reikėtų išsiaiškinti tuos barjerus, kurie gali trukdyti
efektyviems darbo santykiams su klientais palaikyti.
Klientai gali nežinoti sudėtingų programų sistemų kūrimo plonybių, o projekto vadovas
gali ne viską žinoti apie kompiuterizuojamą verslo sritį.
Klientų techninio išprusimo lygis gali būti labai įvairus. Santykiai su jais bus geresni, jei
išsiaiškinsite, kokias technologijas jie naudoja savo darbe.
Štai keletas gerų santykių su klientais palaikymo principų:
- dažnas bendravimas. Reikėtų klientams teikti ne vien ataskaitas, bet ir laikas nuo laiko
paklausinėti, ar visi projekto aspektai jiems yra aiškūs;
- projekto grupės darbų pristatymas. Reikėtų stengtis (pvz., kviečiant į savo
susirinkimus), kad klientai suprastų, jog jų aktyvus domėjimasis projektu ir
reiškiamos pastabos jums yra svarbu;
- sutarimo siekimas. Jei su klientais buvo bendradarbiaujama projekto inicijavimo etape
derinant reikalavimus, tai juos reikėtų įtraukti ir į projekto problemų sprendimą ir
valdymą. Projekto grupė daugiau būna susikoncentravusi ties techniškais klausimais.
Tai gali iškreipti projekto tikslą, todėl klientų pastabos gali padėti išvengti nukrypimų;
- savalaikis nutarimų vykdymas. Jei iš kliento reikia papildomos informacijos ar
nutarimo patvirtinimo, išaiškinkite jam problemą ir nurodykite, kada nutarimas bus
įvykdytas;
- lūkesčių valdymas. Projekto vykdymo bėgyje klientas gali pamiršti projekto
reikalavimų, prielaidų, ribojimų ir kitą planavimo etape parengtą informaciją.
Nuolatinis projekto vykdymo eigoje gaunamų rezultatų ir suplanuotų dalykų
palyginimas padeda viską prisiminti ir stiprina klientų lūkesčius dėl projekto
rezultatų;
- faktų valdymas. Ginčai tarp projekto vykdytojo ir klientų gali kilti grynai dėl paskalų
ar spėlionių. Jei išgirstate, kad kliento atstovas yra nepatenkintas projekto rezultatais,
išsiaiškinkite faktus ir nepasitenkinimo priežastis. Jeigu rezultatai neatitinka projekto
dokumentuose užfiksuotų reikalavimų, priimkite kliento pastabas ir stenkitės
išspręsti problemą. Jei kliento pastabos išeina už numatytų projekto apimties ir
reikalavimų ribų, atmeskite kliento pastabas ir, jeigu reikia, supažindinkite jį su
projekto apimties keitimo procedūra.
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
93
Santykiai su sponsoriumi iškilus abejonėms. Visokie nesklandumai gadina projekto
vadovo gyvenimą. Jeigu nesate subūręs darnios projekto grupės ir santykiai su klientais nėra geri,
gali ateiti laikas, kai neteksite ir sponsoriaus paramos. Susvyravusi parama gali pasireikšti
įvairiais būdais. Galbūt bus nukeltas jūsų projekto peržiūros susirinkimas arba sponsorius staiga
nebeturės laiko projekto klausimams aptarti. Sponsorius gali ir permesti savo su projektu
susijusias pareigas projekto vadovui sakydamas, kad projekto problemų sprendimas yra jūsų, o
ne jo reikalas.
Sponsorius gali pradėti šalintis projekto dėl įvairių priežasčių:
- organizacijos vadovybės pasikeitimas gali iššaukti strategijos pokyčius;
- atsiradę gandai gali būti impulsu šalintis projekto;
- padidėjęs darbo krūvis;
- asmeninio gyvenimo problemos.
Nežiūrint priežasčių, dėl kurių pasikeitė sponsoriaus požiūris į projektą, projekto vadovas
turi išsiaiškinti jas ir siekti sprendimo. Reikėtų išsiaiškinti abejones sponsoriui sukėlusias
priežastis, rūpestingai išdėstyti jam savo nuomonę, pasitelkti sąjungininkus ar įtakingus asmenis.
Jei sprendimo nepavyksta pasiekti, projekto vadovas turėtų nuspręsti, ar ieškoti naujo
sponsoriaus, ar rekomenduoti nutraukti projektą. Jei rekomenduojama nutraukti, tai tą reikėtų
daryti iš karto, o ne „marinti“ projektą iš lėto.
Ryšys su funkcinių padalinių vadovais. Projekto vadovui gali atrodyti, kad jo santykiai su
organizacijos funkcinių padalinių vadovais apsiriboja tik projektui reikalingų išteklių gavimu iš
jų. Retai kada atsitinka taip, kad planavimo metu numatyti projektui reikalingi ištekliai staiga
taptų neprieinami. Tačiau jūsų projekto darbams įtakos gali turėti funkcinių padalinių vadovų
pažadų suteikti projektui išteklius (darbuotojus, įrangą) netesėjimas arba išteklių atsiėmimas
nespėjus projekte atlikti numatytų darbų.
Tokiais atvejais būtina šnekėtis su funkcinių padalinių vadovais ir ieškoti visoms šalims
priimtinų sprendimų. Jūs turite žinoti, kodėl ištekliai nebeskiriami ar atitraukiami iš jūsų
projekto ir kaip funkcinių padalinių vadovai siūlo spręsti dėl to projektui iškylančias problemas.
Jei atitrauktų išteklių pakeitimas kitais neturi įtakos galutiniams projekto rezultatams, tai reikėtų
sutikti su tuo, pvz., naujo žmogaus priėmimu į projekto grupę.
Gali pasitaikyti, kad siūlymas keisti darbuotoją pateikiamas kritiniu jūsų projekto
vykdymo laikotarpiu. Jeigu organizacijos funkcinio padalinio vadovas atsiima savo žmogų iš jūsų
projekto grupės, kuomet darbai yra įpusėję ir tuose darbuose jo vaidmuo yra svarbus, projektui
tai gali turėti nemažą neigiamą poveikį. Todėl jūs, kaip projekto vadovas, siekdamas išvengti
problemų, turėtumėte paaiškinti jam vedančiųjų programuotojų keitimo žalingumą tokiose
situacijose.
Jei funkcinio padalinio vadovas nesileidžia į kalbas ir dėl naujo darbuotojo paieškos teks
nukelti projekto įvykdymo terminą, apie susidariusią situaciją jūs turite informuoti sponsorių ir
laukti jo sprendimo. Būkite pasirengę drauge su sponsoriumi pasverti galimas problemų
pasekmes ir išdėstykite vykusių pokalbių su funkcinio padalinio vadovu rezultatus. Sponsorius
gali teikti projektui aukštesnį prioritetą, nei funkcinio padalinio tuo metu atliekamas darbas, ir
pratęsti funkcinio padalinio vadovo pažadėtų išteklių naudojimo laiką projekte.
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
94
Projekto vykdymo etapo metu atliekami pagrindiniai darbai. Todėl šalia grupės sudarymo,
santykių su akcininkais palaikymo projekto vadovui taip pat tenka sekti ir viso projekto eigą.
12.3. Darbų vykdymas pagal planą
Projekto eigoje vadovas turi užtikrinti, kad viskas vyktų pagal darbų grafiką, būtų
laikomasi biudžeto apribojimų ir kuriamo produkto kokybė atitiktų projekto apimties apraše
numatytus reikalavimus. Tą tenka daryti kiekvieną savaitę. Geram darbų koordinavimui projekto
vadovas turi rinkti duomenis apie atliktus darbus ir lyginti juos su projekto plane numatytų
kontrolinių taškų duomenimis.
12.3.1. Duomenų apie projekto eigą rinkimas
Tinkamam projekto valdymui reikia daug informacijos. Priemonės, kuriomis renkama ši
informacija, yra atliktų darbų ataskaitos, iškilusių problemų sąrašai (issues log), finansinės
ataskaitos.
Darbų ataskaitos. Dauguma jų yra susijusios su darbų grafiku. Turi būti nustatytas
ataskaitos formatas (žiūr. 12.1 lentelę) ir kaip dažnai jos turi būti teikiamos (paprastai – kas
savaitę).
12.1 lentelė. Darbų ataskaitos šablono pavyzdys
Užduotis Dirbta valandų Liko dirbti valandų Atliktų darbų
procentas Pastabos
Jei kai kurie grupės nariai vangiai teikia tokias ataskaitas, reikėtų kviesti susirinkimus ir jų
metu aptarti ataskaitų reikalingumą ir darbų eigos klausimus.
Iškilusių problemų sąrašai. Kiekvieno projekto eigoje atsiranda spręstinų klausimų. Jiems
registruoti ir sekti gali būti naudojamos atitinkamos lentelės, kuriose nurodoma iškilusi
problema, jos įtaka projektui, kas atsakingas už problemos sprendimą, esamas problemos stovis
(žiūr. 12.2 lentelę).
12.2 lentelė. Iškilusių problemų sąrašo šablonas
Problema Įtaka
projektui Atsakingas
asmuo Problemos
stovis Atsiradimo
laikas Išsprendimo
laikas
Problemų sąrašai paprastai peržiūrimi projekto grupės susirinkimuose.
Finansinės ataskaitos. Išleistų pinigų kiekis yra svarbi informacija projekto vadovui.
Dažnai ją tvarko organizacijos finansų padalinys, ir projektų vadovui tai nekelia didelių rūpesčių.
Tačiau nesant tokio padalinio, projekto vadovas pats turi rengti finansines ataskaitas.
Daugelio projektų vadovai peržiūri ir tvirtina savaitines projekto grupės narių ataskaitas
ir projektui panaudotos įrangos ar medžiagų sąrašus.
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
95
12.3.2. Projekto eiga pagal kontrolinius taškus
Darbų grafiko ir biudžeto plano kontroliniai taškai yra tas kelrodis, kurie padeda vykdyti
projektą taip, kaip buvo suplanuota. Minėtų dviejų dokumentų ir projekto apimties aprašo
duomenys nuolatos yra lyginami su tikraisiais projekto eigos duomenimis. Jei pastebimi kokie
nors nukrypimai nuo kontrolinių taškų, jūs turite imtis reikiamų priemonių.
Išvardinkime dalykus, kuriuos projekto vadovas turėtų stebėti.
Darbų grafiko laikymasis. Projekto grupės nariai gali nukrypti nuo darbų grafiko, o
centrinė projekto administracija, neįsigilinusi į darbų ataskaitas, gali norėti plėsti projektą. Bet
kuriuo atveju projekto vadovas kontroliniuose taškuose turi lyginti tikrąją projekto padėtį su
planuotąja. Ataskaitos apie darbų eigą arba grupės nariai susirinkimuose gali signalizuoti apie
pavojus, tačiau kartais į juos jūs galite nekreipti dėmesio. Kiekvienas grupės narys linkęs
koncentruotis ties jam pavesta užduotim, o ne ties bendru darbų srautu. Užduotis, kuriai atlikti
reikia papildomų dviejų dienų, gali neatrodyti kaip didelė problema. Tačiau jeigu trys kiti
darbuotojai dėl to negali pradėti savo darbų, tai jau yra rimta problema. Taip pat projekto
vadovas gali neturėti laiko kiekvienos nuo kontrolinio taško nukrypusios užduoties analizei,
tačiau jeigu užduotis yra darbų grafiko kritiniame kelyje arba ji yra susijusi su keliomis kitomis
užduotimis, į ją turi būti atkreiptas ypatingas dėmesys.
Biudžeto laikymasis. Oficialios bendrosios projekto biudžeto ataskaitos atspindi
kiekvienos užduoties arba tam tikros biudžeto kategorijos (straipsnio) tikrąsias išlaidas. Projekto
biudžeto ataskaitų duomenys lyginami su planuotaisiais kontroliniuose taškuose ir sprendžiama
apie biudžeto vykdymą. Biudžeto ataskaitos yra išlaidų nukrypimų (CV – Cost Variance) analizės
pagrindas.
Ataskaitos tam tikrais laiko tarpais arba tvirtinimui gauti važtaraščiai gali būti pirmieji
įspėjimo ženklai, kad projektas vyksta ne pagal planą. Jūs privalote atkreipti ypatingą dėmesį į
ataskaitas, kuriose nurodytas grupės narių darbo valandų kiekis viršija planuotąsias. Bet kurios
užduoties įvertis galėjo būti netikslus, tačiau jeigu grupės nariai per savaitę dirba daugiau
valandų nei planuota, jūsų projekto biudžeto išlaidos darbo užmokesčiui yra viršijamos.
Projekto apimties laikymasis. Projekto apimties aprašas yra dar vienas dokumentas, kuris
naudojamas projekto eigai stebėti. Kai baigiamas projekto etapas, pasitikrinkite, ar gauti
rezultatai atitinka nurodytus projekto apimties apraše.
Reikia būti atidiems, kad nepražiopsotume potencialių nukrypimų nuo planuotos projekto
apimties. Jei grupės nariai ypač svarbiems rezultatams gauti pastoviai sugaišta daugiau laiko, nei
buvo planuota, nedelsdami užduokite jiems klausimus. Jei apimtis keičiama be leidimo, greitai
spręskite šį klausimą.
Tvirtinami rezultatai. Specialus dėmesys turi būti skiriamas rezultatams kontroliniuose
taškuose, kuriuos turi peržiūrėti sponsorius ar akcininkai ir kurie turi būti tvirtinami. Jei yra
kokių nors nukrypimų, rezultatų tvirtinimas gali vėluoti, o kai kuriuos darbus gali tekti daryti iš
naujo.
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
96
12.4. Informacijos apie projekto eigą platinimas
Projekto vadovui tenka peržiūrėti daug duomenų. Daugumą jų reikia apibendrinti ir
pasidalinti su kitais. Informacijos platinimas – tai akcininkams reikalingos informacijos apie
projektą teikimas. Platinama pagal anksčiau parengtą komunikacijų planą, ir tai gali būti
atliekama įvairiais būdais: informuojant projekto grupės susirinkimuose, platinant ataskaitas
apie projekto stovį, formalias projekto apžvalgas.
12.4.1. Projekto grupės susirinkimai
Susirinkimai yra geriausias grupės bendravimo būdas. Jiems turi būti rengiamasi
kruopščiai, būtina turėti aiškią darbotvarkę, svarstytinus klausimus.
Susirinkimų vedimas. Blogai, jei grupės nariai pasibaigus susirinkimui išsiskirsto nieko
naujo nesužinoję. Produktyvus susirinkimas yra toks, kai projekto vadovas nubrėžia tolesnes
darbų gaires ir išsprendžia ginčus dėl kai kurių projekto darbų. Pasirengimas susirinkimui
reikalauja nemažai pastangų projekto planams ir eigos rezultatams peržiūrėti ir palyginti.
Pasirengimo susirinkimui ir jo vedimo žingsniai:
- susirinkimo laiko paskyrimas;
- dalyvavimo susirinkime svarbos pabrėžimas;
- susirinkimo darbotvarkės parengimas ir išplatinimas;
- susirinkimo pradėjimas ir baigimas numatytu laiku;
- laikymasis susirinkimo darbotvarkės;
- prašymas pasisakyti visus susirinkimo dalyvius;
- susirinkimo minučių paskirstymas.
Susirinkimo rezultatai. Projekto grupės susirinkimuose gali būti aptariami ne tik užduočių
vykdymo klausimai. Gerai organizuotas susirinkimas gali pagerinti grupės narių
bendradarbiavimą ir palengvinti įvairių problemų sprendimą.
Susirinkimai yra gera proga stebėti grupės narių bendradarbiavimo lygį. Tikėtina, kad
grupės nariai gali nežinoti visų užduočių niuansų, todėl jų bendradarbiavimas yra būtinas. Jei
reikia, projekto vadovas gali paskirti laiką pagrindinių projekto laukiamų rezultatų tarpusavio
sąsajoms aptarti.
Jei pastebima, kad tarp projekto grupelių yra prastas ryšys ir tai gali turėti įtakos darbų
grafiko kritiniame kelyje esančių užduočių atlikimui, būtina imtis skubių priemonių, kad žmonės
gautų informaciją apie tas užduotis, nuo kurių rezultatų priklauso jų tolesni darbai.
Projekto vadovo pareiga yra skatinti grupės narių glaudų bendradarbiavimą.
Užrašų įvairiais klausimais (issues log) peržiūra turėtų būti kiekvieno projekto grupės
susirinkimo dalis. Tam sugaištama nedaug laiko, nes už kiekvieno užrašuose pasižymėto
klausimo (problemos) išsprendimą iki nurodyto laiko būna nurodytas atsakingas asmuo (žiūr.
12.2 lentelę). Atsakingam asmeniui tereikia informuoti apie esamą padėtį.
Problemų sprendimas. Projekto grupei nuolatos tenka svarstyti rūpesčius keliančias
problemas. Projekto vadovo pareiga padėti grupės nariams spręsti jas. Žmonės dažnai yra linkę
skubėti su sprendimais, todėl būtina įsitikinti, ar problema apibrėžta aiškiai ir ar yra sutarimas
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
97
dėl jos sprendimo būdo. Skyrus nedaug laiko apmąstymams, gali būti rastas didelių grupės
pastangų nereikalaujantis problemos sprendimo būdas.
Dažniausiai projekto grupės diskusijų tema būna darbų atlikimo vėlavimas. Sprendžiant
šias problemas reikėtų:
- išsiaiškinti vėlavimo priežastis;
- įvardinti už tai atsakingą grupės narį;
- sudaryti koregavimo veiksmų planą;
- atlikti koregavimo veiksmus;
- stebėti rezultatus.
Apie projekto eigą turi būti informuojami ne vien tik grupės nariai, bet ir akcininkai.
12.4.2. Ataskaitos apie projekto eigą
Ataskaitos apie projekto eigą yra kitas informacijos platinimo būdas. Sponsoriui,
akcininkams, klientams nereikia visų detalių apie projektą, kurios reikalingos projekto grupės
nariams. Tačiau jie nori būti informuoti apie projekto eigą. Dėl to daugelio projektų komunikacijų
planuose yra numatytas reguliarus ataskaitų apie projekto eigą platinimas.
Ataskaitos apie projekto eigą gali būti platinamos naudojant bendro naudojimo katalogus
(failus), el. paštą. Specifiniai platinimo būdai turi būti nurodyti komunikacijų plane. Ataskaitų
formatas turėtų būti pastovus. Paprastai jose būna:
- projekto stovio, palyginto su darbų grafiko ir biudžeto kontroliniais taškais,
santrauka;
- pagrindinių rezultatų arba plano kontroliniuose taškuose įvardintų rezultatų
pasiekimo lygis;
- svarbiausių klausimų stovis.
12.4.3. Projekto apžvalgos
Projekto apžvalgos yra daugiau formalus informacijos apie projektą platinimo sponsoriui,
akcininkams ir klientams būdas. Jei ataskaitos apie projekto eigą rengiamos beveik visuose
projektuose, tai apžvalgos nėra privalomos ir jų struktūra priklauso nuo organizacijoje
pasirinktos.
Reguliarios projekto apžvalgos gali būti atliekamos kas mėnesį ar kas metų ketvirtį. Jų
rengimas gali trukti net keletą dienų, dalyvaujant visiems su projekto vykdymu susijusiems
vadovams.
Apžvalgai reikalinga informacija gali priklausyti nuo sponsoriaus ar jūsų organizacinių
poreikių. Sponsoriui skirtą apžvalgą parengti nėra sunku, nes jūs galite žinoti jam rūpimus
klausimus. Jei apžvalga rengiama platesnei auditorijai, reikėtų surinkti pageidavimus, apie ką
klausytojai norėtų išgirsti.
Apžvalgos pristatymo darbotvarkėje reikėtų numatyti laiko tarpą kiekvienam klausimui.
Apžvelgtini klausimai:
- pagrindiniai pasiekimai einamosios apžiūros periode;
- biudžeto suvestinė;
- pagrindiniai klausimai;
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
98
- rizikos mažinimo ir reakcijos į jos veiksnius planai;
- planuojami pasiekimai kitos apžvalgos laikotarpiui.
12.3 lentelėje parodytas projekto apžvalgos lapo pavyzdys.
12.5. Sandorių su tiekėjais priežiūra
Daugelyje projektų reikalinga išorinių tiekėjų pagalba. Jei jūs esate sudarę sandorius
darbams atlikti, neišvengiamai tenka administruoti juos. Tai stebėjimas ir tikrinimas, ar tiekėjai
laiku atlieka sutartus darbus.
12.5.1. Tiekėjų atliekamų darbų ataskaitos
Tiekėjų darbų ataskaitos yra tiek pat svarbios, kaip ir projekto grupės narių ataskaitos.
Tiekėjų darbų rezultatai turi būti gaunami laikantis jūsų projekto darbų grafiko, ir grupės narių
atliekamos užduotys gali priklausyti nuo jų.
Ataskaitų apie atliktus darbus teikimas turi būti numatytas sandorio darbų užduotyje
(SOW). Ryšiai su tiekėjais yra daugiau formalaus pobūdžio ir turi teisinę potekstę.
12.3 lentelė. Projekto apžvalgos lapo pavyzdys
Projekto apžvalga
Apžvalgą parengė:
Pagrindiniai pasiekimai:
1. Pasiekimas ...
2. Pasiekimas ...
Problemos
Problemos pavadinimas Esamas stovis
Biudžetas
Planuotasis Einamasis
Turimos lėšos
Išlaidos
Pagrindiniai rizikos veiksniai
Rizikos veiksniai, jų galimas poveikis Rizikos mažinimo planas
Galimos kliūtys:
1. Kliūtis ...
2. Kliūtis ...
Planuojami pasiekimai iki kitos apžvalgos:
1. Planuojamas pasiekimas ...
2. Planuojamas pasiekimas ...
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
99
Netgi jei tiekėjų ataskaitų detalės yra nurodytos darbų užduotyje (SOW), projekto vadovas
turi įsitikinti, ar tiekėjas pateikia reikiamus duomenis ir reikiamo pavidalo. Savaitinėse
ataskaitose turi būti aiški informacija apie tiekėjo pasiektus rezultatus, nurodant atliktų darbų
procentą, rezultatų pristatymo datos patvirtinimą, problemas ir riziką, dėl ko gali būti vėluojama
pateikti rezultatus.
Kai kurie projektų vadovai organizuoja mėnesinius ar kitokio dažnumo susitikimus su
tiekėjais darbų eigai apžvelgti ir problemoms apsvarstyti.
12.5.2. Nesutarimų su tiekėjais aiškinimasis
Projekto grupės nariai ir tiekėjas kai kuriuos užduoties tiekėjams punktus gali suprasti
skirtingai. Gali būti nesutarimų dėl programavimo technologijų (pvz., senųjų ar objektinio
programavimo) pasirinkimo. Neigiamą poveikį gali turėti „ego veiksnys“ (aš esu labai protingas,
darykite kaip pasakysiu). Galimi ginčai ir dėl platformos.
Visi tokie nesutarimai turi būti svarstomi geranoriškai ir siekiama abiem šalims priimtinų
sprendimų. Nepavykus susitarti elgiamasi pagal sandoryje išdėstytas nuostatas.
12.5.3. Tiekimų vėlavimai
Kai gaunama informacija apie tiekimų vėlavimus, apie susidariusią padėtį reikėtų
informuoti suinteresuotus asmenis. Projekto vadovas turėtų imtis tokių veiksmų:
- susitikti su tiekėju ir gauti daugiau specifinės informacijos apie tiekimo vėlavimą. Gal
įmanoma sutrumpinti vėlavimo laiką ar pateikti dalį produkcijos, kokių veiksmų imasi ir kokias
problemas sprendžia tiekėjas tokioje situacijoje;
- informuoti savo organizacijos pirkimų ir teisės departamentus. Be jų sutikimo jūs
neturėtumėte keisti savo darbų grafiko, nutraukti sandorį ar reikalauti baudų;
- peržiūrėti vėlavimo įtaką visam projekto planui. Bet koks tiekimo vėlavimas reikalauja
peržiūrėti projekto apimtį, darbų grafiką, biudžetą, reikalavimus ištekliams. Dėl tiekimo vėlavimo
atsiranda nauji rizikos veiksniai ir būtina peržiūrėti rizikos valdymo planą;
- informuoti sponsorių kaip galima greičiau ir nurodyti jam galimą vėlavimų įtaką
projekto planui. Jei ta įtaka yra svari, sponsorius gali šią problemą kelti į aukštesnį lygmenį,
šnekėtis su tiekėjo vadovybe;
- informuoti akcininkus kaip galima greičiau. Tiekimų vėlavimai gali tapti gandų apie
projekto gyvybingumą priežastimi, todėl geriau, kad ir akcininkai žinotų tuos vėlavimo faktus.
12.5.4. Atsiskaitymai su tiekėjais
Sandoriuose su tiekėjais nurodoma, kaip su jais bus atsiskaitoma. Atsiskaitymai gali būti
reguliarūs arba susieti su atliktų darbų priėmimu. Netgi jei organizacijos finansų departamentas
tvarko atsiskaitymus, projekto vadovas yra pirmasis sąskaitų gavėjas.
Jei jūs esate atsakingas už mokėjimo sąskaitų patvirtinimą, pasitikrinkite, kad suprantate
gautą sąskaitą ir esate dalyvavęs rengiant to mokėjimo garantiją.
Jei tiekėjui turi būti mokama remiantis darbų grafike numatytais rezultatais, jūs turite
patvirtinti tų rezultatų gavimą ir priėmimą. Tam turi būti peržiūrėta ir patikrinta tiekėjo
pristatytos produkcijos kokybė ir tik tada tvirtinamas mokėjimas.
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
100
Tiekėjo žmonių išlaidoms apmokėti turi būti pateikiami kvitai ir kokiems tikslams tos
išlaidos buvo padarytos. Jei nesate tikras pateiktos sąskaitos teisingumu, kreipkitės į savo
organizacijos finansininką, kad jis peržiūrėtų tą tiekėjo sąskaitą.
Jeigu jums nėra aiški sandoryje nustatyta atsiskaitymų tvarka, kreipkitės į savo
organizacijos pirkimų padalinį ir prašykite paaiškinti. Jie juk yra sandorių ekspertai ir gali padėti
jums. Jei jūsų ir tiekėjo nuomonės dėl atsiskaitymo sumos skiriasi, reikėtų kviestis pirkimų
ekspertą ginčui išspręsti.
12.5.5. Reikalų su tiekėjais tvarkymas
Dalykiški santykiai. Projekto eigoje grupei tenka turėti „aukšto lygio“ santykius su tiekėju.
„Aukštas lygis“ reiškia, kad yra numatyti formalūs susirinkimai, kurių metu jūs ir tiekėjas turite
galimybes kelti problemas ir siūlyti sprendimus teisės aktų ir sandorio ribose. Jei nepavyksta
pasiekti susitarimo dėl sandoryje numatyto, bet darbų užduotyje (SOW) gerai neapibrėžto
kažkokio darbo, projekto eigos svarstymo susirinkime turi būti aiškiai nurodomi trūkumai ir
įvardinamos problemiškos sritys, kuriose tiekėjas nenori toliau tęsti darbų, nes jie nebuvo
numatyti darbų užduotyje.
Apskritai, tiekėjai stengiasi padėti projekto vykdytojams tose srityse, kur jie yra
kompetentingi. Bet jie tampa irzlūs, kai jų prašoma padaryti tai, kas nebuvo aiškiai apibrėžta
sandorio darbų užduotyje. Tai dažniausia projektų vadovų ir tiekėjų ginčų priežastis.
Įsitikinkite, kad tiekėjas gerai supranta jūsų poreikius. Su tiekėju kruopščiai išnagrinėkite
sandorio darbo užduotį (SOW), kad ateityje nekiltų neaiškumų, ką už sutartą sumą reikėjo
padaryti.
Gerai pasirenkite deryboms su tiekėju, būkite griežti ir tikslūs. Kartais manoma, kad
baigus svarstyti kažkokį klausimą yra priimtas ir susitarimas. Ne veltui sakoma, kad kuo didesnis
sandoris, tuo didesni tiekėjo pažadai. Pasistenkite raštu užfiksuoti tuos pažadus ateičiai, kai teks
vėl grįžti prie anksčiau svarstyto klausimo. Tada pokalbį jūs galėsite pradėti sakydami, kad norite
pasitikslinti tai, ką tiekėjas yra kažkada pažadėjęs.
Projekto vykdymo metu tokie numatomi (tylūs) susitarimai sutinkami dažnai. Tarkime,
pvz., jums ir tiekėjui svarstant kokį nors projekto komponentą jis sako: „aš kai ką pasitikrinsiu ir
vėliau grįšim prie to komponento. Aš manau, kad mūsų kompanija gali jį pateikti jums veltui“. Šį
klausimą jūs atidedate kažkuriam laikui. Vykdant projektą jums prireikia to komponento. Jei
pažadas nebuvo užfiksuotas raštu, jūs galite turėti keblumų dėl tiekėjo neįvykdyto pažado.
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
101
13. PROJEKTO KONTROLĖ
Projekto eigoje vadovas turi pastoviai stebėti gaunamus rezultatus. Nukrypimai nuo
projekto plano gali būti perspėjimas, kad reikia daryti pradinio (originalaus) plano korekcijas.
Projekto eigoje gali atsirasti naujų reikalavimų ir/ar pageidavimų plėsti projekto apimtį. Todėl
būtina numatyti ir apgalvotai vykdyti projekto plano keitimo procedūras.
Integruotoji keitimų kontrolės sistema įvertina bendrąjį keitimų poveikį visam projektui ir
padeda padaryti juos visuose projekto plano elementuose. Pvz., jei daromi projekto apimties
keitimai, tai gali tekti koreguoti ir darbų grafiką, biudžetą.
Projekto plano keitimai verčia akcininkus daryti kompromisą tarp projektą ribojančių
veiksnių: laiko, kainos, kokybės, apimties.
13.1. Integruotoji keitimų kontrolė
Projekto planavimo etape numatytus dalykus vėliau kartais tenka keisti. Keitimų
priežastis gali būti pasikeitusi verslo strategija, konkurencinė grėsmė, naujų technologijų
atsiradimas, kas nebuvo žinoma planavimo metu.
Projekto eigoje gali tekti keisti įvairius plano elementus. Kad išvengtume netvarkos,
pakeitus kažkurį plano elementą, nepamirškime atitinkamai pakoreguoti ir kitų plano elementų.
Tam ir yra reikalinga integruotoji keitimų kontrolės sistema.
Keitimų kontrolė gali būti atliekama įvairiai. Tam, pvz., gali būti sudarytas keitimų
kontrolės komitetas iš sponsoriaus, akcininkų ir projekto vykdytojų, kurie peržiūri visus
prašymus ir leidžia arba neleidžia daryti keitimus, arba prašymus gali svarstyti projekto grupė.
Didesniuose ir sudėtingesniuose projektuose keitimų kontrolė paprastai turi didesnį formalumo
laipsnį. Nežiūrint to, kas peržiūri ir tvirtina projekto plano keitimus, apie projekto plane
numatytas ribas viršijančius keitimus turi būti informuojami akcininkai. Jie išdėsto savo
nuomonę apie tokius keitimus.
Panagrinėkime smulkiau, ką apima projekto apimties, darbų grafiko, kainos ir kitų
projekto plano elementų keitimo kontrolė.
13.1.1. Projekto apimties keitimo kontrolė
Projekto apimties plano (žiūr. 3 skyrių) viena iš dalių yra apimties valdymo planas.
Projekto eigoje, prireikus keisti projekto apimtį, vadovaujamasi šiuo planu. Apimties keitimo
kontrolė yra bet kokių projekto apimties keitimų valdymas ir dokumentavimas.
Štai keletas priežasčių, verčiančių keisti projekto apimtį:
- projekto rezultatų peržiūros metu nustatyta, kad gauta papildomų rezultatų, kurie
nebuvo numatyti projekto plane;
- projekto grupės nariai įrodo, kad reikia keisti projekto reikalavimus;
- yra formalus prašymas papildyti projekto siekiamus rezultatus naujais;
- pasikeitė kuriamo produkto projektas (design).
Idealiu atveju projekto apimtis neturėtų būti keičiama be formalaus patvirtinimo
(leidimo). Tačiau projekto vykdytojai, pasikalbėję su naudotojais arba savo nuožiūra, kartais
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
102
padaro tai ar taip, kas nenumatyta projekto apimties plane. Jei jūs pastebite, kad tapote
nukrypimo nuo planuotos projekto apimties auka, o pakeitimas jau yra padarytas, reikėtų siekti,
kad būtų išanalizuota pakeitimo įtaka kitoms projekto dalims ir kad pakeitimas formaliai būtų
patvirtintas.
Apžvelkime keletą projekto apimties keitimo žingsnių ir patarimų:
- naudokime standartinės formos prašymą projekto apimties keitimams daryti,
aprašykime norimą keitimą, jo priežastį ir kas yra prašytojas;
- išanalizuokime prašomo keitimo įtaką projekto biudžetui, darbų grafikui, kuriamo
produkto kokybei;
- naudokime patvirtintas procedūras prašymams priimti ar atmesti;
- apie prašymą keisti projekto apimtį informuokime visus akcininkus;
- patvirtintus keitimus įtraukime į projekto planą.
Projekto apimties keitimai gali iššaukti koregavimo veiksmus ir/ar kontrolinių taškų
projekto plane keitimą.
Koregavimo veiksmai. Jūs, kaip projekto vadovas, pakeistai projekto apimčiai galite
nepritarti ir nenorėti plėtoti to pakeitimo. Jums gali tekti ieškoti kelių, kaip sugražinti projektą į
ankstesnes vėžes. Tam gali tekti sugaišti kažkiek laiko. Taip pat jūs galite norėti išsiaiškinti, kodėl
buvo nukrypta nuo projekto planuotos apimties ir ko reikėtų imtis, kad tai neatsitiktų ateityje,
pvz., apšviesti projekto grupės narius apimties keitimo klausimais.
Kontrolinių taškų derinimas. Bet koks planuotas ar neplanuotas projekto apimties
keitimas reikalauja pakoreguoti dalį pradinio projekto plano. Mažiausiai, tenka koreguoti
projekto apimties aprašą. Priklausomai nuo keitimų dydžio, taip pat gali tekti keisti darbų grafiko
ir biudžeto kontrolinius taškus.
Projekto apimties keitimas gali turėti žymią įtaką suplanuotam darbų grafikui.
13.1.2. Darbų grafiko kontrolė
Projekto grupės narių darbo ataskaitų atitikimo projekto darbų grafikui peržiūros tikslas
yra įsitikinti, ar projektas vyksta normalia vaga, ar reikalingi kokie nors keitimai, galintys
pagerinti kritinio kelio darbus. Darbų grafiko kontrolė yra bet kokio darbų grafiko keitimo ir
tokių keitimų dokumentavimo procesas.
Projektams valdyti skirta programinė įranga yra puiki priemonė, įgalinanti kontroliuoti,
kaip laikomasi darbų grafiko. Ji gali pateikti individualių užduočių planuotų pradžios ir pabaigos
laikų palyginimo su tikruoju laiku rezultatą, prognozuoti bet kokių pradinio darbų grafiko
pakeitimų poveikį atskiroms užduotims, kritiniam darbų keliui ir projekto pabaigos terminui.
Taip pat galima modeliuoti įvairius „o kas, jeigu“ scenarijus, stebėti, kokią įtaką atskiriems
projekto etapams ar galutiniam terminui turi užduočių trukmės pakeitimas arba naujos
papildomos užduoties įtraukimas į patvirtintą projekto planą.
Projekto grupės narių darbo ataskaitos ir kitos ataskaitos visų pirma naudojamos kritinio
kelio darbų eigai įvertinti. Prisiminkime, kad kritinis kelias – tai ilgiausias kelias projekto darbų
grafike, ir bet kokios užduoties jame atlikimo vėlavimas gali pailginti viso projekto laiką.
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
103
Darbų grafiko kontrolės rezultatai – tai grafiko naujinimai, kitų projekto elementų
korekcijos, įgyta patirtis.
Darbų grafiko naujinimai – tai bet kokie projekto darbų grafiko keitimai. Dažniausiai jie
atliekami kas savaitę, remiantis projekto grupės narių darbo ataskaitomis ir gautų rezultatų
palyginamu su grafiko kontrolinių taškų duomenimis.
Kitų projekto elementų korekcijos. Prireikus keisti darbų grafiką, neišvengiamai tenka
koreguoti ir kitus projekto elementus – išteklius, biudžetą, komunikacijas, kokybę, riziką.
Įgyta patirtis. Projekto vykdytojai sužino, dėl kokių priežasčių teko keisti darbų grafiką ir
ką reikėtų daryti, kad kituose projektuose tokių keitimų būtų išvengta.
Projekto apimties ir darbų grafiko keitimai reikalauja papildomų išlaidų.
13.1.3. Išlaidų kontrolė
Tai procesas, kurio metu tikrinamos padarytos išlaidos, nustatomi nukrypimai nuo
biudžeto kontrolinių taškų, imamasi reikiamų korekcijų (pvz., dėl lėšų stygiaus galbūt bus kažko
atsisakoma: funkcionalumo, kokybės, kt.).
Išlaidų kontrolės rezultatas – peržiūrėti kainų įverčiai, kitų projekto elementų korekcijos,
įgyta patirtis.
Įvertintų kainų peržiūra. Laikui bėgant išteklių kainos kinta. Planavimo etapo metu jos
galėjo būti vienokios, o projekto vykdymo metu jos gali būti jau kitokios. Įvertinus planuotos
kainos ir einamosios kainos skirtumą, reikia imtis korekcinių veiksmų.
Kitų projekto elementų korekcijos ir įgytos patirties požiūriu samprotavimai yra panašūs,
kaip ir darbų grafiko kontrolės atveju.
13.1.4. Kitų projekto plano elementų keitimo kontrolė
Projekto apimtis, darbų grafikas, biudžetas yra pagrindiniai kontrolės taikiniai. Tačiau be
jų projekto plane yra ir kitos dalys, kurias taip pat gali reikėti keisti projekto eigoje. Žvilgtelkime
dar į keturių elementų - išteklių, reikalavimų, infrastruktūros ir konfigūracijos - keitimą.
Išteklių keitimas. Kai tik projekto grupė papildoma nauju nariu arba ją palieka narys,
būtina užfiksuoti darbuotojo pasikeitimo priežastį, naujo nario ir išėjusio žmogaus pavardę,
pasikeitimo poveikį projektui.
Reikalavimų keitimas. Tai sudėtinga valdymo sritis. Jei reikalavimai yra papildomi naujais
arba keičiami norint pagerinti jų aiškumą, būtina atkreipti dėmesį į tai, ar tokie pakeitimai neturi
įtakos projekto apimčiai. Bet koks naujas reikalavimas turi praeiti keitimų kontrolę.
Infrastruktūros keitimas. Infrastruktūra – tai tokie elementai, kurie ilgai išlieka pabaigus
projektą. Pvz., projekto grupės narys galėjo planuoti, kad duomenų bazės valdymo sistemą leis
UNIX platformoje, tačiau tinklo tvarkymo grupė projekto eigoje paprašė pastarąją pakeisti į
WINDOWS. Infrastruktūros elementai, kurie gali būti keičiami:
- skaičiavimo sistema;
- programinės įrangos kūrimo aplinka;
- serverio operacinė sistema;
- tinklo infrastruktūra;
- tiekimo metodologijos.
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
104
Konfigūracijos keitimas. Dažniausiai projekto grupė sprendimus dėl programinės ar
aparatinės įrangos konfigūracijos daro tada, kai mato, jog jų sukurtas produktas geriau dirbtų
kitaip sukonfigūruotoje aplinkoje. Dažnai sutinkamas konfigūracijos keitimo pavyzdys yra toks.
Duomenų bazės projektuotojai pasirenka vienokią indeksų sistemą ir naudoja ją projektuojamoje
bazėje. Bet programuotojai, rašantys programas darbui su tokia baze, gali manyti, kad kitokia
indeksų sistema yra geresnė. Taip gimsta konfigūracijos keitimo prašymas.
Konfigūracijos keitimai gali būti labai paprasti ir gana sudėtingi. Tai priklauso nuo
konfigūracijos prigimties ir ko tikimasi iš programinės ar aparatinės įrangos. Tačiau dažniausiai
konfigūracijai pakeisti nereikia daug laiko (pakanka poros valandų), todėl tai nėra didelė kliūtis
projektams. Nereikėtų pamiršti, kad kai kurie konfigūracijos keitimai reikalauja iš naujo pakrauti
(reboot) sistemą ir todėl konfigūracijos keitimo rezultatai tampa prieinami tik po kažkurio laiko.
13.2. Kokybės kontrolė
Kokybės klausimas dažnai susilaukia mažesnio dėmesio nei projekto apimties, biudžeto ar
darbų grafiko klausimai. Tačiau kokybės kontrolės stoka gali skaudžiai atsiliepti projektui.
Kokybės kontrolė yra procesas, kurio metu stebima, ar projekto rezultatai atitinka nustatytų
standartų reikalavimus, ar nereikia daryti atitinkamų keitimų, kad būtų pašalintos neigiamą
poveikį kokybei darančios priežastys. Kokybės valdymo planas (žiūr. 7 skyrių) yra specifinių
kontrolės veiklų pagrindas.
Kokybė kontroliuojama visą projekto vykdymo laiką. Projekto darbų grafike pažymėti
etapai nurodo, kada turi būti gauti pagrindiniai rezultatai. Kokybės tikrinimo priemonėmis ir
būdais įsitikinama, ar gauti rezultatai yra tinkamo lygio. Kokybės tikrinimo veiklos yra svarbios
projekto etapo užbaigimui patvirtinti.
Tarp įvairių projekto darbų rezultatų kokybės sekimo būdų bene labiausiai išsiskiria
tikrinimas (testavimas). Patikrinus kokybę galimi tokie tolesni žingsniai projekte: užduoties
atlikimas iš naujo, keitimų darymas, rezultatų priėmimas, nežiūrint, kad yra kai kurių defektų.
13.2.1. Tikrinimas (testavimas)
Tikrinimas yra plati sąvoka, apimanti apžiūrą, matavimą, testavimą. IT projektuose
tikrinimas dažniausiai vadinamas testavimu.
Testavimui atlikti paprastai reikia laiko. Testavimas yra įkyrus darbas. Kažkoks modulis
leidžiamas dar ir dar kartą, jo veikimas tikrinamas įvairiais požiūriais.
IT projektams bendros yra šios testavimų rūšys:
Modulio testavimas. Programuotojas, baigęs kurti modulį, turi ištestuoti jį. Kai kurie
moduliai, kurie skirti darbui drauge su kitais moduliais, nesiduoda testuojami. Vis dėlto
programuotojas gali patikrinti kai kuriuos jo elementus. Leisdamas modulio programą per
tikrinimo priemonę (checker) eilutę po eilutės, jis patikrina jo veikimą. Procesas gali būti labai
įdomus arba gniuždantis, jei modulis kažką daro klaidingai, o rasti klaidos programoje nesiseka.
Modulių rinkinio (unit) testavimas. Tai, pvz., modulių rinkinys kažkokio tipo uždaviniams
spręsti: piešti grafikams, apdoroti vaizdams, spausdinti ataskaitoms, kt.
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
105
Sistemos testavimas. Tai visos sistemos testavimas ir jis gali trukti ilgai. Tikrinamas
funkcionalumas, veikimo greitis, tikslumas, saugumas, t. t.
Tinkamumo naudotojams testavimas (UAT – User Acceptance Testing). Tą atlieka
nedidelis naudotojų ratas kažkurį laiką. Stebima, ar nėra klaidų (bugs), greičio, loginių ar
apkrovos problemų. Sistema turi būti tokia, kokios naudotojai tikėjosi.
Tinkamumo įmonei testavimas (FAT – Factory Acceptance Testing). Dideles sistemas
testuoti yra geriausia tose vietose, kur jos buvo sukurtos. Pvz., orų prognozės radarų sistema,
kuri buvo papildyta nauja aparatine ir programine įranga. Visa tai išbandoma pas kūrėją
(pardavėją) ir tik po to perkeliama į pirkėjų nurodomas vietas. Šitokį testavimo būdą naudoja
didelių valstybinių užsakymų vykdytojai.
Tinkamumo konkrečiai vietai testavimas (Site Acceptance Testing). Produktas
testuojamas pristačius jį į pirkėjo nurodytą vietą. Pvz., anksčiau turėtas radarų sistemos
pavyzdys. Nors ji buvo išbandyta kūrėjo aplinkoje, tačiau dar patikrinama, kaip sistema veikia
pirkėjo aplinkoje.
Testavimas visada yra svarbus IT projekto kokybės patvirtinimo žingsnis. Kai kuriais
atvejais reikia dar daugiau tikrinimų, priklausančių nuo įvairių veiksnių.
Geografiškai išbarstyta grupė. Projekto grupė dažnai būna išdėstyta keliose vietose.
Programinė įranga gali susidėti iš keleto modulių, kuriuos kuria skirtingos programuotojų
grupės. Nors ryšys tarp grupių ir yra geras, tačiau betarpiškų asmeninių kontaktų nebuvimas gali
padidinti skirtingo supratimo riziką, gali iššaukti skirtumus moduliuose, kas turėtų įtakos visam
programų paketui. Tokiais atvejais reikėtų detalesnio kiekvieno modulio testavimo.
Tiekėjų pristatomi produktai. Tiekėjų pristatomų produktų testavimas turi ypatingą
reikšmę. Ypatumas yra tame, kad testavimo būdas ir laikas turi būti numatyti sandoryje. Tiekėjo
pristatyto produkto ir visos likusios sistemos integruotasis testavimas duoda atsakymą, ar
pristatytas produktas yra priimtinas. Tiekėjo produkto priėmimas reiškia, kad jam už darbą turi
būti apmokėta. Taigi šiais testais turi būti patikrintas visų sandorio darbams keltų reikalavimų
įgyvendinimas.
Nors testavimas yra dažniausiai naudojamas IT projektų kokybės kontrolės būdas, tačiau
jis nėra vienintelis.
13.2.2. Kiti kokybės kontrolės būdai ir priemonės
Pareto diagrama. Ji naudojama laiko bėgyje atsirandančių problemų svarbai ir dažniui
pavaizduoti. Pareto (Vilfredo Pareto) diagramos pagrindas yra vadinamoji 80 / 20 taisyklė. Šis
mokslininkas pastebėjo, kad Italijoje 80% turto priklauso 20% jos gyventojų. Šis principas buvo
perkeltas į daugelį disciplinų (pvz., manoma, kad 80% projekto darbų padaro 20% darbuotojų).
Taikant šį principą kokybės kontrolėje, sakoma, kad didžiosios projekto defektų dalies priežastis
yra nedidelis problemų rinkinys. Pareto diagrama padeda atskirti, kurios problemos yra
svarbiausios ir turi didžiausią poveikį projektui. Problemos atvaizduojamos stačiakampiais,
išdėstytais mažėjimo tvarka. Kuo problema sukelia daugiau defektų, tuo didesnis stačiakampis, ir
jai išspręsti turėtų būti skiriama daugiau dėmesio (žiūr. 13.1 pav.).
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
106
Pareto diagramos tikslas yra dvejopas:
- pavaizduoti defektų reliatyvią svarbą;
- nurodyti problemas, kurioms išspręsti turi būti dedama daugiausia pastangų ir kurios
daro didžiausią poveikį projektui.
13.1 pav. daugiausia defektų atsiranda dėl A ir B problemų (pvz., A problema –prasti
programavimo įgūdžiai). Išsprendus vien tik jas, projekte būtų pašalinta 60-70% visų defektų.
Todėl A ir B problemoms turėtų būti skiriamas pagrindinis dėmesys.
Kontrolinės diagramos yra naudojamos kontroliuojamo parametro svyravimams laike
pavaizduoti. Jos dažniausiai naudojamos apdirbamojoje pramonėje. Tokiose diagramose svarbios
yra vidutinė, viršutinė ir apatinė leistinos reikšmės (žiūr. 13.2 pav.). Pvz., reikia ištekinti tam
tikro diametro detales. Realiai jos bus kažkiek didesnės ar mažesnės. Jei kontrolierius nustato,
kad jų diametras yra tarp viršutinės ir apatinės leistinų ribų, tokios detalės yra tinkamos.
Geriausia, kai jų diametras būna artimas vidutinei reikšmei.
Statistinė atranka. Jeigu jūs turite daugelio darbų rezultatus (pvz., daug ištekintų detalių),
visų jų tinkamumui įvertinti reikėtų atlikti daug matavimų. Tai užimtų daug laiko ir būtų brangu.
Pasitelkus statistinės atrankos metodą, atsitiktinai paimami tik kelių darbų rezultatai, jie
išmatuojami ir sprendžiama apie visų darbų rezultatų (visos detalių partijos) kokybę.
Defektų
dažnumas
1000
750
500
250
A B C D E problema
Suvestinis
defektų
procentas
100%
75%
50%
25%
13.1 pav. Pareto diagramos pavyzdys
5,06
5,00
4,94
Viršutinė riba
Vidutinė reikšmė
Apatinė riba
13.2 pav. Kontrolinės diagramos pavyzdys (taškas – matavimo reikšmė)
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
107
Projekto struktūrinė (blokinė) schema ir proceso diagrama. Apie jas rašyta 7 skyriuje,
nagrinėjant kokybės planavimo klausimus. Struktūrine schema paprastai atvaizduojami sąryšiai
tarp įvairių projekto elementų. Struktūrinė schema arba duomenų sekų diagramos (DFD – Data
Float Diagram) padeda numatyti galimų problemų atsiradimo vietą ir laiką. Todėl tokios
diagramos gali būti labai naudingos ir projekto rezultatų kontrolės metu, nustatant problemos
atsiradimo priežastį.
Tendencijų analizė. Tai matematiniai metodai, įgalinantys prognozuoti defektų atsiradimą,
remiantis anksčiau sukauptais rezultatais.
Testavimas ar kitokie kontrolės būdai naudojami tam, kad nustatytume, ar nereikia imtis
priemonių, kad gautume geresnius rezultatus.
13.2.3. Veiksmai kokybės neatitikimo atvejais
Jei projekto rezultatų (tarpinių ar galutinių) kokybė neatitinka keliamų reikalavimų,
sprendžiama, kokių veiksmų reikėtų imtis trūkumams pašalinti. Dažniausiai imamasi tokių
veiksmų: perdarymo, projekto vykdymo proceso pareguliavimo, susitaikymo su atsiradusia
blogybe.
Perdarymas. Tai bet kuri defektų šalinimo veikla. Pvz., patikrintame programinės įrangos
modulyje aptikus neatitikimus, perrašoma jo programa.
Perdarymams reikia laiko ir lėšų, todėl gali tekti daryti projekto darbų grafiko ir biudžeto
pakeitimus.
Sprendimas dėl produkto perdarymo priklauso nuo aptikto defekto sunkumo ir jo įtakos
galimybei naudoti produktą. Apie defektą reikėtų informuoti sponsorių, akcininkus, klientus ir
pasitelkti juos priimant sprendimą.
Projekto vykdymo proceso pareguliavimas. Bet kurio proceso pareguliavimas gali
atsiliepti visam projektui. Jeigu neaišku, ar proceso pareguliavimas palies tik nedidelę darbuotojų
grupelę ir neturės platesnių pasekmių, geriausia išanalizuoti proceso pareguliavimo pasekmes ir
gauti formalų leidimą daryti tai.
Susitaikymas su atsiradusia blogybe. Jei projekte sukurto produkto išleidimas numatytu
laiku yra daug svarbesnis už neatitikimų pašalinimą, tuomet tenka sutikti su žemesne produkto
kokybe. Nepašalintų trūkumų (defektų) bendroji įtaka turi būti išanalizuota, su tuo turi būti
supažindinti projekto akcininkai ir gautas jų sutikimas išleisti ne visai kokybišką produktą.
Vėliau, pastebėti produkto trūkumai bus šalinami platinant pataisymus (upgrade).
Dar vienas svarbus kokybės kontrolės aspektas yra projekto dokumentų kokybė.
13.2.4. Dokumentų kokybė
IT projektuose sukuriami techninio ir netechninio pobūdžio dokumentai. Jų kokybe
(turiniu, kalbos taisyklingumu, aiškumu, kt.) taip pat turi būti rūpinamasi. Tai produkto
dokumentai naudotojams, naudotojų mokymo medžiaga, pagalbos teikimo (help-desk) medžiaga,
dokumentai priežiūros grupėms.
Dokumentai naudotojams. On-line būdu teikiamos ar spausdintinės instrukcijos sistemos
naudotojams turi būti parengtos kruopščiai. Daug ką erzina, pvz., toks dalykas, kai paspaudus
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
108
klaviatūroje funkcinį klavišą F1, kuris paprastai naudojamas pagalbai išsikviesti, gaunamas
atsakymas „Šiuo klausimu pagalba neteikiama“ arba gaunama minimali informacija.
Naudotojų mokymo medžiaga. Sukurtos sistemos naudotojų mokymas gali būti atliekamas
įvairiai: padedant instruktoriams, savarankiškas mokymasis, naudojant tam tikslui išleistas
knygas, arba on-line būdu teikiamą medžiagą. Mokomoji medžiaga, įskaitant demonstracines
priemones, turi būti gerai apgalvota, suprantama ir tinkamai parengta.
Pagalbos teikimo (help-desk) medžiaga. Projekto vykdytojai dažnai pasirūpina, kad būtų
sukurta grupė žmonių, kurie naudotojams teiktų konsultacijas, pagalbą neaiškumų atvejais,
dirbant su projekte sukurta sistema. Vėlgi, tam naudojama medžiaga turi būti kokybiška.
Dokumentai priežiūros grupėms. Prie projekto rezultatų kokybės prisideda tikslūs ir
patogūs dokumentai sukurtos sistemos prižiūrėtojams.
Serverių administratoriai turi žinoti, kokią įtaką serveriams gali turėti naujai įdiegta
sistema. Tas pat taikytina ir asmeninių kompiuterių (PC) prižiūrėtojams, nes įdiegta nauja
sistema gali turėti poveikį ir klientų kompiuteriams. Todėl turėtų būti parengti atitinkami
dokumentai priežiūros klausimais.
Projekte sukurtos sistemos priežiūros dokumentų taip pat gali reikėti duomenų bazių
administratoriams, kompiuterių tinklo ir kitiems specialistams.
13.3. IT projektų kokybės kontrolė
IT projektuose kokybės kontrolė pradedama žiūrint:
- ar laikomasi gerai žinomų ir plačiai paplitusių standartų;
- ar projekto pradžioje buvo sukurta aplinka (teisinė, organizacinė,
technologinė), kuri garantuotų sėkmę.
Minėtiems klausimams spręsti projekto grupė sugaišta daug laiko. Tam reikia supirkti
įvairius dalykus ir būti pasišventusiems projektui. Panagrinėkime kiekvieną iš šių klausimų
atskirai.
13.3.1. Standartai
IT įmonės, kurios laikosi standartų, pasiekia geresnių rezultatų. Pvz., kuriant programinę
įrangą laikomasi tokių standartų:
- naujos programos rašomos taip, kad joms leisti pakaktų XML naršyklės;
- naujose programose naudojamos Web funkcijos, kaip J2EE, o ne savos funkcijos;
- naujose programose perduodant duomenis klientui naudojamas SOAP (Simple Object
Access Protocol) protokolas (prisiminkime, kad tai OSI modelio transporto lygmens
standartų rinkinys).
Minėti standartai greičiausiai nėra visa apimantys, ir IT įmonė gali jais nesivadovauti. Bet
sutikime, kad jie yra pagrindiniai, daugumai suprantami, remiasi visuotinai pripažintais
protokolais kaip rišamąja medžiaga. Diegiant šiuos standartus įgyjamas tvirtas pagrindas naujai
programinei įrangai kontroliuoti plačiame naudotojų rate.
IT projektų vadovai turėtų sukviesti visus akcininkus ir išsiaiškinti, ar numatomi diegti
standartai visiems yra priimtini. Tai galėtų būti šie standartai:
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
109
- dokumentai, kaip turi būti įrengiami serveriai;
- darbo vietų įrengimo standartai, apimantys operacinę sistemą, kontoros automatinę
įrangą, naršykles, valdymo pulto (panel) nustatymus, kt.;
- programinės įrangos kūrimo standartai;
- kompiuterių tinklo įrengimo standartai, įskaitant tinklo veikimo protokolus.
13.3.2. Standartų organizacijos
Standartų organizacijos rengia pačius įvairiausius standartus. Viena iš jų yra Tarptautinė
standartų organizacija (ISO – International Standards Organization). Kokybės kontrolei įmonės
naudoja ISO 9000 standartą. Kadangi ISO 9000 yra didelis standartas, tikriausiai internete galima
po truputį surinkti informaciją apie jį, sužinoti kaip gimsta ISO standartai ir kokie standartai yra
prieinami.
DMTF (Distributed Management Task Force) standartų organizacija rengia sistemų
valdymo būdų ir sąsajų standartus. Pvz., Microsoft savo leidžiamuose Windows naudoja WBEM
(Web-Based Enterprise Management) standartą, kurį yra parengusi minėta standartų
organizacija.
IEEE (Institute of Electronic and Electric Engineers) yra parengusi plačiai žinomus tinklų
protokolus (protokolas – tai standartų rinkinys). Pvz., IEEE 802.11 yra bevielio vietinio tinklo
(WLAN) standartas.
ITIL (Information Technology Infrastructure Library) yra dar viena naudinga ir įdomi
standartų organizacija, kuri specializuojasi darbinės aplinkos (serverių, tinklo infrastruktūros,
mainfreim‘ų, kt.) valdymo gerinimo srityje. ITIL organizacijai priskiriamas posakis, kad visų
pirma reikia suprasti verslo procesus ir tik po to taikyti technologijas.
ANSI (American National Standards Institute) – tai standartų organizacija, kuri čia mums
įdomi tuo, kad projektų valdymo žinyną [PMBOK] parengė ji.
Standartų organizacijos yra įdėję daug pastangų kurdamos standartus, kad programų
sistemos galėtų sklandžiai sąveikauti tarpusavyje. Projektų vadovai turėtų žinoti standartus ir
laikytis jų.
13.3.3. Projektų valdymo kokybės gerinimas
Yra daug būdų projektų kokybei gerinti. Visų pirma reikėtų įvertinti savo organizacijos
galimybes vykdyti projektus aukštu lygiu. Tam galėtų pasitarnauti CMM (Capability Maturity
Model) modelis [CMM].
CMM modelyje skiriami penki organizacijų gebėjimo lygiai, kur aukštesnieji yra paremti
žemesniaisiais. Dauguma organizacijų pirmuosius savo projektus atlieka žemiausiu, 1-uoju
gebėjimų lygiu. Šie penki gebėjimų (įgūdžių) lygiai CMM modelyje charakterizuojami taip:
1 lygis – pradinis (initial). Šis gebėjimų lygis rodo, kad kiekvienas projektas organizacijoje
vykdomas kaip specialus vienkartinis procesas. Dažnai tai daroma chaotiškai, neorganizuotai,
neturint jokių formalių planų ar taisyklių. Veiklos yra neapibrėžtos ir nekontroliuojamos.
2 lygis – kartojamasis (repeatable). Organizacijoje yra numatyta tam tikra projektų
vykdymo tvarka, padedanti vertinti kainą, rengti darbų grafiką, vertinti rezultatus. Ši tvarka
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
110
kartojama kiekvieno projekto metu. Tačiau tvarka dar yra tobulintina, todėl kiekviename
naujame projekte daromi žingsniai projektų vykdymui gerinti.
3 lygis – apibrėžtasis (defined). Projektų vykdymo procesas yra apibrėžtas ir
standartizuotas. Visi projektai organizacijoje atliekami laikantis apibrėžtų procesų, naudojami
standartiniai dokumentai, reikalavimai, tvirtinimai ir kiti veiksmai projekto rezultatams pasiekti.
Tačiau informacija apie apibrėžtų procesų (tvarkos ir atliekamų veiklų) efektyvumą nėra
renkama.
4 lygis – kiekybiškasis (quantitative, managed). Projekto vykdymo metu organizacija
renka įvairius rodiklius. Projektas yra valdomas stebint kiekybinius ir kokybinius rodiklius.
Veiklos yra ne tik apibrėžtos, bet ir jų efektyvumas kontroliuojamas naudojant įvairius rodiklius.
5 lygis – opimizuojantysis (optimizing). Projektų vykdymo procesas yra nuolatos
tobulinamas, išnaudojant matuojamus kiekybinius rodiklius kaip grįžtamąjį ryšį.
IT technologijų diegimo sėkmė priklauso nuo projektą vykdančios IT organizacijos
gebėjimo greitai ir protingai įdiegti projektų valdymo metodologijas ir nuosekliai laikytis jų. Tik
suprasdami savo organizacijos galimybes imtis projektų gerinimo veiksmų, diegti plačiai žinomus
standartus, galime tikėtis projektų įvykdymo reikiamu kokybės lygiu.
13.4. Rizikos valdymo kontrolė
Projekto planavimo etape buvo įvardinti rizikos veiksniai (nepageidaujami įvykiai, pvz.,
sumažėjo finansavimas, sugedo įranga, iš darbo išėjo žmogus, kt.) ir parengtas reagavimo į juos
planas. Rizikos valdymas – tai procesas, kurio metu atliekami reakcijos į rizikos veiksnius
veiksmai. Šis procesas nėra vien plane įvardintų rizikos veiksnių stebėsena. Jo metu taip pat
vertinamas atliekamų reakcijos veiksmų efektyvumas.
Rizikos valdymas apima ir naujų rizikos veiksnių įvardijimą, kurie gali atsirasti bet kuriuo
projekto vykdymo metu. Nepaisant rizikos veiksnių įvardijimo detalumo pradiniame projekto
plane, pasikeitusios projekto sąlygos, verslo pokyčiai ir kiti projekto plano komponentų keitimai
gali sukelti naujus rizikos veiksnius, į kuriuos taip pat turėtų būti atsižvelgiama.
Rizikos valdymas turi glaudų ryšį su projekte iškylančių problemų valdymu. Iškilusios
problemos turi būti sprendžiamos, vertinama jų sprendimo eiga, keliamos naujos problemos.
Rizikos valdymo nagrinėjimą pradėkime nuo reakcijos į projekto plane numatytus rizikos
veiksnius rezultatų.
13.4.1. Reakcijos į rizikos veiksnius rezultatų valdymas
Rizikos planavimo metu buvo įvardinti projekto rizikos veiksniai ir, remiantis jų
pasirodymo tikimybe ir galimo poveikio projektui laipsniu, surikiuoti prioriteto tvarka. Reakcijos
į kiekvieną aukštesnio prioriteto rizikos veiksnį plane buvo numatyti veiksmai, kurie padėtų
sumažinti rizikos veiksnio įtaką projektui (žiūr. 8.3 lentelę).
Prevencinės (profilaktinės) priemonės. Rizikos veiksniams, kurių galima būtų išvengti ar
sušvelninti jų įtaką projektui, valdyti yra specifiniai būdai, kaip, pvz., naujų užduočių įtraukimas į
darbų grafiką.
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
111
Tokiais atvejais turėtų būti atliekami projekto plane numatyti veiksmai ir vertinama, kaip
tie veiksmai padeda pašalinti arba sumažinti rizikos veiksnio įtaką projektui. Jei atliekami
veiksmai nesumažina rizikos, reikėtų peržiūrėti reakcijos į rizikos veiksnį būdą ir arba prisiimti
riziką, arba imtis naujo reakcijos būdo.
Peržiūrint veiksmus (reakcijos būdą), kurie neduoda laukiamų rezultatų, būtina įsitikinti
ar rizikos veiksnys nėra pakitęs dėl kokių nors aplinkybių. Jei pastebite, kad turite reikalą su
pakitusiu rizikos veiksniu, gali reikėti visai kitokio reakcijos į jį būdo.
Veiksmai nenumatytais atvejais. Kai susiduriama su projekto plane nenumatytais atvejais,
naudojamas kitoks reakcijos į rizikos veiksnius būdas. Tokiais atvejais rizika yra valdoma kitaip.
Rizikos planas nenumatytiems atvejams pradedamas naudoti tik tada, kai iš tikro atsitinka
nepageidaujamas įvykis (pasikeitė įstatymai, įvyko streikas, kt.). Tuomet tenka aiškintis ir valdyti
rizikos priežastis (risk trigger), signalizuojančias apie artėjantį pavojų projektui.
Projekto eigoje reikia būti pasirengusiems bet kokiems pavojaus signalams apie rizikos
veiksnių pasikeitimus. Reakcijos į riziką, atsirandančią dėl nenumatytų priežasčių, veiksmų plano
sudarymo sėkmė slypi žinojime (neignoravime), kad gali atsirasti ir nauji rizikos veiksniai.
13.4.2. Naujų rizikos veiksnių įvardijimas
Reakcijos į riziką planas plėtojamas visą projekto laiką. Kai kurie planavimo metu
įvardinti rizikos veiksniai nepasireiškia (neįvyksta), tačiau gali atsirasti naujų, kurių nėra
pradiniame projekto plane. Kai projektas baigiamas, ateičiai turėtume gerai įsidėmėti kiekvieną
naujai atsiradusį neplanuotą rizikos veiksnį.
Nauji rizikos veiksniai gali turėti įtakos sąraše išdėstytų rizikos veiksnių prioritetams.
Naujų rizikos veiksnių pasirodymo tikimybė ir įtakos projektui lygis gali būti aukštesnis už
anksčiau įvardintus rizikos veiksnius. Projekto plano pakeitimai taip gali pareikalauti keisti
rizikos veiksnių prioritetus. Pvz., projekto eigoje darbų grafike gali tekti keisti kritinį darbų kelią,
kas savo ruožtu gali pareikalauti neatidėliotino kai kurių rizikos veiksnių prioriteto keitimo.
Kai daromi projekto plane numatytų reakcijos į rizikos veiksnius veiksmų pakeitimai arba
įvardijami nauji rizikos veiksniai, gali iškilti būtinumas keisti ir visą projekto planą. Reakcijos į
riziką veiksmai gali iššaukti projekto apimties, darbų grafiko ir biudžeto keitimą. Tokiu atveju
reakcijos į riziką keitimo procedūra turi būti panaši, kaip ir darant kitokius projekto pakeitimus.
Problemų registravimo žurnalas yra kitas svarbus dokumentas, kuris projekto bėgyje turi
būti tvarkomas ir atnaujinamas.
13.4.3. Problemų sprendimo valdymas
Problemų sprendimo eigos valdymas yra labai panašus į rizikos valdymą, nes taip pat turi
būti imamasi atitinkamų veiksmų. Nerūpestingas problemų sąrašo tvarkymas (iškilusių
problemų įtraukimas, atsakingo asmens nurodymas, atžymos apie išspręstas problemas, kt.) gali
atvesti prie naujų problemų atsiradimo kiekvieną savaitę arba kad problemos iš viso nebus
išspręstos.
Aptariant problemas projekto grupės susirinkimuose, reikėtų išsiaiškinti, kaip sekasi už
problemų sprendimą atsakingiems asmenims. Kartais problemos lieka neišspręstos savaites ar
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
112
net mėnesius. Todėl sąraše visada reikėtų registruoti problemos sprendimo planą ir numatomą
išsprendimo datą. Jei problema sprendžiama lėtai, galbūt už ją atsakingam asmeniui reikia
pagalbos arba jis nesupranta problemos. Dėl to gali tekti netgi kreiptis į sponsorių, kad padėtų
įveikti kliūtis.
Visas problemas reikėtų išspręsti kaip galima greičiau, tačiau kai kuriais atvejais
problemos gali būti sprendžiamos jų prioriteto tvarka. Problemų prioritetui nustatyti gali būti
naudojami tie patys būdai, kurie buvo naudoti planuojant riziką. Jeigu keletui problemų spęsti
reikalingi tie patys žmonės, peržiūrėkime problemų poveikio projektui dydį, problemų
prioritetus ir tik tada nutarkime, kurios imsimės visų pirma.
13.4.4. Projektas pavojuje
Kartais projekto grupės narių reakcijos į riziką veiksmai ar problemų sprendimo veiksmai
gali vesti link projekto sužlugdymo. Jeigu tie veiksmai neduoda norimų rezultatų arba atsiranda
nauji, sunkiai suvaldomi rizikos veiksniai, reikia kreiptis į sponsorių ir tartis, ką gi reikėtų daryti.
Kreipimasis į sponsorių dėl pagalbos projekto problemoms spręsti yra delikatus reikalas.
Projektų vadovai nenori užsitarnauti panikuotojo reputacijos, kai iškyla problema ir nesiseka
išspręsti jos griežtais sprendimais. Tačiau, jei padarėte viską, ką jūs galite, ir matote, kad reikalai
negerėja, nedelskite ir kreipkitės į sponsorių. Laiku neinformavus apie projekto sunkią padėtį,
sponsorius taip pat gali nebeturėti galimybių pagelbėti.
Prieš einant pas sponsorių būtina pasirengti aiškiai išdėstyti problemą ar riziką, veiksmus,
kurių ėmėtės, ir jeigu toliau padėtis nesikeis, kokią įtaką tai turės projektui. Pokalbis su
sponsoriumi turi būti trumpas, aukšto lygio. Jam nėra būtina žinoti visų smulkių žingsnių.
Reikėtų prašyti, kad sponsorius imtųsi specifinių veiksmų. Jeigu turite problemų su jūsų
organizacijos kažkuriuo kitu departamentu ir reikalingas atitinkamo lygio sprendimas,
informuokite sponsorių apie tai ir ko jums reikia, kad projektas grįžtų į normalias vėžes.
Kartais pakeisti situacijos būna neįmanoma. Galbūt dėl naujų teisės aktų jūsų projekto
pagrindinės prielaidos tapo negaliojančios arba nauja organizacijos vadovybė pasirinko
strategiją, kuri nebepateisina jūsų projekto. Tokiais atvejais reikėtų rekomenduoti sponsoriui
nutraukti projektą.
13.5. Projekto eigos kontrolė
Projekto eigos kontrolė padeda atskleisti daug svarbios informacijos, kuri rūpi ir
akcininkams. Darbų ataskaitose atspindima esama projekto padėtis ir prognozės dėl projekto
apimties, darbų grafiko, biudžeto ir kokybės. Rizika ir projektui pavojų keliančios problemos turi
būti žinomos ir akcininkams.
Darbų eigos rezultatai turi būti platinami akcininkams laikantis planavimo etape parengto
komunikacijų plano. Ataskaitose turi būti informacija apie nuveiktus darbus iki tam tikro laiko ir
kas dar liko padaryti.
Informacijai apie projekto eigą rinkti yra nemažai analitinių priemonių.
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
113
13.5.1. Darbų ataskaitos
Darbų ataskaitose turėtų būti daugiau specifinė informacija, o ne vien tik konstatavimas,
ar nėra nukrypimų nuo planuotos projekto apimties, darbų grafiko ar biudžeto panaudojimo.
Nukrypimai gali turėti labai įvairų poveikį visam projektui. Todėl dalis ataskaitos turi būti
skiriama problemų analizei ir jų įtakos projektui įvertinimui.
Nukrypimų nuo projekto plano poveikio dydžiui įvertinti naudojami šie būdai:
nukrypimų analizė, tendencijų analizė, viso projekto kainos tikslinimas, atliktų darbų kainos (EV
- earned value) vertinimas, nuokrypiai, indeksai (santykiai).
Nukrypimų analizė – tai einamųjų projekto rezultatų palyginimas su projekto plane
numatytais rezultatais. Ši analizė dažniausiai naudojama projekto darbų grafikui ir biudžetui.
Projektų valdymo tikslams skirta programinė įranga (pvz., Microsoft Project) dažniausiai
turi funkciją projekto eigos nukrypimams nuo suplanuoto darbų grafiko sekti. Ji įgalina
apskaičiuoti naują galutinį projekto įvykdymo terminą, jei vėluojama atlikti kažkuriuos darbus.
Projekto biudžeto ataskaitose palyginamos atitinkamo laikotarpio kontroliniame taške
numatytos lėšos ir iš tikro padarytos išlaidos.
Kiekybiškai nukrypimo dydis ataskaitoje gali būti nurodomas procentais, pvz., atlikta
50% numatytų darbų ir išleista 35% numatytų lėšų. Negerai, kai darbai padaromi laiku, bet
išleidžiama daugiau lėšų, nei buvo numatyta. Tačiau yra visiškai blogai, kai darbai nepadaromi
laiku ir išleidžiama daugiau lėšų nei numatyta.
Tendencijų analizė. Jau nuveikti darbai gali įnešti aiškumo, ko galima tikėtis atliekant
būsimus darbus. Tendencijų analizė yra pagrįsta matematiniais skaičiavimais ir naudojama
prognozuoti, ar darbų atlikimas gerės ar blogės.
Viso projekto kainos tikslinimas. Kadangi projekto eigoje rengiamos biudžeto ataskaitos, iš
jūsų gali būti prašoma pateikti prognozuojamą viso projekto kainą. Atlikus dalį projekto darbų ir
įgijus patirties, atsiranda galimybė tiksliau įvertinti viso projekto kainą, nei projekto pradžioje.
Viso projekto patikslintos kainos įvertis duotu laiku (EAC – estimate at completion) gaunamas
remiantis jau atliktų ir likusių darbų informacija. Kad geriau suprastume tokį įvertį, pravartu
žinoti šias sąvokas:
- viso projekto kainos įvertis projekto pradžioje (BAC – budget at completion);
- tikrosios (faktinės) projekto išlaidos iki duoto laiko (AC – actual cost);
- nuo duoto laiko iki projekto pabaigos likusių darbų prognozuojama kaina (ETC –
estimate to complete);
- viso projekto patikslintos kainos įvertis duotu laiku (EAC – estimate at completion)
EAC = AC + ETC .
Skirtumas tarp EAC ir BAC yra duotu laiku patikslintos projekto kainos nukrypimas nuo
projekto pradžioje įvertintos projekto kainos (VAC – variance at completion): VAC = EAC - BAC.
Atliktų darbų kainos vertinimas. Dideliuose projektuose tenka skirti dėmesį visoms
finansinėms detalėms. Tai įvairūs indeksai (santykiai), kuriuos nesunku apskaičiuoti naudojant
skaičiuokles arba projektų valdymo programinę įrangą. Kad suprastume, kokie duomenys
naudojami tiems indeksams (santykiams) apskaičiuoti, pateikiame labiausiai reikalingas
sąvokas:
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
114
- tikrosios (faktinės) projekto išlaidos iki duoto laiko (AC – actual cost);
- iki duoto laiko atliktų darbų vertė (EV – earned value);
- projekto biudžete duotam laikotarpiui skirta suma (PV – planned value).
Šias sąvokas pakomentuokime pavyzdžiu. Planuojant darbų grafiką buvo nustatyta, kad
kažkokiems darbams atlikti reikės 4 savaičių ir darbai bus baigti kovo 31 d., o suplanuotame
biudžete to laikotarpio darbams numatyta 50000 Lt (tai PV). Už kovo mėnesį gauta biudžeto
ataskaita rodo, kad buvo išleista 48000 Lt (tai AC). Galima pagalvoti, kad reikalai klostosi gerai,
sutaupyta truputis pinigų. Bet pažiūrėję į darbų grafiką matome, kad kovo 31 d. atlikti ne visi
numatyti darbai, o atliktų darbų vertė tik 42000 Lt (tai EV). Atliktiems darbams apmokėti išleista
daugiau pinigų, nei reikėjo (EV-AC<0). Reiškia, yra problema.
Nuokrypiai. Nuokrypiai rodo skirtumą tarp suplanuoto projekto biudžeto ir tikrųjų išlaidų
duotu laiku. Teigiamas nuokrypis rodo, kad jūs sutaupėte pinigų arba laiko ir galite juos
panaudoti kitiems projekto darbams. Neigiamas nuokrypis rodo, kad jūs viršijote biudžetą arba
atsiliekate nuo darbų grafiko. Tai reikalauja jūsų korekcinių veiksmų.
Išlaidų nuokrypis (CV – cost variance) yra iki duoto laiko atliktų darbų vertės (EV) ir
tikrųjų išlaidų (AC) skirtumas:
CV = EV – AC .
Darbų nuokrypis (SV – schedule variance) yra iki duoto laiko atliktų darbų vertės (EV) ir
darbų grafike suplanuotų darbų kainos (PV) skirtumas:
SV = EV – PV.
Neigiamos CV ir SV reikšmės rodo, kad yra problemų.
Indeksai (santykiai). Indeksai atspindi santykius tarp biudžeto komponentų. Jie yra
lengvai apskaičiuojami ir ypač naudingi. Jų reikšmė yra mažesnė arba didesnė už 1. Jei santykio
reikšmė yra didesnė už 1, tai projekto darbų vykdymas lenkia darbų grafiką arba projekto
biudžeto išlaidos panaudotos efektingai (biudžetas neviršytas). Jei santykis yra mažesnis už 1, tai
atsiliekama nuo darbų grafiko arba projekto biudžeto išlaidos panaudotos neefektingai (viršytos
biudžeto išlaidos).
Santykiai gali būti išreiškiami procentais, nes tai gali būti patogiau. Pvz., indekso reikšmė
0,94 atitinka 94%. Taip yra patogiau vykdyti atliktų darbų vertės analizę.
Išlaidų indeksas (CPI – cost performance index) atspindi projekto biudžeto išlaidų
panaudojimo efektyvumą. Jis apskaičiuojamas kaip iki duotos datos atliktų darbų kainos (EV) ir
tikrųjų išlaidų (AC) santykis:
CPI = EV / AC .
Jei CPI<1, tai projekto biudžeto išlaidos naudojamos neefektyviai (viršytos biudžeto išlaidos), jei
CPI>1, tai jūs išleidote pinigų mažiau, nei tikėjotės.
Darbų indeksas (SPI – schedule performance index) yra iki duotos datos atliktų darbų ir
darbų grafike suplanuotų darbų kainų santykis:
SPI = EV / PV .
Jei SPI<1, tai jūs atsiliekate nuo darbų grafiko (turite problemų), jei SPI>1, tai darbams jūs
sugaišote mažiau laiko, nei tikėjotės.
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
115
Darbų tęstinumo indeksas (TCPI – to-complete performance index) yra likusių darbų
kainos ir likusių biudžeto lėšų santykis išreikštas procentais [WL06].
TCPI = (likusių darbų kaina) / (likusios biudžeto lėšos) .
Čia, (likusių darbų kaina) = BAC – EV , (likusios biudžeto lėšos) = BAC – AC , BAC (budget at
completion) yra viso projekto kainos įvertis projekto pradžioje.
TCPI duotu laiku atspindi likusių projekto darbų finansinį suvaržymą. Jei TCPI>1, tai
likusios lėšos likusiems darbams atlikti turi būti naudojamos labai taupiai.
13.5.2. Akcininkų valdymas
Projekto vadovui kartais tenka priimti sunkius sprendimus dėl tolesnės projekto eigos.
Projekto vadovas yra atsakingas ne tik už akcininkų informavimą apie projekto eigos
nukrypimus, bet ir už nukrypimų poveikio projektui įvertinimą ir rekomendacijų, ką reikėtų
daryti, parengimą. Gali tekti daryti kompromisus, norint rezultatyviai užbaigti projektą. Kai
kuriais atvejais nelieka prasmės tęsti projektą, ir dėl jo nutraukimo gali reikėti oficialaus
akcininkų sutikimo.
Pranešimai apie projekto nukrypimus. Analizuojant projekto eigą būtina informuoti
akcininkus apie bet kokius nukrypimus, kurie gali turėti įtakos projekto rezultatams. Projekto
stoviui pristatyti jūs galite rengti papildomas diagramas ar lenteles, kas padėtų aiškiau pristatyti
jūsų analizės rezultatus. Kai kurios diagramos ir ataskaitos gali būti parengtos naudojant
projektų valdymui skirtą programinę įrangą, pvz., Microsoft Project.
Kompromisų valdymas. Prisiminkime, kad visi projektai turi laiko, kainos, kokybės ir
apimties apribojimus. Jei kuris nors iš jų yra keičiamas projekto eigoje, tai, mažiausiai, tenka
keisti dar vieną iš likusių trijų. Keitimus tenka daryti beveik visuose projektuose.
Jei keičiamas bent vienas projekto apribojimas, projekto vadovas turi ieškoti kompromiso
su akcininkais. Pažiūrėkime, kaip vienos srities keitimai įtakoja kitas sritis.
Kompromisas dėl projekto apimties. Prašymai keisti projekto apimtį yra vieni iš
lengvesnių, nes šių keitimų valdymo procesas yra susijęs su keitimo poveikio projektui analize ir
reikalauja akcininkų patvirtinimo.
Jei patvirtintam projektui keliami papildomi reikalavimai, turėtų būti nurodomos
reikiamos papildomos lėšos ir laikas tiems reikalavimams įgyvendinti. Tam gali reikėti
papildomų išteklių ar didesnės projekto grupės. Akcininkai dažnai reiškia norą, kad tie papildomi
reikalavimai būtų įgyvendinti per anksčiau suplanuotą projekto laiką ir už buvusią projekto
kainą. Todėl jiems reikėtų paaiškinti, kad daugiau darbų padaryti per tokį pat laiką ir už tokią pat
kainą galima tik darbų kokybės sąskaita, trumpinant arba iš viso atsisakant darbų rezultatų
testavimo.
Iškilus būtinybei keisti projekto apimtį, reikėtų ieškoti akcininkams priimtinų alternatyvių
sprendimų. Jei papildomi reikalavimai negali būti įgyvendinti nekeičiant darbų grafiko, tai gal
juos galima būtų įgyvendinti ateityje, tobulinant (upgrade) projekte sukurtą produktą. Galbūt yra
ir kiti keliai papildomiems reikalavimams įgyvendinti, todėl visada reikėtų išklausinėti
akcininkus, kad išsiaiškintume, ko jie siekia prašydami keisti projekto apimtį.
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
116
Kompromisas dėl darbų grafiko. Darbų atlikimo vėlavimo priežastys gali būti įvairios
nelaimės, įrangos gedimai, padarytos klaidos. Todėl ypač svarbu gerai žinoti darbų grafiko svarbą
jūsų projektui. Tarkime, jūs esate nustatytos apimties ir biudžeto 10 mėnesių trukmės projekto
vadovas ir prašote akcininkų atidėti projekto baigimo terminą 3 savaitėmis. Iš pirmo žvilgsnio tai
gali atrodyti kaip pagrįstas prašymas, nes visi žino, kad projekto planavimo etape nustatoma tik
apytikrė projekto trukmė. Daugeliu atveju logiškiau būtų rekomenduoti atidėti baigimo terminą,
nei didinti projekto sužlugdymo riziką dėl skubėjimo. Tačiau jeigu buvo nustatytas privalomas
projekto užbaigimo terminas, tokia rekomendacija gali sumažinti pasitikėjimą jūsų organizacija,
gali užtraukti baudas arba teisines sankcijas. Todėl visada, prieš rekomenduojant atidėti projekto
pabaigos terminą, reikia būt pasvėrus, kas yra geriau.
Jeigu jūs atsiliekate nuo darbų grafiko ir nematote perspektyvaus būdo, kaip galėtumėte
išbristi iš šios bėdos turimais ištekliais, informuokite akcininkus apie susidariusią padėtį. Laikant,
kad projekto užbaigimas laiku turi aukščiausią prioritetą, jūs turite įvertinti, kaip galima būtų tą
padaryti. Jei rūpestį kelia nepakankami ištekliai, paaiškinkite tai akcininkams ir nurodykite
reikiamas papildomas lėšas ištekliams padidinti. Jei išteklių didinimas nepadeda laiku baigti
projekto arba nėra garantijų dėl lėšų padidinimo, reikia būti pasirengusiems aptarti, kokių
projekte kuriamo produkto funkcijų galima būtų atsisakyti.
Kartais gali būti neįmanoma laiku baigti projektą. Jeigu pradiniai reikalavimai nebuvo
aiškūs arba kažkas juose buvo praleista, išsiaiškinus tai gali pasirodyti, kad projektas yra daug
sudėtingesnis, nei buvo tikėtasi. Darbai gali būti pagreitinti sumažinus kuriamo produkto
funkcionalumą, jei dėl to nereikia perdaryti anksčiau atliktų darbų. Jeigu ir tai nepadeda išvengti
darbų grafiko pažeidimo, o projektas vis dar išlieka gyvybingas, jūs turite būti tikri, kad
atidėtame projekto užbaigimo termine yra įvertinti visi daryti projekto plano pakeitimai.
Kompromisas dėl išlaidų. Išlaidų viršijimo priežastis gali būti netiksli sąmata, darbų
grafiko vėlavimai, projekto apimties nukrypimai, biudžeto kritinių straipsnių nepaisymas.
Kadangi išlaidos daromos įvairiose srityse, būtina stebėti, kad būtų mokama tik už atliktus
darbus. Jeigu pagal biudžeto planą kažkuriame projekto etape išleidžiate daugiau lėšų nei buvo
atlikta darbų, galite turėti rimtų problemų.
Jeigu reikalaujama griežtai laikytis nustatyto biudžeto, o jūs matote, kad išlaidų viršijimas
yra neišvengiamas, atsiradusiam skirtumui panaikinti tenka siaurinti projektą. Geriausias būdas
padaryti tai yra susitikti su sponsoriumi ir akcininkais ir prašyti leidimo sumažinti projekto
apimtį tiek, kad nebūtų viršytas biudžetas.
Sponsorius ar akcininkai gali reikalauti išlaikyti senąją projekto apimtį, o kad biudžetas
nebūtų viršytas, išlaidas taupyti trumpinant ar atsisakant testavimo darbų, t. y. kuriamo
produkto kokybės sąskaita. Galimi produkto defektai ateityje bus šalinami atliekant ir platinant
patobulinimus (upgrade).
Kompromisų darymas (bendrų sutarimų ieškojimas) ne visada padeda. Jei nerandama
protingos alternatyvos, reikėtų rekomenduoti nutraukti projektą.
Projekto nutraukimas. Kai kuriais atvejais projekto nutraukimas gali būti geriausias
sprendimas, kai nukrypstama nuo plano. Esant nepakankamam finansavimui ar trūkstant
darbuotojų, geriau nutraukti projektą, nei tęsti jį ir patirti fiasko. Jei projektas buvo patvirtintas
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
117
neturint tinkamai parengto plano, gali susidaryti situacijos, kurioms išvengti nėra tinkamų
sprendimų. Taip gali atsitikti dėl dažno reikalavimų keitimo arba kai akcininkų lūkesčiai nebūna
suderinti su projekto planu. Tokiais atvejais reikėtų klausti sponsoriaus ir akcininkų, ar yra
prasmė tęsti projektą. Galbūt pasikeitė verslo strategija, projekte reikia keisti daug ką ir todėl
derėtų jį nutraukti.
Rekomendacija nutraukti projektą nereiškia, kad projekto vadovas yra netikęs. Tai reiškia
raginimą sponsoriui ir akcininkams peržiūrėti pradinius projekto tikslus ir nuspręsti, ar šis
projektas vis dar turi prasmę.
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
118
14. PROJEKTO UŽBAIGIMAS
Projekto užbaigimas – tai formalus viso projekto arba projekto etapų užbaigimas, sukurto
produkto perdavimas naudotojams arba projekto nutraukimas. Pagrindiniai užbaigimo etapo
valdymo darbai yra šie: viso projekto administracinis užbaigimas ir sandorių užbaigimas.
Projekto administracinis užbaigimas
Tai viso projekto arba projekto etapų darbų užbaigimas. Jo metu analizuojami duomenys
ir formuojami rezultatai parodyti 14.1 lentelėje.
14.1 lentelė. Projekto administracinio užbaigimo darbų duomenys ir rezultatai
Įeities duomenys Rezultatai
1. Projekto planas.
2. Sandorių dokumentai.
3. Įmonės aplinkos duomenys.
4. Įmonės organizaciniai dokumentai.
5. Informacija apie atliktus darbus.
6. Projekto rezultatai.
1. Atliktos administracinės baigimo
procedūros.
2. Atliktos sandorių baigimo procedūros.
3. Galutinis projekto produktas.
4. Atnaujinti įstaigos organizaciniai
dokumentai.
Sandorių užbaigimas
Tai kiekvieno sudaryto sandorio užbaigimas ir atsiskaitymas su tiekėju. Sandorių
užbaigimo duomenys ir rezultatai parodyti 14.2 lentelėje.
14.2 lentelė. Sandorių užbaigimo darbų duomenys ir rezultatai
Įeities duomenys Rezultatai
1. Įsigijimų (pirkimų) planas.
2. Sandorių valdymo planas.
3. Sandorių dokumentai.
4. Sandorių baigimo procedūra.
1. Užbaigti sandoriai.
2. Atnaujinti įstaigos organizaciniai
dokumentai.
Projekto užbaigimas taip lakoniškai yra aprašytas [PMBOK] šaltinyje. Apibūdinkime
projekto baigiamuosius darbus kiek smulkiau [HC04].
14.1. Projektų nutraukimo priežastys
Projekto užbaigimo etapas dažniausiai apima formalų projekto rezultatų priėmimą. Tačiau
ne visi projektai būna sėkmingi. Jų baigimo (nutraukimo) priežastys gali būti įvairios:
- rezultatų stoka. Projektas gali būti nutrauktas ar atidėtas neribotam laikui nelaukiant jo
pabaigos. Projektą, kuris niekur neveda, jo vykdytojams gali būti sunku nutraukti, bet
organizacijos vadovybė turi imtis tokio žingsnio. Projektai, kurie atidedami dėl technologijų
nebuvimo ar finansavimo trūkumo, taip pat priklauso niekur nevedančiųjų kategorijai;
- nepatvirtintas projekto planas. Jei planas nėra pagrįstas, natūralu, kad organizacijos
vadovybė tokius projektus atmeta;
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
119
- išteklių stoka. Tai gali būti lėšų, aparatūros, žmonių ar kitokių dalykų trūkumas. Tokia
situacija gali susidaryti dėl netinkamų įverčių planavimo etape arba jūsų projektui skirti ištekliai
perkeliami kitam, aukštesnį prioritetą turinčiam projektui. Nežiūrint išteklių nepakankamumo
priežasties, projektą tenka nutraukti.
14.2. Sandorių užbaigimas
Kai tiekėjas baigia kurį nors jūsų projekto darbų etapą, reikia užbaigti sandorį su juo.
Sandorio užbaigimas – tai sandorio sąlygų įvykdymas ir gautų rezultatų priėmimo
apiforminimas. Netgi jei sandorius tvarko organizacijos pirkimų departamentas, projekto
vadovas turi pateikti jam informaciją apie tiekėjo darbo rezultatų priėmimą. Tam turi būti
patikrinta gautų rezultatų kokybė. Reikalavimas tiekėjams pašalinti pastebėtus trūkumus
neturėtų jų stebinti.
Pirkimų departamentas turi išduoti tiekėjui oficialų raštą apie jo atliktų darbų priėmimą.
Užbaigus sandorį jūs, kaip projekto vadovas jau nebetenkate išteklių praleistiems darbams atlikti
ar nepastebėtiems defektams ištaisyti. Todėl tiekėjo pristatomų rezultatų kokybę reikia
kruopščiai patikrinti ir tik po to oficialiai su juo atsiskaityti.
Visų užbaigtų sandorių dokumentų kopijas reikėtų dėti į archyvą ir saugoti ateičiai.
Ne visuose projektuose sudaromi sandoriai, todėl su jų užbaigimu susiduria ne visų
projektų vadovai. Tačiau kiekvienam projektų vadovui tenka susidurti su administracinėmis viso
projekto užbaigimo procedūromis.
14.3. Administraciniai projekto baigiamieji darbai
Kai tik projektas baigiamas, kiekvienas projekto vadovas kaip galima greičiau dairosi
naujo projekto. Tačiau užbaigtam projektui reikia atlikti dar keletą svarbių darbų. Tai atlikto
projekto dokumentų surinkimas ir apibendrinimas (sutvarkymas), parašų surinkimas,
suinteresuotų šalių informavimas apie projekto baigtį.
Kai kurie administraciniai darbai yra nuobodūs, tačiau jų rezultatai, įgyta patirtis gali
praversti ateityje vykdant naujus projektus.
Panagrinėkime keletą administracinių darbų: projektų archyvo tvarkymas, formalus
projekto rezultatų priėmimas, visapusiška projekto peržiūra (išmoktos pamokos), projekto
rezultatų perdavimas naudotojams, projekto grupės narių atleidimas.
14.3.1. Projektų archyvo tvarkymas
Projekto eigoje jo priežiūrai sukaupiama daug dokumentų. Jų nauda yra ta, kad jie gali
praversti ateityje vykdant naujus projektus. Įvykdyto projekto planavimo dokumentai ir jų
šablonai gali suteikti informacijos ir būti reikalingi vertinant naujo panašaus projekto kainą,
darbų grafiką.
Projektų archyvo kūrimo keliai yra įvairūs. Kai kuriose organizacijose gali būti atskiros
patalpos, kuriose, kaip mažose bibliotekose, laikomi projektų dokumentai, arba gali būti
centralizuoti projektų archyvai. Prieš atiduodant savo projekto dokumentus į biblioteką ar
archyvą, reikia pasidomėti, kaip dokumentai turėtų būti sutvarkyti.
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
120
Natūralu, kad plinta elektroniniai archyvai. Organizacijose gali būti serveriai, kur saugomi
projektų dokumentai.
14.3.2. Formalus projekto rezultatų priėmimas
Jei projekte, einant nuo vieno etapo prie kito, drauge su akcininkais buvo kruopščiai
atliekamos gautų rezultatų peržiūros, tai galutinių projekto rezultatų formalus priėmimas
neturėtų kelti didelių rūpesčių.
Galutinių projekto rezultatų peržiūros tikslas yra gauti akcininkų pritarimą ir parašus bei
oficialiai paskelbti projekto pabaigą.
Priklausomai nuo jūsų organizacijoje esančių taisyklių, gali būti projekto užbaigimo
dokumento specialus šablonas parašams surinkti. Projekto vadovas turi išsiaiškinti, kieno parašų
reikės. Vienų projektų baigimo dokumentuose gali reikėti sponsoriaus ir akcininkų parašų, o kitų
– kiekvienos projekte dalyvavusios grupės dalyvio parašo.
Formalaus priėmimo metu būtina išsiaiškinti visus neatsakytus klausimus ir problemas. Iš
tokios peržiūros visi dalyviai turi skirstytis įsitikinę, kad projekto rezultatai atitinka keltus
reikalavimus.
Nors projekto eigoje akcininkai ir buvo informuojami dėl projekto plano keitimo, kai kurie
dalyviai gali neprisiminti visų keitimų. Todėl formalaus priėmimo metu būtina išsiaiškinti, ar visi
vienodai supranta, ko norėta pasiekti projektu. Tai ypač svarbu, jei buvo atsisakyta kai kurių
reikalavimų ar funkcijų, numatytų pradiniame projekto plane.
Kartais akcininkai, projektui einant į pabaigą, prašo papildyti jį įvairiais dalykais. Jei
projekto pabaiga būtų atidėliojama, kol nebus padaryta viskas, ko jie norėtų, dauguma projektų
niekada nesibaigtų. Todėl yra labai svarbu, kad projekto eigoje visiems prašomiems keitimams
būtų gautas patvirtinimas. Geriausia gynyba prieš prašymus papildyti projektą paskutinę minutę
yra akcentavimas to, ko akcininkai pageidavo ir ką patvirtino projekto plane.
Akcininkai taip pat nori žinoti, kuri grupė yra atsakinga už sukurtos sistemos atidavimą į
eksploataciją. Apie tai rašoma truputį vėliau (žiūr. Projekto rezultatų perdavimas naudotojams).
Vienas iš paskutinių projekto vadovo ir grupės narių baigiamųjų darbų yra visapusiška
projekto peržiūra ir gautų pamokų įsidėmėjimas.
14.3.3. Visapusiška projekto peržiūra (gautos pamokos)
Projekto pabaigoje visapusišką projekto peržiūrą atlikti reikėtų tam, kad įvertintume, kas
projekte buvo gerai ir kas sekėsi prasčiau. Šio proceso metu įvertinamas kiekvienas projekto
etapas. Šios rūšies peržiūros suteikia galimybę gerinti būsimų projektų valdymą (prisiminkime
CMM modelio brandos lygius). Užbaigto projekto vertinimas turėtų padėti atskleisti dalykus,
kurių mes išmokome, kokias pamokas gavome. Galbūt tai padės geriau valdyti kitus projektus.
Jeigu jūs buvote keletą organizacijos funkcinių padalinių apimančio (cross-functional)
projekto vadovas, peržiūroje susidursite su techniniais ir netechniniais projekto komponentais.
Keletui įvairių funkcinių padalinių skirtus projektus valdyti yra sudėtinga. Jus galbūt labiau
domina, kaip projekte buvo kuriama ir testuojama sistema, tačiau informacija apie rinkodarą ir
pardavimus taip pat yra svarbi.
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
121
Popierinio ar elektroninio pavidalo projekto dokumentai yra visapusiškos peržiūros
duomenys. Apibendrinus juos, projektas įvertinamas ir parengiama ataskaita.
Visapusiškos peržiūros metu nagrinėjamos:
- planavimo pamokos;
- organizacinės pamokos;
- projekto vykdymo pamokos.
- projekto vadovavimo (directing) pamokos;
- projekto kontrolės (controlling) pamokos;
- biudžeto tvarkymo pamokos;
- projekto įvertinimas (teigiamos ir neigiamos pusės).
14.3.4. Projekto rezultatų perdavimas naudotojams
Pasibaigus projektui, sukurtą sistemą dažniausiai eksploatuoja ir prižiūri kiti žmonės.
Todėl projekto grupė turi perduoti ją būsimiems naudotojams. Tai nėra paprastas uždavinys.
Dauguma sistemų turi vadinamąsias pagalbos (help desk) funkcijas. Todėl projekto darbų
grafike turi būti numatyti darbai mokymo medžiagai parengti ir pagalbos grupės nariams
apmokyti. Pagalbos grupė turi būti jau pasirengusi teikti paslaugas, kai sukurta sistema įdiegiama
pas naudotojus.
Sukurtos sistemos naudotojams taip pat turi būti parengti sistemos priežiūros
dokumentai ir įrankiai. Jų atnaujinimas jau yra priežiūros grupės narių atsakomybė.
Sistemos priežiūra – tai jos darbingumo išlaikymas visą jos naudojimo laikotarpį. Poreikiai
modifikuoti sistemą yra registruojami ir sekami, nustatoma siūlomų pakeitimų įtaka, keičiamos
programos ir kiti sistemos elementai (pvz., dokumentai), atliekamas testavimas, išleidžiamos
naujos sistemos versijos. Taip pat naudotojai yra mokomi ir jiems teikiama kasdieninė pagalba.
Manoma, kad sistemų priežiūra yra platesnė veiklos sritis nei projektavimas.
Prižiūrėtojai gali pasimokyti iš projekto grupės. Jų kontaktai turėtų užsimegzti kiek galima
anksčiau, ir tai gali sumažinti priežiūrai prireiksiančių pastangų lygį. Kai kuriais atvejais projekto
grupė neturėtų būti verčiama vykdyti užduočių, kurios sukeltų papildomus rūpesčius sistemos
prižiūrėtojams. Sistemos priežiūrai turi būti sukurti atitinkami produktai, programos ar
dokumentai, ir visa tai taip pat turi būti plėtojama ir prižiūrima sistemos gyvavimo kelyje.
14.3.5. Projekto grupės narių atleidimas
Dar projekto planavimo etape turi būti parengtas projekto grupės valdymo planas. Jame numatomos darbuotojų atleidimo procedūros pasibaigus projektui. Bent mėnesį iki projekto pabaigos reikėtų pradėti pokalbius su jūsų organizacijos funkcinių padalinių vadovais ir informuoti juos apie iš tų padalinių projektui vykdyti paimtų darbuotojų tolesnį likimą: ar jie bus traukiami į naują projektą, ar bus gražinami į funkcinį padalinį. Projekto grupės nariai gali būti sunerimę dėl savo ateities, ypač jei jie atleidžiami skirtingu projekto vykdymo metu. Tokiais atvejais reikėtų paaiškinti, kad užbaigus projekto darbus, dėl kurių jie buvo įtraukti į projekto grupę, jie bus atleidžiami. Kadangi jūs turite laikytis darbo sutarties terminų ir žmoniškųjų išteklių taisyklių, suteikite projekto grupės nariams kiek galima daugiau informacijos apie galimą atleidimo datą.
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
122
15. LANKSTIEJI PROJEKTŲ VYKDYMO METODAI
Programų sistemų kūrimo lankstųjį metodą (agile metodą) pasiūlė „Agile Alliance“
organizacija. Jis naudotinas tais atvejais, kai programų sistemų kūrimo projektai yra sunkiai
valdomi, dažnai keičiasi reikalavimai.
Lanksčiuoju metodu, sudėtingus (ilgalaikius) projektus skaidant į paprastesnius
(trumpesnės trukmės) keleto žmonių dydžio grupės atliekamus projektus, siekiama sumažinti
sudėtingo projekto įvykdymo riziką. Didelėse grupėse sudėtingų programų kūrimas trunka ilgai,
atsiranda komunikavimo problemų. Tipiška programų kūrimo trukmė yra 2-3 savaitės.
Kiekvieno tokios trukmės laikotarpio gale projekto prioritetų peržiūrėjimas leidžia greičiau
prisitaikyti prie kintančių reikalavimų, geriau valdyti rizikos veiksnius.
Pagrindinis lanksčiojo metodo skirtumas nuo tradicinių (krioklio, spiralės) modelių yra
orientacija į principus, o ne į procesą. Visa tai yra išdėstyta vadinamajame Agile manifeste
[BECK01].
Lanksčiojo metodo idėjos:
1) asmenys (projekto grupės nariai, kiti akcininkai) ir jų tarpusavio santykiai yra svarbiau
už procesus ir instrumentus;
2) veikianti programų sistema yra svarbiau už sistemos dokumentų išsamumą;
3) projekto grupės bendradarbiavimas su užsakovu yra svarbiau už įsipareigojimus
sandoryje;
4) reaguoti į siūlymus daryti keitimus yra svarbiau nei laikytis plano.
Lanksčiojo metodo principai:
1) klientų poreikių tenkinimas kiek galima greičiau ir nepertraukiamai teikiant naudingą
įrangą;
2) teigiamas požiūris netgi į projekto pabaigoje siūlomus keitimus. Tai gali padidinti
kuriamo produkto konkurentiškumą;
3) pirmalaikis sukurtos įrangos pristatymas geriau nei darbų grafiko trumpinimas;
4) glaudus užsakovo ir projekto grupės bendradarbiavimas viso projekto metu;
5) projekto grupės narių motyvacija. Jiems turi būti sudarytos geros darbo sąlygos,
teikiama parama ir pasitikima jais;
6) asmeniniai pokalbiai yra efektingiausias informacijos perdavimo būdas projekto
grupės narių ir akcininkų tarpe;
7) sukurta ir veikianti programa yra geriausias darbų judėjimo į priekį rodiklis;
8) lanksčiojo metodo (agile) procesai skatina nuolatinį kūrybingumą. Sponsoriui, projekto
grupei, kitiems akcininkams visada turi būti kažkiek neaiškumų;
9) nuolatinis dėmesys techniniam meistriškumui ir geras projektas (struktūra, design)
didina lankstumą;
10) paprastumas, t. y. gebėjimas nedaryti bereikalingų darbų yra labai svarbu;
11) geriausias sistemų struktūras, reikalavimus ir projektus (design) parengia darnios
(self-organizing) grupės;
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
123
12) nuolatinės projekto grupės pastangos didinti savo efektyvumą ir prisiderinti prie
aplinkybių.
Plačiau apie lankstųjį metodą rašoma, pvz., šaltinyje [SS07].
15.1. Grumtynės (Scrum)
Grumtynės (scrum) yra vienas iš lanksčiųjų metodų programų sistemoms kurti [KS04;
SS11]. Jis dar vadinamas hiperproduktyvumo įrankiu, nes kai kuriais atvejais žymiai pagerina
projekto grupių produktyvumą, anksčiau naudojusių tradicines (krioklio, spiralės)
metodologijas.
Grumtynių (scrum) metodui būdinga:
- dokumentas, kuriame prioritetų tvarka surašomos nepradėtos ir neužbaigtos projekto
užduotys (living backlog);
- trumpas laikotarpis (sprint) kelioms užduotims įvykdyti;
- trumpi kasdieniniai susirinkimai-grumtynės (scrum) nuveiktiems darbams ir
planuojamiems darbams pristatyti;
- planavimo posėdžiai, kurių metu sudaromas užduočių rinkinys kitam laikotarpiui;
- susirinkimas laikotarpio pabaigoje vykdytoms užduotims aptarti, kodėl joms vykdyti
laiko įverčiai skyrėsi nuo realiai sugaišto laiko;
- per laikotarpį gautų rezultatų demonstracija, kuriuos pristato užduočių vykdytojų
grupės.
Grumtynių (scrum) metode įvardinamas užduoties vykdytojų grupės koordinatorius, nors
jo teisės ir nesiskiria nuo kitų grupės narių. Koordinatoriaus pareiga yra šalinti kliūtis,
trukdančias atlikti užduotis.
Grumtynių (scrum) metodo privalumas - betarpiškai bendraujančios grupės. Metodo
trūkumas yra tas, kad grupėse turi būti pakankamai iniciatyvių narių (organizacinių sugebėjimų
turinčių narių).
15.2. Aukštasis programavimas (XP)
Aukštasis arba ekstremalusis programavimas (angl. eXtreme Programming - XP) – plačiai
paplitusi lanksčiojo metodo atmaina, kurios pradininkai yra Kent Beck, Ward Cunningham ir Ron
Jeffries [XP09].
Aukštojo programavimo (XP) pagrindiniai principai:
- bendravimas tarp užsakovo ir projekto vykdytojo. Tam į aukštojo programavimo
metodu dirbančią grupę įtraukiamas užsakovas, padedantis detalizuoti darbus ir sudėlioti juos
prioritetų tvarka, galintis iškart atsakyti į iškilusius klausimus;
- mokymasis. Tai įgalina sutrumpinti programavimo darbų laiką. Testuojama
programavimo metu;
- programos paprastumas. Kuo programa paprastesnė, tuo didesnė tikimybė, kad ji gerai
veiks. Prireikus, sudėtingos konstrukcijos keičiamos paprastesnėmis ir šalinami
besidubliuojantys elementai. Pernelyg komplikuotos programos perrašomos naujai.
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
124
- programų peržiūros. Aukštojo programavimo atstovai dirba poromis, prie vieno
monitoriaus ir klaviatūros, todėl visas programos kodas peržiūrimas rašymo metu;
- programos testavimas. Testai rengiami prieš pradedant rašyti programą. Užduotis
laikoma baigta tik tada, kai visi testai baigiami sėkmingai.
Sakoma, kad aukštasis programavimas labiausiai tinkamas mažose, iki 12 žmonių dydžio
grupėse. Aukštojo programavimo metodologijos naudotojai dažnai renkasi dinamiškas
programavimo kalbas, leidžiančias greičiau pasiekti reikiamų rezultatų.
Aukštojo programavimo metodo kritikai laikosi tos nuomonės, kad jo pagrindinis tikslas
yra suteikti programuotojui komfortiškas darbo sąlygas organizacijos vadovybės ir užsakovų
sąskaita. Vadovybė negauna aiškaus projekto plano, negali įvertinti projekto trukmės. Užsakovas
taip pat neturi fiksuoto projekto biudžeto ir sandorio garantijų, kad jam reikalinga programa bus
sukurta, bei turi skirti projektui vieną savo gerai išprususį darbuotoją.
Aukštasis programavimas kritikuojamas dar ir dėl šių aspektų:
- programavimo metu nesukuriami išsamūs dokumentai;
- programuotojai dirba poromis;
- prieš pradedant darbą nėra rengiamas rimtas planas.
Be čia paminėtų Grumtynių (scrum) ir Aukštojo programavimo (XP) lanksčiųjų metodų
yra ir kitų: Crystal Clear, Adaptive Software development, Feature Driven Development, Dynamic
Systems Development Method (DSDM).
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
125
Santrumpos
AĮ - aparatinė įranga;
ADM - darbų išdėstymo vaizdavimas rodykline diagrama (Arrow Diagramming Method);
AC - tikrosios (faktinės) projekto išlaidos iki duoto laiko (Actual Cost);
BAC - viso projekto kainos įvertis projekto pradžioje (Budget At Completion);
BCR - pelno ir kainos santykis (Benefit Cost Ratio);
BPR - verslo procesų reinžinerija (Business Process Re-engineering)
CBA - kainos-naudos analizės metodas (Cost Benefit Analysis);
CMM - organizacijos gebėjimų modelis (Capability Maturity Model);
COCOMO - konstruktyvusis kainos modelis (COnstructive COst MOdel);
COTS - gatava komercinė programinė įranga (Commercial Of The Shelf);
CPI - išlaidų indeksas (Cost Performance Index);
CPM - kritinio kelio metodas (Critical Path Method);
CV - išlaidų nuokrypis (Cost Variance);
DB - duomenų bazė;
DCF - diskontuotas pinigų srautas (Discounted Cash Flow);
DFD - duomenų sekų diagrama (Data Float Diagram);
EAC - viso projekto patikslintos kainos įvertis duotu laiku (Estimate At Completion);
ETC - nuo duoto laiko iki projekto pabaigos likusių darbų prognozuojama kaina
(Estimate To Complete);
EV - iki duoto laiko atliktų darbų vertė (Earned Value);
IRR - vidinės grąžos norma (Internal Rate of Return);
IT - informacinės technologijos;
NPV - grynoji dabartinė vertė (Net Present Value);
PDM - darbų išdėstymo vaizdavimas stačiakampių diagrama (Precedence Diagramming
Method);
PĮ - programinė įranga;
PMBOK - projektų valdymo žinynas (Project Management Body Of Knowledge);
PMI - projektų valdymo institutas (Project Management Institute);
PMO - projektų valdymo skyrius (Program Management Office);
PS - programų sistema;
PV - projekto biudžete duotam laikotarpiui skirta suma (Planned Value);
RFP - kvietimus teikti pasiūlymus (Request For Proposal);
ROI - atsipirkimo norma (Return On Investment);
SDLC - sistemų kūrimo ciklas (System Development Life Cycle);
SDS - sistemos projekto specifikacija (System Design Specification);
SOW - sandorių darbo užduotis (Statement Of Work);
SPI - darbų indeksas (Schedule Performance Index);
SV - darbų nuokrypis (Schedule Variance);
TCPI - darbų tęstinumo indeksas (To-Complete Performance Index);
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
126
TQM - bendrasis kokybės valdymas (Total Quality Management);
VAC - viso projekto kainos nuokrypis nuo kainos įverčio projekto pradžioje
(Variance At Completion);
WBS - projekto suskaidytų darbų lentelė (Work Breakdown Structure); XP - aukštasis programavimas (eXtreme Programming).
Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra
V.Undzėnas, PROGRAMŲ SISTEMŲ PROJEKTŲ IR KOKYBĖS VALDYMAS, Mokymo medžiaga, Vilnius, 2011
127
Šaltiniai
[BECK01] Kent Beck et al. Manifesto for Agile Software Development, 2001.
www.agilemanifesto.org .
[CMMI] Software Engineering Institute, “Capability Maturity Model Integration, v1.1”,
CMU/SEI-2002-TR-002, ESC-TR-2002-002, December 2001.
[FF06] Fabrizio Fioravanti. Skills For Managing Rapidly Changing IT projects. IRM press.
2006.
[HC04] W. Heldman, L. Cram. PROJECT+Study guide. Wiley Publishing, Inc., Indianapolis,
Indiana, 434 p., 2004.
[ISO25010] ISO/IEC 25010:2011. Systems and software engineering -- Systems and software
Quality Requirements and Evaluation (SQuaRE) -- System and software quality
models.
[ISO9126] ISO/IEC 9126-1:2001. Software Engineering-Product Quality-Part 1: Quality Model.
[JT06] Jean Tabaka. Collaboration Explained: Facilitation Skills for Software Project
Leaders. Addison Wesley Professional, 456 p., 2006.
[KHR05] Kenneth H. Rose. Project Quality Management. J. Ross Publishing, 2005.
[KS04] Ken Schwaber. Agile Project Management with Scrum. Microsoft Press. ISBN 978-0-
735-61993-7, 2004.
[LPL00] Lawrence P.Leach. Critical chain project management. ArtechHouse, Boston-
London, 337 p., 2000.
[PFR02] Parviz F.Rad, Project Estimating and Cost Management. Management Concepts,
2002.
[PMBOK] A Guide to the Project Management Body of Knowledge, Fourth edition. Project
Management Institute, 459 p., 2008.
[RBC05] Ronald B.Cagle. Your Successful Project Management Career. AMACOM, 224 p.,
2005.
[SOX] Ivy Xiying Zhang. Economic Consequences of the Sarbanes-Oxley 2002. University
of Rochester, 68 p., 2005.
http://w4.stern.nyu.edu/accounting/docs/speaker_papers/spring2005/Zhang_Ivy_Econo
mic_Consequences_of_S_O.pdf .
[SS11] Ken Schwaber and Jeff Sutherland. The Scrum Guide. 17 p., 2011.
http://www.scrum.org/storage/scrumguides/Scrum%20Guide%20-%202011.pdf
[SW07] James Shore and Shane Warden. The Art of Agile Development. O‘Reilly Media, 418
p., 2007.
[XP09] Extreme Programming: A Gentle Introduction. 2009.
http://www.extremeprogramming.org/ .
[WL06] Walt Lipke. The TCPI indicator. Transforming project performance. Project
management institute (USA), Oklahoma, 7 p., 2006.
http://www.earnedschedule.com/Docs/The%20TCPI%20Indicator%20-%20P&P.pdf