projektų ir kokybės valdymas

projektų ir kokybės valdymas
Vilniaus universitetas Matematikos ir informatikos fakultetas Programų sistemų katedra Valdas Undzėnas Programų sistemų projektų ir kokybės valdymas Dalykas skaitomas Programų sistemų 4 kurso bakalaurams 2013 m.

Programų sistemų projektų ir kokybės valdymas Bendrieji užsiėmimų klausimai
Užsiėmimų forma a) paskaitos; b) pratybos. Įvairiais aspektais nagrinėjama dalyko medžiaga. Atsiskaitymas už dėstomą dalyką a) medžiagos įsisavinimo testai pratybų metu; b) egzaminas; c) svoris galutiniame įvertinime: 40% - pratybų testai; 60% - egzaminas. Šaltiniai 1. A Guide to the Project Management Body of Knowledge (PMBOK), Fourth edition. 459 p., 2008. 2. V.Undzėnas. Programų sistemų projektų ir kokybės valdymas. Mokymo medžiaga, VU MIF, 2011, 136 p. . 3. Standartai; internete ir kitur randami šaltiniai.

Programų sistemų projektų ir kokybės valdymas Bendrieji užsiėmimų klausimai
Mokomojo dalyko skyriai 1) projektų valdymo įvadas; 2) projekto inicijavimas; 3) projekto apimties planavimas; 4) darbų grafiko planavimas; 5) projekto kainos planavimas; 6) projekto grupės planavimas; 7) kokybės planavimas; 8) rizikos planavimas; 9) komunikacijų planavimas; 10) pirkimų planavimas; 11) projekto bendrojo plano rengimas; 12) projekto vykdymas; 13) projekto kontrolė; 14) projekto užbaigimas; 15) lankstieji metodai.

I. Projektų valdymo įvadas (1)
Projektų valdymo svarba m. Standish Group studija (CHAOS) nustatė, kad tik 16.2 % iš visų IT projektų yra sėkmingai įvykdomi (projekto tikslai pasiekiami numatytu laiku ir neviršijant biudžeto). 2. The Standish Group's just-released report, "CHAOS Summary 2009" "This year's results show a marked decrease in project success rates, with 32% of all projects succeeding ...; 44% were challenged ...; 24% failed ...“ 3. Iš interviu su valstybės kontroliere R.Budbergyte: „Nustatyta, kad pasaulyje tik 16 proc. projektų įgyvendinama laiku. Apie 50 proc. jų dėl blogos vadybos pabrangsta 220 proc., o jų įgyvendinimo laikas pailgėja iki 167 proc. Neinvestuojam į kvalifikuotą žmogų, kad jis vadovautų projektui, ir taip padarom nuostolių valstybei. ...“ [„Valstybės tarnybos aktualijos“, 2007 liepa, Nr. 8, „NIEKO NEKEISDAMI, PRIEISIME LIEPTO GALĄ”].

I. Projektų valdymo įvadas (0b)
4. Tarptautinė projektų valdymo asociacija (IPMA) nustatė, kad geras projektų valdymas leidžia sutrumpinti projektų atlikimo trukmę vidutiniškai 20–30 %, o išlaidas sumažinti 10–15 %. 5. Projekto sėkmei didesnę įtaką turi geras valdymas nei technologiniai veiksniai. 6. Žurnalas “International Journal of Project Management” paskelbė: “21 a. projektų valdymas pakeis tradicinę funkcinę vadybą”.

1. Projekto sąvokos apibrėžimas 1.1. Kas yra IT projektas? Tai unikalių produktų ar paslaugų kūrimo veikla, kurie galės būti parduodami klientams arba naudojami savo organizacijoje. Projektai visada būna ribotos trukmės, pradedami tik turint aiškius tikslus ir akcininkus. Programa yra grupė susijusių projektų. 1.2. IT projektų vadovų bendrosios pareigos Projekto vadovo pareigos: projekto vadovas, verslo, programų sistemų, biudžeto, teisinių klausimų analitikas, derybininkas, technologas, strategas, ryšių palaikymo atstovas, laiko skirstytojas, projekto grupės sudarytojas. 1.3. IT projektų svarstymo kalba Su pašnekovais stenkimės kalbėti kiek įmanoma jiems aiškesne kalba.

2. Projektų valdymo apibrėžimas Projekto valdymas - tai žinių, įgūdžių, instrumentų ir metodų naudojimas projekto reikalavimams įgyvendinti. Žinių sritys, kuriomis remiasi projektų valdymas: 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.

3. Bendrieji projekto vadovo įgūdžiai 1) mokėjimas vadovauti; 2) gebėjimas komunikuoti (palaikyti ryšį) balsu; 3) gebėjimas komunikuoti raštu; 4) mokėjimas išklausyti kitų; 5) organizaciniai gebėjimai; 6) mokėjimas skirstyti laiką; 7) planavimo gebėjimai; 8) gebėjimas spręsti problemas; 9) gebėjimas susitarti (prieiti konsensuso); 10) gebėjimas spręsti konfliktus; 11) mokėjimas derėtis; 12) gebėjimas suburti projekto grupę.

4. Projektų valdymo procesai (veiklos) Duomenys gaunami iš procesų grupės Procesų grupės pavadinimas Rezultatai perduodami procesų grupei Iniciatorius Inicijavimas Planavimas Kontrolė Vykdymas Užbaigimas Naudotojai

Trumpas projektų valdymo procesų apibūdinimas: 1) inicijavimas. Tai veiklos, kuriomis siekiama parodyti, kad reikia pradėti projektą: verslo poreikių įvardinimas, reikalavimų metmenų parengimas, kainos numatymas. Sprendimo vykdyti projektą priėmimas; 2) planavimas. Detalizuojami projekto tikslai, įvertinama projekto trukmė, kaina, kiekvienam darbui reikalingi ištekliai, parengiamas projekto planas; 3) vykdymas. Projekte numatytos sistemos kūrimo darbų valdymas. Projekto vadovas koordinuoja projekto grupės narių darbą ir projektui skirtų išteklių naudojimą; 4) kontrolė. Stebima projekto eiga, nukrypimai nuo projekto plano. Analizuojami prašymai daryti projekto pakeitimus, priimami sprendimai; 5) užbaigimas. Projekte sukurtos sistemos formalus priėmimas (užsakovas priima iš projekto vykdytojo) ir perdavimas einamajam darbiniam naudojimui.

Projekto iniciatorius /sponsorius Įmonės aplinka (organizaciniai aspektai, projektų valdymo informacinė sistema, žmoniškieji ištekliai) Įmonės org. dokumentai (taisyklės, procedūros, standartai, apibrėžti procesai, kt.) Projekto nuostatai; preliminari projekto apimtis Projekto valdymo planas Rezultatai; prašymai daryti pakeitimus, pataisymus, šalinti defektus; informacija apie darbų eigą 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, paslaugos, rezultatai Inicijavimas Planavimas Vykdymas Kontrolė

Projekto valdymo procesų persidengimas, kainos ir išteklių poreikio lygis Proceso lygis Kontrolė Projekto pradžia Projekto pabaiga

5. IT projektų gyvavimo ciklas Projekto gyvavimo ciklas – tai laike išdėstytų fazių (etapų) rinkinys. Jis bendriausiu būdu atspindi kiekvienos fazės rezultatus ir darbams reikalingų išteklių kategorijas, užbaigto projekto rezultatų naudojimą. Programų sistemų kūrimo ciklo (SDLC – Software Development Life Cycle) fazių atitikmuo projektų valdymo procesams: SDLC fazės Projektų valdymo procesai 1. Planavimo fazė Inicijavimas, planavimas 2. Analizės fazė 3. Projektavimo (design) fazė Planavimas 4. Realizavimo fazė Vykdymas, kontrolė 5. Naudojimo ir priežiūros fazė Užbaigimas

IT projekto etapai ir kontroliniai taškai Bet kurios programų sistemos kūrimo ciklas (SDLC) dalinamas į etapus (milestones), kas palengvina projekto eigos stebėjimą. Etapą sudaro labai aiškią pabaigą turinčių užduočių rinkinys. Apie etapo įvykdymą raportuojama vienareikšmiškai - taip arba ne. Projekto etapai savo ruožtu gali turėti keletą kontrolinių taškų (baselines, 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.

6. Organizacijos struktūros įtaka projektams Projektų valdymui didelę įtaką turi organizacijos struktūra, kurioje yra vykdomas projektas. Nuo to priklauso projekto vadovo įgaliojimai ir projekto vykdymui reikalingų išteklių skyrimas. Yra trijų tipų organizacijos: 1) funkcinio; 2) matricos; 3) projektinio.

6.1. Funkcinio tipo organizacija Darbuotojai jose yra paskirstyti į funkcinius padalinius (departamentus), pvz., personalo, finansų, teisės, tinklų priežiūros, IT, klientų aptarnavimo, kt. Funkcinio padalinio vadovas Darbuotojas ( asmuo – projekto grupės narys ) Organizacijos vadovas

Funkcinio tipo organizacijose projektai atliekami kaip atskiri, funkciniams 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.

6.2. Matricos tipo organizacija Matricos tipo organizacijos, panašiai kaip ir funkcinio tipo organizacijos, yra padalintos į funkcinius padalinius (departamentus). Funkcinio padalinio vadovas Vyriausiasis projektų vadovas Darbuotojas Projekto vadovas ( asmuo – projekto grupės narys ) Organizacijos vadovas

Matricos tipo organizacijose 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.

6.3. Projektinio tipo organizacija Šio tipo organizacijų pagrindinis darbas yra projektų vykdymas. Pagrindinis jų bruožas - aukšti įgaliojimai projektų vadovams, leidimas jiems naudoti išteklius visą projekto laiką, projektui vykdyti reikalingos darbo grupės sudarymas. Projekto vadovas Projekto vadovas Darbuotojas ( asmuo – projekto grupės narys ) Organizacijos vadovas

II. Projekto inicijavimas (1)
1. Prašymas (užsakymas) pradėti projektą Prašymo rengimo 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.

