Ինչն օգնեց մեզ արագ հարմարվել առցանց առևտրին նոր պայմաններում

Hi!

Ես Միխայիլն եմ, «Sportmaster» ընկերության ՏՏ գծով փոխտնօրենն եմ։ Ես ուզում եմ կիսվել պատմությունով, թե ինչպես ենք մենք վարվել համաճարակի ժամանակ առաջացած մարտահրավերների հետ:

Նոր իրողությունների առաջին օրերին Sportmaster-ի սովորական օֆլայն առևտրի ձևաչափը սառեց, և մեր առցանց ալիքի բեռը, հիմնականում հաճախորդի հասցեին առաքման առումով, ավելացավ 10 անգամ: Ընդամենը մի քանի շաբաթվա ընթացքում մենք հսկա օֆլայն բիզնեսը վերածեցինք առցանց բիզնեսի և հարմարեցրինք ծառայությունը մեր հաճախորդների կարիքներին:

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

Հաճախորդների հարցումներին արագ արձագանքելու համար մենք լրացուցիչ կոնտակտային կենտրոն բացեցինք ընկերության գլխավոր գրասենյակում, և այժմ կարող ենք շաբաթական ստանալ մոտ 285 հազար զանգ: Միևնույն ժամանակ, մենք տեղափոխեցինք 270 խանութ նոր անկոնտակտ և անվտանգ աշխատանքային ձևաչափի, որը թույլ տվեց հաճախորդներին ստանալ պատվերներ, իսկ աշխատակիցներին՝ պահպանել իրենց աշխատանքը:

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

Առցանց ծառայությունների շահագործում

Կոլեսնիկով Սերգեյ, առցանց խանութի և միկրոսերվիսների շահագործման պատասխանատու

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

Պատվերների քանակը մարտի 18-ից մարտի 31-ըԱռցանց վճարային միկրոծառայությունների հարցումների քանակըԿայքում տեղադրված պատվերների քանակը

Առաջին գրաֆիկում տեսնում ենք, որ աճը եղել է մոտավորապես 14 անգամ, երկրորդում՝ 4 անգամ։ Մենք համարում ենք, որ մեր դիմումների արձագանքման ժամանակի չափանիշը ամենացուցաբերն է: 

Այս գծապատկերում մենք տեսնում ենք ճակատների և դիմումների արձագանքը, և ինքներս մեզ համար որոշեցինք, որ որպես այդպիսին աճ չենք նկատել։

Սա առաջին հերթին պայմանավորված է նրանով, որ մենք սկսել ենք նախապատրաստական ​​աշխատանքները 2019 թվականի վերջին։ Այժմ մեր ծառայությունները վերապահված են, սխալների հանդուրժողականությունն ապահովված է ֆիզիկական սերվերների, վիրտուալացման համակարգերի, դոկերների և դրանցում առկա ծառայությունների մակարդակում: Միևնույն ժամանակ, մեր սերվերի ռեսուրսների հզորությունը թույլ է տալիս դիմակայել բազմաթիվ բեռների:

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

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

Ինչ-որ պահի մենք մտածեցինք և որոշեցինք, որ բավական է դիմանալ դրան. մեզ անհրաժեշտ է միասնական համակարգ՝ ամբողջ պատկերն ամբողջությամբ տեսնելու համար: Հիմնական տեխնոլոգիաները, որոնք ներառված են մեր ստեկում, Zabbix-ը՝ որպես ահազանգման և չափումների պահպանման կենտրոն, Prometheus-ը՝ հավելվածների չափումների հավաքագրման և պահպանման համար, Stack ELK-ը՝ ամբողջ մոնիտորինգի համակարգից տվյալների գրանցման և պահպանման համար, ինչպես նաև Grafana՝ վիզուալիզացիայի համար, Swagger, Docker: և այլ օգտակար և ձեզ ծանոթ բաներ:

