Նախագծի ճկուն կառավարում | IT Knowledge Portal
 

Նախագծի ճկուն կառավարում

Ներածություն

Նախագծի ավանդական կառավարումը այն նախագծերի համար, որոնք պարունակում են կարևոր նշանակության ծրագրային բաղադրիչ կարող է լինել որոշ չափով անարդյունավետ, քանի որ պահանջները անըմբռնելի են, անկայուն և ենթակա են փոփոխության: Ուստի ոլորտում ձևավորվում է այլընտրանքային մոտեցում, այն է նախագծի ճկուն կառավարումը( Agile Project Management ):

 

Ի՞նչ է նախագծի ճկուն կառավարումը

Նախագծի ճկուն կառավարումը անընդհատ, հաճախակի կրկնվող և աստիճանաբար իրականացվող գործընթաց է, որտեղ ծրագրավորողները և նախագծի շահառուները ակտիվորեն աշխատում են միասին, որպեսզի հասկանան բնագավառը, բացահայտեն թե ինչ պետք է ստեղծել, և սահմանեն գործառութային մոդուլների և բաղադրիչների հնարավորությունների առաջնահերթությունը:

 

Ճկուն և կրկնվող մոտեցմամբ մշակման տարբերությունն այն է, որ իրականացման ժամանակը ճկուն կառավարման ընթացքում չափվում է շաբաթներով, այլ ոչ թե ամիսներով: Քանի որ ճկուն կառավարումը ծագում է ճկուն ծրագրային ապահովման մշակումից (Agile software development ),այն հետևում է նույն չափորոշիչներին, որոնք որ սահմանված են Ճկուն Մանիֆեստում (Agile Manifesto), երբ խոսքը վերաբերում է համագործակցությանը և փաստաթղթավորմանը: Մի քանի ծրագրային ապահովման մեթոդներ ծագում են ճկուն մեթոդից, այդ թվում Scrum և ծայրահեղ ծրագրավորման մեթոդները (Scrum & Extreme Programming):

 

Ճկուն մեթոդները օգտագործվում են, երբ առկա են հետևյալ պայմանները.

  • հստակ սահմանված է նախագծի արժեքը
  • պատվիրատուն ակտիվորեն մասնակցում է նախագծի ամբողջ ընթացքին
  • պատվիրատուի ներկայացուցիչը, դիզայներները և ծրագրավորողները ֆիզիկապես գտնվում են նույն աշխատանքային վայրում
  • հնարավոր է ՏՏ լուծման հնարավորությունների աստիճանաբար մշակումը
  • ընդունելի է տեսանելի փաստաթղթավորումը (պաշտոնական փաստաթղթավորման փոխարեն գրատախտակի, թղթի կամ պատի վրա քարտեր` պատկերված գծագրեր` այսպես կոչված  «քարտեր պատի վրա»):

 

Գծապատկեր 1.1 պատկերում է զարգացման ճկուն մոդելը:

 

Agile Project Management

Գծապատկեր 1. 1  Նախագծի ճկուն կենսափուլի մոդուլ

 

Ճկուն մոտեցումը բաղկացած է բազմաթիվ արագ կրկնվող պլանավորման և զարգացման փուլերից (ցիկլերից), ինչը թույլ է տալիս նախագծի աշխատանքային խմբին անընդհատ գնահատել մշակվող ՏՏ լուծումը (արտադրանքը) և ստանալ օգտվողների կամ շահառուների անմիջական կարծիքը: Աշխատանքային խումբը ուսումնասիրում, արդիականացնում և բարելավում է նախատեսված ՏՏ լուծումը (արտադրանքը), ինչպես նաև աշխատանքային խմբի կողմից օգտագործվող աշխատանքային մեթոդները` ամեն հաջորդ փուլից հետո:

 

Արդյունավետ պլանավորման, պահանջների սահմանման և լուծման նախագծման գործընթացից հետո փուլն ավարտվում է` նախագծի իրականացման մեկնարկի, առավել մանրամասն պլանավորման, պահանջների սահմանման, նախագծման, մշակման և փորձարկման համար անհրաժեշտ կրկնվող քայլերը տեղի են ունենում այսպես կոչված «ալիքներով»:

 

Այս մոտեցումը թույլ է տալիս կատարել ՏՏ լուծման (արտադրանքի) շտապ, անհապաղ փոփոխություններ, այն դեպքում հենց որ պահանջներն ի հայտ են գալիս: Նախագծի ճկուն կառավարումը պահանջում է նվիրված, ամբողջ աշխատանքային օրվա հասանելիությամբ աշխատանքային խումբ, որն ընդգրկում է պատվիրատուի ներկայացուցիչ կամ վերջնական օգտվող, որտեղ աշխատանքային խմբի անդամներն աշխատում են նույն աշխատանքային վայրում:

 

