Timlid IT डिवीजन में एक सार्जेंट है

कभी-कभी ऐसा लगता है कि लवलीन कैरोल की कविता से डरपोक कोई है या स्नार्क जैसा कुछ है: यह निश्चित रूप से मौजूद है, बहुमुखी और विरोधाभासी है जिसे इसके रोजमर्रा और व्यावसायिक अभिव्यक्तियों में वर्णित किया गया है, लेकिन सभी के लिए यह एक रहस्य है। यह समझने के लिए कि इंजीनियरिंग टीमों में यह कितना महत्वपूर्ण है (टीम लीड नहीं, स्नार्क) की भूमिका कौन है, इस पर ध्यान देना बेहतर है और टीम लीड में कौन से नुकसान छिपे हैं, सेंट टीमलाइड कॉन्फ 2018 में मदद करने का वादा किया गया है, जो सेंट पीटर्सबर्ग में 24-25 सितंबर को आयोजित किया जाएगा। ।

इस कार्यक्रम से एक महीने पहले, हमने मोसोव प्रोजेक्ट के तकनीकी निदेशक रोमन इवलिएव के साथ बिना किसी औपचारिकता के बात की थी , जो सेंट टीमलीड कॉन्फ 2018 कार्यक्रम समिति के प्रमुख हैं। बातचीत में: टीम के नेता कौन हैं, उन्हें कैसे सही तरीके से तैयार करना है, किसके लिए और क्या तैयारी करनी चाहिए। उनकी जिम्मेदारियों का एक घेरा हो और बहुत कुछ।

सूचना

रोमन इविलिएव का जन्म 1982 में हुआ था। 2005 में, उन्होंने साइबर इंजीनियरिंग विभाग, मॉस्को इंजीनियरिंग भौतिकी संस्थान से स्नातक किया। आईटी में 15 साल से अधिक। विशेषज्ञता: उच्च कार्यभार, प्रौद्योगिकी टीमों में प्रबंधन, प्रशिक्षण।

काम के अंतिम स्थान:
• 2009-2013 में, पहले एक वरिष्ठ इंजीनियर, फिर कैस्पर्सकी लैब में एक परियोजना प्रबंधक (वे कॉर्पोरेट साइटों के समर्थन और विकास के लिए जिम्मेदार थे - दोनों बी 2 सी और बी 2 बी)।
• 2014-2016 में - सूचना प्रौद्योगिकी Banki.ru के निदेशक
• उन्होंने 2016 के अंत में मोसोव परियोजना में सीटीओ का स्थान लिया।

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

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

मॉस्को सिटी डिपार्टमेंट ऑफ इंफॉर्मेशन टेक्नोलॉजीज (डीआईटी) और अन्य संरचनाओं के प्रत्येक कोने में, जिनके साथ हमें बातचीत करनी है, खेल के अपने नियम और हमारी समस्याएं, किसी भी विशाल संगठन में, कम से कम एक ही सेर्बेट में। हमारा Mos.ru बाजार b2c- सेवाओं से बहुत अलग नहीं है - सिवाय इसके कि हम पैसा नहीं बनाते हैं।

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



- Mos.ru के मुखौटे के पीछे क्या है?

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

अभी भी हमारे जिम्मेदारी के क्षेत्र में डिजिटल-विशेष परियोजनाएं हैं। ताजा से - यह Zaryadye पार्क के लिए बनाया गया है।

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

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

- आपकी देखरेख में पोर्टल की तकनीकी सहायता में एक बड़ी टीम कितनी शामिल है?

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

- आपका तकनीकी प्रबंधन पदानुक्रम कैसे बनाया गया है? जिम्मेदारी के क्षेत्रों को कैसे विभाजित किया जाता है?

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

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

हमारे पास एक सेवा के रूप में DevOps भी हैं: कार्य निर्धारित किए जाते हैं, प्राथमिकता दी जाती है, और फिर devops के माध्यम से चलते हैं, जो कुछ टीमों के लिए कसकर तय नहीं हैं। इसी तरह, ऑपरेशन काम करता है।

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

