რა დაგვეხმარა ახალ პირობებში ონლაინ ვაჭრობის სწრაფად ადაპტაციაში

Hi!

მე მქვია მიხაილი, ვარ კომპანია Sportmaster-ის IT დირექტორის მოადგილე. მინდა გაგიზიაროთ ისტორია იმის შესახებ, თუ როგორ გავუმკლავდით გამოწვევებს, რომლებიც წარმოიშვა პანდემიის დროს.

ახალი რეალობის პირველ დღეებში Sportmaster-ის ჩვეულებრივი ოფლაინ ვაჭრობის ფორმატი გაიყინა და ჩვენს ონლაინ არხზე დატვირთვა, უპირველეს ყოვლისა, კლიენტის მისამართზე მიწოდების კუთხით, 10-ჯერ გაიზარდა. სულ რამდენიმე კვირაში, ჩვენ გადავაქციეთ გიგანტური ოფლაინ ბიზნესი ონლაინ ბიზნესად და მოვარგეთ სერვისი ჩვენი კლიენტების საჭიროებებს.

ძირითადად, ის, რაც არსებითად იყო ჩვენი გვერდითი ოპერაცია, გახდა ჩვენი ძირითადი ბიზნესი. ყოველი ონლაინ შეკვეთის მნიშვნელობა უკიდურესად გაიზარდა. საჭირო იყო თითოეული რუბლის დაზოგვა, რომელიც კლიენტმა მოიტანა კომპანიაში. 

მომხმარებელთა მოთხოვნებზე სწრაფად რეაგირებისთვის, ჩვენ გავხსენით დამატებითი საკონტაქტო ცენტრი კომპანიის მთავარ ოფისში და ახლა შეგვიძლია მივიღოთ დაახლოებით 285 ათასი ზარი კვირაში. ამავდროულად, ჩვენ გადავიყვანეთ 270 მაღაზია ახალ უკონტაქტო და უსაფრთხო ოპერაციულ ფორმატში, რაც მომხმარებელს საშუალებას აძლევდა მიეღოთ შეკვეთები და თანამშრომლებს შეენარჩუნებინათ სამუშაო.

ტრანსფორმაციის პროცესში ორი ძირითადი პრობლემა შეგვხვდა. ჯერ ერთი, მნიშვნელოვნად გაიზარდა დატვირთვა ჩვენს ონლაინ რესურსებზე (სერგეი გეტყვით, როგორ გავუმკლავდით ამას). მეორეც, იშვიათი (COVID-მდე) ოპერაციების ნაკადი მრავალჯერ გაიზარდა, რაც თავის მხრივ მოითხოვდა დიდი რაოდენობით სწრაფ ავტომატიზაციას. ამ პრობლემის გადასაჭრელად მოგვიწია რესურსების სწრაფად გადატანა იმ სფეროებიდან, რომლებიც ადრე მთავარი იყო. ელენა გეტყვით, როგორ გავუმკლავდით ამას.

ონლაინ სერვისების ოპერირება

კოლესნიკოვი სერგეი, პასუხისმგებელი ონლაინ მაღაზიისა და მიკროსერვისების მუშაობაზე

იმ მომენტიდან, როდესაც ჩვენმა საცალო მაღაზიებმა დაიწყეს ვიზიტორებთან დახურვა, ჩვენ დავიწყეთ მეტრიკის ზრდა, როგორიცაა მომხმარებელთა რაოდენობა, ჩვენს აპლიკაციაში განთავსებული შეკვეთების რაოდენობა და აპლიკაციების მიმართ მოთხოვნის რაოდენობა. 

შეკვეთების რაოდენობა 18 მარტიდან 31 მარტამდემოთხოვნის რაოდენობა ონლაინ გადახდის მიკროსერვისებზესაიტზე განთავსებული შეკვეთების რაოდენობა

პირველ გრაფიკზე ვხედავთ, რომ ზრდა იყო დაახლოებით 14-ჯერ, მეორეში - 4-ჯერ. ჩვენ მიგვაჩნია, რომ ჩვენი აპლიკაციების რეაგირების დროის მეტრიკა ყველაზე საჩვენებლად. 