Նախագծի ճկուն կառավարման միջավայր

Ի տարբերություն նախագծի ավանդական կառավարման, որն ի հայտ է եկել շինարարական, ճարտարագիտական և պաշտպանության ոլորտներում և սկիզբ է առել 1950թ., նախագծի ճկուն կառավարումը ի հայտ է եկել 21-րդ դարում:

 

2001 թվականին ՏՏ և ծրագրային ապահովման ճարտարագիտական ոլորտի հայտնի ծրագրավորողները կազմակերպեցին հանդիպում-քննարկում, որի արդյունքում համաձայնության եկան, թե ինչպես ծրագրային ապահովման մշակման ոլորտը կարող է ավելի լավ արդյունքներ ցուցաբերել:

 

Այս հանդիպման արդյունքում ծրագրային ապահովման ճկուն մշակման համար ձևավորվեց Մանիֆեստ (Manifesto for Agile Software Development ),որը փաստում է այն մասին, որ «ամենաբարձր առաջնահերթությունն այն է, որ պատվիրատուին պետք է բավարարել բարձր գին ունեցող ծրագրային ապահովումը սահմանված ժամկետից շուտ և շարունակական տրամադրման միջոցով»:

 

Նախագծի ճկուն կառավարման զարգացումը անց է կացվում միևնույն աշխատանքային վայրում գտնվող աշխատանքային փոքր խմբի անդամների համագործակցությամբ:

 

Այս հիմնական խումբը սովորաբար ընդգրկում է հետևյալ մասնագետները.

  • երկու ծրագրավորող` ովքեր միասին մշակում, գրում են ծրագրային կոդը (որակի վերահսկման համար)
  • պատվիրատուի ներկայացուցիչ կամ վերջնական օգտվող
  • ՏՏ ճարտարագետ(ներ)
  • գործարար վերլուծաբան
  • նախագծի ղեկավար:

 

Աշխատանքն իրականացվում է մի շարք գործողությունների հաջորդականությամբ` աշխատանքային խումբը  մշակում, գրում է ծրագրային կոդը, ապա փորձարկում է համակարգի աշխատանքային մոդուլները և կրկնում է այս գործընթացը, ըստ անհրաժեշտության:

 

Նախագծի աշխատանքների իրականացման ընթացքում առկա են նվազագույն` քիչ քանակությամբ, փաստաթղթեր, քանի որ աշխատանքային խումբը վստահում և նախընտրում է գրեթե բացառապես ոչ պաշտոնական ներքին հաղորդակցման ձևաչափը:

 

Այսպիսով, կարելի է ասել, որ ճկուն մոտեցումը կրկին տարբերվում է ավանդական մոտեցումից, քանի որ ավանդական մոտեցման ժամանակի զգալի մասը հատկացվում է պլանավորման գործընթացին և ձևավորվում է պահանջների ձևակերպման զգալի քանակությամբ փաստաթղթեր:

 

Նախագծի ճկուն կառավարման աշխատանքային խումբը որոշում և սահմանում է ՏՏ լուծման հնարավորությունների, առանձնահատկությունների առաջնահերթությունները` հաշվի առնելով նրանց արժեքները բիզնես տեսանկյունից, և երբ համակարգի բարձր ռիսկային բաղադրիչները մշակվում են, ապա աշխատանքային խումբը նախ և առաջ աշխատում է ապահովել համակարգի բարձր արժողությամբ հնարավորությունները:

 

Այս մոտեցումը գործում է այն դեպքում, երբ լուծումը պատվիրատուին կարելի է տրամադրել աստիճանաբար: Եթե այդպես հնարավոր չէ, ապա կարելի է համակարգի հնարավորությունները մշակել աստիճանաբար և ապա նոր ինտեգրել համակարգի առաջին թողարկմանը:

 

Ճկուն կառավարման բաղադրիչները

