प्रतिनिधि इंटरव्यू विषय

व्यवहारिक साक्षात्कार: मौन ज्ञान (tacit knowledge) को पुन: प्रयोज्य दस्तावेज़ीकरण में बदलने के बारे में बताएं

व्यवहार संबंधी (Behavioral)मध्यम
Offer.cc संपादकीय टीमप्रकाशित अपडेट किया गया

प्रश्न

आपकी टीम डिप्लॉयमेंट, डिबगिंग या व्यावसायिक नियमों के लिए कुछ लोगों की स्मृति पर निर्भर करती है, और नए सदस्य बार-बार वही प्रश्न पूछते रहते हैं। किसी ऐसे समय के बारे में बताएं जब आपने मौन ज्ञान को पुन: प्रयोज्य दस्तावेज़ीकरण में बदला और यह साबित किया कि इससे टीम के काम में सुधार हुआ।

संकेत और दायरा

आपकी टीम रिलीज़ चरणों, घटना के निदान (incident diagnosis) या व्यावसायिक नियमों के लिए कुछ अनुभवी लोगों पर निर्भर करती है। जानकारी चैट और निजी नोट्स में बिखरी हुई है; ऑनबोर्डिंग धीमी है और ऑन-कॉल इंजीनियर पुरानी गलतियों को दोहराते हैं। उस समय का वर्णन करें जब आपने इस कमी को पहचाना, सही दायरा चुना, उपयोगकर्ताओं को शामिल किया, इसे अपनाने की दर मापी और दस्तावेज़ को अद्यतित (current) रखा।

यह प्रश्न कोई सुंदर पेज बनाने के बारे में नहीं है। यह इस बात का परीक्षण करता है कि क्या आप बिना कोई व्यर्थ प्रक्रिया जोड़े व्यक्तिगत स्मृति को टीम की क्षमता में बदल सकते हैं। इसके मूल कौशल स्वामित्व (ownership), संचार, सरलीकरण और मापने योग्य प्रभाव हैं, इसलिए यह एक व्यवहारिक (behavioral) प्रश्न है।

साक्षात्कारकर्ता क्या मूल्यांकन करता है

साक्षात्कारकर्ता एक ठोस विफलता या बार-बार होने वाले नुकसान/लागत को देखना चाहते हैं, न कि यह कि "मुझे दस्तावेज़ लिखना पसंद है।" प्रभावशाली उत्तरों में पाठकों, निर्णय सीमाओं, उदाहरणों, मालिक (owner) और अपडेट ट्रिगर्स का उल्लेख होता है, और फिर वास्तविक उपयोगकर्ताओं को गाइड की समीक्षा और निष्पादन करने दिया जाता है।

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

पहले स्पष्ट करने योग्य प्रश्न

  • मौन ज्ञान के कारण क्या नुकसान हो रहा था: प्रतीक्षा समय, घटनाएं, बार-बार संचार, या गलत निर्णय?
  • पाठक कौन हैं, और क्या उन्हें प्रक्रियाओं, संदर्भ (context), या निर्णय रिकॉर्ड की आवश्यकता है?
  • कौन से हिस्से स्थिर हैं और कौन से कोड, अनुमतियों (permissions), विक्रेताओं या नीतियों के साथ बदलते हैं?
  • अपडेट का स्वामित्व किसके पास है, और किस बदलाव की स्थिति में समीक्षा शुरू होनी चाहिए?
  • आप सीक्रेट्स, व्यक्तिगत डेटा और उत्पादन (production) की प्रतिबंधित जानकारी की सुरक्षा कैसे करेंगे?
  • पेज व्यूज से परे, इसे अपनाने का सबसे छोटा मापने योग्य संकेत क्या है?

30-सेकंड का उत्तर

"मैं किसी एक घटना या बार-बार होने वाले इंतज़ार के ज़रिए इस अंतर को स्पष्ट करूँगा, फिर न्यूनतम संस्करण के लिए एक उच्च-आवृत्ति, प्रतिवर्ती (reversible) और कम जोखिम वाले वर्कफ़्लो का चयन करूँगा। वास्तविक पाठकों के साथ मिलकर, मैं पूर्वापेक्षाओं, निर्णय बिंदुओं, अवलोकनीय संकेतों, सत्यापन और रोलबैक का दस्तावेज़ीकरण करूँगा, और एक मालिक व अपडेट ट्रिगर सौंपूँगा। लॉन्च के बाद, मैं स्वतंत्र रूप से कार्य पूरा करने में लगे समय, दोहराए गए प्रश्नों और एस्केलेशन को ट्रैक करूँगा। यदि उपयोग कम रहता है, तो मैं बाधाओं को दूर करूँगा या लिंक को सीधे वर्कफ़्लो में जोड़ूँगा। मैं केवल पेज व्यूज गिनने के बजाय वास्तविक कार्य में बदलाव को मान्य करूँगा।"

