Si të shkruani një dokument kërkesash produkti me AI (shabllon falas)

Një dokument kërkesash produkti (PRD) është një përshkrim i shkurtër, me gjuhë të thjeshtë, i asaj që po ndërtoni, për kë është, çfarë duhet të bëjë dhe si do ta dini që funksionon. AI e bën shkrimin e tij shumë më të shpejtë: i jepni shënime të papërpunuara dhe ai i kthen në seksione të strukturuara, histori përdoruesi dhe raste kufitare. Puna juaj është të jepni vendimet që AI nuk mund t’i marrë — qëllimin, shtrirjen dhe atë që lihet jashtë — dhe të kontrolloni çfarë shton.

Ky udhëzues mbulon çfarë duhet të ketë një PRD, një mënyrë hap pas hapi për ta hartuar me çdo asistent AI, prompte për secilin seksion dhe një shabllon për t’u plotësuar që mund ta kopjoni.

Për çfarë shërben një PRD (dhe çfarë nuk është)

Një PRD u përgjigjet katër pyetjeve:

1. Pse po e ndërtojmë këtë? Cili problem, për kë?
2. Çfarë duhet të bëjë në versionin e parë?
3. Çfarë nuk do të bëjë ende?
4. Si do ta dimë që funksionoi?

Nuk është një projekt teknik. Nuk thotë cilën bazë të dhënash ose kornizë të përdorni — kjo i takon një specifikimi të veçantë teknik, nëse ju duhet fare. As nuk është një brief marketingu ose një plan biznesi. Mbajtja e PRD-së te sjellja e produktit është ajo që e bën të dobishme për të gjithë ata që e lexojnë: një dizajner, një zhvillues, një palë që e nënshkruan, ose një ndërtues aplikacionesh me AI që e kthen në kod.

Kush ka nevojë për të

• Themeluesit solo që duan të ndalojnë zgjerimin e shtrirjes para se të nisë.
• Ekipet e vogla që kanë nevojë për një vend të vetëm ku jeton „çfarë kemi rënë dakord“.
• Kushdo që punëson një freelancer ose agjenci, sepse një PRD e qartë merr oferta më të qarta. Shihni punësoni një zhvillues ose ndërtoni me AI.
• Kushdo që ndërton me AI, sepse historitë e përdoruesit dhe lista e të dhënave në një PRD bëjnë prompte më të mira se një listë e pastrukturuar dëshirash.

Çfarë e bën mirë AI — dhe çfarë jo

Gabimi më i zakonshëm është rreshti i dytë nga fundi i kthyer përmbys: AI plotëson me besim boshllëqet me supozime të besueshme për përdoruesit tuaj. Trajtojeni çdo gjë që shkruan për përdoruesit, madhësinë e tregut ose sjelljen si pyetje për t’u verifikuar, jo si fakt.

Hapi 1: Hidhni jashtë çfarë dini

Para se të jepni ndonjë prompt, shkruani shënime të papërpunuara. Pika të shkurtra janë në rregull. Mbuloni:

• Problemin, në një ose dy fjali, nga pikëpamja e përdoruesit.
• Kush e ka atë problem. Jini specifikë: „kontabilistë freelancer me 10–40 klientë“, jo „biznese të vogla“.
• Çfarë bëjnë sot në vend të tij (një fletëllogaritëse, email, një mjet që nuk u pëlqen).
• Rezultatin e vetëm që do ta bënte versionin e parë një sukses.
• Gjëra që tashmë e dini se nuk do t’i bëni.
• Kufizimet e ngurta: afati, buxheti, duhet të punojë në telefona, duhet të lidhet me një mjet që përdorni tashmë.

Nëse nuk keni folur me askënd që e ka atë problem, bëjeni këtë më parë. Si të vlerësoni një ide aplikacioni ka një mënyrë praktike për ta bërë këtë. Një PRD e ndërtuar mbi supozime është një supozim i mirë-formatuar.

Hapi 2: Kërkoni nga AI një draft të parë

Ngjitni shënimet tuaja dhe kërkoni një draft në një strukturë të caktuar. Një prompt që funksionon mirë:

