Kako z umetno inteligenco napisati dokument o zahtevah izdelka (brezplačna predloga)

Dokument o zahtevah izdelka (PRD) je kratek opis v preprostem jeziku, kaj gradite, za koga je namenjeno, kaj mora početi in kako bomo vedeli, da deluje. AI močno pospeši pisanje: dobi grobe zapiske in iz njih naredi strukturirane razdelke, uporabniške zgodbe in robne primere. Vaša naloga je, da zagotovite odločitve, ki jih AI ne more sprejeti – cilj, obseg in to, kar pustite ven – ter da preverite, kar doda.

Ta vodnik zajema, kaj mora biti v PRD-ju, korak za korakom, kako ga osnovati z vsakim pomočnikom AI, pozive za posamezne razdelke in predlogo za izpolnjevanje, ki jo lahko kopirate.

Čemu služi PRD (in čemu ne)

PRD odgovori na štiri vprašanja:

1. Zakaj to gradimo? Kateri problem, za koga?
2. Kaj mora početi v prvi različici?
3. Česa še ne bo počel?
4. Kako bomo vedeli, da je delovalo?

Ni tehnična zasnova. Ne pove, katero bazo podatkov ali ogrodje uporabiti – to sodi v ločen tehnični opis, če ga sploh potrebujete. Prav tako ni marketinški načrt ali poslovni načrt. Če PRD ostane pri vedenju izdelka, je uporaben za vse, ki ga berejo: oblikovalca, razvijalca, deležnika, ki ga potrdi, ali orodje za izdelavo aplikacij, ki iz njega naredi kodo.

Kdo ga potrebuje

• Samostojni ustanovitelji, ki želijo preprečiti širjenje obsega, preden se začne.
• Majhne ekipe, ki potrebujejo eno mesto, kjer živi „kar smo se dogovorili“.
• Vsi, ki najemajo frilenserja ali agencijo, saj jasen PRD pomeni jasnejše ponudbe. Glejte najem razvijalca ali gradnjo z AI.
• Vsi, ki gradijo z AI, ker seznam uporabniških zgodb in podatkov v PRD-ju naredi boljše pozive kot nestrukturiran seznam želja.

Kaj je AI dober pri – in kaj ni

Najpogostejša napaka je obrnjena druga vrstica od spodaj: AI samozavestno zapolni vrzeli sprejemljivimi ugibanji o vaših uporabnikih. Vsako trditev, ki jo napiše o uporabnikih, tržni velikosti ali vedenju, obravnavajte kot vprašanje za preverjanje, ne kot dejstvo.

Korak 1: Zapišite, kar veste

Preden karkoli vnesete v poziv, zapišite grobe zapiske. Ločila so v redu. Zajemite:

• Problem v enem ali dveh stavkih z vidika uporabnika.
• Kdo ga ima. Bodite konkretni: „svobodni knjigovodje z 10–40 strankami“, ne „mala podjetja“.
• Kaj počnejo danes (preglednica, e-pošta, orodje, ki ga ne marajo).
• En rezultat, ki bi naredil prvo različico uspešno.
• Stvari, za katere že veste, da jih ne bomo delali.
• Trde omejitve: rok, proračun, mora delovati na telefonih, mora se povezati z orodjem, ki ga že uporabljate.

Če še niste govorili z nikomer, ki ima ta problem, to najprej storite. Kako preveriti idejo aplikacije vsebuje praktičen način. PRD, zgrajen na ugibanjih, je dobro oblikovano ugibanje.

Korak 2: Od AI zahtevajte prvi osnutek

Prilepite zapiske in zahtevajte osnutek v fiksni strukturi. Poziv, ki dobro deluje:

Tu so moji zapiski o izdelku. Pretvorite jih v dokument o zahtevah izdelka s točno temi razdelki: Povzetek, Problem, Uporabniki, Cilji in metrike uspeha, Obseg (v / ven), Uporabniške zgodbe s sprejemnimi merili, Podatki, Dovoljenja, Robni primeri, Odprta vprašanja. Naj bo krajši od dveh strani. Ne izmišljujte dejstev o uporabnikih ali trgu – kjer moji zapiski ničesar ne povedo, napišite vprašanje pod Odprta vprašanja.

