AI ဖြင့် Product Requirements Doc ရေးနည်း (အခမဲ့ ပုံစံ)

Product requirements document (PRD) ဆိုသည်မှာ သင်တည်ဆောက်နေသည့်အရာ၊ ဘယ်သူအတွက်လဲ၊ ဘာလုပ်ရမလဲ၊ အလုပ်ဖြစ်ကြောင်း ဘယ်လိုသိမလဲ ကို ရိုးရှင်းသော စကားဖြင့် ဖော်ပြသော တိုတောင်းသည့် စာရွက်စာတမ်း ဖြစ်သည်။ AI ဖြင့် ၎င်းကို ရေးခြင်းသည် အလွန်မြန်ဆန်သည်။ သင်က ကြမ်းတမ်းသော မှတ်စုများ ပေးလိုက်ရုံဖြင့် AI က ၎င်းတို့ကို ပုံစံကျသော အပိုင်းများ၊ user story များနှင့် edge case များအဖြစ် ပြောင်းပေးနိုင်သည်။ သင့်တာဝန်မှာ AI မဆုံးဖြတ်နိုင်သော ဆုံးဖြတ်ချက်များ ဖြစ်သည့် ရည်မှန်းချက်၊ နယ်ပယ်နှင့် မပါရန်အရာများကို ပေးရန်နှင့် AI ထည့်သွင်းသည်များကို စစ်ဆေးရန် ဖြစ်သည်။

ဤလမ်းညွှန်တွင် PRD တွင် ပါရမည့်အရာများ၊ မည်သည့် AI assistant နှင့်မဆို ၎င်းကို အဆင့်ဆင့် draft ရေးနည်း၊ အပိုင်းတစ်ခုစီအတွက် prompt များနှင့် ကော်ပီကူးယူနိုင်သော ဖြည့်ရန်ပုံစံတို့ကို ဖော်ပြထားသည်။

PRD ၏ ရည်ရွယ်ချက် (နှင့် မဟုတ်သည်များ)

PRD သည် မေးခွန်းလေးခုကို ဖြေသည်-

1. ဘာကြောင့် ဒါကို တည်ဆောက်နေတာလဲ။ ဘယ်ပြဿနာ၊ ဘယ်သူအတွက်လဲ။
2. ပထမ version တွင် ဘာ လုပ်ဆောင်ရမလဲ။
3. ဘာကို ခုတော့ မလုပ်သေးလဲ။
4. အလုပ်ဖြစ်ကြောင်း ဘယ်လို သိမလဲ။

ဒါဟာ နည်းပညာဆိုင်ရာ design မဟုတ်ပါ။ database သို့မဟုတ် framework ဘာသုံးမလဲ ဆိုတာ မပြောပါ။ ၎င်းသည် လိုအပ်ပါက သီးခြား technical spec တွင် ရှိသင့်သည်။ စီးပွားရေးအစီအစဉ် သို့မဟုတ် marketing brief လည်း မဟုတ်ပါ။ PRD ကို ထုတ်ကုန်၏ အပြုအမူအပေါ်တွင်သာ ထားခြင်းက ၎င်းကို ဖတ်သူအားလုံး အတွက် အသုံးဝင်စေသည်။ ဥပမာ designer၊ developer၊ လက်မှတ်ထိုးသော stakeholder သို့မဟုတ် code အဖြစ် ပြောင်းလဲသော AI app builder။

ဘယ်သူတွေ လိုအပ်လဲ

• Solo founder များ၊ scope creep မဖြစ်ခင် ရပ်တန့်ချင်သူများ။
• အသေးစား team များ၊ "ကျွန်ုပ်တို့ သဘောတူထားသည်" ကို နေရာတစ်ခုတည်းတွင် ထားချင်သူများ။
• Freelancer သို့မဟုတ် agency ငှားသူ အားလုံး၊ ရှင်းလင်းသော PRD ဖြင့် ပို့ကုန်ကြေးပိုရှင်းလင်းသည်။ developer ငှားခြင်း သို့မဟုတ် AI ဖြင့် တည်ဆောက်ခြင်း ကို ကြည့်ပါ။
• AI ဖြင့် တည်ဆောက်သူ အားလုံး၊ PRD ၏ user story နှင့် data စာရင်းက ပုံစံမရှိသော အကြံဉာဏ်စာရင်းထက် prompt ကောင်းများ ဖြစ်စေသည်။

AI ကောင်းသည်နှင့် မကောင်းသည်များ

