इससे हमें नई परिस्थितियों में ऑनलाइन ट्रेडिंग को शीघ्रता से अपनाने में मदद मिली

हाय!

मेरा नाम मिखाइल है, मैं स्पोर्टमास्टर कंपनी में आईटी का उप निदेशक हूं। मैं यह कहानी साझा करना चाहता हूं कि हम महामारी के दौरान पैदा हुई चुनौतियों से कैसे निपटे।

नई वास्तविकताओं के पहले दिनों में, स्पोर्टमास्टर का सामान्य ऑफ़लाइन ट्रेडिंग प्रारूप बंद हो गया, और हमारे ऑनलाइन चैनल पर लोड, मुख्य रूप से ग्राहक के पते पर डिलीवरी के मामले में, 10 गुना बढ़ गया। कुछ ही हफ्तों में, हमने एक विशाल ऑफ़लाइन व्यवसाय को ऑनलाइन में बदल दिया और सेवा को अपने ग्राहकों की ज़रूरतों के अनुसार अनुकूलित किया।

मूलतः, जो अनिवार्य रूप से हमारा साइड ऑपरेशन था वह हमारा मुख्य व्यवसाय बन गया। हर ऑनलाइन ऑर्डर का महत्व बेहद बढ़ गया है. ग्राहक द्वारा कंपनी में लाए गए प्रत्येक रूबल को बचाना आवश्यक था। 

ग्राहकों के अनुरोधों का तुरंत जवाब देने के लिए, हमने कंपनी के मुख्य कार्यालय में एक अतिरिक्त संपर्क केंद्र खोला, और अब हम प्रति सप्ताह लगभग 285 हजार कॉल प्राप्त कर सकते हैं। उसी समय, हमने 270 स्टोरों को एक नए संपर्क रहित और सुरक्षित संचालन प्रारूप में स्थानांतरित कर दिया, जिससे ग्राहकों को ऑर्डर प्राप्त करने और कर्मचारियों को अपनी नौकरी बनाए रखने की अनुमति मिली।

परिवर्तन प्रक्रिया के दौरान, हमें दो मुख्य समस्याओं का सामना करना पड़ा। सबसे पहले, हमारे ऑनलाइन संसाधनों पर भार काफी बढ़ गया है (सर्गेई आपको बताएंगे कि हमने इससे कैसे निपटा)। दूसरे, दुर्लभ (पूर्व-सीओवीआईडी) परिचालनों का प्रवाह कई गुना बढ़ गया है, जिसके परिणामस्वरूप बड़ी मात्रा में तीव्र स्वचालन की आवश्यकता होती है। इस समस्या को हल करने के लिए, हमें उन क्षेत्रों से संसाधनों को शीघ्रता से स्थानांतरित करना होगा जो पहले मुख्य थे। ऐलेना आपको बताएगी कि हमने इससे कैसे निपटा।

ऑनलाइन सेवाओं का संचालन

कोलेनिकोव सर्गेई, ऑनलाइन स्टोर और माइक्रोसर्विसेज के संचालन के लिए जिम्मेदार

जिस क्षण से हमारे खुदरा स्टोर आगंतुकों के लिए बंद होने लगे, हमने उपयोगकर्ताओं की संख्या, हमारे एप्लिकेशन में दिए गए ऑर्डर की संख्या और एप्लिकेशन के अनुरोधों की संख्या जैसे मेट्रिक्स में वृद्धि दर्ज करना शुरू कर दिया। 

18 मार्च से 31 मार्च तक ऑर्डर की संख्याऑनलाइन भुगतान माइक्रोसर्विसेज के लिए अनुरोधों की संख्यावेबसाइट पर दिए गए ऑर्डरों की संख्या

पहले ग्राफ़ में हम देखते हैं कि वृद्धि लगभग 14 गुना थी, दूसरे में - 4 गुना। हम अपने अनुप्रयोगों की प्रतिक्रिया समय मीट्रिक को सबसे अधिक संकेतक मानते हैं। 