Zadnje navodilo je pomembno. Če AI usmerite, naj neznanke preusmeri v „Odprta vprašanja“ namesto da jih zapolni, dobite bistveno bolj pošten osnutek.

Korak 3: Zoži vsak razdelek

Pregledajte osnutek razdelek za razdelkom. Ti nadaljnji pozivi pomagajo:

Problem in uporabniki

Na novo napiši izjavo o problemu v enem ali dveh stavkih z vidika uporabnika. Brez besed o rešitvi.

Če izjava o problemu omenja vaš izdelek, opisuje rešitev, ne problema.

Cilji in metrike uspeha

Predlagaj tri metrike uspeha za prvo različico, ki jih lahko izmerim v prvem mesecu z majhnim številom uporabnikov. Za vsako povej, kako bi jo meril.

Izberite eno ali dve. „Dvajset knjigovodij jo uporablja tedensko en mesec“ je merljivo. „Izboljšati produktivnost“ ni.

Obseg

Našteti vse v tem PRD-ju, kar bi lahko premaknili v kasnejšo različico, ne da bi se porušil osrednji tok.

Orodja AI pogosto dodajajo funkcije. Ta poziv jih prisili v nasprotno smer. Bodite brezkompromisni: večina PRD-jev za prvo različico je prevelik. Kaj je MVP pojasni, zakaj manjše prve različice vas več naučijo.

Uporabniške zgodbe in sprejemna merila

Vsako zahtevo zapiši kot uporabniško zgodbo („Kot [uporabnik] želim [dejanje], da [rezultat]“) z dvema do štirimi sprejemnimi merili v obliki Dano / Ko / Potem.

Sprejemna merila so seznam, s katerim boste kasneje preverjali. „Dano je rezervirana termin, ko drug stranka pogleda koledar, potem termin ni prikazan“ je preverljivo. „Rezervacija dobro deluje“ ni.

Robni primeri in dovoljenja

Za vsako uporabniško zgodbo navedi, kaj se zgodi s praznimi podatki, neveljavnim vnosom, počasno ali neuspelo mrežno zahtevo in uporabnikom, ki nima dostopa.

Tu AI zasluži svoj denar. Hitro odkrije prazna stanja in vrzeli v dovoljenjih, ki jih ljudje pozabijo.

Korak 4: Preglejte kot skeptik

Preberite celoten dokument še enkrat in preverite:

• Vsaka trditev o uporabnikih prihaja od vas ali iz raziskave, ne od AI.
• Obseg „ven“ je vsaj tako dolg kot obseg „noter“.
• Vsaka uporabniška zgodba ima sprejemna merila, ki jih nekdo lahko preveri, ne da bi vas moral vprašati.
• Razdelek o podatkih našteva vsako vrsto zapisa, ki jo aplikacija hrani, in kdo jo lahko vidi.
• Odprta vprašanja imajo odgovorno osebo in rok.
• Nič tehničnega se ni prikradlo, razen če gre za resnično omejitev („mora delovati brez povezave“ je zahteva; „uporabi Redis“ ni).

Nato dokument delite z eno osebo, ki bo izdelek uporabljala ali gradila, in jo vprašajte, kaj ni jasno. Njena vprašanja so vrzeli.

Predloga za izpolnjevanje PRD-ja

Kopirajte to v dokument in zamenjajte oglate oklepaje. Izbrišite razdelke, ki res ne veljajo.

Ime izdelka: [ime] Lastnik: [oseba, odgovorna za odločitve] Stanje: [osnutek / v pregledu / dogovorjeno] — Zadnja sprememba: [datum]

1. Povzetek

[Dva ali trije stavki: kaj to je, za koga in glavni rezultat.]

2. Problem

