Կոնֆլիկտների կառավարում թիմում` հավասարակշռող գործողություն, թե կենսական անհրաժեշտություն:

Էպիգրաֆ:
Ժամանակին Ոզնին ու Փոքր Արջը հանդիպեցին անտառում։
-Բարև, Ոզնի:
-Բարև, Փոքրիկ Արջուկ:
Ուրեմն, բառ առ բառ, կատակ առ կատակ, Ոզնին երեսին հարվածեց Փոքրիկ Արջը...

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

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

Կյանքը բազմազան է, և տատանումները տեղի են ունենում վերը նկարագրված սցենարով: Երբեմն մասնակիցների միջև հարաբերություններն ի սկզբանե այնքան էլ լավ չեն, երբեմն նույնիսկ ուղղակի լուծում պահանջող հարց չկա (ինչպես, օրինակ, էպիգրաֆում), երբեմն քննարկումից հետո հարաբերությունները մնում են նույնը, ինչ նախքան սկսելը, բայց. հարցը վերջնականապես չի լուծվում.

Ի՞նչն է ընդհանուր բոլոր իրավիճակներում, որոնք կարող են սահմանվել որպես աշխատանքային կոնֆլիկտի իրավիճակ:



Նախ, կան երկու կամ ավելի կողմեր. Այս կողմերը կարող են տարբեր տեղեր զբաղեցնել կազմակերպությունում, լինել հավասար հարաբերությունների մեջ (թիմում գործընկերներ), կամ հիերարխիայի տարբեր մակարդակներում (շեֆ-ստորադաս), լինել անհատական ​​(աշխատող) կամ խմբակային (կոնֆլիկտների դեպքում. աշխատող և թիմ կամ երկու թիմ) և այլն: Հակամարտության հավանականության և դրա լուծման հեշտության վրա մեծապես ազդում է մասնակիցների միջև վստահության մակարդակը: Որքան լավ կողմերը ճանաչեն միմյանց, որքան բարձր լինի վստահության մակարդակը, այնքան մեծ կլինի նրանց համաձայնության գալու հնարավորությունը։ Օրինակ, բաշխված թիմի անդամները, ովքեր երբեք դեմ առ դեմ չեն շփվել, ավելի հավանական է, որ բախվեն հասարակ աշխատանքային խնդրի շուրջ, քան այն մարդիկ, ովքեր ունեցել են առնվազն մի քանի դեմ առ դեմ շփումներ: Հետևաբար, բաշխված թիմերում աշխատելիս շատ կարևոր է ապահովել, որ թիմի բոլոր անդամները պարբերաբար անձամբ հանդիպեն միմյանց հետ:

Երկրորդ՝ աշխատանքային կոնֆլիկտային իրավիճակում կողմերը գտնվում են կողմերից մեկի, երկուսի կամ ամբողջ կազմակերպության համար կարևոր հարց լուծելու իրավիճակում։ Միևնույն ժամանակ, իրավիճակի առանձնահատկություններից ելնելով, կողմերը սովորաբար ունենում են բավարար ժամանակ և դրա լուծման մի շարք ուղիներ (ֆորմալ, ոչ պաշտոնական, հանդիպումներ, նամակներ, կառավարման որոշումներ, թիմի նպատակների և պլանների առկայություն, հիերարխիայի փաստ և այլն): Սա տարբերվում է կազմակերպությունում աշխատանքային (կամ ոչ աշխատանքային) հարց լուծելու իրավիճակից, օրինակ, կարևոր հարց լուծելուց. «Էհ, երեխա, ո՞ր տարածքից ես»: փողոցում, կամ կոնֆլիկտը էպիգրաֆից. Աշխատանքային հարցի լուծման դեպքում կարևոր է աշխատանքային գործընթացի որակը և թիմում հարցեր լուծելու մշակույթը։

Երրորդ, հակամարտության որոշիչ գործոնը (մեր քննարկման տեսանկյունից) այն է, որ գործընթացի կողմերը չեն կարող ինքնուրույն գալ հարցի լուծմանը, որը հարմար է բոլոր կողմերին։ Իրավիճակը պահանջում է երրորդ կողմի՝ արտաքին արբիտրի միջամտությունը։ Այս կետը կարող է հակասական թվալ, բայց, ըստ էության, եթե կոնֆլիկտային իրավիճակը հաջողությամբ լուծվեց առանց արտաքին արբիտրի միջամտության, հարցը հաջողությամբ լուծվեց և կողմերի հարաբերությունները չվատթարանան, դա այն իրավիճակն է, որին մենք պետք է ձգտենք. . Մենք, ամենայն հավանականությամբ, չենք էլ իմանա նման հակամարտության մասին, կամ էլ պատահաբար կիմանանք այն լուծելուց հետո։ Որքան շատ խնդիրներ թիմը կարողանա ինքնուրույն լուծել, այնքան ավելի արդյունավետ կլինի:

Կոնֆլիկտի մեկ այլ հատկանշական հատկանիշ, որին արժե անդրադառնալ, որոշման ժամանակ հուզական ինտենսիվության աստիճանն է։ Պարտադիր չէ, որ կոնֆլիկտը կապված լինի բարձր հուզական մակարդակի հետ: Մասնակիցները չպետք է բղավեն և ձեռքերը թափահարեն, որպեսզի իրավիճակը, ըստ էության, հակամարտություն լինի: Հարցը լուծված չէ, առկա է որոշակի հուզական լարվածություն (գուցե արտաքուստ հստակ արտահայտված չէ), ինչը նշանակում է, որ մենք կանգնած ենք կոնֆլիկտային իրավիճակի առաջ։

Ընդհանրապես պե՞տք է միջամտել կոնֆլիկտային իրավիճակներին, թե՞ ավելի լավ է թույլ տալ, որ դրանց լուծումն իր հունով ընթանա և սպասի խնդրի լուծմանը։ Պետք է. Միշտ չէ, որ ձեր իրավասության մեջ է հակամարտությունն ամբողջությամբ լուծելը, բայց ցանկացած իրավիճակում, ցանկացած մասշտաբի կոնֆլիկտում դուք կարող եք չափահաս դիրք գրավել՝ դրանով իսկ ձեր շուրջը մի քանի հոգու բերելով դրան՝ մեղմացնելով դրա բացասական հետևանքները։ հակամարտությունը և նպաստել դրա լուծմանը:

Նախքան կոնֆլիկտային իրավիճակների մի քանի օրինակներ դիտարկելը, եկեք դիտարկենք բոլոր հակամարտությունների համար ընդհանուր մի քանի կարևոր կետեր:

Կոնֆլիկտը լուծելիս կարևոր է լինել կռվից վեր, այլ ոչ թե դրա ներսում (սա նաև կոչվում է «մետա-դիրքորոշում»), այսինքն՝ չմասնակցել կարգավորման գործընթացում կողմերից որևէ մեկին։ Հակառակ դեպքում, արտաքին արբիտր ունենալը որոշումը միայն կամրապնդի կողմերից մեկի դիրքերը՝ ի վնաս մյուս կողմի: Որոշում կայացնելիս կարևոր է, որ այն բարոյապես ընդունվի բոլոր կողմերի կողմից, ինչպես ասում են՝ «գնված»։ Որպեսզի, եթե նույնիսկ կողմերը հիացած չէին կայացված որոշումով, նրանք գոնե անկեղծորեն համաձայնվեին այն իրականացնել։ Ինչպես ասում են՝ կարողանալ չհամաձայնվել և պարտավորվել։ Հակառակ դեպքում հակամարտությունը պարզապես կփոխի իր տեսքը, մարող կրակը կմնա տորֆ ճահճի տակ և ինչ-որ պահի անխուսափելիորեն նորից կբռնկվի։

Երկրորդ կետը, որը մասամբ կապված է առաջինի հետ, այն է, որ եթե արդեն որոշել եք մասնակցել հակամարտության կարգավորմանը, հնարավորինս լրջորեն վերաբերվեք դրան՝ հաղորդակցությունների և կոնտեքստն ուսումնասիրելու տեսանկյունից։ Անձամբ խոսեք կողմերից յուրաքանչյուրի հետ: Յուրաքանչյուրի հետ առանձին, սկզբի համար: Մի բավարարվեք փոստով: Բաշխված թիմի դեպքում գոնե տեսահոլովակով խոսեք։ Մի բավարարվեք ասեկոսեներով ու ականատեսների հաղորդումներով։ Հասկացեք պատմությունը, թե կողմերից յուրաքանչյուրն ինչ է ուզում, ինչու է դա ուզում, ինչ է ակնկալում, նախկինում փորձե՞լ են լուծել այս հարցը, ինչ կլինի, եթե այն չլուծվի, ինչ լուծումներ են տեսնում, ինչպես են պատկերացնում կուսակցության դիրքորոշումը: մյուս կողմը՝ ինչ են մտածում՝ ճիշտ թե սխալ և այլն։ Բեռնեք բոլոր հնարավոր համատեքստը ձեր գլխում, բաց մտքով, ենթադրելով, որ բոլորը ճիշտ են: Դու կոնֆլիկտի ներսում չես, դու դրանից դուրս ես՝ մետապոզիցիայով։ Եթե ​​համատեքստը հասանելի է միայն գրառման թեմայում, գոնե կարդացեք այն ամբողջությամբ և դրա հետ կապված թեմաներն ու փաստաթղթերը: Այն կարդալուց հետո դեռ խոսեք ձեր ձայնով: Դուք գրեթե երաշխավորված եք լսել մի կարևոր բան, որը փոստում չկա:

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

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

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

Մեզանից յուրաքանչյուրն ունի ներքին երեխա՝ մոտ երեք-չորս տարեկան։ Նա աշխատավայրում շատ ժամանակ քնում է, բայց երբեմն արթնանում է և իր վրա վերցնում վերահսկողությունը: Երեխան ունի իր առաջնահերթությունները. Նրա համար կարևոր է պնդել, որ սա իր ավազատուփն է, մայրն իրեն ավելի շատ է սիրում, մեքենան ամենալավն է (դիզայնը լավագույնն է, նա ծրագրավորում է լավագույնը, ...): Կոնֆլիկտային իրավիճակում երեխան կարող է սեղմել խաղալիքները, հարվածել ոտքերը և կոտրել սպաթուլան, բայց նա չի կարող լուծել մեծահասակների հարցերը (լուծումների ճարտարապետություն, ավտոմատ թեստավորման մոտեցումներ, թողարկման ժամկետներ և այլն), նա չի մտածում օգուտների մասին: թիմի համար։ Հակամարտության մեջ գտնվող երեխային կարելի է խրախուսել, մխիթարել և ուղարկել քնելու՝ խնդրելով զանգահարել իր մեծահասակին: Նախքան կոնֆլիկտային իրավիճակում քննարկում սկսելը, համոզվեք, որ դուք խոսում եք մեծահասակի հետ, ոչ թե երեխայի, և որ դուք ինքներդ մեծահասակի դիրքում եք: Եթե ​​ձեր ազնիվ նպատակն այս պահին լուրջ հարց լուծելն է, դուք չափահասի կարգավիճակում եք։ Եթե ​​ձեր նպատակն է հարվածել ձեր ոտքերը և կոտրել ձեր ուսադիրը, ապա սա մանկական դիրք է: Ուղարկեք ձեր ներքին երեխային քնելու և զանգահարեք մեծահասակի կամ վերադասավորեք քննարկումը: Մարդը էմոցիոնալ որոշում է կայացնում, իսկ հետո դրա համար ռացիոնալ հիմնավորում է փնտրում։ Երեխայի կողմից երեխաների առաջնահերթությունների հիման վրա կայացված որոշումը օպտիմալ չի լինի:

Բացի կոնֆլիկտի պահին վարքագծից, երեխայի կամ մեծահասակի դիրքը բնութագրվում է նաև պատասխանատվության մակարդակով, որը մարդը պատրաստ է իր վրա վերցնել: Իր ծայրահեղ դրսեւորումներով ծրագրավորողի մանկական դիրքը, որին ես մեկ անգամ չէ, որ հանդիպել եմ, այսպիսի տեսք ունի՝ կոդը գրել եմ, ուղարկել վերանայման՝ աշխատանքս ավարտված է։ Վերանայողները պետք է վերանայեն և հաստատեն, QA-ն պետք է ստուգի, եթե խնդիրներ լինեն, ինձ տեղյակ կպահեն: Տարօրինակ կերպով, նույնիսկ բավականին հասուն և փորձառու մարդիկ երբեմն նման կերպ են վարվում: Սանդղակի մյուս ծայրն այն է, որ մարդն իրեն պատասխանատու է համարում ապահովելու, որ իր ծածկագիրը աշխատում է, ծածկված է թեստերով, անձամբ ստուգվել է իր կողմից, հաջողությամբ անցել է վերանայումը (անհրաժեշտության դեպքում, ստուգողներին պինգինգի, հարցեր քննարկելու խնդիր չկա։ ձայնով և այլն) և ճնշվել է, ՈԱ-ն անհրաժեշտության դեպքում օգնություն կտրամադրի, կնկարագրվեն թեստային սցենարներ և այլն: Սովորական դեպքերում ծրագրավորողը կամ սկսում է ավելի մոտ չափահաս սանդղակի ավարտին, կամ տեղափոխվում է այնտեղ՝ փորձ ձեռք բերելով (եթե թիմում ճիշտ մշակույթ է մշակվում): Ծայրահեղ դեպքերում նա շարունակում է աշխատել՝ սովորաբար մանկական դիրք բռնելով, հետո նրա ու թիմի մոտ պարբերաբար խնդիրներ ու կոնֆլիկտներ են առաջանում։

Թիմում ճիշտ, հասուն մշակույթի զարգացումը կարևոր խնդիր է ցանկացած մենեջերի համար: Այն պահանջում է երկար ժամանակ և ամենօրյա ջանք, բայց արդյունքն արժե այն: Թիմի մշակույթի վրա ազդելու երկու եղանակ կա՝ օրինակ բերելը (որին անպայման կհետևեն. թիմը միշտ նայում է առաջնորդին) և ճիշտ վարքագծի քննարկում և պարգևատրում: Այստեղ նույնպես անհեթեթ կամ շատ ֆորմալ բան չկա, պարզապես խնդիրներ քննարկելիս նշեք, որ այստեղ ինչ-որ բան կարելի էր անել, շեշտեք, որ նկատել եք, երբ ճիշտ է որոշվել, գովասանք, գրառում թողարկման ժամանակ և այլն։

Դիտարկենք մի քանի բնորոշ կոնֆլիկտային իրավիճակներ՝ պարզից մինչև բարդ.

Աշխատանքային խնդիրների հետ կապված կոնֆլիկտներ

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

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

Մեկ այլ օրինակ, որին ես մի քանի անգամ հանդիպել եմ իմ աշխատանքի ընթացքում, թիմի անդամների հոգեբանական անհամատեղելիությունն է։ Չգիտես ինչու, մարդիկ պարզապես չեն կարող միասին աշխատել, յուրաքանչյուր փոխազդեցություն ավարտվում է սկանդալով: Երբեմն դա պայմանավորված է նրանով, որ մարդիկ բևեռային տեսակետներ ունեն ինչ-որ հրատապ հարցի վերաբերյալ (սովորաբար քաղաքական) և չգիտեն, թե ինչպես դրանք թողնել աշխատանքից դուրս: Նրանց համոզել, որ հանդուրժեն միմյանց կամ փոխեն իրենց վարքը, բավականին ապարդյուն խնդիր է։ Միակ բացառությունը, որին ես հանդիպել եմ, բաց ընկալումներով երիտասարդ գործընկերներն են, որոնց վարքագիծը դեռևս կարելի է աստիճանաբար փոխել պարբերական զրույցների միջոցով: Սովորաբար խնդիրը հաջողությամբ լուծվում է՝ նրանց բաժանելով տարբեր թիմերի, կամ գոնե աշխատանքում շատ հազվադեպ համընկնելու հնարավորություն ընձեռելով:

Վերոնշյալ բոլոր իրավիճակներում արժե անձամբ զրուցել բոլոր մասնակիցների հետ, քննարկել իրավիճակը, հարցնել՝ արդյոք նրանք ընդհանրապես խնդիր տեսնու՞մ են այս դեպքում, հարցնել, թե որոնք են, իրենց կարծիքով, լուծումները և ապահովել նրանց մասնակցությունը դրա կայացմանը։ որոշումը։

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

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

Աշխատանքային խնդիրների հետ կապված կոնֆլիկտներ.

Նման կոնֆլիկտները սովորաբար առաջանում են միանգամից երկու պատճառով՝ և՛ էմոցիոնալ (այն, որ մասնակիցներից մեկը մեծահասակի դիրքում չէ), և՛ բուն աշխատանքային գործընթացի անկատարությունը։ Հավանաբար, հակամարտությունների ամենատարածված տեսակը, որին ես հանդիպել եմ, կոնֆլիկտներն են կոդի վերանայման կամ մշակողների միջև ճարտարապետական ​​քննարկումների ժամանակ:

Այստեղ ես կնշեի երկու բնորոշ դեպք.

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

Լուծման մոտեցումը, որն օգնում է նման իրավիճակում, վերաբերում է հենց երկարաժամկետ հեռանկարին, մեծահասակի մշակույթին: Նախ, խելացի գործունեությունը աշխատում է: Դուք չպետք է ակնկալեք, որ վերանայման վրա կախված ծածկագիրը կգրավի հենց գրախոսողի ուշադրությունը: Մենք պետք է օգնենք գրախոսներին նկատել նրան: Պինգանի մի երկու հոգի, սինկապի մասին հարց տվեք, մասնակցեք քննարկումներին։ Ակնհայտ է, որ անտարբերությունը ավելի հավանական է, որ վնասի, քան օգնի, դուք պետք է օգտագործեք ողջախոհությունը: Երկրորդ, նախնական նախապատրաստումը լավ է աշխատում: Եթե ​​թիմը հասկանում է, թե ինչ է տեղի ունենում և ինչու, ինչու է ընդհանրապես անհրաժեշտ այս օրենսգիրքը, դիզայնը նախապես քննարկվել և համաձայնեցվել է բոլորի հետ, մարդիկ ավելի հավանական է, որ ուշադրություն դարձնեն նման օրենսգրքին և ընդունեն այն աշխատանքի համար: Երրորդ, իշխանությունն աշխատում է։ Եթե ​​ցանկանում եք վերանայվել, ինքներդ շատ ակնարկներ արեք: Կատարեք բարձրորակ ակնարկներ՝ իրական ստուգումներով, իրական թեստերով և օգտակար մեկնաբանություններով: Եթե ​​ձեր մականունը լավ հայտնի է թիմում, ավելի մեծ հավանականություն կա, որ ձեր ծածկագիրը կնկատվի:

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

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

Մի օր իմ թիմից մի ծրագրավորող (եկեք նրան անվանենք Փաշա) փաթեթի տեղակայման համակարգում փոփոխություններով պատչ պատրաստեց, որը մշակվել և աջակցվում էր հարևան բաժնի գործընկերների կողմից: Նրանցից մեկը (Իգորը) ուներ իր ամուր կարծիքը այն մասին, թե կոնկրետ ինչպես պետք է կազմաձևվեն Linux ծառայությունները փաթեթներ տեղակայելիս: Այս կարծիքը տարբերվում էր կարկատանում առաջարկված մոտեցումից, և նրանք չկարողացան համաձայնել։ Ինչպես միշտ, վերջնաժամկետները սպառվում էին, և պետք էր ինչ-որ որոշման գալ, անհրաժեշտ էր, որ նրանցից մեկը չափահաս պաշտոն զբաղեցներ։ Փաշան գիտակցում էր, որ երկու մոտեցումներն էլ կյանքի իրավունք ունեն, բայց ուզում էր, որ իր տարբերակը անցնի, քանի որ Ոչ մեկը, ոչ էլ երկրորդ տարբերակը ակնհայտ տեխնիկական առավելություններ չունեին։

Մեր քննարկումն այսպիսի տեսք ուներ (շատ սխեմատիկ, իհարկե, զրույցը տևեց կես ժամ).

- Փաշա, մի քանի օրից խաղարկային սառեցում ունենք։ Կարևոր է, որ մենք ամեն ինչ հավաքենք և հնարավորինս շուտ սկսենք թեստավորումը: Ինչպե՞ս կարող ենք անցնել Իգորի միջով:
— Նա ուզում է այլ կերպ կարգավորել ծառայությունները, ինձ համար մեկնաբանություններ է դրել...
-Իսկ ի՞նչ կա՝ մեծ փոփոխություններ, մեծ աղմուկ։
-Չէ, մի երկու ժամ աշխատանք կա, բայց ի վերջո տարբերություն չկա, այնպես էլ կստացվի, ինչո՞ւ է սա անհրաժեշտ։ Մի բան եմ սարքել, որ աշխատում ա, ընդունենք։
-Լսիր, որքա՞ն ժամանակ է, ինչ քննարկում ես այս ամենը։
- Այո, մենք արդեն մեկուկես շաբաթ է, ինչ ժամանակ ենք նշում։
-Հըմ... կարո՞ղ ենք մի երկու ժամում արդեն մեկուկես շաբաթ տևած հարց լուծել ու չանել։
- Դե, այո, բայց ես չեմ ուզում, որ Իգորը մտածի, որ ես զիջել եմ…
-Լսիր, ի՞նչն է քեզ համար ավելի կարևոր՝ ազատ արձակե՞լը, քո որոշման հետ մեկտեղ՝ ներսում, թե՞ սպանել Իգորին։ Մենք կարող ենք արգելափակել այն, այնուհետև, այնուամենայնիվ, թողարկումով անցնելու լավ հնարավորություն կա:
-Դե... լավ կլիներ, իհարկե, սրբել Իգորի քիթը, բայց լավ, ազատումն ավելի կարևոր է, համաձայն եմ:
- Իսկապե՞ս քեզ համար այդքան կարևոր է, թե ինչ է մտածում Իգորը: Անկեղծ ասած, նա ամենևին էլ չի մատնվում, պարզապես ուզում է միասնական մոտեցում ունենալ այն բանի տարբեր վայրերում, որոնց համար ինքը պատասխանատու է։
-Դե լավ, թույլ տվեք անել այնպես, ինչպես նա է խնդրում մեկնաբանություններում, և եկեք սկսենք թեստավորումը:
-Շնորհակալ եմ, փաշա՛: Ես վստահ էի, որ երկուսիցդ ավելի հասուն կլինես, չնայած Իգորեկը քեզնից մեծ է :)

Հարցը լուծվեց, ազատումը ժամանակին ազատվեց, փաշան մեծ դժգոհություն չզգաց, քանի որ նա ինքն է լուծում առաջարկել ու իրականացրել։ Իգորն ընդհանուր առմամբ գոհ էր, քանի որ... Նրա կարծիքը հաշվի են առնվել, եւ արել են այնպես, ինչպես ինքն է առաջարկել։

Հիմնականում նույն կոնֆլիկտի մեկ այլ տեսակ է ընտրությունը տեխնիկական լուծումների/գրադարանների/մոտեցումների միջև նախագծում, հատկապես բաշխված թիմում: Նախագծերից մեկում, որը դիրքավորվել էր որպես C/C++ օգտագործող, պարզվեց, որ նախագծի տեխնիկական ղեկավարությունը կտրականապես դեմ է STL-ի (Standard Template Library) օգտագործմանը։ Սա ստանդարտ լեզուների գրադարան է, որը հեշտացնում է զարգացումը, և մեր թիմը շատ սովոր է դրան: Պարզվեց, որ նախագիծը շատ ավելի մոտ է C-ին, քան C++-ին, ինչը թիմին այնքան էլ չոգեշնչեց, քանի որ. Ղեկավարությունը փորձեց առավելագույնը և հավաքագրեց իսկապես հիանալի պլյուս խաղացողներ: Միևնույն ժամանակ, թիմի ամերիկյան մասը՝ և՛ ինժեներները, և՛ մենեջերները, երկար ժամանակ աշխատել էին ընկերությունում, սովոր էին գործերի առկա վիճակին և գոհ էին ամեն ինչից։ Թիմի ռուսական մասը համախմբվեց բոլորովին վերջերս՝ մի քանի շաբաթվա ընթացքում (այդ թվում՝ ես)։ Թիմի ռուսական մասը կտրականապես չէր ցանկանում հրաժարվել զարգացման սովորական մոտեցումից։

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

Այս ամենը բավական երկար տեւեց, մինչեւ վերջապես հասկացա, որ քննարկում ենք հարցի տեխնիկական կողմերը, բայց խնդիրն իրականում տեխնիկական չէր։ Խնդիրը STL-ի առավելություններն ու թերությունները կամ առանց դրա աշխատելու դժվարությունը չեն: Խնդիրը բավականին կազմակերպչական է։ Պարզապես պետք էր հասկանալ, թե ինչպես է աշխատում այն ​​ընկերությունը, որտեղ մենք աշխատում էինք: Մեզնից ոչ ոք նախկինում նման ընկերությունում աշխատելու փորձ չի ունեցել։ Բանն այն էր, որ ծածկագրի մշակումից և արտադրության մեջ թողարկվելուց հետո աջակցությունը վարում էին բոլորովին այլ մարդիկ այլ թիմերից, այլ երկրներից: Մի քանի տասնյակ հազար ինժեներներից կազմված այս հսկայական ինժեներական թիմը (ընդհանուր առմամբ) կարող էր իրեն թույլ տալ միայն տեխնիկական միջոցների միանգամայն տարրական նվազագույնը, այսպես ասած, նվազագույն նվազագույնը։ Այն, ինչ ֆիզիկապես գերազանցում էր ընկերությունում հաստատված ինժեներական ստանդարտը, ապագայում չի կարող ապահովվել: Թիմի մակարդակը որոշվում է նրա ամենաթույլ անդամների մակարդակով: Այն բանից հետո, երբ մենք հասկացանք իրական մոտիվացիա թիմի ամերիկյան մասի գործողություններով, այս հարցը հանվեց օրակարգից, և մենք միասին հաջողությամբ մշակեցինք և թողարկեցինք արտադրանքը՝ օգտագործելով ընկերության կողմից ընդունված չափանիշները: Նամակներն ու չաթերն այս դեպքում լավ չէին ստացվում, ընդհանուր հայտարարի գալու համար պահանջվեցին մի քանի ճամփորդություններ և շատ անձնական շփումներ:

Աշխատանքի ընթացքի տեսանկյունից, կոնկրետ այս դեպքում, կօգնի ունենալ օգտագործվող գործիքների նկարագրությունը, դրանց պահանջները, նորերը ավելացնելու սահմանափակումները և նման սահմանափակումների հիմնավորումը: Նման փաստաթղթերը մոտավորապես համապատասխանում են «Վերօգտագործման ռազմավարություն և զարգացման միջավայր» պարբերություններում նկարագրված «Մենեջերի ձեռնարկ ծրագրային ապահովման մշակման համար», որը մշակվել է ս. NASA. Չնայած իր տարիքին, այն հիանալի նկարագրում է այս տեսակի ծրագրային ապահովման մշակման բոլոր հիմնական գործողությունները և պլանավորման փուլերը: Նման փաստաթղթերի առկայությունը շատ հեշտ է դարձնում քննարկել, թե ինչ բաղադրիչներ և մոտեցումներ կարող են օգտագործվել արտադրանքի մեջ և ինչու:

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

Տեխնիկական լուծման ընտրության հետ կապված մեկ այլ կոնֆլիկտի ժամանակ ինձ նաև նկատելի ժամանակ պահանջվեց կողմերից մեկի մոտիվացիան հասկանալու համար (դա շատ անսովոր դեպք էր), բայց մոտիվացիան պարզ լինելուց հետո լուծումն ակնհայտ էր։

Իրավիճակն այսպիսին է. մոտ 20 հոգանոց թիմում հայտնվում է նոր ծրագրավորող, եկեք նրան անվանենք Ստաս: Այն ժամանակ թիմային հաղորդակցության մեր ստանդարտ գործիքը Skype-ն էր: Ինչպես պարզվեց ավելի ուշ, Ստասը բաց ստանդարտների և բաց կոդով ծրագրաշարի մեծ երկրպագու էր և օգտագործում էր միայն գործիքներ և օպերացիոն համակարգեր, որոնց աղբյուրները հասանելի էին հանրությանը և օգտագործում էին հրապարակայնորեն նկարագրված արձանագրություններ: Skype-ը այս գործիքներից չէ: Մենք շատ ժամանակ ենք ծախսել՝ քննարկելով այս մոտեցման առավելություններն ու թերությունները, Skype-ի անալոգները տարբեր օպերացիոն համակարգերում գործարկելու փորձերը, Ստասի փորձերը՝ թիմին համոզելու անցնել այլ ստանդարտների, անձամբ գրել նրան փոստով, անձամբ զանգահարել նրան։ հեռախոս, գնեք նրան երկրորդ համակարգիչ հատուկ Skype-ի համար և այլն։ Վերջապես հասկացա, որ այս խնդիրն, ըստ էության, տեխնիկական կամ կազմակերպչական չէ, ավելի շուտ գաղափարական է, նույնիսկ, կարելի է ասել, կրոնական (Ստասի համար)։ Նույնիսկ եթե մենք ի վերջո միացնեինք Stas-ն ու Skype-ը (ինչը տևեց մի քանի ամիս), խնդիրը նորից կառաջանար ցանկացած հաջորդ գործիքի վրա: Ստասի աշխարհայացքը փոխելու իրական միջոցներ չունեի իմ տրամադրության տակ, և պատճառ չկար փորձել փոխել այս միջավայրում հիանալի աշխատող թիմի աշխարհայացքը։ Անձն ու ընկերությունը իրենց աշխարհայացքով ուղղակի ուղղանկյուն էին։ Նման իրավիճակներում լավ լուծումը կազմակերպչական է։ Ստասին տեղափոխեցինք այլ թիմ, որտեղ նա ավելի օրգանական էր։

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

Ե՛վ մշակողի մանկական վերաբերմունքով, և՛ աշխատանքային գործընթացի թերություններով պայմանավորված կոնֆլիկտի լավ օրինակ է այն իրավիճակը, երբ կատարվածի սահմանման բացակայության դեպքում մշակողը և ՈԱ թիմը տարբեր ակնկալիքներ ունեն՝ կապված պատրաստակամության հետ: հատկանիշը փոխանցվել է QA-ին: Մշակողը կարծում էր, որ բավական է գրել կոդը և հնարավորությունը ցանկապատի վրայով գցել QA-ին. նրանք այնտեղ կդասավորեն այն: Բավականին հասուն ու փորձառու ծրագրավորող, ի դեպ, բայց դա նրա որակի ներքին շեմն էր։ ՔԱ-ն չհամաձայնեց սրա հետ և պահանջեց ցույց տալ և նկարագրել իրենց այն, ինչ ինքն է ստուգել, ​​և նրանց համար պահանջեց թեստավորման սցենար: Նրանք նախկինում խնդիրներ ունեին այս մշակողի ֆունկցիոնալության հետ և չէին ուզում նորից վատնել իրենց ժամանակը: Ի դեպ, նրանք ճիշտ էին. հատկանիշն իսկապես չէր աշխատում, նա չստուգեց կոդը նախքան այն QA ուղարկելը:

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

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

Հակամարտության ևս մեկ տիպիկ օրինակ, որը սերտորեն կապված է աշխատանքային գործընթացի կազմակերպման հետ: Մենք ունենք արտադրանք, արտադրանքի մշակման թիմ, աջակցող թիմ և հաճախորդ: Հաճախորդը խնդիրներ ունի արտադրանքի հետ և կապվում է աջակցության հետ: Աջակցությունը վերլուծում է խնդիրը և հասկանում, որ խնդիրը ապրանքի մեջ է և խնդիրը փոխանցում է արտադրանքի թիմին: Ապրանքի թիմը զբաղված ժամանակ է, մոտենում է թողարկումը, ուստի հաճախորդի կողմից խնդիր ունեցող տոմսը, որը կորել է մշակողի մյուս տոմսերի շարքում, որին այն նշանակված է, կախված է մի քանի շաբաթ առանց ուշադրության: Աջակցությունը կարծում է, որ մշակողը աշխատում է հաճախորդի խնդրի վրա։ Հաճախորդը սպասում է և հուսով է, որ իրենց խնդրի վրա աշխատանքներ են տարվում։ Իրականում դեռ ոչինչ չի կատարվում։ Մի քանի շաբաթ անց հաճախորդը վերջապես որոշում է հետաքրքրվել առաջընթացով և օգնություն է խնդրում, թե ինչպես են ընթանում գործերը: Աջակցությունը պահանջում է զարգացում: Կառուցապատողը դողում է, թերթում է տոմսերի ցանկը և այնտեղ գտնում է գնորդից տոմս: Հաճախորդից տոմս կարդալով՝ նա հասկանում է, որ խնդիրը լուծելու համար բավարար տեղեկատվություն չկա, և իրեն ավելի շատ գերաններ ու աղբավայրեր են պետք։ Աջակցությունը հաճախորդից լրացուցիչ տեղեկություններ է խնդրում: Եվ հետո հաճախորդը հասկանում է, որ այս ամբողջ ընթացքում ոչ ոք չի աշխատել իր խնդրի վրա։ Եվ որոտը կհարվածի...

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

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

Մեկ այլ տիպիկ օրինակ, որը ես բազմիցս տեսել եմ տարբեր ընկերություններում, մի իրավիճակ է, երբ ապրանքը գրվում է մեկ թիմի կողմից, դրա համար ավտոմատ ինտեգրման թեստերը գրվում են երկրորդ թիմի կողմից, և ենթակառուցվածքը, որի վրա այն գործարկվում է, ուղեկցվում է երրորդով: թիմը։ Անընդհատ թեստերն աշխատելիս խնդիրներ են առաջանում, և դրանցում խնդիրների պատճառ կարող են լինել և՛ արտադրանքը, և՛ թեստերն ու ենթակառուցվածքը: Սովորաբար խնդրահարույց է պայմանավորվել, թե ով պետք է կատարի խնդիրների նախնական վերլուծությունը, ֆայլերի սխալները, արտադրանքի տեղեկամատյանների վերլուծությունը, թեստերը և ենթակառուցվածքը և այլն: Այստեղ կոնֆլիկտները շատ հաճախակի են, և, միևնույն ժամանակ, միատեսակ։ Բարձր հուզական ինտենսիվության դեպքում մասնակիցները հաճախ ընկնում են մանկական դիրքի մեջ, և սերիալում սկսվում են քննարկումներ՝ «ինչու՞ պետք է սրա հետ վարվեմ», «ավելի հաճախ են կոտրվում» և այլն։

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

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

Source: www.habr.com