ამ დიაგრამაში ჩვენ ვხედავთ ფრონტებისა და აპლიკაციების პასუხს და ჩვენ თვითონ დავადგინეთ, რომ ჩვენ ვერ შევამჩნიეთ რაიმე ზრდა, როგორც ასეთი.

ეს, პირველ რიგში, განპირობებულია იმით, რომ 2019 წლის ბოლოს დავიწყეთ მოსამზადებელი სამუშაოები. ახლა ჩვენი სერვისები დაცულია, შეცდომების ტოლერანტობა უზრუნველყოფილია ფიზიკური სერვერების, ვირტუალიზაციის სისტემების, დოკერების და მათში არსებული სერვისების დონეზე. ამავდროულად, ჩვენი სერვერის რესურსების სიმძლავრე საშუალებას გვაძლევს გავუძლოთ მრავალ დატვირთვას.

მთავარი ინსტრუმენტი, რომელიც დაგვეხმარა მთელ ამ ამბავში, ჩვენი მონიტორინგის სისტემა იყო. მართალია, ბოლო დრომდე ჩვენ არ გვქონდა ერთიანი სისტემა, რომელიც მოგვცემდა საშუალებას შეგვეგროვებინა მეტრიკა ყველა ფენაში, ფიზიკური აღჭურვილობისა და ტექნიკის დონიდან ბიზნეს მეტრიკის დონემდე. 

კომპანიაში ფორმალურად იყო მონიტორინგი, მაგრამ როგორც წესი იყო დაშლილი და კონკრეტული განყოფილებების პასუხისმგებლობის ზონაში იყო. სინამდვილეში, როდესაც ინციდენტი ხდებოდა, ჩვენ თითქმის არასოდეს გვქონდა საერთო გაგება, თუ რა მოხდა ზუსტად, არ იყო კომუნიკაცია და ხშირად ეს იწვევდა წრეებში სირბილს პრობლემის მოსაძებნად და იზოლირებისთვის, რათა გამოსწორებულიყო.

რაღაც მომენტში, ჩვენ ვიფიქრეთ და გადავწყვიტეთ, რომ საკმარისი იყო ამის ატანა - გვჭირდებოდა ერთიანი სისტემა, რომ სრული სურათი გვენახა. ძირითადი ტექნოლოგიები, რომლებიც შედის ჩვენს სტეკში არის Zabbix, როგორც გაფრთხილებისა და მეტრიკის შესანახი ცენტრი, Prometheus აპლიკაციების მეტრიკის შეგროვებისა და შესანახად, Stack ELK მონაცემების აღრიცხვისა და შესანახად მთელი მონიტორინგის სისტემიდან, ასევე Grafana ვიზუალიზაციისთვის, Swagger, Docker. და სხვა სასარგებლო და თქვენთვის ნაცნობი ნივთები.

ამავდროულად, ჩვენ ვიყენებთ არა მხოლოდ ბაზარზე არსებულ ტექნოლოგიებს, არამედ ვავითარებთ ჩვენს ზოგიერთს. მაგალითად, ჩვენ ვაკეთებთ სერვისებს სისტემების ერთმანეთთან ინტეგრირებისთვის, ანუ ერთგვარ API-ს მეტრიკის შეგროვებისთვის. გარდა ამისა, ჩვენ ვმუშაობთ საკუთარი მონიტორინგის სისტემებზე - ბიზნეს მეტრიკის დონეზე ვიყენებთ UI ტესტებს. და ასევე ბოტი Telegram-ში, რომ აცნობოს გუნდებს.

ჩვენ ასევე ვცდილობთ, რომ მონიტორინგის სისტემა ხელმისაწვდომი გავხადოთ გუნდებისთვის, რათა მათ შეძლონ დამოუკიდებლად შეინახონ და იმუშაონ თავიანთი მეტრიკებით, მათ შორის, გაფრთხილებების დაყენება ზოგიერთი ვიწრო მეტრიკისთვის, რომლებიც ფართოდ არ გამოიყენება. 

