Projekto planas. Projekto planavimas. Pagrindinės sąvokos. Išteklių planavimo ypatybės

Projektų valdymas – tai technologijų ir meno simbiozė laiku išspręsti unikalią užduotį per tam skirtą biudžetą. Kad projektas būtų sėkmingai užbaigtas, būtina pasiekti įmonės vadovybės ir RM supratimą, kaip jis bus įgyvendintas, kas, kada ir kokius darbus turi atlikti. Projekto planas vertinamas ne kaip vienas dokumentas, o kaip visuma dokumentais pagrįstų sprendimų, atsakančių į aukščiau pateiktus klausimus. Jūsų dėmesiui pristatau apžvalginį straipsnį, kuriame nagrinėjami projektų planavimo technologijos pagrindai.

Projekto planavimo esmė

Projekto planavimas apima daugybę tarpusavyje susijusių iteracijų, kurių rezultatas yra vienas bendrasis planas. Projekto planu mes geriau suprasime planuojamų veiklų sistemą, dokumentuotą rengimo metu. Šią sistemą sudaro ypatingu būdu sujungti parametrai, užtikrinantys, kad būtų išspręsta atskira kūrimo problema. Šie parametrai formuojami remiantis daugybe funkcinių projekto veiklos sričių:

• turinys;
• terminai;
• savikaina;
• personalas;
• reikmenys;
• komunikacijos;
• rizika ir kt.

Planas yra pagrindinis projekto valdymo sistemos elementas. Jei premjerui pavyko parengti detalų planavimo dokumentų rinkinį, jis turi teisę tikėtis garantuoto reikiamų rezultatų gavimo baigus darbus. Tam reikia gerai suplanuoti laiką, išteklius ir kitus aspektus. Kol neparengtas planas, neįmanoma žinoti, kiek pinigų ir laiko prireiks unikaliai užduočiai atlikti. Neturint plano, iš vadovo praktiškai netenkama gairių dėl darbų atitikties projekto tikslams.

Turite suprasti, kad planavimas ne visada duoda teigiamų rezultatų, tačiau neigiamos išvados gali atnešti ne mažiau, o kartais ir daugiau naudos. Bet kokiu atveju lėšų investavimo efektyvumas didėja, o uždirbto pelno „išsiskirstymas“ neįvyksta. Projekto planavimas padeda pagrindą produktyviam darbui ir išsprendžia šias taikomas problemas.

1. Išsiaiškinkite ir detalizuokite renginio tikslus ir rezultatus.
2. Nustatykite darbo sudėtį ir apimtį.
3. Apskaičiuokite terminus ir biudžeto išlaidas.
4. Sudarykite pagrindinių etapų arba viso projekto grafiką ir biudžetą.
5. Išsamiai įvertinkite kiekvieno etapo arba visos užduoties išteklių poreikį.
6. Sudarykite išteklių planą.
7. Atlikite rizikos vertinimą ir sukurkite atsako į riziką planą.
8. Paaiškinkite klientui išsamią įvykio informaciją.
9. Sutikite planą su pagrindiniais dalyviais.
10. Paskirstykite atsakomybę už darbą ir užduotis dalyviams.
11. Patvirtinti bendrąjį planą.
12. Išsiaiškinkite sąveikos planus ir planavimo valdymo procedūras.

Projekto valdymo plano vieta jo gyvavimo ciklo etape. Šaltinis: PMBOK 5 vadovas

Planavimo procesų vieta tarp kitų projekto įgyvendinimo procesų. Šaltinis: PMBOK 5 vadovas

Projekto planavimo negalima palikti ore. Prieš tai inicijuojama, o šių procesų rezultatas yra tikrasis projekto vykdymas. Ir mes pripažįstame keletą svarbių planavimo punktų:

• susietas su konkrečiu laiko momentu unikalios užduoties gyvavimo cikle ir reikšmingu jos laikotarpiu (žr. aukščiau pateiktas diagramas);
• pasikartojantis – nesibaigia parašius planus, reikalauja reguliaraus atnaujinimo iki aktyvaus uždarymo fazės;
• išsamus – neapsiriboja vienu įrankiu ir apima daugybę įrankių bei atitinkamų išvesties dokumentų.

Išplėsta planavimo procesų sudėtis

Projekto planas skiriasi nuo projekto valdymo plano ir susijusių planavimo procesų. Kaip jau apibrėžėme, plačiąja prasme planu turime galvoje iš anksto suplanuotą veiklų sistemą, kurios vykdymo tvarka, seka ir darbų laikas nustatomas. Siaurąja prasme planas yra dokumentas, atspindintis planuojamų veiksmų eiliškumą ir įgyvendinimo terminus. Projekto valdymo planas yra reglamentuotų planavimo procedūrų (procesų), kurių valdymo elementą perima reguliarios, reglamentuotos planų kaip dokumentų kūrimo procedūros, rezultatas.

Pagrindinių planavimo sąvokų apibrėžimai iš PMI. Šaltinis: PMBOK 5 vadovas

Renginių planavimas apima dvi procesų grupes: tiesioginio planų rengimo procesus ir pagalbines procedūras. Kūrimo bloko išvestis yra dokumentas, vadinamas pagrindiniu projekto planu. Jame yra kalendorinis planas, renginio biudžetas ir daugybė kitų dokumentų. Darbo sudėtis ir turinys, jiems įgyvendinti reikalingi ištekliai lemia jų gamybos eiliškumą, trukmę ir išlaidų dydį.

Galimos rizikos planavimas (identifikavimas, nustatymas ir įvertinimas) bei rizikos valdymas įtakoja ne tik grafiko sudarymą, bet ir biudžeto poreikius. Tikslų išsiaiškinimas, unikalios užduoties ribų apibrėžimas ir komandos bei atsakomybės struktūrizavimas padeda prasmingoms projekto planavimo pastangoms. Toliau pateikiame jūsų dėmesiui sąsajų tarp pagrindinių nagrinėjamų procesų procedūrų modelį.

Planavimo procesų modelis projektų valdyme

Yra žinoma, kad pagal PMI standartą beveik kiekviena PMBOK vadovo dalis planavimui skiria visą bloką. Remiantis aukščiau pateikta diagrama, tai yra gana natūralu. PMBOK skyriuje „Projektų integracijos valdymas“ pavaizduotas holistiškiausias planavimo valdymo ir bendrojo plano kūrimo vaizdas. Žemiau pateikiamas vietinis renginių valdymo plano rengimo duomenų srauto diagramos blokas.

Vietos projekto valdymo plano rengimo duomenų srautų diagramos blokas

Aukščiau pateiktas vaizdinis blokas pastebimas dėl daugelio priežasčių. Projektų valdymo žinių bazė, visa šioje srityje įgyta patirtis ir reglamentai yra būtini planavimo sėkmei. Tai taip pat taikoma standartams, programinei įrangai, organizacinei struktūrai ir kultūrai, valdymo metodams, infrastruktūrai ir kt. Chartija yra pagrindinis planavimo vadovas. Šie procesai yra integravimo į pagrindinį planą pagrindas ir pateikiami toliau nurodyti duomenys kuriant galutinę jo versiją:

• projekto parametrų valdymo planai;
• pagrindiniai turinio, kainos ir tvarkaraščio planai;
• plano atnaujinimai.

Kalendoriaus plano rengimo etapai

Kaip prisimename, projektų valdymas yra pastatytas ant „trijų ramsčių“: darbo turinio, apribojimų ir rizikos. Jeigu vadovas moka gerai dirbti su šiais trimis parametrais, tai jam nėra neišsprendžiamų užduočių. Panagrinėkime kalendorinio plano kūrimą iš šių trijų pozicijų perspektyvos ir suskirstykime šį procesą į etapus. Pirmąjį ir antrąjį etapus vadinsime darbo turiniu.

1. Darbų sąrašo nustatymo ir rašymo etapas. Gana dažnai daromos klaidos dėl to, kad nėra galimybės pristatyti visų darbų iš karto. Norint kokybiškai nustatyti operacijų sudėtį, naudinga pasinaudoti nuoseklaus darbo skaidymo metodo pagrindais.
2. Projekto vykdymo nustatymo etapas pagal darbų seką ir trukmę, kurios priklauso nuo jų įgyvendinimo technologijos. Kokybiškam šio etapo rezultatui sukurti puikiai tinka jau minėtas nuoseklaus užduočių išskaidymo ir ekspertinio darbo trukmės vertinimo metodas, naudojant tokius metodus kaip, pavyzdžiui, smegenų šturmas.
3. Išteklių prieinamumo nustatymas. Renginyje naudojami įvairūs ištekliai: finansiniai, materialiniai, darbo, informaciniai ir kt. Finansinių išteklių požiūriu būtina darbo grafiką susieti su finansavimo grafiku. Supažindinama su ribotų išteklių samprata: unikalūs specialistai ir pajėgumai. Tai palieka pėdsaką darbo eilėje ir trukme.
4. Išorinių apribojimų apibrėžimas. Šie apribojimai apima sezoniškumą, įrangos tiekimo technologinius procesus ir įvairius išorinius įvykius. Jei atsižvelgsime į specialių užsakovo pageidavimų (konkretiems partneriams) ar išorinių įvykių pavyzdį (pavyzdžiui, kad etapo užbaigimo laikas sutampa su valstybine švente), tai tokie įvykiai įtraukiami į renginį etapų forma.
5. Reagavimo į riziką plano sudarymo etapas. Analizuojame projekto rizikas ir parengiame atsako planą pagrindinėms grėsmėms. Atsižvelgdami į šį planą, baigiame tvarkaraštį.

Trečiasis ir ketvirtasis etapai yra susiję su apribojimų pozicijomis, penktasis – su rizika. Du atsakymo pagrindai (aktyvus ir pasyvus) lemia sprendimo priėmimo momentą ir jo įtraukimą į projekto planą. Aktyvus atsakas reiškia, kad į grafiką įtraukiame papildomų darbų, kuriais siekiama sumažinti riziką. Tai gali turėti įtakos kitų darbų laikui.

Kaip pavyzdį galime apsvarstyti naujos paslaugos pristatymo rinkai projektą. Tarkime, buvo nustatyta jo paklausos stokos rinkoje rizika. Tada, norint sumažinti šią riziką, būtina atlikti papildomus tyrimus, o šie darbai turi būti įtraukti į grafiką. Pasyvus atsakas reiškia papildomų finansinių rezervų formavimą nustatytai rizikai. Tvarkaraščio rengimo etapus taip pat galima pateikti žemiau pateikta logine seka.

Loginė tvarkaraščio sudarymo seka

Pagrindinės projektų planavimo veiklos