Ja shënimet e mia për një produkt. Ktheji ato në një dokument kërkesash produkti duke përdorur saktësisht këto seksione: Përmbledhje, Problemi, Përdoruesit, Qëllimet dhe metrikat e suksesit, Shtrirja (brenda / jashtë), Historitë e përdoruesit me kritere pranimi, Të dhënat, Lejet, Rastet kufitare, Pyetjet e hapura. Mbajeni nën dy faqe. Mos shpik fakte për përdoruesit ose tregun — aty ku shënimet e mia nuk thonë asgjë, shkruaje pyetjen te Pyetjet e hapura.

Pjesa e fundit e udhëzimit ka rëndësi. T’i thuash AI-së të dërgojë të panjohurat te „Pyetjet e hapura“ në vend që t’i plotësojë, prodhon një draft shumë më të sinqertë.

Hapi 3: Përpunoni çdo seksion

Kaloni draftin seksion për seksion. Këto prompte pasuese ndihmojnë:

Problemi dhe përdoruesit

Rishkruaj deklaratën e problemit në një ose dy fjali nga pikëpamja e përdoruesit. Pa fjalë zgjidhjeje.

Nëse deklarata e problemit përmend produktin tuaj, ajo po përshkruan një zgjidhje, jo një problem.

Qëllimet dhe metrikat e suksesit

Sugjero tre metrika suksesi për versionin e parë që mund t’i matja në muajin e parë me një numër të vogël përdoruesish. Për çdo metrikë, thuaj si do ta matja.

Zgjidhni një ose dy. „Njëzet kontabilistë e përdorin çdo javë për një muaj“ është e matshme. „Përmirësim të produktivitetit“ nuk është.

Shtrirja

Listo gjithçka në këtë PRD që mund të zhvendoset në një version të mëvonshëm pa prishur rrjedhën kryesore.

Mjetet me AI priren të shtojnë veçori. Ky prompt i bën ato të bëjnë të kundërtën. Jini të pamëshirshëm: shumica e PRD-ve të versionit të parë janë shumë të mëdha. Çfarë është një MVP shpjegon përse versionet e vogla të para ju mësojnë më shumë.

Historitë e përdoruesit dhe kriteret e pranimit

Shkruaje çdo kërkesë si histori përdoruesi („Si [përdorues], dua [veprim] që [rezultat]“) me dy deri në katër kritere pranimi në formën Given / When / Then.

Kriteret e pranimit janë lista kontrolli me të cilën do të testoni më vonë. „Duke pasur një termin të rezervuar, kur një tjetër klient e shikon kalendarin, atëherë termini nuk shfaqet“ është e testueshme. „Rezervimi funksionon mirë“ nuk është.

Rastet kufitare dhe lejet

Për çdo histori përdoruesi, listo çfarë ndodh me të dhëna boshe, hyrje të pavlefshme, një kërkesë rrjeti të ngadaltë ose të dështuar, dhe një përdorues që nuk duhet të ketë akses.

Këtu AI ju shërben më së miri. Është e shpejtë në gjetjen e gjendjeve boshe dhe të boshllëqeve të lejeve që njerëzit harrojnë.

Hapi 4: Rishikojeni si skeptik

Lexoni gjithçka edhe një herë dhe kontrolloni:

• Çdo pohim për përdoruesit erdhi nga ju ose nga kërkimi, jo nga AI.
• Shtrirja „jashtë“ është të paktën aq e gjatë sa shtrirja „brenda“.
• Çdo histori përdoruesi ka kritere pranimi që dikush mund t’i testojë pa ju pyetur juve.
• Seksioni i të dhënave liston çdo lloj regjistrimi që mban aplikacioni dhe kush mund ta shohë.
• Pyetjet e hapura kanë një përgjegjës dhe një datë.
• Asgjë teknike nuk u fut përveçse nëse është një kufizim i vërtetë („duhet të punojë offline“ është kërkesë; „përdor Redis“ nuk është).

Pastaj ndajeni me një person që do ta përdorë ose ndërtojë produktin dhe pyetni çfarë nuk është e qartë. Pyetjet e tyre janë boshllëqet.

Shabllon PRD për t’u plotësuar

Kopjojeni këtë në një dokument dhe zëvendësoni kllapat. Fshini çdo seksion që vërtet nuk zbatohet.

Emri i produktit: [emri] Pronari: [personi përgjegjës për vendimet] Statusi: [draft / në rishikim / i rënë dakord] — Përditësuar për herë të fundit: [data]

1. Përmbledhje

[Dy ose tre fjali: çfarë është kjo, për kë dhe rezultati kryesor.]

