AI वापरून प्रॉडक्ट रिक्वायरमेंट्स डॉक कसा लिहायचा (मोफत टेम्पलेट)

प्रॉडक्ट रिक्वायरमेंट्स डॉक (PRD) म्हणजे तुम्ही काय बांधत आहात, ते कोणासाठी आहे, त्याने काय करायला हवे आणि ते योग्य काम करत आहे हे कसे कळेल, याचे छोटे आणि साध्या भाषेतील वर्णन. AI मुळे तो लिहिणे खूप वेगवान होते: तुम्ही त्याला ढोबळ नोट्स दिल्या की तो त्यांचे संरचित विभाग, user stories आणि एज केसेस तयार करतो. AI करू शकत नाही असे निर्णय तुम्ही द्यायचे असतात: ध्येय, व्याप्ती आणि काय वगळले जाते, आणि AI ने जोडलेल्या गोष्टी तपासायच्या असतात.

या मार्गदर्शकात PRD मध्ये काय असावे, कोणत्याही AI असिस्टंटसह तो मसुदा कसा तयार करायचा, प्रत्येक विभागासाठी प्रॉम्प्ट्स आणि कॉपी करता येणारा भरण्याचा टेम्पलेट दिला आहे.

PRD कशासाठी आहे (आणि कशासाठी नाही)

PRD चार प्रश्नांची उत्तरे देतो:

आपण हे का बांधत आहोत? कोणती समस्या, कोणासाठी?
पहिल्या आवृत्तीत त्याने नेमके काय करायला हवे?
त्यात अजून काय नसेल?
ते यशस्वी झाले हे आपल्याला कसे कळेल?

हा तांत्रिक डिझाइन नाही. कोणता डेटाबेस किंवा फ्रेमवर्क वापरायचा हे त्यात सांगितलेले नसते, ते गरज असल्यास वेगळ्या तांत्रिक स्पेकमध्ये असते. हा मार्केटिंग ब्रीफ किंवा बिझनेस प्लॅनही नाही. PRD प्रॉडक्टच्या वर्तनापुरता मर्यादित ठेवल्याने तो सर्वांसाठी उपयुक्त राहतो: डिझायनर, डेव्हलपर, मंजुरी देणारे स्टेकहोल्डर किंवा PRD ला कोडमध्ये बदलणारा AI अॅप बिल्डर.

PRD कोणाला हवा

सोलो फाउंडर्स ज्यांना स्कोप क्रीप सुरू होण्यापूर्वीच थांबवायचा आहे.
छोट्या टीम्स ज्यांना "आपण जे ठरवले ते" एकाच ठिकाणी हवे आहे.
फ्रीलान्सर किंवा एजन्सी नेमणारे कोणीही, कारण स्पष्ट PRD मुळे अंदाजपत्रके अधिक स्पष्ट मिळतात. पहा डेव्हलपर नेमा किंवा AI सह बांधा.
AI सह बांधणारे कोणीही, कारण PRD मधील user stories आणि डेटा यादी असंरचित इच्छायादीपेक्षा चांगले प्रॉम्प्ट्स बनवते.

AI कशात चांगला आहे आणि कशात नाही

काम	AI चांगले करतो	जबाबदारी तुमची
गोंधळलेल्या नोट्सचे विभाग करणे	होय	काहीही बनवले गेले नाही हे तपासणे
सुसंगत स्वरूपात user stories लिहिणे	होय	पहिल्या आवृत्तीत कोणत्या stories असतील ते ठरवणे
एज केसेस यादी करणे (रिकामी स्थिती, एरर, परवानग्या)	होय, अनेकदा थकलेल्या माणसापेक्षा चांगले	कोणत्या महत्त्वाच्या आहेत ते ठरवणे
यशाचे मेट्रिक्स सुचवणे	वाजवी पर्याय देतो	प्रत्यक्षात मोजता येतील असे निवडणे
तुमचे वापरकर्ते, बाजार किंवा बजेट जाणणे	नाही	हे सर्व तुम्हीच
काय वगळायचे ते ठरवणे	नाही, तो गोष्टी कमी करण्यापेक्षा जोडतो	हे सर्व तुम्हीच

