मुंच जैसा हो, या तकनीकी ड्यूटी के बारे में कुछ शब्द

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



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

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

पृष्ठभूमि

डोडो पिज्जा एक साइबर कंपनी है जो पिज्जा बेचती है । हमारा व्यवसाय डोडो आईएस प्लेटफॉर्म पर आधारित है, जो सभी व्यापारिक प्रक्रियाओं का प्रबंधन करता है: आदेश प्राप्त करना, पिज्जा बनाना, इन्वेंट्री का प्रबंधन करना, लोगों को प्रबंधित करना (प्रबंधन) और बहुत कुछ। केवल 8 वर्षों में, हम 12 देशों में 498 पिज़्ज़ेरिया की सेवा करने वाले 80+ डेवलपर्स के लिए एक पिज़्ज़ेरिया परोसने वाले 2 डेवलपर्स से बढ़े हैं।

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

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

शिट होता है

2018 में, मार्केटिंग टीम ने 100 मिलियन रूबल के बजट के साथ हमारा पहला संघीय टीवी विज्ञापन अभियान शुरू किया। यह डोडो पिज्जा के लिए एक शानदार कार्यक्रम था। अभियान के लिए आईटी टीम भी अच्छी तरह से तैयार थी। हमने अपनी तैनाती को स्वचालित और सरल बना दिया है - अब टीमसिटी में एक बटन के साथ हम 12 देशों में एक मोनोलिथ को तैनात कर सकते हैं। प्रदर्शन परीक्षणों का उपयोग करते हुए, हमने एक भेद्यता विश्लेषण किया। हमने अपना सर्वश्रेष्ठ प्रदर्शन किया, लेकिन वैसे भी खराब किया।

विज्ञापन अभियान अद्भुत था। हमें प्रति मिनट 100 से 300 ऑर्डर मिले। यह अच्छी खबर थी। बुरी खबर: डोडो आईएस इस तरह के भार का सामना नहीं कर सका और मर गया। हम वर्टिकल स्केलिंग की सीमा तक पहुँच गए और अब आदेशों की प्रक्रिया नहीं कर सकते थे। सिस्टम ने हर 3 घंटे में रिबूट किया। डाउनटाइम के प्रत्येक मिनट ने हमें हजारों रूबल की लागत दी, नाराज ग्राहकों से सम्मान की हानि की गिनती नहीं की।

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

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

गिरने और उठने की कहानी

प्रारंभिक अवस्था: अखंड वास्तुकला

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

सच्ची कहानी

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

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

2017 में शुरुआती दुर्घटना

14 फरवरी। 14 फरवरी को बधाई के प्रेमियों के लिए, हम दिल के आकार में एक विशेष पिज्जा - पेपरोनी बनाते हैं। मैं हमेशा 14 फरवरी, 2017 को याद रखूंगा, क्योंकि इस दिन, जब सभी पिज़्ज़ेरिया पूरे लोड पर काम कर रहे थे, डोडो आईएस गिरने लगा। प्रत्येक पिज़्ज़ेरिया में उत्पादन प्रबंधन के लिए 4-5 गोलियां होती हैं: पिज्जा निर्माता किस क्रम में आटा रोल करता है, सामग्री डालता है, दांव लगाता है या डिलीवरी के लिए भेजता है। उस समय, पिज़्ज़ेरिया की संख्या 150+ तक पहुंच गई थी, प्रत्येक टैबलेट को एक मिनट में कई बार अपडेट किया गया था। इन सभी प्रश्नों ने डेटाबेस पर इतना भारी भार बनाया कि वह झेलना बंद हो गया और असफल होने लगा। चोटी की बिक्री के दौरान डोडो आईएस की मौत हो गई। लेकिन आगे व्यस्त छुट्टियों का मौसम था: 23 फरवरी, 8 मार्च, 1 मई और 9। इन छुट्टियों के दौरान, हमें आदेशों में और भी अधिक वृद्धि की उम्मीद थी।