Norėdami sukurti pagrindinį planą, projekto vadovas įgyvendina planavimo iteracijų seriją. Vykdant planavimo procesus, generuojami svarbūs instrumentiniai ir galutiniai dokumentai, kurie kartu sudaro bendrąjį planą. Tarp jų:

• hierarchinė darbo struktūra (WBS);
• tinklo schema;
• kokybės valdymo planas;
• projekto tvarkaraštis;
• biudžetas;
• organizacinė diagrama;
• rizikos registras;
• komunikacijos planas;
• pagrindinio projekto planas.

Vizualus projekto planavimo procesų modelis

Aukščiau pateiktas projekto užduoties planavimo procesų modelis. Visą procesų sudėtį galite pamatyti diagramoje. Baseino juostų planavimo procesai yra susiję su beveik visomis projektų valdymo sritimis. Daugelis modelyje nurodytų procesų turės galimybę būti pristatyti atskiruose straipsniuose mūsų svetainėje. Šioje medžiagoje trumpai sutelkiame dėmesį į pagrindines planavimo procedūras.

1. Apimties apibrėžimo procesas atliekamas siekiant išsiaiškinti projekto apimtį, ribas su jo produkto aprašymu. Procesas prasideda išsiaiškinant renginio tikslus, jo ryšį su įmonės strategija ir kintamų įgyvendinimo požiūrių svarstymu. PM turi būti aiškus, kokie darbai nepatenka į projekto sritį ir kokie gaminio reikalavimai.
2. Darbo apimties nustatymo procesas. Ankstesniame procese padėti pagrindai yra išplėtoti į visas būtinas operacijas, kad būtų pasiekta sėkmė. Jų struktūra ir sudėtis yra susiję su pagrindiniu projekto tikslu. WBS yra pagrindinė PM naudojama priemonė dabartinio proceso problemai išspręsti.
3. Darbo santykių nustatymas. Loginė darbų seka yra šio proceso dalykas ir tikslas. Geriausias proceso įgyvendinimo įrankis ir rezultatas yra tinklo modelis (diagrama, grafikas), sukurtas ir optimizuotas naudojant PERT ir CPM metodus.
4. Darbo trukmės įvertinimo procesas. Kiekvienos veiklos, įtrauktos į WBS ir tinklo modelį, trukmės prognozavimas atliekamas remiantis įvairiais metodais. Pagrindiniai metodai yra vertinimo metodai, pagrįsti analogais, „iš apačios į viršų“, iš atlikėjų, ekspertinis ir parametrinis vertinimas.
5. Išteklių poreikių įvertinimo procesas. Proceso tikslas – nustatyti reikiamą žmogiškųjų išteklių, mašinų išteklių ir mechanizmų kiekį. Ištekliai skirstomi į grupes: atsinaujinančius, vartojamuosius ir finansinius.
6. Kalendoriaus plano rengimo tvarka. Procesas atliekamas siekiant nustatyti numatomą atskirų darbų ir viso projekto laiką. Svarbus plano detalizavimo klausimas. Jo išdirbimo gylis turėtų būti pakankamas, kad projekto vadovas galėtų kontroliuoti darbų eigą ir pavestų užduočių atlikimą.
7. Bendrojo projekto plano rengimas. Jis apjungia visus renginio planavimo darbo rezultatus į vieną projekto integravimo dokumentą.

Šiame straipsnyje susipažinome su „maksimaliu“ procedūrų ir dokumentų, kurie sukuria projekto planą, rinkiniu. Praktikoje, ypač kai projektas yra vidutinio ar mažo masto ir yra reguliaraus pobūdžio, dažnai nereikia dėti pernelyg didelių planavimo pastangų. Tokiais atvejais galite apsiriboti standartiniais planavimo sprendimais ir nepilnu dokumentų rinkiniu. Tuo pačiu metu vargu ar galima apsieiti be pagrindinio dokumentinio filmo, išdėstyto konsoliduotame plane, o įdėtos pastangos kuriant jį atsiperka su kaupu.

Projekto planavimo principai.

Darbo suskirstymo struktūra.

Projekto planavimas pagal laiko parametrus.

Projekto tinklo planavimo metodai.

Projekto planavimo darbų organizavimas.

Projektų valdymas: vadovėlis / A.G. Ivasenko, Ya.I. Nikonova, M.V. Karkavinas. – Rostovas n/a: Feniksas, 2009. – P.177-212.

Mazur I.I. Projektų valdymas: vadovėlis. vadovas studentams, studijuojantiems pagal specialybę „Organizacijų valdymas“/I.I. Mazuras [ir kiti]. ; redagavo I.I. Mazura ir V.D. Šapiro – 6 leid., ištrintas. - M.: Leidykla "Omega-L", 2010. -960 p.

Planavimo esmė – išsikelti tikslus ir būdus jiems pasiekti, remiantis darbų (įvykių, veiksmų), kuriuos būtina atlikti, suformavimu, metodų ir priemonių panaudojimu šiems darbams įgyvendinti, susiejant jiems įgyvendinti reikalingus išteklius. , ir projekte dalyvaujančių organizacijų veiksmų koordinavimas.

Plano rengimo veikla apima visus projekto kūrimo ir vykdymo etapus. Pradedama nuo projekto vadovo (projekto vadovo) dalyvavimo rengiant projekto koncepciją, tęsiasi strateginių sprendimų projektui atranka, taip pat jo detalių kūrimas, įskaitant sutarčių pasiūlymų rengimą, sutarčių sudarymą. , darbų vykdymas, ir baigiasi projekto užbaigimu.

Planavimo etape nustatomi visi būtini projekto įgyvendinimo parametrai:

kiekvieno kontroliuojamo projekto elemento trukmė,

darbo jėgos, materialinių, techninių ir finansinių išteklių poreikis,

žaliavų, medžiagų, komponentų ir technologinės įrangos pristatymo terminai,

projektavimo, statybos ir kitų organizacijų įsitraukimo laikas ir apimtys.

Projekto planavimo procesai ir procedūros turi užtikrinti projekto įgyvendinamumą per tam tikrą laikotarpį minimaliomis sąnaudomis, neviršijant standartinių išteklių sąnaudų ir tinkamos kokybės.

Gerai organizuotame projekte už kiekvieno tikslo įgyvendinimą turėtų būti atsakingas konkretus valdymo organas: projekto vadovas už visus tikslus (projekto misija), atsakingi vykdytojai už privačius tikslus ir tt Tai yra, projekto tikslų medis turi sutapti. su už projekto įgyvendinimą atsakingo organizacinio padalinio struktūra. Tam yra kuriama vadinamoji atsakomybės matrica, kuri apibrėžia projektų vykdytojų funkcines pareigas ir nurodo darbų, už kurių įgyvendinimą jie yra asmeniškai atsakingi, kompleksą.

Kuo aukštesnis valdymo organo lygis, tuo labiau apibendrintais, agreguotais rodikliais jis priima sprendimus dėl pavaldžių padalinių valdymo. Didėjant hierarchijos lygiui, ilgėja laiko intervalas tarp suplanuotų užduočių išdavimo, jų vykdymo stebėjimo ir pan. Be to, intervalais tarp intervencijos momentų (planuotų užduočių išdavimo, etalonų nustatymo ir pan.) žemesnio lygio padaliniai dirba savarankiškai. neatsižvelgiant į to paties ar gretimo lygio vienetus. Savarankišką skyrių funkcionavimą turi užtikrinti tam tikri išteklių rezervai, kuriuos taip pat reikia planuoti.

Pagrindinis planavimo tikslas – sukurti projekto įgyvendinimo modelį. Su jo pagalba būtina derinti projekto dalyvių veiklą, nustatoma darbų atlikimo tvarka ir kt.

Planavimas yra tarpusavyje susijusių procedūrų visuma. Pirmasis projekto planavimo etapas – pirminių planų rengimas, kuriais remiantis sudaromas projekto biudžetas, nustatomas išteklių poreikis, organizuojama projekto parama, sudaromos sutartys ir kt. Projekto planavimas yra prieš projekto kontrolę ir yra jo taikymo pagrindas. , nes lyginami planuojami ir faktiniai rodikliai.

Planavimas yra vienas iš svarbiausių projekto procesų, nes jo įgyvendinimo rezultatas dažniausiai yra unikalus objektas, produktas ar paslauga. Planavimo apimtį ir detalumą lemia informacijos, kurią galima gauti proceso metu, naudingumas ir priklauso nuo projekto turinio (ketinimo).

Pats planavimo procesas negali būti visiškai algoritmizuotas ir automatizuotas, nes jame yra daug neaiškių parametrų ir dažnai priklauso nuo atsitiktinių veiksnių. Todėl dėl planavimo siūlomi plano variantai gali skirtis, jei juos rengia skirtingos komandos, kurių specialistai skirtingai vertina išorinių veiksnių poveikį projektui.

KAM pagrindiniai procesai planavimas apima:

projekto apimties planavimas ir dokumentacija;

sąmatų sudarymas, resursų, reikalingų projektui užbaigti, sąnaudų įvertinimas;

darbų apibrėžimas, konkrečių darbų, užtikrinančių projekto tikslų pasiekimą, sąrašo formavimas;

darbų išdėstymas (seka), technologinių priklausomybių ir darbo apribojimų nustatymas ir dokumentavimas;

darbų trukmės, darbo sąnaudų ir kitų išteklių, reikalingų atskiriems darbams atlikti, įvertinimas;

grafiko skaičiavimas, darbų atlikimo technologinių priklausomybių, darbo trukmės ir išteklių poreikio analizė;

išteklių planavimas, nustatant, kokių išteklių (žmonių, įrangos, medžiagų) ir kokiais kiekiais reikės projekto darbams atlikti. Nustatyti, per kiek laiko darbas gali būti atliktas atsižvelgiant į ribotus išteklius;

biudžeto sudarymas, numatomų išlaidų susiejimas su konkrečiomis veiklos rūšimis;

projekto plano kūrimas (rengimas), kitų planavimo procesų rezultatų surinkimas ir jų sujungimas į bendrą dokumentą.

Pagalbiniai procesai atliekama pagal poreikį. Jie apima:

kokybės planavimas, tam tikram projektui tinkamų kokybės standartų apibrėžimas ir būdų jiems pasiekti;

organizacinis planavimas (projektavimas), projektų vaidmenų, atsakomybės ir atskaitomybės santykių apibrėžimas, apklausa, dokumentavimas ir paskirstymas;

personalo atranka, projekto komandos formavimas visuose projekto gyvavimo ciklo etapuose, būtinų žmogiškųjų išteklių, įtrauktų į projektą ir darbas jame, įdarbinimas;

komunikacijų planavimas, projekto dalyvių informacijos ir komunikacijos poreikių nustatymas: kam kokios informacijos reikia, kada ir kaip ji turi būti pateikta;