इस ग्राफ़ में हम मोर्चों और अनुप्रयोगों की प्रतिक्रिया देखते हैं, और अपने लिए हमने निर्धारित किया है कि हमने इस तरह की कोई वृद्धि नहीं देखी है।

यह मुख्य रूप से इस तथ्य के कारण है कि हमने 2019 के अंत में तैयारी का काम शुरू किया। अब हमारी सेवाएँ आरक्षित हैं, भौतिक सर्वर, वर्चुअलाइजेशन सिस्टम, डॉकर्स और उनमें सेवाओं के स्तर पर दोष सहिष्णुता सुनिश्चित की जाती है। साथ ही, हमारे सर्वर संसाधनों की क्षमता हमें कई भारों का सामना करने की अनुमति देती है।

इस पूरी कहानी में हमारी मदद करने वाला मुख्य उपकरण हमारी निगरानी प्रणाली थी। सच है, हाल तक हमारे पास एक भी प्रणाली नहीं थी जो हमें भौतिक उपकरण और हार्डवेयर के स्तर से लेकर व्यावसायिक मेट्रिक्स के स्तर तक सभी स्तरों पर मेट्रिक्स एकत्र करने की अनुमति दे। 

औपचारिक रूप से, कंपनी में निगरानी थी, लेकिन एक नियम के रूप में यह बिखरी हुई थी और विशिष्ट विभागों की जिम्मेदारी के क्षेत्र में थी। वास्तव में, जब कोई घटना घटती थी, तो हमें लगभग कभी भी इस बात की आम समझ नहीं होती थी कि वास्तव में क्या हुआ था, कोई संचार नहीं था, और अक्सर इसके कारण समस्या को खोजने और अलग करने के लिए हलकों में दौड़ना पड़ता था ताकि इसे ठीक किया जा सके।

कुछ बिंदु पर, हमने सोचा और निर्णय लिया कि अब हमारे लिए यह सहन करना बहुत संभव है - हमें पूरी तस्वीर को पूरी तरह से देखने के लिए एक एकीकृत प्रणाली की आवश्यकता है। हमारे स्टैक में शामिल मुख्य प्रौद्योगिकियाँ हैं ज़ैबिक्स एक अलर्टिंग और मेट्रिक्स स्टोरेज सेंटर के रूप में, एप्लिकेशन मेट्रिक्स को इकट्ठा करने और संग्रहीत करने के लिए प्रोमेथियस, संपूर्ण मॉनिटरिंग सिस्टम से डेटा लॉगिंग और संग्रहीत करने के लिए स्टैक ईएलके, साथ ही विज़ुअलाइज़ेशन, स्वैगर, डॉकर के लिए ग्राफाना और अन्य उपयोगी और चीजें जो आपसे परिचित हैं।

साथ ही, हम न केवल बाज़ार में उपलब्ध तकनीकों का उपयोग करते हैं, बल्कि अपनी कुछ तकनीकें भी विकसित करते हैं। उदाहरण के लिए, हम सिस्टम को एक-दूसरे के साथ एकीकृत करने के लिए सेवाएं बनाते हैं, यानी मेट्रिक्स एकत्र करने के लिए किसी प्रकार की एपीआई। साथ ही हम अपने स्वयं के मॉनिटरिंग सिस्टम पर काम कर रहे हैं - बिजनेस मेट्रिक्स के स्तर पर हम यूआई परीक्षणों का उपयोग करते हैं। और टीमों को सूचित करने के लिए टेलीग्राम में एक बॉट भी।

हम निगरानी प्रणाली को टीमों के लिए सुलभ बनाने का भी प्रयास कर रहे हैं ताकि वे अपने मेट्रिक्स को स्वतंत्र रूप से स्टोर कर सकें और उनके साथ काम कर सकें, जिसमें कुछ संकीर्ण मेट्रिक्स के लिए अलर्ट सेट करना भी शामिल है जो व्यापक रूप से उपयोग नहीं किए जाते हैं। 

