Ինչպես գրել արտադրանքի պահանջների փաստաթուղթ AI-ի օգնությամբ (անվճար ձևանմուշ)

Արտադրանքի պահանջների փաստաթուղթը (PRD) կարճ, պարզ լեզվով գրված նկարագրություն է այն մասին, թե ինչ եք կառուցում, ում համար է, ինչ պետք է անի և ինչպես կիմանաք, որ աշխատում է։ AI-ն դրա գրումը զգալիորեն արագացնում է. դուք նրան տալիս եք կոպիտ նշումներ, և նա դրանք վերածում է կառուցվածքային բաժինների, օգտատիրոջ պատմությունների և եզրային դեպքերի։ Ձեր գործը այն որոշումները տալն է, որոնք AI-ն չի կարող կայացնել՝ նպատակը, շրջանակը և այն, թե ինչ է մնում դրսում, և ստուգել այն, ինչ նա ավելացնում է։

Այս ուղեցույցը ներառում է այն, ինչ պետք է լինի PRD-ում, քայլ առ քայլ եղանակ՝ այն կազմելու համար ցանկացած AI օգնականի միջոցով, հուշումներ յուրաքանչյուր բաժնի համար և լրացվող ձևանմուշ, որը կարող եք պատճենել։

Ինչի համար է PRD-ն (և ինչ չէ)

PRD-ն պատասխանում է չորս հարցի.

1. Ինչու ենք սա կառուցում։ Ի՞նչ խնդիր, ում համար։
2. Ի՞նչ պետք է անի առաջին տարբերակում։
3. Ի՞նչ դեռ չի անի։
4. Ինչպե՞ս կիմանանք, որ աշխատեց։

Դա տեխնիկական նախագիծ չէ։ Այն չի ասում, թե որ տվյալների բազան կամ շրջանակը օգտագործել, դա պատկանում է առանձին տեխնիկական նկարագրությանը, եթե ընդհանրապես դրա կարիքը կա։ Այն նաև մարքեթինգային բրիֆ կամ բիզնես պլան չէ։ PRD-ն պահելը միայն արտադրանքի վարքագծի շուրջ է, որ այն օգտակար լինի բոլոր ընթերցողների համար՝ դիզայներին, մշակողին, հաստատող շահագրգիռ կողմին կամ AI հավելվածների կառուցողին, որը այն վերածում է կոդի։

Ում է պետք

• Անկախ հիմնադիրներ, ովքեր ուզում են կանխել շրջանակի ընդլայնումը։
• Փոքր թիմեր, որոնց պետք է մեկ տեղ, որտեղ ապրում է «ինչի ենք համաձայնվել»։
• Ով վարձում է ֆրիլանսեր կամ գործակալություն, քանի որ հստակ PRD-ն ավելի հստակ գնային առաջարկներ է բերում։ Տես վարձեք մշակող կամ կառուցեք AI-ով։
• Ով կառուցում է AI-ով, քանի որ PRD-ի օգտատիրոջ պատմությունները և տվյալների ցուցակը ավելի լավ հուշումներ են, քան կառուցվածք չունեցող ցանկությունների ցուցակը։

Ինչում է AI-ն լավ և ինչում՝ ոչ

Ամենատարածված սխալը երկրորդ-վերջին տողի շրջված տարբերակն է. AI-ն վստահորեն լցնում է բացերը օգտատերերի մասին ենթադրություններով։ Ամեն ինչ, որ նա գրում է օգտատերերի, շուկայի չափի կամ վարքագծի մասին, դիտարկեք որպես հարց, որ պետք է ստուգել, ոչ թե փաստ։

Քայլ 1. Գրեք այն, ինչ գիտեք

Մինչև որևէ հուշում գրելը, գրեք կոպիտ նշումներ։ Կետերը նույնպես բավական են։ Ընդգրկեք՝