အဖြစ်အများဆုံး အမှားမှာ အထက်ပါ ဇယား၏ အောက်မှ ဒုတိယ အတန်းကို ပြောင်းပြန်လှန်ထားခြင်း ဖြစ်သည်။ AI က သင့်အသုံးပြုသူများအကြောင်း ယုံကြည်စွာ ကွက်လပ်များကို ခန့်မှန်းဖြည့်တတ်သည်။ အသုံးပြုသူများ၊ ဈေးကွက်အရွယ်အစား သို့မဟုတ် အပြုအမူအကြောင်း AI ရေးသမျှကို အချက်အလက်မဟုတ်ဘဲ စစ်ဆေးရမည့်မေးခွန်းအဖြစ် ဆက်ဆံပါ။

အဆင့် ၁: သင်သိသမျှကို ချရေးပါ

prompt မပေးမီ ကြမ်းတမ်းသော မှတ်စုများ ရေးပါ။ bullet point များလည်း ရသည်။ အောက်ပါတို့ကို ပါစေပါ-

• ပြဿနာကို အသုံးပြုသူ၏ အမြင်ဖြင့် စာကြောင်း ၁ မှ ၂ ကြောင်းဖြင့်။
• ဘယ်သူ ကြုံနေသလဲ။ တိကျစွာ ဖော်ပြပါ- "၁၀ မှ ၄၀ ဖောက်သည်ရှိသော လွတ်လပ်စွာလုပ်ကိုင်သည့် စာရင်းကိုင်များ" ဟု ရေးပါ၊ "သေးငယ်သော စီးပွားရေးများ" ဟု မရေးပါနှင့်။
• ၎င်းတို့ ယခု ဘာလုပ်နေသလဲ (spreadsheet၊ email၊ မကြိုက်သော tool တစ်ခု)။
• version တစ်ကို အောင်မြင်စေမည့် outcome တစ်ခုတည်း။
• မလုပ်ရန် သိထားသော အရာများ။
• မာကျောသော ကန့်သတ်ချက်များ- deadline၊ ဘတ်ဂျက်၊ ဖုန်းပေါ်တွင် အလုပ်ဖြစ်ရမည်၊ သင်ရှိပြီးသား tool နှင့် ချိတ်ဆက်ရမည်။

ပြဿနာရှိသူနှင့် တစ်ယောက်မျှ မပြောဖူးပါက ဦးစွာ ထိုသို့ လုပ်ပါ။ app idea ကို အတည်ပြုနည်း တွင် လက်တွေ့နည်းလမ်းရှိသည်။ ခန့်မှန်းချက်ပေါ်တွင် တည်ဆောက်ထားသော PRD သည် ပုံစံကောင်းသော ခန့်မှန်းချက်သာ ဖြစ်သည်။

အဆင့် ၂: AI ကို ပထမ draft တောင်းပါ

မှတ်စုများကို ကူးထည့်ပြီး ပုံသေဖွဲ့စည်းပုံဖြင့် draft တောင်းပါ။ အလုပ်ဖြစ်သော prompt ဥပမာ-

ထုတ်ကုန်တစ်ခုအကြောင်း ကျွန်ုပ်၏ မှတ်စုများ ဖြစ်သည်။ ဤအပိုင်းများကို အတိအကျသုံးပြီး product requirements document အဖြစ် ပြောင်းပေးပါ- Summary၊ Problem၊ Users၊ Goals and success metrics၊ Scope (in / out)၊ acceptance criteria ပါသော User stories၊ Data၊ Permissions၊ Edge cases၊ Open questions။ စာမျက်နှာ နှစ်ခုအောက် ထားပါ။ အသုံးပြုသူများ သို့မဟုတ် ဈေးကွက်အကြောင်း အချက်အလက်မတီထွင်ပါနှင့်။ ကျွန်ုပ်၏ မှတ်စုတွင် မပါသည်များကို Open questions အောက်တွင် မေးခွန်းအဖြစ် ရေးပါ။

နောက်ဆုံး ညွှန်ကြားချက်က အရေးကြီးသည်။ မသိသောအရာများကို ဖြည့်မပေးဘဲ "Open questions" သို့ ပို့ခိုင်းခြင်းက ပိုသစ္စာရှိသော draft ကို ရစေသည်။

အဆင့် ၃: အပိုင်းတစ်ခုချင်းစီကို ချိန်ညှိပါ

draft ကို အပိုင်းအလိုက် ဖတ်ပါ။ အောက်ပါ follow-up prompt များက ကူညီသည်-

ပြဿနာနှင့် အသုံးပြုသူများ

