Projekto planas. Projekto planavimas. Pagrindinės sąvokos. Kaupiamosios rizikos skaičiavimo metodas – tai rizikos veiksnių, galinčių trukdyti gauti planuojamas pajamas, įvertinimo metodas. Sudarant diskonto normą šiuo metodu, kaip pagrindas yra nerizikinga norma

Planavimas yra pagrindas, ant kurio yra statomas bet koks projektas. Ir kuo jis stipresnis, tuo didesnė tikimybė, kad projektas bus sėkmingas. Tam yra sukurtas projekto valdymo planas, kuris susideda iš trijų blokų: veiklos (tikslai, projekto koncepcijos, išteklių paskyrimai ir kt.), užduotys ir resursai (žmonės, įranga, pinigai ir kt.).

Kas yra projekto valdymo planas?

Projekto valdymo planas – tai dokumentas, kuriame yra visi projekto elementai: nuo veiklos ir išteklių iki sėkmės ir rizikos vertinimo kriterijų. Kurdamas šį planą, projekto vadovas stengiasi aprėpti visą projektą nuo inicijavimo iki uždarymo.

Planas yra svarbiausias dokumentas kuriant projektą – suinteresuotųjų šalių įtraukimo lygmeniu. Kaip projektas negali būti įgyvendintas be suinteresuoto asmens dalyvavimo, projektas žlugs be gerai apgalvoto valdymo plano. Tokie dokumentai kaip išlaidų valdymo planas, terminai, kokybė, rizika, ištekliai ir kt. yra didesnio valdymo plano dalys.

Tradiciniame projektų valdyme planas numato apribojimus visose penkiose fazėse: pradžios, planavimo, vykdymo, stebėjimo ir užbaigimo. Agile projektų negalima planuoti iki galo dėl darbo su judriu modeliu pobūdžio. Todėl planai rengiami ir tvirtinami per visą projekto gyvavimo ciklą.

Paprastai projekte yra du valdymo planai:

1. bazė— patvirtinta vadovybės (kliento). Tai lemia užduočių sėkmę, kontroliuoja laiką ir kokybę.
2. darbininkas- skirtingai nei ankstesniame, projekto vadovas atlieka jo pakeitimus pagal naują informaciją ar užduotis.

Kam tai?

Geras planas turėtų atsakyti į pagrindinius klausimus:

• Kodėl?— Kokią problemą sprendžia projektas, kokia jo vertė? Kodėl projektas remiamas?
• Ką?— Kokie pagrindiniai projekto produktai (pristatymai)? Ką reikia padaryti norint sėkmingai užbaigti?
• PSO?— Kas dalyvaus projekte ir už ką bus atsakingas kiekvienas dalyvis? Kokiu formatu jie bus organizuojami?
• Kada?– Koks projekto terminas? Kada bus pasiekti pagrindiniai etapai?

Gairės yra projekto įvykis (pavyzdžiui, perėjimas prie naujos iteracijos).

Projekto valdymo plano tikslai yra šie:

Pagrindiniai projekto valdymo plano komponentai

Pagal vieną šabloną planų kurti nepavyks, bet yra pagrindinių elementų rinkinys, kurį žinant, nesunku sukurti būsimo projekto karkasą:

• trumpas plano aprašymas- pora pastraipų apie pagrindinius projekto elementus, kurie atskleisti plane.
• strateginis ir organizacinis derinimas- tai apima suinteresuotųjų šalių ir organizacijos tikslų, kurie bus remiami įgyvendinant projektą, analizės rezultatus.
• projekto apimties apibrėžimas- šią pastraipą sudaro šie elementai: užduotis ir tikslai, laukiami rezultatai, priemonės PBS ir WBS. Skyriuje taip pat svarbu nurodyti kokybės specifikacijas – prekės ar paslaugos efektyvumo kriterijus kliento požiūriu.

PBS (produktų suskirstymo struktūra) yra projekto rezultatų analizės, dokumentavimo ir komunikacijos įrankis. PBS yra gaminiais pagrįsto planavimo metodikos dalis (vienas iš pagrindinių PRINCE2 projektų valdymo modelio metodų).

WBS (darbo skirstymo struktūra) – hierarchinis suskirstymas projektavimo darbaiį smulkesnes užduotis (operacijas) iki tokio lygio, kai aiškūs darbų atlikimo būdai, yra vertinimo ir planavimo galimybė.

• galimybių vertinimas ir nenumatytų atvejų planai- pateikiamas projekto ekonominio, techninio ir organizacinio pagrįstumo įvertinimas, rizikos nustatymas ir analizė, siūlomi veiksmų planai kritinėse situacijose rizikos veiksniams pašalinti.
• apribojimai- žinomų aplinkos ar valdymo nustatytų apribojimų sąrašas (fiksuotas biudžetas, išteklių trūkumas ir pan.).
• reikalavimus projekto komanda — projekto komandos organizavimo, dalyvių vaidmenų ir atsakomybės apibrėžimas. Čia atsiranda mokymo reikalavimai.
• medžiagų reikalavimai- apima vietos elementus, programinė įranga, įranga ir kiti ištekliai projektui užbaigti.
• tvarkaraštis ir etapai- Šiame skyriuje apibrėžiami projekto veiklos etapai ir tvarkaraštis, įskaitant tris pagrindinius elementus: pristatymus (darbo rezultatus), datas arba trukmę ir kritines priklausomybes.
• biudžetas (apytikslis)- numatomos išlaidos paprastai skirstomos į tris tipus: kapitalas (sandėlio pirkimas produkcijai laikyti), eksploatacinės medžiagos (savaitinis medžiagų pirkimas pirkimui) ir darbo jėgos (atlyginimų mokėjimas komandos nariams)
• Rizikos valdymas— išsamus rizikos valdymo proceso aprašymas: nuo identifikavimo (protų šturmo, interviu, SSGG analizės) iki stebėjimo sistemos parinkimo (pro- arba reactive).
• pokyčių valdymas- panašus į ankstesnę pastraipą, susijęs tik su galimais pakeitimais (o jų bus daug). Čia verta užsirašyti pakeitimų atlikimo algoritmą, valdymo metodikas (ADKAR, AIM ir kt.), pakeitimų sėkmės tikimybės skaičiavimo formulę ir kt.
• komunikacijos valdymas— tai susiję ir su komanda, ir su suinteresuotosiomis šalimis. Šiame skyriuje projekto vadovas turėtų aprašyti komunikacijos sistemą, kuri bus naudojama, ir kanalus, kuriais projekto vykdymo dokumentacija perduodama projekto šalims.
• investicijos- čia galite gauti bet kokius dokumentus: nuo individualių užrašų iki pristatymų ir sertifikatų.

Plano skyrių sąrašas papildomas priklausomai nuo konkretaus projekto specifikos.

Pagrindiniai ir darbo planai projekto

Dirbdami su projektu, projekto vadovas, komandos nariai ir Suinteresuotosios šalys dirba su dviejų tipų planais:

• bazė- pirminis, stabilus, patvirtintas užsakovo ar kito iš anksto nurodyto asmens, suderintas su visomis suinteresuotomis šalimis.
• darbininkas- bazinio plano versija, kurioje pateikiami terminų, sąnaudų ir kitų projekto parametrų pokyčiai.

Projekto kūrimo metu galite palyginti pagrindinius ir darbo planus, suprasti, kur darbas „smunka“, o kur atvirkščiai – projektas baigiamas greičiau (taupiau) nei planuota. Retais atvejais projekto eigoje atliekami pagrindinio tvarkymo plano pakeitimai.

Darbo skiltyje Ganto diagrama leidžia pamatyti skirtumą tarp pagrindinio ir darbo plano
(mėlyna - Bendras laikas, raudona – uždelstos užduotys, žalia – laiku atliktos užduotys)

Projekto valdymo plano rengimas

Kaip ir su pagrindiniais projekto valdymo plano elementais, nėra vieno tinkamo būdo jį parengti.

Sukūrėme paprastą nuoseklią plano rašymo procedūrą, kurią sudaro 16 punktų:

