एक उपयोगी समस्या विवरण उस दिखे अंतर को बताता है जो लोगों को पूरा करना है और आज वास्तव में जो होता है, उनके बीच है। प्रभावित समूह, कार्य या प्रक्रिया, वे स्थितियाँ जिनमें अंतर दिखता है, और उसका परिणाम शामिल करें। पसंदीदा समाधान और अपुष्ट कारण को विवरण से बाहर रखें ताकि उनकी जाँच हो सके।
हर संगठन के लिए समस्या विवरण का कोई एक अनिवार्य प्रारूप नहीं है। नीचे दिया प्रारूप लिखने का व्यावहारिक सहायक है। यह उत्पाद की खोज, परियोजना प्रस्ताव या टीम के पूर्वव्यापी में मिले बार-बार होने वाले मुद्दे के लिए काम आता है।
समाधान के प्रति प्रतिबद्ध होने से पहले समस्या को समझने का सिद्धांत GOV.UK की खोज संबंधी मार्गदर्शिका में भी मिलता है। इस लेख के उदाहरण और कार्यशाला मौलिक काल्पनिक उदाहरण हैं, ग्राहकों से प्राप्त परिणाम नहीं।
कॉपी करने योग्य समस्या विवरण का प्रारूप
इसे शुरुआती वाक्य के रूप में इस्तेमाल करें:
जब [संदर्भ] होता है, तो [प्रभावित समूह] को [कार्य या वांछित परिणाम] करना होता है, लेकिन [दिखा हुआ अंतर]। [स्रोत और अवधि] के साक्ष्य से [दायरा या आवृत्ति, यदि ज्ञात हो] दिखता है, जिसके कारण [समर्थित परिणाम] होता है।
फिर साक्ष्य पर एक छोटा नोट जोड़ें:
- ज्ञात: विवरण का समर्थन करने वाले अवलोकन।
- अज्ञात: वे प्रश्न जो व्याख्या बदल सकते हैं।
- दायरे से बाहर: पास की वे समस्याएँ जिन्हें यह प्रयास नहीं सुलझाएगा।
- सफलता का संकेत: कौन-सा दिखने वाला बदलाव मायने रखेगा।
हर खाली जगह में संख्या डालने की ज़िद न करें। “आवृत्ति अभी मापी नहीं गई” गढ़े हुए आधार से अधिक भरोसेमंद है। यदि स्रोत छोटा या असामान्य नमूना शामिल करता है, तो उसकी सीमा बताएँ। साक्ष्य बेहतर होने के साथ विवरण अधिक सटीक होना चाहिए।
विवरण में क्या शामिल होना चाहिए?
| तत्व | उपयोगी शब्दावली | जिस शब्दावली पर सवाल करें |
|---|---|---|
| प्रभावित लोग | नए खाता प्रशासक | हर कोई |
| कार्य | सहकर्मियों को आमंत्रित करना और उनकी पहुँच की पुष्टि करना | हमारे उत्पाद का बेहतर उपयोग करें |
| दिखा हुआ अंतर | लंबित और स्वीकार किए गए आमंत्रणों में अंतर नहीं कर पाते | डैशबोर्ड चाहिए |
| संदर्भ | कई आमंत्रण भेजने के बाद | हमेशा |
| परिणाम | स्थिति की पुष्टि के लिए सहायता से संपर्क करना | उत्पादकता में लाखों का नुकसान |
| साक्ष्य | बताई गई अवधि के मामलों की समीक्षा की | यह स्पष्ट है |
परिणाम गुणात्मक हो सकता है। उदाहरण के लिए, ऐसा काम करने के लिए सहायता माँगना जिसे उपयोगकर्ता स्वयं कर सकता है, तब भी महत्वपूर्ण है जब उसकी वित्तीय लागत ज्ञात न हो। हर असुविधा को राजस्व के नुकसान में न बदलें, जब तक बचाव योग्य तरीका न हो।
हल किया गया उदाहरण: अनुरोध से समस्या तक
काल्पनिक उदाहरण: एक परियोजना “आमंत्रण डैशबोर्ड बनाएँ” अनुरोध से शुरू होती है। यह समाधान का प्रस्ताव है। टीम उसे सही ढंग से बना सकती है और फिर भी गलत समस्या सुलझा सकती है।
खोज के दौरान टीम एक तय महीने के बारह सहायता संवादों की समीक्षा करती है और चार प्रशासकों को आमंत्रण का काम करते हुए देखती है। कई लोग पूछते हैं कि आमंत्रण पहुँचा या स्वीकार हुआ। ये अवलोकन जाँच योग्य समस्या का संकेत देते हैं, लेकिन सभी ग्राहकों में इसकी व्यापकता साबित नहीं करते।
बेहतर विवरण:
कई सहकर्मियों को आमंत्रित करने के बाद, खाता प्रशासकों को यह पुष्टि करनी होती है कि किसे कार्यस्थल तक पहुँच है, लेकिन आमंत्रण स्क्रीन लंबित और स्वीकार किए गए आमंत्रणों में अंतर नहीं बताती। सहायता संवाद और देखे गए चार सत्र दिखाते हैं कि प्रशासक कहीं और पुष्टि खोजते हैं, जिससे ऑनबोर्डिंग प्रक्रिया में एक मैनुअल जाँच जुड़ जाती है।
टीम दो अज्ञात बातें जोड़ती है: क्या यह अनिश्चितता देखे गए खाता प्रकारों के बाहर भी होती है, और क्या डिलीवरी विफलताएँ भी इसमें योगदान देती हैं। अब संभावित प्रतिक्रियाओं में अधिक स्पष्ट स्थिति लेबल, पुष्टि संदेश, गतिविधि दृश्य या आमंत्रण प्रक्रिया में बदलाव शामिल हैं। विवरण इनमें से किसी एक को समय से पहले नहीं चुनता।
तीन आम प्रारूप और उनका उपयोग कब करें
छोटा निर्णय विवरण: जब पाठकों को समस्या तुरंत समझनी हो, तो परियोजना संक्षेप में दो या तीन वाक्य लिखें। पूरा शोध रिकॉर्ड संलग्न करने के बजाय साक्ष्य का लिंक दें।
वर्तमान स्थिति, वांछित स्थिति, अंतर: जब किसी प्रक्रिया की स्पष्ट अपेक्षा हो, तो इसका उपयोग करें। आज क्या होता है बताएँ, आवश्यक स्थिति समझाएँ और अंतर बताएं। पुष्टि करें कि वांछित स्थिति वास्तव में आवश्यक है, केवल प्रबंधक की पसंद नहीं।
उपयोगकर्ता, कार्य, बाधा, परिणाम: जब उत्पाद या सेवा की समस्या किसी व्यक्ति के अनुभव से शुरू हो, तो इसका उपयोग करें। परिचालन सीमाएँ शामिल करें ताकि विवरण यह संकेत न दे कि केवल स्क्रीन बदलने से व्यापक प्रक्रिया ठीक हो जाएगी।
ये लिखने की संरचनाएँ हैं, प्रतिस्पर्धी पद्धतियाँ नहीं। निर्णय स्पष्ट करने वाला सबसे छोटा प्रारूप चुनें। यदि एक वाक्य पढ़ना कठिन हो जाए, तो अनुच्छेद और सहायक तालिका इस्तेमाल करें।
समस्या को रूप देने की 35 मिनट की कार्यशाला चलाएँ
समस्या का अनुभव करने वाले लोगों और साक्ष्य की व्याख्या कर सकने वालों को बुलाएँ। ऐसा व्यक्ति भी शामिल करें जो माने गए समाधान पर सवाल उठा सके। स्रोत सामग्री पहले भेजें और समझाएँ कि कौन-से दावे अभी अनिश्चित हैं।
- पाँच मिनट: चुपचाप पढ़ें। हर प्रतिभागी अवलोकनों, व्याख्याओं और प्रस्तावित समाधानों को अलग-अलग तरीके से चिह्नित करता है।
- आठ मिनट: अलग-अलग विवरण लिखें। सभी से उत्पाद, उपकरण या कार्यान्वयन का नाम लिए बिना अंतर बताने को कहें।
- दस मिनट: सीमाओं की तुलना करें। चर्चा करें कि कौन प्रभावित है, कौन-सा संदर्भ मायने रखता है और कौन-सी बात प्रयास के दायरे से बाहर है।
- सात मिनट: एक साझा संस्करण लिखें। विवादित दावों को अनिश्चितता नोट में रखें।
- पाँच मिनट: साक्ष्य का अगला कदम चुनें। ज़िम्मेदार व्यक्ति और वह निर्णय बताएँ जिसे साक्ष्य दिशा देगा।
उद्देश्य सभी का समान विश्वास नहीं है। उद्देश्य ऐसा जाँचने योग्य विवरण है जो दिखाए कि विश्वास कहाँ समाप्त होता है। यदि समूह प्रभावित जनसमूह पर सहमत न हो सके, तो अगला काम समाधान कार्यशाला के बजाय शोध हो सकता है।
छिपे समाधान और असमर्थित कारण जाँचें
“ग्राहकों को AI सहायक चाहिए” तकनीक तय करता है। पूछें कि कौन-सा काम कठिन है और लोग कौन-सा परिणाम पाना चाहते हैं। तकनीक विकल्पों की सूची में रह सकती है, बिना ज़रूरत की परिभाषा बने।
“टीम को परवाह नहीं, इसलिए अनुरोध देर से होते हैं” बिना साक्ष्य के प्रेरणा बताता है। इसे दिखने वाली स्थिति से बदलें, जैसे हैंडऑफ़ के बाद अनुरोध किसी को सौंपे नहीं गए, फिर जाँचें कि ऐसा क्यों होता है।
“संचार खराब है” कार्रवाई का मार्गदर्शन करने के लिए बहुत व्यापक है। पहचानें कि कौन-सी जानकारी, किन लोगों के बीच, किस निर्णय बिंदु पर और किस परिणाम के साथ है। उत्तर कई अलग समस्याएँ दिखा सकता है। उन्हें बाँटें, ऐसा विवरण न बनाएँ जिसका कोई मालिक न हो।
टीम के काम में बार-बार दिखने वाले अंतर खोजने का एक तरीका पूर्वव्यापी है। अवलोकन इकट्ठा करने के लिए सरल बोर्ड प्रारूप इस्तेमाल करें, फिर चुने मुद्दे को इस समस्या-रूप देने की प्रक्रिया में लाएँ।
तय करें कि विवरण तैयार है या नहीं
किसी ऐसे सहकर्मी से पढ़वाएँ जो परियोजना से परिचित न हो। क्या वह प्रभावित व्यक्ति पहचान सकता है, बता सकता है कि क्या गलत होता है, और दो अलग प्रतिक्रियाएँ सुझा सकता है? यदि वह केवल आपका पसंदीदा समाधान दोहरा सके, तो विवरण संशोधित करें।
फिर पता लगाने की क्षमता जाँचें: हर तथ्यात्मक दावे का संबंध साक्ष्य से होना चाहिए और हर धारणा को लेबल करना चाहिए। सहमत हों कि विवरण की दोबारा समीक्षा कब होगी। नया साक्ष्य समस्या को सीमित कर सकता है, कोई और कारण दिखा सकता है या यह बता सकता है कि आगे काम उचित नहीं।
बदलाव का परीक्षण होने के बाद, इसे पूर्वव्यापी सुधार प्रक्रिया से जाँचें। कार्यान्वयन पूरा होना, दिखे अंतर को बंद करने के बराबर नहीं है।
अक्सर पूछे जाने वाले प्रश्न
समस्या विवरण कितना लंबा होना चाहिए?
अक्सर विवरण के लिए छोटा अनुच्छेद पर्याप्त होता है। साक्ष्य, धारणाएँ और सीमाएँ सहायक नोट में रखें ताकि मुख्य विवरण सटीक होते हुए भी पढ़ने में कठिन न हो।
क्या समस्या विवरण में समाधान शामिल होना चाहिए?
समाधान अलग रखें, जब तक संदर्भ स्पष्ट रूप से सीमित कार्यान्वयन न माँगे। तब भी समस्या अलग से समझाएँ ताकि पाठक जाँच सकें कि चुनी गई प्रतिक्रिया उसे संबोधित करती है या नहीं।
यदि हमारे पास अभी मात्रात्मक साक्ष्य नहीं है तो क्या करें?
ठोस गुणात्मक अवलोकन इस्तेमाल करें और उनकी सीमाएँ बताएँ। आवृत्ति, लागत या अपेक्षित लाभ गढ़ने के बजाय छूटे हुए माप को अगले कदम के रूप में दर्ज करें।