प्रॉम्प्ट और उपयोग के मामले
मुझे अपने बनाए किसी ऐसे प्रोजेक्ट के बारे में बताएं जिसे आपने बाद में बंद (रिटायर) करने का निर्णय लिया। आपने वह निर्णय क्यों लिया, और आपने इसे कैसे क्रियान्वित किया? यह प्रश्न व्यवहारिक, प्रोजेक्ट समीक्षा (retrospective) और नेतृत्व साक्षात्कारों में पूछा जाता है। साक्षात्कारकर्ता यह देखना चाहते हैं कि आप दीर्घकालिक मूल्य की रक्षा कैसे करते हैं, न कि यह कि कोई प्रोजेक्ट हमेशा के लिए बना रहे।
साक्षात्कारकर्ता क्या आंकते हैं
- क्या उपयोग (adoption), लागत, गुणवत्ता, जोखिम या ग्राहकों के परिणाम प्रोजेक्ट को बंद करने के निर्णय का समर्थन करते हैं।
- क्या आप प्रोजेक्ट के परिणामों को अपने अहंकार (ego) से अलग रखते हैं और निर्णय व क्रियान्वयन की पूरी जिम्मेदारी लेते हैं।
- क्या आप प्रभाव को कम करने के लिए माइग्रेशन, रोलबैक, संचार और सहायता की योजना बनाते हैं।
- क्या आप निर्णय के बाद सभी के बीच तालमेल (alignment) बनाते हैं और पुन: प्रयोज्य सीख को सुरक्षित रखते हैं।
उत्तर देने से पहले स्पष्ट करने योग्य प्रश्न
प्रोजेक्ट के लक्ष्य, उपयोगकर्ताओं, आपके निर्णय के अधिकार और समयसीमा की पुष्टि करें। कम से कम दो सत्यापन योग्य मेट्रिक्स तैयार करें जो प्रोजेक्ट जारी रखने की अवसर लागत (opportunity cost) को दर्शाते हों। प्रोजेक्ट को जारी रखने, सीमित करने, रूपांतरित करने और बंद करने की तुलना करें, फिर अपने चयन को समझाएं। प्रभावित ग्राहकों, टीमों और निर्भरताओं (dependencies) की पहचान करें और बताएं कि आपने उन्हें कैसे तैयार किया।
30-सेकंड उत्तर ढांचा
"मैं एक प्रोजेक्ट का ओनर था जिसका उद्देश्य X को हल करना था। Y महीनों के बाद, सबूत Z से पता चला कि मिलने वाला लाभ अब लागत को उचित नहीं ठहरा रहा था। मैंने इसे बंद करने का प्रस्ताव रखा, प्रमुख उपयोगकर्ताओं के साथ प्रभाव की पुष्टि की, और माइग्रेशन, रोलबैक तथा सपोर्ट विंडो की योजना बनाई। हमने T हफ्तों के भीतर बदलाव पूरा किया, मेट्रिक A में सुधार किया, और मैंने इस तर्क और चेकलिस्ट का पुन: उपयोग बाद के एक प्रोजेक्ट में किया।"
चरण-दर-चरण विस्तृत उत्तर
- संदर्भ और लक्ष्य: बताएं कि प्रोजेक्ट किसके लिए था, इसकी सफलता का पैमाना क्या था और आपकी जिम्मेदारी क्या थी।
- साक्ष्य और विकल्प: ट्रेंड डेटा, फीडबैक या जोखिम दिखाएं, और जारी रखने, घटाने, बदलने और बंद करने के विकल्पों की तुलना करें।
- निर्णय और तालमेल: बताएं कि आपने प्रस्ताव कैसे रखा, आपत्तियों को कैसे सुना और एक स्पष्ट निर्णय कैसे सुनिश्चित किया।
- क्रियान्वयन और सुरक्षा: माइग्रेशन, डेटा प्रतिधारण (retention), रोलबैक, संचार, प्रशिक्षण, सहायता, जिम्मेदार व्यक्ति और तिथियों को शामिल करें।
- परिणाम और सीख: ग्राहक प्रभाव, लागत, विश्वसनीयता या डिलीवरी की गति में बदलावों की रिपोर्ट करें, फिर बताएं कि किस चीज़ का पुन: उपयोग किया गया।
उच्च-गुणवत्ता वाला नमूना उत्तर
मैं एक आंतरिक रिलीज डैशबोर्ड का ओनर था जिसका उपयोग तीन टीमें लॉन्च स्थिति की जांच के लिए करती थीं। छह महीनों के बाद, उपयोग केवल दो पुराने पृष्ठों पर केंद्रित हो गया था जबकि रखरखाव में प्रत्येक पुनरावृत्ति (iteration) में लगभग दो दिन का समय लग रहा था। कंपनी के पास एक एकीकृत डैशबोर्ड भी था, इसलिए दोनों को बनाए रखने से डेटा का दोहराव और अनुमति (permission) संबंधी जोखिम पैदा हो रहा था। मैंने एक्सेस लॉग, सपोर्ट टिकट और रखरखाव के घंटों को संयोजित किया, फिर पुराने इंटरफ़ेस को रिटायर करने का प्रस्ताव रखा, जबकि इसकी क्वेरी क्षमता को सुरक्षित रखा गया। प्रोडक्ट और सपोर्ट टीमों को चिंता थी कि उपयोगकर्ता अपना प्रवेश बिंदु खो देंगे, इसलिए मैंने दो सप्ताह की समानांतर अवधि, माइग्रेशन गाइड, डेटा स्नैपशॉट, प्रतिवर्ती रीडायरेक्ट स्विच और लगातार उपयोग करने वाले उपयोगकर्ताओं के साथ सीधे संपर्क की योजना बनाई। दो सप्ताह बाद, पुराने डैशबोर्ड का ट्रैफ़िक उसके बेसलाइन का आठ प्रतिशत रह गया, कोई ब्लॉकिंग टिकट नहीं आया, और टीमों ने प्रति इटरेशन लगभग दो दिन बचाए। मैंने अपनी प्रोजेक्ट चेकलिस्ट में निर्भरता समीक्षा, संचार टेम्प्लेट और रोलबैक मानदंड जोड़े और किसी अन्य सिस्टम को बंद करते समय उनका पुन: उपयोग किया। इस अनुभव ने मुझे किसी प्रोजेक्ट को उसके परिणामों और स्थिरता के आधार पर आंकना सिखाया, न कि निरंतर रखरखाव को इस बात का प्रमाण मानना कि पिछले प्रयासों को जारी ही रखा जाना चाहिए।
सामान्य गलतियाँ
- अपने निर्णय या कार्यों का उल्लेख किए बिना केवल यह कहना कि किसी मैनेजर ने इसे बंद करने का आदेश दिया था।
- ग्राहकों, डेटा और निर्भरताओं की अनदेखी करते हुए प्रोजेक्ट बंद करने को किसी की गलती के रूप में प्रस्तुत करना।
- बेसलाइन, समय सीमा या परिणाम के आंकड़ों के बिना केवल राय देना।
- व्यावसायिक ट्रेड-ऑफ को समझाए बिना केवल कार्यान्वयन विवरणों को सूचीबद्ध करना।
- सीख और बदले हुए व्यवहार को समझाए बिना प्रोजेक्ट को सीधे विफलता कह देना।
अनुवर्ती प्रश्न और उत्तर
आपने प्रोजेक्ट बंद करने के विरोध को कैसे संभाला?
उपयोगकर्ताओं, अनुपालन या डिलीवरी जोखिम से जुड़ी चिंताओं को दोहराएं, फिर सफलता के समान पैमानों के आधार पर विकल्पों की तुलना करें। यदि असहमति बनी रहती है, तो एक छोटा पायलट, समानांतर अवधि या स्पष्ट रोलबैक शर्त का प्रस्ताव दें ताकि चर्चा अवलोकन योग्य साक्ष्यों पर वापस आ सके।
क्या होता यदि बंद करने के बाद कुछ गड़बड़ हो जाती?
आपके द्वारा पहले से निर्धारित की गई निगरानी, ऑन-कॉल ओनर और रोलबैक पथ का वर्णन करें। एक ठोस प्रतिक्रिया दें: आपने इसे कब पहचाना, किसने निर्णय लिया, सेवा को कैसे बहाल किया गया, और उसके बाद चेकलिस्ट कैसे बदली गई।
क्या डूबी हुई लागत (sunk cost) ने आपको झिझकाया?
भावना को स्वीकार करें, फिर भविष्य के लाभ, जोखिम और विकल्पों का उपयोग करके पुनर्मूल्यांकन करें। समझाएं कि प्रोजेक्ट के ज्ञान और संपत्तियों को स्थानांतरित किया जा सकता है, भले ही प्रोजेक्ट को स्वयं बनाए रखने की आवश्यकता न हो।
आप कैसे दिखाते हैं कि प्रोजेक्ट को बंद करना आपका योगदान था?
टीम की डिलीवरी को अपने स्वामित्व से अलग करें: आपके द्वारा जुटाए गए साक्ष्य, आपके द्वारा स्थापित तालमेल, आपके द्वारा डिज़ाइन किए गए सुरक्षा उपाय, और प्रभाव को सत्यापित करने के लिए आपके द्वारा उपयोग किए गए परिणाम मेट्रिक्स।