Բարև ընկերներ։ Շատ հաճախ, հատկապես աութսորսինգում, նույն պատկերն եմ տեսնում։ Տարբեր նախագծերի վերաբերյալ թիմերում հստակ աշխատանքային հոսքի բացակայություն:
Ամենակարևորն այն է, որ ծրագրավորողները չեն հասկանում, թե ինչպես շփվել հաճախորդի և միմյանց հետ: Ինչպես կառուցել որակյալ արտադրանքի մշակման շարունակական գործընթաց: Ինչպես պլանավորել ձեր աշխատանքային օրը և սպրինտները:
Եվ այս ամենն, ի վերջո, հանգեցնում է խախտված ժամկետների, արտաժամյա աշխատանքի, մշտական ցուցադրությունների, թե ով է մեղավոր, և հաճախորդների դժգոհությունը՝ որտեղ և ինչպես է ամեն ինչ շարժվում: Շատ հաճախ այս ամենը հանգեցնում է ծրագրավորողների և նույնիսկ ամբողջ թիմերի փոփոխության: Հաճախորդի կորուստ, հեղինակության վատթարացում և այլն։
Ժամանակին ես հենց նոր մտա մի այնպիսի նախագծի, որտեղ կային այս բոլոր հրճվանքները։
Ոչ ոք չէր ուզում պատասխանատվություն ստանձնել նախագծի համար (ծառայությունների մեծ շուկա), շրջանառությունը սարսափելի էր, հաճախորդը պարզապես պատռեց և նետեց: Գործադիր տնօրենը մի կերպ մոտեցավ ինձ և ասաց, որ դու ունես անհրաժեշտ փորձ, ուստի քարտերը ձեռքում ես։ Վերցրեք նախագիծը ձեզ համար: Եթե դուք խաբեք, մենք կփակենք նախագիծը և բոլորին դուրս կքշենք: Կստացվի, թույն կլինի, հետո առաջնորդիր ու զարգացրու այնպես, ինչպես քեզ հարմար է։ Արդյունքում ես դարձա նախագծի թիմի ղեկավար, և ամեն ինչ ընկավ իմ ուսերին:
Առաջին բանը, որ ես արեցի, զրոյից աշխատանքային հոսքի ձևավորումն էր, որը համապատասխանում էր իմ այն ժամանակվա տեսլականին և գրեցի աշխատանքի նկարագրություն թիմի համար: Այն իրականացնելը հեշտ չէր. Բայց ինչ-որ տեղ մեկ ամսվա ընթացքում ամեն ինչ կարգավորվեց, մշակողները և հաճախորդը սովորեցին դրան, և ամեն ինչ անցավ հանգիստ և հարմարավետ: Որպեսզի թիմին ցույց տամ, որ սա պարզապես փոթորիկ չէ բաժակի մեջ, այլ իրական ելք իրավիճակից, ես ստանձնեցի առավելագույն չափի պարտականություններ՝ թիմից հեռացնելով տհաճ առօրյան։
Արդեն անցել է մեկուկես տարի, և նախագիծը զարգանում է առանց արտաժամյա աշխատանքի, առանց «առնետավազքի» և բոլոր տեսակի սթրեսների։ Հին թիմում ինչ-որ մեկը չցանկացավ այդպես աշխատել և հեռացավ, ընդհակառակը, ինչ-որ մեկն իսկապես մտավ դրա մեջ, որ թափանցիկ կանոններ հայտնվեցին։ Բայց արդյունքում թիմում բոլորը շատ մոտիվացված են և ամբողջությամբ գիտեն հսկայական նախագիծը՝ և՛ ճակատային, և՛ հետին վերջնամասերով: Ներառյալ ինչպես կոդերի բազան, այնպես էլ ողջ բիզնես տրամաբանությունը: Նույնիսկ հասել է նրան, որ մենք պարզապես «թիավարողներ» չենք, այլ մենք ինքներս ենք առաջարկում բազմաթիվ բիզնես գործընթացներ և նոր առանձնահատկություններ, որոնք դուր են գալիս բիզնեսին:
Մեր կողմից այս մոտեցման շնորհիվ հաճախորդը որոշեց պատվիրել մեկ այլ շուկա մեր ընկերությունից, ինչը լավ նորություն է:
Քանի որ սա աշխատում է իմ նախագծի վրա, գուցե այն նաև օգնի ինչ-որ մեկին: Այսպիսով, գործընթացը ինքնին, որն օգնեց մեզ փրկել նախագիծը.
«Իմ սիրելի նախագիծը» նախագծով թիմային աշխատանքի ընթացքը.
ա) Թիմային գործընթացում (մշակողների միջև)
- Բոլոր առաջադրանքները ստեղծված են Jira համակարգում
- Յուրաքանչյուր առաջադրանք պետք է հնարավորինս նկարագրվի և կատարի խիստ մեկ գործողություն:
- Ցանկացած հատկանիշ, եթե այն բավական բարդ է, բաժանվում է բազմաթիվ փոքր խնդիրների
- Թիմն աշխատում է առանձնահատկությունների վրա՝ որպես մեկ առաջադրանք: Սկզբում մենք միասին կատարում ենք մեկ ֆունկցիա, տալիս ենք փորձարկման, հետո վերցնում հաջորդը։
- Յուրաքանչյուր առաջադրանք պիտակավորված է backend-ի կամ frontend-ի համար
- Կան առաջադրանքների և սխալների տեսակներ: Դուք պետք է դրանք ճիշտ նշեք:
- Առաջադրանքն ավարտելուց հետո այն փոխանցվում է կոդի վերանայման կարգավիճակին (ձգման հարցում է ստեղծվում իր գործընկերոջ համար)
- Նա, ով ավարտեց առաջադրանքը, անմիջապես հետևում է այս առաջադրանքի իր ժամանակին
- Կոդը ստուգելուց հետո PR-ը հաստատվում է, և դրանից հետո նա, ով կատարել է այս առաջադրանքը, ինքնուրույն միացնում է այն հիմնական մասնաճյուղի մեջ, որից հետո այն փոխում է իր կարգավիճակը՝ պատրաստի տեղակայման մշակող սերվեր:
- Բոլոր առաջադրանքները, որոնք պատրաստ են տեղակայվել մշակողի սերվերում, տեղադրվում են թիմի ղեկավարի կողմից (նրա պատասխանատվության ոլորտը), երբեմն թիմի անդամը, եթե ինչ-որ բան հրատապ է: Տեղակայումից հետո բոլոր առաջադրանքները տեղակայման համար պատրաստից մինչև dev փոխանցվում են կարգավիճակի. պատրաստ է փորձարկման համար մշակողի վրա
- Բոլոր առաջադրանքները ստուգվում են հաճախորդի կողմից
- Երբ հաճախորդը փորձարկեց առաջադրանքը մշակողի վրա, նա այն տեղափոխում է արտադրության համար պատրաստի կարգավիճակ:
- Արտադրության տեղակայման համար մենք ունենք առանձին մասնաճյուղ, որտեղ մենք միավորում ենք վարպետը տեղակայումից անմիջապես առաջ
- Եթե թեստավորման ժամանակ հաճախորդը հայտնաբերում է սխալներ, ապա նա վերադարձնում է առաջադրանքը վերանայման՝ սահմանելով դրա կարգավիճակը, որը վերադարձվել է վերանայման: Այսպես մենք առանձնացնում ենք նոր առաջադրանքները չփորձարկվածներից։
- Արդյունքում, բոլոր առաջադրանքները գնում են ստեղծումից մինչև ավարտ. Անելիքներ → Զարգացման փուլում → Կոդի վերանայում → Պատրաստի տեղակայում մշակողին → QA մշակողի վրա → (Վերադարձ դեպի մշակում) → Պատրաստի տեղակայում մինչև պատրաստի → QA արդյունահանման → Կատարված
- Յուրաքանչյուր մշակող փորձարկում է իր կոդը ինքնուրույն, այդ թվում՝ որպես կայքի օգտատեր։ Չի թույլատրվում միացնել մասնաճյուղը հիմնականին, եթե հաստատապես հայտնի չէ, որ կոդը աշխատում է։
- Յուրաքանչյուր խնդիր ունի առաջնահերթություններ. Առաջնահերթությունները սահմանվում են կամ հաճախորդի կամ թիմի ղեկավարի կողմից:
- Մշակողները առաջին հերթին կատարում են առաջնահերթ առաջադրանքներ:
- Մշակողները կարող են միմյանց առաջադրանքներ հանձնարարել, եթե համակարգում տարբեր սխալներ են հայտնաբերվել կամ մեկ առաջադրանքը բաղկացած է մի քանի մասնագետների աշխատանքից։
- Բոլոր առաջադրանքները, որոնք հաճախորդը ստեղծում է, ուղարկվում են թիմի ղեկավարին, ով գնահատում է դրանք և կամ խնդրում է հաճախորդին վերջնականացնել դրանք, կամ հանձնարարում է թիմի անդամներից մեկին:
- Բոլոր առաջադրանքները, որոնք պատրաստ են տեղակայվել մշակողի կամ պրոդուկտորի վրա, նույնպես հասնում են թիմի ղեկավարին, ով ինքնուրույն որոշում է, թե երբ և ինչպես տեղակայել: Յուրաքանչյուր տեղակայումից հետո թիմի ղեկավարը (կամ թիմի անդամը) պետք է հաճախորդին տեղեկացնի այդ մասին: Եվ նաև փոխեք առաջադրանքների կարգավիճակները մինչև պատրաստի փորձարկման համար dev / prod:
- Ամեն օր նույն ժամին (մենք ունենք ժամը 12.00-ին) հավաք ենք անցկացնում թիմի բոլոր անդամների միջև
- Հանրահավաքին բոլորը հայտնում են, այդ թվում՝ թիմի ղեկավարը, թե ինչ է արել նա երեկ, ինչ է նախատեսում անել այսօր։ Ինչը չի աշխատում և ինչու: Այսպիսով, ամբողջ թիմը տեղյակ է, թե ով ինչ է անում և ինչ փուլում է գտնվում նախագիծը։ Սա մեզ հնարավորություն է տալիս կանխատեսելու և անհրաժեշտության դեպքում ճշգրտելու մեր գնահատականներն ու ժամկետները։
- Հանդիպմանը թիմի ղեկավարը հայտարարում է նաև նախագծում կատարված բոլոր փոփոխությունների և ընթացիկ սխալների մակարդակի մասին, որոնք հաճախորդի կողմից չեն հայտնաբերվել: Բոլոր սխալները դասավորված են և հանձնարարվում են թիմի յուրաքանչյուր անդամին՝ դրանք լուծելու համար:
- Հանրահավաքում թիմի ղեկավարը հանձնարարում է առաջադրանքներ յուրաքանչյուրի համար՝ հաշվի առնելով ծրագրավորողների ընթացիկ ծանրաբեռնվածությունը, նրանց մասնագիտական պատրաստվածության մակարդակը, ինչպես նաև հաշվի առնելով որոշակի առաջադրանքի հարևանությունը այն ամենին, ինչ ներկայումս անում է մշակողը:
- Հանդիպմանը թիմի ղեկավարը մշակում է ճարտարապետության և բիզնես տրամաբանության ընդհանուր ռազմավարություն: Դրանից հետո ամբողջ թիմը քննարկում է դա և որոշում՝ արդյոք ճշգրտումներ անել, թե ընդունել այս ռազմավարությունը:
- Յուրաքանչյուր մշակող գրում է կոդ և ինքնուրույն կառուցում ալգորիթմներ մեկ ճարտարապետության և բիզնես տրամաբանության շրջանակներում: Յուրաքանչյուրը կարող է արտահայտել իրագործման իր տեսլականը, բայց ոչ ոք ոչ ոքի չի ստիպում դա անել այսպես և ոչ այլ կերպ։ Յուրաքանչյուր որոշում արդարացված է. Եթե կա ավելի լավ լուծում, բայց հիմա դրա համար ժամանակ չկա, ապա ճարպի մեջ առաջադրանք է ստեղծվում՝ կոդի որոշակի մասի ապագա վերաֆակտորինգի համար։
- Երբ մշակողը ստանձնում է առաջադրանքը, այն տեղափոխում է զարգացման կարգավիճակ: Հաճախորդի հետ առաջադրանքի հստակեցման հետ կապված բոլոր հաղորդակցությունները ընկնում են մշակողի ուսերին: Տեխնիկական հարցեր կարող են տրվել թիմի ղեկավարին կամ գործընկերներին:
- Եթե մշակողը չի հասկանում առաջադրանքի էությունը, և հաճախորդը չի կարող խելամտորեն բացատրել այն, ապա նա անցնում է հաջորդ առաջադրանքին: Իսկ թիմի ղեկավարը վերցնում է ընթացիկն ու քննարկում հաճախորդի հետ։
- Ամեն օր ծրագրավորողը պետք է հաճախորդի չաթում գրի, թե ինչ խնդիրների վրա է աշխատել երեկ և ինչ խնդիրների վրա է աշխատելու այսօր։
- Աշխատանքային հոսքը հիմնված է Scrum-ի վրա: Ամեն ինչ բաժանված է սպրինտների։ Յուրաքանչյուր սպրինտ տևում է երկու շաբաթ:
- Սպրինտները ստեղծվում, լրացվում և փակվում են թիմի ղեկավարի կողմից:
- Եթե նախագիծն ունի խիստ ժամկետներ, ապա մենք փորձում ենք մոտավորապես գնահատել բոլոր առաջադրանքները։ Եվ մենք նրանցից սպրինտ ենք հավաքում։ Եթե հաճախորդը փորձում է ավելի շատ առաջադրանքներ ավելացնել սպրինտին, ապա մենք առաջնահերթություններ ենք սահմանում և որոշ այլ առաջադրանքներ փոխանցում հաջորդ սպրինտին:
բ) Հաճախորդի հետ աշխատելու գործընթացը
- Յուրաքանչյուր մշակող կարող է և պետք է շփվի հաճախորդի հետ
- Դուք չեք կարող թույլ տալ, որ հաճախորդը պարտադրի իր խաղի կանոնները: Պետք է քաղաքավարի և բարեհամբույր կերպով հաճախորդին հասկացնել, որ մենք մասնագետ ենք մեր ոլորտում, և միայն մենք պետք է կառուցենք աշխատանքային գործընթացներ և հաճախորդին ներգրավենք դրանցում:
- Իդեալում, անհրաժեշտ է, նախքան որևէ ֆունկցիոնալության իրականացմանը անցնելը, մի հատկանիշի (աշխատանքային հոսքի) համար ստեղծել ամբողջ տրամաբանական գործընթացի հոսքի գծապատկեր: Եվ ուղարկեք հաճախորդին հաստատման համար: Սա վերաբերում է միայն բարդ և ոչ ակնհայտ ֆունկցիոնալությանը, օրինակ՝ վճարային համակարգին, ծանուցման համակարգին և այլն։ Սա թույլ կտա ձեզ ավելի ճշգրիտ հասկանալ, թե կոնկրետ ինչ է պետք հաճախորդին, պահպանել փաստաթղթերը հատկանիշի համար, ինչպես նաև ապահովագրել ձեզ այն փաստից, որ հաճախորդը կարող է ապագայում ասել, որ մենք չենք արել այն, ինչ նա խնդրել է:
- Բոլոր դիագրամները/հոսքերի գծապատկերները/տրամաբանությունը և այլն: մենք խնայում ենք Confluence/Fat-ում, որտեղ հաճախորդին խնդրում ենք մեկնաբանություններում հաստատել ապագա իրականացման ճիշտությունը:
- Մենք աշխատում ենք հաճախորդին չծանրաբեռնել տեխնիկական մանրամասներով։ Եթե մեզ անհրաժեշտ է հասկանալ, թե ինչպես է հաճախորդը ցանկանում, ապա մենք պարզունակ ալգորիթմներ ենք գծում հոսքի գծապատկերի տեսքով, որը հաճախորդը կարող է հասկանալ և ինքնուրույն շտկել/փոփոխել ամեն ինչ:
- Եթե հաճախորդը նախագծում սխալ է հայտնաբերել, ապա մենք խնդրում ենք ձեզ մանրամասն նկարագրել այն Fat-ում: Ի՞նչ հանգամանքներում է դա տեղի ունեցել, ե՞րբ, ինչ գործողությունների հաջորդականություն է իրականացվել պատվիրատուի կողմից թեստավորման ժամանակ։ Խնդրում ենք կցել սքրինշոթներ:
- Մենք փորձում ենք ամեն օր, առավելագույնը երկու օր, տեղակայվել մշակողի սերվերում: Այնուհետև հաճախորդը սկսում է փորձարկել ֆունկցիոնալությունը, և նախագիծը պարապ չէ: Միևնույն ժամանակ, սա հաճախորդի համար նշան է, որ նախագիծը լիարժեք մշակման փուլում է, և ոչ ոք նրան հեքիաթներ չի պատմում:
- Հաճախ է պատահում, որ հաճախորդն ընդհանրապես չի հասկանում, թե իրեն ինչ է պետք։ Քանի որ նա իր համար նոր բիզնես է ստեղծում՝ դեռևս չվրիպազերծված գործընթացներով։ Հետևաբար, շատ տարածված դեպք է, երբ մենք կոդի ամբողջական կտորներ ենք նետում աղբարկղ և վերափոխում ենք հավելվածի տրամաբանությունը: Այստեղից բխում է, որ պետք չէ բացարձակապես ամեն ինչ ծածկել թեստերով։ Իմաստ ունի թեստերով ծածկել միայն կրիտիկական ֆունկցիոնալությունը, այնուհետև վերապահումներով:
- Լինում են իրավիճակներ, երբ թիմը հասկանում է, որ մենք չենք տեղավորվում վերջնաժամկետների մեջ։ Այնուհետև մենք իրականացնում ենք առաջադրանքների արագ աուդիտ և անմիջապես տեղեկացնում ենք հաճախորդին այդ մասին: Որպես իրավիճակից ելք՝ առաջարկում ենք ժամանակին գործարկել կարևոր և կարևոր ֆունկցիոնալությունը, իսկ մնացածը թողնել հետթողարկման։
- Եթե հաճախորդը սկսում է գլխից տարբեր առաջադրանքներ կատարել, սկսում է երևակայել և բացատրել իր մատների վրա, ապա մենք խնդրում ենք նրան տրամադրել էջի դասավորություն և հոսել տրամաբանությամբ, որը պետք է ամբողջությամբ նկարագրի ամբողջ դասավորության և դրա վարքագիծը: տարրեր.
- Նախքան որևէ խնդիր ստանձնելը, մենք պետք է համոզվենք, որ այս հատկությունը ներառված է մեր համաձայնագրի/պայմանագրի պայմանների մեջ: Եթե սա նոր առանձնահատկություն է, որը դուրս է մեր նախնական պայմանավորվածություններից, ապա մենք պետք է անպայման գնահատենք այս հատկանիշը ((մոտավոր ժամկետ + 30%) x 2) և հաճախորդին նշենք, որ մեզ այդքան ժամանակ կպահանջվի դրա համար, գումարած՝ վերջնաժամկետը տեղափոխվում է երկուսով բազմապատկած գնահատման ժամանակի համար: Եկեք ավելի արագ կատարենք առաջադրանքը. հիանալի, բոլորը միայն կշահեն դրանից: Եթե ոչ, ուրեմն մենք ապահովագրված ենք։
գ) Այն, ինչ մենք չենք ընդունում թիմում.
- Անհետևողականություն, անհամապատասխանություն, մոռացկոտություն
- «Նախաճաշի կերակրում». Եթե դուք չեք կարող կատարել առաջադրանքը, չգիտեք, թե ինչպես, ապա դուք պետք է անմիջապես տեղեկացնեք թիմի ղեկավարին այս մասին և չսպասեք մինչև վերջինը:
- Բրովադաս ու պարծենում է մի մարդուց, ով դեռ գործով չի ապացուցել իր հնարավորություններն ու պրոֆեսիոնալիզմը։ Եթե ապացուցվի, ուրեմն հնարավոր է՝ պարկեշտության սահմաններում 🙂
- Խարդախությունն իր բոլոր դրսեւորումներով. Եթե առաջադրանքը չի ավարտվել, ապա չպետք է փոխեք դրա կարգավիճակը ավարտվածի և հաճախորդի չաթում գրեք, որ այն պատրաստ է: Համակարգիչը խափանվել է, համակարգը խափանվել է, շունը ծամել է նոութբուքը՝ այս ամենն անընդունելի է։ Եթե իրական ֆորս-մաժոր է տեղի ունենում, ապա թիմի ղեկավարը պետք է անմիջապես տեղեկացվի:
- Երբ մասնագետն անընդհատ օֆլայն է, և աշխատանքային ժամերին դժվար է նրան կապ հաստատել։
- Թունավորումը թիմում չի թույլատրվում: Եթե ինչ-որ մեկը ինչ-որ բանի հետ համաձայն չէ, ուրեմն բոլորը հավաքվում են միտինգի և քննարկում և որոշում են։
Եվ մի շարք հարցեր / թեզեր, որոնք ես երբեմն խնդրում եմ իմ հաճախորդին հեռացնել բոլոր թյուրիմացությունները.
- Որո՞նք են ձեր որակի չափանիշները:
- Ինչպե՞ս որոշել, արդյոք նախագիծը խնդիրներ ունի, թե ոչ:
- Խախտելով համակարգի փոփոխման/բարելավման վերաբերյալ մեր բոլոր առաջարկությունները և խորհուրդները՝ բոլոր ռիսկերը կրում եք միայն դուք
- Ծրագրի ցանկացած խոշոր փոփոխություն (օրինակ, բոլոր տեսակի լրացուցիչ հոսքերը) կհանգեցնեն սխալների հնարավոր ի հայտ գալուն (որոնք մենք, իհարկե, կուղղենք)
- Անհնար է մի քանի րոպեի ընթացքում հասկանալ, թե ինչ խնդիր է առաջացել նախագծում, և առավել եւս՝ այն շտկել հենց այնտեղ։
- Մենք աշխատում ենք կոնկրետ արտադրանքի հոսքի վրա (Առաջադրանքներ Ժիրայում - Զարգացում - Փորձարկում - Տեղակայում): Սա նշանակում է, որ մենք չենք կարող պատասխանել զրույցի հարցումների և բողոքների ողջ հոսքին:
- Ծրագրավորողները պարզապես ծրագրավորողներ են, ոչ թե պրոֆեսիոնալ փորձարկողներ և չեն կարող ապահովել նախագծի թեստավորման պատշաճ որակը
- Վաճառքի վերջնական փորձարկման և առաջադրանքների ընդունման պատասխանատվությունն ամբողջությամբ կրում է ձեզ վրա
- Եթե մենք արդեն ստանձնել ենք առաջադրանքը, ապա մենք չենք կարող անմիջապես անցնել ուրիշներին, մինչև չավարտենք ընթացիկը (հակառակ դեպքում դա հանգեցնում է էլ ավելի մեծ սխալների և զարգացման ժամանակի ավելացման)
- Թիմում ավելի քիչ մարդիկ կան (արձակուրդների կամ հիվանդությունների պատճառով), և ավելի շատ աշխատանք կա, և մենք ֆիզիկապես ժամանակ չենք ունենա արձագանքելու այն ամենին, ինչ ցանկանում եք:
- Ձեզնից պահանջելը, որ դուք տեղակայվեք արտադրության մեջ առանց մշակողի վրա փորձարկված առաջադրանքների, միայն ձեր ռիսկն է, այլ ոչ թե մշակողի
- Երբ դուք դնում եք մշուշոտ առաջադրանքներ, առանց ճիշտ հոսքի, առանց դիզայնի դասավորության, դա մեզանից պահանջում է շատ ավելի մեծ ջանքեր և իրականացման ժամանակ, քանի որ մենք պետք է ձեր փոխարեն լրացուցիչ աշխատանք կատարենք:
- Սխալների հետ կապված ցանկացած առաջադրանք, առանց դրանց առաջացման և սքրինշոթերի մանրամասն նկարագրության, մեզ հնարավորություն չի տալիս հասկանալու, թե ինչն է սխալ եղել և ինչպես կարող ենք բաց թողնել այս սխալը:
- Նախագիծը պահանջում է մշտական կատարելագործում և կատարելագործում` արդյունավետությունն ու անվտանգությունը բարելավելու համար: Հետևաբար, թիմն իր ժամանակի մի մասը ծախսում է այդ բարելավումների վրա:
- Ելնելով այն հանգամանքից, որ մենք ունենք արտաժամյա ժամեր (հրատապ շտկումներ), դրանք պետք է փոխհատուցենք մյուս օրերին
Որպես կանոն, հաճախորդը անմիջապես հասկանում է, որ ծրագրային ապահովման մշակման մեջ ամեն ինչ այնքան էլ պարզ չէ, և միայն ցանկությունն ակնհայտորեն բավարար չէ։
Ընդհանուր առմամբ, այս ամենը: Կուլիսների հետևում ես թողնում եմ բազմաթիվ բանակցություններ և բոլոր գործընթացների սկզբնական կարգաբերում, բայց արդյունքում ամեն ինչ ստացվեց։ Կարող եմ ասել, որ այս գործընթացը մեզ համար դարձել է յուրօրինակ «արծաթե փամփուշտ»։ Նախագծին եկած նոր մարդիկ արդեն կարող էին առաջին իսկ օրվանից անմիջապես ներգրավվել աշխատանքի համար, քանի որ բոլոր գործընթացները նկարագրված են, իսկ փաստաթղթերն ու ճարտարապետությունը գծապատկերների տեսքով անմիջապես պատկերացում տվեցին այն մասին, թե ինչ ենք անում մենք բոլորս։ այստեղ.
Հ.Գ Ուզում եմ ճշտել, որ մեր կողմից նախագծի ղեկավար չկա։ Դա հաճախորդի կողմից է: Ամենևին էլ տեխնոլոգ չէ: Եվրոպական նախագիծ. Ամբողջ հաղորդակցությունը կատարվում է միայն անգլերենով:
Հաջողություն բոլորին ձեր նախագծերում: Մի այրեք և փորձեք բարելավել ձեր գործընթացները:
աղբյուրը իմ .
Source: www.habr.com