- सीनियर इंजीनियर ‘सही होने’ से ज़्यादा ‘प्रभावी कार्रवाई’ को महत्व देते हैं, और हर गलत प्रोजेक्ट को रोकने की कोशिश नहीं करते
- ‘खराब प्रोजेक्ट’ में तकनीकी, राजनीतिक और UX समस्याएँ शामिल हो सकती हैं, और यह अक्सर व्यक्तिपरक आकलन पर निर्भर करता है
- प्रभाव को बैंक खाते की तरह मैनेज करना चाहिए, क्योंकि बार-बार विरोध करने पर भरोसा कम हो सकता है और व्यक्ति ‘राजनीतिक दिवालियापन’ की स्थिति में पहुँच सकता है
- दखल देना है या नहीं, यह प्रोजेक्ट की निकटता, टीम पर प्रभाव, और कंपनी-स्तरीय नुकसान के पैमाने के आधार पर तय होता है
- हर समस्या सुलझाने की कोशिश करने के बजाय रणनीतिक रूप से हस्तक्षेप का समय चुनना चाहिए, और बाकी मामलों में अवलोकन व तैयारी से काम लेना चाहिए
खराब प्रोजेक्ट की परिभाषा और उदाहरण
- ‘खराब प्रोजेक्ट’ अनावश्यक समस्याओं को हल करने, जटिल डिज़ाइन, या राजनीतिक प्रेरणाओं जैसी कई शक्लों में सामने आ सकता है
- UX के नज़रिए से, यह ऐसे मामलों में हो सकता है जहाँ ऐसी समस्या हल की जा रही हो जो है ही नहीं, या मौजूदा flow को तोड़ा जा रहा हो
- तकनीकी रूप से इसमें ज़रूरत से ज़्यादा जटिलता, गलत library का चुनाव, और अक्षम architecture शामिल हो सकते हैं
- राजनीतिक रूप से, यह promotion या ट्रेंड का पीछा करने के लिए बनाए गए प्रोजेक्ट्स हो सकते हैं
- कोई प्रोजेक्ट अच्छा है या खराब, यह अक्सर समय बीतने के बाद ही स्पष्ट होने वाला व्यक्तिपरक निर्णय होता है, शुरुआत में नहीं
- Google का एक उदाहरण यह था कि platform team ने core user flow को किसी दूसरी team को सौंपने की कोशिश की, लेकिन यह प्रोजेक्ट राजनीतिक कारणों से असफल हो गया
- तकनीकी रूप से यह शानदार था, लेकिन टीमों के बीच अधिकार संबंधी समस्याओं के कारण 2 साल बाद बंद कर दिया गया
- इससे यह सीख मिलती है कि राजनीति और समस्या की सही परिभाषा, तकनीकी उत्कृष्टता जितनी ही महत्वपूर्ण हैं
हर खराब प्रोजेक्ट को रोका नहीं जा सकता, इसके कारण
- software कंपनियों में ‘तेज़ execution’ की ओर झुकाव बहुत मज़बूत होता है, इसलिए चिंताएँ उठाना गति धीमी करने जैसा माना जाता है
- इसलिए जब तक बात बहुत बड़ी समस्या न लगे, उसे नज़रअंदाज़ किए जाने की संभावना अधिक रहती है
- बार-बार विरोध करने पर व्यक्ति को ‘नकारात्मक इंसान’ का टैग लग सकता है, जबकि रोकी गई विफलताओं का श्रेय नहीं मिलता
- विरोध करने से किसी और के promotion या किसी वरिष्ठ executive के प्रोजेक्ट पर असर पड़ सकता है, इसलिए इसमें राजनीतिक जोखिम भी होता है
- एक इंजीनियर की ध्यान देने की क्षमता सीमित होती है, और हर समस्या में दखल देने से वह निंदक बन सकता है
प्रभाव को ‘बैंक खाते’ की तरह मैनेज करना
- प्रभाव परिणामों और सहयोग से जमा होने वाली पूंजी है, और हर विरोध के साथ इसमें से निकासी होती है
- $5 चेक: code review स्तर की छोटी टिप्पणी
- $500 चेक: architecture निर्णय या timeline पर आपत्ति
- $50,000 चेक: executive-स्तर के प्रोजेक्ट को रोकने की कोशिश
- छोटी-छोटी बातों पर बार-बार दखल देने से बड़े मुद्दों पर प्रतिक्रिया देने की क्षमता खत्म हो जाती है
- जब प्रभाव खत्म हो जाता है, तो व्यक्ति मीटिंग इनवाइट्स से बाहर किया जाना, राय की अनदेखी होना जैसी ‘राजनीतिक दिवालियापन’ की स्थिति में पहुँच सकता है
हस्तक्षेप का समय तय करने के मानदंड
- विशेषज्ञता की जाँच: यह सुनिश्चित करना कि आपका आकलन पर्याप्त आधार वाला है
- अपनी बात की सीमा समझना: राय देना ‘आदेश’ नहीं बल्कि ‘दृष्टिकोण साझा करना’ है
- निर्णय के तीन तत्व
- निकटता (Proximity): प्रोजेक्ट आपकी टीम के जितना करीब होगा, दखल की लागत उतनी कम होगी
- टीम प्रभाव (Team Impact): विफलता से टीम को सीधा नुकसान होने की आशंका हो, तो दखल का महत्व बढ़ता है
- कंपनी पैमाना (Company Scale): विफलता का असर पूरे संगठन पर बड़ा हो, तो हस्तक्षेप ज़रूरी हो सकता है
खराब प्रोजेक्ट्स से निपटने के तरीके
- सीधा हस्तक्षेप: प्रोजेक्ट रोकने की मांग करना या गंभीर चिंता वाला दस्तावेज़ जमा करना
- इसके लिए दृढ़ विश्वास और जोखिम उठाने की तैयारी चाहिए
- आंशिक हस्तक्षेप: डिज़ाइन की दिशा बदलना या बेहतर समाधान की ओर मार्गदर्शन करना
- सहयोगात्मक रवैये से आगे बढ़ने पर आपको ‘मदद करने वाले व्यक्ति’ के रूप में देखा जा सकता है
- हस्तक्षेप न करना: जब राजनीतिक जड़ता या प्रभाव की सीमा के कारण दखल की उपयोगिता कम हो
- अगर टीम संबंधित है, तो निर्भरता कम करने या विकल्प तैयार करने जैसे बचाव उपाय करने चाहिए
- अगर संबंध नहीं है, तो शांत रहकर अवलोकन करें और केवल अंदरूनी स्तर पर राय साझा करें
- टीम प्रबंधन: टीम के सदस्यों के साथ वास्तविक स्थिति ईमानदारी से साझा करें, लेकिन अनावश्यक राजनीतिक विवरणों से बचें
निष्कर्ष
- “सही होना और प्रभावी होना अलग बातें हैं” — यही मूल समझ है
- बड़ी कंपनियों में तर्क से ज़्यादा राजनीति और संदर्भ काम करते हैं, और हर गलती को तुरंत सुधारा नहीं जा सकता
- प्रभाव और भरोसे का रणनीतिक उपयोग करके उन क्षणों पर ध्यान देना चाहिए जहाँ वास्तविक बदलाव संभव हो
- बाकी मामलों में सहकर्मियों के साथ बात साझा करें, तैयारी करें, और अवलोकन से सीखें
- भले ही हर चीज़ पूरी तरह हल न हो, यह दृष्टिकोण लंबे समय तक टिकाऊ है
अभी कोई टिप्पणी नहीं है.