rizikos nustatymas ir įvertinimas, nustatymas, kuris neapibrėžtumo veiksnys ir kiek gali turėti įtakos projekto eigai, palankių ir nepalankių projekto įgyvendinimo scenarijų nustatymas, rizikų dokumentavimas;

tiekimo planavimas, nustatant, ką, kaip, kada ir su kuo pirkti ir pristatyti;

planuoti pasiūlymus, dokumentuoti produktų reikalavimus ir nustatyti galimus tiekėjus.

Planavimo lygių nustatymas taip pat yra planavimo dalykas ir atliekamas kiekvienam konkrečiam projektui, atsižvelgiant į jo specifiką, mastą, geografiją, laiką ir kt.

Šio proceso metu nustatomas projektui skirtus darbų paketus atitinkančių planavimo lygių tipas ir skaičius, jų esminiai ir laiko santykiai.

Planai (grafai, tinklai), kaip planavimo procesų rezultatų išraiška, turėtų sudaryti tam tikrą piramidinę struktūrą, kuri turi informacijos kaupimo savybių, diferencijuotą pagal sąmoningumo valdymo lygius, suskirstytą pagal vystymosi periodus (trumpalaikius, vidutinės trukmės ir ilgalaikius). -terminas). Planavimo lygiai ir planų sistema turėtų būti kuriami naudojant grįžtamojo ryšio principus, kurie užtikrina nuolatinį planuojamų duomenų palyginimą su faktiniais duomenimis ir turi didelį lankstumą, aktualumą ir efektyvumą.

Planavimas yra išteklių (medžiagų ir žmogiškųjų) paskirstymo ir paskirstymo procesas, atsižvelgiant į projekto užbaigimo išlaidas ir laiką. Planavimas yra vienas iš svarbiausių projekto procesų, nes jo įgyvendinimo rezultatas dažniausiai yra unikalus objektas, produktas ar paslauga.

Pagrindinis planavimo funkcijos pateikiami žemiau.

Poreikių pavertimas valdomomis užduotimis. Iš pradžių projektas pasirodo su užsakovu parengtų ir suderintų reikalavimų forma. Planavimo tikslas – pateikti šiuos reikalavimus kaip atskirų užduočių visumą, kurių įgyvendinimą galima kontroliuoti.

Reikalingų išteklių nustatymas. Detaliuose planuose bus nustatytas žmonių skaičius, reikalinga įranga ir veiklos sąlygos, kurių reikės projektui užbaigti.

Komandinio darbo projekte koordinavimas. Labai dažnai projektas suskaidomas į atskirus darbus, kuriuos galima atlikti lygiagrečiai. Planai leidžia koordinuoti šią veiklą, apibrėžiant, kas ką ir kada daro.

Galimos rizikos įvertinimas. Nors kai kurios rizikos gali būti nustatytos formuluojant reikalavimus, daug daugiau atrandama po detalaus planavimo. Žinodami apie šių pavojų egzistavimą, galėsite jas pastebėti anksčiau (jei jie pasireikš) ir pasiruošti jas spręsti.

Įspėti iškilus problemoms. Nukrypimas nuo plano yra signalas, kad iškilo problemų. Planai nėra dogma, kurios reikia besąlygiškai laikytis. Projekto vadovui jos greičiausiai bus prielaidos ir palyginimo pagrindas. Jei projektas neatitinka lūkesčių, planas turi būti atitinkamai koreguojamas.

Grupė planavimo procesai parodyta pav. 3.10. Šie procesai gali būti kartojami ir yra kartotinės procedūros dalis, kol pasiekiamas tam tikras rezultatas. Pavyzdžiui, jei pradinė projekto pabaigos data yra nepriimtina, tada reikalingi ištekliai, kaina ir kartais projekto turinys. ( Projektų valdymo procesų grupės

Planavimo proceso grupė

Projektas Žmogiškųjų išteklių valdymas

Planavimas

Žmogiškųjų išteklių valdymo plano rengimas techninių išteklių

Apibrėžimas

Projekto laiko valdymas

Apibrėžimas

operacijos

Kontrolė

vientisumas

Pirkimų planavimas

Projekto kaštų valdymas^

Išlaidų sąmata

Projekto kokybės valdymas

Projekto valdymo plano rengimas

Apibrėžimas

sekos

operacijos

operacijų išteklių

Planavimas

kokybės

trukmės

operacijos

Plėtra

tvarkaraščiai

Projekto rizikos valdymas

Apibrėžimas

Planavimas

valdymas

rizika

Kokybinės rizikos analizės atlikimas

Kiekybinės rizikos analizės atlikimas

Reagavimo į riziką planavimas

Ryžiai. VELNIAS. Planavimo procesai

projektas turi būti pakeistas. Rezultatas šiuo atveju bus sutartos sąlygos, apimtys, išteklių spektras, biudžetas ir projekto turinys, atitinkantis jo tikslus.

Planavimas yra būtina sąlyga norint atlikti bet kokią užduotį, net ir pačią paprasčiausią. Netinkamas planavimas gali sukelti projekto nesėkmę arba netinkamus rezultatus projekto aplinkoje.

Planavimas viena ar kita forma vykdomas per visą projekto laikotarpį. Projekto gyvavimo ciklo pradžioje paprastai parengiamas neformalus pradinis planas – apytikslis supratimas, ką reikės įgyvendinti, jei projektas bus įgyvendintas. Projekto atrankos sprendimas daugiausia grindžiamas šio pradinio plano vertinimais. Oficialus ir detalus projekto planavimas pradedamas priėmus sprendimą jį įgyvendinti.

Planavimas susideda iš toliau nurodytų dalykų planus:

• darbų atlikimas, įskaitant jo darbo intensyvumo ir terminų įvertinimą;
• darbo turinio ir apimties valdymas;
• organizacinė struktūra;
• konfigūracijos valdymas;
• kokybės valdymas;
• rizikos valdymas;
• Pirkimų valdymas;
• projektavimo rezultatų ir atlikėjų veiklos sertifikavimas.

Apibrėžimas planavimo lygiai taip pat yra planavimo objektas ir vykdomas kiekvienam konkrečiam projektui, atsižvelgiant į jo specifiką, mastą, geografiją, laiką ir kt. Šio proceso metu nustatomas projektui skirtus darbų paketus atitinkančių planavimo lygių tipas ir skaičius, jų esminiai ir laiko santykiai.

Planai (grafai, tinklai), kaip planavimo procesų rezultatų išraiška, visumoje turėtų sudaryti tam tikrą piramidinę struktūrą, kuri turėtų informacijos kaupimo savybių, diferencijuotų pagal sąmoningumo valdymo lygius, ir turėtų būti ešelonuota pagal vystymosi laikotarpius (trumpalaikius, vidutinius). - ilgalaikis ir ilgalaikis). Planavimo lygiai ir planų sistema turi būti kuriami naudojant grįžtamojo ryšio principus, užtikrinančius nuolatinį planuojamų duomenų palyginimą su faktiniais duomenimis, jie turi būti labai lankstūs, aktualūs ir efektyvūs.

Tinklo planai yra konsoliduojami dėl to, kad bendrąjį tinklo planą sudaro daug privačių tinklų planų. Kiekviename iš šių privačių planų yra nustatytas ilgiausias kelias. Tada šie keliai įdedami į atskiras tinklo dalis. Tokio laipsniško agregavimo pagalba gaunami kelių lygių tinklo planai (3.11 pav.). Paprastai yra koncepcinis planas, strateginis projekto įgyvendinimo planas ir taktiniai (detalūs, operatyviniai) planai.

Tinklo planas su keliais projektais (vyresniajai vadovybei)

1 lygis

3 lygis

2 lygis

Tinklo planas su pagrindiniais etapais (gairėmis)

Detalus tinklo planas

Ryžiai. 3.11.Kelių pakopų tinklo planai

Koncepcinis planavimas, kurio rezultatas – koncepcinis planas, tai pagrindinės projekto dokumentacijos, techninių reikalavimų, sąmatų, detalių grafikų, kontrolės ir valdymo procedūrų rengimo procesas. Koncepcinis planavimas vyksta projekto gyvavimo ciklo pradžioje.

Strateginis planavimas yra strateginių, integruotų, ilgalaikių planų rengimo procesas.

Detalus (operatyvus, taktinis) planavimas susiję su taktinių, detaliųjų planų (grafikų), pagrįstų operatyvinio valdymo hierarchine darbo struktūra (WBS) kūrimu.

atsakingų vykdytojų lygmenyje.

Suplanuokite turinio valdymą. Viena iš įprastų programinės įrangos projektų „ligų“ vadinama „šliaužiantis funkcionalizmas“ kai prie originaliai suprojektuotos būdelės mylimam šuniui iš pradžių prideda namelis sodo įrankiams laikyti, o vėliau – kelių aukštų namas jo šeimininkui. Ir visa tai bandoma statyti ant tų pačių pamatų ir iš tų pačių medžiagų. Šis požiūris sukėlė daugelio programinės įrangos kūrimo projektų mirtį. Todėl, kai tik pavyko stabilizuoti ir susitarti dėl WBS – hierarchinės darbo struktūros, būtina plėtoti projekto apimties valdymo planas, dėl kurio turėtumėte:

• nustatyti pakeitimų prašymų šaltinius;
• nustato turinio pakeitimų analizės, vertinimo ir tvirtinimo/atmetimo tvarką;
• nustato turinio pakeitimų dokumentavimo tvarką;
• nustato informavimo apie turinio pasikeitimus tvarką. Pirma užduotis, kurią reikia išspręsti analizuojant užklausą

pakeitimams - nustatyti keitimo objektus: reikalavimus, architektūrą, duomenų struktūras, šaltinio kodus, testavimo scenarijus, vartotojo dokumentaciją ir kt. Tada reikia suprojektuoti ir detaliai aprašyti visų identifikuotų objektų pokyčius. Galiausiai, reikėtų įvertinti šių pakeitimų atlikimo, pakeitimų testavimo sąnaudas ir jų įtaką projekto terminui. Šis darbas pareikalaus įvairių specialistų: analitikų, projektuotojų, kūrėjų, testuotojų, taip pat projektų vadovo praleisto laiko, o kartais ir reikšmingo, todėl į tai turi būti atsižvelgta planuojant.

Organizacinės struktūros planavimas.Organizacinė struktūra- tai yra sutartas ir patvirtintas pagrindinių projekto dalyvių vaidmenų, atsakomybės ir tikslų pasiskirstymas. Jame būtinai turi būti:

• darbo santykių tarp projekto darbo grupių sistema;
• ataskaitų teikimo sistema;
• projektų eigos vertinimai;
• sprendimų priėmimo sistema.