Reikalavimų metmenys (koncepcija, high-level requirements) 1) problemos apibrėžimas; 2) reikalavimų kategorijos: funkciniai, verslo, techniniai (nefunkciniai); 3) tiekėjų pasiūlymai; 4) reikalavimų metmenų dokumento rengimas, jo sudėtis: - problemos apibrėžimas; - tikslai; - strateginė vertė; - reikalavimai; - aplinkybių įvertinimas (projekto vykdytojo galimybės); - ankstesnė patirtis (istoriniai duomenys).

2. Projektų atranka 1) atrankos būdai. Sprendžiami leidimo pradėti projektą ir jo finansavimo klausimai. Tą daro organizacijos vadovybė, departamento ar kitokio padalinio vadovas. Sudėtingų projektų atveju rengiamos galimybių studijos (feasibility study) ir tik jų pagrindu priimami sprendimai. Vertinama nauda, rinkos dydis, rizika, alternatyvos. Tą daro tretieji (nesusiję) asmenys; 2) atrankos kriterijai: - sprendimų priėmimo modeliai; - ekspertų nuomonė.

Sprendimų priėmimo modeliai 1) naudą vertinantys modeliai: - kainos-naudos analizė (CBA – Cost Benefit Analysis). Vertinama projekto kaina, numatomi sutaupymai, prognozuojamas pajamų padidėjimas. Praktikoje dažniausiai naudojamas pelno ir kainos santykis (BCR – Benefit Cost Ratio). Jei BCR > 1, projektas atsipirko. Kuo BCR didesnis, tuo projektas patrauklesnis; - vertinimo balais modelis (weighted scoring model). Naudojami iš anksto nustatyti kriterijai, remiantis kuriais projektai yra reitinguojami. Kiekvienas kriterijus turi leistiną balų kiekį ir svorio koeficientą; - ekonominis modelis. Keletas jame naudojamų bendriausių sąvokų: d – diskonto norma. d = (1+N) / (1+I) – 1 + r , kur N – palūkanų norma, I – infliacija, r - rizika; DCF (Discounted Cash Flow) – diskontuotas pinigų srautas. Tai diskontuotas pajamų ir išlaidų skirtumas per laiko periodą (pvz., metus);

NPV - grynoji dabartinė vertė (Net Present Value). Ji parodo pinigų sumos ateityje ekvivalentą šiandien. Apskaičiuojama kaip diskontuotų pinigų srautų suma: 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ė; Sn – n-tojo periodo pinigų srautas; d – diskonto norma. S0 yra išlaidos projekto pradžioje. Kuo NPV didesnis, tuo projektas yra patrauklesnis; atsipirkimo periodas (payback period). Tai numatomas laiko tarpas, per kurį projektas atsipirks; IRR - vidinės grąžos norma (Internal Rate of Return). Gaunamas pagal formulę: 0 = Σn ( Sn / (1+IRR)n ), kai NPV = 0. Kuo IRR didesnis, tuo projektas rentabilesnis (pelningesnis). Pvz., jei d < IRR, verta skolintis pinigų ir pradėti projektą. Kitu atveju – ne;

ROI - atsipirkimo norma (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; 2) matematiniai optimizacijos modeliai. Šie modeliai naudojami labai sudėtingiems projektams įvertinti ir atrinkti, reikalauja gilių statistikos ir kitų matematikos žinių. Tai tiesiniai, netiesiniai, dinaminiai ir kitokie programavimo algoritmai, sprendimų medžiai ir kita. Ekspertų nuomonė Ekspertizę gali atlikti sponsorius, pagrindiniai akcininkai, konsultantai, pramonės atstovai. Ekspertų nuomonė gali būti derinama su sprendimo priėmimo modelio rezultatais. To prireikia, kai atrankai pateiktų projektų įverčiai, gauti naudojant sprendimo priėmimo modelį, mažai tesiskiria. Nors ekspertai ir daro paprastesnį projektų atrankos procesą, tačiau pavojus suklysti išlieka.

3. Projekto akcininkai 1) sponsorius. Projekto sponsorius yra ypatingas akcininkas ir jis turėtų būti tik vienas. Sponsorius yra asmuo, kuris remia projektą organizacijos vardu. 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) kiti projekto akcininkai: - projekto vadovas; - projekto grupės nariai; - organizacijos funkcinių padalinių vadovai; - pirkėjai/klientai; - galiniai naudotojai; 3) kas yra jūsų projekto akcininkai? - vienos veiklos srities projektas; - keleto veiklos sričių projektas; - įmonės projektas; - akcininkų sąrašas.

4. Projekto nuostatai (project chart) Tai pradinis projekto dokumentas (projekto pagrindas). Jo sudėtis: - reikalavimų metmenys (high-level requirements); - informacija apie projekto grupę. Projekto vadovo įgaliojimai, reikiami specialistai, subrangovai; - uždaviniai ir tikslai; - projekto pagrindimas. Kaina, nauda, atsipirkimo periodas; - formalus projekto patvirtinimas. Vadovų hierarchija.

III. Projekto apimties planavimas (1)
Projekto apimtis (project scope) - jam įvykdyti reikalingų darbų kiekis ir dydis. Apimties planavimo metu apibrėžiamas reikiamas išteklių kiekis ir nustatomi projekto apribojimai (terminai, kaina, kokybė). Projekto nuostatai yra įeities duomenys projekto apimties planui rengti. 1. Projekto apimties plano struktūra Sukurtame projekto apimties plane turi būti šios trys dalys: - apimties aprašas; - apimties valdymo planas; - suskaidytų darbų lentelė (WBS – Work Breakdown Structure).

1.1. Projekto apimties aprašas - projekto poreikis; - reikalavimai; - pagrindiniai laukiami rezultatai; - sėkmės kriterijai; - projekto užbaigimo kriterijus; - trukmės ir kainos metmenys; - prielaidos; - apribojimai. Projekto poreikis Išdėstomi prašymo pradėti projektą argumentai, teisės aktai, kuriais yra paremtas prašymas.

Reikalavimai Aprašomos sistemos savybės ir funkcijos, akcentuojama naujovės. Tai papildyti, detalizuoti reikalavimų metmenys, kurie buvo projekto nuostatuose. Laukiami projekto rezultatai Pateikiama suvestinė lentelė rezultatų, kurie turi būti gauti kuriant produktą. Pvz., sistema, naudojimo instrukcija, mokymo medžiaga, pagalbos naudotojams priemonės. Sėkmės kriterijai Nurodomi veiklos srities, kuriai yra vykdomas projektas, pagerėjimo rezultatai. Jų pasiekimo laipsnį turi būti galima įvertinti kiekybiškai. Kriterijų pavyzdžiai: bendras pajamų padidėjimas, darbo našumo padidėjimas, atitikimas teisės aktams, darbuotojų kiekio sumažėjimas.

Projekto užbaigimo kriterijus Juo parodoma, kada laikysime projektą užbaigtu. Pvz., gali būti reikalaujama, kad pridavimo metu sistema turi veikti be jokių priekaištų. Trukmės ir kainos metmenys Projekto trukmės ir dabartinės projekto kainos metmenys gaunami remiantis panašių jau vykdytų projektų duomenimis arba patirtį panašiuose darbuose turinčio eksperto nuomonės. Tai nėra tikslūs duomenys. IT projektuose kainos metmenų paklaida būna iki 75%. Prielaidos Prielaida – tai veiksmas, sąlygos ar įvykis, kurio tikimasi. Apribojimai Jie yra dviejų tipų. Pirmieji susiję su laiku, kaina, kokybe, apimtim. Antrieji yra specifiniai ir siejami su darbų grafiku, žmoniškaisiais ištekliais, sistemos testavimo galimybėmis.

1.2. Projekto apimties valdymo planas Aprašomos procedūros, kurių reikės laikytis norint daryti bet kokius projekto apimties pakeitimus viso jo gyvavimo ciklo bėgyje. Apimties valdymo procesui, mažiausiai, turi būti parengti: - standartinė prašymų forma keitimams projekte 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; - viso projekto plano koregavimo būdas.

1.3. Projekto suskaidytų darbų lentelė Projekto suskaidytų darbų lentelėje (WBS – Work Breakdown Structure) nurodomi pagrindiniai projekto darbai. Darbai skaidomi į keletą lygių tol, kad žemiausio lygio darbų įvykdymo laipsnį galima būtų išmatuoti ir būtų aišku, kokio finansavimo jiems reikėtų. 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 Darbelis Darbelis 1 lygis 2 lygis 3 lygis t. t. 1. Darbų grupė WBS su numeruojamais darbais

WBS rengimo gairės - pasitelkime išmanančius žmones. Nesistenkime viską daryti patys; - kiekvienas žemesnio lygio punktas yra aukščiau esančio lygio komponentas. Skaidykime darbus į tiek lygių, kad jau galėtume rengti darbų trukmės, kainos ir reikiamų išteklių įverčius; - nekurkime pernelyg smulkių darbų lentelės. Remkimės 8/80 taisykle: darbai ne trumpesni nei 8 valandos ir ne ilgesni nei 80 valandų; - kiekvieną punktą skaidykime į tinkamą lygių kiekį; - naudokime skaitinius numerius kiekvienam WBS darbui. WBS nauda WBS yra projekto trukmės ir kainos, reikalingų išteklių vertinimo pagrindas. Tai instrumentas, padedantis bendrauti projekto grupės nariams, bendrauti su užsakovu, stebėti projekto eigą, kt.

2. IT projekto apimtį įtakojantys veiksniai - IT įmonės dydis; - projekto siekiamų rezultatų apibrėžimo tikslumas; - darbo su užsakovu aplinkybės; - sėkmės kriterijų apibrėžimo sunkumas; - pašaliniai ar neišsiaiškinti elementai; - santykiai su tiekėjais; - projekto grupės narių pasitraukimas; - projekto darbų dalinimas keliems IT padaliniams; - testuojami elementai reikalauja gero apibrėžimo.

IV. Darbų grafiko planavimas (1)
Projekto darbų grafiko (schedule) rengimo įeities duomenys yra WBS, kuris buvo sudarytas projekto apimties planavimo metu. 1. Darbų eilės tvarka 1.1. Darbų priklausomybių tipai - privalomoji priklausomybė; - savarankiškai nustatoma priklausomybė; - išorinė priklausomybė.