जिस दिन तुम मरोगे । हमारी विकास योजनाओं और भार सीमा को जानकर, जिसका हम सामना कर सकते हैं, हमने पाया कि हम कितने समय तक जीवित रह सकते हैं। आर्मगेडन की अनुमानित तारीख के बारे में छह महीने में उम्मीद की गई थी: अगस्त - सितंबर 2017 में। अपनी मृत्यु की तारीख को जानकर क्या जीना पसंद है?

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

एक साल बाद कुछ सुधार

वर्ष के दौरान, हम स्पष्ट रूप से बढ़े हैं:

• हमने 4-5 घंटे में तैनाती की प्रक्रिया को स्वचालित और त्वरित किया
• अंत में, हमने मोनोलिथ को देखना शुरू किया: ट्रैकर और टीवी बोर्ड अपने स्वयं के डेटाबेस के साथ एक अलग सेवा में चले गए
• हमने डिलीवरी के कैश डेस्क को अलग करना शुरू कर दिया - दूसरा घटक जिसने एक उच्च भार बनाया
• उपयोगकर्ता और डिवाइस प्रमाणीकरण प्रणाली को फिर से लिखना

ऐसा लगता है कि हम खुद पर गर्व कर सकते हैं। लेकिन हमारे सामने एक बड़ी निराशा थी।

संघीय विज्ञापन अभियान के दौरान विफलता। आत्मविश्वास का दूसरा संकट

तकनीकी ऋण जमा करना आसान है, लेकिन चुकाने में बहुत मुश्किल है। यह संभावना नहीं है कि आप पहले से समझ पाएंगे कि यह आपको कितना खर्च करेगा।

इस तथ्य के बावजूद कि हम पूरे साल एक तकनीकी बैकलॉग से जूझते रहे, हम एक बड़े पैमाने पर विपणन अभियान के लिए तैयार नहीं थे और फिर से अपने व्यवसाय के सामने खराब हो गए। जिस भरोसे को हमने बूंद-बूंद करके कमाया वह गायब हो गया।

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



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

सबक सीखा

पूर्वव्यापी के बाद, हमने अपनी प्रक्रियाओं को पूरी तरह से पुनर्गठित किया। हमने एक आधार के रूप में LeSS लिया और इसे इंजीनियरिंग प्रथाओं के साथ पूरक किया। अगले कुछ महीनों में, हमने इंजीनियरिंग प्रथाओं को शुरू करने में एक सफलता हासिल की। LeSS के आधार पर, हमने लागू किया है और इसका उपयोग जारी है:

• एकल उत्पाद बैकलॉग
• पूरी तरह से क्रॉस कार्यात्मक और क्रॉस घटक कमांड
• जोड़ी और भीड़ प्रोग्रामिंग
• सच निरंतर एकीकरण (CI) - एक शाखा में 12 टीमों के साथ कोड का एकीकरण
• शाखाओं के साथ सरलीकृत कार्य (ट्रंक-आधारित विकास)
• बार-बार रिलीज: माइक्रोसर्विस के लिए निरंतर तैनाती, मोनोलिथ के लिए दैनिक रिलीज
• एक अलग क्यूए टीम के इनकार, क्यूए विशेषज्ञ विकास टीम का हिस्सा हैं

6 प्रथाएँ जिन्हें हमने संकट के बाद चुना:

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

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

2. आंतरिक हैकाथॉन। हमने 500 त्रुटियां हैकथॉन को अंजाम दिया। सभी टीमों ने एक साथ लॉग को मंजूरी दी और साइट पर और एपीआई में 500 त्रुटियों के कारणों को हटा दिया। लक्ष्य था लॉग को साफ रखना। जब लॉग साफ होते हैं, तो नई त्रुटियां स्पष्ट रूप से दिखाई देती हैं, आप आसानी से अलर्ट के लिए थ्रेसहोल्ड सेट कर सकते हैं।

हैकथॉन का एक और उदाहरण बग्स है। पहले, हमारे पास बग्स का पूरा बैकलॉग था, उनमें से कुछ कई वर्षों से वहाँ लटके हुए थे। वे कभी खत्म होते नहीं दिख रहे थे। और हर दिन नए दिखाई दिए। हमने बग और सामान्य बैकलॉग तत्वों पर काम किया।


