जैसे ही आप अपनी तकनीक से डरने लगेंगे, डर के नए कारण जल्द ही दिखाई देंगे।

भय पाश इस तरह से कसता है:

1. मामूली सम्पादनों से अप्रत्याशित, भयावह या महंगा परिणाम होता है।
2. हमें बदलाव का डर सताने लगा है।
3. हम सभी संपादनों को यथासंभव छोटा और स्थानीय बनाने का प्रयास करते हैं।
4. कोड आधार पैच, अपवादों और विशेष मामलों से भरा है।
5. भय तीव्र होता है।

भय तब शुरू होता है जब एक हानिरहित संपादित अप्रत्याशित रूप से एक समस्या का कारण बनता है। उत्पादन में डाउनटाइम या बस एक कष्टप्रद बग। एक गलती प्रबंधन का ध्यान आकर्षित कर सकती है। कोड में आपके दोष के बारे में निर्देशकों की बैठक की तरह कुछ भी नहीं प्रेरित करता है!

इस तरह की परेशानी थी, क्योंकि डेवलपर परिवर्तन के सभी परिणामों की भविष्यवाणी नहीं कर सकता था। शायद परीक्षण सूट अपर्याप्त था। या एक विशेष मामला सामने आया है जो केवल उत्पादन में देखा गया है। (उदाहरण के लिए, एक एकल ग्राहक जिसकी डेटा सेटिंग सभी से भिन्न होती हैं)। जो भी विशिष्ट कारण है, परिणाम है: "मुझे नहीं पता था कि ऐसा होगा।"

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

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

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

टिपिंग बिंदु

यह तीन तरीकों से समाप्त हो सकता है:

1. आदर्श वाक्य के तहत कार्डिनल कोड रीफैक्टरिंग (आमतौर पर एक अलग टीम के साथ) "अब हम इसे सही करेंगे!" यह भी देखें: दूसरी प्रणाली के सिंड्रोम और "क्या कभी नहीं किया जा सकता है, भाग I" ।
2. बड़े पैमाने पर आउटसोर्सिंग।
3. प्रभावित परिसंपत्तियों को दूसरी कंपनी को बेचना।

लूप से कैसे बचें

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

ट्रिब्यूनल विफलता की सबसे खराब प्रतिक्रिया है।

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

कैसे एक पाश को तोड़ने के लिए

कई प्रबलित छोरों की तरह, भय का चक्र अविश्वसनीय रूप से तोड़ना मुश्किल है। अब तक, मैंने इससे सफल निकास का एक भी मामला नहीं देखा है। यदि यह आपकी कंपनी में शुरू हुआ, तो मुझे आपके अनुभव के बारे में सुनना अच्छा लगेगा!