1.2. Darbų priklausomybės pobūdis a) pabaigos-pradžios b) pabaigos-pabaigos c) pradžios-pradžios d) pradžios-pabaigos Pirmasis darbas Antrasis darbas Pirmasis darbas Antrasis darbas Pirmasis darbas Antrasis darbas Pirmasis darbas Antrasis darbas

1.3. Darbų išdėstymo diagramos a) darbų išdėstymas PDM (Precedence Diagramming Method) diagrama. Kitur vadinama AON – Activity On Node. b) darbų išdėstymas ADM (Arrow Diagramming Method) diagrama. Kitur vadinama AOA – Activity On Arrow. A darbas Pradžia B darbas C darbas D darbas Pabaiga A darbas Pradžia B darbas C darbas D darbas Pabaiga

2. Darbų trukmės vertinimas 2.1. Trukmės apibrėžimas Darbo atlikimo trukmė apima bendrąjį kalendorinį laiką (įskaitant laisvadienius ir švenčių dienas). 2.2. Trukmės vertinimo būdai a) analogiškasis arba iš viršaus–žemyn. Remiamasi anksčiau vykdytų projektų panašiems darbams realiai sugaišto laiko perėmimu. Žemas tikslumas; b) ekspertinis. Pasitelkiami projekto darbus gerai išmanantys žmonės; c) kiekybiškasis. Naudojamas, kai yra išmatuota tam tikro darbų kiekio trukmė ir yra formulės viso darbo trukmei apskaičiuoti. Tiksliausias būdas.

Darbų išdėstymo diagramos pavyzdys: Pradžia A darbas: 3 dienos C darbas: 8 dienos B darbas: 5 dienos D darbas: 12 dienų E darbas: 6 dienos Pabaiga

3. Darbų grafiko sudarymas 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. 3.1. Kritinio kelio metodas Kritinio kelio metodas (CPM) yra matematinio analizavimo būdas. Kritinis kelias projekto darbų grafike yra ilgiausios darbų sekos kelias projekte, nuo kurio priklauso viso projekto pabaigos terminas. Kritinio kelio darbų trukmės negali turėti svyravimų. Gali svyruoti tik darbo pradžios laikas arba darbui užbaigti papildomai skiriamo laiko trukmė.

CPM metodo eiga: a) peržiūra pirmyn. Visų pirma randamos darbų sekos, vedančios nuo projekto pradžios iki pabaigos. Kiekvienam darbui apskaičiuojamas anksčiausias pradžios laikas ir anksčiausias pabaigos laikas; b) peržiūra atgal. Darbų išdėstymo diagramos analizė pradedama nuo galo ir einama link pradžios. Kiekvienam darbui apskaičiuojama vėliausia darbo pradžia ir vėliausia darbo pabaiga; c) laikų svyravimų radimas. 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ų. Kritinis darbų kelias bus tas, kuriame visų darbų laikų svyravimai lygūs 0.

Kritinio darbų kelio nustatymo iliustracija, remiantis turėta darbų diagrama. Pradžia A darbas: 3 dienos C darbas: 8 dienos B darbas: 5 dienos D darbas: 12 dienų E darbas: 6 dienos Pabaiga Darbas Anksčiausia pradžia Anksčiausia pabaiga Vėliausia pradžia Vėliausia pabaiga Svyravimai A 3 B 8 C 11 6 14 D 20 E 17

d) 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: - papildomų išteklių (pvz., darbuotojų) skyrimas; - lygiagretus darbų atlikimas, kurie normaliai būtų atliekami nuosekliai. Minėtiems darbų grafiko planavimo darbams atlikti yra įrankiai: projektų valdymo programinė įranga, pvz., Microsoft Project.

3.2. Projekto etapai Etapai turi atspindėti pagrindinius projekto gyvavimo ciklo įvykius. Jų datos nurodo, kada turi būti gauti svarbūs projekto rezultatai. Projekto darbų grafike etapų pabaigos laikai nustatomi tokie, kad juose įvardintus darbus būtų galima be išlygų atlikti 100 proc. Etapo darbų atlikimas turi būti vertinamas vienareikšmiškai: atlikta arba neatlikta. 3.3. Darbų grafiko kontroliniai taškai 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į. 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. Projekto terminai ir tikrovė 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. Parengti gerą projekto darbų grafiką nėra lengva. Dalį problemų gali padėti išspręsti bendri organizacijos interesai. Jei jūsų projektas yra svarbus ir 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.

V. Projekto kainos planavimas (1)
Projekto vadovas, turėdamas projekto apimties aprašą, darbų sąrašą (WBS) ir jų atlikimo grafiką, turi parengti projekto biudžetą, ir, kai jį patvirtina projekto rėmėjai, tvarkyti jį. Lėšos yra numatomos kiekvienam projekto etapui. Biudžeto išlaidoms sekti taip pat yra naudojami kontroliniai taškai. 1. Išteklių planavimas Išteklių planavimo pradžioje reikėtų pasidomėti, kur galima būtų gauti informacijos apie anksčiau vykdytų panašių projektų išteklius. 1.1. Išteklių tipai - žmoniškieji ištekliai; - įranga; - medžiagos.

1.2. Išteklių poreikio nustatymas Išteklių poreikio dokumente aprašomi kiekvienam projekto darbui reikalingi visų trijų tipų ištekliai. Tam rengiami: - pareigų aprašai; - įrangos ir medžiagų aprašai; - reikiamų išteklių lentelė (pavyzdys žemiau). Darbas Programuo-tojai Inžinieriai Ekonomistai Dokumentų rengėjai Serveriai A 1 B 2 C 3 D 4 E

2. Išteklių kainos vertinimas 2.1. Kainos vertinimo būdai a) analogiškasis. Remiasi anksčiau vykdytų projektų patirtimi. Kitaip jis dar vadinamas iš viršaus-žemyn (top down) arba leistinų ribų (order of magnitude) kainos vertinimo būdu. Naudojamas visam projektui, atskiroms jo dalims ar rezultatams. Tačiau jis nėra naudojamas vertinant išteklių poreikį atskiriems darbams ar jų grupėms. 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.

b) parametrinis modeliavimas. Tai matematiniai modeliai. Geriausiai tinka statybų projektuose. 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.

c) pavyzdinis vertinimas (definitive estimates). Duoda geriausią tikslumą, nes 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). Projekto darbų (WBS) ir reikiamų išteklių sąrašai 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. Vertinant reikiamų išteklių kainas, būtina remtis pastangų dydžiu, kas matuojama žmogaus darbo valandomis. Skirtumas tarp darbui atlikti reikalingo laiko ir pastangų dydžio yra tas, kad trukmės įverčiai darbų grafike padeda mums nustatyti, kiek gi kalendorinio laiko reikės projektui užbaigti, o pastangų dydžio įverčiai naudojami projekto kainai nustatyti

Projektui įvykdyti reikalingų pastangų dydžio pavyzdys Dar vieni duomenys, kurių reikia pavyzdiniam kainos vertinimo būdui, yra kiekvieno tipo išteklių kaina (įkainiai): valandos arba dienos kaina, mokestis (pvz., naudojimosi sistema) ar vertė (pvz., el. energijos kilovatvalandės, kanceliarinės prekės). Darbas Ištekliai Pastangų dydis A Dokumentų rengėjai (1) 20 val. B Programuotojai (2) 100 val. C Inžinieriai (3) 60 val. Serveriai N/A D Programuotojai (4) 200 val. E Ekonomistai (1) 30 val.

Projekto kainos vertinimo pavyzdys: Darbas Ištekliai Pastangų dydis Kaina, įkainis Visa kaina A Dokumentų rengėjai (1) 20 val. 30 Lt/val 600 Lt B Programuotojai (2) 100 val. 50 Lt/val 5000 Lt C Inžinieriai (3) 60 val. 40 Lt/val 2400 Lt Serveriai N/A 50000 Lt D Programuotojai (4) 200 val. 10000 Lt E Ekonomistai (1) 30 val. 60 Lt/val 1800 Lt Iš viso: 69800 Lt

2.2. Kainos vertinimo rekomendacijos - šaukime projekto darbo grupės pasitarimus; - gerai suvokime naudojamą kainos vertinimo būdą; - naudokime kokį nors prieinamą šabloną; - stenkimės gauti įverčius iš darbą atliekančių žmonių; - numatykime lėšas projekto grupės nariams skatinti; - dokumentuokime visas prielaidas.

3. Projekto biudžeto sudarymas Projekto vadovas įvertintą projekto kainą perduoda organizacijos biudžeto tvarkytojams (pvz., finansų departamentui). 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 paskirstomos atskiriems projekto darbams. Projekto biudžetas padeda orientuotis, kokio dydžio išlaidos leistinos kiekvieno tipo ištekliams numatytais laikotarpiais. Dažniausiai biudžetas padalinamas mėnesiais. Prieš pradėdami projekto darbus susipažinkite su jūsų organizacijoje galiojančiomis taisyklėmis, projekto vadovo įgaliojimais tvarkyti projekto biudžeto klausimais.

3.1. Projekto biudžetas Projekto biudžetas rengiamas remiantis patvirtintu projekto kainos įverčiu ir darbų grafiku. Atkreiptinas dėmesys į du savarankiškus fondus, kurie gali būti biudžete: - specialųjį fondą. Juo siekiama sudaryti geresnes galimybes projekto rizikos klausimams spręsti. Dažniausiai naudojami priešakiniuose projektuose, kai nėra galimybės remtis ankstesnių projektų patirtimiir kainų įverčių paklaidos gali būti didelės. Dažniausiai projekto vadovui suteikiami įgaliojimai naudoti specialiojo fondo lėšas; - vadovybės rezervinį fondą. Jį skiria organizacijos vadovybė situacijoms spręsti (išeinant už pradinės apimties projekto ribų), kurių nebuvo galima numatyti rengiant projekto kainos įvertį. 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ų. Dažniausiai biudžetai būna lentelės pavidalo, padalinti mėnesiais ar metų ketvirčiais. Projekto biudžeto pavyzdys: Sausis Vasaris Kovas Suma Darbo užmokestis 600 Lt 1200 Lt 3000 Lt 4800 Lt Samdomas darbas (programuotojai) 5000 Lt 15000 Lt Aparatinė įranga (serveris) 50000 Lt Iš viso: 69800 Lt

