Colay / मार्गदर्शिकाएँ
पांच हितधारकों को एक स्पष्ट पीआरडी दें, जो कई लेखन दृष्टिकोणों से सूचित हो
जब किसी उत्पाद की आवश्यकता कई हितधारकों के पास जाती है, तो समीक्षा शुरू होने से पहले ही अस्पष्ट शब्द अलग-अलग धारणाएं उत्पन्न कर सकते हैं। Colay फॉर्मूलेशन की तुलना करने और उत्पाद, डिज़ाइन, इंजीनियरिंग, QA और समर्थन से संबंधित प्रश्नों का पूर्वानुमान लगाने में मदद कर सकता है। लक्ष्य दृश्यमान खुले निर्णयों के साथ एक साझा आवश्यकता है। कई ड्राफ्ट तैयारी में सुधार कर सकते हैं; वे पहली समीक्षा पर अनुमोदन की गारंटी नहीं दे सकते।
वाक्य में सुधार करने से पहले दायरा तय करें
वर्तमान निर्णय को स्पष्ट शब्दों में लिखें: किसे क्या परिणाम चाहिए, कौन सी शर्तें लागू होती हैं, क्या दायरे से बाहर है और कौन से प्रश्न अनुत्तरित हैं। प्रस्तावित निर्णय को स्वीकृत निर्णय से अलग चिह्नित करें। अन्यथा एक सुंदर पुनर्लेखन चुपचाप एक सुझाव को एक आवश्यकता में बदल सकता है।
Atlassian PRD को उत्पाद के उद्देश्य, सुविधाओं, उपयोगकर्ता ज़रूरतों और सफलता मानदंडों का साझा विवरण बताता है। AI से अलग शब्दांकन मांगते समय यही साझा उद्देश्य सीमा बने। हितधारक के अनुसार स्पष्टीकरण उसी आवश्यकता को समझाए; उत्पाद के पांच अलग संस्करण न बनें जिन्हें एक साथ पूरा नहीं किया जा सकता।
एक काल्पनिक आवश्यकता जो सही प्रश्नों को आमंत्रित करती है
इस ड्राफ्ट के साथ एक काल्पनिक रिपोर्टिंग उत्पाद पर विचार करें: उपयोगकर्ताओं को आसानी से रिपोर्ट निर्यात करने में सक्षम होना चाहिए। स्वीकृत दायरा संकीर्ण है: कार्यक्षेत्र के मालिक वर्तमान में फ़िल्टर की गई तालिका को UTF-8 CSV फ़ाइल के रूप में निर्यात कर सकते हैं। अनुसूचित निर्यातों को बाहर रखा गया है. फ़ाइल-आकार सीमाएँ, खाली परिणाम और विफलता व्यवहार अभी भी अनिर्णीत हैं। ये उदाहरणात्मक आवश्यकताएं हैं, Colay सुविधाएं नहीं।
एक स्पष्ट मुख्य कथन यह है: एक कार्यक्षेत्र स्वामी सक्रिय तालिका फ़िल्टर से मेल खाने वाली पंक्तियों को UTF-8 CSV फ़ाइल के रूप में निर्यात कर सकता है। इसके आगे बहिष्करण और अनुत्तरित प्रश्न रखें। किसी मॉडल को लापता प्रदर्शन निर्णय को आविष्कृत अवधि से बदलने न दें।
| समीक्षक | प्रश्न उजागर करने के लिए | समीक्षा पैकेट में उपयोगी जोड़ |
|---|---|---|
| उत्पाद | इससे उपयोगकर्ता को कौन सा परिणाम मिलता है? | उद्देश्य और बहिष्कृत अनुसूचित-निर्यात उपयोग मामला |
| डिज़ाइन | मालिक वर्तमान फ़िल्टर को कैसे समझेगा? | खुले इंटरैक्शन प्रश्न, कोई आविष्कृत स्वीकृत डिज़ाइन नहीं |
| इंजीनियरिंग | किस सीमा और विफलता व्यवहार की आवश्यकता है? | स्पष्ट अनिर्णीत बाधाएँ |
| QA | कौन से अवलोकन बताए गए व्यवहार को प्रदर्शित करते हैं? | भूमिका, फ़िल्टर और फ़ाइल प्रारूप के लिए उदाहरण मामले |
| समर्थन | निर्यात विफल होने पर उपयोगकर्ता को क्या करना चाहिए? | मालिक के साथ एक अनुत्तरित पुनर्प्राप्ति प्रश्न |
आठ दृष्टिकोणों का अनुरोध करें, फिर उन्हें समेकित करें
चयनित उपलब्ध एजेंटों का उपयोग Ask separately में उनकी प्रारंभिक व्याख्याओं का निरीक्षण करने के लिए करें। आठ अनुरोधित दृष्टिकोणों को आठ स्वतंत्र मॉडलों की आवश्यकता नहीं है। कोई भी असहमति रखें जो वास्तविक उत्पाद विकल्प की ओर इशारा करती हो। उदाहरण के लिए, क्या एक खाली तालिका केवल-हेडर फ़ाइल उत्पन्न करती है, यह टीम का निर्णय है, न कि औसत निकालने की शैलीगत प्राथमिकता।
इस पीआरडी अंश की समीक्षा करें: [पाठ]। स्वीकृत निर्णय: [तथ्य]। प्रस्ताव: [अभी तक स्वीकृत नहीं]। दायरे से बाहर: [सूची]। खुले प्रश्न: [सूची]। उपयोगकर्ता परिणाम, संक्षिप्त दायरा, परीक्षण योग्यता, अनुमतियाँ, विफलता व्यवहार, प्रदर्शन, समर्थन आवश्यकताओं और कार्यकारी संदर्भ पर जोर देते हुए आठ फॉर्मूलेशन तैयार करें। प्रत्येक संस्करण को समान स्वीकृत दायरा बनाए रखना होगा। तकनीकी सीमाएँ न बनाएँ या खुले प्रश्नों को चुपचाप हल न करें। प्रत्येक संस्करण के लिए, उसके द्वारा उजागर की गई एक अस्पष्टता की पहचान करें। फिर एक आधिकारिक आवश्यकता, उदाहरण स्वीकृति मामले और सुझाए गए मालिकों के साथ एक निर्णय सूची प्रस्तावित करें। प्रत्येक नए सुझाव को प्रस्ताव के रूप में चिह्नित करें।
एक आवश्यकता के आधार पर समीक्षा पैकेट बनाएं
काल्पनिक निर्यात आवश्यकता के लिए, एक स्वीकृत मामला यह जांच कर सकता है कि मालिक को एक CSV प्राप्त होता है जिसमें सक्रिय फ़िल्टर से मेल खाने वाली पंक्तियाँ होती हैं। एक गैर-मालिक का अपेक्षित इंटरफ़ेस और एक खाली-परिणाम प्रतिक्रिया तब तक प्रश्न बनी रहती है जब तक कि टीम ने उन पर निर्णय नहीं ले लिया हो। यह अंतर एआई-जनित परीक्षण सूची को आकस्मिक दायरा बनने से रोकता है।
- एक मुख्य फॉर्मूलेशन चुनें और अनुमोदित निर्णय सूची के साथ इसकी तुलना करें। भूमिकाओं, स्थितियों, आउटपुट और बहिष्करणों की शब्दशः जाँच करें।
- पहले से लिए गए निर्णयों के लिए उदाहरण स्वीकृति मामले जोड़ें। अनसुलझे व्यवहार वाले मामलों को सहमत परीक्षणों के बजाय प्रश्नों के रूप में लेबल करें।
- शब्दावली संपादन को स्कोप प्रस्तावों से अलग करें। नई पंक्ति सीमा, अनुमति नियम या पुनर्प्राप्ति पथ को वाक्य बेहतर पढ़ने पर भी उत्पाद निर्णय की आवश्यकता होती है।
- अपनी मौजूदा समीक्षा प्रक्रिया के माध्यम से समीक्षकों को आधिकारिक पाठ, सार्थक परिवर्तन और मालिकों के साथ खुले प्रश्न भेजें।
केंद्रित वर्डिंग पास के लिए macOS शॉर्टकट का उपयोग करें
PRD खुला रखें और Colay ओवरले डिफ़ॉल्ट ⌘⇧K या सेटिंग्स में चुने शॉर्टकट से खोलें। केवल ज़रूरी अंश और अनुमति प्राप्त संदर्भ पेस्ट करें। ओवरले ड्राफ्टिंग कार्यक्षेत्र खोलता है; दस्तावेज़ खुद नहीं पढ़ता और PRD मंज़ूरी के लिए जमा नहीं करता।
समीक्षा के बाद, रिकॉर्ड करें कि किन टिप्पणियों के शब्दों में बदलाव आया है और किन टिप्पणियों से उत्पाद का निर्णय बदला है। आधिकारिक आवश्यकता और उसके उदाहरणों को एक साथ अद्यतन करें। संपूर्ण पीआरडी को बार-बार लिखने के बजाय, जरूरत पड़ने पर किसी कठिन अनुच्छेद पर संकेत का पुन: उपयोग करें। एक उपयोगी परिणाम टीम के लिए वास्तविक निर्णयों का एक छोटा, स्पष्ट सेट होता है।
आपके सवालों के जवाब
क्या प्रत्येक हितधारक को एक अलग पीआरडी प्राप्त करना चाहिए?
एक आधिकारिक आवश्यकता रखें। आप विभिन्न चिंताओं के लिए संक्षिप्त स्पष्टीकरण जोड़ सकते हैं, लेकिन उन्हें समान दायरे, शर्तों और निर्णयों का संदर्भ देना चाहिए।
क्या AI स्वीकृति मानदंड लिख सकता है?
यह आपूर्ति की गई आवश्यकताओं से उदाहरण प्रस्तावित कर सकता है। उनकी सावधानीपूर्वक समीक्षा करें: एक प्रशंसनीय मानदंड व्यवहार या ऐसी सीमा का परिचय दे सकता है जिसे किसी ने अनुमोदित नहीं किया है।
क्या होगा यदि सभी मॉडल सोचते हैं कि आवश्यकता स्पष्ट है?
फिर भी वास्तविक समीक्षकों से इसकी व्याख्या करने को कहें। मॉडल धारणाएं साझा कर सकते हैं, और टीम के पास कार्यान्वयन और व्यावसायिक संदर्भ है जो प्रॉम्प्ट में नहीं था।
स्रोत और कार्यप्रणाली
- Atlassian: how to create a PRD
पीआरडी के उद्देश्य और साझा भूमिका पर प्राथमिक मार्गदर्शन। निर्यात आवश्यकता, आठ-दृष्टिकोण प्रॉम्प्ट और समीक्षा पैकेट मूल उदाहरण हैं।
अपना अगला सवाल Colay में पूछें
एक मॉडल चुनें, Auto का उपयोग करें, या Consensus के साथ कई दृष्टिकोण एक साथ लाएं।