მთელი სისტემის განმავლობაში ჩვენ ვცდილობთ პროაქტიულობისკენ და ინციდენტების რაც შეიძლება სწრაფად ლოკალიზაციას. გარდა ამისა, ბოლო დროს მნიშვნელოვნად გაიზარდა ჩვენი მიკროსერვისებისა და სისტემების რაოდენობა და შესაბამისად გაიზარდა ინტეგრაციების რაოდენობაც. და, როგორც ინტეგრაციის დონეზე ინციდენტების დიაგნოსტიკის პროცესის ოპტიმიზაციის ნაწილი, ჩვენ ვავითარებთ სისტემას, რომელიც საშუალებას გაძლევთ ჩაატაროთ ჯვარედინი სისტემური შემოწმებები და აჩვენოთ შედეგი, რაც საშუალებას გაძლევთ იპოვოთ ძირითადი პრობლემები, რომლებიც დაკავშირებულია იმპორტთან და სისტემების ურთიერთქმედებით. ერთმანეთი. 

რა თქმა უნდა, ოპერაციული სისტემების კუთხით ჯერ კიდევ გვაქვს განვითარებისა და განვითარების ადგილი და ამაზე აქტიურად ვმუშაობთ. შეგიძლიათ მეტი წაიკითხოთ ჩვენი მონიტორინგის სისტემის შესახებ აქ. 

ტექნიკური ტესტები 

ორლოვ სერგეი, ვებ და მობილური განვითარების კომპეტენციის ცენტრს ხელმძღვანელობს

მას შემდეგ რაც დაიწყო ფიზიკური მაღაზიის დახურვა, განვითარების პერსპექტივიდან სხვადასხვა გამოწვევების წინაშე ვდგავართ. უპირველეს ყოვლისა, დატვირთვის მატება, როგორც ასეთი. გასაგებია, რომ თუ არ მიიღება შესაბამისი ზომები, მაშინ როდესაც სისტემას დიდი დატვირთვა ეკისრება, ის შეიძლება გადაიქცეს გოგრად სევდიანი აფეთქებით, ან მთლიანად დაქვეითდეს შესრულებაში, ან თუნდაც დაკარგოს ფუნქციონირება.

მეორე ასპექტი, ოდნავ ნაკლებად აშკარა, არის ის, რომ მაღალი დატვირთვის ქვეშ მყოფი სისტემა ძალიან სწრაფად უნდა შეიცვალოს, ბიზნეს პროცესების ცვლილებებთან ადაპტირება. ზოგჯერ დღეში რამდენჯერმე. ბევრ კომპანიას აქვს წესი, რომ თუ ბევრი მარკეტინგული აქტივობაა, სისტემაში ცვლილებების შეტანა საჭირო არ არის. საერთოდ არცერთი, ნება მიეცით იმუშაოს მანამ, სანამ მუშაობს.

და ჩვენ არსებითად გვქონდა გაუთავებელი შავი პარასკევი, რომლის დროსაც საჭირო იყო სისტემის შეცვლა. და სისტემის ნებისმიერი შეცდომა, პრობლემა ან წარუმატებლობა ძალიან ძვირი დაუჯდება ბიზნესს.

მომავალს რომ ვუყურებ, ვიტყვი, რომ ჩვენ მოვახერხეთ ამ ტესტების გამკლავება, ყველა სისტემამ გაუძლო დატვირთვას, ადვილად მასშტაბური იყო და ჩვენ არ განგვიცდია რაიმე გლობალური ტექნიკური ხარვეზი.

არსებობს ოთხი საყრდენი, რომლებზეც ეყრდნობა სისტემის უნარი გაუძლოს მაღალი ტალღის დატვირთვას. პირველი მათგანი არის მონიტორინგი, რომლის შესახებაც ზემოთ წაიკითხეთ. ჩაშენებული მონიტორინგის სისტემის გარეშე, თითქმის შეუძლებელია სისტემის ბლოკირების პოვნა. კარგი მონიტორინგის სისტემა სახლის ტანსაცმელს ჰგავს, ის კომფორტული და თქვენზე მორგებული უნდა იყოს.