3.2. Biudžeto lėšos projekto etapams 3.3. Biudžeto naudojimo kontroliniai taškai 3.4. Įrankis biudžetui sudaryti – projektų valdymo programinė įranga

VI. Projekto grupės planavimas (1)
Projekto kainos planavimo metu, kalbant apie žmoniškųjų išteklių poreikį, buvo akcentuojama darbuotojų specialybė, kokius darbus jie turėtų mokėti dirbti. Projekto grupės planavimo rezultatas – tai nustatyta grupės organizacinė struktūra ir kur ieškosime projektui vykdyti reikiamų specialistų. 1. Projekto grupės organizacinės struktūros planavimas 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.

1.1. Projekto sąsajos - organizacinės; - techninės; - tarp darbuotojų. 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ė. Šio dokumento pavidalas gali būti įvairus: lentelė, sąrašas, kt Svarstymo metu iki smulkmenų išsiaiškinami sponsoriaus suteikti įgaliojimai projekto vadovui, ypač jeigu projekto nuostatuose (project chart) jie buvo neaiškūs arba iš viso nebuvo nurodyti. Įgaliojimai projekto vadovui samdyti ar atleisti darbuotojus, naudoti projekto biudžeto lėšas turi būti dokumentuoti..

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. Projekto grupės organizacinės struktūros schemos pavyzdys: 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

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. 2. Projekto grupės narių atranka Geriausia, kai projektų vadovas apklausia pageidaujančius dirbti projekto grupėje ir turi įgaliojimus priimti tinkančius. Tačiau dažnai jam tenka tartis su savo organizacijos funkcinių padalinių vadovais, prašydamas skirti atitinkamos specialybės darbuotoją į projekto grupę.

2.1. Pretendentų į projekto grupę apklausa Jei jūsų organizacija yra matricos arba projektinio tipo, projekto vadovas turi daugiau galių pasirenkant darbuotojus. Numatomiems pokalbiams su pretendentais į projekto grupę reikėtų parengti klausimus: a) apie darbo įgūdžius: - kokia asmens kvalifikacija ir patirtis 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. Priklausomai nuo projekto specifikos, galimi ir kitokie klausimai.

2.2. Tarimasis su organizacijos funkcinių padalinių vadovais Jeigu projekto vykdymui priimamas žmogus, kuris turi įsipareigojimų kituose organizacijos darbuose, būtina išsiaiškinti, kiek valandų per dieną jis galės skirti jūsų projektui. Svarbus grupės narių atskaitomybės klausimas. Už tam tikrus rezultatus jis turi būti atskaitingas tik vienam vadovui – organizacijos funkcinio padalinio vadovui arba projekto vadovui. Projekto vadovas turėtų inicijuoti pasitarimus su reikalingų funkcinių padalinių vadovais darbuotojų skyrimo ir kitiems klausimams aptarti. Keletas patarimų: - su kiekvieno funkcinio padalinio vadovu tarkitės skirtingu laiku; - sužinokite asmenis, kurie galėtų padėti jums sudarant projekto grupę; - numatykite asmenis, kurių prašysite funkciniame padalinyje; - pirmiausia prašykite labiausiai reikalingų žmonių.

2.3. Kiti projekto grupės sudarymo scenarijai Projekto sponsorius gali norėti paskirti į projekto grupę tam tikrus žmones. Reikiamų specialistų samdymas iš išorės, jei tokių nėra jūsų organizacijoje.

VII. Kokybės planavimas (1)
Projekto kokybės valdymas apima tris procesus: kokybės planavimą, veiklų kokybei užtikrinti vykdymą ir kokybės kontrolę. Čia nagrinėjamas tik kokybės planavimas, kurio tikslas yra įvardinti projektui tinkamus kokybės standartus ir apibrėžti jų taikymą, kad projekte sukurtas produktas atitiktų numatytus reikalavimus. Svarbiausias kokybės planavimo komponentas yra organizacijoje priimtos kokybės taisyklės (politika). Projekto vadovui reikėtų išsiaiškinti, ar toks dokumentas yra jo organizacijoje. 1. Kokybės užtikrinimo priemonės ir būdai Jūsų organizacijoje esančiose kokybės taisyklėse gali būti nurodytos priemonės ir būdai, darbų kryptys ir pastangos. Tai gali būti daugelyje projektų sutinkamos standartinės priemonės. Pramoninių standartų ar vyriausybės teisės aktų projektų vadovai taip pat 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.

