Hogyan írjunk termékkövetelmény-dokumentumot AI-val (ingyenes sablon)

A termékkövetelmény-dokumentum (PRD) egy rövid, közérthető leírás arról, mit építesz, kinek készül, mit kell tudnia, és honnan fogod tudni, hogy működik. Az AI sokkal gyorsabbá teszi a megírását: a nyers jegyzeteidből strukturált szekciókat, felhasználói történeteket és szélsőséges eseteket készít. A te feladatod, hogy megadd azokat a döntéseket, amelyeket az AI nem tud meghozni — a célt, a hatókört és azt, mi marad ki —, és ellenőrizd, amit hozzáad.

Ez az útmutató bemutatja, mi tartozik egy PRD-be, lépésről lépésre hogyan írhatod meg bármelyik AI-asszisztenssel, promptokat ad minden szekcióhoz, és másolható, kitölthető sablont is tartalmaz.

Mire való a PRD (és mire nem)

A PRD négy kérdésre válaszol:

1. Miért építjük ezt? Milyen problémát, kinek?
2. Mit kell tudnia az első verziónak?
3. Mit nem fog tudni egyelőre?
4. Hogyan fogjuk tudni, hogy működött?

Nem technikai terv. Nem mondja meg, melyik adatbázist vagy keretrendszert használd — az egy külön technikai specifikációba tartozik, ha egyáltalán kell. Nem is marketingkoncepció vagy üzleti terv. Ha a PRD a termék működésére szorítkozik, az teszi hasznossá mindenki számára: a tervezőnek, a fejlesztőnek, a jóváhagyó érdekeltnek vagy az AI-építőnek, amely kódot készít belőle.

Kinek van rá szüksége

• Egyszemélyes alapítóknak, akik meg akarják akadályozni, hogy a hatókör elcsússzon.
• Kis csapatoknak, akiknek kell egy hely, ahol a „mit állapítottunk meg” megmarad.
• Bárkinek, aki freelancert vagy ügynökséget bíz meg, mert egy világos PRD tisztább árajánlatokat eredményez. Lásd: fejlesztő felbérlése vagy építés AI-val.
• Bárkinek, aki AI-val épít, mert a PRD felhasználói történetei és adatlistája jobb promptokat ad, mint egy strukturálatlan kívánságlista.

Miben jó az AI — és miben nem

A leggyakoribb hiba az előző sor fordítottja: az AI magabiztosan kitölti a réseket a felhasználókról szóló valószínű találgatásokkal. Mindent, amit a felhasználókról, a piac méretéről vagy a viselkedésről ír, kérdésnek tekints, amit ellenőrizni kell, nem ténynek.

1. lépés: Írd le, amit tudsz

Mielőtt bármilyen promptot írnál, készíts nyers jegyzeteket. Felsorolás is jó. Térj ki az alábbiakra:

• A probléma, egy-két mondatban, a felhasználó szemszögéből.
• Kinek van ez a problémája. Legyél konkrét: „szabadúszó könyvelők 10–40 ügyféllel”, nem „kis vállalkozások”.
• Mit csinálnak most helyette (táblázat, e-mail, egy eszköz, amit nem szeretnek).
• Az az egy eredmény, amely az első verziót sikeressé tenné.
• Amit már most tudsz, hogy nem fogsz megcsinálni.
• Kemény korlátok: határidő, költségvetés, telefonon is működnie kell, egy már használt eszközzel kell integrálódnia.

Ha még nem beszéltél olyanokkal, akiknek megvan a problémájuk, ezt tedd előbb. A hogyan validáljunk egy alkalmazásötletet gyakorlati módot ad rá. Egy találgatásokra épülő PRD csak jól formázott találgatás.

2. lépés: Kérj az AItól egy első vázlatot

Illeszd be a jegyzeteidet, és kérj vázlatot fix szerkezetben. Egy jól működő prompt:

Itt vannak a jegyzeteim egy termékről. Alakítsd át termékkövetelmény-dokumentummá pontosan ezekkel a szekciókkal: Összefoglaló, Probléma, Felhasználók, Célok és sikermutatók, Hatókör (be / ki), Felhasználói történetek elfogadási kritériumokkal, Adatok, Jogosultságok, Szélsőséges esetek, Nyitott kérdések. Maximum két oldal legyen. Ne találj ki tényeket a felhasználókról vagy a piacról — ahol a jegyzeteim nem mondanak semmit, a kérdést a Nyitott kérdések alá írd.

Az utolsó mondatnak nagy súlya van. Ha azt mondod az AI-nak, hogy az ismeretleneket a „Nyitott kérdések” alá tegye, ahelyett, hogy kitöltené őket, sokkal őszintébb vázlatot kapsz.

3. lépés: Szorítsd meg az egyes szekciókat

Nézd át a vázlatot szekciónként. Ezek a követő promptok segítenek:

Probléma és felhasználók

Írd át a problémaleírást egy-két mondatban a felhasználó szemszögéből. Megoldási szavak nélkül.

Ha a problémaleírás megemlíti a terméked, az megoldást ír le, nem problémát.

Célok és sikermutatók

Javasolj három sikermutatót az első verzióhoz, amelyeket az első hónapban mérhetek kevés felhasználóval. Mindegyiknél írd le, hogyan mérném.

Válassz egyet vagy kettőt. „Húsz könyvelő havonta használja egy hónapig hetente” mérhető. A „növelni a termelékenységet” nem az.

Hatókör

Sorold fel ebben a PRD-ben mindazt, ami későbbi verzióba is átkerülhetne anélkül, hogy az alapfolyamat sérülne.

Az AI-eszközök hajlamosak funkciókat hozzáadni. Ez a prompt az ellenkezőjére készteti őket. Legyél könyörtelen: a legtöbb első verziós PRD túl nagy. A mi az MVP megmagyarázza, miért tanít többet a kicsi első verzió.

Felhasználói történetek és elfogadási kritériumok

Írd meg minden követelményt felhasználói történetként („Mint [felhasználó], szeretnék [művelet], hogy [eredmény]”), két-négy elfogadási kritériummal Adott / Amikor / Akkor formában.

Az elfogadási kritériumok azok az ellenőrzőlisták, amelyek ellen később tesztelsz. „Adott egy lefoglalt időpont, amikor egy másik ügyfél megnézi a naptárat, akkor a foglalt időpont nem látszik” tesztelhető. A „a foglalás jól működik” nem az.

Szélsőséges esetek és jogosultságok

Minden felhasználói történethez sorold fel, mi történik üres adatnál, hibás bevitelnél, lassú vagy sikertelen hálózati kérésnél, és olyan felhasználónál, akinek nem lenne hozzáférése.

Itt hasznos igazán az AI. Gyorsan észreveszi az üres állapotokat és a jogosultsági réseket, amelyeket az emberek elfelejtenek.

4. lépés: Nézd át kritikusan

Olvasd végig még egyszer az egészet, és ellenőrizd:

• Minden állítás a felhasználókról tőled vagy kutatásból származik, nem az AI-tól.
• A „ki” hatókör legalább olyan hosszú, mint a „be” hatókör.
• Minden felhasználói történetnek olyan elfogadási kritériuma van, amelyet valaki le tud tesztelni anélkül, hogy téged kérdezne.
• Az adatszekció felsorolja az alkalmazás által tárolt rekordtípusokat és azt, ki láthatja őket.
• A nyitott kérdéseknek van felelőse és határideje.
• Semmi technikai nem csúszott be, hacsak nem valódi korlát („offline is működnie kell” követelmény; „használjunk Redist” nem az).

Ezután add oda az egyik embernek, aki használni vagy építeni fogja a terméket, és kérdezd meg, mi nem világos. Az ő kérdései mutatják meg a hiányosságokat.

Kitölthető PRD-sablon

Másold be egy dokumentumba, és cseréld ki a szögletes zárójeleket. Törölj minden szekciót, amely valóban nem alkalmazható.

Terméknév: [név] Felelős: [a döntésekért felelős személy] Állapot: [vázlat / felülvizsgálat alatt / elfogadva] — Utoljára frissítve: [dátum]

1. Összefoglaló

[Két-három mondat: mi ez, kinek szól, és a fő eredmény.]