მეორე ასპექტი არის ტესტირება. ჩვენ ძალიან სერიოზულად ვეკიდებით ამ საკითხს: ჩვენ ვწერთ კლასიკურ ერთეულებს, ინტეგრაციის ტესტებს, დატვირთვის ტესტებს და ბევრ სხვას თითოეული სისტემისთვის. ჩვენ ასევე ვწერთ ტესტირების სტრატეგიას და ამავდროულად ვცდილობთ გავზარდოთ ტესტირების დონე იმ დონემდე, რომ აღარ გვჭირდება ხელით შემოწმება.

მესამე საყრდენი არის CI/CD მილსადენი. აპლიკაციის აშენების, ტესტირებისა და განლაგების პროცესები მაქსიმალურად უნდა იყოს ავტომატიზირებული, ხელით ჩარევა არ უნდა მოხდეს. CI/CD Pipeline-ის თემა საკმაოდ ღრმაა და მას მხოლოდ მოკლედ შევეხები. აღსანიშნავია მხოლოდ ის, რომ ჩვენ გვაქვს CI/CD Pipeline checklist, რომელსაც თითოეული პროდუქტის გუნდი გადის კომპეტენციის ცენტრების დახმარებით.

და აქ არის საკონტროლო სია

ამ გზით ბევრი მიზანი მიიღწევა. ეს არის API ვერსიები და ფუნქციების გადართვა, რათა თავიდან იქნას აცილებული გამოშვების მატარებელი და მიაღწიოს სხვადასხვა ტესტების გაშუქებას ისეთ დონეზე, რომ ტესტირება იყოს სრულად ავტომატიზირებული, განლაგება იყოს უწყვეტი და ა.შ.

მეოთხე საყრდენი არის არქიტექტურული პრინციპები და ტექნიკური გადაწყვეტილებები. არქიტექტურაზე შეიძლება ბევრი ვისაუბროთ დიდი ხნის განმავლობაში, მაგრამ მინდა ხაზი გავუსვა რამდენიმე პრინციპს, რომლებზეც მინდა გავამახვილო ყურადღება.

პირველ რიგში, თქვენ უნდა აირჩიოთ სპეციალიზებული ინსტრუმენტები კონკრეტული ამოცანებისთვის. დიახ, ეს აშკარად ჟღერს და გასაგებია, რომ ლურსმნები ჩაქუჩით უნდა იყოს ჩასმული, მაჯის საათები კი სპეციალური ხრახნებით უნდა დაიშალა. მაგრამ ჩვენს ეპოქაში ბევრი ინსტრუმენტი ისწრაფვის უნივერსალიზაციისკენ, რათა მოიცვას მომხმარებელთა მაქსიმალური სეგმენტი: მონაცემთა ბაზები, ქეშები, ჩარჩოები და დანარჩენი. მაგალითად, თუ აიღებთ MongoDB მონაცემთა ბაზას, ის მუშაობს მრავალდოკუმენტურ ტრანზაქციებზე, ხოლო Oracle მონაცემთა ბაზა მუშაობს json-თან. და როგორც ჩანს, ყველაფრის გამოყენება შესაძლებელია ყველაფრისთვის. მაგრამ თუ ჩვენ ვიცავთ პროდუქტიულობას, მაშინ მკაფიოდ უნდა გვესმოდეს თითოეული ხელსაწყოს ძლიერი და სუსტი მხარეები და გამოვიყენოთ ის, რაც გვჭირდება ჩვენი კლასის დავალებებისთვის. 

მეორეც, სისტემების დაპროექტებისას სირთულის ყოველი ზრდა გამართლებული უნდა იყოს. ეს მუდმივად უნდა გვახსოვდეს, დაბალი დაწყვილების პრინციპი ყველასთვის ცნობილია. მიმაჩნია, რომ ეს უნდა იქნას გამოყენებული კონკრეტული სერვისის დონეზე, მთელი სისტემის დონეზე და არქიტექტურული ლანდშაფტის დონეზე. ასევე მნიშვნელოვანია სისტემის თითოეული კომპონენტის ჰორიზონტალურად გაზომვის შესაძლებლობა დატვირთვის გზაზე. თუ თქვენ გაქვთ ეს უნარი, სკალირება არ გაგიჭირდებათ.