1.1. Kokybės-naudos analizė Įvardinamos kokybės užtikrinimo veiklos, 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. 1.2. Lyginamoji analizė Lyginamoji analizė (benchmarking) yra toks tikrinimo būdas, kuriame lyginamos panašios veiklos. Naudingas, kai yra daromi turimos sistemos pakeitimai ar naujinimai (upgrade).

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ą, nustatyti kontrolinius taškus, kur reikėtų įvertinti tam tikrų darbų rezultatų kokybę ir tik po jų patikrinimo daryti kitus darbus. 1.4. Kokybės kaina Kokybės kaina yra visų kokybės užtikrinimo darbų kaina: - prevencinė (planavimas, darbuotojų mokymas, modulių tikrinimas); - įvertinimo (sukurto produkto apžiūra, testavimas, kokybės auditas; - neatitikimų šalinimo.

2. Kokybės valdymo planas Šiame plane surašomi visi projekte kuriamo produkto kokybei užtikrinti reikalingi darbai, procedūros, tikrinimo būdai ir tiems darbams atlikti reikalingi ištekliai. Tikrinimo būduose nurodomos 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 - kompaktiškumą, veikimo greitį, tikslumą, 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. Testavimo darbams gali būti samdomos nepriklausomos organizacijos. Taip elgiamasi dideliuose IT projektuose.

Kriterijai. Jei projektas buvo skaidomas į etapus, tai etapų rezultatams įvertinti gali būti naudojami ir kokybės kriterijai. Tokiu atveju 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.

VIII. Rizikos planavimas (1)
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 - 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. IT projektuose rizikos poveikis išlaidoms gali siekti net kelis šimtus procentų. Rizikos planavimas – tai veiksmų numatymas, projekte iškilus nenumatytoms aplinkybėms.

1. Rizikos veiksnių įvardinimas 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ė. Lokalieji rizikos veiksniai yra susiję su tam tikrais projekto etapais arba su tam tikrais projekto darbais.

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 įranga, kurią naudosite užduočiai vykdyti?

2. Rizikos analizė Rizikos analizės metu aiškinamasi, kurie įvardinti rizikos veiksniai yra pavojingiausi projektui, ir jie surikiuojami prioritetų tvarka. 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 apskaičiuoti, jos poveikį projekto tikslams ir padarinius visam projektui. Modernūs 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.

Kokybinės analizės metu įvardinti rizikos veiksniai charakterizuojami tikimybe ir galimo neigiamo poveikio dydžiu projektui. Tikimybė ir poveikis dažniausiai nurodomi taip: aukštas, vidutinis arba žemas. Laikantis tokio vertinimo, sudaroma visų įvardintų rizikos veiksnių apibūdinimo lentelė. Rizikos veiksnių apibūdinimo lentelės pavyzdys: 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. 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

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 rizikingus darbus. - rizikos nukreipimas kitiems. Atsakomybė už riziką perkeliama trečiosioms šalims; - rizikos mažinimas. Rizikos veiksnių tikimybės ir poveikio dydžio mažinimas; - rizikos prisiėmimas. Paprastai prisiimama žemesnio prioriteto rizika arba taip elgiamasi, kai nėra kitos išeities.

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: - 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?

3.2. Veiksmai nenumatytais atvejais 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, pvz., toks: Toks rizikos valdymo planas gali būti pateiktas projekto sponsoriui, akcininkams. Rizikos veiksnys Tikimybė Poveikio dydis Galimos pasekmės Prevencinės arba nenumatytų atvejų priemonės Veiksnys Nr. 1 Aušta Aukštas Aukštos Priemonės aprašas Veiksnys Nr. 2 Vidutinė Vidutinis Žemos Nėra Veiksnys Nr. 3 Aukšta vidutinės

IX. Komunikacijų planavimas (1)
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. 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.

1. Komunikacijų strategija 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. 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.

Projekto komunikacijų plano pavyzdys: Su kuo komunikuojam Komunikacijų tikslai, klausimai Komunikacijų būdas Atsakingas asmuo Komunikacijų dažnumas Projekto grupė Projekto tikslai, kontroliniai taškai, rizika, kt. Darbų grafikas, grupės susirinkimai, kontrolinis sąrašas Projekto vadovas Kas savaitę Projekto sponsorius Projekto eiga, Projekto ataskaita Rizika Kontrolinis sąrašas Finansai Biudžeto suvestinė Funkcinės grupės vedėjas Kas mėnesį Subrangovai Kontroliniai taškai, finansai Darbų ataskaita Kas mėnesį / kas ketvirtį Darbų eiga Telefonu Kas savaitę / kai reikia Kita

2. Komunikacija su projekto grupės nariais Projekto vadovo pagrindinis darbas yra palaikyti ryšį su grupės nariais, užtikrinti, kad visi žinotų projekto tikslus ir savo indėlį į rezultatą. 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 svarbu mokėti pasirinkti bendravimo su kiekvienu grupės nariu stilių. Neformaliems kontaktams vieni grupės nariai gali labiau mėgti el. paštą, kiti – telefoninius pokalbius.

3. Komunikacija su akcininkais Kad galėtume parengti komunikacijų su kitais akcininkais planą, visų pirma reikia sužinoti kas jie yra. Prisiminkime, kad akcininku yra tas, kas vienaip ar kitaip priklauso nuo projekto rezultatų. Jeigu akcininko atsakingasis atstovas gerai nesupranta, kokią įtaką projektas turės jų organizacijai, būtina su juo susisiekti ir paaiškinti visa tai. Atstovas gali būti labai užimtas ir todėl neskiria reikiamo dėmesio į jūsų projektą. Žinodami, kad atstovas gali skirti jums tik 5 minutes laiko, labai svarbu išnaudoti šį laiką protingai. Naudinga parengti projekto pristatymo planą, kuriame būtų: - nurodyti tuos projekto plano aspektus, kuriuos norite pristatyti; - išvardinti žinomą arba tikėtiną projekto naudą akcininkui; - apibrėžti pagrindinę informaciją, būtiną akcininkams.

Projekto, skirto naujai viešųjų pirkimų sistemai sukurti, pristatymo akcininkams plano pavyzdys. jame parodyti trys projekto pristatymo variantai. 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ų plėtimas ir gerinimas. Mokymų nauda detalės. Sistemos demonstracija Kaip (pasieks projekto tikslus) 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 Tiekimo grupė pradės sistemos pardavimus lapkričio 9 d. Mokymų rengimas. Mokymai naudoti sistemą Sąsaja su žmoniškųjų veiksnių grupe, klientų aptarnavimas

X. Pirkimų planavimas (1)
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. 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.

1. Kurti patiems ar pirkti? Sprendimui kurti patiems ar pirkti paslaugas arba gatavą produktą priimti įtakos turi nemažai veiksnių. Įranga. Jei yra kuriama nauja programų sistema ir jai įdiegti reikia aparatinės įrangos (AĮ, hardware), tokią AĮ galima pirkti iš kitos organizacijos arba nuomoti. Tik būtina atsižvelgti į įvairias aplinkybes: sukurtos sistemos gyvavimo trukmę, ar AĮ reikės dalintis su kitais, kt. Darbuotojų samdymas. Žmonės iš išorės gali būti samdomi visam projektui vykdyti arba tik atskiriems projekto darbams atlikti. Tačiau reikėtų vengti samdyti visus programuotojus, kad įvykdytumėte projektą. Galvokim ir apie būsimą sistemos priežiūrą. Kitos prekės ar paslaugos. Pvz., gali būti geriau pirkti mokymų paslaugas, nepriklausomus testuotojus. Patiems susikurti tam reikiamą infrastruktūrą gali neapsimokėti.

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. Šių žinių dažnai prireikia ir projektų vadovams. Dažniausiai sutinkami šių trijų kategorijų sandoriai: - fiksuotos kainos. Geriausia naudoti tada, kai yra gerai apibrėžtas kuriamas produktas ir yra nemažai informacijos iš ankstesnių panašių projektų; - išlaidas padengiantieji. Jie pirkėjams yra rizikingiausi, nes nežino galutinės kainos. Tačiau 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ę; - laiko ir medžiagų apmokėjimo. Naudojami įdarbinant papildomus žmones, kai specifiniams projekto darbams atlikti prireikia specialistų.

3. Darbo užduotis tiekėjams Darbo užduotyje (SOW – Statement Of Work) detaliai aprašomos prekės arba paslaugos, kurias jūs norite pirkti. 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. Netgi jei darbo užduotį yra rengęs kitas organizacijos departamentas (pvz., pirkimų), projekto vadovas turi užtikrinti projekto reikalavimų tikslumą. Daug kompanijų turi šablonus darbo užduotims rengti. Tai priemonė, padedanti perteikti tiekėjams išsamią informaciją.

4. Prašymas tiekėjams teikti pasiūlymus Prašymo teikti pasiūlymus (RFP – Request For Proposal) esmė yra gauti tiekėjų pasiūlymus užduotyje nurodytiems darbams atlikti. 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. 5. Tiekėjų atrankos kriterijai 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. Pvz., galimi tokie kriterijai: - visa pasiūlymo kaina; - 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.

XI. Projekto bendrojo plano rengimas (1)
1. Kas yra projekto planas? Projekto planas yra dokumentas, kuriame sujungti visi planavimo duomenys. Projekto vadovas naudos jį kaip vadovą darbų eigai stebėti. Apskritai, projekto planas laikas nuo laiko yra peržiūrimas ir koreguojamas. Projekto planas yra visų darbų eigos stebėjimo ir reikiamų korekcijų darymo pagrindas. 2. Projekto plano sudėtis Dažniausiai projekto plane yra tokios dalys: - bendroji. Pateikiama informacija apie organizaciją ir patį projektą; - suplanuoti dalykai. Talpinami visi planavimo rezultatai; - šablonai ir kontroliniai sąrašai. Naudojami projekto valdyme; - šaltinių nuorodos; - priedai.

2.1. Bendroji dalis Šioje dalyje paprastai būna tokie skyriai: - informacija apie dokumentą. Nurodoma informacija apie dokumento naujinimus ir priežiūrą, versijų numeriai ir peržiūrų datos, kontaktinė informacija; - turinys. Atspindima dokumento organizacinė struktūra – dalys, skyriai, poskyriai ir nuo kurio puslapio jie yra dokumente. 2.2. Suplanuoti dalykai Tai pagrindinė projekto plano dalis. Jos pagrindiniai skyriai: - santrauka (executive summary). Trumpai pristatomi projekto nuostatai (verslo poreikiai, kodėl buvo pradėtas projektas, projekto tikslai); - reikalavimai. Projekto funkciniai, techniniai ir verslo reikalavimai, kurie buvo suformuluoti projekto inicijavimo etape;

- apimtis. Pateikiamos projekto ribos, atitinkančios klientų sutartus siekiamus rezultatus; - akcininkai. Sąrašas asmenų, atsakingų už projekto rezultatus - sponsorius, klientai, projekto vadovas, projekto grupės nariai, kt.; - reikiami ištekliai. Išvardinami ne žmoniškieji ištekliai, 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; - 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šų;

- biudžetas. Nurodoma tik visa projekto kaina arba išskaidyta į 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 eigos stebėjimo klausimai; - komunikacijos. Nurodomas komunikacijų su sponsoriumi, klientais, projekto grupe ir kitais akcininkais būdas ir dažnumas;

- vykdymo planas. Tai 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. 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. Dėstoma, kaip bus mokomi sukurtos sistemos galiniai naudotojai, administratoriai, pagalbos teikimo tarnyba ir kitos grupės. 2.3. Šablonai ir kontroliniai sąrašai Kontrolinių sąrašų pavyzdžiai: - diegimo (instaliavimo) kontrolinis sąrašas; - testavimo kontrolinis sąrašas; - kiti kokybės kontroliniai sąrašai.

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 ir projektų valdymo metodologija; - kiti reikalingi reglamentai ar standartai. 2.5. Priedai - projekto darbų grafiko kontroliniai taškai; - projekto biudžeto kontroliniai taškai.

3. Projekto 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. 3.1. Plano rašymo organizavimas ir rašymas Prieš pradedant rašyti projekto planą visų pirma peržiūrimi turimi dokumentai ir numatoma jų pateikimo tvarka. Apibrėžiamos dokumentų tvarkymo procedūros: kaip turi būti daromi dokumento pakeitimai, kokia naujų versijų numeravimo sistema, kaip turi būti nurodomos versijų datos ir numeriai. Apsisprendžiama, kaip planas bus platinamas: atspausdintas popieriuje ar elektroniniu būdu.

3.2. Plano keitimas Plano pradinį variantą projekto vykdymo etape tenka ne kartą koreguoti. Projekto plano keitimas yra iteracinis procesas. Projekto eigoje pakeitus pagrindinius plano komponentus, būtina pakoreguoti įvairius plano skyrius. 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ą. Bet kokie projekto plano pakeitimai turi būti daromi griežtai laikantis nustatytos tvarkos. Jie turi būti daromi tik gavus oficialų patvirtinimą, išduotą laikantis projekto apimties valdymo plane nustatytų taisyklių. 3.3. Plano peržiūra Projekto planą peržiūri sponsorius ir akcininkai. Atviras klausimų ar interesų aptarimas padeda parengti geresnį projekto planą. Galutinė projekto plano peržiūra yra formali procedūra, kuria užbaigiamas projekto planavimo etapas.

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ėsena, aplinka) 11. Komunikacijos 12. Vykdymo planas 13. Priežiūros planas 14. Mokymų planas Šablonai ir kontroliniai sąrašai Šaltinių nuorodos Priedai

XII. Projekto vykdymas (1)
Projekto vykdymo sėkmė priklauso nuo: - sudarytos projekto grupės; - kaip laikomasi projekto plano; - kaip platinama projekto informacija; - kaip valdomi sandoriai su tiekėjais. 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. 1.1. Darnios projekto grupės sudarymas ir valdymas Grupės plėtros etapai: a) grupės sudarymas; b) kova dėl pareigų; c) santykių nusistovėjimas; d) našus darbas.

Darbas su projekto grupe: 1) pirmasis susirinkimas (project kickoff). Projektų vadovas turėtų prašyti grupės narių atsakyti į tokius klausimus: - kodėl aš esu projekto grupėje? - kas aš ir ko iš manęs tikimasi? - ką aš rengiuosi daryti? - kaip darysiu savo darbą? Geras pirmasis susirinkimas yra toks, kuriame atsakoma į šiuos klausimus ir sukuriama bendradarbiavimo atmosfera projekto grupės nariams, akcininkams. Keletas tokio susirinkimo 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.

2) Grupės darbo (performance) valdymas. Projekto vadovas turi teisę įpareigoti grupės narius daryti darbus ir reikalauti iš jų atsakomybės už rezultatus. Vadovas turi būti kompetentingas, gerbiamas, sąžiningas, atviras. Valdymui svarbus yra grupės narių grįžtamasis ryšys. Darbų grįžtamasis ryšys turi būti savalaikis. Iškilusiems konfliktams spręsti galimi įvairūs būdai: prisiderinimas, vengimas, gynimasis, kompromisas, bendradarbiavimas. Dvi konfliktinės situacijos, kurios reikalauja išskirtinio dėmesio: - grupės narių ginčai (jiems išspręsti turi įsikišti projekto vadovas); - irzlių grupės narių, nuodijančių kolektyvo atmosferą, valdymas. Darniai projekto grupei sukurti, jos darbo našumui didinti padeda mokymai.

1.2. Mokymai Kai kuriose organizacijose kaip šalutinis tikslas gali būti projekto grupės narių įgūdžių gerinimas arba informacijos apie naujus produktus ar procesus rinkimas. Jei kuriant produktą naudojama nauja ir besiplėtojanti technologija, 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.

