प्रॉम्प्ट और दायरा
यह सॉफ्टवेयर इंजीनियरों, टेक लीड्स और इंजीनियरिंग प्रबंधकों के लिए ओनरशिप से जुड़ा एक सामान्य प्रश्न है। Dataford का प्रकाशित प्रश्न उम्मीदवारों से यह समझाने के लिए कहता है कि उन्होंने टीम की अस्पष्ट जवाबदेही को कैसे पहचाना, उन्होंने क्या तंत्र (mechanism) पेश किया, और उसका क्या परिणाम रहा। Amazon का Ownership मार्गदर्शन कहता है कि जब किसी समस्या का कोई स्पष्ट ओनर नहीं होता है, तो लीडर्स ओनर को ढूंढते हैं, हैंडऑफ़ को ठीक करते हैं, और समाधान तक पहुंचाते हैं। एक वास्तविक कहानी का उपयोग करें; "मैंने बहुत समन्वय (coordination) किया" कोई परिणाम नहीं है।
साक्षात्कारकर्ता क्या जांच रहा है
चार संकेतों पर ध्यान दें: बार-बार होने वाले दोबारा काम (rework), अप्रूवल के इंतज़ार या अनदेखे अलर्ट्स से ज़िम्मेदारी के अंतर (gap) को पहचानना; ज़िम्मेदारी संभालने से पहले सीमाओं की जांच करना; निर्णय लेने वाले और कार्य निष्पादक (executor) को दृश्यमान बनाना; और एक पुन: प्रयोज्य (reusable) तंत्र के साथ परिणाम तक पहुंचना। ThirstySprout की व्यवहारिक गाइड एक विशिष्ट कहानी, STAR और मापने योग्य परिणामों की अनुशंसा करती है। एक मजबूत उत्तर आपके निर्णय, अन्य लोगों की बाधाओं और इस बात को दर्शाता है कि तंत्र ने याददाश्त पर निर्भरता को कैसे कम किया।
पहले स्पष्ट करने योग्य प्रश्न
ऐसी कहानी चुनें जहां समस्या कोई ओनर न होना, दोहरा ओनरशिप होना, या निष्पादन से अलग निर्णय लेने का अधिकार होना थी; अपने औपचारिक अधिकार का उल्लेख करें; बताएं कि क्या जोखिम ने उपयोगकर्ताओं, राजस्व, अनुपालन (compliance) या डिलीवरी को प्रभावित किया; इसमें शामिल टीमों के नाम बताएं; और उस अवलोकन योग्य मीट्रिक की पहचान करें जिसने सुधार दिखाया। यदि यह केवल एक बार का एहसान था, तो ऐसा मामला चुनें जिसमें एक स्थायी हैंडऑफ़ और एक दृश्यमान परिणाम की आवश्यकता थी।
30-सेकंड का उत्तर ढांचा
कहा जाए: "एक क्रॉस-टीम पहल पर, मैंने पाया कि बोर्ड, ऑन-कॉल शेड्यूल और डिज़ाइन दस्तावेज़ में एक ही काम के तीन अलग-अलग ओनर थे। दो हैंडऑफ़ छूट गए थे और एक माइलस्टोन फिसल गया था। मैंने तथ्यों को सत्यापित करने के लिए टिकटों और एक टाइमलाइन का उपयोग किया, फिर सब कुछ खुद संभालने के बजाय निर्णय के अधिकारों, निष्पादन और बैकअप कवरेज को संरेखित करने के लिए ओनर्स को एक साथ लाया। हमने प्रोजेक्ट टेम्पलेट में एक ज़िम्मेदारी मैट्रिक्स (responsibility matrix), हैंडऑफ़ चेकलिस्ट और एस्केलेशन पाथ जोड़ा, और मैंने पहले पुनरावृत्ति (iteration) का सत्यापन किया। इसका परिणाम (अपने वास्तविक डेटा से बदलें) कम दोबारा काम और समय पर डिलीवरी रहा; औपचारिक ओनर ने बाद में इसे बनाए रखा। मैंने उस शुरुआती संकेत का भी उल्लेख किया जो मुझसे छूट गया था।"
चरण-दर-चरण गहन विश्लेषण
चरण 1: साक्ष्य के साथ अंतर का पता लगाएं
"वह टीम मददगार नहीं थी" से शुरुआत न करें। अधूरे काम, प्रतीक्षा समय, डुप्लिकेट सबमिशन, अलर्ट प्रतिक्रिया और हैंडऑफ़ रिकॉर्ड की सूची बनाएं। प्रत्येक कार्रवाई के लिए निर्णय लेने वाले, निष्पादक, सूचित पक्ष और बैकअप को चिह्नित करें। "कोई नहीं जानता कि कौन निर्णय लेता है" को "ओनर पर बहुत अधिक काम का बोझ है" से अलग करें; पहले वाले को एक सीमा की आवश्यकता होती है, जबकि दूसरे को क्षमता या प्राथमिकता में बदलाव की आवश्यकता हो सकती है।
चरण 2: लोगों को संरेखित करने से पहले सीमाओं की पुष्टि करें
समझाएं कि आप हस्तक्षेप क्यों कर रहे हैं, क्या जोखिम है, और कौन से निर्णय अभी भी औपचारिक ओनर के हैं। अधिकार, कार्यभार और लक्ष्यों के बारे में प्रत्येक टीम की चिंताओं को सुनें, फिर उन्हीं तथ्यों का उपयोग करके एक संक्षिप्त चर्चा आयोजित करें। सबसे छोटा उपयोगी तंत्र प्रस्तावित करें: एक जवाबदेह निर्णयकर्ता, एक प्रत्यक्ष रूप से ज़िम्मेदार निष्पादक, एक बैकअप और एक एस्केलेशन पाथ। ओनरशिप के विकल्प के रूप में अधिक बैठकों को न लाएं।
चरण 3: समझौते को एक जांचने योग्य तंत्र में बदलें
निर्णय के अधिकार, डिलिवरेबल्स, पूर्णता मानदंड और हैंडऑफ़ ट्रिगर्स को प्रोजेक्ट दस्तावेज़ या टिकट टेम्पलेट में लिखें। प्रत्येक माइलस्टोन पर, ओनर इनपुट, आउटपुट और अगले प्राप्तकर्ता की पुष्टि करता है; उच्च-जोखिम वाले काम में ऑन-कॉल, रोलबैक या अप्रूवल की शर्तें जुड़ती हैं। तंत्र को छुट्टियों, टीम के बदलावों और नए कर्मचारियों के आने पर भी काम करना चाहिए, बिना इसके कि आपको लोगों को लगातार याद दिलाना पड़े।
चरण 4: असहमति और एस्केलेशन को संभालें
यदि लोग ओनर या सीमा पर विवाद करते हैं, तो असहमति को लक्ष्यों, अधिकार और संसाधनों में विभाजित करें, फिर ऐसे मीट्रिक का उपयोग करें जिसे ओनर स्वीकार करता हो। जब समय सीमा तक संरेखण नहीं बन पाता है, तो एक अस्थायी ओनर, जोखिम, एस्केलेशन लक्ष्य और निर्णय की तारीख तय करें। एस्केलेशन से निर्णय प्राप्त होता है; यह विवाद को मैनेजर पर थोपने के लिए नहीं है।
चरण 5: परिणाम सत्यापित करें और अपनी कमी को स्वीकार करें
समस्या से जुड़ा परिणाम चुनें: छूटे हुए हैंडऑफ़, प्रतीक्षा समय, दोबारा काम के घंटे, अलर्ट प्रतिक्रिया, या समय पर माइलस्टोन। वास्तविक रिकॉर्ड का उपयोग करें; यदि संख्या अनुमानित है, तो विधि समझाएं। उस शुरुआती संकेत के साथ समाप्त करें जो आपसे छूट गया था और वह जांच जो आपने जोड़ी थी। यह दावा न करें कि केवल टेम्पलेट ने सुधार किया है।
मॉडल उच्च-गुणवत्ता वाला उत्तर
"एक भुगतान-समाधान (payment-reconciliation) माइग्रेशन के दौरान, डेटा प्लेटफ़ॉर्म ने एक फ़ाइल जनरेट की और वित्त प्रणाली ने इसे आयात किया, लेकिन किसी के पास विफल पुनरावृत्तियों (failed retries) या अंतिम पुष्टि का ओनरशिप नहीं था। दो टीमों ने एक ही बैच का पुनः प्रयास किया, जिससे डुप्लिकेट-आयात जोखिम पैदा हुआ। मैंने इसे टिकट प्रतीक्षा समय और दो परस्पर विरोधी रनबुक्स में पाया। मैं प्रोजेक्ट का ओनर नहीं था, इसलिए मैंने टाइमलाइन और जोखिम ओनर को भेजा और डेटा, वित्त और ऑन-कॉल लीड्स को 30 मिनट के संरेखण के लिए आमंत्रित किया। हमने वित्त ओनर को अंतिम पुष्टि के लिए ज़िम्मेदार बनाया, डेटा ओनर को निर्माण और पुनः प्रयासों के लिए ज़िम्मेदार बनाया, और आयात के बाद एक बैकअप के साथ बैच-नंबर वाली रसीद जोड़ी। मैंने ज़िम्मेदारी मैट्रिक्स और हैंडऑफ़ चेकलिस्ट को रिलीज़ टेम्पलेट में शामिल किया और पहले पुनरावृत्ति का सत्यापन किया। इसका परिणाम (अपने वास्तविक डेटा से बदलें) दो महीने तक कोई डुप्लिकेट आयात न होना और कम प्रतीक्षा समय रहा; औपचारिक ओनर ने बाद में इसे बनाए रखा। समीक्षा में, मैंने स्वीकार किया कि मैंने केवल विकास कार्यों को देखा था और पूर्णता की क्रॉस-सिस्टम परिभाषा (cross-system definition of done) की जांच नहीं की थी, इसलिए मैंने डिज़ाइन समीक्षाओं में 'सफलता की पुष्टि कौन करता है?' जोड़ा।"
सामान्य गलतियाँ और सुधार
- "किसी के पास ओनरशिप नहीं था, इसलिए मैंने सब कुछ ले लिया": यह बचाव दिखाता है, स्थायी ओनरशिप नहीं; अधिकार की पुष्टि करें और एक औपचारिक ओनर स्थापित करें।
- केवल बैठकों और ज़िम्मेदारी मैट्रिक्स का वर्णन करना: एक तंत्र परिणाम नहीं है; इसे हैंडऑफ़, प्रतीक्षा या घटना मेट्रिक्स से जोड़ें।
- दूसरी टीम को दोष देना: बाधाओं को समझाएं और बताएं कि कैसे एक साझा लक्ष्य, साक्ष्य और एस्केलेशन पाथ ने एक निर्णय निकाला।
- प्रभावशाली संख्याएँ या टीम का श्रेय मनगढ़ंत बनाना: रिकॉर्ड का उपयोग करें; जब संख्याएँ उपलब्ध न हों, तो माप विधि दें और असत्यापित परिणामों को स्पष्ट रूप से चिह्नित करें।
फॉलो-अप प्रश्न और उत्तर
आपने व्यक्तिगत रूप से क्या किया?
औपचारिक ओनर के निर्णय और टीम के काम से "मैंने देखा, सत्यापित किया, प्रस्तावित किया, प्रलेखित किया और फ़ॉलोअप किया" को अलग करें। साक्षात्कारकर्ता को सहयोग को एकल कहानी में बदले बिना आपके निर्णय को देखना चाहिए।
क्या होगा यदि औपचारिक ओनर ने आपकी प्रस्तावित सीमा को अस्वीकार कर दिया?
पूछें कि क्या आपत्ति अधिकार, क्षमता, या लक्ष्य के टकराव की है और शीर्षक के बजाय तंत्र को समायोजित करें। यदि उपयोगकर्ता या डिलीवरी जोखिम बना रहता है, तो अस्थायी ओनर को रिकॉर्ड करते हुए साक्ष्य, विकल्पों और निर्णय की तारीख के साथ एस्केलेट करें।
क्या होगा यदि तंत्र शुरू होने के बाद एक बार हैंडऑफ़ विफल हो गया?
स्वीकार करें कि तंत्र से एक केस छूट गया। समझाएं कि आपने ट्रिगर की समीक्षा कैसे की, एक जांच या ऑटोमेशन कैसे जोड़ा, और मूल कारण को भारी प्रक्रिया से छिपाने से कैसे बचा। परिणाम तेजी से रिकवरी या किसी अप्रभावी तंत्र को हटाने का निर्णय हो सकता है।
बिना किसी परिमाणित परिणाम के आप विश्वसनीय कैसे बने रहते हैं?
जांचने योग्य विकल्पों का उपयोग करें जैसे कि टिकट के नमूने, छूटे हुए हैंडऑफ़ लॉग, समय पर पूरे हुए माइलस्टोन की संख्या, या ओनर का फीडबैक, और दायरा, बेसलाइन और सीमाओं का उल्लेख करें। "यह अधिक सहज लगा" कोई परिणाम नहीं है।