1. Nustatykite plano rengimo pradžios sąlygas- svarbu suprasti, su kuo jį kursite (vieni, dalyvaujant vadovybei, dalininkams), kur ir kada ir t.t. Svarbu numatyti metodus (pavyzdžiui, smegenų šturmą) ir programinę įrangą (pvz., Microsoft Visual Studio), kuri bus naudojama kuriant planą – tai sutaupys daug laiko ir supaprastins užduotį.
2. Nustatykite projekto pradžios sąlygas- čia aprašomas projekto turinys, rezultatams keliamų reikalavimų sąrašas ir jo valdymas. Pavyzdžiui, buvo sumanytas projektas parduoti aukštos kokybės neoninius suktukus su superherojų atspaudais. Sėkmingai įgyvendinus metinį projektą, per 12 mėnesių nuo projekto pradžios turi būti parduota 100 000 vienetų prekių, o po to vyks verslo pardavimas. Projekto valdymo struktūrą sudarys bendras projekto vadovas centriniame biure ir atitinkami padaliniai projekto regioniniuose biuruose.
3. Apibrėžkite veiksmus, kurių reikia imtis tiems, kuriuos atliks projekto komanda, ir užsakomųjų paslaugų teikimas.
4. Sukurkite projekto WBS, suskaidydami jį į mažesnius, valdomus gabalus. Tai panašu į Agile metodą, kai visas kodas yra padalintas į daug mažų darbo dalių.
5. Parašykite užduočių rinkinį, kad atliktumėte kiekvieną WBS dalį, ir sukurkite jų priklausomybę. Taigi, regioninio sandėlio, skirto suktukų laikymui, pirkimo ir įrengimo užduotį galima atlikti tik išanalizavus rinką ir pardavus tam tikrą prekių kiekį konkrečioje vietovėje.
6. Nustatyti reikalingos kompetencijos atlikti kiekvieną užduotį.Čia svarbu ne pritaikyti reikiamas žinias ir įgūdžius taip, kad jie atitiktų potencialius projekto dalyvius, o orientuotis į „idealius“ reikalavimus.
7. Apskaičiuokite laiką ir išlaidas užduotims atlikti.
8. Suprojektuoti projektą.Ši technika tinkama tik bakalėjos verslui, todėl ją lengva parodyti diagramomis (pavyzdžiui, Ganto diagrama).
9. Sukurkite projekto tvarkaraštį- pradžios, tarpinės, pabaigos datos. Pavyzdžiui, supaprastinta schema: lapkričio 1 d. pradedamas projektas, gruodžio 1 d. – Naujųjų metų išpardavimų pradžia, gruodžio 31 d., susumavus naujametinių pardavimų rezultatus, sausio 15 d. specializuota linija Valentino dienai, vasario 20 d., apibendrinant ir kt.
10. Apskaičiuokite projekto kainą(mūsų atveju, kiek kainuos sėkmingai parduoti 100 000 suktukų ir parduoti verslą).
11. Nurodykite kokybės reikalavimus(pavyzdžiui, nustatyti suktukų gamybos kokybės standartai).
12. Paskirkite konkrečius žmones, atsakingus už užduotis.Čia pravers 6 punktas, su kurio sąrašu susiesite komandos narių kompetencijas.
13. Suplanuokite darbo su suinteresuotosiomis šalimis formatą- pasirinkti komunikacijos kanalus, nustatyti jų įsitraukimo į darbą su projektu laipsnį ir kt.
14. Apskaičiuokite riziką (pavyzdžiui, naudodami kaupiamojo metodo formulę). Mūsų pavyzdyje su suktukais tai gali būti banalus rinkos perpildymas, ekspeditorių vykdomas sutarties sąlygų pažeidimas ir pan. Rizikos analizėje naudokite ankstesnių pastraipų duomenis.
15. Užsirašykite projekto apribojimus ir, atsižvelgdami į juos, įveskite duomenis į projekto valdymo planą. Pas mus suktuko detalės pristatomos iš Kinijos, surinkimas vyksta Ukrainoje ir tai jau riboja griežtos medžiagų kokybės kontrolės ir greito pakeitimo galimybę.
16. Dar kartą peržiūrėkite visus plano punktus pasiekti zen. Belieka galutinai sudėlioti pirkinių sąrašą ir jiems keliamus reikalavimus, derinti su suinteresuotomis šalimis – ir jūs turite savo rankose paruoštas planas projektų valdymas.

Kaupiamosios rizikos skaičiavimo metodas – tai rizikos veiksnių, galinčių trukdyti gauti planuojamas pajamas, įvertinimo metodas. Kuriant diskonto normą už šis metodas Nerizikinga grąžos norma imama kaip pagrindas, prie jos pridedama investicijų į projektą ar įmonę rizikos grąžos norma.

Vladislavas Gagarskis, kaip pavyzdį, pateikia tokią tvirtinimo schemą:

1. Projekto komandos vadovai bendrai parengtą planą siunčia projekto vadovui.
2. Vadovas tvirtina projekto valdymo planą arba, atsiradus klaidų, pasirūpina, kad būtų atlikti pakeitimai.
3. Projekto vadovas patvirtintą planą perduoda projekto komandos vadovams tolimesniam įgyvendinimui.

Bet ši schema labiau tinka paruoštoms komandoms kurie vieną po kito vykdo kelis projektus arba pakeitę veiklos profilį. Tiems, kurie „nuo nulio“ nusprendė parašyti ir patvirtinti projekto valdymo planą, technika netiks. Tokiais atvejais pagrindinis projektas projekto vadovo teikimu patvirtina įmonės ar projekto vadovas (užsakovas).

Verdiktas

ne gyvenimo gelbetojas.

Iš pradžių tai bus deklaracija be priemonių jai įgyvendinti. Priemonė gali tapti su juo projektai / užduotys / subužduotys ir atsižvelgiant į pinigus, laiką ir atsakingus žmones tiesiai atliekant užduotis. Tai geriausias būdas organizuoti vizualinį įmonės darbą, kur ryšys tarp pradinio lygio ir darbo planų yra akivaizdus kiekvienam.

Tačiau planas yra pradžia, kuri nulems 50% projekto sėkmės.

Planavimas yra kiekybinio ir kokybinio pobūdžio tikslų kūrimo ir priėmimo procesas bei būdų, kaip juos efektyviausiai pasiekti, nustatymas. Šie nustatymai, dažniausiai sukurti tikslų medžio pavidalu, apibūdina trokštamą ateitį ir, jei įmanoma, yra skaitine forma išreiškiami rodiklių rinkiniu, kuris yra esminis šio valdymo lygmens.

Planavimo poreikį lemia daugybė priežasčių. Reikšmingiausi iš jų: ateities neapibrėžtumas, plano koordinavimo vaidmuo, ekonominių pasekmių optimizavimas.

Iš tiesų, jei projekto ateitis būtų absoliučiai nulemta, nereikėtų nuolat kurti planų, tobulinti jų rengimo ir struktūrizavimo metodų. Tai rodo, kad pagrindinis bet kokio plano sudarymo tikslas yra ne nustatyti tikslius skaičius ir gaires, nes tai iš principo neįmanoma, o nustatyti tam tikrą „koridorių“ kiekvienai iš svarbiausių sričių, kurioje tas ar kitas rodiklis gali būti nustatytas. skirtis.

Plano koordinuojančiojo vaidmens prasmė yra ta, kad gerai struktūrizuotų tikslų buvimas disciplinuoja tiek numatomą, tiek esamą veiklą, sujungia jas į tam tikrą sistemą ir leidžia įmonei dirbti be didelių trikdžių.

Paskutinė planų rengimo priežastis yra ta, kad bet koks sistemos veiklos neatitikimas reikalauja finansinių (tiesioginių ar netiesioginių) išlaidų jam įveikti. Tokio neatitikimo tikimybė yra daug mažesnė, jei darbai atliekami pagal planą; be to, neigiamos finansinės pasekmės yra ne tokios reikšmingos.

Planavimas leidžia užtikrinti aukštą tikslų pasiekimo laipsnį ir didelę tikimybę, remiantis sistemingu sprendimų rengimu. Taigi tai yra būtina sąlyga veiksmingam projekto įgyvendinimui. Projekto planas yra pagrindinė projekto dalyvių integravimo priemonė. Projekto plano sudarymas ir suderinimas užtikrina, kad visi dalyviai geriau suprastų savo užduotis ir pareigas.

Projekto plane detaliai analizuojama, kaip subalansuoti projekto išlaidų, įgyvendinimo laikas, grafikas ir kokybė.

Projekto planavimo etape išsprendžiamos šios užduotys:

• projekto tikslų ir rezultatų paaiškinimas ir patikslinimas;
• projekto sudėties ir apimties patikslinimas;
• realaus projekto (ar atskirų jo etapų) grafiko ir biudžeto sudarymas;
• projekto išteklių poreikio išaiškinimas, projekto (arba atskirų projekto etapų) išteklių paramos planas;
• rizikos įvertinimas ir atsako į riziką plano rengimas;
• sąveikos tvarkos projekto komandoje, taip pat tarp projekto komandos ir išorinės aplinkos išaiškinimas;
• projektų valdymo procedūrų kūrimas ir tobulinimas;
• plano patvirtinimas pagrindinių projekto dalyvių;
• projekto plano tvirtinimas.

Išplėsta projekto valdymo plano struktūra

Pagrindiniai planavimo žingsniai

Tikslų formavimas

Planuojant nustatomos dvi tikslų grupės.

Formalūs tikslai yra veiklos naudingumo ir projekto būklės vertinimo kriterijus, kuris išplaukia iš sprendimus priimančių asmenų veiklos motyvacijos.

Tikri tikslai atspindi būdus, kaip pasiekti formalius tikslus (gaminti gaminius, jų kokybę ir kiekį, reikalingus išteklius, kokybę ir kiekį).

Problemos analizė

Problemos analizė apima šiuos veiksmus:

• faktinės būklės nustatymas (padėties analizė);
• padėties prognozė;
• problemų identifikavimas priešpriešinant tikslų sistemą ir situacijos analizės bei prognozavimo rezultatus;
• problemos struktūrizavimas.

Struktūrizuojant problemas jas pirmiausia reikia suskirstyti į dvi grupes:

• Išorinio pobūdžio problemos, kurių sprendimui projekto komanda negali turėti įtakos per visą planavimo laikotarpį.
• Problemos yra vidinės, kurių sprendimas priklauso nuo efektyvaus projektų valdymo.

Tada antrajai kategorijai priskirtas problemas reikia suskirstyti į dvi klases:

• Problemos, kurių sprendimas nereikalauja didelių finansinių ir laiko sąnaudų. Šios klasės problemos išsprendžiamos einamojo arba veiklos planavimo metu.
• Problemos, kurioms išspręsti reikia ilgo laiko ir nemažo finansavimo.