ပြဿနာ ကြေညာချက်ကို အသုံးပြုသူ၏ အမြင်ဖြင့် စာကြောင်း ၁ မှ ၂ ကြောင်းဖြင့် ပြန်ရေးပါ။ ဖြေရှင်းနည်းစကားလုံး မပါစေပါနှင့်။

ပြဿနာ ကြေညာချက်တွင် သင့်ထုတ်ကုန်ကို ဖော်ပြထားလျှင် ၎င်းသည် ပြဿနာကို မဟုတ်ဘဲ ဖြေရှင်းနည်းကို ဖော်ပြနေခြင်း ဖြစ်သည်။

ရည်မှန်းချက်များနှင့် success metric များ

version တစ်အတွက် သုံးခု အသုံးပြုသူ အနည်းငယ်ဖြင့် ပထမလတွင် တိုင်းတာနိုင်သော success metric သုံးခု အကြံပြုပါ။ တစ်ခုစီအတွက် တိုင်းတာပုံကို ပြောပါ။

တစ်ခု သို့မဟုတ် နှစ်ခု ရွေးပါ။ "ဘောက်ချာ ၂၀ ယောက်က တစ်ပတ်လျှင် တစ်လ အသုံးပြုသည်" ဆိုသည်မှာ တိုင်းတာနိုင်သည်။ "အလုပ်ထုတ်လုပ်မှု တိုးတက်စေသည်" ဆိုသည်မှာ မတိုင်းတာနိုင်ပါ။

Scope

ဤ PRD တွင် ပါသော အရာများထဲမှ ပင်မစီးဆင်းမှုကို မပျက်စီးစေဘဲ နောက်ပိုင်း version သို့ ရွှေ့နိုင်သည်များကို စာရင်းပြုစုပါ။

AI tool များသည် feature များ ထည့်ပေါင်းတတ်သည်။ ဤ prompt က ၎င်းကို ပြောင်းပြန်လုပ်စေသည်။ ရဲရဲဖြတ်ပါ။ version တစ်အတွက် PRD အများစုသည် ကြီးလွန်းသည်။ MVP ဆိုတာ ဘာလဲ တွင် ပထမ version သေးသေးလေး ဘာကြောင့် သင်ယူစရာ ပိုများသည်ကို ရှင်းပြထားသည်။

User story နှင့် acceptance criteria

requirement တစ်ခုချင်းစီကို user story ("[အသုံးပြုသူ] အနေဖြင့်၊ [လုပ်ဆောင်ချက်] ကို လိုချင်သည်၊ ရလဒ် [outcome] ရစေရန်") အဖြစ် ရေးပြီး Given / When / Then ပုံစံဖြင့် acceptance criteria နှစ်ခုမှ လေးခု ထည့်ပါ။

Acceptance criteria သည် နောက်ပိုင်း စမ်းသပ်မည့် စစ်ဆေးစာရင်း ဖြစ်သည်။ "Given ကြိုတင်ဘွတ်ထားသော အချိန်၊ when အခြားဖောက်သည်က ပြက္ခဒိန်ကို ကြည့်သည်၊ then ထို အချိန်ကို မပြပါ" ဆိုသည်မှာ စမ်းသပ်နိုင်သည်။ "booking ကောင်းစွာ အလုပ်လုပ်သည်" ဆိုသည်မှာ မဟုတ်ပါ။

Edge case နှင့် permission

user story တစ်ခုစီအတွက် data အလွတ်၊ မမှန်ကန်သော input၊ နှေးကွေးသော သို့မဟုတ် ပျက်ကွက်သော network request နှင့် ဝင်ခွင့်မရှိသင့်သော အသုံးပြုသူ တို့တွင် ဘာဖြစ်မလဲ ကို စာရင်းပြုစုပါ။

ဒီနေရာမှာ AI ကောင်းစွာ အလုပ်လုပ်သည်။ လူများ မေ့တတ်သော empty state နှင့် permission ကွက်လပ်များကို ရှာဖွေရာတွင် မြန်ဆန်သည်။

အဆင့် ၄: သံသယရှိသူတစ်ယောက်ကဲ့သို့ ပြန်စစ်ပါ

တစ်ခါ ထပ်ဖတ်ပြီး အောက်ပါတို့ကို စစ်ပါ-