2. Problemi

[Problemi nga pikëpamja e përdoruesit. Çfarë bëjnë sot dhe pse i dhemb.]

3. Përdoruesit

4. Qëllimet dhe metrikat e suksesit

• Qëllimi: [rezultati që versioni i parë duhet të arrijë]
• Metrika: [si do ta matni dhe objektivi]
• Jo-qëllim: [diçka që njerëzit mund ta supozojnë, por që ky version nuk synon ta bëjë]

5. Shtrirja

Në versionin e parë:

• [veçori]
• [veçori]

Jo në versionin e parë:

• [veçori, dhe pse mund të presë]
• [veçori, dhe pse mund të presë]

6. Historitë e përdoruesit

Histori 1: Si [përdorues], dua të [veprim] që [rezultat].

• Given [konteksti], when [veprimi], then [rezultati].
• Given [konteksti], when [veprimi], then [rezultati].

Histori 2: Si [përdorues], dua të [veprim] që [rezultat].

• Given [konteksti], when [veprimi], then [rezultati].

7. Të dhënat

8. Lejet

[Kush mund të hyjë, cilët role ekzistojnë dhe çfarë mund të shohë dhe ndryshojë secili rol.]

9. Rastet kufitare

• [Gjendja boshe: çfarë shfaqet kur s’ka ende të dhëna]
• [Hyrje e pavlefshme: çfarë ndodh me një email të gabuar ose një fushë që mungon]
• [Qasja: çfarë ndodh kur dikush hap një faqe që nuk duhet ta hapë]

10. Integrimet dhe kufizimet

[Pagesat, email-i, mjetet ekzistuese, afatet, buxheti, pajisjet ku duhet të punojë.]

11. Pyetjet e hapura

Nga PRD te prompte

Një PRD e mirë shndërrohet pothuajse drejtpërdrejt në prompte për një ndërtues aplikacionesh me AI:

• Përmbledhja, përdoruesit dhe tabela e të dhënave bëhen prompti juaj i parë.
• Çdo histori përdoruesi bëhet një prompt pasues.
• Çdo kriter pranimi bëhet diçka që testoni në pamje paraprake.
• Lista „jo në versionin e parë“ është ajo që refuzoni të kërkoni ende.

Ndërtimi një histori në një herë dhe kontrollimi i kritereve të pranimit para se të kaloni tek tjetra është shumë më i besueshëm sesa ngjitja e gjithë PRD-së dhe kërkimi i gjithçkaje njëherësh. Si të shkruani prompte për ndërtuesit e aplikacioneve me AI e trajton më gjerësisht anën e promptimit.

Gabimet më të zakonshme

• Shkrimi i zgjidhjes si problem. „Përdoruesit kanë nevojë për një panel“ është një zgjidhje. „Pronarët nuk mund të shohin cilat fatura kanë skaduar pa i hapur një nga një“ është një problem.
• Mungesa e seksionit „jashtë shtrirjes“. Pa të, çdo bisedë rihap shtrirjen.
• Lënia e AI-së të shpikë përdorues. Personat e krijuar nga AI duken të vërtetë dhe nuk janë.
• Metrika që nuk mund t’i matni. Nëse nuk keni mënyrë ta numëroni, nuk është metrikë.
• Mos e përditësoni kurrë. Një PRD që nuk përputhet më me atë që ndërtoni është më keq sesa aspak. Mbajeni një datë „përditësuar për herë të fundit“ dhe ndryshojeni kur ndryshojnë vendimet.

Përdorimi i një PRD me Mythex

Nëse ndërtoni në Mythex, mund ta ngjitni PRD-në tuaj drejt e në chat. Modaliteti Plan është një zgjedhje e mirë për një PRD: agjenti e lexon, propozon një qasje dhe një listë hapash që mund ta rishikoni në një skedë plani, dhe nis të ndryshojë skedarët vetëm kur shtypni Build. Mund të ruani edhe pjesët që duhet të zbatohen gjithmonë — audienca, brendi, rregullat — si njohuri projekti, që të mos i përsërisni në çdo chat. Dokumentacioni i chat-it shpjegon modalitetet Build, Plan dhe Ask, dhe shablonet janë një mënyrë e shpejtë për të parë si mund të duket një version i parë para se të shkruani dokumentin e plotë.

Pyetje