Į šias problemas atsižvelgiama ilgalaikio planavimo ir prognozavimo procese.

Ieškokite alternatyvų

Alternatyvos yra vienas kitą paneigiantys sprendimai.

Prognozavimas vaidina svarbų vaidmenį įgyvendinant ilgalaikius projektus. Galima išskirti dviejų tipų prognozes.

• Įtakos prognozės duoti supratimą, kokius rezultatus sukels kiekvienas iš galimų sprendimų, t.y. kaip šį sprendimą turėti įtakos projekto vykdymui.
• Plėtros prognozės situacijos taikomos rodikliams išorinė aplinka, kuriam sprendimus priimantys asmenys nagrinėjamu laikotarpiu negali daryti įtakos.

Alternatyvų vertinimas

Alternatyvų vertinimas jų priimtinumo, efektyvumo ir rizikos požiūriu yra sprendimų priėmimo pagrindas. Optimalia laikoma legali ir praktiškai įgyvendinama alternatyva, leidžianti kuo labiau priartėti prie užsibrėžtų realių tikslų pasiekimo esant esamiems apribojimams – resursams, laikui, darbui ir kt.

Įgyvendinant projektą planas turėtų būti atnaujintas atsižvelgiant į esamą būklę ir padarytus pakeitimus. Taigi projekto planas tampa pagrindu vertinant pažangą, padarytą įgyvendinant šį projektą.

Siekdamas užtikrinti projekto plano pagrįstumą ir tikslumą, projekto vadovas turi išspręsti šias užduotis.

1. Pagrindinių projekto dalyvių įtraukimas į planavimo procesą, atsakomybės už numatytus parametrus užtikrinimas.
2. Pasiekti sutartą supratimą apie projekto struktūrą ir apimtį bei išteklių poreikius su užsakovu ir pagrindiniais projekto dalyviais.
3. Planavimas organizacinė struktūraįgyvendinant projektą ir užtikrinti, kad projektui būtų pritraukti reikiami ištekliai.
4. Susitarkite dėl pagrindinių dalyvių atsakomybės už rezultatus.

Įsivaizduokite, kad pirmą kartą susiduriate su poreikiu sukurti svetainę. Kaip nieko nepamiršti pakeliui ir jau pradiniame etape įvertinti finansines ir darbo sąnaudas? Žemiau dalinuosi savo patirtimi rengiant paslaugų įmonės rinkodaros svetainės kūrimo projekto planą.

Yra paprastesnių variantų, pavyzdžiui, nukreipimo puslapio kūrimas naudojant LP generatoriaus paslaugą ar panašiai. Negalite apsiriboti vienu puslapiu ir sukurti visavertę svetainę naudodami svetainių kūrimo priemonę. Tai darbiniai variantai, nuo jų nieko neatkalbinu. Viskas priklauso nuo svetainės tikslų ir atitinkamai nuo jūsų reikalavimų. Siūlau kelių puslapių SEO orientuotos svetainės projekto planą nenaudojant svetainių kūrimo priemonės.

Pagrindinių darbo blokų apibrėžimas

Svetainės kūrimo užduotis apima įvairius etapus, kuriuose dalyvauja įvairūs specialistai. Pradedu nuo pagrindinių didelių blokų nustatymo. Šiuo metu planas atrodo taip:

1. Klasikinė rinkodara: produkto, konkurentų pažinimas, USP kūrimas
2. Semantikos parinkimas
3. Svetainės struktūros kūrimas
4. prototipų kūrimas
5. Dizainas
6. Išdėstymas
7. Programavimas
8. Testavimas
9. paleisti

Vaizdas darosi aiškesnis, tačiau smulkmenų neužtenka, todėl dideles užduotis skaidau į smulkesnes.

Apytikslis puslapių skaičius ir tipai

Norėdami apskaičiuoti projekto planą, sudarau orientacinį svetainės puslapių sąrašą ir užduočių, kurių reikia šiam puslapiui, tipus. Tai man padeda skaičiuoti darbo valandas atliekant užduotis. Tikėtina, kad darbo eigoje puslapių sąrašas keisis, tačiau šiame etape jo pakaks skaičiavimams. Lentelė atrodys maždaug taip.

Puslapiai (kaukės)	Puslapių skaičius	Surinkite SA	TK iš SEO specialisto	Tekstas	Prototipas	Dizainas	Išdėstymas	Programavimas
namai	1	1	1	1	1	1	1	1
korporatyviniams klientams	1	1	0	1	1	1	1	1
Paslaugos (skilties puslapis)	1	1	1	1	1	1	1	1
Paslaugų skyrius	3	3	3	3	2	2	2	2
Paslaugų poskyris	7	7	7	7	1	1	1	1
Klausimai ir atsakymai (DUK)	1	0	1	0	1	1	1	1
Vieno straipsnio puslapis	X	X	X	X	1	1	1	1
Kontaktai	1	0	1	1	1	1	1	1
Apie įmonę	1	0	1	1	1	1	1	0
Kainos	1	0	1	0	1	1	1	1
	17	13	16	15	11	11	11	10

Užduočių sąrašo detalizavimas

Darbo sąnaudoms apskaičiuoti stengiuosi užduotis suskirstyti taip, kad kiekvienai užduočiai būtų galima priskirti po vieną. atsakingas specialistas. Iš karto prie užduočių sąrašo pridedu stulpelį „Rangovas“ ir numatomą valandų skaičių užduočiai atlikti.