3. परियोजना टीमों से एक स्थिर टीम के लिए। प्रोजेक्ट टीमों के साथ एक मजेदार कहानी थी। संकट के दौरान, हमने ऐसे लोगों की विशेषज्ञ टीमों का गठन किया जो इस कार्य के लिए सबसे योग्य थे। संकट समाप्त होने के बाद, टीमों ने इस अभ्यास को जारी रखने का फैसला किया। इस तथ्य के बावजूद कि मुझे यह विचार बिल्कुल पसंद नहीं आया, हमने कोशिश की। केवल 2 सप्ताह (एक स्प्रिंट) में, अगले रेट्रोस्पेक्टिव में, टीमों ने इस अभ्यास को छोड़ दिया (इस फैसले ने मुझे खुश कर दिया)। यदि किसी टीम में कुछ कौशल का अभाव है, तो वे धीरे-धीरे सीख सकते हैं। लेकिन टीम भावना, समर्थन और आपसी सहायता को पूरा करने में बहुत लंबा समय लगता है, इसमें महीनों लगते हैं। लघु अवधि की परियोजना टीमें लगातार गठन और तूफान के चरण में हैं। आप इसे कई हफ्तों तक सहन कर सकते हैं, लेकिन आप हर समय इस तरह से काम नहीं कर पाएंगे।

4. कोई मैनुअल प्रतिगमन। हमने मैन्युअल प्रतिगमन से छुटकारा पाने के लिए एक लक्ष्य निर्धारित किया है। इस तक पहुंचने में हमें 1.5 साल लगे। लेकिन एक दीर्घकालिक महत्वाकांक्षी लक्ष्य होने से आप लक्ष्य के लिए अग्रणी कदमों के बारे में सोचते हैं।


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

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



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

परिणाम

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

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

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

व्यावसायिक परिणाम

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

टीमों के लिए परिणाम

आज हम इंजीनियरिंग विधियों की एक विस्तृत श्रृंखला का उपयोग करते हैं:

1. पूरी तरह से क्रॉस कार्यात्मक और क्रॉस घटक कमांड
2. जोड़ी / मोब प्रोग्रामिंग
3. निरंतर एकीकरण - एक शाखा में 12 आदेशों का निरंतर एकीकरण
4. एक टीम के रूप में विषय विशेषज्ञ
5. कोई अलग क्यूए टीम नहीं है, क्यूए विशेषज्ञ विकास टीमों का हिस्सा हैं
6. ऑटोटेस्ट के साथ मैनुअल रिग्रेशन को बदलना
7. कोई बग नीति नहीं (#Zerobugspolicy)
8. तैनाती में तेजी लाने के लिए एक चालक के रूप में लाइन को रोकें

हमने क्या सीखा है

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

1. इंजीनियरिंग प्रथाओं व्यवसाय को संकट से बचाती है
2. तकनीकी ऋण जमा न करें। यह बहुत देर हो सकती है और बहुत अधिक खर्च हो सकती है
3. क्रांतिकारी परिवर्तन क्रांतिकारी से कई गुना अधिक समय लेते हैं
4. एक संकट हमेशा एक बुरी चीज नहीं होती है। प्रक्रियाओं में क्रांति लाने के लिए संकट का उपयोग करें
5. हालांकि, पहले से लंबी विकासवादी प्रशिक्षण की आवश्यकता है।
6. आँख बंद करके उन सभी तरीकों को लागू न करें जो आपको पसंद हैं। कुछ तरीके पंखों में इंतजार कर रहे हैं, और जब वह आएगा, तो टीमें बिना प्रतिरोध के उनका उपयोग करेंगी। सही क्षण की प्रतीक्षा करें
7. समय के साथ, टीम खुद महत्वपूर्ण निर्णय लेने और उन्हें लागू करने के लिए शुरू होती है। उन्हें प्रयास करने के लिए एक सक्षम वातावरण दें, उन्हें असफल होने दें और गलतियों से सीखें

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

---

धन्यवाद

, LeSS. .

. .

, Product Owner', -.

.

, Scrum-, . .

, : , . , . , .