• အသုံးပြုသူများအကြောင်း claim တိုင်း သင် သို့မဟုတ် သုတေသနမှ လာသည်၊ AI မှ မဟုတ်ပါ။
• Scope "out" သည် အနည်းဆုံး Scope "in" လောက် ရှည်သည်။
• User story တစ်ခုချင်းစီ တွင် သင့်ကို မမေးဘဲ တစ်စုံတစ်ယောက်က စမ်းသပ်နိုင်သော acceptance criteria ရှိသည်။
• Data အပိုင်း တွင် app က သိမ်းသော record အမျိုးအစား အားလုံးနှင့် ၎င်းကို ဘယ်သူမြင်နိုင်သလဲ ပါသည်။
• Open questions တွင် တာဝန်ရှိသူနှင့် ရက်စွဲ ရှိသည်။
• နည်းပညာဆိုင်ရာ အရာ မပါဝင်ပါက ("offline အလုပ်လုပ်ရမည်" သည် requirement ဖြစ်သည်၊ "Redis သုံးပါ" မဟုတ်ပါ)။

ထို့နောက် ထုတ်ကုန်ကို အသုံးပြုမည် သို့မဟုတ် တည်ဆောက်မည့် လူတစ်ယောက်အား ပေးပြီး မရှင်းသည်များ မေးခိုင်းပါ။ သူတို့၏ မေးခွန်းများသည် ကွက်လပ်များ ဖြစ်သည်။

ဖြည့်ရန် PRD ပုံစံ

စာရွက်တစ်ခုတွင် ကူးထည့်ပြီး ကွင်းစများကို အစားထိုးပါ။ တကယ်မသက်ဆိုင်သော အပိုင်းများကို ဖျက်ပါ။

ထုတ်ကုန်အမည်: [အမည်] ပိုင်ရှင်: [ဆုံးဖြတ်ချက်များအတွက် တာဝန်ရှိသူ] အခြေအနေ: [draft / ဆွေးနွေးနေသည် / သဘောတူပြီး] — နောက်ဆုံးပြင်ဆင်သည့်ရက်: [ရက်စွဲ]

၁. အနှစ်ချုပ်

[စာကြောင်း ၂ မှ ၃ ကြောင်း- ဘာလဲ၊ ဘယ်သူအတွက်လဲ၊ အဓိက outcome ဘာလဲ။]

၂. ပြဿနာ

[အသုံးပြုသူ၏ အမြင်ဖြင့် ပြဿနာ။ ယခု ဘာလုပ်နေသလဲ၊ ဘာကြောင့် နာကျင်စေသလဲ။]

၃. အသုံးပြုသူများ

၄. ရည်မှန်းချက်များနှင့် success metric

• ရည်မှန်းချက်: [version တစ်က ရရှိရမည့် outcome]
• Metric: [တိုင်းတာပုံနှင့် target]
• Non-goal: [လူတွေ ထင်နိုင်သော်လည်း ဤ version က မလုပ်ရန် ရည်ရွယ်သည့်အရာ]

၅. Scope

Version တစ်တွင် ပါသည်:

• [feature]
• [feature]

Version တစ်တွင် မပါသေးပါ:

• [feature၊ ဘာကြောင့် နောက်မှလုပ်နိုင်သလဲ]
• [feature၊ ဘာကြောင့် နောက်မှလုပ်နိုင်သလဲ]

၆. User story များ

Story ၁: [အသုံးပြုသူ] အနေဖြင့်၊ [လုပ်ဆောင်ချက်] ကို လိုချင်သည်၊ [outcome] ရစေရန်။

• Given [အခြေအနေ]၊ when [လုပ်ဆောင်ချက်]၊ then [ရလဒ်]။
• Given [အခြေအနေ]၊ when [လုပ်ဆောင်ချက်]၊ then [ရလဒ်]။

Story ၂: [အသုံးပြုသူ] အနေဖြင့်၊ [လုပ်ဆောင်ချက်] ကို လိုချင်သည်၊ [outcome] ရစေရန်။

• Given [အခြေအနေ]၊ when [လုပ်ဆောင်ချက်]၊ then [ရလဒ်]။

၇. Data

၈. Permission

[ဘယ်သူ login ဝင်နိုင်သလဲ၊ ဘယ် role များ ရှိသလဲ၊ role တစ်ခုစီက ဘာကို မြင်နိုင်ပြီး ဘာကို ပြောင်းနိုင်သလဲ။]

၉. Edge case များ

• [Empty state- data မရှိသေးသောအခါ ဘာပြမလဲ]
• [မမှန်ကန်သော input- email မှားခြင်း သို့မဟုတ် field လွဲခြင်းတွင် ဘာဖြစ်မလဲ]
• [ဝင်ခွင့်- မသင့်သော စာမျက်နှာကို ဖွင့်သောအခါ ဘာဖြစ်မလဲ]