Նախագծի ճկուն կառավարման հիմքն ապահովում են ստորև նշված հիմնական տարրերը: Կարևոր է նշել, որ այս հնարքները (մեխանիզմները) կարող են նաև օգտագործվել ծրագրային ապահովման մշակման ավանդական մեթոդների համար` նախագծի իրականացման բարելավման նպատակով: Հիմնական տարրերը հետևյալն են.

 

1. Տեսանելի վերահսկում

Այս «քարտեր պատի վրա» պլանավորման մեթոդն աջակցում է աշխատանքային խմբին նախագծի իրականացման աշխատանքների կազմակերպման գործում:

 

Օրինակ, նախագծի իրականացման աշխատանքային հաջողակ, ճկուն մի խումբ պատին ամրացրեց տարբեր գույնի քարտերի խմբեր, որոնք ներկայացնում էին լուծման գործառութային մոդուլները` հնարավորությունները:

 

ՏՏ լուծման այն գործառութային մոդուլները` հնարավորությունները, որոնք նախագծված, մշակված, փորձարկված և գործարկման ընթացում էին գտնվում մեկ գույնի էին, իսկ այն գործառութային մոդուլները` հնարավորությունները, որոնք նախագծված, մշակված, փորձարկված, բայց դեռ գործարկման ընթացում չէին (բայց պատրաստ էին գործարկման) մեկ այլ գույնի էին:

 

Այս դեպքում աշխատանքային խումբը կարող էր միանգամից (մեկ ակնթարթում) տեսնել, թե որ փուլում էին նրանք գտնվում յուրաքանչյուր գործառութային մոդուլի դեպքում:

 

Տեսանելի վերահսկումը արդյունավետ հնարք (մեխանիզմ) է բոլոր նախագծերի համար, քանի որ այն ապահովում է, որ աշխատանքային խմբի յուրաքանչյուր անդամ նույն կերպ տեսնի նախագիծը:

 

2. Նույն աշխատանքային վայրում գտնվող բարձր կատարողականություն ունեցող աշխատանքային խմբեր

Ծրագրային ապահովման Ճկուն մշակման ընթացքում, աշխատանքային խմբի հիմնական բոլոր անդամները, այդ թվում նաև պատվիրատուի ներկայացուցիչը կամ վերջնական օգտվողը, գտնվում են նույն աշխատանքային վայրում` ցանկալի է նույն աշխատանքային սենյակում:

 

Այս մոտեցումը մեծապես բարձրացնում է համակարգման և հաղորդակցման որակը: Սակայն այս մոտեցումը ՏՏ մասնագետների, մասնավորապես, ծրագրավորողների համար կարող է աշխատաոճի մշակութային զգալի փոփոխության պատճառ լինել:

 

Ծրագրային ապահովման մշակման ավանդական մեթոդներում ծրագրավորողները սովորաբար աշխատում են ինքնուրույն, անկախ, և հազվադեպ են հաղորդակցվում պատվիրատուի հետ, մինչև որ լուծումը լիովին մշակված չլինի:

 

Քանի որ նախագծի ղեկավարները պատասխանատու են բարձր կատարողականություն ունեցող աշխատանքային խումբ ձևավորելու համար, նրանք պետք է հաշվի առնեն և ապահովեն, որ աշխատանքային խմբի անդամները կարողանան աշխատել միասին, և որ ծրագրավորողները իրոք կարող են աշխատել համագործակցության պայմաններում:

 

3. Փորձարկման վրա հիմնված մշակում

Այն դեպքերում, երբ պատվիրատուն, հաճախորդը դժվարանում է պահանջները հստակ ձևակերպել, աշխատանքային ճկուն խմբերը հաճախ օգտագործում են փորձարկման վրա հիմնված մշակման մեխանիզմը:

 

Որպես օրինակ, դիտարկենք նախագծի իրականացման վերոհիշյալ աշխատանքային հաջողակ, ճկուն խումբը, որը հաճախ առաջին հերթին մշակում էր փորձարկման դեպքերը, օրինակները (test cases) հետո նոր անցնում էր պահանջների սահմանման գործընթացին:

 

Այս մոտեցումը ակնհայտորեն պահանջում է պահանջների սահմանման, նախագծման, մշակման և փորձարկման փուլերի միջև իրականացնել ավելի շատ կրկնվող քայլեր: Այս դեպքում այս ողջ չորս փուլային ցիկլը փլուզվում է:

 

Սակայն ցանկացած դեպքում, աշխատանքային ճկուն խմբերը գրեթե միշտ փորձարկման պլանները մշակում են պահանջների սահմանման հետ միաժամանակ, եթե պահանջը փորձարկման ենթակա չէ, ապա նշանակում է, որ այն դեռ լիովին մշակված չէ:

 

Այս մոտեցումը լավագույն փորձն է (գործելակարգը), որը կարելի է օգտագործել ծրագրային ապահովման ավանդական մշակման ընթացքում` վստահ լինելու համար, որ պահանջները ամբողջական, ճշգրիտ և փորձարկման ենթակա են:

 

