प्रॉम्प्ट
किसी टीम के साथी को उसके पहले प्रोडक्शन बदलाव के दौरान मेंटर करने के बारे में बताएं। समझाएं कि आपने सीखने के लक्ष्यों की पहचान कैसे की, जोखिम को कैसे विभाजित किया, समीक्षा की व्यवस्था कैसे की, धीरे-धीरे जिम्मेदारियां कैसे सौंपीं, और डिलीवरी तथा क्षमता वृद्धि दोनों को कैसे मापा।
परिदृश्य और सीमाएं
एक वास्तविक सेवा, बदलाव का दायरा, अनुभव की कमी और लॉन्च विंडो का उपयोग करें। हो सकता है कि आप एक औपचारिक मेंटर, समीक्षक या अस्थायी भागीदार रहे हों, लेकिन उस व्यक्ति के लिए काम खुद पूरा कर देना मेंटरिंग का परिणाम नहीं है।
यह क्या जांचता है
यह परीक्षा मदद को केवल उत्तर देने के बजाय क्षमता निर्माण में बदलने की जांच करती है। Google का कोड-समीक्षा मार्गदर्शन सिखाने को एक महत्वपूर्ण समीक्षा कार्य मानता है; GitLab की मेंटरशिप पेयरिंग, लक्ष्यों और निरंतर फीडबैक पर जोर देती है। मजबूत उत्तर शिक्षार्थी के निर्णय लेने के दायरे को बनाए रखते हुए प्रोडक्शन की रक्षा करते हैं।
संदर्भ उत्तर संरचना
STAR-L का उपयोग करें: Situation बदलाव और सीखने का संदर्भ देती है; Task सेवा के परिणाम और मेंटर की सीमा को बताता है; Action साझा विभाजन, रोलबैक की तैयारी, समीक्षा के छोटे कदम, अवलोकन और क्रमिक स्वामित्व को शामिल करता है; Result लॉन्च, घटना (incident), डिलीवरी-समय और क्षमता के प्रमाण देता है; Learning बताती है कि आपकी कोचिंग में क्या बदलाव आया।
महत्वपूर्ण विवरण
प्री-प्रोडक्शन जांच, दो-व्यक्ति अनुमोदन (two-person approval), कैनरी आकार, निगरानी और रोलबैक रिहर्सल जैसे गार्डरेल्स के नाम बताएं। बताएं कि टीम के साथी ने कौन से निर्णय लिए। केवल यह कहने के बजाय कि संबंधों में सुधार हुआ, स्वतंत्र बदलावों, कम समीक्षा लूप्स, ऑन-कॉल आत्मविश्वास, या बाद की मेंटरिंग को मापें।
सामान्य गलतियां
टीम के साथी के लिए खुद कोड लिखना; केवल उनकी कमजोरियों पर ध्यान केंद्रित करना; दबाव में गार्डरेल्स को छोड़ देना; सफलता का श्रेय खुद ले लेना; यह छोड़ देना कि फीडबैक ने व्यवहार को कैसे बदला; या मेंटरशिप को एकतरफा आदेशों के रूप में चित्रित करना।
मूल्यांकन रूब्रिक
मजबूत उत्तरों में सीखने के लक्ष्य, क्रमिक रूप से जिम्मेदारियां सौंपना, सुरक्षा गार्डरेल्स और सत्यापन योग्य परिणाम शामिल होते हैं। वे बताते हैं कि आपने कब हस्तक्षेप किया, आप कब पीछे हटे, और ज्ञान दस्तावेज़ीकरण या टीम प्रथाओं में कैसे शामिल हुआ। कमजोर उत्तर क्षमता वृद्धि के बिना केवल एक पेयरिंग सत्र का वर्णन करते हैं।
फॉलो-अप प्रश्न
क्या होगा यदि टीम का साथी किसी ऐसे डिज़ाइन पर जोर देता है जिसे आप जोखिम भरा मानते हैं?
मान्यताओं, जोखिमों और सत्यापन को एक साथ लिखें और सबसे छोटा प्रतिवर्ती (reversible) प्रयोग चलाएं। यदि यह अधिकार या जोखिम बजट से अधिक है, तो डिज़ाइन को चुपचाप बदलने के बजाय टीम समीक्षा पथ का उपयोग करें।
आपको कैसे पता चलेगा कि पीछे हटने का समय आ गया है?
देखें कि क्या टीम का साथी डिज़ाइन को समझा सकता है, मेट्रिक्स चुन सकता है, रोलबैक निष्पादित कर सकता है, और विसंगतियों पर प्रतिक्रिया दे सकता है। उन्हें कई कम जोखिम वाले कदमों का नेतृत्व करने दें, फिर अपनी स्वीकृतियों और संकेतों को कम करें।
मेंटरिंग ने टीम को कैसे प्रभावित किया?
बार-बार पूछे जाने वाले प्रश्नों को रनबुक, चेकलिस्ट या समीक्षा टेम्पलेट में बदलें, टीम के साथी को इसे बेहतर बनाने के लिए आमंत्रित करें, और ट्रैक करें कि क्या बाद के बदलाव तेज़, सुरक्षित हैं, या उनमें कम बार-बार मदद की आवश्यकता होती है।