इन दोनों टीमों ने DevOps, परीक्षण और संचालन के "मुख्य विकास" के साथ बातचीत की।

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

- तो यह शब्द लग गया। और ऐसा तिमलीद क्या करता है?

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

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

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

हाल तक, Banki.ru में और Mos.ru में, विशेष रूप से "बैक" मेरे साथियों से बाहर निकल गए थे। एक नियम के रूप में, एक वरिष्ठ बैक-एंड डेवलपर ने इस भूमिका को लिया। लेकिन इस समय मेरे पास पहले से ही दो टीम हैं, जो दृश्यपटल से आगे हैं।

सब कुछ बदल रहा है। हमें वर्तमान तकनीकी वास्तविकताओं के अनुकूल होना था, और इसके परिणामस्वरूप हमें वह मिला जिसे हम गिल्ड कहते हैं।

यहाँ यह बात है: 2018 में बैकेंड की दुनिया में क्या हो रहा है, और इसके विपरीत, इसका ध्यान रखना सामने वाले के लिए कठिन है। हमने महसूस किया कि लोगों को एक क्षैतिज स्तर पर सहयोग करने की आवश्यकता है, प्रत्यक्ष अधीनता के बिना अनौपचारिक संघों में शामिल हों, लेकिन स्थिति के साथ - गुप्त समाजों में रैंक की तरह, "बैक-एंड ऑर्डर के मास्टर" जैसा कुछ। ऐसे "शीर्षकों" के वाहक वे लोग होते हैं, जो वास्तव में एक लागू प्रकृति के प्रबंधकीय निर्णय लेते हैं: क्या हम PHP 7.2 में चले जाएंगे, क्या कोणीय विकास होगा, या रिएक्ट पर दांव लगाना बेहतर होगा।

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

अंततः, आर्किटेक्चर टीम मेरे सिस्टम आर्किटेक्ट को बदल देती है। हां, मेरे पास एक सिस्टम आर्किटेक्ट नहीं है।

- आपकी टीम में टीम का नेतृत्व किस स्थान पर होता है? क्या वह सीधे सीटीओ को रिपोर्ट करता है या मध्य स्तर के प्रबंधक हैं?

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

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

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

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

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

Banki.ru में, तकनीकी विभाग की संरचना भी "सेलुलर" थी: इसमें टीमों को टीम के नेताओं द्वारा नियंत्रित किया गया था, और अधिकांश समय उनमें से पांच के साथ मैंने विकास प्रबंधक की अनुपस्थिति में सीधे संपर्क किया था। जैसे अभी मोसवन में है।

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

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

- आपकी राय में, एक टीम लीडर पेशे या संगठन में स्थितिजन्य भूमिका है, जो स्कैम मास्टर के साथ सादृश्य द्वारा है?

- अब मेरे पास टीम में दोनों हैं। जब टीम के कार्य मूल रूप से समान होते हैं, तो यह एक बात है और लोग एक ही लय में चलते हैं। एक और तब है जब एक टीम एन समस्याओं को समानांतर में हल किया जाता है, जहां एन एक टीम में इंजीनियरों की संख्या को पार कर सकता है। दूसरे मामले में, टीम के नेता के पास एक प्राकृतिक प्रशासक के रूप में, यहां तक ​​कि अस्थायी रूप से मुड़ने का हर मौका है, जो इन कार्यों को "रूट" करेगा। मेरे लिए, यह एक भूमिका और एक पेशा दोनों है।

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

क्या डरपोक एक पेशे के रूप में मौजूद है, सवाल बैकफिल है। क्या टीम लीडर एक पेशा है? वास्तव में। केवल रॉकेट विज्ञान में एक है, और एक और प्रोग्रामिंग में, इसके प्रतिनिधि द्वारा किए गए कार्यों के दृष्टिकोण से और इसके द्वारा किए जाने वाले कार्यों की श्रेणी। कंपनी में, जहां पांच लोग विकास में हैं, एक। 250 कर्मचारियों के लिए कार्यालय में - एक और।

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