सर्वात सामान्य चूक म्हणजे वरील दुसऱ्या-शेवटच्या ओळीचे उलटे रूप: AI आत्मविश्वासाने रिकाम्या जागा तुमच्या वापरकर्त्यांबद्दलच्या संभाव्य अंदाजांनी भरतो. वापरकर्ते, बाजाराचा आकार किंवा वर्तन याबद्दल तो जे लिहितो त्याला तथ्य न मानता पडताळणीचा प्रश्न माना.

पायरी 1: तुम्हाला काय माहिती आहे ते टाका

कोणताही प्रॉम्प्ट देण्यापूर्वी ढोबळ नोट्स लिहा. बुलेट पॉइंट्स चालतील. यात हे समाविष्ट करा:

समस्या, एक-दोन वाक्यांत, वापरकर्त्याच्या दृष्टीकोनातून.
ती कोणाला आहे. नेमके लिहा: "१०-४० क्लायंट असणारे फ्रीलान्स बुककीपर", "छोटे व्यवसाय" नाही.
ते आज त्याऐवजी काय करतात (स्प्रेडशीट, ईमेल, नापसंत असलेले एखादे टूल).
पहिली आवृत्ती यशस्वी ठरवणारा एकच परिणाम.
तुम्ही काय करणार नाही हे आधीच माहीत असलेल्या गोष्टी.
कठोर मर्यादा: डेडलाइन, बजेट, फोनवर चालले पाहिजे, तुम्ही आधीच वापरत असलेल्या टूलशी जोडले गेले पाहिजे.

ज्यांना ही समस्या आहे अशा कोणाशी तुम्ही बोलला नसाल, तर आधी ते करा. अॅप कल्पना कशी तपासायची यात व्यावहारिक पद्धत आहे. अंदाजांवर बांधलेला PRD म्हणजे चांगल्या स्वरूपात लिहिलेला अंदाजच.

पायरी 2: AI कडून पहिला मसुदा मागा

तुमच्या नोट्स पेस्ट करा आणि ठराविक रचनेत मसुदा मागा. चांगले काम करणारा प्रॉम्प्ट:

ही माझ्या एका प्रॉडक्टबद्दलची नोट्स आहे. ती याच विभागांसह प्रॉडक्ट रिक्वायरमेंट्स डॉकमध्ये बदला: सारांश, समस्या, वापरकर्ते, ध्येय आणि यशाचे मेट्रिक्स, स्कोप (आत / बाहेर), acceptance criteria असलेल्या user stories, डेटा, परवानग्या, एज केसेस, खुले प्रश्न. दोन पानांपेक्षा कमी ठेवा. वापरकर्ते किंवा बाजाराबद्दल तथ्ये बनवू नका. माझ्या नोट्समध्ये जे नाही ते खुले प्रश्न विभागात प्रश्न म्हणून लिहा.

शेवटची सूचना महत्त्वाची आहे. माहिती नसलेल्या गोष्टी भरण्याऐवजी "खुले प्रश्न" मध्ये टाकण्यास सांगितल्याने अधिक प्रामाणिक मसुदा मिळतो.

पायरी 3: प्रत्येक विभाग घट्ट करा

मसुदा एक-एक विभाग करून पहा. हे फॉलो-अप प्रॉम्प्ट्स मदत करतात:

समस्या आणि वापरकर्ते

समस्येचे विधान वापरकर्त्याच्या दृष्टीकोनातून एक-दोन वाक्यांत पुन्हा लिहा. उपायाचे शब्द नकोत.

समस्येच्या विधानात तुमच्या प्रॉडक्टचा उल्लेख असेल, तर ते समस्या नव्हे तर उपाय वर्णन करत आहे.

ध्येय आणि यशाचे मेट्रिक्स

