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

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

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

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

• अंकगणितीय संचालन का समर्थन करना।
• / से रूपांतरण में सहायक। यह दशमलव प्रणाली की कार्यक्षमता को प्रभावित करेगा। उदाहरण के लिए, आपको दशमलव से रूपांतरण का समर्थन करने की आवश्यकता है।
• तार्किक संचालन का समर्थन।

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

संभवतः यह इतना स्पष्ट है। वहाँ कुछ नुकसान छिपे हुए हैं। उनमें से सबसे पहले एक ट्रैकर में सुविधा अनुरोधों और उत्पाद आवश्यकताओं का प्रबंधन कर रहा है।

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

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

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



^{Zendesk प्रतिक्रिया पोर्टल}

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

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

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