[Problem z vidika uporabnika. Kaj počnejo danes in zakaj jih to moti.]

3. Uporabniki

4. Cilji in metrike uspeha

• Cilj: [rezultat, ki ga mora doseči prva različica]
• Metrika: [kako jo bomo merili in ciljna vrednost]
• Ne-cilj: [nekaj, kar bi ljudje morda predpostavljali, a te različica ne poskuša narediti]

5. Obseg

V prvi različici:

• [funkcija]
• [funkcija]

Ni v prvi različici:

• [funkcija in zakaj lahko počaka]
• [funkcija in zakaj lahko počaka]

6. Uporabniške zgodbe

Zgodba 1: Kot [uporabnik] želim [dejanje], da [rezultat].

• Dano [kontekst], ko [dejanje], potem [rezultat].
• Dano [kontekst], ko [dejanje], potem [rezultat].

Zgodba 2: Kot [uporabnik] želim [dejanje], da [rezultat].

• Dano [kontekst], ko [dejanje], potem [rezultat].

7. Podatki

8. Dovoljenja

[Kdo se lahko prijavi, kakšne vloge obstajajo in kaj lahko vsaka vloga vidi in spremeni.]

9. Robni primeri

• [Prazno stanje: kaj se prikaže, ko še ni podatkov]
• [Neveljaven vnos: kaj se zgodi pri napačnem e-naslovu ali manjkajočem polju]
• [Dostop: kaj se zgodi, ko nekdo odpre stran, do katere ne bi smel imeti dostopa]

10. Integracije in omejitve

[Plačila, e-pošta, obstoječa orodja, roki, proračun, naprave, na katerih mora delovati.]

11. Odprta vprašanja

Od PRD-ja do pozivov

Dobro napisan PRD se skoraj neposredno spremeni v pozive za orodje za izdelavo aplikacij:

• Povzetek, uporabniki in tabela podatkov postanejo vaš prvi poziv.
• Vsaka uporabniška zgodba postane en nadaljnji poziv.
• Vsako sprejemno merilo postane nekaj, kar preizkusite v predogledu.
• Seznam „ni v prvi različici“ je tisto, kar še ne zahtevate.

Gradnja ene zgodbe naenkrat in preverjanje njenih sprejemnih meril, preden greste naprej, je veliko bolj zanesljivo kot prilepiti cel PRD in zahtevati vse hkrati. Kako pisati pozive za orodja za izdelavo aplikacij podrobneje obravnava pozive.

Pogoste napake

• Pisanje rešitve kot problema. „Uporabniki potrebujejo nadzorno ploščo“ je rešitev. „Lastniki ne vidijo, katere račune so zapadli, ne da bi odprli vsakega posebej“ je problem.
• Brez razdelka „ven“. Brez njega se vsak pogovor znova odpre obseg.
• Dovoljevanje AI, da izmisli uporabnike. Osebe, ki jih je izmislil AI, delujejo resnično, pa niso.
• Metrike, ki jih ne morete izmeriti. Če tega ne morete šteti, to ni metrika.
• Nikoli ne posodabljanje. PRD, ki se ne ujema več s tem, kar gradite, je slabši kot nobenega. Ohranjajte datum „zadnje spremembe“ in ga spremenite, ko se odločitve spremenijo.

Uporaba PRD-ja z Mythexom

Če gradite v Mythexu, lahko PRD prilepite naravnost v klepet. Način Plan je dobro izbira za PRD: agent ga prebere, predlaga pristop in seznam korakov, ki ga lahko pregledate v zavihku plana, in začne spreminjati datoteke šele, ko pritisnete Build. Dele, ki bi morali vedno veljati – publiko, znamko, pravila – lahko shranite kot znanje projekta, da jih ne ponavljate v vsakem klepetu. Dokumentacija o klepetu razlaga načine Build, Plan in Ask, predloge pa so hiter način, da vidite, kako bi lahko izgledala prva različica, preden napišete celoten dokument.

Vprašanja