या PRD साठी पहिल्या आवृत्तीचे तीन यशाचे मेट्रिक्स सुचवा जे मला लहान वापरकर्ता गटासह पहिल्या महिन्यात मोजता येतील. प्रत्येकासाठी ते कसे मोजाल ते सांगा.

एक किंवा दोन निवडा. "वीस बुककीपर महिनाभर आठवड्याला वापरतात" हे मोजता येण्याजोगे आहे. "उत्पादकता सुधारणे" नाही.

स्कोप

या PRD मधील अशा सर्व गोष्टी यादी करा ज्या मुख्य प्रवाह न मोडता नंतरच्या आवृत्तीत हलवता येतील.

AI टूल्स फीचर्स जोडतात. हा प्रॉम्प्ट त्यांना उलट करायला लावतो. कठोर राहा: बहुतेक पहिल्या-आवृत्तीचे PRD खूप मोठे असतात. MVP म्हणजे काय हे स्पष्ट करते की लहान पहिल्या आवृत्त्या तुम्हाला अधिक शिकवतात.

User stories आणि acceptance criteria

प्रत्येक आवश्यकता user story म्हणून लिहा ("एक [वापरकर्ता] म्हणून, मला [कृती] करायची आहे जेणेकरून [परिणाम] मिळेल") आणि Given / When / Then स्वरूपात दोन ते चार acceptance criteria द्या.

Acceptance criteria ही नंतर तपासायची चेकलिस्ट आहे. "Given एक बुक केलेला स्लॉट, when दुसरा क्लायंट कॅलेंडर पाहतो, then तो स्लॉट दिसत नाही" तपासता येते. "बुकिंग छान चालते" तपासता येत नाही.

एज केसेस आणि परवानग्या

प्रत्येक user story साठी रिकामा डेटा, चुकीचे इनपुट, हळू किंवा अयशस्वी नेटवर्क विनंती आणि ज्याला प्रवेश नसावा असा वापरकर्ता असेल तेव्हा काय होते ते यादी करा.

येथेच AI फायदेशीर ठरतो. लोक विसरतात अशा रिकाम्या स्थिती आणि परवानगीतील त्रुटी ओळखण्यात तो वेगवान आहे.

पायरी 4: संशयी नजरेने पुनरावलोकन करा

सर्व काही पुन्हा एकदा वाचा आणि तपासा:

वापरकर्त्यांबद्दल प्रत्येक दावा तुमच्याकडून किंवा संशोधनातून आला आहे, AI कडून नाही.
स्कोप "बाहेर" किमान "आत" इतका लांब आहे.
प्रत्येक user story ला acceptance criteria आहेत जे कोणी तुम्हाला न विचारता तपासू शकेल.
डेटा विभाग अॅप ठेवत असलेला प्रत्येक प्रकारचा रेकॉर्ड आणि तो कोण पाहू शकतो ते यादी करतो.
खुल्या प्रश्नांना मालक आणि तारीख आहे.
तांत्रिक काहीही खरी मर्यादा असल्याशिवाय आत आलेले नाही ("ऑफलाइन चालले पाहिजे" ही आवश्यकता आहे; "Redis वापरा" नाही).

मग तो ज्याने हे उत्पादन वापरायचे किंवा बांधायचे आहे अशा एका व्यक्तीला दाखवा आणि काय अस्पष्ट आहे ते विचारा. त्यांचे प्रश्न म्हणजेच उणिवा.

भरण्याचा PRD टेम्पलेट

हे डॉकमध्ये कॉपी करा आणि कंसातील भाग बदला. जो विभाग खरोखर लागू नाही तो काढून टाका.

प्रॉडक्टचे नाव: [नाव] मालक: [निर्णयांसाठी जबाबदार व्यक्ती] स्थिती: [मसुदा / पुनरावलोकनात / मान्य] — शेवटचे अद्यतन: [तारीख]

1. सारांश

[दोन-तीन वाक्ये: हे काय आहे, कोणासाठी आहे आणि मुख्य परिणाम काय.]

2. समस्या

[वापरकर्त्याच्या दृष्टीकोनातून समस्या. ते आज काय करतात आणि त्याला त्रास का होतो.]