Užduotis	Vykdytojas	Laikrodis	komentuoti
Pagrindinių paslaugų ir konkurentų nustatymas	Rinkodaros specialistas	6	Svarbu suprasti svetainės apimtį. Ištyrus konkurentus, sąrašą galima koreguoti.
Ekspresinė konkurentų svetainių analizė	Rinkodaros specialistas	24	Atsižvelgiant į rinkos išmanymą ir projekto sudėtingumą, laikas gali būti koreguojamas.
USP pranašumų ir plėtros pareiškimas	Rinkodaros specialistas	8	Remdamiesi informacija apie įmonę ir konkurentus, parengiame pagrindinį pasiūlymą ir trumpai atsakome į klausimą: „kodėl verta pirkti iš mūsų“.
Pradinis sklypo struktūros planavimas	Rinkodaros specialistas	2	Tik tada galima sudaryti pagrindinę svetainės struktūrą, kuri šiame etape atrodo kaip puslapių sąrašas.
Semantinės šerdies rinkimas ir segmentavimas	SEO specialistas	26	SEO specialistas surenka visą užklausų sąrašą ir sujungia jas į semantines grupes. Mano skaičiuojamas laikas yra apie 2 valandas kiekvienam preliminarios svetainės struktūros puslapiui (tam, žinoma, aktualus SEO). Jei svetainė jau yra, turėtumėte atsižvelgti į užklausas, kurių svetainė jau yra paieškos rezultatuose.
To derinimas ir patvirtinimas. branduoliai	Rinkodaros specialistas	8	Semantinę šerdį geriau derinti su klientu, kad ateityje nekiltų nesusipratimų.
Svetainės struktūros koregavimas, atsižvelgiant į šeimos branduolį	SEO specialistas	6	SEO specialistų pasiūlymai puslapių sąrašui, navigacijai.
Svetainės struktūros tobulinimas ir derinimas, atsižvelgiant į šeimos branduolį	Rinkodaros specialistas	4	Šiame etape gauname svetainės skeletą. Be to, manau, kad yra tipiškų puslapių. Pavyzdžiui, kad visi skirtingų paslaugų puslapiai būtų pagaminti pagal tą patį šabloną.
Pagrindinės turinio SEO gairės puslapiams pagal puslapius	SEO specialistas	8	Kad nereikėtų taisyti prototipų ar net baigtų puslapių, SEO pageidavimus rekomenduoju gauti jau šiame etape. Ši pastraipa yra apie blokus puslapyje. 1 puslapyje dedu 0,5 val.
SEO TOR puslapio turiniui	SEO specialistas	30	Šioje pastraipoje kalbama apie rekomendacijas dėl tekstų, kurie turėtų būti puslapiuose. Vienam puslapiui skiriu 2 valandas.
Tekstų rašymas	Tekstų rašytojas / rinkodaros specialistas	90	Jei jums pasisekė rasti geras tekstų rašytojas, tekstų rašymą galite patikėti jam. Dažniausiai paslaugų puslapių tekstai, unikalūs puslapiai, tokie kaip „Apie įmonę“, „404“, „Kontaktai“ ir kt. Pati rašau. Aš skiriu laiką pagal savo standartus, todėl vienam puslapiui skiriu 6 valandas, bet tai gali keistis nuo projekto iki projekto.
Puslapio prototipų kūrimas	Rinkodaros specialistas	82	Taip pat planuoju 6 valandas 1 puslapiui, plius 2 darbo dienas pagrindiniam, nes reikia paruošti maketo maketą, antraštę ir poraštę. Man patogu daryti prototipus lygiagrečiai rašant tekstus.
Projektuotojo techninių specifikacijų parengimas	Rinkodaros specialistas	13	Nors „Axure RP“ prototipai yra gana aprašomieji, yra keletas dalykų, kuriuos dizaineriui reikia skirti, ypač pradžioje. Apibūdinkite stilių spalvų schema. Man patogu siųsti stiliaus pavyzdžius ir diskutuoti žodžiu, kad įsitikinčiau, jog kalbame apie tą patį.
Pagrindinio puslapio dizainas + rekomendacijos prisitaikymui	Dizaineris	16	Kadangi dabar neįmanoma gyventi be svetainės mobiliesiems, patariu jau šiame etape pagalvoti apie adaptacinę versiją. Pasirodė veikianti schema, kai projektuotojas parengia ne kelis projektavimo variantus, o surašo rekomendacijas. Praleidžiama mažiau laiko, o rezultatas toks pats.
Kitų puslapių dizainas + rekomendacijos prisitaikymui	Dizaineris	66	Viename puslapyje skaičiuoju 6 valandas. Kai kur gali būti daugiau, kitur mažiau. Šiuo metu taip pat dėlioju rekomendacijas maketuotojui dėl adaptacinio maketavimo.
Projekto tvirtinimas ir tvirtinimas	Rinkodaros specialistas	14	Maketų tvirtinimas visada užtrunka, ypač kai reikia patvirtinti pirmųjų puslapių stilių ir dizainą. Patariu tam susiplanuoti laiką.
Optimizuotų metažymų ir H1 paruošimas	SEO specialistas	16	Apskritai šį elementą galima įjungti bet kuriuo metu prieš paleidžiant svetainę, tačiau nepamirškite!
Maketavimo ir programavimo techninių specifikacijų parengimas	Rinkodaros specialistas	17	Kadangi svarstau apie paslaugų svetainės variantą, nemanau, kad moduliai yra sunkiai įgyvendinami. Todėl viename puslapyje guliu 1,5 valandos.
SEO rekomendacijos maketavimo ir programavimo etapui	SEO specialistas	6	Vėlgi, norint to neperdaryti, geriau nedelsiant paruošti svetainę, atsižvelgiant į tolesnį reklamavimą paieškos sistemose.
Išdėstymas (pritaikomas)	Rašytojas	104	Viskas priklauso nuo išdėstymo sudėtingumo. Infrastruktūros diegimui, pasiruošimui darbui priimu 2 dienas, 1 lapui – 8 valandas.
Maketo tvirtinimas ir derinimas	Rinkodaros specialistas	24	Negalite įtraukti šio elemento, bet vis tiek turite patikrinti maketą, parašyti pakeitimus ir jį priimti. Priklausomai nuo komandos ir projekto, tai gali užtrukti daug laiko. Todėl rekomenduoju jį išdėstyti projekte.
Programavimas	Programuotojas	80	Skirtingų puslapių surinkimas į baigtą svetainę. TVS modulių išvada, skirta tolesniam svetainės turinio valdymui nedalyvaujant kūrėjui.
Programinės įrangos dalies patvirtinimas ir patvirtinimas	Rinkodaros specialistas	15	Tiesą sakant, atrodo, kad šiai užduočiai neskiriu daug laiko. Be šio etapo 100% neišsiversite, palikite tam laiko.
Testavimas ir derinimas	Rinkodaros specialistas	40	Ši užduotis yra spustelėti visus mygtukus, peržiūrėti visus puslapius, išbandyti visas TVS funkcijas ir patikrinti svetainę skirtingose ​​naršyklėse ir skirtinguose įrenginiuose. Jei projektas nedidelis, tuomet gali pakakti ir pačiam patikrinti, kompleksui įtraukiame testuotojus.
Svetainės kovinės versijos paleidimas	Programuotojas	8	Iki šiol visi patikrinimai buvo atliekami bandymų aikštelėje. Tik dabar pereiname prie atviros svetainės vartotojams.
Analitikos sujungimas + CallTouch + tikslų nustatymas	Rinkodaros specialistas/programuotojas	16	Neprivalomas elementas, kuris pradeda tapti norma, nes be analitikos neįmanoma suprasti, kaip svetainė susidoroja su savo užduotimis.
Rekomendacijos pirminiam SEO optimizavimui	SEO specialistas	8	Atidžiai klausomės, ką mums sako SEO specialistas ir laikomės jo rekomendacijų. Jei svetainė iš pradžių buvo parengta pagal dabartinį planą, tada patobulinimų turėtų būti minimaliai, tačiau robots.txt ir svetainės schemą ruošiame tik dabar.
SEO rekomendacijų įgyvendinimas	Rašytojas/programuotojas	16	Skaičiuoju 2 darbo dienas.
SEO rekomendacijų taikymo tikrinimas bandymų svetainėje	Rinkodaros specialistas	4
SEO rekomendacijų taikymas pagrindinėje svetainėje	Programuotojas	3

Projekto terminų skaičiavimas

Didžioji dalis darbų atliekama, vėliau gautas valandas dažome pagal dieną. Kai kurie etapai vyks lygiagrečiai. Pavyzdžiui, aš pateikiu skaičiavimą, kai prie projekto dirba 1 kiekvienos krypties specialistas, atitinkamai didžiausias darbo valandų skaičius per dieną yra 8 valandos vienam specialistui.

Lentelė didelė, todėl duodu nuorodą į Google skaičiuoklę, kur galima pamatyti baigtą rezultatą.

Pabaigoje pateikiu kiekvieno specialisto darbo sąnaudas. Taigi, žinodami valandos tarifą, galite įvertinti projekto kainą. Lentelė atrodo taip.

Taip pat pridedu bendrą lentelę apie projekto sąlygas.

	Valandos	dienų
Bendras projekto laikas:	760	62
Darbo dienos per mėnesį		20
Projekto terminas (mėnesiais)		3.1

Suprantu, kad 62 dienos nelygu 760 valandų. Skirtumas atsiranda dėl to, kad kai kurias užduotis vienu metu atlieka skirtingi specialistai.

Šis sklypo plėtros planas buvo parengtas remiantis Asmeninė patirtis ir tai nėra vienintelis teisingas pasirinkimas. Tačiau tikiuosi, kad tai bus naudinga kaip atspirties taškas, jei svetainę kuriate pirmą kartą arba, kaip verslo atstovas, planuojate užsisakyti svetainę studijoje ir norite geriau suprasti šį procesą.

Projekto planavimas yra nenutrūkstamas procesas, tobulinamas per visą gyvavimo ciklą, kurio metu Geriausias būdas siekiant užsibrėžtų tikslų ir uždavinių, atsižvelgiant į esamą ir besikeičiančią situaciją. Kompetentingas projekto planas, atsižvelgiant į produkto specifiką, rinkos ypatybes ir tendencijas, vartotojų pageidavimus, riziką ir kitus veiksnius, leidžia išvengti neefektyvių išlaidų net koncepcijos ir kūrimo stadijoje. Toks planavimas ne visada duoda teigiamų rezultatų, tačiau net ir neigiamos išvados yra labai naudingos.

Pirmoji plano rašymo užduotis – nedelsiant paskatinti projekto eigą. Projekto planas turi įtikinti sprendimus priimančius asmenis, kad idėja yra perspektyvi, kad ji pateisins lūkesčius, grafiką, biudžetą ir pan. Jei plėtra nėra įtikinama plano lygmeniu, projektas gali ir nepasiekti pradinio etapo. Ir atvirkščiai - sėkmingas planas iš karto formuoja projekto vadovo reputaciją ir suteikia tvirtą pagrindą pradėti proceso įgyvendinimą.

Projekto planas sudaromas pagal standartinę bendrą schemą, tačiau dokumento turinys visada yra unikalus, nes produkto savybių ir jo įgyvendinimo sąlygų derinys yra unikalus. Projekto vykdymo plane pateikiamos gairės visai projekto komandai ir nurodoma:

• pagal darbo apimtį
• pagal prioritetą
• apie valdymo metodų pasirinkimą,
• pagal kokybės standartus
• palaikant ryšį su suinteresuotomis šalimis,
• pagal veiklos vertinimo kriterijus ir kt.

1. Projekto fonas.
2. Užduotys ir tikslai.
3. Skalė.
4. Sienos (apribojimai).
5. Prielaidos (prielaidos).
6. įtakos ir priklausomybės.
7. Rizika ir problemos.
8. Strategijos ir metodai.
9. Laiko, išteklių, kokybės, masto kontrolės priemonės ir metodai.
10. Ryšiai.
11. Pristatymo tvarkaraštis.
12. Našumas ir jo matavimas.
13. Privalumų realizavimas.

Standartizuota schema leidžia lengviau naršyti dokumente, kuris gali apimti šimtus puslapių, jei reikia įgyvendinti dideles idėjas. Supaprastina darbo su planu procesą ir leidžia logiškai, nuosekliai, struktūriškai išdėstyti projekto planavimo etapus. Jei, pavyzdžiui, į skalę įtraukti elementai nėra dokumentuoti, gali pasirodyti, kad tarp projekto dalyvių nėra bendro supratimo, kas ką išleidžia. Ir jei nenurodysite kokybės lygio, gali taip pasirodyti kad gamintojui pakankamos kokybės gali nepakakti klientui.

Tinkamų detalių trūkumas sukelia klaidų, tačiau detalių perteklius su daugybe pasikartojimų trukdo suprasti projekto turinį. Todėl projekto gynimo planas dažniausiai išbandomas ant klausytojų, neturinčių išankstinių žinių apie projektą, įtraukiant plačios auditorijos atstovus. Prie projekto plano pridėtas fonas padės pritaikyti įgyvendinimo programą į bendrą kontekstą, o žodynėlis, santrumpų ir techninių santrumpų iššifravimas leis bet kam lengvai suprasti projekto esmę, neįtraukiant trečiųjų šalių informacijos šaltinių.