2. Probléma

[A probléma a felhasználó szemszögéből. Mit csinálnak most, és miért fáj ez nekik.]

3. Felhasználók

4. Célok és sikermutatók

• Cél: [az eredmény, amelyet az első verziónak el kell érnie]
• Mutató: [hogyan mérjük, és a célérték]
• Nem cél: [valami, amit az emberek feltételezhetnek, de ez a verzió nem akarja megcsinálni]

5. Hatókör

Az első verzióban:

• [funkció]
• [funkció]

Az első verzióban nincs benne:

• [funkció, és miért várhat]
• [funkció, és miért várhat]

6. Felhasználói történetek

1. történet: Mint [felhasználó], szeretnék [műveletet végrehajtani], hogy [eredmény].

• Adott [kontextus], amikor [művelet], akkor [eredmény].
• Adott [kontextus], amikor [művelet], akkor [eredmény].

2. történet: Mint [felhasználó], szeretnék [műveletet végrehajtani], hogy [eredmény].

• Adott [kontextus], amikor [művelet], akkor [eredmény].

7. Adatok

8. Jogosultságok

[Ki jelentkezhet be, milyen szerepkörök vannak, és mit láthat és változtathat meg mindegyik szerepkör.]

9. Szélsőséges esetek

• [Üres állapot: mi jelenik meg, ha még nincs adat]
• [Hibás bevitel: mi történik hibás e-mail-címnél vagy hiányzó mezőnél]
• [Hozzáférés: mi történik, ha valaki olyan oldalt nyit meg, amit nem kellene]

10. Integrációk és korlátok

[Fizetések, e-mail, meglévő eszközök, határidők, költségvetés, eszközök, amelyeken működnie kell.]

11. Nyitott kérdések

A PRD-től a promptokig

A jó PRD szinte közvetlenül átalakítható promptokká egy AI-alkalmazásépítőnek:

• Az összefoglaló, a felhasználók és az adattábla adja az első promptot.
• Minden felhasználói történet egy követő promptot ad.
• Minden elfogadási kritérium valami, amit az előnézetben tesztelsz.
• A „nincs az első verzióban” lista az, amit még nem kérsz el.

Egy történetet építeni és ellenőrizni az elfogadási kritériumait, mielőtt a következőre lépnél, sokkal megbízhatóbb, mint a teljes PRD bemásolása és mindent egyszerre kérni. A hogyan írjunk promptokat AI-alkalmazásépítőknek részletesebben foglalkozik a promptolással.

Gyakori hibák

• A megoldást írni problémaként. „A felhasználóknak irányítópult kell” megoldás. „A tulajdonosok nem látják, mely számlák lejártak, anélkül hogy mindegyiket megnyitnák” probléma.
• Nincs „hatókörön kívül” szekció. Enélkül minden beszélgetés újranyitja a hatókört.
• Az AI-nak hagyni, hogy felhasználókat találjon ki. Az AI által kitalált személyek valóságosnak tűnnek, pedig nem azok.
• Olyan mutatók, amelyeket nem tudsz mérni. Ha nincs módod megszámolni, az nem mutató.
• Soha nem frissíteni. Az a PRD, amely már nem egyezik azzal, amit építesz, rosszabb, mint semmi. Tarts nyilván egy „utoljára frissítve” dátumot, és módosítsd, ha változnak a döntések.

PRD használata a Mythexszel

Ha a Mythexben építesz, a PRD-det egyenesen beillesztheted a chatbe. A Plan mód jó választás PRD-hez: az ügynök elolvassa, javasol egy megközelítést és egy lépéslistát, amelyet a terv fülön átnézhetsz, és csak akkor kezd fájlokat módosítani, amikor megnyomod a Build gombot. Azokat a részeket, amelyeknek mindig érvényesnek kell lenniük — közönség, márka, szabályok — projekttudásként is elmentheted, hogy ne kelljen minden chatben megismételned. A chat dokumentáció elmagyarázza a Build, Plan és Ask módot, a sablonok pedig gyors képet adnak arról, hogyan nézhetne ki egy első verzió, mielőtt megírnád a teljes dokumentumot.

Kérdések