Բարդ նախագծերը մի անհարմար պարադոքս ունեն։ Ընկերությունում կարող են աշխատել ուժեղ մասնագետներ, լինել հստակ ռազմավարություն, փորձառու տեխնոլոգիական թիմ, պրոֆեսիոնալ մարքեթինգ, լավ պրոդուկտ և առաջին դեմքի աջակցություն։ Յուրաքանչյուր ֆունկցիա առանձին կարող է իր աշխատանքը կատարել բարձր մակարդակով, բայց նախագիծը միևնույն է սկսում է դանդաղել, որոշումները՝ բախվել միմյանց, ժամկետները՝ սահել, իսկ վերջնական արդյունքը՝ լինել ներդրված ջանքերի գումարից ավելի թույլ։ Սովորաբար պատճառը սկսում են փնտրել հենց ֆունկցիաների ներսում։ Վերանայում են IT-ի աշխատանքը, փոխում գործընթացները, ուժեղացնում project management-ը, հստակեցնում KPI-ները, ավելացնում հանդիպումները։ Բայց երբեմն իրական խնդիրը բոլորովին այլ տեղում է։
Այն գտնվում է ֆունկցիաների միջև։ Հենց այնտեղ է ռազմավարությունը պետք է դառնա պրոդուկտ։ Պրոդուկտը՝ տեղավորվի տեխնոլոգիական ճարտարապետության մեջ։ Տեխնոլոգիան՝ հաշվի առնի հաճախորդի վարքագիծը։ Մարքեթինգը՝ հստակ իմանա, թե ինչ է իրականում դուրս գալու շուկա և երբ։ Customer Service-ը՝ հասկանա ապագա հաճախորդային ճանապարհը։ Իսկ տարբեր ստորաբաժանումների որոշումները պետք է միավորվեն մեկ համակարգի մեջ ավելի շուտ, քան յուրաքանչյուրը սկսի օպտիմալացնել միայն իր հատվածը։ Բարդ նախագծերի հետ տարիների աշխատանքի ընթացքում ես այս տարածքը ավելի ու ավելի եմ ընկալում որպես առանձին մասնագիտական ոլորտ։ Ես այն անվանում եմ Strategic Project Architecture։
Որքան բարդ է նախագիծը, այնքան քիչ է դրա արդյունքը պատկանում մեկ առանձին ֆունկցիայի, և այնքան ավելի կարևոր է դառնում այդ ֆունկցիաների միջև կապերի ճարտարապետությունը։
Մոբայլ բանկը՝ որպես կազմակերպական ճարտարապետության փորձություն
Այս երևույթը հատկապես պարզ տեսա Converse Bank-ի հետ աշխատանքի ընթացքում։ Առաջին հայացքից խնդիրը բավական ծանոթ էր թվում՝ զարգացնել մոբայլ բանկը։ Բայց մոբայլ բանկը վաղուց արդեն պարզապես IT պրոդուկտ չէ։ Բանկի համար այն միաժամանակ տեխնոլոգիա է, պրոդուկտային ալիք, հաճախորդի հիմնական ինտերֆեյս, վաճառքի գործիք, բրենդի մի մաս, հաղորդակցության միջավայր և գնալով ավելի հաճախ՝ հաճախորդի ամենօրյա հիմնական շփման կետը ընկերության հետ։
Այս բոլոր շերտերը գտնվում էին տարբեր մարդկանց և տարբեր ֆունկցիաների պատասխանատվության դաշտում։ Տեխնոլոգիական թիմը պատասխանատու էր իրականացման և կայունության համար։ Retail-ը՝ բանկային պրոդուկտների և բիզնես տրամաբանության։ Marketing-ը՝ առաջարկի, հաղորդակցության և ընկալման։ UX-ը՝ օգտատիրոջ սցենարների։ Տեղեկատվական անվտանգությունը՝ սահմանափակումների և ռիսկերի։ Customer Service-ը՝ այս բոլոր որոշումների իրական հետևանքների՝ հաճախորդների հետ ամենօրյա շփման մեջ։ Այդ պատճառով մոբայլ բանկի զարգացումը շատ արագ դադարեց լինել միայն development-ի հարց։ 2023 թվականի սկզբին բանկի CEO-ն առաջարկեց փոխել այս ուղղության կառավարման գործող մոդելը։ Ի պատասխան ես առաջարկեցի ստեղծել CFT՝ մշտական cross-functional team, որը կառուցված կլիներ հենց պրոդուկտի շուրջ։
Մոդելը աջակցություն ստացավ, իսկ Retail-ի և mobile development-ի ղեկավարները հատկապես խորությամբ ներգրավվեցին դրա հետագա աշխատանքի մեջ։ Ինձ համար այդ որոշման նշանակությունը շատ արագ դուրս եկավ մեկ կոնկրետ նախագծի սահմաններից։ Մենք փաստացի փոխեցինք կառավարման օբյեկտը։ Մինչ այդ մոբայլ բանկը հեշտ էր ընկալել որպես առաջադրանքների հերթականություն, որոնք բիզնեսից անցնում են IT, IT-ից՝ մարքեթինգ և այդպես շարունակ՝ կազմակերպական շղթայով։
Նոր մոդելում ձևավորվեց ընդհանուր որոշումների կոնտուր, որի ներսում հնարավոր էր պրոդուկտը տեսնել ամբողջությամբ։ Սա արդեն սկզբունքորեն այլ ճարտարապետություն է։
Ամենաթանկ սխալը՝ համակարգի մի մասը կառավարել որպես ամբողջ համակարգ
Ընկերությունների մեծ մասը կառուցված է ֆունկցիոնալ սկզբունքով։ Դա տրամաբանական է։ Ֆինանսները պետք է լավ զբաղվեն ֆինանսներով։ IT-ն՝ տեխնոլոգիաներով։ Marketing-ը՝ մարքեթինգով։ Retail-ը՝ բիզնեսով։ Խնդիրը սկսվում է այն պահին, երբ ընկերության իրական արդյունքը այլևս չի տեղավորվում կազմակերպական կառուցվածքի սահմաններում։ Հաճախորդը ստորաբաժանումներ չի տեսնում։
Նա տեսնում է մեկ մոբայլ բանկ։ Նրա համար կարևոր չէ, թե որ թիմն էր պատասխանատու կոնկրետ էկրանի համար, ով էր համաձայնեցնում տեքստը, ով էր սահմանում բիզնես կանոնը կամ ով էր զբաղվում ինտեգրմամբ։ Եթե հավելվածը անհարմար է, հաճախորդի համար անհարմար է բանկը։ Եթե հաղորդակցությունը խոստանում է մի բան, իսկ պրոդուկտը գործում է այլ կերպ, հաճախորդի աչքում սխալվել է ընկերությունը։
Միևնույն ժամանակ կազմակերպության ներսում կարող են աշխատել առանձին թիմեր, որոնցից յուրաքանչյուրը ֆորմալ առումով իր աշխատանքը ճիշտ է կատարել։ Այդ պատճառով բարդ նախագծի ամենակարևոր հարցերից մեկը չափազանց պարզ է հնչում։
ո՞վ է պատասխանատու այն արդյունքի համար, որը գոյություն ունի ֆունկցիաների միջև։
Սովորաբար այս հարցը ակնհայտ պատասխան չունի։ Project manager-ը պատասխանատու է նախագծի շարժման համար։ Product owner-ը՝ պրոդուկտի։ Ֆունկցիոնալ ղեկավարները՝ իրենց ուղղությունների։ CEO-ն՝ ամբողջ բիզնեսի։ Բայց ո՞վ է նախագծում այս մակարդակների միջև կախվածությունների ամբողջ համակարգը։ Հենց այստեղ է սկսվում Strategic Project Architecture-ի տարածքը։
Ուժեղ մասնագետները ինքնուրույն ուժեղ համակարգ չեն ստեղծում
Converse Mobile-ում սա կրկնվում էր տարբեր իրավիճակներում։ Վերցնենք տեղեկատվական անվտանգությունը։ Ցանկացած լուրջ security որոշում ունի տեխնիկական կողմ։ Բայց մոբայլ բանկում այն գրեթե անխուսափելիորեն ազդում է նաև հաճախորդի վրա։ Փոխվում է անվտանգության կանոնը՝ կարող է փոխվել մուտքի սցենարը։ Փոխվում է մուտքի սցենարը՝ պետք է փոխվի հաճախորդին տրվող բացատրությունը։ Այդ բացատրությունն արդեն առնչվում է ինտերֆեյսին, տեքստերին, Customer Service-ին և երբեմն՝ մարքեթինգային հաղորդակցությանը։
Տեխնիկապես ճիշտ լուծումը պետք է անցնի մի քանի մասնագիտական «լեզուներով», մինչև դառնա նորմալ հաճախորդային փորձ։ Նույնը տեղի էր ունենում UX-ի հետ։ Կարելի է անցկացնել որակյալ user research։ Կարելի է ստանալ ուժեղ դիզայն։ Կարելի է ստեղծել շատ լավ պրոտոտիպեր։ Բայց հետազոտության և աշխատող պրոդուկտի միջև կա որոշումների երկար շղթա։
Հետազոտության ո՞ր արդյունքն է դառնում պրոդուկտային առաջնահերթություն։ Ի՞նչն է պահանջում բիզնես տրամաբանության փոփոխություն։ Ի՞նչն է տեխնոլոգիապես իրագործելի։ Ի՞նչը պետք է մտնի տվյալ development cycle-ի մեջ։ Ինչպե՞ս է նոր լուծումը ազդելու գործող սցենարների վրա։ Եվ ինչպե՞ս այն պետք է բացատրվի օգտատիրոջը։ Հետազոտությունն ինքն իրեն պրոդուկտ չի փոխում։ Դիզայնը՝ նույնպես։ Արժեքը ստեղծվում է այն պահին, երբ տարբեր դիսցիպլինները միավորվում են մեկ հետևողական որոշումների գործընթացում։
Բարդ նախագծերը հազվադեպ են ձախողվում մասնագետների բացակայության պատճառով։ Ավելի հաճախ դրանք կորցնում են արագությունն ու որակը այն պահին, երբ որոշումը փոխանցվում է մի մասնագիտական աշխարհից մյուսը։
Ճարտարապետական բացը
Ժամանակի ընթացքում նման իրավիճակների համար ես սկսեցի օգտագործել ճարտարապետական բաց հասկացությունը։ Դա այն պահն է, երբ նախագծի անհրաժեշտ բաղադրիչները գոյություն ունեն, բայց դրանց միացման մեխանիզմը բավարար չափով սահմանված չէ։ Կա ռազմավարություն։ Կան թիմեր։ Կա բյուջե։ Կա roadmap։ Կա պատասխանատվություն յուրաքանչյուր ստորաբաժանման ներսում։ Բայց մնում են հարցեր, որոնք բառացիորեն ընկնում են այդ սահմանների արանքը։
Ո՞վ է որոշում, երբ բիզնեսն ու տեխնոլոգիան առաջարկում են երկու հավասարապես հիմնավորված տարբերակ։ Ո՞վ է որոշում քայլերի հաջորդականությունը, երբ մի թիմի աշխատանքը կախված է մյուս թիմի որոշումից։ Ե՞րբ պետք է մարքեթինգը ստանա տեղեկատվություն առաջիկա release-ի մասին։ Ինչպե՞ս է հաճախորդի feedback-ը դառնում պրոդուկտային առաջնահերթություն։
Ո՞վ է տեսնում, որ մեկ ստորաբաժանման ներսում արդյունավետ լուծումը ամբողջ համակարգի համար խնդիր է ստեղծում։ Սրանք ճարտարապետական հարցեր են։ Եվ հերթական հանդիպումը սովորաբար չի լուծում դրանք։ Խնդիրը հազվադեպ է այն, որ մարդիկ քիչ են շփվում։ Երբեմն նրանք նույնիսկ չափազանց շատ են շփվում։
Խնդիրը այն կառուցվածքի բացակայությունն է, որը սահմանում է՝ որ որոշումները պետք է ընդունվեն համատեղ, որտեղ է ownership-ը և ինչպես են միմյանցից կախված որոշումները վերածվում նախագծի մեկ ընդհանուր շարժման։
Ինչու project management-ը այստեղ բավարար չէ
Լավ project management-ը հսկայական արժեք ունի։ Այն օգնում է կառավարել ժամկետները, առաջադրանքները, ռեսուրսները, կախվածությունները և կատարումը։ Բայց կա աշխատանքի մի մակարդակ, որը հայտնվում է մինչև task list-ը։ Պատկերացնենք իրավիճակ։
Business-ը ցանկանում է շուկա դուրս բերել նոր պրոդուկտ։ Technology-ն տեսնում է ճարտարապետական սահմանափակում։ UX-ը հասկանում է, որ սկզբնական հաճախորդային սցենարը անհարմար է լինելու։ Marketing-ն արդեն կառուցում է հաղորդակցությունը այդ պրոդուկտի շուրջ։
Management-ը launch-ից սպասում է կոնկրետ կոմերցիոն արդյունք։ Ի՞նչ է պետք այդ իրավիճակում ավելացնել task tracker-ում։ Նախ պետք է որոշել հենց լուծման կառուցվածքը։ Գուցե պետք է փոխել պրոդուկտը։
Գուցե՝ development-ի հաջորդականությունը։ Գուցե՝ առաջարկը։ Գուցե՝ ժամկետների սպասումները։ Գուցե նույնիսկ՝ արդյունքը չափելու եղանակը։
Միայն դրանից հետո նախագիծը նորից դառնում է կառավարելի առաջադրանքների համակարգ։ Հենց այստեղ եմ ես տեսնում կարևոր տարբերությունը։
Project management-ը կազմակերպում է արդեն ընտրված կառուցվածքի կատարումը։ Strategic Project Architecture-ը օգնում է ստեղծել այդ կառուցվածքը։
Ինչ է իրականում անում Strategic Project Architect-ը
Ես այս տերմինն օգտագործում եմ որպես աշխատանքի նկարագրություն, ոչ թե որպես նոր, գեղեցիկ պաշտոն։ Strategic Project Architect-ի առաջին խնդիրն է կառավարման օբյեկտը մեծացնել մինչև դրա իրական չափը։ Երբ ընկերությունն ասում է՝ «մենք նոր հավելված ենք ստեղծում», իրական նախագիծը կարող է ներառել պրոդուկտային մոդել, օպերացիոն գործընթացներ, տեխնոլոգիա, customer experience, մարքեթինգ, աջակցություն, տվյալներ և աշխատակիցների վարքագծի փոփոխություն։ Եթե կառավարվում է միայն հավելվածը, նախագծի իրական ծավալի մեծ մասը դուրս է մնում ընդհանուր ճարտարապետությունից։
Երկրորդ խնդիրը կախվածությունները տեսնելն է ավելի շուտ, քան դրանք կվերածվեն խնդիրների։ Ո՞ր որոշումն է բացում հաջորդի հնարավորությունը։ Ի՞նչը չի կարելի անել զուգահեռ։ Ո՞ր ֆունկցիաները պետք է պայմանավորվեն մինչև իրականացումը սկսելը։ Որտե՞ղ է համակարգի մի մասի փոփոխությունը ինքնաբերաբար փոխում մյուսը։ Երրորդը՝ ստեղծել որոշումների ճարտարապետությունը։ Բարդ նախագծերում քիչ է պարզապես սահմանել, թե ով ինչ է անում։
Շատ ավելի կարևոր է սահմանել, թե ով ում հետ է որոշում կայացնում, ինչ մակարդակում և ինչ հարցերի շուրջ։ Չորրորդը՝ ստեղծել ընդհանուր աշխատանքային արտեֆակտներ։ Դա կարող է լինել blueprint, roadmap, decision register, matrix, միասնական design system կամ մեկ այլ գործիք։ Անվանումը երկրորդական է։ Լավ արտեֆակտը կատարում է մեկ հիմնական գործառույթ՝ տարբեր պրոֆեսիոնալ թիմերը սկսում են աշխատել իրականության մեկ ընդհանուր տարբերակի հետ։
Եվ հինգերորդ խնդիրը, թերևս ամենաբարդը, ընդհանուր արդյունքը տեղային օպտիմալացումից պաշտպանելն է։ Գրեթե ցանկացած ստորաբաժանում կարող է ապացուցել, որ իր կոորդինատային համակարգի ներսում գործում է տրամաբանորեն։ Բայց դա պարտադիր չէ, որ նախագիծը դարձնի ավելի լավը։
CFT-ն ավելի շատ հանդիպումներ անցկացնելու միջոց չէր
Converse Mobile-ում cross-functional team-ի իմաստը հենց սա էր։ Մենք չէինք փորձում պրոֆեսիոնալ ֆունկցիաները փոխարինել մեկ «ընդհանուր» թիմով։ Նրանց փորձագիտական ուժը մնում էր իր տեղում։ Փոխվում էր կապերի համակարգը։
Retail-ը բերում էր բիզնես տրամաբանությունն ու պրոդուկտի ընկալումը։ Mobile development-ը՝ տեխնոլոգիական հնարավորություններն ու սահմանափակումները։ Marketing-ը՝ հաճախորդին, առաջարկը և հաղորդակցությունը։ Մյուս ֆունկցիաները միանում էին այնտեղ, որտեղ որոշումը պահանջում էր իրենց փորձագիտական մասնակցությունը։ Ձևավորվեց ընդհանուր կոնտուր, որտեղ հակասությունները հնարավոր էր տեսնել ավելի շուտ և քննարկել որպես մեկ պրոդուկտի խնդիր։ Հետագայում նույն համակարգին ավելի խորը սկսեցին միանալ հետազոտությունը, UX-ը, հաճախորդների feedback-ը, դիզայնը և նոր պրոդուկտային որոշումները։ Այս մոդելի ամենակարևոր արդյունքը ես նույնիսկ առանձին release-ը չեմ համարում։
Ավելի հիմնարար բան փոխվեց։ Կազմակերպության ներսում մոբայլ բանկը սկսեց գոյություն ունենալ որպես մեկ միասնական պրոդուկտ, այլ ոչ թե տարբեր ստորաբաժանումների միջև բաշխված առաջադրանքների հավաքածու։ Սա կառուցվածքային փոփոխություն է։
Երբ բոլորը ճիշտ են, նախագիծը հատկապես խոցելի է
Կան նախագծեր, որոնց խնդիրները տեսանելի են անմիջապես։ Չկան բավարար ռեսուրսներ։ Թիմը սխալվել է։ Տեխնոլոգիան չի աշխատում։ Ռազմավարությունը հստակ չէ։ Դրանք ցավոտ իրավիճակներ են, բայց ախտորոշումը համեմատաբար պարզ է։ Ավելի բարդ է այն նախագիծը, որտեղ յուրաքանչյուրը իր տրամաբանության մեջ ճիշտ է։
IT-ն հիմնավորված կերպով պաշտպանում է ճարտարապետությունը։ Business-ը հիմնավորված կերպով պահանջում է կոմերցիոն արդյունք։ Marketing-ը հիմնավորված կերպով մտածում է հաճախորդի և շուկայի մասին։ InfoSec-ը հիմնավորված կերպով սահմանափակում է ռիսկը։
UX-ը հիմնավորված կերպով պահանջում է օգտագործելիություն։ Կառավարչական խնդիրը սկսվում է այն պահին, երբ այս բոլոր մասնագիտական ճիշտ դիրքորոշումները պետք է վերածվեն մեկ որոշման։ Այդ պատճառով այսօր, երբ մտնում եմ բարդ նախագիծ, առաջին հերթին չեմ նայում առաջադրանքների ցանկին։ Ես նայում եմ կապերին։
Որտե՞ղ է արդյունքի ownership-ը։ Ո՞ր որոշումներն են հատում մի քանի ֆունկցիաների սահմանները։ Որտե՞ղ են տարբեր թիմերը նույն խնդրի համար օգտագործում տարբեր սահմանումներ։ Ո՞ր կախվածություններն ամբողջությամբ ոչ ոք չի տեսնում։
Ո՞ր պահին մեկ թիմի մասնագիտորեն ճիշտ որոշումը կարող է վատացնել ընդհանուր արդյունքը։ Շատ հաճախ նախագծի իրական խնդիրը հենց այնտեղ է։
Արդյունքի ճարտարապետությունը
Վերջին տարիներին բարդ նախագծերի վերաբերյալ իմ պատկերացումը զգալիորեն փոխվել է։ Ես դրանք ավելի քիչ եմ ընկալում որպես առաջադրանքների հաջորդականություն և ավելի շատ՝ որպես փոխկապակցված որոշումների համակարգ։ Ռազմավարությունը ձևավորում է պրոդուկտը։ Պրոդուկտը փոխում է տեխնոլոգիան։ Տեխնոլոգիան ձևավորում է customer experience-ը։ Customer experience-ը ազդում է հաղորդակցության և վաճառքի վրա։ Հաճախորդի իրական վարքագիծը վերադառնում է պրոդուկտ և նորից փոխում ռազմավարական որոշումները։ Այս համակարգը միաժամանակ ապրում է մի քանի մասնագիտական աշխարհներում։
Այդ պատճառով դրա ամբողջականության համար պատասխանատու մարդը պարտադիր չէ լինի սենյակի լավագույն ծրագրավորողը, լավագույն մարքեթոլոգը կամ լավագույն product expert-ը։ Նրա խնդիրը այլ է։ Նա պետք է յուրաքանչյուր դիսցիպլինից հասկանա այնքան, որ տեսնի դրանց միջև եղած տարածքը։ Եվ ժամանակին նկատի այն պահը, երբ նախագիծը դադարում է լինել մասնագիտական որոշումների հավաքածու և արդեն պահանջում է ճարտարապետություն, որը դրանք կվերածի մեկ արդյունքի։
Ինձ համար հենց սա է նշանակում Strategic Project Architect։
Բարդ նախագծի ուժը որոշվում է ոչ միայն դրա առանձին մասերի որակով, այլ նրանով, թե որքան լավ են այդ մասերը կարողանում աշխատել որպես մեկ համակարգ։
Այսօր ընկերությունները ավելի ու ավելի հաճախ նման համակարգերը հավաքում են տարբեր աղբյուրներից։ Ուժեղ IT թիմ կարելի է ներգրավել շուկայից։ UX/UI-ն՝ վստահել մասնագիտացված գործակալության։ Ընկերության ներսում արդեն աշխատում են Retail-ը, Marketing-ը, Finance-ը, Compliance-ը, Operations-ը։ Իսկ ներդրողը կամ սեփականատերը բերում է գաղափարը, ամբիցիան, բյուջեն և ժամկետը։ Խնդիրը սկսվում է այն պահին, երբ այս բոլոր ուժեղ մասնակիցները պետք է վերածվեն մեկ նախագծի։ Ո՞վ է միացնելու բիզնես տեսլականը տեխնոլոգիական ճարտարապետության հետ։ Ո՞վ է հետևելու, որ պրոդուկտը, customer experience-ը, օպերացիոն մոդելն ու հաղորդակցությունը զարգանան համաժամանակյա։ Ո՞վ է նկատելու երկու մասնագիտորեն ճիշտ որոշումների հակասությունը մինչև այն կվերածվի թանկարժեք վերանայման։ Եվ ո՞վ է տեսադաշտում պահելու ոչ թե առանձին workstream-ները, այլ ամբողջ արդյունքը՝ սկզբնական գաղափարից մինչև այն պահը, երբ լուծումն իրականում սկսում է աշխատել մարդկանց համար։
Յուրաքանչյուր մեծ նախագծի համար բոլոր անհրաժեշտ կարողությունները մեկ ընկերության ներսում կառուցելը հաճախ չափազանց երկար և չափազանց թանկ է։ Ժամանակակից շուկան վաղուց սովորել է լավագույն մասնագիտացված փորձագիտությունը ներգրավել դրսից։ Բայց որքան շատ նման փորձագիտություններ են միավորվում մեկ նախագծում, այնքան ավելի մեծ արժեք է ստանում դրանց օրկեստրացիան։ Հենց այս ըմբռնումից էլ ես հիմնեցի USPACE-ը։ USPACE-ը աշխատում է սեփականատերերի, ներդրողների և ընկերությունների ղեկավարների հետ, ովքեր նախաձեռնում են բարդ ինտեգրված նախագծեր և ցանկանում են ամբիցիայից հասնել աշխատող արդյունքի՝ պահպանելով ժամկետների, ներդրումների և որոշումների կառավարելիությունը։ Մենք կարող ենք աշխատել ընկերության ներքին թիմերի, տեխնոլոգիական գործընկերների, գործակալությունների, խորհրդատուների և այլ արտաքին փորձագետների կողքին։ Մեր խնդիրը այս ուժեղ բաղադրիչներից մեկ աշխատող նախագծային ճարտարապետություն հավաքելն է և դրա ամբողջականությունը պահպանելը այն ընթացքում, երբ նախագիծը դառնում է ավելի բարդ։
Որովհետև վերջում նշանակություն չունի, թե քանի թիմ է ներգրավված եղել, որքան փաստաթուղթ է ստեղծվել կամ նույնիսկ արդյոք լուծումը ֆորմալ առումով launch է արվել։ Կարևորն ուրիշ բան է։ Իրականացվե՞լ է այն տեսլականը, որի համար նախագիծը սկսվել էր։ Մնացե՞լ է այն ողջամիտ ժամկետների և ներդրումային տրամաբանության սահմաններում։ Եվ ամենակարևորը՝ մարդիկ՝ արտաքին հաճախորդները կամ աշխատակիցները, ստացե՞լ են լուծում, որն իրականում օգտագործում են։ Երբ դա տեղի է ունեցել, նախագիծն ավարտված է։
Մինչ այդ արդյունքի ճարտարապետությունը դեռ պահանջում է կառավարում։
