उपयोगकर्ता अनुरोध और उत्पाद आवश्यकताएँ

उत्पाद प्रबंधक के काम के बारे में बहुत सारे लेख और किताबें, रणनीतिक सोच और नवाचार के मुद्दों पर विचार करें। बेशक, यह आधार है। मुझे दैनिक दिनचर्या के कार्यों पर ध्यान देना पसंद है। ऐसा एक काम उपयोगकर्ता के अनुरोधों और उत्पाद आवश्यकताओं के साथ है।

स्वयंसिद्ध यह है कि उपयोगकर्ताओं से कार्यक्षमता के लिए अनुरोध उत्पाद आवश्यकताओं नहीं हैं। एक अनुरोध को आसानी से कई आवश्यकताओं में विभाजित किया जा सकता है, और इसके विपरीत, एक आवश्यकता में उपयोगकर्ताओं के कई अनुरोध शामिल होते हैं।

आइए एक साधारण उदाहरण देखें - कैलकुलेटर एप्लीकेशन। आपको एक अनुरोध मिला है: बाइनरी नंबर सिस्टम के लिए समर्थन जोड़ें। यह कई उत्पाद आवश्यकताओं को जन्म दे सकता है।

• अंकगणितीय संचालन के लिए समर्थन।
• रूपांतरण का समर्थन। यह, संयोग से, मौजूदा दशमलव प्रणाली को प्रभावित करेगा। इंटरफेस में बटन बनाने के लिए यह न्यूनतम, आवश्यक होगा।
• तार्किक संचालन के लिए समर्थन।

जैसा कि आप देख सकते हैं, शुरू में उपयोगकर्ता ने समर्थन करने के लिए नहीं कहा था, उदाहरण के लिए, केवल तार्किक संचालन। एक पूरे के रूप में संख्या प्रणाली के लिए अनुरोध, लेकिन इसमें कई आवश्यकताएं शामिल हैं।

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

कार्य का दूसरा पहलू सीधे आवश्यकताओं को इकट्ठा करना है। एक तरीका उन्हें तकनीकी सहायता के माध्यम से प्राप्त करना है। यह एक अच्छी प्रक्रिया है, जिसके परिणामस्वरूप आपको सार को फ़िल्टर करने का अनुरोध मिलता है। दूसरी ओर, यह आपके उपयोगकर्ताओं के लिए अपारदर्शी है। कई लोग यह नहीं देख सकते हैं कि ऐसा अनुरोध था, और बार-बार एक्सेस किया जाता है।

इसलिए, विक्रेता, विशेष रूप से क्लाउड समाधान बनाने वाले, प्रतिक्रिया प्राप्त करने के लिए पोर्टल का उपयोग कर सकते हैं।



^{Zendesk प्रतिक्रिया फोरम}

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

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

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