एक पीआरडी कैसे लिखें जिसे डेवलपर्स शिप कर सकें

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

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

एक अच्छा उत्पाद आवश्यकता दस्तावेज़ टेम्पलेट एक काम अच्छी तरह से करता है: यह इंजीनियरों को प्रत्येक के लिए पीएम के पास वापस जाए बिना हजारों सूक्ष्म निर्णय लेने के लिए पर्याप्त संदर्भ देता है। यह "क्या" से पहले "क्यों" और "कैसे" से पहले "किसके लिए" का उत्तर देता है।

यह वह प्रारूप है जिसका हम उपयोग करते हैंसावीहमारे दौरानखोज एवं पीआरडी चरण. हमने इन दस्तावेज़ों से जटिल उत्पाद भेजे हैं, जिनमें शामिल हैंफेनाडो ए.आई, एक एजेंटिक प्लेटफ़ॉर्म जो टेक्स्ट प्रॉम्प्ट को कार्यशील वेब ऐप्स में बदल देता है, अब 50,000 उपयोगकर्ताओं को सेवा प्रदान कर रहा है।

आपके पीआरडी को जिन 7 अनुभागों की आवश्यकता है

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

1. समस्या कथन

किसी विशिष्ट व्यक्ति द्वारा विशिष्ट दर्द का अनुभव करने के संदर्भ में समस्या बताएं। इस खंड की संरचना में तीन प्रश्न हैं:

• यह समस्या किसे है?व्यक्तित्व का नाम बताएं. "50-200 ड्राइवरों वाली लॉजिस्टिक्स कंपनियों में संचालन प्रबंधक" उपयोगी है। "उपयोगकर्ता" नहीं है.
• यह कितना दर्दनाक है?लागत की मात्रा निर्धारित करें. समय बर्बाद हुआ, पैसा बर्बाद हुआ, त्रुटियाँ पैदा हुईं। "डिस्पैचर्स मैन्युअल रूप से मार्ग निर्दिष्ट करने में प्रति दिन 3 घंटे खर्च करते हैं" एक समस्या है जिसे हल किया जाना चाहिए। "रूट असाइनमेंट में सुधार किया जा सकता है" इंजीनियरों को कुछ नहीं बताता।
• अब वे क्या करें?वर्तमान समाधान का वर्णन करें. लोग आज इस समस्या का समाधान कर रहे हैं, भले ही उनका समाधान धीमा, मैन्युअल या त्रुटि-प्रवण हो। वर्कअराउंड को समझना इंजीनियरों को बताता है कि "काफ़ी अच्छा" कैसा दिखता है और बार कहाँ बैठता है।

समस्या कथन ही बुनियाद है. यदि इंजीनियरिंग समस्या को अच्छी तरह से समझती है, तो वे निर्णयों को आगे बढ़ाए बिना बेहतर डिज़ाइन ट्रेडऑफ़ बनाएंगे। यदि वे ऐसा नहीं करते हैं, तो विशिष्टता में प्रत्येक अस्पष्टता के लिए एक स्लैक संदेश की अपेक्षा करें।

2. सफलता मेट्रिक्स

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

• अस्पष्ट:"ऑनबोर्डिंग को तेज़ बनाएं"
• विशिष्ट:"मैन्युअल डेटा आयात चरण को समाप्त करके नए उपयोगकर्ता की ऑनबोर्डिंग को 3 दिन से घटाकर 2 घंटे करें"

विशिष्ट संस्करण इंजीनियरों को बताता है कि कहाँ ध्यान केंद्रित करना है। वे जानते हैं कि डेटा आयात कदम एक बाधा है। वे जानते हैं कि लक्ष्य 2 घंटे का है, 2 मिनट का नहीं, जिससे यह बदल जाता है कि कितना स्वचालन बनाने लायक है। 3 से 5 मेट्रिक्स शामिल करें. इससे अधिक और आप एक साथ बहुत सारे परिणामों के लिए अनुकूलन कर रहे हैं, जिसका अर्थ है कि आप उनमें से किसी के लिए भी अनुकूलन नहीं कर रहे हैं।

3. उपयोगकर्ता कहानियाँ व्यक्तित्व के आधार पर समूहीकृत

कहानियों को क्रिया करने वाले व्यक्ति के आधार पर समूहित करें, फीचर क्षेत्र के आधार पर नहीं। इससे इंजीनियर स्क्रीन के बजाय वर्कफ़्लो के बारे में सोचते रहते हैं। एक उपयोगकर्ता कहानी इस प्रारूप का अनुसरण करती है:"एक [व्यक्तित्व] के रूप में, मैं [कार्रवाई] करना चाहता हूं ताकि [परिणाम] हो।"

टैक्सी बुकिंग SaaS के लिए एक उदाहरण सेट:

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

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