Domeno planavimas

Čia nagrinėjama produktų ir paslaugų, kurios turėtų būti pagamintos užbaigus projektą, rinkinys. Projekto planavimas pagal dalykinę sritį apima šias procedūras:

• Dabartinės būklės analizė.
• Pagrindinių projekto charakteristikų paaiškinimas.
• Sėkmės kriterijų ir projekto problemų patvirtinimas.
• Prielaidų ir apribojimų, priimtų pradiniame projekto etape, analizė.
• Projekto rezultatų kriterijų apibrėžimas tarpiniame ir baigiamajame etapuose.
• Sukurti duoto ploto struktūrinį dekompoziciją.

Projekto gyvavimo procese šią sritį sudarantys elementai gali keistis. Darbo tikslai ir charakteristikos gali būti patikslintos tiek pasiekus tarpinius rezultatus, tiek projekto rengimo stadijoje.

Projekto laiko planavimas

Pagrindinės šio parametro sąvokos yra: terminai, darbų trukmė, pagrindinės datos ir kt.. Koordinuotas dalyvių darbas organizuojamas remiantis kalendoriniais planais – projektiniais ir techniniais dokumentais, kurie nustato projekto darbų sąrašą, jų tarpusavio ryšį. , seka, terminai, atlikėjai ir ištekliai. Dirbant su projektu visam gyvenimo ciklas sudaromas darbo grafikas valdymo etapams ir lygiams.

Darbo suskirstymo struktūra (WBS)

WBS – grafinis projektavimo darbų hierarchijos atvaizdavimas – pirmasis projekto planavimo etapas. Iš esmės WBS yra projekto padalijimas į tokias dalis, kurios yra būtinos ir pakankamos planavimui ir efektyviai kontrolei. Sudarant hierarchinę struktūrą reikia laikytis šių taisyklių:

1. Viršutinio lygio darbų atlikimas pasiekiamas atliekant žemesnio lygio darbus.
2. Pirminis procesas gali turėti kelis antrinius darbus, kurių vykdymas automatiškai nutraukia pirminį procesą. Tačiau vaiko darbui yra tik vienas tėvų darbas.
3. Pirminio proceso išskaidymas į vaikų darbus vykdomas pagal vieną kriterijų: arba pagal pritraukiamus išteklius, arba pagal veiklos rūšį, arba pagal gyvavimo ciklo etapus ir pan.
4. Kiekviename lygyje turi būti renkami lygiaverčiai vaikų darbai. Jų homogeniškumo nustatymo kriterijai gali būti, pavyzdžiui, atlikto darbo apimtis ir laikas.
5. Konstruojant struktūrą kaip visumą, skirtinguose hierarchijos lygiuose būtina taikyti skirtingus dekompozicijos kriterijus.
6. Dekompozicijos kriterijų seka parenkama taip, kad kuo didesnė kūrinių sąveikų ir priklausomybių dalis būtų žemesniuose hierarchinės struktūros lygiuose. Veikia aukštesni lygiai- autonominis.
7. Darbo išskaidymas laikomas baigtu, jeigu vadovui ir projekto dalyviams aiškūs žemesnio lygio darbai, aiškūs jo pasiekimo būdai. galutinis rezultatas ir jo rodiklius, atsakomybė už darbų atlikimą paskirstoma vienareikšmiškai.

Remiantis WBS, sudaromas projekto darbų sąrašas. O tada nustatoma jų įgyvendinimo seka, santykis organizacinių ir technologinių modelių pagalba bei darbų trukmė.

Darbo trukmė

Darbų trukmė nustatoma pagal standartus, pagal asmeninę patirtį (kai yra panašaus darbo pavyzdys), pagal skaičiavimo metodus projektų planavimui. Tokie metodai apima, pavyzdžiui, PERT įvykių analizės metodą, kuris naudojamas, kai yra neapibrėžtumas vertinant operacijų trukmę. Tačiau yra įvairių būdų, kaip valdyti projekto laiką.

• PERT. Metodas laikomas svertiniu vidurkiu trijų tipų prognozės: optimistinės, laukiamos ir pesimistinės. Nustačius kiekvienos prognozės trukmę (naudojant formulę ir/ar įtraukus ekspertus), apskaičiuojama kiekvienos prognozės tikimybė. Tada kiekvienos prognozės reikšmės ir jų tikimybės padauginamos ir vertės pridedamos.
• tinklo diagrama. Tinklo diagrama yra grafinis veiklos ir priklausomybių tarp jų vaizdas. Dažniau jis pateikiamas grafiko pavidalu, kurio viršūnės yra projektiniai darbai, o jų seka ir ryšys parodomas jungiančiomis rodyklėmis.
• Ganto diagramos. Tai horizontali diagrama su projektavimo darbų rodymu segmentų pavidalu, orientuotų pagal kalendorių. Segmento ilgis atitinka darbo trukmę, o rodyklės tarp segmentų rodo darbų santykį ir seką.

Be to, kiekviename projekte užtikrinamas darbų optimizavimas pagal laiko kriterijų, tvirtinami kalendoriniai planai. Bendras metodų tikslas planuojant projekto laiką yra sutrumpinti projekto trukmę neprarandant jo komponentų kokybės.

Projekto darbo jėga

Šioje planavimo dalyje pirmiausia nustatomas turimų išteklių kiekis. Tai daroma sudarant atlikėjų sąrašą, jų prieinamumą ir galimybę dalyvauti projekte.

Tada kiekvienam projekto darbui vykdytojams paskiriama jų atsakomybės sritis. Dažnai kalendoriniame plane darbo išteklių paskirstymo lygmenyje yra prieštaravimų. Tada atliekama prieštaravimų analizė ir jų pašalinimas.

Projekto kaina

Yra keli projekto išlaidų planavimo etapai:

1. Pirmajame etape nustatomos išteklių, kiekvieno projekto darbo ir viso projekto naudojimo išlaidos. Projekto kaina čia yra bendra išteklių ir darbų kaina. Atsižvelgiama į įrangos kainą (įskaitant nuomojamą įrangą), visą darbo dieną dirbančių ir pagal sutartį samdomų darbuotojų darbą, medžiagas, transportavimą, seminarus, konferencijas, mokymo išlaidas ir kt.
2. Antrasis etapas – projekto sąmatos parengimas, derinimas ir tvirtinimas. Projekto sąmata čia yra dokumentas, kuriame yra pagrindimas ir bendros projekto kainos apskaičiavimas. Paprastai jis gaminamas atsižvelgiant į būtinų išteklių kiekį, darbo kiekį ir kt.
3. Trečiasis etapas apima biudžeto rengimą, jo derinimą ir tvirtinimą. Biudžetas nustato išteklių apribojimus ir sudaromas tokia forma:

• išlaidų ir kaupiamųjų išlaidų stulpelių diagramos,
• kaupiamųjų išlaidų linijinės diagramos, paskirstytos laikui bėgant,
• išlaidų diagramos,
• kalendoriniai tvarkaraščiai ir planai,
• išlaidų paskirstymo matricos.

Tuo pat metu biudžeto rizikos valdymas nagrinėjamas atskirame projekto planavimo skyriuje.

Rizikos planavimas

Šiame skyriuje aprašomi procesai, susiję su rizikos nustatymu, analize, įvertinimu ir atsako į riziką kūrimu. Rizika apibūdinama 3 parametrais:

• rizikos įvykis,
• rizikos įvykio tikimybę,
• nuostolių dydžio, rizikos veiksnio realizavimo atveju.

Paprastas rizikos planavimo metodas įgyvendinamas pagal šią veiksmų seką:

1. Rizikos nustatymas. Tam pasitelkiami ne tik ekspertai, bet ir visi, kurie padės aptikti galimas projekto spragas.
2. Rizikos realizavimo tikimybės nustatymas. Matuojama procentais, dalimis, taškais ir kitais vienetais.
3. Rizikų klasifikavimas pagal kiekvienos konkrečios rizikos reikšmę projektui ir jos vietą hierarchijoje. Pirmenybė teikiama tiems, kurie yra labai tikėtini ir svarbūs visam projektui.
4. Suplanuoti priemones, mažinančias kiekvienos individualios rizikos tikimybę, nurodant už tai atsakingus darbuotojus.
5. Neigiamų padarinių pašalinimo priemonių planavimas rizikos realizavimo atveju, paskiriant atsakingus asmenis.

Kuriant projektą, planas turi būti parašytas nepriklausomai nuo to, kokioje srityje įmonė veikia: nuo gamybos projektai ir IT technologijų sferą bei kraštovaizdžio tvarkymą ir miesto gerinimo darbus. Tačiau pats projekto planavimas nėra „sustabdomas ore“, nes prieš jį inicijuojamas projektas, o užbaigiamas perėjimas prie tiesioginio projekto vykdymo.

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

Pagrindinis planavimo funkcijos yra išvardyti žemiau.

Paverskite poreikius 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ų, kurias galima kontroliuoti, rinkinį.

Reikalingų išteklių nustatymas. Detalieji planai lems žmonių skaičių reikalinga įranga ir veiklos sąlygos, kurių prireiks projektui užbaigti.

Komandinio darbo projekte koordinavimas. Labai dažnai projekto vykdymas išskaidomas į atskiras veiklas, kurios gali būti vykdomos 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 nustatoma po detalaus planavimo. Žinodami apie šių pavojų egzistavimą, galėsite jas pastebėti anksčiau (jei jie pasitvirtino) ir pasiruošti jas spręsti.

