सभी को नमस्कार! मेरा नाम अलेक्जेंडर अफेनोव है। मैं लमोडा ऑर्डर प्रोसेसिंग टीम का टीम लीडर हूं। पिछले साल मैंने TeamLead Conf 2018 में बात की थी। प्रदर्शन की रिकॉर्डिंग यहाँ उपलब्ध है ।

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

रिपोर्ट को 3 भागों में विभाजित किया जाएगा:

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

लमोडा एक आईटी कंपनी के रूप में

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

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

लैमोडा इन समस्याओं को निम्नलिखित तरीकों से हल कर सकता है:

अपनी डिलीवरी सेवा की सेवाएं प्रदान करें।

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

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

हम 2016 के बाद से सभी सम्मेलनों में घर में विकास के बारे में बात कर रहे हैं। हम स्वयं सभी प्रक्रियाओं को स्वचालित करते हैं। यह लगभग सौ अलग-अलग सेवाएं हैं: प्रसंस्करण आदेश और भुगतान से लेकर पते की वस्तुओं और उपहार प्रमाणपत्रों के साथ काम करना। इस सब के लिए समर्थन लगभग 300 लोगों की एक टीम है।

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

प्रमुख मुद्दे

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

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

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

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

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

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

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

निम्नलिखित प्रश्न जो मुझे रुचि देते हैं, एक दीर्घकालिक परिप्रेक्ष्य की चिंता करते हैं। उदाहरण के लिए, कैसे और कहाँ विकसित होना है?

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

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

प्रदर्शन की समीक्षा

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

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

संभावित परिणाम क्या हैं?

पहला विकल्प: एक व्यक्ति काम शुरू होने से पहले छह महीने में खराब करने में कामयाब रहा। अलविदा कहने का समय आ गया। यह बहुत कम ही होता है, लेकिन हम यथार्थवादी होंगे - ऐसा होता है।

एक अन्य विकल्प एक ड्यूस है। कुछ याद आ रहा है। गति, पूर्वानुभव, दृढ़ता हो सकती है। कुछ सुधार की जरूरत है।

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

चार - सहमत से अधिक किया। पदोन्नति / वेतन के लिए उम्मीदवार।

पाँच - ऊनी भेड़िया। ऐसा लगता है कि यह समय उठाने, बोनस देने आदि का है।

मैं खुद इस तरह की समीक्षा के कई पुनरावृत्तियों से गुजरा। पहले, यह हर तिमाही में आयोजित किया जाता था, जो बहुत सुविधाजनक नहीं था, क्योंकि 3 महीने तक खुद को साबित करने का अवसर हमेशा नहीं होता है। अब समीक्षा हर छह महीने में होती है।

इसलिए, सबसे पहले मैं सीनियर डेवलपर से सीनियर में बड़ा हुआ। तब मेरी टीम के नेता ने फैसला किया कि अब वह तकनीक के साथ अधिक काम करना चाहते हैं और तकनीकी टीम (वास्तुकार) की स्थिति में चले गए, और मैं एक टीम लीडर बन गया।

तो आगे क्या है? मुझे कुछ करने की जरूरत है, किसी तरह मास्टर करने के लिए।

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

एक अन्य बिंदु समान "बुनियादी नियम" है। मैं क्या कर सकता हूँ?

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

कैसे और कहाँ बढ़ें? यह प्रश्न गायब नहीं होता है, क्योंकि तब आप विभाग के प्रमुख (समूह लीड) बनना चाह सकते हैं।

खैर, सवाल - मुझे क्या उम्मीद है, यह भी मुझे काफी समझ में आता है।

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

एक टीम को क्या करना चाहिए?

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

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

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

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

कई लोग कहते हैं कि विकास के 10 वर्षों के बाद "प्रबंधन से विकास" का अनुपात लगभग 80 से 20 हो जाएगा। यह हमेशा प्राप्त करने योग्य नहीं है। नतीजतन, आप अनिवार्य रूप से विशेषज्ञता खो देंगे और वर्तमान रुझानों से बाहर हो जाएंगे। आगे भी बढ़ते रहना आवश्यक है।

आपकी स्थिति के संदर्भ में आप कैसे विकसित हो सकते हैं, इसके लिए संभावित रणनीतियाँ हैं। अगले भाग में, हम इस बारे में बात करेंगे कि एक टीम में रोल रोटेशन बस-फैक्टर को बढ़ाने में कैसे मदद करता है।

रोल रोटेशन

मैं उन लोगों को तारीख तक लाऊंगा जो नहीं जानते हैं और आपको बताते हैं कि बस कारक क्या है।

बस कारक एक संख्या है जो इंगित करता है कि यदि डेवलपर्स की एक निश्चित संख्या "एक बस दस्तक देती है", तो परियोजना पर काम बंद हो जाएगा। यह कई स्तरों पर खुद को प्रकट कर सकता है। उदाहरण के लिए, यह कुछ विशिष्ट जटिल प्रणाली तत्व के लिए एक बस कारक हो सकता है।

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

आगे क्या चर्चा की जाएगी बस कारक को बढ़ाने के लिए रणनीति है। और वे टीम लीडर के सभी पिछले कर्तव्यों के साथ एक, बल्कि सुखद तस्वीर के साथ आएंगे, जिसके बारे में मैंने बात की थी।

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

सहायक अभियंता

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

एक सहायक इंजीनियर कौन है?

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

थोड़ा विचलित: हम पुराने Zend 1 ढांचे पर डेढ़ सौ हजार लाइनों की एक प्रणाली के बारे में बात कर रहे हैं। पिछली टीम के वास्तुकार ने एक बार कहा था कि हमारी प्रणाली के अनुसार, हमारे पास इस आकार का ऋण है - यह एक तकनीकी ऋण नहीं है, बल्कि एक तकनीकी बंधक है। इसलिए रिपोर्ट का शीर्षक।

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

रिलीज इंजीनियर

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

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

वह (रिलीज़ इंजीनियर) आने वाली समस्याओं को रिकॉर्ड करता है। अगर कुछ ऊबा हुआ है, तो अपनी गलतियों से सीखना बहुत अच्छा होगा। ऐसा करने के लिए, वह रिलीज की तारीख और उन त्रुटियों को इंगित करता है जो समस्या का कारण बने। यह अगली रिलीज़ इंजीनियर को आम समस्याओं को देखने और उनसे बचने में सक्षम बनाता है। ठीक है, हाँ, वह लगातार एक सप्ताह से अधिक समय तक ऐसा नहीं करता है, क्योंकि एक रिलीज एकत्र करना महंगा है।

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

Tehlid

एक और अधिक दिलचस्प आभासी स्थिति तकनीकी नेता है।

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

निष्कर्ष

परिणामस्वरूप हमें क्या मिलता है?

एक टीम में लंबे समय तक (कम से कम छह महीने) भूमिकाओं का रोटेशन एक अनुभवहीन कनिष्ठ के लिए भी संभव बनाता है कि वह सिस्टम के विभिन्न भागों और प्रकार के कार्यों के साथ कौशल प्राप्त कर सके।

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

इस क्षण से, टीम लीडर को अपने कार्यों को अधीनस्थों को सौंपना चाहिए और, क्योंकि यदि आपको याद है, तो टीम लीडर के पास खुद को बाहर रखने और कहीं बढ़ने का काम नहीं है।

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

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

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

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

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

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

तकनीकी बंधक: क्या और किसके लिए टीम बकाया है