• Խնդիրը մեկ-երկու նախադասությամբ, օգտատիրոջ տեսանկյունից։
• Ով ունի այն։ Եղեք կոնկրետ. «ֆրիլանս հաշվապահներ 10–40 հաճախորդով», ոչ թե «փոքր բիզնեսներ»։
• Ինչ են անում այսօր փոխարենը (աղյուսակ, էլ. նամակ, գործիք, որը չեն սիրում)։
• Այն մեկ արդյունքը, որը առաջին տարբերակը հաջողակ կդարձնի։
• Այն ամենը, ինչ արդեն գիտեք, որ չեք անի։
• Կոշտ սահմանափակումներ՝ ժամկետ, բյուջե, պետք է աշխատի հեռախոսներում, պետք է ինտեգրվի գործիքի հետ, որն արդեն օգտագործում եք։

Եթե դեռ խոսել չեք որևէ մեկի հետ, ում հետ կա այս խնդիրը, սկզբում դա արեք։ Ինչպես վավերացնել հավելվածի գաղափարը ունի գործնական եղանակ դրա համար։ Ենթադրությունների վրա կառուցված PRD-ն լավ ձևավորված ենթադրություն է։

Քայլ 2. Խնդրեք AI-ից առաջին նախագիծը

Ձեր նշումները տեղադրեք և խնդրեք նախագիծ ֆիքսված կառուցվածքով։ Հուշում, որը լավ է աշխատում.

Ահա իմ նշումները մի արտադրանքի մասին։ Վերածեք դրանք արտադրանքի պահանջների փաստաթղթի՝ հենց այս բաժիններով. Ամփոփում, Խնդիր, Օգտատերեր, Նպատակներ և հաջողության չափանիշներ, Շրջանակ (ներառված / չներառված), Օգտատիրոջ պատմություններ՝ ընդունման չափանիշներով, Տվյալներ, Թույլտվություններ, Եզրային դեպքեր, Բաց հարցեր։ Պահեք այն երկու էջից պակաս։ Մի հորինեք փաստեր օգտատերերի կամ շուկայի մասին. որտեղ իմ նշումները չեն ասում, գրեք հարցը «Բաց հարցեր» բաժնում։

Վերջին հրահանգը կարևոր է. AI-ին ասելով, որ անհայտները դնի «Բաց հարցեր»-ում, այլ ոչ թե լցնի դրանք, ստանում եք շատ ավելի ազնիվ նախագիծ։

Քայլ 3. Խստացրեք յուրաքանչյուր բաժին

Անցեք նախագծի միջով բաժին առ բաժին։ Այս հետագա հուշումները օգնում են.

Խնդիրը և օգտատերերը

Վերագրեք խնդրի հայտարարությունը մեկ-երկու նախադասությամբ՝ օգտատիրոջ տեսանկյունից։ Առանց լուծման բառերի։

Եթե խնդրի հայտարարությունը հիշատակում է ձեր արտադրանքը, ապա այն նկարագրում է լուծում, ոչ թե խնդիր։

Նպատակներ և հաջողության չափանիշներ

Առաջարկեք երեք հաջողության չափանիշ առաջին տարբերակի համար, որոնք կարող եմ չափել առաջին ամսվա ընթացքում փոքր թվով օգտատերերի հետ։ Յուրաքանչյուրի համար ասեք, թե ինչպես կչափեմ։

Ընտրեք մեկ-երկուսը։ «Քսան հաշվապահ այն շաբաթական օգտագործում է մեկ ամիս» չափելի է։ «Բարձրացնել արտադրողականությունը» չէ։

Շրջանակ

Թվարկեք այս PRD-ի ամեն ինչ, որ կարող է տեղափոխվել հետագա տարբերակ՝ առանց հիմնական հոսքը խախտելու։

AI գործիքները հակված են գործառույթներ ավելացնելու։ Այս հուշումը նրանց ստիպում է անել հակառակը. եղեք անողոք. առաջին տարբերակի PRD-ների մեծ մասը չափազանց մեծ է։ Ինչ է MVP-ն բացատրում է, թե ինչու փոքր առաջին տարբերակները ավելի շատ են սովորեցնում։

Օգտատիրոջ պատմություններ և ընդունման չափանիշներ

Գրեք յուրաքանչյուր պահանջ որպես օգտատիրոջ պատմություն («Որպես [օգտատեր], ես ուզում եմ [գործողություն], որպեսզի [արդյունք]») երկու-չորս ընդունման չափանիշով՝ Given / When / Then ձևով։