4. Հարմարեցվող վերահսկում

Աշխատանքային խմբի յուրաքանչյուր անդամ անընդհատ գտնվում է հարմարվելու գործընթացում, ինչը կարող է խմբի որոշ անդամներին ուղղակիորեն նյարդայնացնել, հատկապես նրանց, ովքեր նախընտրում են համակարգված աշխատաոճը:

 

Այս դինամիկ միջավայրի պատճառով, նախագծի ղեկավարը պետք է լինի առաջնորդ, և ոչ թե ուղղակի ղեկավար անձ կամ հսկիչ: Նախագծի ղեկավարը խիստ հրահանգներ տալու փոխարեն, որոնց պետք է ամբողջ աշխատանքային խումբը հետևի, օժանդակում է աշխատանքային խմբին աշխատանքային հարաբերություններ ձևավորելու հարցում, կանոնակարգում է աշխատանքային գործընթացը և խթանում համագործակցությունը:

 

Աշխատանքային ճկուն խմբի անդամները շարունակ հարմարվում են իրենց մեթոդները բարելավելու գործընթացին, քանի որ նրանք ներառում են ինչպես նախորդ ցիկլից քաղված դասերը հաջորդ կրկնվող քայլում, այնպես էլ ցանկացած նախագծի համար լավագույն փորձը:

 

5. Համագործակցության զարգացում

Նախագծի ճկուն կառավարումը հիմնված է աշխատանքային խմբի բոլոր անդամների միջև առկա համագործակցության վրա` նախագծի շրջանակում մշակված արդյունքները տրամադրելու, դրանց մասին անկեղծ արձագանք ստանալու և ձեռք բերված փորձառությունը լուծման հաջորդ կրկնվող քայլում իրականացնելու նպատակով:

 

Այս մշտական արձագանքները և բարելավման գործընթացը նախագծի ճկուն կառավարման ուժեղ կողմերից մեկն է:

 

Նախագծի ղեկավարն ավարտում է նախնական պլանավորումը, իսկ բիզնես վերլուծաբանը սահմանում է և որոշում լուծման գործառութային մոդուլների` ն հնարավորությունների առաջնահերթությունները պատվիրատուի և ՏՏ ներկայացուցիչների հետ համատեղ:

 

Այնուհետև նախագծի աշխատանքային ճկուն խմբերը համագործակցում են յուրաքանչյուր գործառութային մոդուլի նախագծման, զարգացման, փորձարկման և սխալների ուղղման շուրջ:

 

Նախագծի հաջողությանը խթանում է պատվիրատուի, հաճախորդի հետ մշտական համագործակցությունը:

 

6. Հնարավորությունների մշակում

Այս մոտեցումը զգալիորեն նվազեցնում է առկա բարդությունը, քանի որ այն աշխատանքային խմբին թույլ է տալիս, տվյալ ժամանակահատվածում, կենտրոնանալ միայն և միայն մեկ հնարավորության` գործառութային մոդուլի, մշակման աշխատանքների վրա:

 

Օրինակ, եթե աշխատանքային խումբը կատարում է 4-րդ հնարավորության` գործառութային մոդուլի, մշակման աշխատանքները, ապա այդ խմբի ուշադրության կենտրոնում միայն այդ հնարավորության մշակումն է: Նրանք չեն առնչվում 1-ից 3-րդ հնարավորությունների` գործառութային մոդուլների, մշակման աշխատանքներին: Բիզնես վերլուծաբանը և նախագծի ղեկավարը` հաշվի առնելով բիզնես արժեքը և ռիսկային գործոնը, հաստատում են, որ պատվերների գրանցամատյանում առկա հաջորդ հնարավորության` գործառութային մոդուլի, մշակման աշխատանքները իսկապես հաջորդ առաջնահերթությունն է:

 

Սովորաբար, առաջնահերթ ստեղծվում են բարձր ռիսկայնություն ունեցող կամ ենթակառուցվածքի հիմնական բաղադրիչները, և ապա նոր սահմանվում է մնացած մոդուլների ստեղծման առաջնահերթությունը` հաշվի առնելով նրանց բիզնես արժեքը:

 