Reikia atsiminti, kad projekto organizacinė struktūra yra „gyvas“ organizmas. Jis pradeda formuotis planavimo etape ir turėtų keistis, kai projektas vystosi. Organizacinės struktūros nestabilumas (dažni atlikėjų pasikeitimai) gali tapti rimta projekto valdymo problema, nes atsiranda pakeitimo kaštai, kuriuos nulemia laikas, kai naujas dalyvis patenka į projekto kontekstą.

Konfigūracijos valdymo planavimas. Vienas iš svarbių programinės įrangos gamybos procesų yra konfigūracijos valdymas. Apie šią žinių sritį parašyta ne viena knyga. Čia kalbėsime tik apie tai, kaip reikėtų planuoti šį darbą. Projekto konfigūracijos valdymo plane turėtų būti:

• dirbti siekiant užtikrinti bendrą visos projekto dokumentacijos ir sukurto programos kodo saugyklą, užtikrinančią projekto informacijos saugumą ir atkūrimą po gedimo;
• darbas prie projekto komandos narių naudojamų darbo vietų ir serverių įrengimo;
• darbas, būtinas organizuojant tarpinių sistemos leidimų surinkimą, taip pat galutinę jos versiją.

Šį darbą dažniausiai atlieka konfigūracijos inžinierius. Jei projektas mažas, tai šis vaidmuo gali būti papildomas vienam iš programuotojų ar projekto vadovo. „Paskirstyti“ šį darbą visiems projekto dalyviams, pirma, neefektyvu. Norint įdiegti ir konfigūruoti kūrimo aplinkas, tokias kaip duomenų bazės ir taikomųjų programų serveriai, reikia specifinių kompetencijų ir žinių apie konkrečias produkto versijas. Jei visi kūrėjai turės išmokti šių įgūdžių, tai užtruks per daug laiko. Antra, konfigūracijos valdymo darbų „išplitimas“ gali sukelti kolektyvinį neatsakingumą, kai niekas nežino, kodėl „projektas neveiks“ ir kaip „grąžinti“ į ankstesnę versiją.

Konfigūracijos valdymas gali tapti daug sudėtingesnis, jei projekto komanda kartu su naujo produkto funkcionalumo kūrimu turės palaikyti keletą šio produkto laidų, kurias anksčiau įdiegė skirtingi klientai, tačiau į visą šį darbą reikia atsižvelgti projekte. planą.

Kokybės vadybos planavimas. Kita pagrindinė programinės įrangos inžinerijos žinių sritis yra kokybės užtikrinimas. Yra įvairių nuomonių apie tai, kas yra programinės įrangos kokybė ir kaip ją efektyviai užtikrinti. Apsiribokime teiginiu, kad kokybės užtikrinimas yra gana svarbus darbas, kurį reikia planuoti iš anksto ir atlikti viso programinės įrangos projekto metu, o ne tik priėmimo testų metu.

Planuojant šį darbą būtina suprasti, kad projekto produktas neturi būti aukščiausios kokybės, kuri nepasiekiama per ribotą laiką. Reikalingą gaminio kokybę lemia jai keliami reikalavimai. Pagrindinė kokybės užtikrinimo užduotis yra ne klaidų paieška gatavame produkte (produkcijos kontrolė), o užkirsti joms kelią gamybos proceso metu.

Kokybės vadybos planas turėtų apimti šiuos darbus:

• objektyvus programinės įrangos produktų ir technologinių operacijų atitikties taikomiems standartams, procedūroms ir reikalavimams patikrinimas;
• nustatyti kokybės nukrypimus, nustatyti jų priežastis, taikyti priemones jiems pašalinti, taip pat stebėti, kaip įgyvendinamos priemonės ir jų efektyvumas;
• vyresniajai vadovybei teikti nepriklausomą informaciją apie neatitikimus, kurie neišsprendžiami projekto lygmeniu.

Darbo turinio ir sudėties patikslinimas. Projekto turinio išaiškinimas (dekompozicija) yra vienas iš svarbiausių projektų valdymo disciplinos komponentų. Detalizavimas leidžia apskaičiuoti, pavyzdžiui, bendrą projekto kainą per bendrą atskirų darbų kainą. Projekto turinio detalizavimo rezultatas yra darbo suskirstymo struktūra(Work Breakdown Structure – WBS). Daugeliu atvejų ši struktūra yra hierarchinė. Tuo pačiu metu yra pats detalizavimo procesas darbo suskirstymo struktūra, t.y. veikla siekiant sukurti detalią darbo ar projekto užduočių struktūrą.

Hierarchinė darbo struktūra(WBS) – tai į rezultatus orientuotas projekto komandos atliekamų darbų išskaidymas, siekiant projekto tikslų ir reikalaujamų rezultatų. Jos pagalba struktūrizuojamas ir nustatomas visas projekto turinys. Kiekvienas paskesnis hierarchijos lygis atspindi išsamesnį projekto elementų apibrėžimą. WBS kūrimo pagrindas yra projekto koncepcija, kuri apibrėžia projekto produktus ir pagrindines jų charakteristikas. WBS užtikrina, kad būtų nustatytas visas darbas, reikalingas projekto tikslams pasiekti. Daugelis projektų žlunga ne todėl, kad jie neturi plano, o todėl, kad planas nepaiso svarbių darbų, tokių kaip testavimas ir klaidų taisymas, taip pat projekto produktai, tokie kaip vartotojo dokumentacija. Todėl, jei WBS sudarytas teisingai, bet koks į jį neįtrauktas darbas negali būti laikomas projekto darbu. WBS padalina projektą į subprojektus, darbo paketus ir subpaketus. Kiekvienas paskesnis išskaidymo lygis suteikia nuoseklų projekto turinio detalizavimą, leidžiantį įvertinti darbų laiką ir apimtį. Į WBS turi būti įtraukti visi tarpiniai ir galutiniai produktai.

Yra įvairių būdų, kaip suskaidyti projekto darbą. Pavyzdžiui, GOST 19.102-77 numato krioklio priėjimas ir apibrėžia šiuos dalykus programinės įrangos sistemos kūrimo etapai.

• 1) techninės specifikacijos;
• 2) preliminarus projektas;
• 3) techninis projektas;
• 4) darbo projektas;
• 5) įgyvendinimas.

Jei laikysimės šio standarto, šie dizaino gaminiai turėtų būti pirmojo WBS lygio. Jei turėtume sukurti automatizuotą valdymo sistemą, skirtą valdyti branduolinį reaktorių arba pilotuojamą erdvėlaivį, tai būtent tai turėjo būti padaryta. Tačiau kuriant komercinę programinę įrangą šis metodas yra neveiksmingas.

Šiuolaikinės komercinės programinės įrangos kūrimo procesas turi būti laipsniškas. Tai reiškia, kad aukščiausiame projekto dekompozicijos lygyje turėtų būti projekto produktai, o kitame lygyje - komponentai, iš kurių šie produktai susideda. Komponentai gali būti toliau skaidomi į „funkcijas“ – funkcijas, kurias jie turi įgyvendinti.

Programinės įrangos produktą sudarančių komponentų išskyrimas yra aukšto lygio projektavimo elementas, kuris turėtų būti atliktas projekto planavimo etape, nelaukiant, kol bus parengti visi kuriamos programinės įrangos funkciniai reikalavimai. Komponentai gali būti tiek taikomųjų programų posistemiai, tiek infrastruktūros arba branduoliniai, pavyzdžiui, autentifikavimo ir saugos posistemis, grafinės sąsajos (GUI) vaizdinių komponentų biblioteka. Sudarant pagrindinį darbo planą, neturėtumėte stengtis detalizuoti visų WBS darbų, kiek įmanoma, pakanka 3–5 lygių.

Detalizavimo kontekste terminai „užduotys“ ir „darbas“ dažnai vartojami pakaitomis. Visgi teisingiau sakyti, kad užduotis lemia tarpinio rezultato pasiekimą, o darbas – veiksmų visuma šiems rezultatams pasiekti. Kadangi bet kuri užduotis reikalauja atlikti tam tikrus darbus laikantis tam tikrų apribojimų, tikrai galime kalbėti apie neabejotiną užduočių „priskyrimą“ darbui ir atvirkščiai. Tai yra terminų pakeičiamumo kasdieniame gyvenime priežastis. Tuo pačiu suprasdami šių sąvokų skirtumus galite pajusti produkto kūrimo proceso požiūrio niuansus, taigi ir projektų gyvavimo ciklą, įskaitant programinės įrangos sistemų projektus.

Apskritai galime kalbėti apie detalė: „programa – projektas - užduotis yra operacija“. Fig. 3.12 paveiksle pateikiamas tokio detalizavimo pavyzdys (rodomos tik užduočių operacijos A).

Ryžiai. 3.12.Terminų vartojimo pavyzdys: programa, projektas, užduotis, operacija

Kiekvienas tokios struktūros elementas yra susijęs su apribojimais ir kitomis reikšmingomis savybėmis bei duomenimis. Aktualumas reiškia jų būtinumą arba naudingumą priimant sprendimus. Tam tikrų terminų detalumo gylis ir taikymo lygis priklauso nuo konkretaus projekto, valdymo kultūros, gyvavimo ciklo standartų, projekto specifikos ir masto, taip pat nuo kitų veiksnių, būdingų tiek konkrečiai organizacijai, tiek konkrečiam projektui.

Asmeninė atsakomybė turi būti nustatyta už visas projekto dalis (paprojekčius ir darbų paketus). Kiekvieno darbo paketo išvesties rezultatas turi būti aiškiai apibrėžtas. Darbų ir projektų sąmatos turi būti suderintos su pagrindiniais komandos nariais, atliekančios įmonės vadovybe ir, jei reikia, su užsakovu. Pagal susitarimą komandos nariai prisiima įsipareigojimus įgyvendinti projektą, o vadovybė prisiima atsakomybę už projekto aprūpinimą reikalingais ištekliais.

WBS yra viena pagrindinių projektų valdymo mechanizmo įrankių (priemonių), kurios pagalba matuojamas projekto rezultatų pasiekimo laipsnis. Svarbiausia jo funkcija – užtikrinti, kad visi projekto dalyviai suprastų ir suprastų, kaip projektas bus vykdomas. Vėliau pradinė padėtis bus kaip gairės palyginimui su dabartiniu projekto vykdymu, siekiant nustatyti nukrypimus.

Projekto išlaidų sąmata. Programinės įrangos projekto valdymo procesas prasideda nuo daugelio veiklų, kurias vienija bendras pavadinimas projekto planavimas. Pirmasis iš šių veiksmų yra atlikti projekto išlaidų sąmatą. Tai padeda pagrindą kitai projekto planavimo veiklai. Vertinant projektą klaidų kaina yra itin didelė. Labai svarbu vertinimą atlikti su minimalia rizika.

