नमस्ते। मेरा नाम अलेक्जेंडर गुज़ेंको है, मैं एक बड़ी कंपनी में तीन फ्रंट-एंड डेवलपमेंट टीमों का टीम लीडर हूं। हाल ही में, एक कर्मचारी मेरे पास आया और बोला: “मैं टीम लीडर बनना चाहता हूँ। मैं कहाँ से शुरू करूँ?" इस तरह इस लेख का विचार पैदा हुआ, जिसे मैंने बाद में एक मार्गदर्शक के रूप में भेजने का वादा किया था।
इस लेख में, मैं आपको बताऊंगा कि मैं एक टीम लीडर कैसे बना, इस पद पर आप किन कौशलों के बिना कुछ नहीं कर सकते, और यदि आप एक "साधारण" डेवलपर हैं तो अपने टीम प्रबंधन कौशल को कैसे सुधारें।
आइए सिद्धांत से शुरू करें, जिसके बिना यह समझना मुश्किल होगा कि आप विकास का प्रबंधन करने क्यों गए, लेकिन इसके बजाय परियोजना बजट की गणना क्यों की।
शास्त्रीय अर्थ में, एक टीम लीड एक विकास टीम का प्रमुख होता है। यह सच है लेकिन कुछ आपत्तियों के साथ।
आज के परिदृश्य में, टीम नेतृत्व में प्रोग्रामर से आगे बढ़कर डिजाइनर, विश्लेषक, परीक्षक, एसईओ विशेषज्ञ और विभिन्न आईटी और गैर-आईटी पेशेवर शामिल हैं। इसलिए, समान भूमिका साझा करने वाले कर्मचारियों के समूह के नेता के रूप में टीम लीड को परिभाषित करना अधिक सटीक है, हालांकि मैं विशेष रूप से डेवलपर्स पर ध्यान केंद्रित करूंगा।
दूसरे, टीम लीडर सिर्फ एक टीम लीडर नहीं होता, बल्कि कर्मचारियों और प्रबंधन के बीच मुख्य कड़ी होता है। यह एक महत्वपूर्ण जोड़ है, और मैं नीचे इसका कारण समझाने का प्रयास करूंगा।
तीसरा, यह समझने के लिए कि टीम का नेतृत्व किसके लिए जिम्मेदार है, भूमिका और स्थिति के बीच अंतर करना महत्वपूर्ण है।
टीम लीडर की भूमिका में मुख्य रूप से प्रबंधकीय कार्य शामिल होते हैं:
अपने शुद्ध रूप में, भूमिका शायद ही कभी पाई जाती है, भले ही भर्ती स्थल पर जिम्मेदारियों की सूची अन्यथा कहती हो।
टीम लीड की स्थिति एक साथ कई भूमिकाओं को जोड़ सकती है: टीम लीड, तकनीकी लीड और लीड डेवलपर। इस पद पर, एक विशेषज्ञ अक्सर स्वयं कोड लिखता है, टीम के काम का प्रबंधन करता है, और तकनीकी भाग के लिए जिम्मेदार होता है:
यह व्यवसाय के लिए अधिक सुविधाजनक है जब टीम का नेतृत्व और तकनीकी नेतृत्व एक ही व्यक्ति हो। व्यवहार में, यहां तक कि बड़ी कंपनियों में भी, टीम लीड की स्थिति में विभिन्न अनुपातों में सभी तीन भूमिकाओं का संयोजन शामिल होता है। इसलिए, एक टीम नेतृत्व क्या करता है इसके बारे में विचार अक्सर भिन्न होते हैं।
यदि आप विभिन्न कंपनियों के डेवलपर्स से पूछें कि टीम लीड की जिम्मेदारियाँ क्या हैं, तो उत्तर संभवतः अलग-अलग होंगे। स्वयं टीम के नेतृत्वकर्ताओं के बीच भी समान प्रकार की राय होगी। इसे सत्यापित करने के लिए, बस किसी भी नौकरी खोज साइट पर जाएं और विभिन्न रिक्तियों में जिम्मेदारियों की सूची देखें।
एक विकास दल का नेतृत्व करने के लिए, आपको गंभीर दक्षताओं और अनुभव की आवश्यकता होती है। इसलिए, टीम लीडर बनने का सबसे आम और सही तरीका यह है कि पहले वरिष्ठ स्तर तक पहुंचें और उसके बाद ही नेतृत्व की स्थिति का लक्ष्य रखें। लेकिन ऐसा हमेशा नहीं होता.
यदि टीम में केवल मध्य प्रोग्रामर शामिल हैं और उनमें से एक पहल कर्मचारी है जो सभी मामलों से अवगत है और परियोजना का समर्थन करता है, तो वह एक उत्कृष्ट टीम लीड होगा। हां, उनके पास सीनियर की तुलना में कम तकनीकी कौशल है, लेकिन अगर टीम में उनसे ऊपर कोई नहीं है, तो उनकी योग्यताएं काफी होंगी।
साथ ही, सभी वरिष्ठों को टीम नेतृत्व की स्थिति उपयुक्त करियर पथ नहीं मिलेगी। नेतृत्व की स्थिति में काम करना वास्तव में दिलचस्प होना चाहिए, अन्यथा आप प्रबंधकीय कार्यभार से दूर हो सकते हैं।
संक्षिप्त उत्तर: इसे आज़माएँ। अपने प्रबंधक को बताएं कि आप मुफ़्त में अतिरिक्त ज़िम्मेदारियाँ लेना चाहते हैं और देखें कि क्या होता है। यह एक जीत-जीत योजना है, इसलिए प्रबंधन आमतौर पर सहयोग करने को तैयार रहता है।
टीम लीडर जीतता है : कोई उसके लिए अपना काम करता है।
व्यवसाय जीतता है : काम पूरा हो जाता है, लेकिन आपको इसके लिए पैसे नहीं देने पड़ते।
टीम लीड प्रशिक्षु को एक फायदा यह भी है : कई महीनों से एक साल तक इस मोड में काम करने के बाद, वह खुद समझ सकता है कि क्या वह सफल होता है और क्या उसे नेतृत्व करना पसंद है। और यदि प्रत्येक बिंदु का उत्तर "हाँ" है, तो आप इस दिशा में आगे बढ़ने के बारे में गंभीरता से सोच सकते हैं।
केवल दो ही विकल्प हैं. पहला है कंपनी के अन्य सभी डेवलपर्स को बाहर बिठाना और "सबसे पुराने" कर्मचारी के रूप में टीम लीड बनना। हालाँकि, एक जोखिम है कि "पुराना" शब्द को उद्धरण चिह्नों में नहीं डालना पड़ेगा। दूसरा विकल्प यह है कि आप स्वयं पहल करें।
मैं आपको बताऊंगा कि यह मेरे लिए कैसा था। मेरे डिप्लोमा के अनुसार, मेरा पेशा प्रबंधक है, और मैंने विश्वविद्यालय में अपनी पढ़ाई के समानांतर प्रोग्रामिंग का अध्ययन स्वयं किया। इसलिए प्रोग्रामर के रूप में अपनी पहली नौकरी मिलने से पहले ही मैंने एक डेवलपमेंट टीम लीडर बनने का फैसला कर लिया।
सबसे पहले, मैंने छोटी कंपनियों में काम किया। मुझे इसमें महारत हासिल करने और एक जूनियर से एक मजबूत मध्य खिलाड़ी बनने में दो साल लग गए। प्रोग्रामिंग में अनुभव के बिना, आप एक अच्छे टीम लीडर नहीं बन पाएंगे: आपको यह समझने की ज़रूरत है कि विकास प्रक्रिया कैसे काम करती है, और इसमें क्या गलतियाँ और कमियाँ हैं।
कुछ साल बाद, मैं एक बड़ी कंपनी में काम करने आया और तुरंत संकेत दिया कि मैं एक टीम लीडर बनना चाहता हूं। बड़ी कंपनियों में, हर छह महीने या साल में एक बार, वे आमतौर पर प्रदर्शन की समीक्षा करते हैं, जब प्रबंधक कर्मचारी से मिलते हैं और साथ में वे निकट भविष्य के लिए एक व्यक्तिगत विकास योजना बनाते हैं। ऐसी प्रत्येक बैठक में, मैंने कहा कि मैं टीम लीड बनना चाहता हूं। पहली बार उन्होंने मुझसे कहा: "सब कुछ बढ़िया है, लेकिन पहले अनुभव हासिल करो।" हमने एक विकास योजना बनाई ताकि मैं नेतृत्व का अनुभव प्राप्त कर सकूं।
लगभग छह महीने तक मैंने अपने टीम लीडर के साथ मिलकर कार्यों का आकलन और विश्लेषण किया और उन्हें कर्मचारियों के बीच वितरित करने का प्रयास किया। जब हमारे काम की गुणवत्ता लगभग समान थी, तो कंपनी ने एक नई फ्रंट-एंड डेवलपमेंट टीम बनाई, जिसका नेतृत्व मैंने किया। बड़ी कंपनियों में आपको ज्यादा देर तक इंतजार नहीं करना पड़ता।
वे कहते हैं कि एक टीम लीडर के विकास में दो महत्वपूर्ण मील के पत्थर होते हैं: पहला दो से छह कर्मचारियों का होना और दूसरा 7 या अधिक कर्मचारियों का होना। पहले, मेरे पास केवल एक कर्मचारी था, और अब मैं तीन फ्रंट-एंड डेवलपमेंट टीमों का नेतृत्व करता हूं - 12 कर्मचारी।
मैंने बस पहल दिखाई, प्रबंधन के सामने आया और जैसे ही मौका मिला, मुझे टीम लीडर नियुक्त कर दिया गया।
टीम नेतृत्व अक्सर कंपनी के भीतर उठाया जाता है, और इसे ध्यान में रखना महत्वपूर्ण है। अगर आपकी मौजूदा नौकरी में तरक्की की संभावनाएं हैं तो आपको पहल करनी चाहिए और खुद को मैनेजर की भूमिका में आजमाना चाहिए। लेकिन अगर पूरी टीम फ्रंट-एंड और बैक-एंड है और हर कोई अपना टीम लीडर है, तो आपको चमत्कार की उम्मीद नहीं करनी चाहिए। किसी बड़ी कंपनी में जाना बेहतर है और संकेत दें कि भविष्य में आप नेतृत्व की स्थिति लेना चाहते हैं। आपको प्रक्रियाओं का अध्ययन करने और परियोजना के व्यावसायिक तर्क को समझने के लिए समय की आवश्यकता होगी। लेकिन जब कंपनी में कोई उपयुक्त पद खुलता है, तो संभवतः वे किसी बाहरी व्यक्ति के बजाय आपको चुनेंगे।
टीम लीड की स्थिति में हार्ड और सॉफ्ट दोनों कौशल समान रूप से महत्वपूर्ण हैं। डेवलपर्स आमतौर पर जानते हैं कि कठिन कौशल में क्या कमी है। इसके अलावा, ये आवश्यकताएं दृढ़ता से विशेषज्ञता और प्रौद्योगिकी स्टैक से जुड़ी हुई हैं, इसलिए कोई सार्वभौमिक सूची नहीं है। मैं सॉफ्ट स्किल्स के बारे में बात करूंगा जिन्हें मैं उत्पाद और कंपनी के लिए महत्वपूर्ण मानता हूं।
विकास की गति और गुणवत्ता, और इसलिए लागत, कंपनी की प्रक्रियाओं पर निर्भर करती है, लेकिन वे शायद ही कभी आदर्श होती हैं।
उदाहरण के लिए, आपने एक बग ठीक कर दिया है और बिल्ड को स्टैंड पर लाने के लिए तैयार हैं, व्यवसाय प्रतीक्षा कर रहा है। लेकिन ऐसा करने के लिए, आपको पांच पाइपलाइनों से गुजरना होगा और इसमें शामिल सभी लोगों से अनुमोदन प्राप्त करना होगा। आप जिम्मेदारों को लिखें - मौन। आप उन्हें खींचना शुरू कर देते हैं, लेकिन औपचारिक संदेश सिर्फ जवाब देने के लिए आते हैं - हर किसी के पास समय नहीं है। संशोधित संस्करण को स्टैंड तक पहुंचने में छह घंटे तक का समय लग सकता है। और यह सारा समय आप अपने सहकर्मियों तक पहुँचने में बिताते हैं, और व्यवसाय को धन की हानि होती है।
एक अन्य उदाहरण विभिन्न प्रणालियों, कार्यक्रमों, स्टैंडों और रिपॉजिटरी तक पहुंच की अत्यधिक संख्या है। आमतौर पर बैंकों को इससे नुकसान होता है. एक व्यक्ति काम पर आता है, उसे परियोजना को समझने की जरूरत है, लेकिन पहले डेढ़ महीने तक वह कुछ भी नहीं कर सकता, क्योंकि - यह सही है - कोई पहुंच नहीं है। पहुंच के साथ एक और समस्या यह है कि उनमें से कई हैं, और उनके नाम याद रखना असंभव है। उदाहरण के लिए, निर्देशिका में "भंडार तक पहुंच" के बजाय A32B18KZ होगा - इसे खोजने का प्रयास करें।
मैं वास्तविक मामलों को जानता हूं जहां एक डेवलपर एक या दो महीने तक काम शुरू करने में असमर्थ था। इस पूरे समय उन्हें वेतन मिलता रहा, लेकिन उनका मोहभंग हो गया और उन्होंने नौकरी छोड़ दी। यानी, कंपनी ने एक कर्मचारी की तलाश में छह महीने बिताए, उसे दो महीने का वेतन दिया और फिर भर्ती प्रक्रिया फिर से शुरू करनी पड़ी।
प्रक्रियाओं में ऐसी समस्याएँ काम को जटिल और धीमा कर देती हैं। टीम लीडर का कार्य उन्हें देखना और समझना है कि वास्तव में क्या ख़राब काम कर रहा है और विफलता कहाँ होती है।
प्रक्रियाओं में केवल समस्याएं देखना ही महत्वपूर्ण नहीं है, बल्कि समाधान प्रस्तुत करना भी महत्वपूर्ण है। आप प्रबंधन को शामिल किए बिना कुछ कठिनाइयों से स्वयं निपट सकते हैं। उदाहरण के लिए, एक टीम एक असुविधाजनक राज्य प्रबंधक से जूझ रही है। यदि परियोजना छोटी है या बिल्कुल शुरुआत में है, तो आप एक कॉल की व्यवस्था कर सकते हैं, सबसे अच्छा विकल्प ढूंढ सकते हैं, और यह बता सकते हैं कि बिना किसी नुकसान के धीरे-धीरे एक नए राज्य प्रबंधक को कैसे पेश किया जाए। एक समाधान मिल गया, और व्यवसाय को समस्या के अस्तित्व के बारे में पता भी नहीं चला।
लेकिन अधिकांश समस्याओं का समाधान केवल वरिष्ठ प्रबंधन की मदद से ही किया जा सकता है। उदाहरण के लिए, स्टैंड पर बिल्ड जारी करने में तेजी लाने के लिए, आप एक ऐसे व्यक्ति की पहचान कर सकते हैं जिसके सभी विभागों में अच्छे संबंध हैं और निर्णय निर्माताओं तक उसकी पहुंच है, और उसे अनुमोदन प्रक्रिया में शामिल कर सकते हैं। यदि अन्य विभागों के सहकर्मियों से कोई प्रतिक्रिया नहीं मिलती है, तो वह जानता है कि किसे लिखना है और प्रक्रिया को मैन्युअल रूप से सेट कर सकता है। लेकिन ऐसे काम के लिए एक अलग पद की आवश्यकता होती है, इसलिए आपको कंपनी के प्रबंधन से मंजूरी लेनी होगी।
एक्सेस समस्या को इसी तरह हल किया जाता है। अधिकांश डेवलपर्स को समान सिस्टम और प्रोग्राम की आवश्यकता होती है। उदाहरण के लिए, फ्रंट-एंड डेवलपर्स के लिए - एक रिपॉजिटरी, स्टैंड, जीरा, आदि। तो क्यों न उनके लिए एक मानक एक्सेस पैकेज बनाया जाए और एक ऐसे व्यक्ति को नियुक्त किया जाए जो उनसे छोटे वेतन के लिए अनुरोध करेगा? लेकिन इसके लिए कंपनी के शीर्ष प्रबंधन की इच्छाशक्ति की भी आवश्यकता है।
इसलिए, एक टीम लीडर के मुख्य कौशल में से एक समस्या के सार को व्यवसाय तक सही ढंग से पहुंचाने में सक्षम होना है। यहां कुछ रहस्य हैं.
एक बार पर्याप्त नहीं है . पहले संपर्क के बाद समस्याएं शायद ही कभी हल होती हैं, इसलिए आपको निश्चित अंतराल पर प्रबंधन के पास जाना होगा और उन्हें समस्या की याद दिलानी होगी: "यह टीम को हतोत्साहित कर रहा है," "हम उत्पादकता खो रहे हैं।"
यदि आप देखते हैं कि टीम की समस्याएँ और व्यावसायिक हित किस प्रकार जुड़े हुए हैं, तो इस बिंदु पर जाएँ । उदाहरण के लिए, एक गंभीर बग था जिसे ठीक करने में दो दिन लग गए, भले ही इसमें केवल कुछ घंटे का काम शामिल था, और परिणामस्वरूप व्यवसाय को पैसे का नुकसान हुआ। आप प्रबंधन के पास जाएं और निर्माण के समन्वय की समस्या के बारे में बात करें। ऐसे क्षणों में, व्यवसाय सुझावों के लिए यथासंभव खुले रहते हैं। लेकिन समाधान पहले से ही तैयार होना चाहिए.
सबसे अच्छा तरीका यह गणना करना है कि समस्या को प्रबंधन के पास ले जाने से पहले कंपनी को कितनी कीमत चुकानी पड़ रही है।
फ्रंट-एंड टीम लीडर के रूप में, मैं नियमित रूप से कर्मचारियों से फीडबैक एकत्र करता हूं। उदाहरण के लिए, डेवलपर्स लगातार शिकायत करते हैं कि कार्यों का खराब वर्णन किया गया है। इस कारण यह पता लगाने में काफी समय लग जाता है कि समस्या का लेखक उनसे क्या चाहता है। फिर परीक्षक डेवलपर्स के पास आते हैं और यह समझने की कोशिश करते हैं कि क्या किया गया है और वास्तव में उन्हें क्या परीक्षण करने की आवश्यकता है, और आगे की श्रृंखला में। नतीजतन, हर कोई अभी भी अपने तरीके से सार को समझता है, और बग दिखाई देते हैं।
मैंने गणना की कि औसतन टीम अपने कामकाजी समय का 40% बग ठीक करने में खर्च करती है। टीम के साथ मिलकर, हमने पूर्वव्यापी विश्लेषण किया और पाया कि इनमें से आधे बग केवल इसलिए उत्पन्न हुए क्योंकि उन्होंने समस्या के सार को गलत समझा। अर्थात्, डेवलपर्स का 20% कार्य समय बर्बाद हो जाता है क्योंकि कार्यों का खराब वर्णन किया जाता है। यह वह नंबर है जिसके साथ आपको प्रबंधन के पास जाना चाहिए। इसे पैसे में बदलना आसान है - वही भाषा जो व्यवसाय समझता है।
जब लोग एक-दूसरे के साथ काम करने का आनंद लेते हैं, तो कोई भी बातचीत सहज हो जाती है। स्क्रम इतना लोकप्रिय क्यों है? यह दस्तावेज़ीकरण के बारे में नहीं बल्कि लोगों के बारे में है। कभी-कभी किसी सहकर्मी को उसके उत्तर के दस्तावेजीकरण के लिए दो दिन तक इंतजार करने और हर चीज का विस्तार से वर्णन करने की तुलना में दो मिनट के लिए कॉल करना अधिक प्रभावी होता है। इसलिए, जब टीम के भीतर आपसी समझ और पारस्परिक सहायता का माहौल होता है, तो लोगों के लिए एक-दूसरे से संपर्क करना आसान हो जाता है। उदाहरण के लिए, आपको कोड का एक टुकड़ा मिला और आप समझ नहीं पा रहे हैं कि यह क्या करता है। यदि टीम में स्थिति अच्छी नहीं है, तो आप कॉल करने और पूछने से डरेंगे - "वह सोचेगा कि मैं बेवकूफ हूं।"
टीम के भीतर अच्छे संबंध बनाए रखने के लिए, मैं सप्ताह में एक बार घंटों कॉल करता हूं। इस समय को हम तीन भागों में बांटते हैं. पहला है "आराम"। हम मीम्स और चुटकुले साझा करते हैं। दूसरा भाग समस्याओं की चर्चा है। कभी-कभी हम मिरो में एक साथ कार्ड फेंकते हैं, जो हर किसी को पसंद नहीं आता। इस तरह से मुझे एक तस्वीर मिलती है कि वास्तव में कौन सी चीज़ लोगों को धीमा कर रही है। फिर हम समाधान के लिए विकल्प लेकर आ सकते हैं, जिसके लिए मैं प्रबंधन के साथ पैरवी करूंगा। और हम फिर से "आराम" करते हैं: हम फिल्मों या किसी और चीज़ पर चर्चा कर सकते हैं। ऐसी बैठकें एक सकारात्मक माहौल बनाती हैं और एक नेता के रूप में मुझे यह समझने में मदद करती हैं कि टीम में क्या दिक्कतें हैं।
नए टीम नेतृत्वकर्ताओं की एक सामान्य गलती कार्य प्रक्रियाओं को स्वयं पर केंद्रित करना है। ऐसे में अगर टीम लीडर अचानक बीमार पड़ जाए या छुट्टी पर चला जाए तो काम रुकने लगेगा और उसकी लगातार खिंचाई होती रहेगी। ऐसा होने से रोकने के लिए, आप टीम में से किसी को टीम नेतृत्व की कुछ जिम्मेदारियाँ निभाना सिखा सकते हैं। उदाहरण के लिए, महीने में एक बार कार्यों को वितरित करने के लिए दूसरों पर भरोसा करें। इस तरह, टीम में किसी और के पास यह कौशल होगा, और टीम का नेतृत्व शांति से छुट्टी पर जा सकेगा, यह जानते हुए कि उसके बिना कुछ भी नहीं टूटेगा।
शायद टीम लीड के काम का आकलन करने के लिए यह एक अच्छा मानदंड है: यदि आपको टीम से हटा दिया जाता है, तो सुरक्षा मार्जिन एक महीने के लिए पर्याप्त होना चाहिए।
विकास में, किसी परियोजना पर जोखिमों को प्रबंधित करने के लिए बस कारक जैसे मीट्रिक का उपयोग किया जाता है। यह दिखाता है कि पूरे प्रोजेक्ट को विफल करने के लिए टीम के कितने सदस्यों को एक काल्पनिक बस की चपेट में आना होगा। यदि बस कारक = 1 है, तो आपको गंभीर समस्याएँ हैं।
उदाहरण के लिए, हम एक जटिल परियोजना विकसित कर रहे हैं। इसमें एक परिष्कृत मॉड्यूल है, और केवल एक डेवलपर जानता है कि यह कैसे काम करता है और जानता है कि इसे कैसे संभालना है। यदि यह व्यक्ति बीमार हो जाता है, नौकरी छोड़ देता है या छुट्टी पर चला जाता है, तो इस मॉड्यूल को बदलना एक बहुत लंबी और महंगी प्रक्रिया बन जाएगी, जो पूरे प्रोजेक्ट पर नकारात्मक प्रभाव डालेगी। ऐसा होने से रोकने के लिए, आपको धीरे-धीरे अन्य कर्मचारियों को जटिल मॉड्यूल या लाइब्रेरी के साथ काम करना सिखाने की ज़रूरत है।
टीम लीडर को प्रक्रियाओं को एक व्यक्ति तक सीमित किए बिना, उसे प्रोजेक्ट के लिए आलोचनात्मक बनाए बिना, टीम के भीतर जिम्मेदारी को सही ढंग से वितरित करने में सक्षम होना चाहिए।
टीम लीडर को यह समझना चाहिए कि प्रोजेक्ट कहां जा रहा है, इसमें क्या समस्याएं हैं और उन्हें कैसे हल किया जाए। उदाहरण के लिए, टीम का कुल कार्यभार प्रति सप्ताह 100 कार्य घंटे है। और व्यवसाय पूरे 100 घंटों तक अपनी शुभकामनाएं देता है। इस समय प्रोजेक्ट पर तकनीकी कर्ज जमा हो रहा है, जिससे निपटने का भी समय आ गया है। टीम लीडर का कार्य तकनीकी ऋण के गंभीर होने से पहले के क्षण को ट्रैक करना और प्रबंधन की पैरवी करना है ताकि टीम अपने समय का एक निश्चित प्रतिशत वर्तमान समस्याओं को हल करने में खर्च करे।
शुरुआत में ही यह जानना बेहतर है कि टीम लीड खतरे की घंटी को पहचानने में क्यों परेशान हो रहे हैं।
यह सबसे आम समस्या है, जब आप महीने-दर-महीने प्रबंधन तक पहुंचने की कोशिश करते हैं, आप अपनी समस्याओं और तैयार समाधान के साथ आते हैं, लेकिन शीर्ष पर, वे समस्या को बस बैकलॉग में डाल देते हैं और कुछ नहीं होता है। इसके कई कारण हो सकते हैं. पहला यह कि आप व्यवसाय के प्रति गलत भाषा बोल रहे हैं, और आपको अपना दृष्टिकोण बदलना चाहिए। दूसरा यह कि आपका बॉस "हर चीज़ को सबसे अच्छी तरह जानता है" और हर चीज़ को अपने तरीके से करता रहता है। ऐसे में सबसे अच्छा उपाय यही होगा कि कंपनी बदल दी जाए.
एक सरल उदाहरण: आपकी टीम लगातार कार्यों से अभिभूत है, और अब पर्याप्त हाथ नहीं हैं। छोटे और मध्यम आकार के व्यवसायों के पास नए कर्मचारियों को नियुक्त करने के लिए पैसे नहीं हो सकते हैं। इस मामले में, आप एक अतिरिक्त भूमिका निभा सकते हैं, जैसे कि सिस्टम विश्लेषक की भूमिका, और कार्यों का वर्णन करना शुरू कर सकते हैं ताकि काम तेजी से आगे बढ़े। बड़ी कंपनियों में, सबसे अधिक संभावना है, पैसा है, लेकिन निर्णय लेने की श्रृंखला बहुत लंबी है, और इस बात की कोई गारंटी नहीं है कि कोई बिल्ली तीसरे और चौथे स्तर के मालिकों के बीच से नहीं गुजरी है और इस वजह से प्रक्रिया नहीं रुकेगी। यहां आप केवल शीर्ष प्रबंधन से किसी को अपने पक्ष में करने का प्रयास कर सकते हैं या बस इंतजार कर सकते हैं।
ऐसा होता है कि आप किसी कंपनी में आते हैं, एक रणनीति विकसित करते हैं, योजनाएँ बनाते हैं और काम के प्रति जुनूनी होते हैं, लेकिन समय बीत जाता है और कुछ भी नहीं बदलता है। यहाँ निराश होने में देर नहीं लगती: “किसे चाहिए यह सब?” इस मामले में, आप यह समझने के लिए पूर्वव्यापी विश्लेषण कर सकते हैं कि परियोजना प्रगति क्यों नहीं कर रही है। अपने आप से पूछें: "शायद मैं गलत लक्ष्य पर प्रहार कर रहा हूँ, गलत समस्याओं का समाधान कर रहा हूँ?"
ऐसा तब होता है जब आपको नेतृत्व की स्थिति में रखा जाता है, जिम्मेदारी दी जाती है, लेकिन कोई नियंत्रण लीवर नहीं दिया जाता है। उदाहरण के लिए, स्वतंत्र रूप से साक्षात्कार आयोजित करने और अपनी टीम में शामिल होने के लिए डेवलपर्स को भर्ती करने का कोई तरीका नहीं है। यहां केवल दो विकल्प हैं: या तो व्यवसाय तक पहुंचने का प्रयास करें और अपनी स्थिति बताएं, या कंपनी बदल दें।
उत्पाद विकसित करने और टीम की मौजूदा समस्याओं को हल करने के लिए, टीम नेतृत्व को निर्णय निर्माताओं के साथ लगातार संपर्क में रहना चाहिए। यदि "शीर्ष" तक पहुंच बंद हो जाती है, तो समस्याएं अनसुलझी रह जाएंगी, आशाजनक विकास रणनीतियां अनकही रह जाएंगी और काम करने की प्रेरणा खत्म हो जाएगी। यदि आप प्रबंधन के साथ संबंध स्थापित नहीं कर सकते हैं तो परेशान न होने के लिए, कंपनियों को बदलना बेहतर है।
कभी-कभी बहुत सारे कार्य होते हैं, और टीम आने वाले प्रवाह का सामना नहीं कर पाती है। निरंतर आपातकाल की स्थिति में, नियमित कॉल पृष्ठभूमि में फीकी पड़ जाती हैं - जब बग्स को खत्म करने में इतना समय खर्च किया जा सकता है, तो मीम्स और खाली बकबक की जरूरत किसे है? परिणामस्वरूप, पूरी टीम एक चालित घोड़े में बदल जाती है, जिसकी देर-सबेर शक्ति ख़त्म हो जाएगी और लोग जाना शुरू कर देंगे। टीम का नेतृत्व केवल कर्मचारियों के विस्तार के लिए दबाव डालने या कार्यों को एक कतार में रखने का प्रयास कर सकता है।
ऐसा तब हो सकता है जब आप पहले से स्थापित टीम में शामिल हों जहां हर कोई एक-दूसरे से नफरत करता हो। संचार की एक विषाक्त शैली पहले से ही टीम में जड़ें जमा चुकी है, और किसी भी पारस्परिक सहायता की कोई बात नहीं है। तब केवल एक ही काम किया जा सकता है कि पूरी टीम को भंग कर दिया जाए और फिर से भर्ती की जाए।
समस्या कोई भी हो, अनुकूल परिणाम की संभावना हमेशा रहती है। पहली असफलता के बाद हार मत मानो. यह थोड़ा इंतजार करने या अपना दृष्टिकोण बदलने लायक हो सकता है। लेकिन अगर आपने सब कुछ करने की कोशिश की है, और ऐसा लगता है कि आप एक खाली दीवार पर दस्तक दे रहे हैं, तो छोड़ने का निर्णय ही एकमात्र सही होगा।
समस्याओं को सुलझाने की क्षमता एक टीम लीडर का एक महत्वपूर्ण गुण है। लेकिन, अफ़सोस, यह हमेशा काम नहीं करता। लेकिन अगर आपको लगता है कि आप एक या दो साल से समय निकाल रहे हैं और आप इसे किसी भी तरह से प्रभावित नहीं कर सकते, लेकिन आप विकास करना चाहते हैं, तो कंपनी बदलना कोई बुरा विचार नहीं है। परिवर्तन से डरो मत. नौकरी बदलना सामान्य बात है.