पूरे सिस्टम में, हम यथाशीघ्र घटनाओं की सक्रियता और स्थानीयकरण के लिए प्रयास करते हैं। इसके अलावा, हमारे माइक्रोसर्विसेज और सिस्टम की संख्या में हाल ही में काफी वृद्धि हुई है, और तदनुसार एकीकरण की संख्या भी बढ़ी है। और एकीकरण स्तर पर घटनाओं के निदान की प्रक्रिया को अनुकूलित करने के हिस्से के रूप में, हम एक ऐसी प्रणाली विकसित कर रहे हैं जो आपको क्रॉस-सिस्टम जांच करने और परिणाम प्रदर्शित करने की अनुमति देती है, जो आपको आयात और सिस्टम के इंटरैक्शन से जुड़ी मुख्य समस्याओं का पता लगाने की अनुमति देती है। एक दूसरे। 

बेशक, ऑपरेटिंग सिस्टम के मामले में हमारे पास अभी भी बढ़ने और विकसित होने की गुंजाइश है और हम इस पर सक्रिय रूप से काम कर रहे हैं। आप हमारी निगरानी प्रणाली के बारे में अधिक पढ़ सकते हैं यहां. 

तकनीकी परीक्षण 

ओरलोव सर्गेई, वेब और मोबाइल विकास के लिए सक्षमता केंद्र के प्रमुख हैं

जब से भौतिक स्टोर बंद होने शुरू हुए हैं, हमें विकास के नजरिए से विभिन्न चुनौतियों का सामना करना पड़ा है। सबसे पहले, जैसे लोड बढ़ता है। यह स्पष्ट है कि यदि उचित उपाय नहीं किए जाते हैं, तो जब सिस्टम पर एक उच्च भार लागू किया जाता है, तो यह एक दुखद धमाके के साथ कद्दू में बदल सकता है, या प्रदर्शन में पूरी तरह से गिरावट कर सकता है, या यहां तक ​​​​कि अपनी कार्यक्षमता भी खो सकता है।

दूसरा पहलू, थोड़ा कम स्पष्ट, यह है कि उच्च लोड के तहत सिस्टम को व्यावसायिक प्रक्रियाओं में बदलावों के अनुरूप बहुत तेज़ी से बदलना पड़ता है। कभी-कभी दिन में कई बार. कई कंपनियों का नियम है कि अगर मार्केटिंग एक्टिविटी बहुत ज्यादा है तो सिस्टम में कोई बदलाव करने की जरूरत नहीं है। बिल्कुल भी नहीं, जब तक यह काम करता है तब तक इसे काम करने दें।

और हमारे पास अनिवार्य रूप से एक अंतहीन ब्लैक फ्राइडे था, जिसके दौरान सिस्टम को बदलना आवश्यक था। और सिस्टम में कोई भी त्रुटि, समस्या या विफलता व्यवसाय के लिए बहुत महंगी होगी।

आगे देखते हुए, मैं कहूंगा कि हम इन परीक्षणों का सामना करने में कामयाब रहे, सभी प्रणालियों ने भार का सामना किया, आसानी से स्केल किया गया, और हमें किसी भी वैश्विक तकनीकी विफलता का अनुभव नहीं हुआ।

ऐसे चार स्तंभ हैं जिन पर सिस्टम की उच्च वृद्धि भार झेलने की क्षमता टिकी हुई है। उनमें से पहला है निगरानी, ​​जिसके बारे में आपने अभी ऊपर पढ़ा है। अंतर्निहित निगरानी प्रणाली के बिना, सिस्टम की बाधाओं का पता लगाना लगभग असंभव है। एक अच्छी निगरानी प्रणाली घर के कपड़ों की तरह है; यह आरामदायक और आपके अनुरूप होनी चाहिए।