Pagrindinis projekto išlaidų algoritminio modeliavimo sunkumas yra sąmatos priklausomybė nuo gatavo produkto savybių ir parametrų. Pradiniame projekto etape neįmanoma tiksliai nustatyti šių savybių ir parametrų. Yra daug metodų, kaip apskaičiuoti programinės įrangos kainą, kuri turėtų būti naudojama lygiagrečiai. Jei gauti rezultatai labai skiriasi, tai reiškia, kad analizei panaudota nepakankama arba netinkama informacija. Programinės įrangos produkto kaina dažnai iš anksto nustatomas siekiant sudaryti sutartį, o tai lemia vėliau sistemos funkcionalumo koregavimą iki tokių, kurie atitiktų šią kainą.

Įžymūs projekto išlaidų įvertinimo modelis B. Boema SOSOMO atsižvelgia į dizaino ypatybes, kuriamos programinės įrangos savybes, techninę įrangą ir personalo galimybes. Šis modelis taip pat apima įrankius, skirtus projekto darbo trukmei nustatyti. Laikas, reikalingas darbams atlikti, tiesiogiai nepriklauso nuo projektui samdomų specialistų skaičiaus. Pridėjus daugiau žmonių prie vėluojančio projekto, jo užbaigimas gali būti atidėtas.

Algoritminiai projektų kaštų skaičiavimo modeliai naudojami programinės įrangos projektams valdyti, nes jie palaiko kiekybinę parametrų analizę. Šie modeliai leidžia įvertinti kiekvieno atskiro parametro indėlį į bendrą projekto kainą ir atlikti objektyvų (nors ir neapsaugotą nuo klaidų) šių parametrų palyginimą.

Projekto išlaidų įvertinimas- vienas iš svarbiausių projekto darbų, kuris nustatomas pagal atskirų projekto dalių kainą, darbų atlikimo sąlygas, faktinį atlikėjų personalą, naudojamus metodus ir priemones. Į projekto kainą įskaičiuotos ir projekto vykdymo išlaidos, t.y. kompiuteriai, programinė įranga, erdvė, baldai, telefonai, modemai ir daug daugiau. Be to, kartais reikia atsižvelgti ir į papildomas išlaidas (pavyzdžiui, už saugumą). Papildomos projekto išlaidos apima testavimo sistemos, CABE sistemos ir kt. pirkimą. Pagrindinis projekto vertinimas yra projekto išlaidų sąmata, išreikštas atlikėjų darbo dienomis prie projekto. Šis vertinimas atliekamas ankstyvame valdymo ir planavimo etape.

Bendrą projekto kainą nustato patyrę specialistai su paklaida iki 10%. Sąnaudų įvertinimas gali būti „iš viršaus į apačią“, „iš apačios į viršų“ arba remiantis anksčiau pagaminto dizaino kaina. Ekspertai atlieka pesimistinius, optimistiškus ir realistiškus vertinimus, apklausdami visus darbo grupės narius ir pakoreguodami kiekvieną vertinimą, kad gautų labiausiai tikėtiną. Kai kuriose darbo grupėse pesimistiniai ir optimistiški vertinimai gali labai skirtis.

Algoritminiai projekto išlaidų įvertinimo metodai parodyti ryšius tarp projekto išlaidų ir joms įtakos turinčių veiksnių.

Yra įvairių empirinių būdų įvertinti projekto kainą, pavyzdžiui, projekto kainą siūloma nustatyti naudojant formulę

KAINA = (a + b?)t(X),

kur 5 yra tam tikras sistemos dydžio įvertinimas; a, b, c - empirinės konstantos; X - išlaidų veiksnių vektorius su dimensija penktadienis - reguliavimo daugiklis, pagrįstas sąnaudų veiksniais.

Eksperimentiniu būdu gautas supaprastintas įvertinimas išreiškiamas taip:

KAINA = 5,255 0,91.

Šie įverčiai buvo gauti analizuojant projektus, kuriuose programos svyravo nuo 4000 iki 467000 kodo eilučių ir buvo parašytos 28 skirtingomis programavimo kalbomis 66 kompiuteriuose. Plėtrai buvo skirta nuo 12 iki 11 758 žmogaus mėnesių. Taip pat žinomi kiti empirinio modeliavimo būdai.

Pirmuosiuose modeliuose buvo naudojami kainų rodikliai, buvo atsižvelgta į personalą ir projekto savybes, produktą ir aplinką. Modeliai apima trijų projekto valdymo etapų įvertinimą. Pirmajame etape sukuriamas prototipas didelės rizikos užduotims atlikti (vartotojo sąsaja, programinė įranga, sąveikos sistema, diegimas ir kt.) ir įvertinamos išlaidos (pvz., lentelių skaičius duomenų bazėje, ekranai ir ataskaitų formos ir kt. .). Antrajame etape įvertinamos projekto reikalavimuose atsispindinčių projekto funkcinių taškų projektavimo ir įgyvendinimo sąnaudos. Trečiajame etape sąmata reiškia užbaigtą projektą, kai galima nustatyti sistemos dydį pagal užbaigtas programos eilutes ir kitus veiksnius.

Pagrindinis eksperimentinio projekto išlaidų įvertinimo modelis šiandien yra tokia lygtis:

KAINA = bS c m(X),

Kur bS c - pirminis įvertinimas, kuris koreguojamas naudojant išlaidų vektorių t(X) ir senų bei naujų objektų skaičiaus apskaitą; Su- parametras, kuris svyruoja nuo nulio iki vieneto pirmajam projekto etapui ir nuo 1,01 iki 1,26 likusiems etapams.

Taikant formalizuotą metodą, projekto vertinimas grindžiamas LOC ir FP metrikų naudojimu.

Konstruktyvus kaštų modelis(SOSOMO – Konstruktyvus kaštų modelis), kurį pasiūlė B. Boehm, apjungia žinomiausius formalizuoto projektų vertinimo metodus – LOC sąmatos(LOC – kodo eilutės), kurios yra pagrįstos programos kodo eilučių skaičiumi. Taikant šį modelį sudaromos preliminarios sąmatos, kurios leidžia klientui pateikti teisingus reikalavimus programinės įrangos kūrimo sąnaudoms ir sąnaudoms, taip pat užtikrina galimybę sudaryti programinės įrangos planą.

Į funkcijas orientuota FP metrika Užuot skaičiuoję LOC balus, jie netiesiogiai matuoja programinės įrangos produktą. Svarstomas ne dydis, o gaminio funkcionalumas ar naudingumas. Šios metrikos autorius – A. Albrechtas. Funkcinio dydžio nustatymas susideda iš kelių žingsnių ir prasideda nustatant funkcijas, kurias turi turėti programa. Tarptautinė funkcinių taškų vartotojų grupė (IFPUG) paskelbė kriterijus, pagal kuriuos nustatomos programos funkcijos. Skaičiuojant FP metriką, naudojamos penkios informacijos charakteristikos: išorinių įėjimų skaičius; išorinių išėjimų skaičius (išėjimai reiškia ataskaitas, ekranus, spaudinius, klaidų pranešimus); išorinių užklausų skaičius; vidinių loginių failų skaičius; išorinės sąsajos failų skaičius.

Surinkę visą reikiamą informaciją, pereikite prie metrikų skaičiavimas - nustatyti funkcijų rodyklių skaičius FP (funkciniai taškai) pagal tam tikrą formulę, kur įvesties sudėtingumo koregavimo koeficientų reikšmės (kiekvienas koeficientas gali turėti šias reikšmes: 0 - jokios įtakos; 1 - atsitiktinis; 2 - mažas; 3 - vidutinis; 4 - 5 - pagrindiniai) atrenkami empiriškai pagal atsakymus į 14 klausimų, apibūdinančių programos sistemos parametrus.

Metodas susideda iš to, kad vienodai išmatuojamos visos bet kurio projekto programos galimybės ir paraiškos dydis išreiškiamas vienu skaičiumi, kuris vėliau gali būti naudojamas norint įvertinti kodo eilučių skaičių, projekto kainą ir laiką. Jos pagrindu formuojami produktyvumo, kokybės ir kt.

Privalumasį funkciją orientuota metrika yra ta, kad jos nepriklauso nuo programavimo kalbos ir yra lengvai apskaičiuojamos bet kuriame projekto etape.

Trūkumaiį funkciją orientuota metrika – rezultatai pagrįsti subjektyviais, o ne tiesioginiais matavimais; Be to, norint tiksliai ir nuosekliai taikyti šį metodą, reikia turėti tam tikrų įgūdžių.

Naudojant standartines lenteles, FP įverčiai gali būti lengvai konvertuojami į LOC įverčius, t.y. Iš funkcinio dydžio apskaičiuokite kodo eilučių skaičių. Tačiau konvertavimo rezultatai priklauso nuo programavimo kalbos, naudojamos įdiegiant programinę įrangą (pavyzdžiui, Java programoje vienas funkcinio dydžio vienetas yra lygus 53 šaltinio kodo eilutėms). Savo ruožtu kodo eilučių skaičius leidžia nustatyti bendrą darbo intensyvumą, išreikštą asmens mėnesiais, ir projekto laiko juostą.

Atliekant vertinimą, yra du galimi LOC ir FP duomenų panaudojimo būdai: kaip įvertinimo kintamieji, nustatantys kiekvieno produkto elemento dydį, arba kaip metrika, surinkta dirbant su ankstesniais projektais ir įtraukta į įmonės metrikos bazę.

Pavyzdys 3.1. Panagrinėkime darbo įvertinimo pagal ShS metriką procedūros atlikimo tvarką.

1 etapas. Suprojektuoto gaminio paskirties sritis yra padalinta į daugybę funkcijų/i,/2,/3, kurių kiekviena gali būti

vertinti individualiai

2 etapas. Kiekvienai funkcijai / planuokliui sukuriama geriausia LOC n, blogiausia YUS X ir tikėtinas JUS V vertinimai. Įverčių formavimo procese naudojami eksperimentiniai duomenys iš metrinio pagrindo arba intuityvios planuotojo idėjos. Galimų įverčių diapazonas atitinka pateiktą neapibrėžtumo laipsnį.

3 etapas. Kiekvienai funkcijai f t numatoma vertinimo vertė nustatoma:

JUS I + YUS X + 4 BOC^ aušintuvas = 6"

yus.

4 etapas. Funkcijos plėtros AL-našumo vertė apskaičiuojama pagal vieną iš trijų taisyklių.

Taisyklė L. Visoms funkcijoms imama ta pati reikšmė, lygi vidutiniam PR avg produktyvumui, paimtam iš metrinės bazės, t.y.

PR, = PR vid. / = 1, 2, ..., P.

Taisyklė B. i-ajai funkcijai tinkinta našumo vertė apskaičiuojama remiantis vidutine našumo metrika:

ys sr

MS kietas ’