ტექნიკურ გადაწყვეტილებებზე საუბრისას, ჩვენ ვთხოვეთ პროდუქტის გუნდებს მოემზადებინათ რეკომენდაციების, იდეებისა და გადაწყვეტილებების ახალი ნაკრები, რომელიც მათ განახორციელეს სამუშაო დატვირთვის შემდეგი ტალღისთვის მოსამზადებლად.

ქეში

აუცილებელია შეგნებულად მივუდგეთ ლოკალური და განაწილებული ქეშების არჩევანს. ზოგჯერ აზრი აქვს ორივეს ერთ სისტემაში გამოყენებას. მაგალითად, გვაქვს სისტემები, რომლებშიც ზოგიერთი მონაცემი არსებითად არის გამოფენის ქეში, ანუ განახლების წყარო მდებარეობს თავად სისტემის უკან და სისტემები არ იცვლება. ამ მონაცემს. ამ მიდგომისთვის ჩვენ ვიყენებთ ადგილობრივ კოფეინის ქეშს. 

და არის მონაცემები, რომ სისტემა აქტიურად იცვლება ოპერაციის დროს და აქ უკვე ვიყენებთ განაწილებულ ქეშს Hazelcast-ით. ეს მიდგომა საშუალებას გვაძლევს გამოვიყენოთ განაწილებული ქეშის უპირატესობები იქ, სადაც ისინი ნამდვილად საჭიროა, და მინიმუმამდე დავიყვანოთ Hazelcast კლასტერული მონაცემების მიმოქცევის სერვისის ხარჯები, სადაც ამის გარეშე შეგვიძლია. ჩვენ ბევრი დავწერეთ ქეშებზე. აქ и აქ.

გარდა ამისა, Hazelcast-ში სერიალიზატორის Kryo-ზე შეცვლამ კარგი სტიმული მოგვცა. და Hazelcast-ში ReplicatedMap-დან IMap + Near Cache-ზე გადასვლამ საშუალება მოგვცა მინიმუმამდე შეგვეყვანა მონაცემთა გადაადგილება კლასტერში. 

მცირე რჩევა: მასიური ქეშის გაუქმების შემთხვევაში, ზოგჯერ გამოიყენება მეორე ქეშის გახურების და შემდეგ მასზე გადართვის ტაქტიკა. როგორც ჩანს, ამ მიდგომით უნდა მივიღოთ მეხსიერების ორმაგი მოხმარება, მაგრამ პრაქტიკაში, იმ სისტემებში, სადაც ეს იყო პრაქტიკული, მეხსიერების მოხმარება შემცირდა.

რეაქტიული დასტა

ჩვენ ვიყენებთ რეაქტიულ დასტას საკმაოდ დიდ სისტემებში. ჩვენს შემთხვევაში, ეს არის Webflux ან Kotlin კორუტინებით. რეაქტიული დასტა განსაკუთრებით კარგია იქ, სადაც ჩვენ ველოდებით ნელი შეყვანის-გამოსვლის ოპერაციებს. მაგალითად, ზარები შენელებულ სერვისებზე, ფაილურ სისტემასთან ან შენახვის სისტემებთან მუშაობა.

ყველაზე მნიშვნელოვანი პრინციპია ზარების დაბლოკვის თავიდან აცილება. რეაქტიულ ჩარჩოებს აქვთ მცირე რაოდენობის ცოცხალი სერვისის ძაფები, რომლებიც გაშვებულია ქუდის ქვეშ. თუ ჩვენ უყურადღებოდ მივცემთ საკუთარ თავს უფლებას განვახორციელოთ პირდაპირი დაბლოკვის ზარი, როგორიცაა JDBC დრაივერის ზარი, სისტემა უბრალოდ გაჩერდება. 

შეეცადეთ გადააქციოთ შეცდომები თქვენს გამონაკლისად. პროგრამის შესრულების რეალური ნაკადი გადადის რეაქტიულ ჩარჩოებზე და კოდის შესრულება ხდება არაწრფივი. შედეგად, ძალიან რთულია პრობლემების დიაგნოსტიკა სტეკის კვალის გამოყენებით. და გამოსავალი აქ იქნება მკაფიო, ობიექტური გამონაკლისების შექმნა ყოველი შეცდომისთვის.