Ընդունման չափանիշները այն ստուգաթերթն են, որով հետագայում կթեստավորեք։ «Տրված է ամրագրված ժամանակահատված, երբ մեկ այլ հաճախորդ նայում է օրացույցը, ապա ժամանակահատվածը չի ցուցադրվում» թեստավորելի է։ «Ամրագրումը լավ է աշխատում» չէ։

Եզրային դեպքեր և թույլտվություններ

Յուրաքանչյուր օգտատիրոջ պատմության համար թվարկեք, թե ինչ է լինում դատարկ տվյալների, սխալ մուտքագրման, դանդաղ կամ ձախողված ցանցային հարցման և այն օգտատիրոջ դեպքում, ով չպետք է մուտք ունենա։

Այստեղ AI-ն իր տեղն է գտնում. արագ է նկատում դատարկ վիճակները և թույլտվությունների բացերը, որոնք մարդիկ մոռանում են։

Քայլ 4. Վերանայեք որպես թերահավատ

Կարդացեք ամբողջը մեկ անգամ ևս և ստուգեք.

• Օգտատերերի մասին յուրաքանչյուր պնդում եկել է ձեզնից կամ հետազոտությունից, ոչ թե AI-ից։
• Շրջանակի «դուրս» մասը առնվազն նույնքան երկար է, որքան «ներս» մասը։
• Յուրաքանչյուր օգտատիրոջ պատմություն ունի ընդունման չափանիշներ, որոնք ինչ-որ մեկը կարող է թեստավորել առանց ձեզ հարցնելու։
• Տվյալների բաժինը թվարկում է հավելվածի պահած յուրաքանչյուր գրառման տեսակ և ով կարող է տեսնել այն։
• Բաց հարցերը ունեն պատասխանատու և ամսաթիվ։
• Ոչ մի տեխնիկական բան չի մտել, եթե դա իրական սահմանափակում չէ («պետք է աշխատի օֆլայն» պահանջ է. «օգտագործել Redis» չէ)։

Այնուհետև կիսվեք այն մեկ մարդու հետ, ով կօգտագործի կամ կկառուցի արտադրանքը, և հարցրեք, թե ինչն է անհստակ։ Նրանց հարցերը բացերն են։

Լրացվող PRD ձևանմուշ

Պատճենեք սա փաստաթղթի մեջ և փոխարինեք փակագծերը։ Ջնջեք այն բաժինները, որոնք իրականում չեն կիրառվում։

Արտադրանքի անուն: [անուն] Պատասխանատու: [անձ, ով պատասխանատու է որոշումների համար] Կարգավիճակ: [նախագիծ / վերանայման մեջ / համաձայնեցված] — Վերջին թարմացում: [ամսաթիվ]

1. Ամփոփում

[Երկու-երեք նախադասություն. ինչ է սա, ում համար և հիմնական արդյունքը։]

2. Խնդիր

[Խնդիրը օգտատիրոջ տեսանկյունից. ինչ են անում այսօր և ինչու է դա խնդրահարույց։]

3. Օգտատերեր

4. Նպատակներ և հաջողության չափանիշներ

• Նպատակ: [արդյունքը, որին պետք է հասնի առաջին տարբերակը]
• Չափանիշ: [ինչպես կչափեք, և թիրախը]
• Ոչ-նպատակ: [բան, որ մարդիկ կարող են ենթադրել, բայց այս տարբերակը չի փորձում անել]

5. Շրջանակ

Առաջին տարբերակում:

• [գործառույթ]
• [գործառույթ]

Առաջին տարբերակում չկա:

• [գործառույթ, և ինչու կարող է սպասել]
• [գործառույթ, և ինչու կարող է սպասել]

6. Օգտատիրոջ պատմություններ

Պատմություն 1: Որպես [օգտատեր], ես ուզում եմ [գործողություն], որպեսզի [արդյունք]։

• Տրված է [համատեքստ], երբ [գործողություն], ապա [արդյունք]։
• Տրված է [համատեքստ], երբ [գործողություն], ապա [արդյունք]։

Պատմություն 2: Որպես [օգտատեր], ես ուզում եմ [գործողություն], որպեսզի [արդյունք]։

• Տրված է [համատեքստ], երբ [գործողություն], ապա [արդյունք]։