दूसरा पहलू है परीक्षण. हम इस बिंदु को बहुत गंभीरता से लेते हैं: हम प्रत्येक सिस्टम के लिए क्लासिक इकाइयां, एकीकरण परीक्षण, लोड परीक्षण और कई अन्य लिखते हैं। हम एक परीक्षण रणनीति भी लिख रहे हैं, और साथ ही परीक्षण के स्तर को उस बिंदु तक बढ़ाने का प्रयास कर रहे हैं कि हमें अब मैन्युअल जांच की आवश्यकता नहीं है।

तीसरा स्तंभ सीआई/सीडी पाइपलाइन है। किसी एप्लिकेशन के निर्माण, परीक्षण और तैनाती की प्रक्रियाओं को यथासंभव स्वचालित किया जाना चाहिए; कोई मैन्युअल हस्तक्षेप नहीं होना चाहिए। सीआई/सीडी पाइपलाइन का विषय काफी गहरा है, और मैं इस पर केवल संक्षेप में बात करूंगा। यह केवल उल्लेख करने योग्य है कि हमारे पास एक सीआई/सीडी पाइपलाइन चेकलिस्ट है, जिसे प्रत्येक उत्पाद टीम योग्यता केंद्रों की सहायता से पूरा करती है।

और यहाँ चेकलिस्ट है

इस तरह कई लक्ष्य हासिल किये जाते हैं. यह रिलीज ट्रेन से बचने के लिए एपीआई वर्जनिंग और फीचर टॉगल है, और विभिन्न परीक्षणों के कवरेज को ऐसे स्तर पर प्राप्त करना है कि परीक्षण पूरी तरह से स्वचालित हो, तैनाती निर्बाध हो, इत्यादि।

चौथा स्तंभ वास्तुशिल्प सिद्धांत और तकनीकी समाधान है। हम लंबे समय तक वास्तुकला के बारे में बहुत सारी बातें कर सकते हैं, लेकिन मैं कुछ सिद्धांतों पर जोर देना चाहता हूं जिन पर मैं ध्यान केंद्रित करना चाहूंगा।

सबसे पहले, आपको विशिष्ट कार्यों के लिए विशेष उपकरण चुनने की आवश्यकता है। हां, यह स्पष्ट लगता है, और यह स्पष्ट है कि कीलों को हथौड़े से ठोका जाना चाहिए, और कलाई घड़ियों को विशेष स्क्रूड्राइवर्स से अलग किया जाना चाहिए। लेकिन हमारे युग में, कई उपकरण उपयोगकर्ताओं के अधिकतम वर्ग को कवर करने के लिए सार्वभौमिकरण का प्रयास करते हैं: डेटाबेस, कैश, फ्रेमवर्क और बाकी। उदाहरण के लिए, यदि आप MongoDB डेटाबेस लेते हैं, तो यह मल्टी-डॉक्यूमेंट लेनदेन के साथ काम करता है, और Oracle डेटाबेस json के साथ काम करता है। और ऐसा प्रतीत होगा कि हर चीज़ का उपयोग हर चीज़ के लिए किया जा सकता है। लेकिन अगर हम उत्पादकता के पक्ष में हैं, तो हमें प्रत्येक उपकरण की ताकत और कमजोरियों को स्पष्ट रूप से समझना होगा और अपने वर्ग के कार्यों के लिए उन उपकरणों का उपयोग करना होगा जिनकी हमें आवश्यकता है। 

दूसरे, सिस्टम डिजाइन करते समय, जटिलता में प्रत्येक वृद्धि को उचित ठहराया जाना चाहिए। हमें इसे लगातार ध्यान में रखना चाहिए; कम युग्मन का सिद्धांत सभी को पता है। मेरा मानना ​​है कि इसे एक विशिष्ट सेवा के स्तर पर, और संपूर्ण प्रणाली के स्तर पर, और वास्तुशिल्प परिदृश्य के स्तर पर लागू किया जाना चाहिए। लोड पथ के साथ प्रत्येक सिस्टम घटक को क्षैतिज रूप से स्केल करने की क्षमता भी महत्वपूर्ण है। यदि आपके पास यह क्षमता है, तो स्केलिंग मुश्किल नहीं होगी।