1.3. Skatinimas ir pripažinimas 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, kt. Priklausomai nuo organizacijos taisyklių, skatinimas gali apsiriboti garbės raštais ar dovanomis. Kai žmogus skatinamas, turi būti aiškiai įvardinti darbai, už kuriuos jis nusipelnė pagarbos.

2. Santykiai su kitais akcininkais Santykiai su klientais. Klientai gali nežinoti sudėtingų programų sistemų kūrimo plonybių, o projekto vadovas gali ne viską žinoti apie kompiuterizuojamą veiklos sritį. Keletas gerų santykių su klientais palaikymo principų: - dažnas bendravimas; - projekto grupės darbų pristatymas; - sutarimo siekimas; - savalaikis nutarimų vykdymas; - lūkesčių valdymas; - faktų valdymas.

Santykiai su sponsoriumi iškilus abejonėms. 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 sponsoriaus parama gali pasireikšti įvairiais būdais. 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. Jei sprendimo nepavyksta pasiekti, projekto vadovas turėtų nuspręsti, ar ieškoti naujo sponsoriaus, ar rekomenduoti nutraukti projektą.

Santykiai su funkcinių padalinių vadovais. 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ų. Jei atitrauktų išteklių pakeitimas kitais neturi įtakos galutiniams projekto rezultatams, tai reikėtų sutikti su tuo, pvz., naujo žmogaus priėmimu į grupę. Jei dėl naujo darbuotojo paieškos teks nukelti projekto įvykdymo terminą, apie susidariusią situaciją informuokite sponsorių ir laukite jo sprendimo. 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.

3. Darbų vykdymas pagal planą Geram darbų koordinavimui projekto vadovas turi rinkti duomenis apie atliktus darbus ir lyginti juos su projekto plane numatytų kontrolinių taškų duomenimis. 3.1. Duomenų apie projekto eigą rinkimas Priemonės informacijai rinkti 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 ir kaip dažnai jos turi būti teikiamos (paprastai – kas savaitę). Darbų ataskaitos šablono pavyzdys: Užduotis Dirbta valandų Liko dirbti valandų Atliktų darbų procentas Pastabos

Iškilusių problemų sąrašai. Spręstiniems klausimams 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škilusių problemų sąrašo šablono pavyzdys: 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. Problema Įtaka projektui Atsakingas asmuo Problemos stovis Atsiradimo laikas Išsprendimo laikas

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. Išvardinkime dalykus, kuriuos projekto vadovas turėtų stebėti: - darbų grafiko laikymasis; - biudžeto laikymasis; - projekto apimties laikymasis; - tvirtinami rezultatai. Specialus dėmesys skiriamas rezultatams kontroliniuose taškuose, kuriuos turi peržiūrėti sponsorius ar akcininkai ir kurie turi būti tvirtinami.

4. Informacijos apie projekto eigą platinimas 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. 4.1. Projekto grupės susirinkimai Susirinkimų vedimas. Produktyvus susirinkimas yra toks, kai projekto vadovas nubrėžia tolesnes darbų gaires ir išsprendžia ginčus dėl projekto darbų. 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. Susirinkimai yra gera proga stebėti grupės narių bendradarbiavimo lygį. Užrašų įvairiais klausimais (issues log) peržiūra turėtų būti kiekvieno projekto grupės susirinkimo dalis. Už kiekvieno užrašuose pasižymėto klausimo (problemos) išsprendimą iki nurodyto laiko būna nurodytas atsakingas asmuo (žiūr. Iškilusių problemų sąrašo šablono pavyzdį). Atsakingam asmeniui tereikia informuoti apie esamą padėtį. Problemų sprendimas. 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.

4.2. Ataskaitos apie projekto eigą Sponsoriui, akcininkams, klientams nereikia visų detalių apie projektą, kurios reikalingos projekto grupės nariams. Jiems reguliariai teikiamos ataskaitos apie projekto eigą. 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.

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. Apžvalgos daromos kas mėnesį ar kas metų ketvirtį. Jų rengimas gali trukti net keletą dienų, dalyvaujant visiems su projekto vykdymu susijusiems vadovams. Apžvelgtini klausimai: - pagrindiniai pasiekimai einamosios apžiūros periode; - biudžeto suvestinė; - pagrindiniai klausimai; - rizikos mažinimo ir reakcijos į jos veiksnius planai; - planuojami pasiekimai kitos apžvalgos laikotarpiui.

5. Sandorių su tiekėjais priežiūra Daugelyje projektų reikalinga išorinių tiekėjų pagalba. Jei yra sudaryti sandoriai, tenka administruoti juos. Tai stebėjimas ir tikrinimas, ar tiekėjai laiku atlieka sutartus darbus. 5.1. Tiekėjų atliekamų darbų ataskaitos 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ę. Projekto vadovas turi įsitikinti, ar tiekėjas pateikia reikiamus duomenis ir reikiamo pavidalo. Kai kurie projektų vadovai organizuoja mėnesinius ar kitokio dažnumo susitikimus su tiekėjais darbų eigai apžvelgti ir problemoms apsvarstyti.

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ų, dėl platformos, kt. Visi tokie nesutarimai turi būti svarstomi geranoriškai ir siekiama abiem šalims priimtinų sprendimų. Nepavykus susitarti elgiamasi pagal sandoryje išdėstytas nuostatas. 5.3. Tiekimų vėlavimai Tiekimų vėlavimo atvejais projekto vadovas turėtų imtis tokių veiksmų: - susitikti su tiekėju ir gauti daugiau informacijos apie tiekimo vėlavimą; - informuoti savo organizacijos pirkimų ir teisės departamentus; - peržiūrėti vėlavimo įtaką visam projekto planui; - informuoti sponsorių ir akcininkus.

5.4. Atsiskaitymai su tiekėjais Sandoriuose su tiekėjais nurodoma, kaip su jais bus atsiskaitoma. Jei tiekėjui turi būti mokama remiantis darbų grafike numatytais rezultatais, projekto vadovas turi patvirtinti tų rezultatų gavimą ir priėmimą. Turi būti peržiūrėta ir patikrinta tiekėjo pristatytos produkcijos kokybė ir tik tada tvirtinamas mokėjimas. 5.5. Reikalų su tiekėjais tvarkymas Dalykiški santykiai. Sandoryje numatyti, bet darbų užduotyje (SOW) gerai neapibrėžti darbai turi būti svarstomi ir aiškiai nurodomi trūkumai, įvardinamos problemiškos sritys, dėl ko tiekėjas nenori toliau tęsti darbų. Į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.

XIII. Projekto kontrolė (1)
1. Integruotoji keitimų kontrolė Nukrypimai nuo projekto plano gali būti perspėjimas, kad reikia daryti pradinio (originalaus) plano korekcijas. 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ą. 1.1. Projekto apimties keitimo kontrolė Projekto apimties plano viena iš dalių yra apimties valdymo planas. Apimties keitimo kontrolė yra bet kokių projekto apimties keitimų valdymas ir dokumentavimas laikantis valdymo plano.

Keletas priežasčių, verčiančių keisti projekto apimtį: - projekto rezultatų peržiūros metu pastebėta, 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; - pasikeitė kuriamo produkto projektas (design). Projekto apimtis neturėtų būti keičiama be formalaus patvirtinimo (leidimo). Keletas projekto apimties keitimo žingsnių ir patarimų: - naudokime standartinės formos prašymą 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, 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. Ieškoma kelių, kaip sugražinti projektą į ankstesnes vėžes. Aiškinamasi, kodėl buvo nukrypta nuo planuotos projekto apimties ir ko reikėtų imtis, kad tai neatsitiktų ateityje. Kontrolinių taškų derinimas. Bet koks projekto apimties keitimas reikalauja pakoreguoti projekto planą. Priklausomai nuo keitimų dydžio, gali tekti keisti darbų grafiko ir biudžeto kontrolinius taškus. 1.2. Darbų grafiko kontrolė Darbų grafiko kontrolė yra bet kokio darbų grafiko keitimo ir tokių keitimų dokumentavimo procesas. Projekto grupės narių ir kitos ataskaitos visų pirma naudojamos kritinio kelio darbų eigai įvertinti. Darbų grafiko kontrolės rezultatai – tai grafiko naujinimai, kitų projekto elementų korekcijos, įgyta patirtis.

1.3. Išlaidų kontrolė Tai procesas, kurio metu tikrinamos padarytos išlaidos, nustatomi nukrypimai nuo biudžeto kontrolinių taškų, imamasi reikiamų korekcijų. Išlaidų kontrolės rezultatas – peržiūrėti kainų įverčiai, kitų projekto elementų korekcijos, įgyta patirtis. 1.4. Kitų projekto plano elementų keitimo kontrolė Projekto apimtis, darbų grafikas, biudžetas yra pagrindiniai kontrolės taikiniai. Be jų taip pat gali keistis kitų projekto plano elementų duomenys: išteklių, reikalavimų, infrastruktūros ir konfigūracijos. Išteklių keitimas. Keičiantis darbuotojams, būtina užfiksuoti naujo žmogaus pavardę, pasikeitimo poveikį projektui. Reikalavimų keitimas. Jei reikalavimai yra papildomi naujais arba keičiami gerinant jų aiškumą, būtina įsitikinti, ar tai 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., UNIX keičiant į 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. Konfigūracijos keitimas. Įrangos konfigūracija keičiama tada, kai pastebima, jog sukurtas produktas geriau dirbtų kitaip sukonfigūruotoje aplinkoje. Konfigūracijos keitimas nėra didelė kliūtis projektams. Tik kai kurie konfigūracijos keitimai reikalauja iš naujo pakrauti (reboot) sistemą ir todėl rezultatai tampa prieinami tik po kažkurio laiko.

2. Kokybės kontrolė Kokybės kontrolės metu stebima, ar projekto rezultatai atitinka nustatytų standartų reikalavimus, ar nereikia daryti keitimų, kad būtų pašalintos neigiamą poveikį kokybei darančios priežastys. Kokybės valdymo planas yra specifinių kontrolės veiklų pagrindas. Kokybės tikrinimo veiklos yra svarbios projekto etapų užbaigimui patvirtinti. Patikrinus kokybę, galimi tokie tolesni žingsniai: užduoties atlikimas iš naujo, keitimų darymas, rezultatų priėmimas, nežiūrint, kad yra kai kurių defektų. Yra įvairios kokybės tikrinimo priemonės ir būdai. 2.1. Tikrinimas (testavimas) Tikrinimas yra plati sąvoka, apimanti apžiūrą, matavimą, testavimą. IT projektuose tikrinimas dažniausiai vadinamas testavimu.