Հնարավորությունների` գործառութային մոդուլների, բաղադրիչները նպատակահարմար է ստեղծել այնպես, որ նրանք` հիմնական համակարգի նկատմամբ, ունենան միայն միակողմանի կախվածություն, հետևաբար, ստացվում է, որ առանձնահատուկ բաղադրիչները անկախ են և կարող են ստեղծվել ցանկացած հերթականությամբ կամ նույնիսկ` զուգահեռ:

 

7. Առաջնորդություն և համագործակցություն այլ ոչ թե կարգադրություն և վերահսկում

 

 

«Նախագծի ճկուն կառավարման սկզբունքներն անվերջ են: Այն ավելի շատ առնչվում է առաջնորդության
(ղեկավարության) հետ: Նախագծի ճկուն կառավարումն անդրադառնում է քայլերի,
որոնք ավելի շատ օժանդակում են առաջնորդությանը (ղեկավարությանը),
քան ավանդական կառավարմանը»

 

Սենջիվ Ավգուստին
Գործադիր տնօրեն
Lean-Agile Consulting Practice at CC Pace Systems in Fairfax,
VA խորհրդատվական ընկերություն

 

Նախագծի ղեկավարը աշխատում է պատվիրատուի և ՏՏ կառավարման ներկայացուցիչների և հիմնական շահառուների հետ` վստահ լինելու համար, որ նրանք տեղեկացված են նախագծի կարգավիճակի մասին:

 

Բացի այդ, նախագծի ղեկավարը վերացնում է ցանկացած խոչընդոտ, որը խանգարում է հիմնական աշխատանքային ճկուն խմբերին:

 

Բիզնես վերլուծաբանը ղեկավարում է նախագծի բիզնես առավելությունները և աշխատանքային ճկուն խմբերի ուշադրությունը մշտապես կենտրոնացնում է բիզնես կարիքների վրա:

 

8. Անցում գնից դեպի եկամուտներ