7. Տվյալներ

8. Թույլտվություններ

[Ով կարող է մուտք գործել, ինչ դերեր կան, և յուրաքանչյուր դեր ինչ կարող է տեսնել և փոխել։]

9. Եզրային դեպքեր

• [Դատարկ վիճակ. ինչ է ցուցադրվում, երբ դեռ տվյալներ չկան]
• [Սխալ մուտքագրում. ինչ է լինում սխալ էլ. փոստի կամ բաց դաշտի դեպքում]
• [Մուտք. ինչ է լինում, երբ ինչ-որ մեկը բացում է էջ, որին չպետք է մուտք ունենա]

10. Ինտեգրացիաներ և սահմանափակումներ

[Վճարումներ, էլ. փոստ, գոյություն ունեցող գործիքներ, ժամկետներ, բյուջե, սարքեր, որոնց վրա պետք է աշխատի։]

11. Բաց հարցեր

PRD-ից մինչև հուշումներ

Լավ PRD-ն գրեթե ուղղակիորեն վերածվում է AI հավելվածների կառուցողի հուշումների.

• Ամփոփումը, օգտատերերը և տվյալների աղյուսակը դառնում են ձեր առաջին հուշումը։
• Յուրաքանչյուր օգտատիրոջ պատմություն դառնում է մեկ հետագա հուշում։
• Յուրաքանչյուր ընդունման չափանիշ դառնում է այն, ինչ թեստավորում եք նախադիտման մեջ։
• «Առաջին տարբերակում չկա» ցանկը այն է, ինչ դեռ չեք խնդրում։

Մեկ պատմությամբ կառուցելը և նախքան հաջորդին անցնելը դրա ընդունման չափանիշները ստուգելը շատ ավելի հուսալի է, քան ամբողջ PRD-ն տեղադրելը և ամեն ինչ միանգամից խնդրելը։ Ինչպես գրել հուշումներ AI հավելվածների կառուցողի համար-ը ավելի մանրամասն է անդրադառնում հուշումների կողմին։

Սովորական սխալներ

• Լուծումը գրել որպես խնդիր։ «Օգտատերերին պետք է վահանակ» լուծում է։ «Սեփականատերերը չեն կարող տեսնել, թե որ հաշիվներն են ժամկետանց, առանց յուրաքանչյուրը բացելու» խնդիր է։
• Չկա «շրջանակից դուրս» բաժին։ Առանց դրա յուրաքանչյուր զրույց նորից բացում է շրջանակը։
• Թույլ տալ AI-ին հորինել օգտատերեր։ AI-ի հորինած անձնավորությունները իրական են թվում, բայց չեն։
• Չափումներ, որոնք չեք կարող չափել։ Եթե չունեք այն հաշվելու միջոց, դա չափանիշ չէ։
• Երբեք չթարմացնել։ PRD-ն, որը չի համապատասխանում այն բանին, ինչ կառուցում եք, ավելի վատ է, քան ընդհանրապես չլինելը։ Պահեք «վերջին թարմացում» ամսաթիվը և փոխեք այն, երբ որոշումները փոխվում են։

PRD-ի օգտագործումը Mythex-ի հետ

Եթե կառուցում եք Mythex-ում, կարող եք PRD-ն ուղղակի զրույցի մեջ տեղադրել։ Plan ռեժիմից սկսելը լավ է PRD-ի համար. գործակալը կարդում է այն, առաջարկում է մոտեցում և քայլերի ցուցակ, որը կարող եք վերանայել պլանի ներդիրում, և սկսում է ֆայլեր փոխել միայն այն ժամանակ, երբ սեղմում եք Build։ Կարող եք նաև պահել այն մասերը, որոնք միշտ պետք է գործեն՝ լսարան, ապրանքանիշ, կանոններ, որպես նախագծի գիտելիք, որպեսզի յուրաքանչյուր զրույցում չկրկնեք դրանք։ Chat-ի փաստաթղթերը բացատրում են Build, Plan և Ask ռեժիմները, իսկ ձևանմուշները արագ ձև են տալիս տեսնելու, թե ինչ կարող է լինել առաջին տարբերակը, նախքան ամբողջական փաստաթուղթը գրելը։

Հարցեր