IT projektams bendros yra šios testavimų rūšys: - modulių testavimas; - modulių rinkinio (unit) testavimas; - sistemos testavimas; - tinkamumo naudotojams testavimas (UAT – User Acceptance Testing) Nedidelis naudotojų ratas kažkurį laiką tikrina, ar sistema yra tokia, kokios tikėtasi; - tinkamumo įmonei testavimas (FAT – Factory Acceptance Testing). Dideles sistemas testuoti yra geriausia tose vietose, kur jos buvo sukurtos. Išbandoma pas kūrėją ir tik po to perkeliama į užsakovo nurodytą vietą; - tinkamumo konkrečiai vietai testavimas (Site Acceptance Testing). Sistema testuojama įdiegus ją užsakovo nurodytoje vietoje. Nors ji buvo išbandyta kūrėjo aplinkoje, tačiau dar patikrinama, kaip sistema veikia užsakovo aplinkoje.

Kai kuriais atvejais reikia sudėtingesnių testavimų: - modulius kuria geografiškai išbarstyta projekto grupė. Betarpiškų asmeninių kontaktų nebuvimas gali būti skirtingo supratimo, modulių nesuderinamumo priežastimi. Tokiais atvejais reikėtų detalesnio kiekvieno modulio testavimo; - produktus pristato tiekėjai. 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. 2.2. Kiti kokybės kontrolės būdai ir priemonės Pareto diagrama. Ji naudojama projekte kylanč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% gyventojų. Šis principas buvo perkeltas į daugelį disciplinų. Kokybės kontrolėje laikoma, kad 80% defektų priežastis yra 20% kylančių problemų. Taip pat manoma, kad 80% projekto darbų padaro 20% projekto grupės narių.

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. Pareto diagramos pavyzdys: Dažniausiai iškylančios problemos yra A ir B (pvz., A problema – prasti programavimo įgūdžiai). Išsprendus vien tik jas, būtų atsikratyta apie 60% visų defektų. Defektų dažnumas 1000 750 500 250 A B C D E Problema Suvestinis defektų procentas 100% 75% 50% 25%

Kontrolinės diagramos. Jos yra naudojamos kontroliuojamo parametro svyravimams laike pavaizduoti. Dažniausiai sutinkamos apdirbamojoje pramonėje. Tokiose diagramose svarbios yra vidutinė, viršutinė ir apatinė leistinos parametro reikšmės (pvz., tekinamos detalės diametras). Kontrolinės diagramos pavyzdys: 5,06 5,00 4,94 Viršutinė riba Vidutinė reikšmė Apatinė riba (taškas – matavimo reikšmė)

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ę. Projekto struktūrinė (blokinė) schema ir proceso diagrama. Taip 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.

2.3. Veiksmai kokybės neatitikimo atvejais Perdarymas. Tam reikia laiko ir lėšų, todėl gali tekti daryti projekto darbų grafiko ir biudžeto pakeitimus. Projekto 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. 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).

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. Dokumentai naudotojams. On-line būdu teikiamos ar spausdintinės instrukcijos sistemos naudotojams turi būti parengtos kruopščiai. Naudotojų mokymo medžiaga. Sukurtos sistemos naudotojams mokomoji medžiaga, įskaitant demonstracines priemones, turi būti apgalvota, suprantama ir tinkamai parengta. Pagalbos teikimo (help-desk) medžiaga. Neaiškumų naudotojams atvejais pagalbos teikimo tarnybų naudojama medžiaga turi būti kokybiška. Dokumentai priežiūros grupėms. 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.

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ę. 3.1. Standartai Standartų besilaikančios IT įmonės pasiekia geresnių rezultatų. Pvz., kuriant programinę įrangą paprastai laikomasi tokių standartų: - naujos programos rašomos taip, kad joms leisti pakaktų XML naršyklės; - naujose programose naudojamos Web funkcijos, o ne savos funkcijos; - naujose programose perduodant duomenis klientui naudojamas SOAP (Simple Object Access Protocol) protokolas ( OSI modelio transporto lygmens standartų rinkinys). Taip įgyjamos geresnės galimybės kontroliuoti naują programinę įrangą 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: - 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 protokolus. 3.2. Standartų organizacijos ISO (International Standards Organization) – tarptautinė standartizacijos organizacija. Kokybės kontrolei įmonės naudoja ISO 9000 standartą. DMTF (Distributed Management Task Force) standartų organizacija rengia sistemų valdymo standartus. IEEE (Institute of Electronic and Electric Engineers) yra parengusi plačiai žinomus tinklų protokolus. ANSI (American National Standards Institute). Ji mums įdomi tuo, kad parengė projektų valdymo žinyną [PMBOK]. LST – Lietuvos standartizacijos departamentas. Perima kitų standartus.

3.3. Projektų valdymo kokybės gerinimas Yra daug būdų projektų kokybei gerinti. Visada reikėtų įvertinti savo organizacijos galimybes vykdyti projektus aukštu lygiu. Tam galėtų pasitarnauti CMM (Capability Maturity Model) modelis. 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). Projektai dažnai vykdomi neorganizuotai, neturint formalių planų ar taisyklių. Veiklos neapibrėžtos, nekontroliuojamos. 2 lygis – kartojamasis (repeatable). Organizacijoje yra numatyta tam tikra projektų vykdymo tvarka, padedanti vertinti kainą, rengti darbų grafiką, vertinti rezultatus. Ši tvarka kartojama kiekvieno projekto metu, tačiau ji tobulintina.

3 lygis – apibrėžtasis (defined). Projektų vykdymo procesas yra apibrėžtas ir standartizuotas. 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šį. Projektų vykdymui aukštu kokybės lygiu būtina suprasti savo organizacijos galimybes valdyti projektus, diegti plačiai žinomus standartus.

4. Rizikos valdymo kontrolė Rizikos valdymas – tai procesas, kurio metu atliekami reakcijos į rizikos veiksnius veiksmai. Šis procesas nėra vien projekto plane įvardintų rizikos veiksnių stebėsena. Jo metu taip pat vertinamas reakcijos veiksmų efektyvumas, įvardijami naujai atsirandantys rizikos veiksniai. Rizikos valdymas turi glaudų ryšį su projekte iškylančių problemų valdymu. Problemos turi būti sprendžiamos, vertinama jų sprendimo eiga, keliamos naujos. 4.1. Reakcijos į rizikos veiksnius rezultatų valdymas Prevencinės (profilaktinės) priemonės. Rizikos veiksniams išvengti ar sušvelninti yra įvairūs būdai, pvz., naujų užduočių įtraukimas į darbų grafiką. Atsitikus rizikos veiksniui atliekami projekto plane numatyti veiksmai ir vertinama, kaip tie veiksmai padeda pašalinti arba sumažinti rizikos veiksnio įtaką projektui. Jei jie nesumažina rizikos, peržiūrimas reakcijos į rizikos veiksnį būdas ir rizika prisiimama arba imamasi naujo reakcijos būdo.

Veiksmai nenumatytais atvejais. Rizikos planas nenumatytais atvejais 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. 4.2. Naujų rizikos veiksnių įvardijimas Kai kurie projekto planavimo etape į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į. 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ą veiksmų keitimas gali iššaukti projekto apimties, darbų grafiko ir biudžeto keitimą. Todėl reakcijos į riziką veiksmų keitimo procedūra turi būti panaši, kaip ir darant kitokius projekto pakeitimus.

4.3. Problemų sprendimo valdymas Problemų valdymas yra labai panašus į rizikos valdymą, nes taip pat turi būti imamasi atitinkamų veiksmų. Problema tai ne rizika. Problema - tai uždavinys, reikalaujantis tyrimo, sprendimo. Rizika - tai tik nepageidaujamas dalykas, kuris gali atsitikti, bet gali ir neatsitikti. 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 net mėnesius. Todėl sąraše visada reikėtų registruoti problemas, jų sprendimo planą, atsakingą asmenį, numatomą išsprendimo datą. 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ą.

4.4. Projektas pavojuje Kartais reakcijos į riziką ar problemų sprendimo veiksmai gali neduoti norimų rezultatų arba pagimdyti naujus, sunkiai suvaldomus rizikos veiksnius. Tokiais atvejais reikia kreiptis į sponsorių ir tartis, ką gi reikėtų daryti. Laiku neinformavus apie projekto sunkią padėtį, sponsorius taip pat gali nebeturėti galimybių pagelbėti. Jeigu yra problemų su jūsų organizacijos kažkuriuo 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ų arba naujos strategijos jūsų organizacijoje projektas tapo neperspektyvus. Tokiais atvejais reikėtų rekomenduoti sponsoriui nutraukti projektą.

5. Projekto eigos kontrolė Projekto 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ų. 5.1. Darbų ataskaitos Ataskaitose turi būti problemų analizė ir jų įtakos projektui įvertinimas. 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 programinė įranga (pvz., Microsoft Project) 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.