Հնարավորությունների` գործառութային մոդուլների, առաջնահերթությունը սահմանվում է այնպիսի արժեքի հիման վրա, ինչպիսիք են աճող եկամուտը կամ շուկայի մասնաբաժինը:

 

Բիզնես վերլուծաբանի դերն է ապահովել, որ նախագծի աշխատանքային ճկուն խումբը չափազանց շատ ներդրումներ չունենա նոր լուծման մշակման ընթացքում: Քանի որ այդպիսի ներդրման դեպքում նրանք տապալած կլինեն պատվերը (բիզնես դեպքը, business case) և նախագիծը կարժենա ավելի, քան կազմակերպությունը ձեռք կբերի:

 

Մինչ նախագծի ղեկավարը կենտրոնացած է նախագծի ծախսերի պլանավորման և կառավարման վրա, բիզնես վերլուծաբանը անդրադառնում է սեփականության ընդհանուր արժեքին, որը ներառում է ոչ միայն նոր լուծման մշակման կամ ձեռքբերման ծախսերը, այլև օպերացիոն համակարգի արժեքը այն կիրարկելուց հետո:

 

9. Քաղված դասեր

Յուրաքանչյուր ցիկլից հետո, աշխատանքային խումբը անց է կացնում քաղված դասերի վերաբերյալ հանդիպում-քննարկումներ որոշելու համար, թե նրանք ինչ կարող են բարելավել հաջորդ կրկնվող քայլի համար: Քանի որ աշխատանքային խումբը յուրաքանչյուր քայլի ընթացքում բացի գիտելիքներ և փորձ ձեռք բերելուց նաև հարմարվում է աշխատանքային խմբի համատեղ աշխատաոճին, ապա արդյունքում խմբի կատարած աշխատանքները շարունակաբար բարելավում են:

 

Արժեքի հիմնավորում

 

«Նախագծի ավանդական կառավարման մոտեցումը գծային մոտեցում է, որտեղ փորձում եք ամեն ինչ կատարել միանգամից:
Դուք միանգամից, նախապես կատարում եք շատ մանրամասն պլանավորում, և ապա տրամադրում այն,
ինչպես ասում են «Մեծ պոռթկումով» («Big Bang»): Ոլորտի մտածելակերպը
ծրագրային ապահովման մշակումից տարածվել է նաև այլ ծրագրերի համար»:

Սենջիվ Ավգուստին

 

 

Այս մոտեցումը նախագծերի ճկուն և ավանդական կառավարման միջև տարբերության հիմքն է: Այժմ «Մեծ պոռթկումը» առաջանում է ավելի մեծ ճկունության և համագործակցության արդյունքում, որն ապահովում է նախագծերի ճկուն կառավարումը:

 

Նախապես կատարվում է «միայն բավականաչափ» պլանավորում: Քանի որ համակարգի յուրաքանչյուր գործառութային մոդուլ աստիճանաբար է մշակվում, ապա աշխատանքային խումբը հավաքագրում է մուտքային տվյալները և ձեռք է բերում փորձառություն պատվիրատուի կողմից կատարված արձագանքների և կարծիքների վերլուծության արդյունքում:

 

Քանի որ պատվիրատուն տեսնում և / կամ  փորձարկում է աշխատանքային նախատիպը, նա ավելի լավ է կարողանում արդիականացնել կամ վերասահմանել պահանջները և նկարագրել աշխատանքային խմբին, թե կազմակերպությունն իսկապես ինչի կարիք ունի:

 

Ճկուն մեթոդը ընդգրկում է այն փոփոխությունները, որոնք ավելացնում են արժեքը, և կրկնվող զարգացման միջոցով նվազեցնում է փոփոխության գինը:

Փոքրիկ մոդուլում փոփոխություններ կատարելն ավելի շահավետ է, համեմատած հսկայական համակարգ նախագծելու ու զարգացնելու և ապա նոր նրանում փորձելու որոշ փոփոխություններ կատարելու հետ:

 

Նախագծի ճկուն կառավարումը կարո՞ղ է աշխատել

 

«Նախագծի կառավարման հիմքում, թե ավանդական, թե ճկուն կառավարման դեպքում, առկա են շատ նման սկզբունքներ:
Այն պատվիրատուի, հաճախորդի համար լավ աշխատանք կատարելու մասին է:
Այն աշխատանքային խումբը ղեկավարելու մասին է:
Այն չափելի բիզնես արդյունքներ տրամադրելու մասին է»:

Սենջիվ Ավգուստին

 

 

Այս սկզբունքներից կամ գործելակերպերից շատերը կարող են իրականացվել թիմային կառուցվածք ունեցող միջավայրերից մեծամասնությունում: Այնուհանդերձ, նախագծի կառավարման որոշ մասնագետներ կարող են հրաժարվել կառավարման ճկուն սկզբունքներից, եթե նրանք չեն կարողանում ընդունել բոլոր բաղադրիչները և փորձը: Այս մոտեցումը սխալ է:

 

Օրինակ, ի՞նչ է պատահում, եթե նրանք չեն կարող օգտվողին ամբողջ աշխատանքային օրվա ընթացքում պահել աշխատանքային խմբի հետ միևնույն աշխատանքային սենյակում:

Դա չի նշանակում, որ նրանք չեն կարող միավորել ճկուն կառավարման վերը նշված որոշ տարրեր, ինչպիսիք են օրինակ տեսանելի վերահսկումը և հնարավորությունների մշակումը:

 

Բացի այդ, եթե նույնիսկ օգտվողը չի կարող ներգրավվել ամբողջ աշխատանքային օրվա հասանելիությամբ, ապա օգտվողների մեծ մասը պատրաստ է մասնակցել խմբի աշխատանքներին, հատկապես փորձարկման և հնարավորությունների` գործառութային մոդուլների, մշակման, առաջնահերթությունների սահմանման ընթացքում: Բիզնես վերլուծաբանը հետո կարող է օգտվողին ներկայացնել, մինչդեռ ամբողջ աշխատանքային օրվա հասանելիությամբ հիմնական թիմը շարունակում է միասին աշխատել:

 

Ամփոփում

Այսպիսով ճկուն կառավարման հնարքները նախագծերի կառավարման գործընթացում ընդգրկելը նպաստում է յուրաքանչյուր հնարավորության` գործառութային մոդուլի, առավելությունների վրա ուշադրության կենտրոնացմանը:

 

Նախագծի ավանդական կառավարման ժամանակ, խմբերը ձգտում են ավարտել նախագծերը ժամանակին և առկա բյուջեի շրջանակներում և հաճախ կորցնում են ընդհանուր առավելությունների պատկերը, որին ուղղված են ընկերության ողջ ջանքերը:

 

Կարևոր է հիշել այն ռազմավարությունը, որն ակնկալվում է, որ նախագիծը պետք է առաջ տանի, ինչպես նաև սեփականության ընդհանուր արժեքը և ոչ թե միայն նախագծի ծախսերը:

 

Այսպիսով նախագծի առավելությունները ակնհայտ կլինեն, անկախ նրանից թե աշխատանքային խումբը շենք է կառուցում, թե նոր բիզնես լուծում է մշակում:






 
 
© 2017 Association of Modern Technologies Professionals