3. वापरकर्ते

वापरकर्ता प्रकार	त्यांना काय हवे आहे	ते किती वेळा वापरतील
[उदा. मालक]	[गरज]	[रोज / आठवड्याला]
[उदा. क्लायंट]	[गरज]	[क्वचित]

4. ध्येय आणि यशाचे मेट्रिक्स

ध्येय: [पहिल्या आवृत्तीने साध्य केला पाहिजे असा परिणाम]
मेट्रिक: [ते कसे मोजाल आणि लक्ष्य किती]
नॉन-ध्येय: [लोक गृहीत धरू शकतील अशी गोष्ट, जी ही आवृत्ती करत नाही]

5. स्कोप

पहिल्या आवृत्तीत:

[फीचर]
[फीचर]

पहिल्या आवृत्तीत नाही:

[फीचर, आणि ते का थांबू शकते]
[फीचर, आणि ते का थांबू शकते]

6. User stories

Story 1: एक [वापरकर्ता] म्हणून, मला [कृती] करायची आहे जेणेकरून [परिणाम] मिळेल.

Given [संदर्भ], when [कृती], then [परिणाम].
Given [संदर्भ], when [कृती], then [परिणाम].

Story 2: एक [वापरकर्ता] म्हणून, मला [कृती] करायची आहे जेणेकरून [परिणाम] मिळेल.

Given [संदर्भ], when [कृती], then [परिणाम].

7. डेटा

रेकॉर्ड	मुख्य फील्ड्स	कोण तयार करू शकतो	कोण पाहू शकतो
[उदा. बुकिंग]	[तारीख, वेळ, क्लायंट, सेवा]	[क्लायंट]	[मालक, तो क्लायंट]

8. परवानग्या

[कोण लॉगिन करू शकतो, कोणत्या भूमिका आहेत आणि प्रत्येक भूमिका काय पाहू आणि बदलू शकते.]

9. एज केसेस

[रिकामी स्थिती: अजून डेटा नसताना काय दिसते]
[चुकीचे इनपुट: चुकीचा ईमेल किंवा गहाळ फील्ड असताना काय होते]
[प्रवेश: कोणी उघडू नये अशा पेज उघडल्यास काय होते]

10. एकत्रीकरण आणि मर्यादा

[पेमेंट्स, ईमेल, विद्यमान टूल्स, डेडलाइन, बजेट, ज्या उपकरणांवर चालायला हवे.]

11. खुले प्रश्न

प्रश्न	मालक	कधीपर्यंत ठरवायचे
[प्रश्न]	[नाव]	[तारीख]

PRD ते प्रॉम्प्ट्स

चांगला PRD AI अॅप बिल्डरसाठीच्या प्रॉम्प्ट्समध्ये जवळजवळ थेट रूपांतरित होतो:

सारांश, वापरकर्ते आणि डेटा टेबल तुमचा पहिला प्रॉम्प्ट होतो.
प्रत्येक user story एक फॉलो-अप प्रॉम्प्ट होतो.
प्रत्येक acceptance criterion तुम्ही प्रीव्ह्यूमध्ये तपासता.
"पहिल्या आवृत्तीत नाही" यादी म्हणजे अजून न मागण्याची गोष्ट.

PRD पूर्ण पेस्ट करून सर्व काही एकदम मागण्यापेक्षा एका वेळी एक story बांधणे आणि पुढे जाण्यापूर्वी तिचे acceptance criteria तपासणे अधिक विश्वासार्ह आहे. AI अॅप बिल्डरसाठी प्रॉम्प्ट्स कसे लिहायचे प्रॉम्प्टिंगच्या बाजूची अधिक माहिती देते.

सामान्य चुका

