कार्यात्मक आवश्यकताओं को कैसे लिखें

नमस्कार, हेब्र!

आज हम इस बारे में बात करना चाहते हैं कि नए उत्पाद और सुविधाएँ बनाते समय हमारी उत्पाद टीम डेवलपर्स के लिए कार्यात्मक आवश्यकताओं की तैयारी कैसे करती है।

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



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

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

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

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

कार्यात्मक आवश्यकताएं: यह क्या है और उनकी आवश्यकता क्यों है

सबसे पहले, आइए देखें कि कार्यात्मक आवश्यकताएं क्या हैं।

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

कार्यात्मक आवश्यकताओं में आमतौर पर शामिल होते हैं:

• उपयोगकर्ता की कहानी - विकास टीम से आप क्या उम्मीद करते हैं
• मामलों का उपयोग करें - उपयोग परिदृश्य दिखाएं
• वायरफ्रेम - आपके विचार के लिए एक विज़ुअलाइज़ेशन टूल

आज हम उपयोगकर्ता कहानी और उपयोग के मामलों पर ध्यान केंद्रित करेंगे।

उपयोगकर्ता की कहानी

उपयोगकर्ता कहानी यह बताती है कि परिणाम प्राप्त करने के लिए उपयोगकर्ता एक निश्चित भूमिका क्या करता है, और इस कार्य को जीवन में लाने के लिए डेवलपर को क्या करने की आवश्यकता है।

आमतौर पर, एक टेम्पलेट का उपयोग किया जाता है:

एक </ b> नाम भूमिका के रूप में, मैं <उद्देश्य, क्रिया> करना चाहता हूं, ताकि <अपेक्षित परिणाम> करूं, <डेवलपर क्या करना चाहिए>

इस पद्धति के आवेदन के विभिन्न उदाहरण हैं। उदाहरण के लिए, यह इस तरह से Trello में काम करता है:



रिटेल रॉकेट में, हम टेबल का उपयोग करके Google डॉक्स में उपयोगकर्ता कहानियां बनाते हैं। यह विभिन्न टीमों के बीच संचार प्रक्रिया को सरल बनाने में मदद करता है, क्योंकि हर कोई टिप्पणी छोड़ सकता है और प्रतिक्रिया दे सकता है।

उदाहरण के लिए, ऑनलाइन स्टोर के लिए एनपीएस ट्रैकिंग कार्य इस तरह दिखता है:



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

मामलों का उपयोग करें

उपयोग किए गए मामलों का उपयोग उपयोगकर्ता के व्यवहार के चरण का वर्णन करता है जब एक विकसित उत्पाद के साथ बातचीत करते हैं।

उपयोगकर्ता का कार्य वह है जो उपयोगकर्ता अल्पकालिक लक्ष्यों को प्राप्त करने के लिए करता है।

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

आइए हमारी हाल ही में जारी की गई सुविधा का एक उदाहरण देखें - सामूहिक मेलिंग के लिए छवियों और फोंट की गैलरी ।

उपयोगकर्ता का लक्ष्य हमारे प्लेटफ़ॉर्म में छवियों को संग्रहीत करना और ईमेल अभियान बनाने के लिए उनका उपयोग करना है।

उपयोगकर्ता कार्य :

• चित्र अपलोड करें
• एक पत्र टेम्पलेट में छवियों को एम्बेड करें
• चित्र हटाएं

प्रत्येक कार्य के लिए आपको अपना स्वयं का उपयोग मामला लिखना होगा - उपयोगकर्ता इंटरफ़ेस के साथ कैसे इंटरैक्ट करता है, इसका विवरण।

उपयोग के मामलों के उदाहरण:

छवि अपलोड:

• ईमेल विपणनकर्ता आपके व्यक्तिगत रिटेल रॉकेट खाते में प्रवेश करता है
• ईमेल मार्केटर गैलरी अनुभाग खोलता है
• ईमेल विपणनकर्ता ड्रैग एंड ड्रॉप के माध्यम से या "सेलेक्ट फाइल्स" बटन पर क्लिक करके चित्र अपलोड करता है
• चित्र अपलोड किए गए हैं
• उपयोगकर्ता छवियों के सफल अपलोड की सूचना देखता है