तकनीकी समाधानों की बात करते हुए, हमने उत्पाद टीमों से सिफारिशों, विचारों और समाधानों का एक नया सेट तैयार करने के लिए कहा, जिसे उन्होंने कार्यभार की अगली लहर की तैयारी में लागू किया।

केशीओ

स्थानीय और वितरित कैश की पसंद पर सचेत रूप से विचार करना आवश्यक है। कभी-कभी एक ही सिस्टम के भीतर दोनों का उपयोग करना समझ में आता है। उदाहरण के लिए, हमारे पास ऐसे सिस्टम हैं जिनमें कुछ डेटा अनिवार्य रूप से एक शोकेस कैश है, यानी अपडेट का स्रोत सिस्टम के पीछे ही स्थित है, और सिस्टम नहीं बदलता है यह डेटा. इस दृष्टिकोण के लिए हम स्थानीय कैफीन कैश का उपयोग करते हैं। 

और डेटा है कि सिस्टम ऑपरेशन के दौरान सक्रिय रूप से बदलता है, और यहां हम पहले से ही हेज़लकास्ट के साथ एक वितरित कैश का उपयोग कर रहे हैं। यह दृष्टिकोण हमें वितरित कैश के लाभों का उपयोग करने की अनुमति देता है जहां उनकी वास्तव में आवश्यकता होती है, और हेज़ेलकास्ट क्लस्टर डेटा को प्रसारित करने की सेवा लागत को कम करने की अनुमति देता है जहां हम इसके बिना कर सकते हैं। हमने कैश के बारे में बहुत कुछ लिखा है। यहां и यहां.

इसके अलावा, हेज़लकास्ट में सीरियलाइज़र को क्रियो में बदलने से हमें अच्छा बढ़ावा मिला। और हेज़लकास्ट में रेप्लिकेटेड मैप से आईमैप + नियर कैश में संक्रमण ने हमें क्लस्टर में डेटा की आवाजाही को कम करने की अनुमति दी। 

एक छोटी सी सलाह: बड़े पैमाने पर कैश अमान्य होने की स्थिति में, दूसरे कैश को गर्म करने और फिर उस पर स्विच करने की रणनीति कभी-कभी लागू होती है। ऐसा प्रतीत होता है कि इस दृष्टिकोण से हमें दोगुनी मेमोरी खपत मिलनी चाहिए, लेकिन व्यवहार में, उन प्रणालियों में जहां इसका अभ्यास किया गया था, मेमोरी खपत कम हो गई।

प्रतिक्रियाशील ढेर

हम काफी बड़ी संख्या में प्रणालियों में प्रतिक्रियाशील स्टैक का उपयोग करते हैं। हमारे मामले में, यह वेबफ्लक्स या कोरटाइन के साथ कोटलिन है। प्रतिक्रियाशील स्टैक विशेष रूप से अच्छा है जहां हम धीमी इनपुट-आउटपुट संचालन की उम्मीद करते हैं। उदाहरण के लिए, धीमी सेवाओं के लिए कॉल, फ़ाइल सिस्टम या स्टोरेज सिस्टम के साथ काम करना।

सबसे महत्वपूर्ण सिद्धांत कॉल को ब्लॉक करने से बचना है। रिएक्टिव फ्रेमवर्क में हुड के नीचे कम संख्या में लाइव सर्विस थ्रेड चल रहे हैं। यदि हम लापरवाही से खुद को सीधे ब्लॉकिंग कॉल करने की अनुमति देते हैं, जैसे कि जेडीबीसी ड्राइवर कॉल, तो सिस्टम बस रुक जाएगा। 

