उपयोगकर्ता कहानी की परिभाषा में 'ऐसा इसलिए' का उद्देश्य क्या है?

Question

एक उपयोगकर्ता कहानी को एक वाक्य में परिभाषित किया जा सकता है जैसे:

As a <type of user> I want <some goal> so that <some reason>

केवल Google 'उपयोगकर्ता कहानी सूत्र' के लिए और पहले सभी लिंक इस सूत्र का प्रस्ताव करते हैं।

मेरा प्रश्न यह है कि उस खंड का उद्देश्य क्या है ? क्या यह प्रबंधकों के लिए है? क्या ऐसा है ताकि परियोजना प्रबंधक और हितधारक वस्तु की प्राथमिकता को बेहतर ढंग से समझ सकें? ऐसा क्यों है?

नोट: मैंने as a <type of user> I want <some goal>सूत्र के साथ काम किया है, और यह अच्छी तरह से काम करता है। मैंने इस प्रारूप को लागू करके अपने काम में कोई समस्या नहीं देखी है जो अधिक संक्षिप्त है।

Comments

एसई उपयोगकर्ता के रूप में, मैं एक गेंडा चाहता हूं।

— पिस्कोवर ने बिल्डिंग

Answer 1

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

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

हालांकि, आमतौर पर उन विशेषताओं को प्रदर्शित करना आसान होता है, क्योंकि आम तौर पर उन्हें प्रस्तावित करने वाले लोगों को उनके लिए एक ठोस व्यवसाय कारण की आपूर्ति करने में परेशानी होगी।

Popping The Why Stack नाम की एक तकनीक है , जहां आप "ऐसा" भाग लेते हैं, और "क्यों?" पूछते हैं, फिर आप उस उत्तर को लेते हैं, और "क्यों?" फिर से, पुनरावर्ती रूप से। "क्यों" रों, आप या तो "क्योंकि यह हमें पैसे बनाती हूँ" पर पहुंचे हैं, के बाद (चलो कहते हैं) तीन से पांच नहीं या "क्योंकि यह हमें पैसा बचा सकते हैं" (अधिमानतः बिल्कुल के एक सटीक विवरण के साथ कैसे है कि होने जा रहा है), तो यह सुविधा लागू करने लायक नहीं है।

कुछ लोगों का मानना यह इतना महत्वपूर्ण होने के लिए कि वे वास्तव में इसे रखा पहली कहानी टेम्पलेट में:

के लिए [...]

के तौर पर [...]

में चाहता हूं [...]

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

Comments

आपके द्वारा वर्णित पांच वॉयस ( en.wikipedia.org/wiki/5_Whys ) कहलाता है और यह आमतौर पर (सॉफ्टवेयर) इंजीनियरिंग क्षेत्रों में उपयोगी होता है, जिसमें सुधार की प्रक्रिया में गुणवत्ता इंजीनियरिंग से लेकर गुणवत्ता नियंत्रण तक की आवश्यकता होती है। यह शायद विकसित करने के लिए एक अच्छा कौशल है।

— थॉमस ओवेन्स

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

— मैथियास

Answer 2

"ऐसा है" लक्ष्य के लिए एक कारण प्रदान करता है।

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

कारण के लिए एक और उपयोग कहानियों को प्राथमिकता देना है। यदि आपके पास दो कहानियाँ हैं:

मैं पिछले महीने की बिक्री के आंकड़े प्रदर्शित करना चाहता हूं।
मैं संभावनाओं की सूची प्रदर्शित करना चाहता हूं।

लेकिन केवल एक करने के लिए संसाधन हैं - जो आप करते हैं? कारण के बिना आप सिर्फ अनुमान लगा रहे होंगे और आप समय पर सही वितरण नहीं करेंगे। हालांकि यह कम महत्वपूर्ण है क्योंकि ग्राहक आपको बता रहा है कि पहले क्या करना है, लेकिन कभी-कभी ऐसा नहीं होता है।

Comments

मुझे नहीं लगता कि यह कहानियों को प्राथमिकता देने के बारे में है, बल्कि गहरी आवश्यकताओं के बारे में है। ग्राहक द्वारा कहानियों को प्राथमिकता दी जानी चाहिए। हालांकि, "ताकि" का उपयोग अतिरिक्त आवश्यकताओं (कार्यात्मक, गैर-कार्यात्मक, और गुणवत्ता विशेषताओं) को अलग करने के लिए किया जा सकता है जो उपयोगकर्ता के लिए मूल्य जोड़ देगा। अतिरिक्त मूल्य के तरीकों में से एक है, मुझे लगता है कि अधिकतम मूल्य बढ़ाने की अवधारणा है।

— थॉमस ओवेन्स

@ थोमस - अच्छा बिंदु। मैं कारणों की अदला-बदली करूँगा - मुझे लगता है कि प्राथमिकता वहां है, लेकिन उतना महत्वपूर्ण नहीं है।

— ChrisF

Answer 3

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

उदाहरण:

एआई सभी कंपनी के कर्मचारियों की एक सूची से कर्मचारियों का चयन करने में सक्षम होना चाहता है

बीआई सभी कंपनी के कर्मचारियों की एक सूची से कर्मचारियों का चयन करने में सक्षम होना चाहता है ताकि मैं 5 साल पहले कंपनी छोड़ चुके लोगों को हटा सकूं।

(बी) एक मध्यम संगठन में भी कोई मतलब नहीं है, लेकिन आप उपयोगकर्ता की आवश्यकता को मान्य कर सकते हैं और ग्राहक को आवश्यकता को पूरा करने के लिए एक और तरीका प्रस्तावित कर सकते हैं।

Comments

+1 - यह समस्या की जड़ तक पहुंचने में मदद करता है; अन्यथा आपको सिर्फ एक संभावित समाधान दिया जाता है।

— जेएफओ