ელასტიური ძებნა

Elasticsearch-ის გამოყენებისას არ აირჩიოთ გამოუყენებელი მონაცემები. ეს, პრინციპში, ასევე ძალიან მარტივი რჩევაა, მაგრამ ყველაზე ხშირად ეს არის ის, რაც დავიწყებულია. თუ თქვენ გჭირდებათ ერთდროულად 10 ათასზე მეტი ჩანაწერის არჩევა, უნდა გამოიყენოთ Scroll. ანალოგიის გამოსაყენებლად, ის ცოტათი ჰგავს კურსორს რელაციურ მონაცემთა ბაზაში. 

არ გამოიყენოთ პოსტფილტრი, თუ საჭირო არ არის. ძირითადი ნიმუშის დიდი მონაცემებით, ეს ოპერაცია მნიშვნელოვნად იტვირთება მონაცემთა ბაზაში. 

გამოიყენეთ ნაყარი ოპერაციები, სადაც ეს შესაძლებელია.

API

API-ის შემუშავებისას შეიყვანეთ მოთხოვნები გადაცემული მონაცემების მინიმიზაციისთვის. ეს განსაკუთრებით ეხება ფრონტთან დაკავშირებით: სწორედ ამ კვანძზე გავდივართ ჩვენი მონაცემთა ცენტრების არხებს და უკვე ვმუშაობთ არხზე, რომელიც გვაკავშირებს კლიენტთან. თუ მას აქვს ოდნავი პრობლემა, ძალიან ბევრი ტრაფიკი იწვევს მომხმარებლის უარყოფით გამოცდილებას.

და ბოლოს, ნუ გადააგდებთ მონაცემთა მთელ კრებულს, იყავით მკაფიო ხელშეკრულების შესახებ მომხმარებლებსა და მომწოდებლებს შორის.

ორგანიზაციული ტრანსფორმაცია

ეროშკინა ელენა, IT დირექტორის მოადგილე

იმ მომენტში, როდესაც მოხდა კარანტინი და გაჩნდა საჭიროება მკვეთრად გაზრდილიყო ონლაინ განვითარების ტემპი და შემოგვეღო ომნიკანალური სერვისები, ჩვენ უკვე ორგანიზაციული ტრანსფორმაციის პროცესში ვიყავით. 

ჩვენი სტრუქტურის ნაწილი სამუშაოზე გადავიდა პროდუქტის მიდგომის პრინციპებისა და პრაქტიკის მიხედვით. ჩამოყალიბდა გუნდები, რომლებიც ახლა პასუხისმგებელნი არიან თითოეული პროდუქტის მუშაობასა და განვითარებაზე. ასეთ გუნდებში თანამშრომლები 100%-ით არიან ჩართულნი და აწყობენ თავიანთ სამუშაოს Scrum-ის ან Kanban-ის გამოყენებით, იმისდა მიხედვით, თუ რა არის მათთვის სასურველი, განლაგების მილსადენის შექმნა, ტექნიკური პრაქტიკის განხორციელება, ხარისხის უზრუნველყოფის პრაქტიკა და მრავალი სხვა.

საბედნიეროდ, ჩვენი პროდუქტის გუნდების დიდი ნაწილი იყო ონლაინ და ყოვლისმომცველი სერვისების სფეროში. ამან საშუალება მოგვცა უმოკლეს დროში (სერიოზულად, ფაქტიურად ორ დღეში) გადართვა დისტანციური მუშაობის რეჟიმში ეფექტურობის დაკარგვის გარეშე. მორგებულმა პროცესმა მოგვცა საშუალება სწრაფად შევეგუებოდით ახალ სამუშაო პირობებს და შეგვენარჩუნებინა ახალი ფუნქციების მიწოდების საკმაოდ მაღალი ტემპი.