Kur YUS Trečiadienis - vidutinis LOC balas, paimtas iš metrinės bazės (atitinka vidutinį produktyvumą).

Taisyklė B. i-ajai funkcijai reguliuojama našumo vertė apskaičiuojama naudojant pasirinktą analogą (paimta iš metrinės bazės):

BOSdnI

Ponia Oži

Taisyklės A naudojimas tolesniuose etapuose užtikrina minimalų tikslumą ir maksimalų skaičiavimų paprastumą. Taisyklė B leidžia pasiekti maksimalų tikslumą ir didžiausią skaičiavimo sudėtingumą.

Scena 5. Bendra projekto išlaidų sąmata (asmens mėnesiui) apskaičiuojama, jei taikoma A taisyklė:

jei naudojama taisyklė B arba C:

b1у ^ozh/

6 etapas. Bendra projekto išlaidų sąmata apskaičiuojama, jei taikoma A arba B taisyklė:

KAINA = UDST vid. yuS 0Zh/ ;

jei naudojama taisyklė B:

KAINA = UDST an/ ^YUS 0Zh/ ,

kur UDST avg yra vidutinės vienos programos kodo eilutės kainos metrika; UDST an, - vienos analoginės linijos kainos metrika (abi metrika paimta iš metrinės bazės).

Projekto grafiko sudarymas. Nustačius darbų darbo intensyvumą, būtina nustatyti jų įgyvendinimo grafiką ir bendrą projekto terminą, t.y. sudaryti projekto darbų grafiką Pagrindinis grafikas yra patvirtintas grafikas su nurodytomis projekto laiko fazėmis, etapais ir hierarchinės darbo struktūros elementais.

Pagrindinis grafikas daugeliu atvejų yra sutarties su klientu elementas. Kontroliniai taškai (etapai) pasitarnauja kaip taškai analizuojant projekto būseną ir priimant sprendimus „§o arba po1 §o“ formatu, todėl jie turėtų akivaizdžiai parodyti projekto būseną. Kontrolinių taškų parinkimui ir formavimui keliami tam tikri reikalavimai, pavyzdžiui, kontrolinis taškas „Dizainas baigtas“ yra neinformatyvus nuoseklus pristatymo būdas laikomas efektyvesniu metodu: minėtas kontrolinis taškas suformuluotas forma „; 1, 3, 5 ir 7 reikalavimų testavimas baigtas.

Jeigu darbai tarpusavyje nesusiję, tai bet kurį iš jų galime pradėti ir užbaigti tada, kai mums patogu; visi darbai gali būti atliekami lygiagrečiai, tokiu atveju minimali projekto trukmė yra lygi ilgiausio darbo trukmei. Tačiau praktikoje dažniausiai pasitaiko priklausomybių tarp darbų, kurie gali būti „sunkūs“, pavyzdžiui, konkrečios funkcijos „analizė – projektavimas – kodavimas – testavimas – dokumentavimas“ arba „minkštas“, kurį galima peržiūrėti arba sušvelninti, pvz. , konkretaus vykdytojo nuoseklų užduočių vykdymą galima perplanuoti kitam rangovui, o vietoj pagrindinės programinės įrangos kūrimo, kuri turi būti prieš taikomosios programinės įrangos kūrimą, galite sukurti „stubus“, imituojančius jos darbą.

Darbo plano su jų įgyvendinimo terminais rengimas gali būti atliekamas naudojant kritinio kelio metodą CPM arba PERT programų analizės ir vertinimo metodą. Projekto planas pateikiamas pagal etapus: „Planavimas“, „Dizainas“, „Kodavimas“, „Testavimas“ ir „Priežiūra“. Planavimas yra susijęs su specifikacijų, biudžeto ir grafiko nustatymu, taip pat bendro projekto plano kūrimu.

IN projekto kritinio kelio metodas(Kritinis kelias) naudojama ilgiausia projekto darbų grandinė. Padidinus bet kokio darbo šioje grandinėje trukmę, pailgėja viso projekto trukmė. Projekte visada yra bent vienas kritinis kelias, bet gali būti keli. Projekto vykdymo metu kritinis kelias gali pasikeisti.

Vykdydamas projektą vadovas pirmiausia turi atkreipti dėmesį į užduočių vykdymą kritiniame kelyje ir stebėti kitų kritinių kelių atsiradimą. Yra praktinė rekomendacija: kritiniame kelyje turėtų būti darbas su nestandžiomis jungtimis, kurias visada galima perplanuoti, jei kyla grėsmė praleisti terminus. Darbo grafikas sudaromas pagal schemą, parodytą pav. 3.13.

Reikalavimų tvarkaraštis

prie projekto

Ryžiai. 3.13.Darbo su projektu planavimo žingsniai

Planuojant programos analizės ir vertinimo metodas PERT įvykis arba data plane yra tam tikras etapas (kontrolinis taškas) individualaus projekto darbo kelyje ir naudojamas tam tikrų darbų atlikimo būsenai rodyti/žymėti. Projekto kontekste vadovai naudoja gaires, kad nustatytų svarbius tarpinius rezultatus, kurie turi būti pasiekti projekto metu.

Dažnai vadinama vadovo apibrėžta etapų seka etapo planas (pagal įvykius). Apibrėžus planą, kaip pasiekti atitinkamus etapus, sukuriamas etapu pagrįstas tvarkaraštis.

Planavimo etape taip pat galima naudoti tinklo darbo suskirstymą ir Ganto diagramą.

Darbo suskirstymas tinkle(SPP) yra hierarchinė struktūra, skirta projekto užduotims išskaidyti į papildomas užduotis. Žemesniame lygyje yra darbai detalizuoti į veiklos elementus veikiančių sistemų sistemos tinkliniame modelyje.

Tinklo modelis leidžia suskirstyti darbą į pagrindinius komponentus ir subkomponentus, nustatyti veiklos sritis, kuriomis siekiama sudėtingų tikslų, paskirstyti asmenis, atsakingus už individualaus darbo su projektu įgyvendinimą, ir užpildyti ataskaitas, apibendrinančias informaciją apie projekto rezultatus.

Darbų plane turi atsispindėti pagrindiniai darbo etapai ir reikalinga darbo būklė kiekviename etape, kiekvieno darbo suskirstymas į atskiras užduotis, taip pat darbų ryšiai, kiekvienos veiklos atlikimo laiko intervalai, darbų pradžios ir pabaigos laikai. Į darbo planą įtrauktos įvairaus tipo projekto funkcijų, posistemių, patikimumo, apsaugos priemonių demonstravimas, plano dokumentuose taip pat pateikiamas vadovų ir technikų rinkinys, kaip atlikti nurodytas operacijas, palaikyti sistemos ryšius su kitais posistemiais ir kt.

Darbo plane WBS grafiko pavidalu pateikiamos fazės (etapai), žingsniai ir veiklos, įskaitant pradinę ir galutinę proceso veiklą (3.14 pav.).

Fazė Ir

1 veiksmas 2 veiksmas

Ryžiai. 3.14.Žingsnis po žingsnio projekto plano grafikas

Kita vizualinio darbo plano vaizdavimo forma galėtų būti tinklo schema, nurodytas grafiko pavidalu, kurio viršūnėse išsidėstę darbo elementai, o ant lankų - dienų (savų) skaičius, reikalingas jiems atlikti (3.15 pav.). Šie ženklai naudojami proceso vykdymo laikui nustatyti. Lankas paliekantis inicialą

Ryžiai. 3.15.

viršūnė ir įvedimas į galutinę viršūnę, atitinka laiko žymą „nulis“.

Diagramoje gali būti ciklinių takų. Grafas naudojamas kritiniams keliams analizuoti, t.y. nustatyti kiekvieno proceso trukmę.

Tvarkaraščio kūrimas susideda iš pradžios taško (įvykio ar įvykių rinkinio, įvykusio prieš proceso etapo pradžią ir kuriam aprašyta sąlygų rinkinys, įskaitant proceso pradžią), trukmės (laiko intervalo, per kurį procesas turi sėkmingai užbaigti savo vykdymą), terminas (data , iki kurios procesas visiškai ar iš dalies užbaigiamas) ir proceso pabaigos taškas (kontrolinis taškas, kuriame klientas patikrina gautų proceso rezultatų kokybę).

Akivaizdžiausias būdas pateikti pagrindinį tvarkaraštį yra Ganto diagramos- linijinė diagrama, kurioje projekto užduotys pavaizduotos laikotarpiais, įskaitant jų įgyvendinimo pradžios ir pabaigos datas, atsižvelgiant į galimą vėlavimą. Šioje diagramoje planuojamos veiklos (darbų suskirstymo struktūros elementai) pateikiamos kairėje pusėje, datos rodomos viršuje, o veiklos trukmė – horizontaliomis juostomis nuo tam tikros veiklos pradžios iki jos pabaigos datos (pav. 3.16).

Ryžiai. 3.16. Ganto diagramos

Vykdymo proceso grupė

Projektų valdymo procesų grupės

Projekto kokybės valdymas

Saugumas

kokybės

Šiuolaikinė projektų valdymo programinė įranga leidžia vizualizuoti projekto grafiko struktūrą ir darbo procesus, pavyzdžiui, plačiai žinoma ir gana dažnai praktikoje naudojama Projektų valdymo sistema. Tai leidžia kūrėjui ar projekto vadovui matyti, kaip atliekamos įvairios veiklos – nuosekliai ar lygiagrečiai, ir ar jos eina kritiniu keliu.

Projekto planavimas yra projekto valdymo dalis, apimanti tvarkaraščius, pvz., Ganto diagramą, planuoti darbą ir pranešti apie pažangą projekto aplinkoje.

Iš pradžių apibrėžiama projekto apimtis, tačiau nėra apibrėžti tinkami projekto užbaigimo būdai. Po šio veiksmo darbo vienetai, reikalingi darbui atlikti, turėtų būti išvardyti ir sugrupuoti į darbo suskirstymo struktūrą (WBS), atsižvelgiant į įvairių užduočių trukmę. Projekto planavimas dažnai naudojamas įvairioms projekto sritims organizuoti, įskaitant projekto planus, darbo krūvius ir komandų bei žmonių valdymą. Loginės užduočių priklausomybės nustatomos naudojant tinklo aktyviąją diagramą, kuri leidžia nustatyti kritinį kelią.