चित्र हटाएं:

• उपयोगकर्ता छवि पर क्लिक करता है
• छवि बाहर खड़ी है
• चयनित छवि के बाहर के क्षेत्र पर क्लिक करके चयन को हटाया जा सकता है।
• उपयोगकर्ता तीन डॉट्स आइकन पर क्लिक करता है
• एक संदर्भ मेनू दिखाई देता है।
• उपयोगकर्ता इसमें "फ़ाइल हटाएं" लिंक का चयन करता है। यदि कई चित्र चुने गए, तो सभी हटा दिए जाएंगे।
• छवि हटा दी गई है

सभी उपयोग परिदृश्यों को एक ही तरह से चित्रित किया गया है, जो विकास को इस बात की स्पष्ट समझ देता है कि उत्पाद या विशेषताओं के साथ उपयोगकर्ता की बातचीत क्या दिखती है और इसके लिए क्या करने की आवश्यकता है।

कार्यात्मक आवश्यकताएं इतनी महत्वपूर्ण क्यों हैं

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

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

हमारे गैलरी का उदाहरण लें। यदि उत्पाद प्रबंधक सिर्फ एक गैलरी बनाने के काम के साथ आया था, तो फ़ाइल हटाने के बारे में एक बिंदु पर, डेवलपर्स को स्पष्ट करना होगा:

• क्या मुझे फ़ाइल को हटाने की आवश्यकता है?
• क्या यह एक मैनुअल विलोपन होगा या नई फाइलें डाउनलोड होने पर सबसे पुरानी फाइलें स्वचालित रूप से हटा दी जाएंगी, यदि भंडारण सीमा पार हो गई है?
• फ़ाइलों की सूची से निष्कासन है या क्या आपको फ़ाइल खोलने की आवश्यकता है
• फ़ाइल को स्थायी रूप से हटा दिया गया है या क्या फ़ाइलों के लिए एक टोकरी है जहां वे कुछ समय के लिए संग्रहीत हैं? यदि आपको एक टोकरी चाहिए, तो उसमें कितनी फाइलें संग्रहीत हैं?
• क्या बैच फ़ाइल विलोपन होना चाहिए या केवल एक ही हटाया जा सकता है?
• फ़ाइल को एक अलग आइकन (यह आइकन कैसा दिखता है?) या मेनू आइटम के माध्यम से हटा दिया जाता है (इसे क्या कहा जाएगा? यह कार्रवाई सूची में कहां स्थित है?)
• आदि

और आखिरकार, यह कार्य के बिंदुओं में से एक है, और पहले से ही बहुत सारे प्रश्न हैं। और प्रत्येक को खोजने के लिए दोनों तरफ समय और प्रयास की आवश्यकता होती है।

कार्यात्मक आवश्यकताएँ उत्पाद प्रबंधक को कार्य के भीतर इंटरफेस से उपयोगकर्ता इंटरैक्शन के सभी परिदृश्यों को स्पष्ट रूप से सोचने और समझने में मदद करती हैं।

अधिक सटीक रूप से कार्य को प्रस्तुत किया गया है और काम शुरू करने से पहले डेवलपर्स के पास जितना अधिक विवरण है, काम उतना ही अधिक कुशल है। कोई भी समय लंबे और कभी-कभी अर्थहीन संचार पर व्यर्थ नहीं जाता है। इस मामले में, सभी पक्षों को लाभ होता है: डेवलपर्स को स्पष्ट समझ मिलती है कि क्या करना है और कैसे करना है, और कार्य प्रदाता को ठीक उसी तरह से काम मिलता है जिस रूप में उसने इसकी कल्पना की थी।

और आप डेवलपर्स के लिए कार्यों का निर्माण कैसे करते हैं?

उत्पाद निदेशक गुलफ़िया कुरमंगलेवा