Միևնույն ժամանակ, մենք օգտագործում ենք ոչ միայն շուկայում առկա տեխնոլոգիաները, այլ նաև զարգացնում ենք մեր որոշ տեխնոլոգիաներ: Օրինակ՝ մենք ծառայություններ ենք ստեղծում համակարգերը միմյանց հետ ինտեգրելու համար, այսինքն՝ ինչ-որ API՝ չափումներ հավաքելու համար։ Բացի այդ, մենք աշխատում ենք մեր սեփական մոնիտորինգի համակարգերի վրա. բիզնեսի չափման մակարդակում մենք օգտագործում ենք UI թեստեր: Եվ նաև բոտ Telegram-ում՝ թիմերին ծանուցելու համար:

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

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

Իհարկե, օպերացիոն համակարգերի առումով մենք դեռ աճելու և զարգանալու տեղ ունենք, և մենք ակտիվորեն աշխատում ենք այս ուղղությամբ: Դուք կարող եք կարդալ ավելին մեր մոնիտորինգի համակարգի մասին այստեղ. 

Տեխնիկական փորձարկումներ 

Օրլով Սերգեյը ղեկավարում է վեբ և բջջային ծրագրավորման կոմպետենտ կենտրոնը

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

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

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

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

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

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

Երրորդ սյունը CI/CD Pipeline-ն է: Հավելվածի կառուցման, փորձարկման և տեղադրման գործընթացները պետք է հնարավորինս ավտոմատացված լինեն, ձեռքով միջամտություն չպետք է լինի: CI/CD Pipeline-ի թեման բավականին խորն է, և ես միայն հակիրճ կանդրադառնամ դրան։ Հարկ է միայն նշել, որ մենք ունենք CI/CD Pipeline ստուգաթերթ, որը յուրաքանչյուր ապրանքային թիմ անցնում է իրավասության կենտրոնների օգնությամբ:

Եվ ահա ստուգաթերթը

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

Չորրորդ հենասյունը ճարտարապետական ​​սկզբունքներն ու տեխնիկական լուծումներն են։ Ճարտարապետության մասին կարելի է երկար խոսել, բայց ես ուզում եմ ընդգծել մի երկու սկզբունքներ, որոնց վրա կցանկանայի կենտրոնանալ։

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

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

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

Քեշի

Անհրաժեշտ է գիտակցաբար մոտենալ տեղական և բաշխված քեշերի ընտրությանը։ Երբեմն իմաստ ունի օգտագործել երկուսն էլ միևնույն համակարգում: Օրինակ, մենք ունենք համակարգեր, որոնցում տվյալների մի մասը հիմնականում ցուցադրական քեշ է, այսինքն՝ թարմացումների աղբյուրը գտնվում է հենց համակարգի հետևում, և համակարգերը չեն փոխվում: այս տվյալները։ Այս մոտեցման համար մենք օգտագործում ենք տեղական կոֆեինի քեշը: 

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

Բացի այդ, Hazelcast-ում սերիալիզատորը Kryo-ի փոխելը մեզ լավ խթան տվեց: Եվ Hazelcast-ում ReplicatedMap-ից անցումը IMap + Near Cache-ին թույլ տվեց մեզ նվազագույնի հասցնել տվյալների շարժումը կլաստերի միջով: 

Մի փոքր խորհուրդ. քեշի զանգվածային անվավերության դեպքում երբեմն կիրառելի է երկրորդ քեշը տաքացնելու և այնուհետև դրան անցնելու մարտավարությունը։ Թվում է, թե այս մոտեցմամբ մենք պետք է ստանանք կրկնակի հիշողության սպառում, սակայն գործնականում այն ​​համակարգերում, որտեղ դա կիրառվել է, հիշողության սպառումը նվազել է։

Ռեակտիվ կույտ

Մենք օգտագործում ենք ռեակտիվ ստեկը բավականին մեծ թվով համակարգերում: Մեր դեպքում սա Webflux կամ Kotlin է կորուտիններով: Ռեակտիվ կույտը հատկապես լավ է, որտեղ մենք ակնկալում ենք դանդաղ մուտքային-ելքային գործողություններ: Օրինակ, զանգեր դեպի դանդաղ ծառայություններ, աշխատել ֆայլային համակարգի կամ պահեստավորման համակարգերի հետ:

Ամենակարևոր սկզբունքը զանգերի արգելափակումից խուսափելն է։ Ռեակտիվ շրջանակներն ունեն փոքր թվով կենդանի սպասարկման թելեր, որոնք անցնում են գլխարկի տակ: Եթե ​​մենք անզգույշ թույլ տանք մեզ ուղղակի արգելափակող զանգ կատարել, ինչպիսին է JDBC վարորդի զանգը, համակարգը պարզապես կկանգնի: 

Փորձեք սխալները վերածել ձեր սեփական գործարկման բացառության: Ծրագրի կատարման իրական հոսքը տեղափոխվում է ռեակտիվ շրջանակներ, և կոդի կատարումը դառնում է ոչ գծային: Արդյունքում, շատ դժվար է ախտորոշել խնդիրները՝ օգտագործելով stack traces-ը: Եվ այստեղ լուծումը կլինի յուրաքանչյուր սխալի համար հստակ, օբյեկտիվ գործարկման բացառություններ ստեղծելը:

Elasticsearch- ը

Elasticsearch-ն օգտագործելիս մի ընտրեք չօգտագործված տվյալներ: Սա, սկզբունքորեն, նույնպես շատ պարզ խորհուրդ է, բայց ամենից հաճախ հենց դա է մոռացվում։ Եթե ​​Ձեզ անհրաժեշտ է միաժամանակ ընտրել ավելի քան 10 հազար գրառում, ապա պետք է օգտագործեք Scroll-ը: Անալոգիա օգտագործելու համար այն մի փոքր նման է կուրսորին հարաբերական տվյալների բազայում: 

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

Անհրաժեշտության դեպքում օգտագործեք զանգվածային գործողություններ:

API

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

Եվ վերջապես, մի ​​շպրտեք տվյալների մի ամբողջ փունջ, պարզ եղեք սպառողների և մատակարարների միջև կնքված պայմանագրի վերաբերյալ:

Կազմակերպչական վերափոխում

Էրոշկինա Ելենա, ՏՏ գծով փոխտնօրեն

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

Մեր կառույցի մի մասը աշխատանքի է անցել ապրանքային մոտեցման սկզբունքների և պրակտիկայի համաձայն: Ձևավորվել են թիմեր, որոնք այժմ պատասխանատու են յուրաքանչյուր ապրանքի շահագործման և զարգացման համար: Նման թիմերի աշխատակիցները 100%-ով ներգրավված են և կառուցում են իրենց աշխատանքը Scrum-ի կամ Kanban-ի միջոցով՝ կախված նրանից, թե որն է նրանց համար նախընտրելի, տեղակայման խողովակաշարի ստեղծում, տեխնիկական պրակտիկաներ, որակի ապահովման պրակտիկա և շատ ավելին:

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

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

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

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

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

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

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

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

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

Արդյունքները

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

Մարդիկ. Ահա թե ինչի վրա է ամեն ինչ հենվում։ Աշխատակիցները պետք է վայելեն իրենց աշխատանքը և հասկանան ընկերության նպատակները և այն ապրանքների նպատակները, որոնց վրա նրանք աշխատում են: Եվ, իհարկե, նրանք կարող էին զարգանալ մասնագիտորեն։ 

Технология. Ընկերության համար անհրաժեշտ է հասուն մոտեցում ցուցաբերել իր տեխնոլոգիական փաթեթի հետ աշխատելու և իրավասություններ ստեղծելու համար, որտեղ դա իսկապես անհրաժեշտ է: Այն հնչում է շատ պարզ և ակնհայտ: Եվ շատ հաճախ անտեսվում է:

Գործընթացները. Կարևոր է պատշաճ կերպով կազմակերպել արտադրանքի թիմերի և իրավասությունների կենտրոնների աշխատանքը, փոխգործակցություն հաստատել բիզնեսի հետ՝ նրա հետ որպես գործընկեր աշխատելու համար:

Ընդհանրապես, մենք գրեթե այդպես գոյատևեցինք: Հերթական անգամ հաստատվեց մեր ժամանակների հիմնական թեզը՝ ճակատին հնչեղ կտկտոցով

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

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

Source: www.habr.com