Įspėjimas apie problemą. Nukrypimas nuo plano yra problemų signalas. Planai nėra dogma, kurios reikia besąlygiškai laikytis. Projekto vadovui jie labiau yra spėlionės ir palyginimo pagrindas. Jeigu projekto įgyvendinimas nepateisina lūkesčių, tuomet būtina atitinkamai koreguoti planą.

Grupė planavimo procesai parodyta pav. 3.10. Šie procesai gali būti kartojami ir būti iteracinės procedūros dalis, atliekama tol, kol pasiekiamas tam tikras rezultatas. Pavyzdžiui, jei pradinė projekto užbaigimo data yra nepriimtina, tada reikalingi ištekliai, kaina ir kartais ( Procesų grupės ^Projektų valdymas

Planavimo proceso grupė

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

Planavimas

Žmogiškųjų išteklių valdymo plano rengimas 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

Vystymas

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ų nomenklatūra, biudžetas ir projekto turinys, atitinkantis jo tikslus.

Planavimas yra būtina bet kokios, net ir paprasčiausios užduoties, prielaida. Netinkamas planavimas gali sukelti projekto nesėkmę arba duoti netinkamų rezultatų projekto aplinkoje.

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

Planavimas susideda iš šių dalykų sudarymo planus:

• darbų atlikimas, įskaitant jų 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ą, turinčią informacijos kaupimo savybių, diferencijuotą pagal sąmoningumo valdymo lygius, ir turi būti ešelonuoti pagal kūrimo laiką (trumpą). - vidutinės trukmės, ilgalaikės ir ilgalaikės). Planavimo lygiai ir planų sistema turi būti sudaryta 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 aglomeruoti 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 vietoje atskirų tinklo dalių. Tokio laipsniško agregavimo pagalba gaunami kelių lygių tinklo planai (3.11 pav.). Paprastai yra koncepcinis planas, strateginis planas projekto įgyvendinimas, taktiniai (detalieji, operatyviniai) planai.

Tinklo planas su keliais projektais (vyresniajai vadovybei)

1 lygis

3 lygis

2 lygis

Tinklo planas su etapais

Detalus tinklo planas

Ryžiai. 3.11.Pakopiniai tinklo planai

Koncepcinis planavimas, kurio rezultatas yra koncepcinis planas, yra pagrindinės projekto dokumentacijos rengimo procesas, Techniniai reikalavimai, vertinimai, integruoti grafikai, kontrolės ir valdymo procedūros. Koncepcinis planavimas vykdomas pradiniu projekto gyvavimo ciklo laikotarpiu.

Strateginis planavimas yra strateginių, išplėstų, ilgalaikių planų kūrimo procesas.

Išsamus (eksploatacinis), taktinis) planavimas susiję su taktinių, detaliųjų planų (grafikų), pagrįstų hierarchine darbo struktūra (WBS), kūrimu operatyviniam valdymui

atsakingų vykdytojų lygmenyje.

Turinio valdymo planavimas. Viena iš įprastų programinės įrangos projektų „ligų“ vadinama „šliaužiantis bruožas-rizmas“, kai prie originaliai suprojektuotos būdelės mylimam šuniui pirmiausia pritvirtinama pašiūrė sodo įrankiams laikyti, o po to – kelių aukštų namelis jo šeimininkui. Ir visa tai bandoma statyti ant tų pačių pamatų ir iš tų pačių medžiagų. Šis požiūris lėmė 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ų peržiūros, 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 - identifikuoti 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ų pakeitimus. Galiausiai, reikėtų įvertinti šių pakeitimų atlikimo, pakeitimų testavimo sąnaudas ir jų įtaką projekto laiko juostai. Šis darbas pareikalaus įvairių specialistų darbo valandų, o kartais ir nemažo: analitikų, projektuotojų, kūrėjų, testuotojų, taip pat projektų vadovo, 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ų, atsakomybių ir veiklos tikslų pasiskirstymas. Jame būtinai turi būti:

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

Reikia atsiminti, kad projekto organizacinė struktūra yra „gyvas“ organizmas. Ji pradeda formuotis planavimo etape ir turi keistis, kai projektas vystosi. Organizacinės struktūros nestabilumas (dažnas atlikėjų pasikeitimas) gali tapti rimta projekto valdymo problema, nes yra pakeitimo kaina, kurią lemia naujo dalyvio įėjimas į projekto kontekstą.

Konfigūracijos valdymo planavimas. Vienas iš svarbiausių programinės įrangos gamybos procesų yra konfigūracijos valdymas. Apie šią žinių sritį parašyta ne viena knyga. Bus kalbama tik apie tai, kaip šis darbas turėtų būti planuojamas. Projekto konfigūracijos valdymo plane turėtų būti:

• stengtis pateikti bendrą visos projekto dokumentacijos ir sukurto programos kodo saugyklą, užtikrinti projekto informacijos saugumą ir atkūrimą po gedimo;
• darbas prie projekto komandos narių naudojamų darbo vietų ir serverių įrengimo;
• darbus, reikalingus organizuojant tarpinių sistemos laidų surinkimą bei 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. „Užtepti“ šį darbą visiems projekto dalyviams, pirma, neefektyvu. Diegiant ir konfigūruojant kūrimo aplinkas, tokias kaip duomenų bazės ir taikomųjų programų serveriai, reikia tam tikrų kompetencijų ir žinių apie konkrečių produktų versijų funkcijas. Jei šiuos įgūdžius turi įvaldyti visi kūrėjai, tai užtruks per daug darbo laiko. Antra, „tepimas“ konfigūracijos valdymo darbai gali sukelti kolektyvinį neatsakingumą, kai niekas nežino, kodėl projektas „nevyksta“ ir kaip „atsukti“ į ankstesnę versiją.

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

Kokybės vadybos planavimas. Dar viena pagrindinių programinės įrangos inžinerijos žinių sričių yra kokybės užtikrinimas. Yra įvairių nuomonių apie tai, kas yra programinės įrangos kokybė ir kaip ją efektyviai užtikrinti. Apsiribosime teiginiu, kad kokybės užtikrinimas yra gana svarbus darbas, kurį reikėtų planuoti iš anksto ir atlikti viso programinės įrangos projekto metu, o ne tik priėmimo testų metu.

Planuojant šį darbą reikia suprasti, kad projekto produktas neturi būti kuo kokybiškesnis, o tai nepasiekiama per ribotą laiką. Reikalinga kokybė produktas nustatomas pagal jam keliamus reikalavimus. Pagrindinis kokybės užtikrinimo uždavinys – ne surasti klaidas gatavame produkte (produkcijos kontrolė), o užkirsti joms kelią gamybos procese.

Kokybės vadybos planas turėtų apimti šią veiklą:

• objektyvus programinės įrangos produktų ir technologinių operacijų atitikties taikomiems standartams, procedūroms ir reikalavimams patikrinimas;
• kokybės nukrypimų nustatymas, jų priežasčių nustatymas, priemonių jiems pašalinti taikymas, taip pat taikomų priemonių įgyvendinimo ir efektyvumo kontrolė;
• aukščiausios vadovybės teikimas nepriklausoma informacija apie neatitikimus, kurių negalima išspręsti projekto lygmeniu.

Darbo turinio ir apimties patikslinimas. Projekto turinio išaiškinimas (dekompozicija) yra vienas svarbiausių sudedamosios dalys projektų valdymo disciplinos. Detalizavimas leidžia įvertinti, pvz. Iš viso išlaidų projektą per bendrą atskirų darbų kainą. Projekto apimties detalizavimo rezultatas yra darbo suskirstymo struktūra(Work Breakdown Structure – WBS). Daugeliu atvejų ši struktūra yra hierarchinė. Tuo pačiu metu detalizavimo procesas yra darbo suskirstymo struktūra, t.y. detalios darbo struktūros ar projekto užduoties kūrimo veikla.

Hierarchinė kūrinių struktūra(WBS) – tai į rezultatą orientuotas projekto komandos atliekamo darbo, siekiant projekto tikslų ir reikiamų rezultatų, išskaidymas. Jos pagalba struktūrizuojamas ir apibrėžiamas visas projekto turinys. Kiekvienas kitas hierarchijos lygis atspindi išsamesnį projekto elementų apibrėžimą. WBS kūrimo pagrindas yra projekto koncepcija, kuri apibrėžia projekto produktus ir jų pagrindines charakteristikas. WBS užtikrina, kad būtų nustatytos visos veiklos, reikalingos projekto tikslams pasiekti. Daugelis projektų žlunga ne todėl, kad jie neturi plano, o todėl, kad planas neatlieka svarbių darbų, tokių kaip klaidų testavimas ir 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, subpaketus. Kiekvienas kitas išskaidymo lygis suteikia nuoseklų projekto turinio detalizavimą, kuris leidžia įvertinti darbo laiką ir apimtį. WBS turėtų apimti visus tarpinius ir galutinius produktus.

Galite išskaidyti projekto darbą įvairiais būdais. Pavyzdžiui, GOST 19.102-77 numato krioklio priėjimas ir apibrėžia šiuos dalykus programinės įrangos sistemos kūrimo etapai.

• 1) techninė užduotis;
• 2) projektinis projektas;
• 3) techninis projektas;
• 4) darbo projektas;
• 5) įgyvendinimas.