त्रुटियों को अपने स्वयं के रनटाइम अपवाद में बदलने का प्रयास करें। प्रोग्राम निष्पादन का वास्तविक प्रवाह प्रतिक्रियाशील ढाँचे में बदल जाता है, और कोड निष्पादन अरेखीय हो जाता है। परिणामस्वरूप, स्टैक ट्रेस का उपयोग करके समस्याओं का निदान करना बहुत मुश्किल है। और यहां समाधान प्रत्येक त्रुटि के लिए स्पष्ट, वस्तुनिष्ठ रनटाइम अपवाद बनाना होगा।

Elasticsearch

Elasticsearch का उपयोग करते समय, अप्रयुक्त डेटा का चयन न करें। सिद्धांत रूप में, यह भी बहुत सरल सलाह है, लेकिन अक्सर यही बात भुला दी जाती है। यदि आपको एक समय में 10 हजार से अधिक रिकॉर्ड चुनने की आवश्यकता है, तो आपको स्क्रॉल का उपयोग करना होगा। सादृश्य का उपयोग करने के लिए, यह रिलेशनल डेटाबेस में एक कर्सर जैसा है। 

जब तक आवश्यक न हो पोस्टफ़िल्टर का उपयोग न करें। मुख्य नमूने में बड़े डेटा के साथ, यह ऑपरेशन डेटाबेस को बहुत अधिक लोड करता है। 

जहां लागू हो, वहां थोक संचालन का उपयोग करें।

API

एपीआई डिज़ाइन करते समय, प्रेषित डेटा को न्यूनतम करने की आवश्यकताएं शामिल करें। यह विशेष रूप से सामने वाले के संबंध में सच है: यह इस जंक्शन पर है कि हम अपने डेटा केंद्रों के चैनलों से परे जाते हैं और पहले से ही हमें क्लाइंट से जोड़ने वाले चैनल पर काम कर रहे हैं। यदि इसमें थोड़ी सी भी समस्या है, तो बहुत अधिक ट्रैफ़िक नकारात्मक उपयोगकर्ता अनुभव का कारण बनता है।

और अंत में, ढेर सारा डेटा बाहर न फेंकें, उपभोक्ताओं और आपूर्तिकर्ताओं के बीच अनुबंध के बारे में स्पष्ट रहें।

संगठनात्मक परिवर्तन

एरोशकिना ऐलेना, आईटी के उप निदेशक

उस समय जब संगरोध हुआ, और ऑनलाइन विकास की गति को तेजी से बढ़ाने और ओमनीचैनल सेवाओं को शुरू करने की आवश्यकता पैदा हुई, हम पहले से ही संगठनात्मक परिवर्तन की प्रक्रिया में थे। 

हमारी संरचना का एक हिस्सा उत्पाद दृष्टिकोण के सिद्धांतों और प्रथाओं के अनुसार काम में स्थानांतरित किया गया था। टीमों का गठन किया गया है जो अब प्रत्येक उत्पाद के संचालन और विकास के लिए जिम्मेदार हैं। ऐसी टीमों में कर्मचारी 100% शामिल होते हैं और स्क्रम या कानबन का उपयोग करके अपने काम की संरचना करते हैं, जो इस पर निर्भर करता है कि उनके लिए क्या बेहतर है, एक तैनाती पाइपलाइन स्थापित करना, तकनीकी प्रथाओं को लागू करना, गुणवत्ता आश्वासन प्रथाओं और बहुत कुछ।

सौभाग्य से, हमारी अधिकांश उत्पाद टीमें ऑनलाइन और ओमनीचैनल सेवाओं के क्षेत्र में थीं। इसने हमें कम से कम संभव समय में (गंभीरता से, शाब्दिक रूप से दो दिनों में) बिना दक्षता खोए दूरस्थ कार्य मोड पर स्विच करने की अनुमति दी। अनुकूलित प्रक्रिया ने हमें नई कामकाजी परिस्थितियों को जल्दी से अनुकूलित करने और नई कार्यक्षमता प्रदान करने की काफी उच्च गति बनाए रखने की अनुमति दी।