გარდა ამისა, ჩვენ გვჭირდება იმ გუნდების გაძლიერება, რომლებიც ონლაინ ბიზნესის საზღვარზე არიან. იმ მომენტში გაირკვა, რომ ამის გაკეთება მხოლოდ შიდა რესურსებით შეგვეძლო. და დაახლოებით 50 ადამიანმა ორ კვირაში შეცვალა ტერიტორია, სადაც ადრე მუშაობდა და ჩაერთო მათთვის ახალ პროდუქტზე მუშაობაში. 

ამას არ სჭირდებოდა მენეჯმენტის განსაკუთრებული ძალისხმევა, რადგან ჩვენი საკუთარი პროცესის ორგანიზებასთან, პროდუქტის ტექნიკურ გაუმჯობესებასთან და ხარისხის უზრუნველყოფის პრაქტიკასთან ერთად, ჩვენ ვასწავლით ჩვენს გუნდებს თვითორგანიზებას - მართონ საკუთარი წარმოების პროცესი ადმინისტრაციული რესურსების ჩართვის გარეშე.

ჩვენ შევძელით ჩვენი მენეჯმენტის რესურსების ფოკუსირება ზუსტად იქ, სადაც საჭირო იყო იმ მომენტში - ბიზნესთან ერთად კოორდინაციაზე: რა არის ახლა მნიშვნელოვანი ჩვენი კლიენტისთვის, რა ფუნქციონირება უნდა განხორციელდეს პირველ რიგში, რა უნდა გავაკეთოთ იმისათვის, რომ გავზარდოთ ჩვენი გამტარუნარიანობა. შეკვეთების მიწოდება და დამუშავება. ამ ყველაფერმა და მკაფიო მისაბაძი მოდელმა შესაძლებელი გახადა ამ პერიოდის განმავლობაში დატვირთოთ ჩვენი წარმოების ღირებულების ნაკადები იმით, რაც მართლაც მნიშვნელოვანია და აუცილებელია. 

გასაგებია, რომ დისტანციური მუშაობისა და ცვლილებების მაღალი ტემპით, როდესაც ბიზნესის ინდიკატორები დამოკიდებულია ყველას მონაწილეობაზე, არ შეიძლება დაეყრდნოთ მხოლოდ შინაგან გრძნობებს სერიიდან „ყველაფერი კარგად მიდის ჩვენთან? დიახ, როგორც ჩანს, კარგია. ” საჭიროა წარმოების პროცესის ობიექტური მეტრიკა. ჩვენ გვაქვს ეს, ისინი ხელმისაწვდომია ყველასთვის, ვინც დაინტერესებულია პროდუქტის გუნდების მეტრიკით. პირველ რიგში, თავად გუნდი, ბიზნესი, ქვეკონტრაქტორები და მენეჯმენტი.

ორ კვირაში ერთხელ, თითოეულ გუნდთან იმართება სტატუსი, სადაც 10 წუთის განმავლობაში აანალიზებენ მეტრიკას, წარმოების პროცესში გამოვლენილა ბლაგვები და მუშავდება ერთობლივი გადაწყვეტა: რა შეიძლება გაკეთდეს ამ შეფერხებების აღმოსაფხვრელად. აქ შეგიძლიათ დაუყოვნებლივ მიმართოთ დახმარებას მენეჯმენტისგან, თუ რაიმე გამოვლენილი პრობლემა გუნდების გავლენის ზონის მიღმაა, ან კოლეგების ექსპერტიზა, რომლებსაც შესაძლოა უკვე შეექმნათ მსგავსი პრობლემა.

თუმცა, ჩვენ გვესმის, რომ იმისთვის, რომ რამდენჯერმე ავაჩქაროთ (და ეს არის ზუსტად ის მიზანი, რომელიც საკუთარ თავს დავსახეთ), ჯერ კიდევ ბევრი რამის სწავლა და ყოველდღიურ საქმიანობაში დანერგვა გვჭირდება. ამჟამად ჩვენ ვაგრძელებთ ჩვენი პროდუქტის მიდგომის გაფართოებას სხვა გუნდებისა და ახალი პროდუქტების მიმართ. ამისთვის ჩვენთვის ახალი ფორმატის - მეთოდოლოგთა ონლაინ სკოლის დაუფლება მოგვიწია.