चरण-दर-चरण समाधान

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

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

दो वास्तविक पाठकों को बिना किसी मौखिक मदद के गाइड निष्पादित करने के लिए आमंत्रित करें। छूटे हुए संदर्भ और भ्रमित करने वाले शब्दों को चिन्हित करें। कोड, डैशबोर्ड या टिकटों के लिंक जोड़ें ताकि काम करते समय पेज आसानी से मिल सके। सीक्रेट्स, व्यक्तिगत डेटा और प्रोडक्शन क्रेडेंशियल्स को छिपाएं (redact करें) और एक सुरक्षित एक्सेस पाथ का उपयोग करें।

एक रखरखाव अनुबंध (maintenance contract) बनाएं: एक मालिक, संस्करण या अंतिम समीक्षा का समय, और कोड परिवर्तन, घटनाओं या विक्रेता परिवर्तनों के लिए एक समीक्षा ट्रिगर निर्धारित करें। यदि लोग रखरखाव से हिचकिचाते हैं, तो केवल वही सामग्री रखें जो संचालन को प्रभावित करती है, और स्थायी निर्णयों को एक परिवर्तन टेम्पलेट या स्वचालित जांच में स्थानांतरित करें।

इसे अपनाने का मापन पहली बार स्वतंत्र रूप से कार्य पूरा करने के समय, दोहराए गए प्रश्नों, ऑन-कॉल एस्केलेशन, रोलबैक सफलता और उन पाठकों के अनुपात से करें जिन्हें अभी भी मदद की आवश्यकता होती है। पेज व्यूज एक कमजोर संकेतक हैं। छोटे नमूने के लिए, कार्य के पहले और बाद के अवलोकन का उपयोग करें और सटीक कार्य-कारण संबंध का दावा करने के बजाय अन्य प्रभावित करने वाले कारकों (confounders) का विवरण दें।

प्रतिरोध को उपयोगिता के संकेत (usability signal) के रूप में देखें: प्रवेश बिंदु छिपा हो सकता है, भाषा अपरिचित हो सकती है, चरण बहुत लंबे हो सकते हैं, या अनुमति गायब हो सकती है। अनिवार्य पावती (acknowledgment) के बजाय एक छोटी कार्यशाला और एक वास्तविक कार्य के साथ इसे ठीक करें। जहाँ संभव हो, स्थिर पूर्वापेक्षाओं को स्क्रिप्ट या CI जांच में बदलें ताकि टीम को स्मृति पर कम निर्भर रहना पड़े।

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

आदर्श उत्तर

"एक रिलीज़ घटना के दौरान, केवल एक टीम साथी जानता था कि रोलबैक के लिए कौन सा स्विच सुरक्षित था, जिसके कारण टीम को लगभग 40 मिनट तक प्रतीक्षा करनी पड़ी। मैंने पिछले तीन महीनों के समान एस्केलेशन और दोहराए गए प्रश्नों की समीक्षा की, ज्ञान के एक नियमित अंतर की पुष्टि की, और पहले न्यूनतम गाइड के रूप में रोलबैक को चुना।

दो ऑन-कॉल इंजीनियरों और मैंने पूर्वापेक्षाओं, मीट्रिक जांच, स्विच स्थान, सत्यापन और रोलबैक के बाद की जांच को एक सुरक्षित डैशबोर्ड लिंक के साथ लिखा। एक नए सदस्य ने केवल गाइड का उपयोग करके यह अभ्यास किया; 'स्वस्थ' (healthy) स्थिति को परिभाषित नहीं किया गया था और अनुमति का रास्ता गायब था, इसलिए मैंने सीमाएँ (thresholds) और एस्केलेशन चरण जोड़े। रोटेटिंग ऑन-कॉल मालिक ने इसका रखरखाव किया, और कॉन्फ़िगरेशन बदलने पर रिलीज़ टेम्पलेट ने अपडेट के लिए प्रेरित किया।

चार सप्ताह बाद, नए सदस्यों के अभ्यास का मध्यमान (median) समय 25 से घटकर 10 मिनट हो गया और संबंधित एस्केलेशन प्रति सप्ताह पाँच से घटकर दो हो गए। व्यूज हमारी सफलता का पैमाना नहीं थे। जब किसी विक्रेता ने एक मीट्रिक का नाम बदल दिया, तो मैंने गाइड को अपडेट किया और एक स्वचालित जांच जोड़ी। इसका परिणाम किसी एक व्यक्ति की स्मृति के स्थान पर एक सत्यापन योग्य, रखरखाव योग्य टीम क्षमता के रूप में सामने आया।"