Tendencijų analizė. Jau nuveikti darbai gali įnešti aiškumo, ko galima tikėtis atliekant būsimus. Tendencijų analizė yra pagrįsta matematiniais skaičiavimais ir naudojama prognozuoti, ar darbų atlikimas gerės ar blogės. Viso projekto kainos tikslinimas. Atlikus dalį projekto darbų, atsiranda galimybė tiksliau įvertinti viso projekto kainą, nei projekto pradžioje. Tokiam įverčiui suprasti reikia žinoti šias sąvokas: AC (actual cost) - tĩkrosios (faktinės) projekto išlaidos iki duoto laiko; ETC (estimate to complete) - nuo duoto laiko iki projekto pabaigos likusių darbų kainos įvertis; EAC (estimate at completion) - viso projekto patikslintos kainos įvertis duotu laiku. Jis gaunamas remiantis jau atliktų ir likusių darbų informacija: EAC = AC + ETC; BAC (budget at completion) - viso projekto kainos įvertis projekto pradžioje. VAC (variance at completion) - skirtumas tarp EAC ir BAC yra duotu laiku patikslintos projekto kainos nukrypimas nuo projekto pradžioje įvertintos projekto kainos.

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ą. Tiems skaičiavimams suprasti labiausiai reikalingos sąvokos yra: AC (actual cost) - tĩkrosios (faktinės) projekto išlaidos iki duoto laiko, ACWP; EV (earned value) - iki duoto laiko atliktų darbų vertė, BCWP; PV (planned value) - projekto biudžete duotam laikotarpiui skirta suma, BCWS. Nuokrypiai. Rodo skirtumą tarp suplanuoto projekto biudžeto ir tikrųjų išlaidų duotu laiku. CV (cost variance) - išlaidų nuokrypis. Jis apskaičiuojamas taip: CV = EV – AC. SV (schedule variance) - darbų nuokrypis. Jis apskaičiuojamas taip: 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. Jei santykio reikšmė yra didesnė už 1, tai projekto darbų vykdymas lenkia darbų grafiką arba projekto biudžetas neviršytas. Jei santykis yra mažesnis už 1, tai atsiliekama nuo darbų grafiko arba išlaidos viršija numatytąsias projekto biudžete. Santykiai gali būti išreiškiami procentais, nes tai gali būti patogiau. Pvz., indekso reikšmė 0,94 atitinka 94%. CPI (cost performance index) - išlaidų indeksas. Atspindi projekto biudžeto išlaidų panaudojimo efektyvumą. Jis apskaičiuojamas taip: CPI = EV / AC . Jei CPI<1, tai išlaidos panaudotos neefektyviai, jei CPI>1, tai išleista pinigų mažiau, nei tikėtasi.

SPI (schedule performance index) - darbų indeksas. Tai iki duotos datos atliktų darbų ir darbų grafike suplanuotų darbų kainų santykis: SPI = EV / PV . Jei SPI<1, tai atsiliekama nuo darbų grafiko, jei SPI>1, tai darbams sugaišta mažiau laiko, nei tikėtasi. TCPI (to-complete performance index) - darbų tęstinumo indeksas. Tai likusių darbų kainos ir likusių biudžeto lėšų santykis išreikštas procentais. TCPI = (likusių darbų kaina) / (likusios biudžeto lėšos), (likusių darbų kaina) = BAC – EV , (likusios biudžeto lėšos) = BAC – AC , BAC (budget at completion) - 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.

5.2. Akcininkų valdymas Projekto vadovas yra atsakingas už akcininkų informavimą apie projekto eigos nukrypimus, už nukrypimų poveikio projektui įvertinimą ir rekomendacijų, ką reikėtų daryti, parengimą. Tenka daryti kompromisus, norint rezultatyviai užbaigti projektą. Kartais nelieka prasmės tęsti projektą, ir dėl jo nutraukimo gali reikėti oficialaus akcininkų sutikimo. Pranešimai apie projekto nukrypimus. Pojekto eigoje būtina informuoti akcininkus apie bet kokius nukrypimus, kurie gali turėti įtakos projekto rezultatams. Projekto stoviui, analizės rezultatams pristatyti rengiamos diagramos ar lentelės. Kai kurios diagramos ir ataskaitos gali būti parengtos naudojant projektų valdymo programinę įrangą.

Kompromisų valdymas. 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 ir papildomos lėšos ir laikas tiems reikalavimams įgyvendinti. Daugiau darbų padaryti per tokį pat laiką ir už tokią pat kainą galima tik darbų kokybės sąskaita, trumpinant arba iš viso atsisakant rezultatų testavimo. Visada reikėtų išklausinėti akcininkus, kad išsiaiškintume, ko jie siekia prašydami keisti projekto apimtį.

Kompromisas dėl darbų grafiko. Darbų atlikimo vėlavimo priežastys gali būti įvairios nelaimės, įrangos gedimai, padarytos klaidos. 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 užtraukti baudas arba teisines sankcijas. Prieš rekomenduojant atidėti projekto pabaigos terminą, reikia būt pasvėrus, kas yra geriau. 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.

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. Jei 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. Išlaidas galima taupyti 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. Esant nepakankamam finansavimui ar trūkstant darbuotojų, geriau nutraukti projektą. Sunkios situacijos, kurioms išvengti nėra tinkamų sprendimų, gali susidaryti 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 projektas vis dar turi prasmę.

XIV. Projekto užbaigimas (1)
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: viso projekto administracinis užbaigimas ir sandorių užbaigimas. 1. Projektų nutraukimo priežastys Ne visi projektai būna sėkmingi. Jų užbaigimo (nutraukimo) priežastys gali būti įvairios: - rezultatų stoka. 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; - išteklių stoka. Tokia situacija gali susidaryti dėl netinkamų įverčių planavimo etape arba jūsų projektui skirti ištekliai perkeliami kitam.

2. Sandorių užbaigimas 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ė. Visų užbaigtų sandorių dokumentų kopijas reikėtų dėti į archyvą ir saugoti ateičiai. 3. Administraciniai projekto baigiamieji darbai Užbaigus projektą reikia atlikti dar keletą svarbių darbų: - perduoti projekto duomenis į archyvą; - sutvarkyti formalius projekto rezultatų priėmimo dokumentus; - visapusiškai peržiūrėti projektą (ką išmokome, kokią patirtį įgijome); - perduoti projekto rezultatus naudotojams; - atleisti projekto grupės narius.

3.1. Projektų archyvo tvarkymas Projekto eigoje 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ą. Prieš atiduodant savo projekto dokumentus į biblioteką ar archyvą, reikia pasidomėti, kaip dokumentai turėtų būti sutvarkyti. 3.2. Formalus projekto rezultatų priėmimas Galutinių projekto rezultatų peržiūros tikslas yra gauti akcininkų pritarimą ir parašus bei oficialiai paskelbti projekto pabaigą. Projekto vadovas turi išsiaiškinti, kieno parašų reikės. 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.

3.3. Visapusiška projekto peržiūra (gautos pamokos) Užbaigto projekto vertinimas turėtų padėti atskleisti dalykus, kurių išmokome, kokias pamokas gavome. Galbūt tai padės geriau valdyti kitus projektus. 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).

3.4. Projekto rezultatų perdavimas naudotojams Sukurtą sistemą dažniausiai eksploatuoja ir prižiūri kiti žmonės. Todėl projekto grupė turi perduoti ją būsimiems naudotojams, perduoti sistemos priežiūros dokumentus ir įrankius. Jų atnaujinimas jau bus priežiūros grupės atsakomybė. 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. Kadangi būtina laikytis darbo sutarties terminų ir žmoniškųjų išteklių taisyklių, projekto grupės nariai turėtų būti informuoti apie galimą atleidimo datą.

XV. Lankstieji metodai (1)
Programų sistemų kūrimo lankstieji metodai (agile metodai) naudotini tais atvejais, kai programų sistemų kūrimo projektai yra sunkiai valdomi, dažnai keičiasi reikalavimai. Lanksčiuoju metodu sudėtingi (ilgalaikiai) projektai skaidomi į paprastesnius (trumpos trukmės) 2-3 žmonių atliekamus projektus. Taip sumažinama sudėtingo projekto įvykdymo rizika. 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 greitai prisitaikyti prie kintančių reikalavimų, geriau valdyti rizikos veiksnius. Pagrindinis lanksčiojo metodo skirtumas nuo tradicinių (krioklio, spiralės modeliai) modelių yra orientacija į principus, o ne į procesą. Visa tai yra išdėstyta vadinamajame Agile manifeste. Susipažinkime su jais.

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 į prašymus daryti keitimus yra svarbiau nei laikytis plano.

Lanksčiojo metodo principai (1): 1) klientų poreikių tenkinimas tiekiant naudingą įrangą kiek galima greičiau; 2) teigiamas požiūris netgi į projekto pabaigoje prašomus daryti 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;

Lanksčiojo metodo principai (2): 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 – gebėjimas nedaryti bereikalingų darbų – yra labai svarbu; 11) geriausius reikalavimus, projektus (design) ir sistemas sukuria darnios (self-organizing) grupės; 12) nuolatinės projekto grupės pastangos didinti savo efektyvumą ir derintis prie aplinkybių.

1. Grumtynės (Scrum) Grumtynės (scrum) yra vienas iš lanksčiųjų metodų programų sistemoms kurti. Šiam 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 (sprint); - laikotarpio pabaigoje rengiamas susirinkimas 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.

2. Aukštasis programavimas (XP) Aukštasis arba ekstremalusis programavimas (eXtreme Programming - XP) – plačiai paplitusi lanksčiojo metodo atmaina. Jo pagrindiniai principai: - bendravimas tarp užsakovo ir projekto vykdytojo. Į grupę įtraukiamas užsakovas, padedantis detalizuoti darbus ir sudėlioti juos prioritetų tvarka, galintis iškart atsakyti į iškilusius klausimus; - mokymasis. Sutrumpina programavimo darbus. Testuojama programavimo metu; - programos paprastumas. Kuo programa paprastesnė, tuo didesnė tikimybė, kad ji gerai veiks. Sudėtingos konstrukcijos skaidomos į paprastesnes; - programų peržiūra. Aukštojo programavimo atstovai dirba poromis. Todėl visas programos kodas peržiūrimas rašymo metu; - programos testavimas. Testai rengiami prieš pradedant rašyti programą. Užduotis laikoma įvykdyta tik tada, kai visi testai baigiami sėkmingai.

Programų sistemų projektų ir kokybės valdymas
P a b a i g a

projektų ir kokybės valdymas

Παρόμοιες παρουσιάσεις

Παρουσίαση με θέμα: "projektų ir kokybės valdymas"— Μεταγράφημα παρουσίασης:

Παρόμοιες παρουσιάσεις

Σχετικά με το έργο

Σχόλια

Είσοδος

Σύνδεση μέσω των κοινωνικών δικτύων:

projektų ir kokybės valdymas

Παρόμοιες παρουσιάσεις

Παρουσίαση με θέμα: "projektų ir kokybės valdymas"— Μεταγράφημα παρουσίασης:

Παρόμοιες παρουσιάσεις

Σχετικά με το έργο

Σχόλια