डेवलपर्स के 5 डर जो हमने दूर किए हैं

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



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

1. सबकुछ छोड़ने का डर

परीक्षण बग के बिना किसी उत्पाद को जारी करने का एक निश्चित तरीका है। लेकिन कभी-कभी कोड की जांच के लिए कोई उपकरण नहीं होता है।

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

कुछ मामलों में, परीक्षण की उपेक्षा की जा सकती है, लेकिन हमारी नहीं। गलती महंगी है। आप केवल एक चर को इनिशियलाइज़ नहीं करते हैं, और आधे मामलों में ऑपरेटिंग सिस्टम इंस्टॉल होना बंद हो जाएगा। आप कोड की कुछ पंक्तियों में गलत हैं - और डेटा सेंटर "लेट" होगा। जैसा कि आप जानते हैं, कोई भी "गिर" डेटा सेंटर के लिए जिम्मेदार नहीं होना चाहता है, इसलिए यह डर मेरी टीम में सबसे पहले आता है (हालांकि यह कंपनी में परिवर्तनों से संबंधित नहीं है)।

सब कुछ छोड़ने के डर को कैसे दूर किया जाए

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

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

2. बिना परीक्षक के छोड़े जाने का डर

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

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

क्रॉस-परीक्षण का क्या लाभ है

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

3. दूसरी टीम में जाने का डर

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

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

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

संक्षेप में कि कार्यान्वयन कैसे हुआ

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

डेवलपर्स ने परिचय से दूसरी टीम को क्या लाभ दिया

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

4. टीम लीड के बिना मेंटर बनने / रहने का डर

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

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

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

1. समझाने में, अधिक संदर्भ दिए जाने की आवश्यकता है। सिर में सब कुछ सुंदर है, और जब आप इसे बताते हैं, तो यह बाहर फाड़ा और समझ से बाहर हो जाता है।
2. एक समीक्षा में केवल एक कोड को नहीं देखना चाहिए, बल्कि यह समझें कि इस कोड के साथ किसी व्यक्ति ने क्या हल करने की कोशिश की। फिर इसके तर्क को समझना और त्रुटियों को खोजना आसान है।
3. ज्ञान साझा करना सहायक है: विचारों को तैयार करना सीखना; अपने सिर में अलमारियों पर सब कुछ रखो; जब आप समझाते हैं, तो आप समस्या का सबसे अच्छा समाधान पाते हैं।

5. नई तकनीकों को न सीखने का डर

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

कई वर्षों के लिए, प्रौद्योगिकी बहुत आगे निकल गई है। हमने C ++ 11 में पुराने संस्करण को लिखा और मेक का उपयोग करते हुए, नए के लिए हमने C ++ 17, CMake, कॉनन और डॉकर को चुना। टीम को यह सब सीखने और आवेदन करने का तरीका सीखने की जरूरत है। आराम क्षेत्र से बाहर का रास्ता, चुनौती और सोचा "क्या होगा अगर मैं नहीं कर सकता और दूसरों से भी बदतर हो जाएगा", "क्या होगा यदि मेरे लिए और अधिक समस्याएं हैं, तो मैंने इसे समझ नहीं पाया और मुझे बाहर निकाल दिया।" हम अभी भी नई तकनीकों में महारत हासिल कर रहे हैं, और इस डर के खिलाफ लड़ाई अभी भी जारी है।

नई तकनीकों को तेजी से कैसे सीखें

1. पुराने और अनुभवी सहयोगियों से पूछने में संकोच न करें, बेवकूफ लगने से डरो मत।
2. दस्तावेज करने के लिए, नए लोगों के विसर्जन की प्रक्रिया को तेज करने के लिए और एक ही बात को 10 हजार बार बताने के लिए नहीं। ज्ञान का आधार बनाए रखें।
3. ठीक है Google हमेशा मदद के लिए मौजूद है। यदि यह काम नहीं करता है, तो बिंदु 1 देखें।

डर नहीं, बल्कि चुनौतियां हैं

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

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

क्यों डरते हो?

PS यदि आप DCImanager डेमो संस्करण को देखना चाहते हैं, तो bizdev@ispsystem.com पर संपर्क करें, इस विषय पर "मैं नया DCImanager देखना चाहता हूं"। जब यह तैयार हो जाएगा, तो हम आपको लिखेंगे। या यदि आपको सर्वर प्रबंधन के लिए एक उत्पाद की आवश्यकता है, लेकिन किसी कारण के लिए वर्तमान DCImanager फिट नहीं है और बाजार पर कोई उपयुक्त समाधान नहीं है, तो ऐसे सॉफ़्टवेयर के लिए अपनी इच्छाओं को लिखें, शायद हम विकास योजना में कुछ शामिल करेंगे।