Jei laikysitės šio standarto, šie projekto produktai turėtų būti pirmojo WBS lygio. Jei tektų sukurti automatizuotą valdymo sistemą branduoliniam reaktoriui arba pilotuojamam erdvėlaivis, būtent tai ir turėjo būti padaryta. Tačiau kuriant komercinę programinę įrangą šis metodas yra neefektyvus.

Š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. Tada komponentai gali būti išskaidyti į „funkcijas“ – funkcijas, kurias jie turi įgyvendinti.

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

Detalizavimo kontekste terminai „užduotys“ ir „darbai“ dažnai vartojami pakaitomis. Nepaisant to, teisingiau sakyti, kad užduotis lemia tarpinio rezultato pasiekimą, o darbas yra veiksmų visuma šiems rezultatams pasiekti. Kadangi bet kuri užduotis reikalauja atlikti tam tikrą darbą, esant tam tikriems apribojimams, tikrai galima kalbėti apie neabejotiną užduočių „priskyrimą“ darbui ir atvirkščiai. Tai yra terminų pakeičiamumo priežastis Kasdienybė. Kartu 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.

AT bendras atvejis gali kalbėti apie detalizuojant: „programa – projektas - užduotis yra operacija. Ant pav. 3.12 parodytas tokio detalizavimo pavyzdys (rodomos tik užduoties operacijos BET).

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

Kiekvienas tokios struktūros elementas turi apribojimų ir kitų reikšmingų charakteristikų bei su juo susijusių duomenų. Reikšmė reiškia jų būtinumą ar naudingumą priimant sprendimus. Tam tikrų terminų detalumas ir vartojimo lygis priklauso nuo konkretaus projekto, valdymo kultūros, gyvavimo ciklo standartų, projekto specifikos ir apimties, taip pat nuo kitų veiksnių, būdingų tiek konkrečiai organizacijai, tiek konkrečiai organizacijai. projektą.

Visos projekto dalys (paprojekčiai ir darbų paketai) turi būti asmeniškai atsakingos. Kiekvieno darbo paketo rezultatas turi būti aiškiai apibrėžtas. Dėl projekto veiklų ir sąmatų reikėtų susitarti su pagrindiniais komandos nariais, įgyvendinančios įmonės vadovybe, o prireikus – ir su užsakovu. Dėl koordinavimo komandos nariai prisiima įsipareigojimus projekto įgyvendinimui, o vadovybė – už projekto aprūpinimą reikalingais ištekliais.

WBS yra vienas pagrindinių projektų valdymo mechanizmo įrankių (priemonių), kuris matuoja projekto rezultatų pasiekimo laipsnį. Svarbiausia jo funkcija – užtikrinti, kad visi projekto dalyviai suprastų ir suprastų, kaip projektas bus vykdomas. Vėliau, siekiant nustatyti nukrypimus, bazinė linija bus naudojama kaip gairės palyginimui su dabartiniu projekto vykdymu.

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

Pagrindinis projekto kainos algoritminio modeliavimo sunkumas yra sąmatos priklausomybė nuo gatavo produkto savybių ir parametrų. Ankstyvoje projekto stadijoje šių savybių ir parametrų tiksliai nustatyti neįmanoma. Yra daug PP sąnaudų įvertinimo metodų, kurie turėtų būti naudojami lygiagrečiai. Jeigu gauti rezultatai labai skiriasi, vadinasi, analizei panaudota nepakankama arba netinkama informacija. Programinės įrangos produkto kaina dažnai iš anksto nustatoma siekiant sudaryti sutartį, todėl sistemos funkcionalumas vėliau pritaikomas prie tokių, kurie atitiktų šią kainą.

Žinomas projekto išlaidų įvertinimo modelis B. Boehma SOSOMO atsižvelgia į projektavimo ypatybes, kuriamos programinės įrangos savybes, techninę įrangą ir personalo galimybes. Šis modelis taip pat apima įrankius, skirtus projekto darbo trukmei nustatyti. Darbų atlikimo laikas nėra tiesiogiai proporcingas projektui samdytų specialistų skaičiui. Įtraukus daugiau žmonių į projektą, kuris atsilieka nuo grafiko, jo užbaigimas gali būti atidėtas.

Algoritminiai projektų sąnaudų modeliai naudojami programinės įrangos projektams valdyti, nes jie palaiko kiekybinė analizė parametrus. Š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 išlaikymo išlaidos, t.y. kompiuteriai, programinė įranga, kvadratai, baldai, telefonai, modemai ir daug daugiau. Be to, kartais reikia atsižvelgti į papildomų išlaidų(pavyzdžiui, saugumas). Papildomos projekto išlaidos apima testavimo sistemos, SABE sistemos ir kt. įsigijimą. Pagrindinė projekto sąmata yra projekto išlaidų sąmata, išreikštas atlikėjų darbo dienomis prie projekto. Šis įvertinimas atliekamas ankstyvoje priežiūros ir planavimo stadijoje.

Bendrą projekto kainą nustato patyrę specialistai su iki 10% paklaida. Sąnaudos gali būti apskaičiuojamos iš viršaus į apačią, iš apačios į viršų arba remiantis anksčiau pagaminto projekto kaina. Ekspertai atlieka pesimistinį, optimistinį ir realų vertinimą, apklausdami visus narius darbo grupė ir pakoreguoti kiekvieną įvertinimą, kad gautumėte labiausiai tikėtiną. Kai kuriose darbo grupėse pesimistiniai ir optimistiški vertinimai gali labai skirtis.

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

Yra įvairių empirinių požiūrių į projekto kainą įvertinti, pavyzdžiui, projekto kainą siūloma nustatyti pagal formulę

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

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

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

KAINA = 5,255 0,91.

Šie skaičiavimai buvo pagrįsti projektų, kuriuose programos svyravo nuo 4000 iki 467000 kodo eilučių ir buvo parašytos 28 skirtingomis programavimo kalbomis 66 kompiuteriams, analize. 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, produkto bei aplinkos savybes. 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. .). Antrame etape įvertinamos projekto funkcinių taškų projektavimo ir įgyvendinimo sąnaudos, atsispindinčios projekto reikalavimuose. Trečiajame etape vertinimas reiškia užbaigtą projektą, kai sistemos dydį galima nustatyti pagal baigtas programos eilutes ir kitus veiksnius.

Ši lygtis yra pagrindinis eksperimentinio projekto kainos vertinimo modelis šiandien:

KAINA = bS c m(X),

kur bS c - pradinis įvertinimas, kuris koreguojamas naudojant išlaidų vektorių m(X) ir senų bei naujų objektų skaičiaus apskaitą; su- parametras, kuris keičiasi nuo nulio iki vieneto pirmajam projekto etapui ir nuo 1,01 iki 1,26 - likusiems etapams.

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

Konstruktyvus vertybinis modelis(COSOMO - Constructive cost model), pasiūlytas 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 kaštam ir kaštams, taip pat suteikia galimybę sudaryti programinės įrangos planą.