- चलो अपने आदर्श दुनिया पर जाएँ। जब एक टीम में एक उत्पाद प्रबंधक, एक परियोजना प्रबंधक और सभी-सभी शामिल होते हैं, तो टीम के नेता की जिम्मेदारी कहां होती है? क्या टिमलीड "उत्पादकता" के बजाय "डिज़ाइन" की ओर बढ़ता है?

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

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



- टाइमलाइड को क्या नियंत्रित करना है?

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

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

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

तीसरा, किसी भी प्रकार की विफलताओं की स्थिति में ऐसा नेता, जिसे वह स्वयं सामना नहीं कर सकता, तुरंत उन्हें संकेत देता है और उन लोगों के ध्यान में लाता है जो समस्या को हल कर सकते हैं। यदि टीम के पास समय नहीं है, तो, वह मुश्किल से इसे खोजता है, अपने बॉस को कदम बताता है, और बिना वीरानी के स्वीकार करता है: "हमारे पास समय नहीं है, क्योंकि हम" कम करके आंका "जाते हैं, और उसे समाधान प्रदान करते हैं।

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

इस प्रकार, टीम लीडर एक पूर्ण तकनीकी प्रबंधक है, न कि "इसे रहने दो" की श्रेणी से किसी प्रकार का उपांग।

- क्या अन्य जिम्मेदारियों - या एक Timlid की देखभाल के लिए दिया जाना चाहिए?

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

, «» : , , - «- ». HR-. , , , . . HR- .

, . , - . .

. - , , , . : , . , : «- , - ».

, — , , — . . , Mos.ru . , . - , . , «» , , , : , . , : , , .

— «», ?

— , - . , . . — , , - . , code review, - , . , (, ). , Vue.js, PostgreSQL 10 «» . , , -, .

, . , , : , Sphinx Avito. .

, , — - , . . , , , .

- , . , , , .

— , ? , back-end front-end .

— . , , , «», . «» , , , .

— — , — ? , ? «»?

— , . . - , - — . . , , , . , IT — , . . : , .

CTO . — , ? , « — — » — , , , ? .

— , , , ?

— , . , - . — . , . .

, , . . , : « PHP, Go, - -». , , .

, «», : , , .

. - , . - « ». , , .

— . . — . HR-. , . , ? , , . , , — - .

— . , . — .

, soft skills, , , , . , ? , . : .

— «» «-». , , . , ? ?

— , . — — . , : « ». , . , — . . Saint TeamLead Conf : , «», «».

, — — . , , , : « , — ». : , .

, , : : « , , — - ».

— ? ?

— , , soft skills. , , , , , .

, , , , , . — , , .

— , , , ? ?

— - . , . 7±2, , , , , ( ). -, — -.

— , ? ?

— : , .

:
• . , , , , , .
• , , , , , , .
• , , .



— , IT , ?

- नहीं! . , «» IT-. , , : , «» .

TeamLead Conf, , «», , , , — , , — .

, , . , Mos.ru , . : . Banki.ru , , , , ; - .

— . , , , , review. .

, Saint TeamLead Conf, — . , , , , , .

— , TeamLead Conf , , ? ?

— , , , - . , .

— , .

— IT , «» ? ?

— . . , - - . , . - .

— ? « », , - ?

— . , - : , , , IT-, . , « », .

«» — HighLoad++ , ++, «» — Whale Rider Aletheia Business. « »: , , , .

, Saint TeamLead Conf . , ?

वसंत TeamLead Conf की सामग्री पूरी तरह से हमारे YouTube चैनल पर पोस्ट की गई है। नए सम्मेलन का एक वीडियो भी दिखाई देगा, लेकिन कुछ महीनों में। यदि आप याद नहीं करना चाहते हैं तो सदस्यता लें।

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