Projekto planavimas yra neaiškus; jis turi būti atliktas prieš pradedant įgyvendinti projektą. Todėl užduočių trukmė dažnai apskaičiuojama naudojant optimistinių, normalių ir pesimistinių įverčių svertinį vidurkį. Tai prideda „buferių“ planuojant, kad būtų galima numatyti projekto įgyvendinimo vėlavimus (pvz., ilgus patvirtinimus). Laikas grafike gali būti skaičiuojamas naudojant projektų valdymo programinę įrangą. Kiekvienai veiklai reikalingi ištekliai ir kaštai gali būti įvertinti, pateikiant bendrą projekto kainą. Šiame etape projekto tvarkaraštis gali būti optimizuotas, kad būtų pasiekta tinkama pusiausvyra tarp išteklių naudojimo ir projekto trukmės, atitinkančios projekto tikslus. Sukūrus ir patvirtinus projekto tvarkaraštį, jis tampa pradiniu (arba tiksliniu) grafiku. Integruoto projekto pažanga bus vertinama pagal pradinį grafiką per visą projekto laikotarpį. Pažangos analizavimas pagal pradinį tvarkaraštį vadinamas uždirbtos vertės metodu.

Į projekto planavimo etapą įeina projekto chartija ir koncepcijos pasiūlymai. Projekto planavimo etapo rezultatai apima projekto reikalavimus, projekto tvarkaraštį ir projekto valdymo planą.

Projektą galima planuoti rankiniu būdu, tačiau dažnai naudojami projektų valdymo programinės įrangos paketai. Tokie kompleksai apima profesionalų „Oracle Primavera“ ir kasdieniškesnį „MS Project“.

Projektų valdymo srityje projekto tvarkaraštis yra projekto etapų, užduočių ir rezultatų sąrašas, paprastai su numatoma pradžios ir pabaigos data. Šie elementai dažnai įvertinami pagal kitą informaciją, įtrauktą į projekto tvarkaraštį, pvz., išteklių paskirstymą, biudžetą, užduočių trukmę, ryšius, priklausomybes ir suplanuotus įvykius. Projekto tvarkaraštis dažniausiai naudojamas planuojant ir valdant projektų portfelį. Tvarkaraščio elementai gali būti glaudžiai susieti su darbų suskirstymo struktūra (WBS) pagal pagrindinius įvykius, darbų ataskaitą arba sutarties duomenis.

Projektų grafikų charakteristikos

Daugelyje pramonės šakų, pavyzdžiui, inžinerijos ir statybos, už projekto grafiko kūrimą ir palaikymą atsako vidinis planuotojas arba planuotojų komanda, atsižvelgiant į projekto dydį. Planavimo metodai yra gerai išvystyti ir nuosekliai taikomi visose pramonės šakose.

Reikėtų pažymėti, kad projektų valdymas neapsiriboja pramone; eilinis žmogus gali panaudoti šį metodą tvarkydamas savo gyvenimą. Kai kurios projektų valdymo programos, šablonai, diagramos ir pavyzdžiai padės vartotojams susikurti savo tvarkaraštį.

Projektų grafikų rengimo metodai

Prieš kurdami tvarkaraštį, turite sukurti darbo suskirstymo struktūrą (WBS), įvertinti kiekvienos užduoties išlaidas ir sudaryti išteklių sąrašą. Jei šių tvarkaraščio komponentų nėra, juos galima sukurti naudojant konsensusu pagrįstus įvertinimo metodus, pvz., Delphi metodą. Taip yra todėl, kad pats grafikas yra apytikslis: kiekviena tvarkaraščio diena yra apskaičiuota, ir jei tos datos nėra pagrįstos faktine žmonių, kurie ketina atlikti darbą, patirtimi, grafikas nebus tikslus.

Kad projekto grafikas būtų realus, turi būti laikomasi šių kriterijų:

• Tvarkaraštis turi būti nuolat (geriausia kas savaitę) atnaujinamas (atnaujinamas).
• EAS vertė (balas užbaigus) turi būti lygi bazinei vertei.
• Darbo krūvis turi būti teisingai paskirstytas komandos nariams (atsižvelgiant į savaitgalius).

ĮVADAS

Projekto valdymas yra plano sudarymas ir darbo eigos sekimas. Atitinkamai, kuo geresnis projekto planas, tuo tiksliau jis sudarytas, tuo lengviau atlikti projektavimo darbus ir sėkmingai užbaigti projektą.

Norėdami gerai planuoti, pirmiausia turite gerai suprasti, kas yra projektas ir iš kokių elementų jis susideda.

Bet kurios organizacijos veikla yra vykdyti operacijas ir projektus. Abu turi daug bendro, pavyzdžiui, juos atlieka žmonės, kuriems skiriami riboti ištekliai.

Pagrindinis skirtumas tarp operacijų ir projektų yra tas, kad operacijos yra nuolatinės ir pasikartojančios, o projektai yra laikini ir unikalūs. Remiantis tuo, projektas apibrėžiamas kaip laikinos pastangos sukurti unikalų produktą ar paslaugą. „Laikinasis“ reiškia, kad kiekvienas projektas turi tam tikrą pradžios ir pabaigos datą. Kai kalbame apie tai, kad produktas ar paslauga yra unikali, turime omenyje, kad jis pastebimai skiriasi nuo panašių produktų ar paslaugų.

Kiekvieno projekto unikalumas sukelia sunkumų jį planuojant, nes dažnai sunku numatyti, kaip iš tikrųjų bus pasiekti rezultatai. Todėl projektinės veiklos rezultatas yra ne tik produktas ar paslauga, bet ir išmoktos pamokos, tai yra patirtis, kuri panaudojama ateityje planuojant ir vykdant tolesnius projektus.

PROJEKTO PLANAVIMAS

Planavimo etapas yra vienas iš svarbiausių. Šiame etape nustatomos projekto užduotys, biudžetas ir terminas. Gana dažnai planavimas suprantamas tik kaip darbų planavimas, resursų valdymo, biudžeto sudarymo ir pan.

Visa planavimo technika apima šiuos veiksmus:

• 1) Projekto tikslų apibrėžimas ir jų aprašymas. Gana dažnai projektai prasideda be aiškaus tikslo.
• 2) Technologinių etapų nustatymas. Projektui turi būti parinkta įgyvendinimo technologija, kuri lemia projekto kūrimo etapus. Viena iš tipiškų planavimo klaidų – plano ir technologinio ciklo neatitikimas.
• 3) Technologiniams etapams būtina nustatyti užduočių sąrašą, nurodyti jų ryšius (seką) ir numatomą trukmę (priklausomai nuo priskirtų išteklių).
• 4) Būtina susitarti dėl projektui skiriamų išteklių. Pažymėtina, kad visi įmonės ištekliai turi būti paskirstyti centralizuotai. Gana dažnai planavimo klaida įvyksta dėl to, kad kai kurie riboti ištekliai vienu metu naudojami dviejuose skirtinguose projektuose vienu metu.
• 5) Jei nustatote išteklių kainas, biudžetą taip pat galima gauti automatiškai. Viena iš tipiškų klaidų yra ta, kad biudžetas skiriamas nekreipiant dėmesio į numatomą projekto kainą.
• 6) Rašytinė užduotis, biudžetas ir darbo grafikas sudaro oficialų „Projekto plano“ dokumentą. Gana dažnai, prieš pradedant projektą, kai kurių iš šių dokumentų trūksta, bus aptartos to pasekmės.

Taigi, siekiant sėkmingo projekto planavimo, svarbūs keli veiksniai, į kuriuos reikia atsižvelgti:

• · sprendžiamų užduočių klasė, gatavo produkto kopijų skaičius, darbo pobūdis (kūrimas, kūrimas, palaikymas);
• · darbo plano (gyvenimo ciklo modelio) parinkimas atsižvelgiant į projekto sudėtingumą ir kūrimo komandos galimybes;
• · patirtis dalykinėje srityje ir kūrimo automatizavimo įrankiai;
• · kūrėjų aprūpinimas automatizavimo įrankiais ir technine bei programine baze;
• · užsakovo reikalavimų darbo laikui ir kokybei lygis.

Gerai organizuotame projekte už kiekvieno tikslo įgyvendinimą turėtų būti atsakingas konkretus valdymo organas: projekto vadovas, už visus tikslus (projekto misija), atsakingi vykdytojai už privačius tikslus ir t.t. Tai yra, projekto tikslų medis turi būti atsakingas. sutampa su už projekto įgyvendinimą atsakingo organizacinio padalinio struktūra. Tam yra kuriama vadinamoji atsakomybės patricė, kuri apibrėžia projekto vykdytojų funkcines pareigas ir nurodo darbų, už kurių įgyvendinimą jie yra asmeniškai atsakingi, visuma.

Pagrindinis planavimo tikslas – sukurti projekto įgyvendinimo modelį.

Dažnos planavimo klaidos

Planavimas naudojant neteisingus tikslus. Bet koks projektas savo turiniu yra skirtas problemai išspręsti, konkrečiam poreikiui patenkinti ir pan. Atsižvelgiant į tai, formuluojami tam tikri konkretūs tikslai. Jei problema neaiški ir neaiškiai suformuluota, tuomet galima susidurti su dažna klaida, kai bus priimtas teisingas sprendimas, tačiau tiksliai nežinoma, kokia tai problema.

Norint išvengti tokios situacijos, būtina išsiaiškinti tikrąjį darbo pagrindą: įrašyti – pageidautina dokumentais – problemų ir poreikių, kuriuos būtina išspręsti užbaigus projektą, aprašymą; nustatyti, kaip konkrečių problemų sprendimas atsispindi projekto tikslų ir uždavinių aprašyme. Tik po to galite pradėti planuoti.

Planavimas remiantis nepilnais duomenimis. Panaši situacija būdinga tada, kai reikia planuoti darbus, kurių pradžia, o galbūt ir pats jų įgyvendinimo faktas priklauso nuo testų rezultatų ar ankstesnių etapų sėkmės/nesėkmės.

Panaši situacija dažnai susiklosto informacinių sistemų kūrimo ir pritaikymo projektuose. Klientas turi nenugalimą norą kuo greičiau gauti gatavą įrankį. Tačiau jis turi tik miglotą supratimą apie pasirinktos programinės įrangos galimybes ir ką jis nori automatizuoti. Kita vertus, programinės įrangos tiekėjai labai mažai žino apie faktinius valdymo procesus (funkcinius, informacinius, organizacines struktūras) kliento organizacijoje. Ir tik pradėjus įgyvendinti projektą, prasideda abipusio informavimo ir mokymo procesas. Paaiškinus teiginį, žymiai, kartais net kelis kartus, padidėja darbo apimtis ir pasikeičia jo tikslai bei sudėtis.

Planavimas vykdomas dalyvaujant tik planuotojams. Tokia planavimo organizacija gali atnešti didelių nuostolių, nes neatsižvelgiama į svarbius veiksnius. Paprastai pamirštamos iš pažiūros nereikšmingos detalės ar aplinkybės, kurių nesilaikymas vis dėlto gali privesti prie didžiulių nuostolių. Todėl planuojant turėtų būti įtraukti ir atsakingi už konkrečius projekto darbus, atsakingi už projekto finansavimą, tiekimą ir pan. Jau nekalbant apie psichologinius plano įgyvendinimo aspektus, kurių kūrime konkretūs atlikėjai nedalyvavo.