सामान्य गलतियाँ

  • "मैंने एक विकी लिखा" → कोई पैमाना या अपनाने का प्रमाण नहीं → एक बेसलाइन, पाठक और परिणाम प्रस्तुत करें।
  • विश्वकोश (encyclopedia) बनाना → पढ़ने में कठिन और जल्दी पुराना होना → एक बार-बार होने वाले वर्कफ़्लो से शुरुआत करें।
  • निर्णयों के बिना कमांड सूचीबद्ध करना → पाठकों को पता नहीं होता कि कब रुकना है → पूर्वापेक्षाएँ, संकेत, शाखाएँ और रोलबैक परिभाषित करें।
  • उपयोगकर्ता परीक्षण छोड़ना → घटना के दौरान कमियां सामने आती हैं → वास्तविक पाठकों से बिना सहायता के इसे चलवाएं।
  • कोई मालिक न होना → पहला बदलाव ही इसे अमान्य कर देता है → स्वामित्व और ट्रिगर्स सौंपें।
  • व्यूज को प्रमाण के रूप में उपयोग करना → विज़िट से कार्य पूरा होने का प्रमाण नहीं मिलता → कार्य पूरा होने का समय, प्रश्न और एस्केलेशन ट्रैक करें।
  • अनिवार्य प्रशिक्षण को अपनाना मानना → लोग वापस चैट पर पूछने लगते हैं → गाइड को सीधे वर्कफ़्लो में रखें और खोजने की कठिनाई को दूर करें।
  • सीक्रेट्स प्रकाशित करना → दस्तावेज़ीकरण एक सुरक्षा जोखिम बन जाता है → संवेदनशील जानकारी हटाएं और नियंत्रित एक्सेस का उपयोग करें।

फॉलो-अप प्रश्न और उत्तर

फॉलो-अप 1: क्या होगा यदि टीम दस्तावेज़ों का रखरखाव नहीं करती है?

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

फॉलो-अप 2: आप यह कैसे साबित करेंगे कि सुधार गाइड की वजह से ही हुआ?

पहले और बाद के कार्य समापन समय, एस्केलेशन और त्रुटियों की तुलना करें, और कार्य अवलोकन तथा पाठकों की प्रतिक्रिया जोड़ें। नमूने के आकार और अन्य कारकों को ईमानदारी से बताएं।

फॉलो-अप 3: आपको दस्तावेज़ कब नहीं लिखना चाहिए?

एक बार की, कम जोखिम वाली जानकारी जिसे समझाने में कुछ ही मिनट लगते हैं, उसके लिए दीर्घकालिक रखरखाव उचित नहीं है; एक टिप्पणी, टिकट या संक्षिप्त संदेश का उपयोग करें। एक स्थायी संपत्ति तभी बनाएं जब बार-बार होने वाला नुकसान उसके रखरखाव से अधिक हो।

फॉलो-अप 4: आप गोपनीय जानकारी को कैसे संभालते हैं?

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

फॉलो-अप 5: नए सदस्य अभी भी वही प्रश्न पूछ रहे हैं। इसका क्या मतलब है?

पाठकों को दोष देने के बजाय प्रवेश बिंदु, भाषा, अनुमतियों और निष्पादन क्षमता की जांच करें। बार-बार पूछे जाने वाले प्रश्नों को अक्सर पूछे जाने वाले प्रश्नों (FAQ), जांच या फ़ॉर्म में बदलें और देखें कि क्या प्रश्न उच्च-मूल्य वाले अपवादों में बदल रहे हैं।

फॉलो-अप 6: आप पुराने (stale) दस्तावेज़ों को कैसे संभालते हैं?

समीक्षा का समय और मालिक निर्धारित करें, कोड, घटना या विक्रेता परिवर्तनों पर समीक्षा ट्रिगर करें, और उस सामग्री को चिह्नित करें या हटा दें जिसकी वैधता की पुष्टि नहीं की जा सकती।

फॉलो-अप 7: यह "प्रक्रिया में सुधार" से किस प्रकार भिन्न है?

इसका मुख्य उद्देश्य किसी व्यक्ति पर निर्भर स्मृति को खोजने योग्य, सत्यापन योग्य और अनुरक्षित टीम संपत्ति में बदलना है। वर्कफ़्लो समान रह सकता है जबकि निष्पादन और हैंडऑफ़ अधिक विश्वसनीय हो जाते हैं।

सार्वजनिक स्रोत

संबंधित प्रश्न