दृष्टिकोण
स्टेकहोल्डर समीक्षा को निर्णयों को हल करना चाहिए
फीडबैक के लिए खुले अनुरोध विरोधाभासी संपादनों को आमंत्रित करते हैं। प्रत्येक समीक्षा को एक निर्णय, एक साक्ष्य मानक, और एक मालिक दें जो असहमति को हल कर सके।
आप स्टोरीबोर्ड को फीडबैक के लिए भेजते हैं। एक समीक्षक अधिक विवरण चाहता है। दूसरा कम पाठ चाहता है। कोई उद्देश्य को फिर से लिखता है। कोई और पूछता है कि यह कोर्स क्यों है।
उन सभी टिप्पणियों का महत्व हो सकता है। लेकिन वे विभिन्न निर्णयों से संबंधित हैं, और आपने उन्हें एक ही बातचीत में आमंत्रित किया है बिना यह समझाए कि आपको किस बातचीत की आवश्यकता है।
"कृपया समीक्षा करें" प्रभावी लगता है। यह समीक्षकों को अपने मानदंड बनाने के लिए छोड़ देता है।
मैं अनुरोध को अधिक विशिष्ट बनाऊंगा: क्या तय किया जाना चाहिए, कौन सा प्रमाण इसे सूचित करना चाहिए, और कौन निर्णय को बंद कर सकता है?
कृपया समीक्षा करें एक अधूरा अनुरोध है
एक उपयोगी समीक्षा काम के बारे में अनिश्चितता को कम करती है।
यदि एक समीक्षा बीस टिप्पणियाँ उत्पन्न करती है लेकिन परियोजना के केंद्रीय प्रश्न को अनसुलझा छोड़ देती है, तो हमारे पास अधिक गतिविधि है लेकिन आवश्यक रूप से अधिक दिशा नहीं है।
समीक्षक को निर्णय से मिलाएं
विभिन्न लोग विभिन्न चीजें जानते हैं। एक विषय विशेषज्ञ एक नियम की पुष्टि कर सकता है। एक फ्रंटलाइन कर्मचारी एक स्थिति की पहचान कर सकता है जो गलत लगती है। एक प्रक्रिया मालिक यह तय कर सकता है कि अपवाद को कैसे संभाला जाना चाहिए। एक प्रायोजक दायरे में परिवर्तन को मंजूरी दे सकता है।
ये योगदान मूल्यवान हैं, लेकिन ये एक-दूसरे के स्थान पर नहीं रखे जा सकते।
एक प्रायोजक की एक लंबे वीडियो की प्राथमिकता यह स्थापित नहीं करती कि शिक्षार्थियों को अधिक स्पष्टीकरण की आवश्यकता है। एक डिज़ाइनर की एक सरल परिदृश्य की प्राथमिकता एक अनसुलझी नीति प्रश्न को हल नहीं करती। एक नीति विशेषज्ञ की स्वीकृति हमें यह नहीं बताती कि क्या कोई व्यस्त शिफ्ट के दौरान संदर्भ का उपयोग कर सकता है।
काम भेजने से पहले, निर्णय का नाम दें और इसके लिए आवश्यक विशेषज्ञता को स्पष्ट करें। यदि समीक्षक इसे हल नहीं कर सकता है, तो उनसे उपयुक्त मालिक की पहचान करने के लिए कहें।
यह अप्रत्याशित निष्कर्षों का स्वागत करना भी आसान बनाता है। एक शिक्षार्थी जो इंटरफ़ेस का परीक्षण कर रहा है, एक नीति विरोधाभास का पता लगा सकता है। उस निष्कर्ष को नीति मालिक तक पहुंचना चाहिए न कि डिज़ाइन संपादनों की सूची में दबाया जाना चाहिए।
एक संक्षिप्त समीक्षा ब्रीफ लिखें
मैं लिंक या अटैचमेंट के ऊपर एक संक्षिप्त समीक्षा ब्रीफ रखूंगा। पांच पंक्तियाँ अक्सर पर्याप्त होती हैं:
- निर्णय: इस समीक्षा को क्या तय करना चाहिए?
- सामग्री: काम के किस भाग की समीक्षकों को जांच करनी चाहिए?
- मानदंड: इसे स्वीकार्य बनाने के लिए क्या चाहिए?
- स्वामित्व: कौन विशेषज्ञता में योगदान करता है, और कौन अंतिम निर्णय करता है?
- समय: प्रतिक्रिया कब आवश्यक है, और यदि निर्णय खुला रहता है तो क्या होता है?
पहले प्रोटोटाइप के लिए निर्णय यह हो सकता है कि गतिविधि लक्षित कार्य को दर्शाती है और इसे लक्षित उपयोगकर्ताओं के लिए समझना आसान है या नहीं। अंतिम रिलीज़ समीक्षा में कार्यक्षमता, सटीकता, पहुंच और तैयारी के बारे में अलग प्रश्न होते हैं।
तुरंत निर्णय के बाहर टिप्पणियों के लिए अलग से पहचानने के लिए कहें। इससे उन्हें एक स्थान मिलता है बिना हर अवलोकन को स्वचालित रूप से पूरे प्रोजेक्ट को फिर से खोलने दिए।
एक तात्कालिक सटीकता समस्या अभी भी ध्यान देने की आवश्यकता है। एक परिभाषित समीक्षा दायरा चिंताओं को व्यवस्थित करना चाहिए, न कि उन्हें दबाना।
एक निर्णय की समीक्षा करें न कि पूरे कोर्स की
एक काल्पनिक प्रोजेक्ट की कल्पना करें जो नए सेवा समन्वयकों को उपकरण मरम्मत अनुरोधों को रूट करने में मदद करता है। प्रोटोटाइप में एक इनटेक फॉर्म और एक छोटा रूटिंग प्रैक्टिस गतिविधि शामिल है। अनिश्चित मुद्दा यह है कि जब एक अनुरोध दो सेवा श्रेणियों में फिट होता है तो क्या करना है।
फीडबैक के लिए एक खुला अनुरोध फॉर्म लेबल, चित्रण, परिचय और प्रश्नों की संख्या में संपादन उत्पन्न कर सकता है। इनमें से कोई भी रूटिंग नियम को तय नहीं करता।
एक समीक्षा संक्षेप जिसे आप अनुकूलित कर सकते हैं
निर्णय: उन अनुरोधों के लिए रूटिंग लॉजिक को मंजूरी दें जो एक से अधिक श्रेणी में फिट होते हैं।
सामग्री: लिंक किए गए प्रोटोटाइप में तीन उदाहरण अनुरोधों और प्रस्तावित रूटों का निरीक्षण करें।
मानदंड: रूट को वर्तमान सेवा प्रक्रिया का पालन करना चाहिए, प्राप्तकर्ता मालिक की पहचान करनी चाहिए, और यह स्पष्ट करना चाहिए कि कब परामर्श की आवश्यकता है।
स्वामित्व: सेवा लीड अपवादों की पहचान करते हैं; प्रक्रिया मालिक संघर्षों को हल करता है; डिज़ाइनर उस निर्णय के बाद प्रैक्टिस को अपडेट करता है।
समय: कृपया सहमति की गई समीक्षा तिथि तक प्रतिक्रिया दें। यदि नियम अनसुलझा रहता है, तो हम प्रभावित प्रैक्टिस मामलों को रोकेंगे और रिलीज़ पर प्रभाव की पहचान करेंगे।
अब समीक्षक जानता है कि कौन-सी योगदान महत्वपूर्ण है। डिज़ाइनर के पास भी प्रभावित मामले को संपादित करना रोकने का एक कारण है जब तक कि शासकीय नियम स्पष्ट नहीं हो जाता।
एक बार जब नियम तय हो जाता है, तो एक अलग उपयोगकर्ता परीक्षण यह देख सकता है कि नए समन्वयक इसे समझते हैं और लागू करते हैं या नहीं। लॉजिक और अनुभव की उपयोगिता की स्वीकृति संबंधित हैं, लेकिन प्रत्येक को अपने स्वयं के प्रमाण की आवश्यकता होती है।
असहमति को जानकारी के रूप में मानें
जब समीक्षक असहमत होते हैं, तो हर सुझाव को एक समझौता स्क्रीन में संयोजित करने की प्रवृत्ति का विरोध करें।
दो विरोधाभासी टिप्पणियाँ दर्शकों, कार्य, या उपयोग की शर्तों के बारे में विभिन्न धारणाओं को प्रकट कर सकती हैं। प्रत्येक समीक्षक से पूछें कि वे किस स्थिति के लिए डिज़ाइन कर रहे हैं और वे किस जोखिम को रोकने की कोशिश कर रहे हैं।
रूटिंग उदाहरण में, एक लीड मान सकता है कि समन्वयक तुरंत एक वरिष्ठ सहयोगी से परामर्श कर सकता है। दूसरा एक शाम की शिफ्ट के बारे में सोच सकता है जिसमें सीमित कवरेज है। यह एक संदर्भ का अंतर है जिसे समर्थन चुनने से पहले हल करना महत्वपूर्ण है।
असहमति को एक प्रश्न के रूप में रिकॉर्ड करें। प्रक्रिया को किन शर्तों को कवर करने की आवश्यकता है? कौन सा स्रोत उत्तर को नियंत्रित करता है? निर्णय लेने का अधिकार किसके पास है?
यदि असहमति पसंद का मामला है, तो डिज़ाइन मानदंड पर लौटें। यदि यह एक आवश्यकता से संबंधित है, तो जिम्मेदार मालिक को शामिल करें। यदि यह उपयोगकर्ताओं के बारे में अनिश्चितता को दर्शाता है, तो एक प्रासंगिक अवलोकन एकत्र करें।
एक संशोधन तब उपयोगी होता है जब यह चिंता का उत्तर देता है। केवल एक टिप्पणी को गायब करने के लिए अधिक सामग्री जोड़ना असली मुद्दे को बिना छुए छोड़ सकता है।
लिखित रूप में लूप को बंद करें
समीक्षा के बाद, एक संक्षिप्त निर्णय रिकॉर्ड रखें। प्रश्न, सहमति की गई उत्तर, तर्क, स्रोत या प्रमाण, और मालिक को नोट करें। किसी भी धारणाओं की पहचान करें जिन्हें अभी भी जांचने की आवश्यकता है।
यह विशेष रूप से उपयोगी है जब कोई एक महीने बाद पूछता है कि एक अनुभाग क्यों हटाया गया या एक अपवाद को अलग तरीके से क्यों संभाला गया। आप कारण पर फिर से विचार कर सकते हैं बजाय इसके कि टिप्पणियों को फ़ाइलों में बिखेरकर फिर से बनाना पड़े।
एआई समीक्षा नोट्स को संक्षेपित करने और समान चिंताओं को समूहित करने में मदद कर सकता है। इसके संक्षेप को मूल के खिलाफ जांचें। एक उत्पन्न संक्षेप को सुझाव को स्वीकृति में बदलने या असहमति की आवश्यकता को मिटाने न दें।
चुप्पी सहमति का विश्वसनीय संकेत नहीं है। यदि एक आवश्यक मालिक ने प्रतिक्रिया नहीं दी है, तो निर्णय को खुला चिह्नित करें और परिणाम स्पष्ट करें। टीमें वृद्धि या प्रतिनिधि प्राधिकरण पर सहमत हो सकती हैं, लेकिन वह सहमति स्पष्ट होनी चाहिए।
समीक्षा की गुणवत्ता को इस बात से मापें कि क्या आवश्यक प्रश्न हल हो गए हैं और क्या सामग्री जोखिम स्पष्ट रूप से दिखाई दे रहे हैं। तेज़ टर्नअराउंड केवल तभी उपयोगी है जब निर्णय पर्याप्त रूप से सही हों ताकि काम को आगे बढ़ाया जा सके।
आपकी अगली समीक्षा अनुरोध पर, "मुझे बताएं कि आप क्या सोचते हैं" को एक विशिष्ट निर्णय और उसके मूल्यांकन के लिए मानदंड से बदलें। आप अपने समीक्षकों को एक स्पष्ट कार्य देंगे और अपने लिए उनके फीडबैक पर कार्रवाई करने के लिए एक स्पष्ट आधार देंगे।
समीक्षा को प्रोजेक्ट को एक ऐसा उत्तर छोड़ना चाहिए जिसका वह उपयोग कर सके।
संबंधित पढ़ाई
आपके SME ने आपको 74 स्लाइड दींहितधारक बातचीत शुरू करने के लिए प्रदर्शन समस्या को स्पष्ट करें और निर्णयों को जो सीखने का समर्थन करना है।
Learning Rewired Lab™
प्रोजेक्ट के निर्णयों को जुड़े रखें।
The Lab एक संपूर्ण पेशेवर कार्यक्षेत्र है जो एक शिक्षण अनुरोध को एक ठोस प्रदर्शन समाधान में बदलता है। अनुरोध को चुनौती दें, प्रणाली की जांच करें, प्रतिक्रिया डिज़ाइन करें, और एक जुड़े हुए प्रोजेक्ट में सबूत की योजना बनाएं।
अनुरोध को चुनौती दें, प्रणाली की जांच करें, और उत्पादन शुरू होने से पहले प्रदर्शन के लिए डिज़ाइन करें।
- एक जुड़े हुए प्रोजेक्ट रिकॉर्ड
- अनुरोध और प्रदर्शन निदान
- उत्पाद-उन्मुख शिक्षण उपकरण
- AI-सहायता प्राप्त डिज़ाइन कार्यप्रवाह
- व्यावहारिक कार्यस्थल अनुप्रयोग