Planavimas neatsižvelgiant į ankstesnę patirtį. Net ir turint geriausius įvertinimus, nepasinaudojus ankstesne patirtimi įgyvendinant panašius projektus, gali būti padaryta rimtų planavimo klaidų.

Planuoti išteklius neatsižvelgiant į jų prieinamumą. Tai visų pirma susiję su tam tikros kvalifikacijos darbo ištekliais ir galimybe atvykti tam tikru laiku į tam tikrą vietą atlikti projekto darbų. Kita bėda, jei ta pati specialistų grupė planuojama keliuose vienu metu vykdomuose projektuose.

Planuoti neatsižvelgiant į motyvaciją. Paprastai prie projektų pritraukiami atlikėjai iš funkcinių padalinių, kurie turi savo. Vadovybė, savi tikslai ir konkrečios užduotys ir, žinoma, sava atlygio forma, kuri dažniausiai neturi nieko bendro su projekto tikslais ir uždaviniais. Todėl atlikėjai nejaučia projektinio darbo atsakomybės ir svarbos be tinkamų paskatų savo veiklos rezultatams. Tačiau projekto vadovas neturi pakankamai teisių stimuliuoti atlikėjus ir negali sudaryti finansinio skatinimo biudžeto pagal projekto rezultatus.

Per daug detalių planavimas. Kai projektas planuojamas per daug detaliai , problemų kyla analizuojant, planuojant ir stebint jo būseną – pavyzdžiui, kas baigta ir kas vėluojama. Be to, sunku efektyviai valdyti daugybę išteklių, nustatyti laiko vėlavimus, įvertinti išlaidas ir sudaryti realistiškus, valdymo tikslais priimtinus tvarkaraščius. Per didelis detalumas atsižvelgiant į veiksnius lemia būtinybę išspręsti daugybę konfliktų, dažnų pokyčių, nuolatinio derinimo su kitais tuo pačiu metu vykdomais projektais. Tačiau per didelis išplėtimas taip pat gali sukelti problemų dėl valdymo praradimo. Aukso vidurio reikia tada, kai projekte planuojami tik tie parametrai, kuriuos galima ir reikia kontroliuoti.

Ko reikia norint išvengti planavimo klaidų (keli patarimai):

• · projektui turi būti suformuluotas spręstinų problemų sąrašas;
• · į pagrindinį projekto tikslą (misiją) turi būti atkreiptas visų dalyvių dėmesys;
• · turi būti nustatyta rizika ir, jei įmanoma, neįtraukti nelaimingi atsitikimai;
• · būtina užtikrinti, kad projekto strategija būtų įgyvendinta ir atitiktų biudžeto, laiko ir apimties apribojimus (buvo atlikta PCTS galimybių analizė: P – Performance, C – Cost, T – Time, S – Scope. Išlaidos yra a lygmens vykdymo funkcija P, laikas T ir turinys, darbo apimtis S);
• · teigiamų projekto įgyvendinimo „už ir prieš“ analizės rezultatų buvimas (buvo atlikta jėgos lauko analizė, kurią sudaro veiksnių, galinčių palengvinti ir trukdyti įgyvendinti projektą, aprašymas ir kiekybinis įvertinimas );
• · galutinis rezultatas turi būti aiškus visiems projekto komandos nariams;
• · projektinės veiklos rezultatų vertinimo rodikliai turėtų pakankamai tiksliai įvertinti situaciją. Patartina sukurti vidines veiklos vertinimo skales pagal darbo pobūdį.

Projekto tikslų apibrėžimas

Tikslų nustatymas pirmiausia reiškia, kad projektas turi prasidėti tikslo pareiškimu. Šiuo atveju tikslas turi būti užfiksuotas raštu išmatuojamų rodiklių forma.

Problemos formulavimo etapas, šis etapas vykdomas pagal konsultavimo sutartį, t.y. etapo apmokėjimas yra pagrįstas laiku. Dėl užduoties neapibrėžtumo neįmanoma iš anksto planuoti jos kainos. Scenos kaina yra maždaug lygi 10% visų darbų kainos.

Pagrindinis etapo produktas – dokumentas „Problemos pareiškimas“ (Produkto vizija).

Šiame dokumente turėtų būti apibrėžtas projekto tikslas ir pateiktas pagrindinių reikalavimų sąrašas be išsamaus paaiškinimo. Svarbus kriterijus: nepaisant to, kad nėra išsamaus aprašymo, sąrašas turi būti pritaikytas statistiniam darbo intensyvumo įvertinimui su standartiniu nuokrypiu (rizika) priimtino diapazono ribose.

Remiantis „Problemos pareiškimu“, reikia parengti „Ekonominio pagrindimo“ dokumentą.

Šiame dokumente turi būti pateiktas statistinis darbų darbo intensyvumo (kaštų) įvertinimas. Kita vertus, reikia atlikti įgyvendinimo ekonominio poveikio analizę.

Analizei naudojama panašių projektų darbo intensyvumo (efektyvumo) statistika. Nesant šios statistikos, įverčių klaidos yra neišvengiamos, tokiu atveju turėtumėte pabandyti gauti statistiką, pagrįstą prototipų kūrimo / demonstravimo rezultatais.

Rizikos vertinimas turi būti išreikštas galimo darbo intensyvumo pertekliaus forma (pesimistinis vertinimas). Būtent nuo šio įvertinimo ir reikėtų vadovautis nustatant bendrą produkto darbo intensyvumą (kainą).

Dėl to „Problemos pareiškime“ turime neaiškiai suformuluotą užduotį, o „Ekonominiame pagrindime“ – sąmatą. Rizika dėl neaiškių reikalavimų turi būti įvertinta pesimistiškai. Etapo užbaigimo sąlyga: šalių „Problemos pareiškimas“ ir „Ekonominis pagrindimas“ pasirašymas.

Išteklių valdymas ir planavimas

valdymo projekto planavimo resursas

Išteklių valdymas yra viena iš pagrindinių projektų valdymo posistemių. Apima išteklių, dažniausiai darbo ir logistikos, planavimo, pirkimo, tiekimo, paskirstymo, apskaitos ir kontrolės procesus. Išteklių valdymo uždavinys – užtikrinti optimalų jų panaudojimą galutiniam tikslui – projekto rezultato su suplanuotais rodikliais formavimui pasiekti.

Materialiniai ir techniniai ištekliai – tai žaliavos, medžiagos, konstrukcijos, komponentai, energijos ištekliai, technologiniai ištekliai ir kt.

Darbo ištekliai yra tie, kurie tiesiogiai dirba su materialiniais ir techniniais ištekliais.

Projekto materialinių išteklių valdymas iš esmės prasideda priešinvesticiniu etapu, kai planavimo fazėje rengiama galimybių studija, apibrėžiami resursų reikalavimai ir galimybė juos pateikti. Praktika rodo, kad bet kuriuo metu ištekliai yra riboti, todėl pagrindinės išteklių valdymo užduotys yra šios:

• 1. Optimalus išteklių planavimas
• 2. Logistikos valdymas, įskaitant:
  • · išteklių pirkimų valdymas;
  • · išteklių paskirstymo valdymas.

Išteklių sąvoka yra susijusi su „darbo“ sąvoka, nes ištekliai yra susiję ne su projektu kaip visuma, o su konkrečiu darbu, atliekamu suplanuota seka, atitinkančia projekto darbo grafiką.

Pirkimų ir prekių planavimas ir organizavimas - pirmasis projekto išteklių valdymo etapas. Susideda iš etapų, įskaitant tiekėjų atranką, užsakymų pateikimą ir prekių stebėjimą.

Planavimo etape atliekama subalansuota darbų paketų ir sunaudotų išteklių analizė, atsižvelgiant į apribojimus ir prognozuojamą jų paskirstymą pagal išteklių poreikio grafikus. Projekto resursų planavimas yra pagrindas laiku nustatyti resursų poreikį ir numatyti galimybę numatyti išteklius resursų pirkimo sutarčių sudarymui, išteklių tiekimo planavimui, taip pat jau nupirktų išteklių paskirstymo projekto darbams pagrindas.

Kaip pagrindinis projekto valdymo komponentas, išteklių planavimas apima keletą komponentų, įskaitant:

• · darbų paketų ir išteklių, skirtų projekto tikslams pasiekti, kūrimas ir subalansuota analizė;
• · išteklių paskirstymo sistemos sukūrimas ir atsakingų vykdytojų paskyrimas;
• · darbų eigos stebėjimas – planuotų darbų parametrų palyginimas su faktiniais ir korekcinių veiksmų rengimas.

Ištekliai veikia kaip projekto darbo komponentai, įskaitant atlikėjus, energiją, medžiagas, įrangą ir kt. Atitinkamai išteklių poreikio funkcija gali būti susieta su kiekvienu darbu, o viso projekto išteklių poreikius galima apskaičiuoti naudojant planavimo metodus ir suderinimo metodai gali užtikrinti atitikties poreikius, prieinamumą arba galimybę teikti išteklius.

Iš esmės, planuojant patenkinti projekto veikloms reikalingus išteklius, reikia atsižvelgti į vieną bendrą taisyklę: bendra poreikių apimtis kiekvienai išteklių rūšiai kiekvienu projekto gyvavimo ciklo momentu turi būti ne mažesnė už bendrą apimtį. šių išteklių prieinamumą tuo metu, atsižvelgiant į atsargas.

Projekto išlaidų įvertinimas

Priklausomai nuo projekto gyvavimo ciklo etapo ir vertinimo tikslo, naudojami įvairūs projekto kainos įvertinimo tipai ir metodai. Atsižvelgiant į vertinimų tikslus, tokių vertinimų tikslumas taip pat skiriasi. Detaliau nenagrinėsime, bet reikia nepamiršti, kad didžiausia klaida, žinoma, atsiranda projekto stabilizavimo stadijoje, kai yra nustatomos ir taisomos tam tikros versijos klaidos, taip pat gali būti, kad viskas, kas yra buvo atliktas nebuvo tinkamai įgyvendintas (technologine prasme), bet tai jau reiškia neraštingą dizainą.

Norėdami įvertinti projekto kainą, turite žinoti išteklių, sudarančių projektą, kainą, laiką, kurio reikia darbui atlikti, ir šio darbo kainą.

Taigi sąnaudų apskaičiavimas prasideda nuo projekto išteklių ir darbo struktūros nustatymo. Šios užduotys sprendžiamos kaip projekto planavimo dalis, o šio proceso rezultatus turėtų gauti išlaidų įvertinimo modulis. Projekto kainą lemia ištekliai būtinas darbui atlikti.