Į funkcijas orientuota FP metrika užuot skaičiuojant LOC balą, programinės įrangos produktas matuojamas netiesiogiai. Svarstomas ne dydis, o gaminio funkcionalumas ar naudingumas. Šios metrikos autorius – A. Albrechtas. Funkcijos dydžio nustatymas susideda iš kelių žingsnių ir prasideda nustatant funkcijas, kurias turi turėti programa. Tarptautinė funkcijų taškų vartotojų grupė (IFPUG) paskelbė kriterijus, pagal kuriuos nustatomos taikomųjų programų funkcijos. Skaičiuojant FP-metriką, naudojamos penkios informacinės charakteristikos: išorinių įėjimų skaičius; išorinių kaiščių skaičius (smeigtukai 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 metrinis skaičiavimas - apibrėžti funkcijų rodyklių skaičius FP (funkciniai taškai) pagal tam tikrą formulę, kur sudėtingumo koregavimo įvesties koeficientų reikšmės (kiekvienas koeficientas gali turėti šias reikšmes: 0 - jokios įtakos; 1 - atsitiktinis; 2 - mažas; 3 - vidutinis; 4 – svarbūs; 5 – pagrindiniai) atrenkami empiriškai pagal atsakymus į 14 klausimų, apibūdinančių programos sistemos parametrus.

Metodas susideda iš vienodo visų programos galimybių matavimo bet kuriam projektui ir paraiškos dydžio išreiškimo vienu skaičiumi, kurį vėliau galima naudoti norint įvertinti kodo eilučių skaičių, kainą ir projekto laiką. Pagal jį formuojami našumo, 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 funkciškai orientuota metrika – rezultatai pagrįsti subjektyviais duomenimis, naudojami ne tiesioginiai, o netiesioginiai matavimai. Be to, norint tiksliai ir nuosekliai taikyti šį metodą, reikia turėti tam tikrų įgūdžių.

Standartinių lentelių pagalba FP įverčiai lengvai paverčiami LOC įverčiais, t.y. pagal funkcinį dydį apskaičiuokite kodo eilučių skaičių. Tačiau perskaičiavimo 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ą žmogaus mėnesiais, ir projekto laiką.

Atliekant vertinimą, yra dvi galimybės naudoti LOC ir FP duomenis: kaip vertinimo kintamuosius, kurie nustato kiekvieno produkto elemento dydį, arba kaip metriką, surinktą dirbant su ankstesniais projektais ir įtrauktus į firmos metrikos pagrindą.

Pavyzdys 3.1. Panagrinėkime darbo įvertinimo pagal GC 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 / planuotojas sukuria geriausią LOC n , blogiausia YUS X ir tikėtina JUS V sąmatos. Įverčių formavimo procese naudojami eksperimentiniai duomenys iš metrinio pagrindo arba intuityvi planuotojo atvaizdai. Galimų įverčių verčių diapazonas atitinka numatomo neapibrėžtumo laipsnį.

3 etapas. Kiekvienai funkcijai f t numatoma sąmatos vertė nustatoma:

JUS I + YUS X + 4 LOC^ oj=6"

yus.

4 etapas. Funkcijos plėtros GC atlikimo vertė apskaičiuojama pagal vieną iš trijų taisyklių.

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

PR, = PR žr. / = 1, 2, ..., P.

taisyklė b. Funkcijai /-oji, remiantis vidutine našumo metrika, apskaičiuojama tinkinta našumo vertė:

ys vid

MS kietas ’

kur JAV trečiadienis - vidutinis LOC balas, paimtas iš metrinės bazės (atitinka vidutinį produktyvumą).

Taisyklė B. Funkcijai /-oji reguliuojama našumo vertė apskaičiuojama pagal pasirinktą analogą (paimta iš metrinės bazės):

LOSdienos

ms laukti

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

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

jei naudojama taisyklė B arba C:

b1m ^exp/

6 etapas. Apskaičiuoja bendrą projekto išlaidų sąmatą, jei naudojama A arba B taisyklė:

KAINA \u003d UDST, palyginti su YuS 0F /;

jei naudojama taisyklė B:

KAINA \u003d UDST ir / ^YUS 0J / ,

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

Projekto grafiko rengimas. Nustačius darbų sudėtingumą, būtina nustatyti jų įgyvendinimo grafiką ir bendros sąvokos projekto įgyvendinimas, t.y. sudaryti projekto grafiką Pagrindinis grafikas yra patvirtintas grafikas su nurodytais projekto laiko etapais, gairėmis ir darbų suskirstymo struktūros elementais.

Pagrindinis grafikas daugeliu atvejų yra sutarties su klientu elementas. Kontroliniai taškai (gabariniai taškai) būti projekto būklės analizės ir sprendimų priėmimo taškai „§o arba 1 §О“ 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 punktas „Projektas baigtas“ yra neinformatyvus, efektyvesniu metodu laikomas nuoseklaus pristatymo būdas: aukščiau pateiktas kontrolinis taškas suformuluotas formoje „ 1, 3, 5 ir 7 reikalavimų testavimas atliktas“.

Jei darbai nėra tarpusavyje susiję, 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 tarp darbų dažniausiai yra priklausomybių, kurios gali būti „sunkios“, pvz., „analizė – projektavimas – kodavimas – testavimas – dokumentavimas“ arba „minkštas“, kurias galima peržiūrėti arba sušvelninti, pvz. , konkretaus atlikėjo nuoseklų užduočių vykdymą galima perplanuoti kitam atlikėjui, o užuot sukūrę pagrindinę programinę įrangą, kuri turėtų būti anksčiau nei kuriant taikomąją programinę įrangą, galite sukurti „stubus“, imituojančius jos darbą.

Darbų plano su jų įgyvendinimo terminais rengimas gali būti atliekamas CPM kritinio kelio metodu arba PERT programos analizės ir vertinimo metodu. Projekto planas pateikiamas etapais: „Planavimas“, „Dizainas“, „Kodavimas“, „Testavimas“ ir „Priežiūra“. Planavimas apima specifikacijų, biudžeto ir grafiko apibrėžimą, taip pat viso projekto plano rengimą.

AT projekto kritinio kelio metodas(Kritinis kelias) projekte naudoja ilgiausią darbų grandinę. Padidinus bet kokio darbo šioje grandinėje trukmę, pailgėja viso projekto trukmė. Projektas visada turi bent vieną kritinį kelią, bet gali būti ir daugiau nei vienas. Projekto vykdymo metu kritinis kelias gali pasikeisti.

Vykdydamas projektą vadovas visų pirma turėtų atkreipti dėmesį į užduočių vykdymą kritiniame kelyje ir stebėti kitų kritinių kelių atsiradimą. Egzistuoti praktinė rekomendacija: kritiniame kelyje turėtų būti darbas su laisvomis nuorodomis, 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 gairės (kontrolinis taškas) pakeliui į atskirų projekto veiklų įgyvendinimą ir naudojamas tam tikrų veiklų užbaigimo būsenai rodyti/žymėti. Vykdydami projektą, vadovai naudoja etapus, kad nurodytų svarbius projekto etapus, kuriuos reikia pasiekti.

Vadovo apibrėžta etapų seka dažnai vadinama etapo planas (pagal įvykius). Atitinkamų etapų pasiekimo plano apibrėžimas sudaro etapais pagrįstą tvarkaraštį.

Tinklo darbų suskirstymas ir Ganto diagrama taip pat gali būti naudojami planavimo etape.

Darbų suskirstymas tinkle(СРР) yra hierarchinė projekto užduočių skaidymo į subužduotis struktūra. Žemesniame lygyje yra darbai, detalizuoti CPP tinklo modelio veiklos elementai.

Tinklo modelis leidžia suskirstyti darbą į pagrindinius komponentus ir subkomponentus, nustatyti veiklos sritis, skirtas sudėtingiems tikslams pasiekti, paskirstyti asmenis, atsakingus už individualų projekto darbą, atlikti ataskaitas su informacijos apie projekto rezultatus santrauka.

Šiuo atveju darbo plane turi būti atsispindi pagrindiniai darbo etapai ir reikalinga darbo būklė kiekviename etape, kiekvieno darbo suskirstymas į atskiras užduotis, taip pat darbų sąsajos, laiko intervalai kiekvienai veiklai, darbo pradžios ir pabaigos laikas. Darbo planas apima skirtingi tipai projekto funkcijų, posistemių, patikimumo, apsaugos priemonių demonstravimas ir kt.. Plano dokumentuose taip pat pateikiamas gairių ir metodų rinkinys, kaip atlikti nurodytas operacijas, palaikyti sistemos ryšius su kitais posistemiais ir kt.

Darbo plane CPP 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.Projekto plano žingsnis po žingsnio grafikas

Kita vizualinio darbo plano pateikimo forma gali būti tinklo diagrama, nustatytas grafiko pavidalu, kurio viršūnėse išsidėstę darbo taškai, o ant lankų - dienų (savų) skaičius, reikalingas jiems atlikti (3.15 pav.). Šios etiketės nustato proceso vykdymo laiką. Lankas, kylantis iš pradinės

Ryžiai. 3.15.

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

Diagramoje gali būti ciklinių takų. Pagal grafiką atliekama kritinių takų analizė, t.y. nustatyti kiekvieno proceso trukmės duomenis.

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

Galima pavaizduoti patį paprasčiausią grafiką Ganto diagramos- linijinė diagrama, kurioje projekto užduotys pavaizduotos laiko intervalais, įskaitant jų įgyvendinimo pradžios ir pabaigos datas, atsižvelgiant į galimus vėlavimus. Šioje diagramoje planuojamos operacijos(darbų suskirstymo struktūros elementai) pateikiami kairėje pusėje, datos rodomos viršuje, o operacijų trukmė rodoma horizontaliomis juostomis nuo šios operacijos pradžios iki jos atlikimo datos (3.16 pav.) .

Projekto planas			L Elvest K., Goričeva R., Ivannikova O., Plotnikova O.
Reikalavimų specifikacija
2.1. Pirminis reikalavimų sąrašas				Goričeva R.
2.2. Reikalavimai modeliai			Plotnikova O.
2.3. Aukšto lygio sistemos architektūra				Sorokinai O., Elvestui K.
2.4. Sistemos patvirtinimo kriterijai				Ivannikova O.
2.5. Mitologinės duomenų bazės modelis				Čečikova A.
2.6. Žodynėlis				Goričeva R., Plotnikova O.
Projektavimo dokumentacija
3.1. architektūros projektas			N Elvestas K.
3.2. Vartotojo sąsajos projektas			| Skaitikliai A., Plotnikova O.
3.3. Posistemių projektas			Aš Sorokina O.
3.4. Duomenų bazės modelis			N Ivannikova O.
3.5. Bandymo planas				b Goričeva R.
Įgyvendinimo dokumentas
4.1. Įgyvendinimo apžvalga					Skaitikliai A., Sorokis		Ša O., Iva
4.2. Naudotojo gidas					Elvestas K., Goričeva
Testo vykdymo dokumentas
5.1. Baltos dėžės bandymas				N. Konterčikova A.,			Sorokinas
5.2. Integracijos testavimas		1^ Elvestas K					Dailidė
5.3. Sertifikavimo testavimas							cheva R., II
Projekto užbaigimas ir pristatymas							Skaitliukas

Ryžiai. 3.16. Ganto diagramos

Vykdymo proceso grupė

Projektų valdymo procesų grupės

Projekto kokybės valdymas

Saugumas

kokybės

Šiuolaikinės projektų valdymo programinės įrangos priemonės leidžia vizualizuoti projekto grafiko struktūrą ir darbo vykdymo procesus, pavyzdžiui, gerai žinoma ir gana dažnai praktikoje naudojama Projektų valdymo sistema. Tai leidžia kūrėjui ar projekto vadovui pamatyti, kaip Skirtingos rūšys veikla – nuosekliai ar lygiagrečiai, nesvarbu, ar jos eina kritiniame kelyje.