4. दायरा सीमा (आप क्या नहीं बना रहे हैं)

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

स्पष्ट बहिष्करण लिखें:

• "v1 में कोई मोबाइल ऐप नहीं। केवल प्रतिक्रियाशील डिज़ाइन के साथ वेब।"
• "चरण 2 तक कोई बहुभाषी समर्थन नहीं।"
• "स्ट्राइप चेकआउट द्वारा प्रबंधित भुगतान पुनर्निर्देशित; कोई कस्टम भुगतान प्रवाह नहीं।"
• "एडमिन पैनल केवल आंतरिक है; किरायेदारों के लिए कोई व्हाइट-लेबलिंग नहीं है।"

प्रत्येक बहिष्करण उस वार्तालाप को रोकता है जो अन्यथा मध्य स्प्रिंट में होता जब कोई कहता है "रुको, मुझे लगा कि हम भी ऐसा ही कर रहे थे।" कठोर निर्णयों को पहले ही दस्तावेज़ में रखें, अब से तीन सप्ताह बाद स्टैंडअप में नहीं।

5. तकनीकी बाधाएँ

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

• एकीकरण:"आरएफसी के माध्यम से ग्राहक के मौजूदा एसएपी सिस्टम से इन्वेंट्री डेटा खींचना होगा।" इंजीनियरों को डेटा स्तर डिज़ाइन करने से पहले तृतीय-पक्ष निर्भरता के बारे में जानना आवश्यक है।
• प्रदर्शन:"डैशबोर्ड को डेटा की 10,000 पंक्तियों के साथ 2 सेकंड से कम समय में लोड होना चाहिए।" यह बाधा कैशिंग, पेजिनेशन और डेटा को पूर्व-एकत्रित करना है या नहीं, इसके बारे में निर्णय लेती है।
• अनुपालन:"सभी रोगी डेटा को आराम और पारगमन के दौरान एन्क्रिप्ट किया जाना चाहिए। HIPAA अनुपालन आवश्यक है।" यह एक वाक्य पूरे बुनियादी ढांचे के दृष्टिकोण को बदल देता है।
• डेटा निवास:"उपयोगकर्ता डेटा को EU डेटा केंद्रों के भीतर ही रहना चाहिए।" यह कुछ क्लाउड प्रदाताओं और क्षेत्रों को समाप्त कर देता है।

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

6. वायरफ्रेम या उपयोगकर्ता प्रवाह

वायरफ़्रेम को पॉलिश दिखने की आवश्यकता नहीं है। उन्हें स्पष्ट होने की जरूरत है. फिग्मा प्रोटोटाइप काम करता है, और फोन कैमरे से खींचा गया हाथ से खींचा गया आरेख भी काम करता है। जो बात मायने रखती है वह यह है कि दस्तावेज़ दिखाता है कि उपयोगकर्ता सिस्टम के माध्यम से स्क्रीन दर स्क्रीन कैसे चलता है।

कम से कम शामिल करें:

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

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

7. स्वीकृति मानदंड के साथ मील के पत्थर

प्रोजेक्ट को 2-से-4-सप्ताह के मील के पत्थर में विभाजित करें। प्रत्येक मील का पत्थर एक कामकाजी वेतन वृद्धि प्रदान करता है जिसे हितधारक देख और परीक्षण कर सकते हैं। प्रत्येक मील के पत्थर के लिए, स्वीकृति मानदंड लिखें जो द्विआधारी हैं: उत्तीर्ण या असफल, पूरा हुआ या नहीं।

• मील का पत्थर 1 (सप्ताह 1-2):उपयोगकर्ता साइन अप कर सकता है, लॉग इन कर सकता है और एक खाली डैशबोर्ड देख सकता है। स्वीकृति: प्रमाणीकरण प्रवाह ईमेल/पासवर्ड और Google OAuth के साथ काम करता है। डैशबोर्ड शून्य-स्थिति संदेश के साथ प्रस्तुत करता है।
• मील का पत्थर 2 (सप्ताह 3-4):उपयोगकर्ता प्रोजेक्ट बना और संपादित कर सकता है। स्वीकृति: सीआरयूडी संचालन कार्य। फॉर्म सत्यापन खाली फ़ील्ड और डुप्लिकेट नामों को पकड़ता है। डेटा पूरे सत्र में बना रहता है.
• मील का पत्थर 3 (सप्ताह 5-6):उपयोगकर्ता टीम के सदस्यों को आमंत्रित कर सकता है और भूमिकाएँ सौंप सकता है। स्वीकृति: आमंत्रण ईमेल 30 सेकंड के भीतर भेज दिया जाता है। आमंत्रित उपयोगकर्ता सही अनुमतियों के साथ प्रोजेक्ट को स्वीकार और एक्सेस कर सकता है।