इसके अलावा, हमें उन टीमों को मजबूत करने की जरूरत है जो ऑनलाइन कारोबार में अग्रणी हैं। उस क्षण यह स्पष्ट हो गया कि हम केवल आंतरिक संसाधनों का उपयोग करके ही ऐसा कर सकते हैं। और दो सप्ताह में लगभग 50 लोगों ने उस क्षेत्र को बदल दिया जहां वे पहले काम करते थे और एक ऐसे उत्पाद पर काम करने में शामिल हो गए जो उनके लिए नया था। 

इसके लिए किसी विशेष प्रबंधन प्रयास की आवश्यकता नहीं थी, क्योंकि अपनी स्वयं की प्रक्रिया को व्यवस्थित करने, उत्पाद के तकनीकी सुधार और गुणवत्ता आश्वासन प्रथाओं के साथ-साथ, हम अपनी टीमों को स्व-संगठित होना सिखाते हैं - प्रशासनिक संसाधनों को शामिल किए बिना अपनी स्वयं की उत्पादन प्रक्रिया का प्रबंधन करना।

हम अपने प्रबंधन संसाधनों को ठीक वहीं केंद्रित करने में सक्षम थे जहां उस समय इसकी आवश्यकता थी - व्यवसाय के साथ समन्वय पर: अभी हमारे ग्राहक के लिए क्या महत्वपूर्ण है, पहले कौन सी कार्यक्षमता लागू की जानी चाहिए, हमारी थ्रूपुट क्षमता बढ़ाने के लिए क्या करने की आवश्यकता है ऑर्डर वितरित करने और संसाधित करने के लिए। यह सब और एक स्पष्ट रोल मॉडल ने इस अवधि के दौरान हमारे उत्पादन मूल्य धाराओं को उस चीज़ से लोड करना संभव बना दिया जो वास्तव में महत्वपूर्ण और आवश्यक है। 

यह स्पष्ट है कि दूरस्थ कार्य और परिवर्तन की उच्च गति के साथ, जब व्यावसायिक संकेतक हर किसी की भागीदारी पर निर्भर करते हैं, तो आप केवल श्रृंखला की आंतरिक भावनाओं पर भरोसा नहीं कर सकते "क्या हमारे साथ सब कुछ ठीक चल रहा है?" हाँ, यह अच्छा लगता है।" उत्पादन प्रक्रिया के वस्तुनिष्ठ मेट्रिक्स की आवश्यकता है। हमारे पास ये हैं, ये उत्पाद टीमों के मेट्रिक्स में रुचि रखने वाले किसी भी व्यक्ति के लिए उपलब्ध हैं। सबसे पहले, स्वयं टीम, व्यवसाय, उपठेकेदार और प्रबंधन।

हर दो सप्ताह में एक बार, प्रत्येक टीम के साथ एक स्थिति आयोजित की जाती है, जहां 10 मिनट के लिए मैट्रिक्स का विश्लेषण किया जाता है, उत्पादन प्रक्रिया में बाधाओं की पहचान की जाती है, और एक संयुक्त समाधान विकसित किया जाता है: इन बाधाओं को खत्म करने के लिए क्या किया जा सकता है। यदि कोई पहचानी गई समस्या टीमों के प्रभाव क्षेत्र से बाहर है, या सहकर्मियों की विशेषज्ञता से बाहर है, जो पहले से ही इसी तरह की समस्या का सामना कर चुके हैं, तो यहां आप तुरंत प्रबंधन से मदद मांग सकते हैं।

हालाँकि, हम समझते हैं कि कई गुना तेजी लाने के लिए (और यही वह लक्ष्य है जो हमने अपने लिए निर्धारित किया है), हमें अभी भी बहुत कुछ सीखने और इसे अपने दैनिक कार्य में लागू करने की आवश्यकता है। अभी हम अन्य टीमों और नए उत्पादों के लिए अपने उत्पाद दृष्टिकोण को बढ़ाना जारी रख रहे हैं। ऐसा करने के लिए, हमें अपने लिए एक नए प्रारूप में महारत हासिल करनी थी - पद्धतिविदों का एक ऑनलाइन स्कूल।