उपायाला समस्या म्हणून लिहिणे. "वापरकर्त्यांना डॅशबोर्ड हवा" हा उपाय आहे. "मालकांना प्रत्येक इनव्हॉईस उघडल्याशिवाय कोणते थकीत आहेत ते दिसत नाही" ही समस्या आहे.
"स्कोप बाहेर" विभाग नसणे. तो नसेल तर प्रत्येक संभाषणात स्कोप पुन्हा उघडला जातो.
AI ला वापरकर्ते बनवू देणे. AI ने बनवलेले पर्सोना खरे वाटतात, पण ते खरे नसतात.
न मोजता येणारे मेट्रिक्स. ते मोजण्याचा मार्ग नसेल तर ते मेट्रिक नाही.
कधीच अद्ययावत न करणे. तुम्ही बांधत आहात त्याशी जुळत नसलेला PRD काहीच नसण्यापेक्षा वाईट आहे. "शेवटचे अद्यतन" तारीख ठेवा आणि निर्णय बदलल्यावर ती बदला.

Mythex सह PRD वापरणे

Mythex मध्ये बांधत असाल, तर तुमचा PRD थेट चॅटमध्ये पेस्ट करू शकता. PRD साठी Plan मोड चांगला आहे: एजंट तो वाचतो, एक दृष्टिकोन आणि चरणांची चेकलिस्ट सुचवतो जी तुम्ही प्लॅन टॅबमध्ये पाहू शकता, आणि तुम्ही Build दाबेपर्यंत फाइल्स बदलायला सुरुवात करत नाही. जे भाग नेहमी लागू व्हायला हवेत, जसे प्रेक्षक, ब्रँड आणि नियम, ते प्रोजेक्ट नॉलेज म्हणूनही जतन करू शकता, म्हणजे प्रत्येक चॅटमध्ये ते पुन्हा लिहावे लागत नाही. Build, Plan आणि Ask मोड्स चॅट डॉक्स मध्ये स्पष्ट केले आहेत, आणि संपूर्ण दस्तऐवज लिहिण्यापूर्वी पहिली आवृत्ती कशी दिसू शकते ते पाहण्यासाठी टेम्पलेट्स जलद मार्ग आहेत.

प्रश्न

प्रॉडक्ट रिक्वायरमेंट्स डॉक म्हणजे काय?

PRD म्हणजे एक छोटा दस्तऐवज जो सांगतो की एखादे प्रॉडक्ट किंवा फीचरने काय करायला हवे, ते कोणासाठी आहे आणि ते योग्य काम करत आहे हे तुम्हाला कसे कळेल. तो समस्या आणि अपेक्षित वर्तन सांगतो, कोड नाही, त्यामुळे डिझायनर, डेव्हलपर आणि AI टूल्स सर्व त्यावरून बांधणी करू शकतात.

AI माझ्यासाठी PRD लिहू शकते का?

तुमच्या नोट्सचा संरचित मसुदा तयार करणे, गहाळ विभाग शोधणे आणि एज केसेस सुचवणे यात AI चांगले आहे. तुमचे वापरकर्ते, मर्यादा किंवा प्राधान्यक्रम AI ला माहिती नसतात, त्यामुळे ध्येय, व्याप्ती आणि काय वगळायचे हे तुम्हीच ठरवता, आणि AI ने जोडलेली प्रत्येक आवश्यकता तुम्ही तपासता.

PRD किती मोठा असावा?

तो शक्य तितका छोटा असावा, पण कोण, काय, का आणि ते कसे मोजायचे हे उत्तर देणारा असावा. अॅपच्या पहिल्या आवृत्तीसाठी साधारणपणे एक ते तीन पाने पुरेशी असतात. मोठे दस्तऐवज अनेकदा वाचले जात नाहीत आणि महत्त्वाचे निर्णय लपवतात.

AI अॅप बिल्डरने बांधणी करत असल्यास मला PRD लागतो का?

औपचारिक PRD लागत नाही, पण छोटा PRD AI बिल्डर्सना अधिक विश्वासार्ह बनवतो. PRD मधील user stories आणि डेटा यादी जवळजवळ थेट चांगल्या प्रॉम्प्ट्समध्ये रूपांतरित होते, आणि स्कोप विभाग एकाच वेळी सर्वकाही मागण्यापासून थांबवतो.