मील के पत्थर पाठ्यक्रम सुधार के लिए प्राकृतिक जांच बिंदु बनाते हैं। यदि मील का पत्थर 2 में दो के बजाय चार सप्ताह लगते हैं, तो आप मील का पत्थर 3 शुरू होने से पहले जानते हैं। आप ओवररन कंपाउंड से पहले दायरा, समयरेखा या बजट समायोजित कर सकते हैं।

सामान्य गलतियाँ जो पीआरडी को तोड़ देती हैं

40 पन्ने लिखकर कोई नहीं पढ़ता

यदि आपका पीआरडी 10 पृष्ठों से अधिक लंबा है, तो इंजीनियर इसे हटा देंगे। वे पहले खंड को पढ़ेंगे, अपने स्प्रिंट से संबंधित भाग को छोड़ देंगे, और उस संदर्भ को भूल जाएंगे जो उनके काम को उत्पाद लक्ष्यों से जोड़ता है। एक संक्षिप्त दस्तावेज़ जो पढ़ा जाता है वह Google ड्राइव में मौजूद एक व्यापक दस्तावेज़ को मात देता है। गहराई चाहने वाले लोगों के लिए पूरक सामग्री (वायरफ्रेम, शोध डेटा, प्रतिस्पर्धी विश्लेषण) के लिंक के साथ 5 से 10 पृष्ठों का लक्ष्य रखें।

कार्यान्वयन विवरण निर्दिष्ट करना

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

कोई दायरा सीमा नहीं

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

कारण बताए बिना सुविधाओं को सूचीबद्ध करना

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

उत्पाद आवश्यकताएँ दस्तावेज़ टेम्पलेट

इस टेम्पलेट को कॉपी करें और इसे अपने अगले प्रोजेक्ट के लिए भरें। प्रत्येक अनुभाग में आपके लेखन का मार्गदर्शन करने के लिए संकेत शामिल हैं।

सावी डिस्कवरी और पीआरडी चरण में पीआरडी का उपयोग कैसे करता है

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

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

यहां बताया गया है कि हमारी डिस्कवरी और पीआरडी प्रक्रिया में क्या शामिल है:

• समस्या सत्यापन:हम आपकी धारणाओं को चुनौती देते हैं। यदि आप जिस समस्या का वर्णन कर रहे हैं वह आपके उपयोगकर्ताओं के अनुभव से मेल नहीं खाती है, तो गलत समाधान तेजी से बनाना सही समाधान धीमी गति से बनाने से भी बदतर है।
• कार्यक्षेत्र बातचीत:हम इस पर काम करते हैं कि v1 में क्या है और किस चीज़ का इंतज़ार करना चाहिए। के लिएफेनाडो ए.आई, इसका मतलब डेटाबेस स्कीमा और एपीआई मार्गों के साथ पूर्ण-स्टैक आउटपुट तक विस्तार करने से पहले सिंगल-पेज ऐप जेनरेशन से शुरुआत करना था। पहला संस्करण मूल मूल्य साबित हुआ; दूसरे संस्करण में इसका विस्तार किया गया।
• तकनीकी वास्तुकला स्केच:अनुमान लगाने से पहले, हम सिस्टम आर्किटेक्चर की रूपरेखा तैयार करते हैं। यह जल्दी ही लाल झंडे पकड़ लेता है: एकीकरण जटिलता, प्रदर्शन बाधाएं, अनुपालन आवश्यकताएं जो बुनियादी ढांचे के दृष्टिकोण को बदल देती हैं।
• निश्चित-मूल्य मील के पत्थर:पीआरडी मानचित्र में प्रत्येक मील का पत्थर एक निश्चित मूल्य पर होता है। इंजीनियरिंग शुरू होने से पहले आप जानते हैं कि आप प्रत्येक डिलिवरेबल के लिए कितना भुगतान कर रहे हैं। कोई प्रति घंटा बिलिंग आश्चर्य नहीं, कोई ओपन-एंडेड समयसीमा नहीं।

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

पीआरडी लिखना पहला इंजीनियरिंग निर्णय है

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

सात खंडों का प्रयोग करें. प्रत्येक में विशिष्ट रहें. जो आप नहीं बना रहे हैं उसे लिख लें। सफलता को संख्याओं से परिभाषित करें. और जब आप किसी ऐसे अनुभाग पर पहुँचते हैं जिसे आप नहीं भर सकते हैं, तो यह अधिक कोड लिखने से पहले अधिक शोध करने का संकेत है।

सही प्रश्नों का उत्तर देने वाली पांच पेज की पीआरडी गलत सवालों का जवाब देने वाली चालीस पेज की पीआरडी से बेहतर प्रदर्शन करेगी।

अक्सर पूछे जाने वाले प्रश्नों