मेथडोलॉजिस्ट, वे लोग जो टीमों को एक प्रक्रिया बनाने, संचार स्थापित करने और कार्य कुशलता में सुधार करने में मदद करते हैं, अनिवार्य रूप से परिवर्तन के एजेंट हैं। अभी, हमारे पहले समूह के स्नातक टीमों के साथ काम कर रहे हैं और उन्हें सफल होने में मदद कर रहे हैं। 

मुझे लगता है कि वर्तमान स्थिति हमारे लिए ऐसे अवसर और संभावनाएं खोलती है जिनके बारे में शायद हम स्वयं अभी तक पूरी तरह से जागरूक नहीं हैं। लेकिन अभी हम जो अनुभव और अभ्यास प्राप्त कर रहे हैं, वह पुष्टि करता है कि हमने विकास का सही रास्ता चुना है, हम भविष्य में इन नए अवसरों को नहीं चूकेंगे और स्पोर्टमास्टर के सामने आने वाली चुनौतियों का प्रभावी ढंग से जवाब देने में सक्षम होंगे।

निष्कर्ष

इस कठिन समय के दौरान, हमने मुख्य सिद्धांत तैयार किए हैं जिन पर सॉफ्टवेयर विकास निर्भर करता है, जो, मुझे लगता है, इससे निपटने वाली प्रत्येक कंपनी के लिए प्रासंगिक होंगे।

लोग. इसी पर सब कुछ टिका है. कर्मचारियों को अपने काम का आनंद लेना चाहिए और कंपनी के लक्ष्यों और जिन उत्पादों पर वे काम करते हैं उनके लक्ष्यों को समझना चाहिए। और, निःसंदेह, वे पेशेवर रूप से विकसित हो सकते हैं। 

Технология. कंपनी के लिए यह आवश्यक है कि वह अपने प्रौद्योगिकी स्टैक के साथ काम करने के लिए एक परिपक्व दृष्टिकोण अपनाए और जहां इसकी वास्तव में आवश्यकता हो वहां दक्षताएं बनाए। यह बहुत सरल और स्पष्ट लगता है. और अक्सर नजरअंदाज कर दिया जाता है.

Процессы. उत्पाद टीमों और सक्षमता केंद्रों के काम को ठीक से व्यवस्थित करना, व्यवसाय के साथ एक भागीदार के रूप में काम करने के लिए बातचीत स्थापित करना महत्वपूर्ण है।

सामान्य तौर पर, हम इसी तरह जीवित बचे रहे। हमारे समय की मुख्य थीसिस की एक बार फिर पुष्टि हुई, माथे पर एक जोरदार क्लिक के साथ

भले ही आप एक विशाल ऑफ़लाइन व्यवसाय हैं, जिसमें कई स्टोर और कई शहर हैं, जहां आप काम करते हैं, अपना ऑनलाइन व्यवसाय विकसित करें। यह केवल एक अतिरिक्त बिक्री चैनल या एक सुंदर एप्लिकेशन नहीं है जिसके माध्यम से आप कुछ खरीद भी सकते हैं (और इसलिए भी कि प्रतिस्पर्धियों के पास भी सुंदर हैं)। तूफान से निपटने में आपकी मदद करने के लिए यह कोई अतिरिक्त टायर नहीं है।

यह एक परम आवश्यकता है. जिसके लिए न सिर्फ आपकी तकनीकी क्षमताएं और इंफ्रास्ट्रक्चर तैयार होना चाहिए, बल्कि आपके लोग और प्रक्रियाएं भी तैयार होनी चाहिए। आख़िरकार, आप कुछ ही घंटों में जल्दी से अतिरिक्त मेमोरी, स्थान खरीद सकते हैं, नए इंस्टेंस तैनात कर सकते हैं, आदि। लेकिन लोगों और प्रक्रियाओं को इसके लिए पहले से तैयार रहना होगा।

स्रोत: www.habr.com