მეთოდოლოგები, ადამიანები, რომლებიც ეხმარებიან გუნდებს პროცესის შექმნაში, კომუნიკაციის დამყარებაში და მუშაობის ეფექტურობის გაუმჯობესებაში, არსებითად არიან ცვლილების აგენტები. ამჟამად, ჩვენი პირველი კოჰორტის კურსდამთავრებულები მუშაობენ გუნდებთან და ეხმარებიან მათ წარმატების მიღწევაში. 

ვფიქრობ, არსებული ვითარება გვიხსნის შესაძლებლობებსა და პერსპექტივებს, რომლებიც, შესაძლოა, ჩვენ თვითონ ჯერ ბოლომდე არ ვიცოდეთ. მაგრამ გამოცდილება და პრაქტიკა, რომელსაც ახლა ვიღებთ, ადასტურებს, რომ ჩვენ ავირჩიეთ განვითარების სწორი გზა, ჩვენ არ გამოვტოვებთ ამ ახალ შესაძლებლობებს მომავალში და შევძლებთ ისეთივე ეფექტურად ვუპასუხოთ გამოწვევებს, რომლებსაც Sportmaster-ის წინაშე დგას.

დასკვნები

ამ რთულ პერიოდში ჩვენ ჩამოვაყალიბეთ ძირითადი პრინციპები, რომლებზეც ეყრდნობა პროგრამული უზრუნველყოფის განვითარება, რაც, ვფიქრობ, აქტუალური იქნება ყველა კომპანიისთვის, რომელიც ამ საქმეს ეხება.

ხალხი. ეს არის ის, რასაც ყველაფერი ეყრდნობა. თანამშრომლებმა უნდა დატკბნენ თავიანთი მუშაობით და გაიგონ კომპანიის მიზნები და იმ პროდუქტების მიზნები, რომლებზეც მუშაობენ. და, რა თქმა უნდა, მათ შეეძლოთ პროფესიული განვითარება. 

Технология. აუცილებელია, რომ კომპანიამ გამოიჩინოს მოწიფული მიდგომა თავისი ტექნოლოგიური წყობით მუშაობისთვის და კომპეტენციების ჩამოყალიბება იქ, სადაც ეს ნამდვილად საჭიროა. ძალიან მარტივად და აშკარად ჟღერს. და ძალიან ხშირად იგნორირებულია.

Процессы. მნიშვნელოვანია პროდუქტის გუნდებისა და კომპეტენციების ცენტრების მუშაობის სწორად ორგანიზება, ბიზნესთან ურთიერთობის დამყარება, რათა მასთან პარტნიორად იმუშაოთ.

ზოგადად, ასე გადავრჩით. ჩვენი დროის მთავარი თეზისი კიდევ ერთხელ დადასტურდა, შუბლზე ხმაურიანი დაწკაპუნით

მაშინაც კი, თუ თქვენ ხართ უზარმაზარი ოფლაინ ბიზნესი, მრავალი მაღაზიით და ქალაქების თაიგულით, სადაც მუშაობთ, განავითარეთ თქვენი ონლაინ ბიზნესი. ეს არ არის მხოლოდ დამატებითი გაყიდვების არხი ან ლამაზი აპლიკაცია, რომლის საშუალებითაც შეგიძლიათ შეიძინოთ რაიმე (და ასევე იმიტომ, რომ კონკურენტებსაც აქვთ ლამაზი). ეს არ არის სათადარიგო საბურავი ყოველი შემთხვევისთვის, რომელიც დაგეხმარებათ ქარიშხლის გატარებაში.

ეს აბსოლუტური აუცილებლობაა. რისთვისაც უნდა მომზადდეს არა მხოლოდ თქვენი ტექნიკური შესაძლებლობები და ინფრასტრუქტურა, არამედ თქვენი ხალხი და პროცესები. ყოველივე ამის შემდეგ, შეგიძლიათ სწრაფად შეიძინოთ დამატებითი მეხსიერება, სივრცე, განათავსოთ ახალი ინსტანციები და ა.შ. რამდენიმე საათში. მაგრამ ხალხი და პროცესები ამისთვის წინასწარ უნდა იყოს მომზადებული.

წყარო: www.habr.com