၁၀. Integration နှင့် ကန့်သတ်ချက်များ

[ငွေပေးချေမှု၊ email၊ ရှိပြီးသား tool များ၊ deadline၊ ဘတ်ဂျက်၊ အလုပ်လုပ်ရမည့် စက်ပစ္စည်းများ။]

၁၁. Open questions

PRD မှ prompt များသို့

ကောင်းသော PRD သည် AI app builder အတွက် prompt များအဖြစ် တိုက်ရိုက်ပြောင်းနိုင်သည်-

• အနှစ်ချုပ်၊ အသုံးပြုသူများနှင့် data ဇယား သည် သင်၏ ပထမ prompt ဖြစ်လာသည်။
• User story တစ်ခုစီ သည် follow-up prompt တစ်ခု ဖြစ်လာသည်။
• Acceptance criterion တစ်ခုစီ သည် preview တွင် သင်စမ်းသပ်ရမည့်အရာ ဖြစ်လာသည်။
• "Version တစ်တွင် မပါသေးပါ" စာရင်းသည် ယခုမတောင်းဆိုသေးသော အရာများ ဖြစ်သည်။

PRD တစ်ခုလုံးကို ကူးထည့်ပြီး အရာအားလုံး တောင်းဆိုခြင်းထက် story တစ်ခုချင်းစီကို တည်ဆောက်ပြီး ၎င်း၏ acceptance criteria ကို မစစ်ဆေးမီ နောက်တစ်ခုသို့ မသွားခြင်းက ပို၍ ယုံကြည်စိတ်ချရသည်။ AI app builder အတွက် prompt ရေးနည်း တွင် prompt ဘက်ကို ပိုမိုအသေးစိတ် ဖော်ပြထားသည်။

အများဆုံး အမှားများ

• ဖြေရှင်းနည်းကို ပြဿနာအဖြစ် ရေးခြင်း။ "အသုံးပြုသူများ dashboard လိုသည်" ဆိုသည်မှာ ဖြေရှင်းနည်း ဖြစ်သည်။ "Owner များက ငွေတောင်းခံလွှာတစ်ခုချင်းစီကို မဖွင့်ဘဲ ရက်လွန်သွားသည်ကို မမြင်နိုင်ပါ" ဆိုသည်မှာ ပြဿနာ ဖြစ်သည်။
• "Scope အပြင်" အပိုင်း မရှိခြင်း။ ၎င်းမရှိလျှင် စကားဝိုင်းတိုင်း scope ကို ပြန်ဖွင့်ရမည်။
• AI က အသုံးပြုသူများကို တီထွင်ခွင့်ပေးခြင်း။ AI ဖန်တီးထားသော persona များသည် တကယ်ရှိသည်ဟု ထင်ရသော်လည်း မရှိပါ။
• တိုင်းတာ၍မရသော metric များ။ ရေတွက်နည်းမရှိလျှင် ၎င်းသည် metric မဟုတ်ပါ။
• ဘယ်တော့မှ မပြင်ခြင်း။ သင်တည်ဆောက်နေသည်နှင့် မကိုက်ညီတော့သော PRD သည် မရှိသည်ထက် ဆိုးသည်။ "နောက်ဆုံးပြင်ဆင်သည့်ရက်" ကို ထားပြီး ဆုံးဖြတ်ချက်များ ပြောင်းသည့်အခါ ပြင်ပါ။

Mythex တွင် PRD သုံးခြင်း

Mythex ကို အသုံးပြုပါက PRD ကို chat တွင် တိုက်ရိုက်ကူးထည့်နိုင်သည်။ Plan mode သည် PRD အတွက် ကိုက်ညီသည်။ agent က ဖတ်ပြီး ချဉ်းကပ်နည်းနှင့် plan tab တွင် သုံးသပ်နိုင်သော အဆင့် စာရင်းကို အဆိုပြုပြီး Build ကို နှိပ်မှသာ ဖိုင်များ ပြောင်းလဲစတင်သည်။ ထပ်တူ မရေးရလိုသော အရာများ- ပရိသတ်၊ brand၊ စည်းမျဉ်းများကို project knowledge အဖြစ် သိမ်းနိုင်သည်။ chat docs တွင် Build၊ Plan နှင့် Ask mode များကို ရှင်းပြထားသည်။ template များ က စာရွက်အပြည့်ရေးမီ ပထမ version ပုံစံကို မြင်ရန် အမြန်နည်းဖြစ်သည်။

မေးခွန်းများ