Kuidas kirjutada tehisintellektiga tootenõuete dokumenti (tasuta mall)

Tootenõuete dokument (PRD) on lühike ja selges keeles kirjeldus sellest, mida te ehitate, kellele see on mõeldud, mida see peab tegema ja kuidas teate, et see töötab. Tehisintellekt muudab selle kirjutamise palju kiiremaks: annate ligikaudsed märkmed ja see muudab need struktureeritud jaotisteks, kasutajalugudeks ja äärmuslikeks juhtumiteks. Teie ülesanne on anda otsused, mida tehisintellekt ei suuda teha — eesmärk, ulatus ja see, mis jäetakse välja — ning kontrollida, mida ta juurde lisab.

See juhend käsitleb seda, mis PRD-sse kuulub, sammu-sammult viisi selle koostamiseks mis tahes tehisintellekti assistendiga, prompte iga jaotise jaoks ning täidetavat malli, mille võite kopeerida.

Milleks PRD on (ja milleks mitte)

PRD vastab neljale küsimusele:

1. Miks me seda ehitame? Milline probleem ja kellele?
2. Mida see peab esimeses versioonis tegema?
3. Mida see veel ei tee?
4. Kuidas me teame, et see töötas?

See ei ole tehniline disain. See ei ütle, millist andmebaasi või raamistikku kasutada — selleks on eraldi tehniline spetsifikatsioon, kui üldse vaja on. See ei ole ka turundusbrief ega äriplaan. Kui hoiate PRD toote käitumises, on see kasulik kõigile, kes seda loevad: disainerile, arendajale, kinnitajale või tehisintellekti rakenduste koostajale, kes selle koodiks muudab.

Kellele see vajalik on

• Üksikutele asutajatele, kes tahavad ulatuse hiilimise ära hoida.
• Väikestele meeskondadele, kellel on vaja ühte kohta, kus elab „see, mida me kokku leppisime“.
• Igaühele, kes palkab freelancerit või agentuuri, sest selge PRD toob selgemad pakkumised. Vaata arendaja palkamine või ehitamine tehisintellektiga.
• Igaühele, kes ehitab tehisintellektiga, sest PRD kasutajalood ja andmenimekiri on paremad promptid kui struktureerimata soovinimekiri.

Mida tehisintellekt hästi teeb — ja mida mitte

Kõige levinum viga on eelviimase rea pööratud versioon: tehisintellekt täidab lünki enesekindlalt ligikaudsete oletustega teie kasutajate kohta. Kõike, mida ta kirjutab kasutajate, turu suuruse või käitumise kohta, käsitlege küsimusena, mida kontrollida, mitte faktina.

Samm 1: kirjutage kõik, mida teate

Enne kui midagi küsite, kirjutage ligikaudsed märkmed. Loetelud sobivad. Katke:

• Probleem ühes või kahes lauses kasutaja vaatenurgast.
• Kes seda probleemi kogeb. Olge konkreetne: „vabakutselised raamatupidajad 10–40 kliendiga“, mitte „väikeettevõtted“.
• Mida nad praegu selle asemel teevad (tabel, e-kiri, tööriist, mis neile ei meeldi).
• Ühe tulemuse, mis muudaks esimese versiooni eduks.
• Kõik, mida teate, et ei tee.
• Kõvad piirangud: tähtaeg, eelarve, peab töötama telefonides, peab ühilduma tööriistaga, mida juba kasutate.

Kui te pole veel rääkinud ühegi inimesega, kellel see probleem on, tehke see enne. Kuidas rakenduse ideed valideerida pakub praktilist viisi. Oletustele ehitatud PRD on hästi vormindatud oletus.

Samm 2: paluge tehisintellektilt esimene mustand

Kleepige oma märkmed ja paluge mustandit kindlas struktuuris. Prompt, mis hästi töötab:

Siin on minu märkmed toote kohta. Muutke need tootenõuete dokumendiks, kasutades täpselt neid jaotisi: Kokkuvõte, Probleem, Kasutajad, Eesmärgid ja edumõõdikud, Ulatus (sees / väljas), Kasutajalood koos vastuvõtukriteeriumidega, Andmed, Õigused, Äärmuslikud juhtumid, Avatud küsimused. Hoidke see alla kahe lehekülje. Ärge leiutage fakte kasutajate ega turu kohta — kus minu märkmed ei ütle, kirjutage küsimus jaotisse Avatud küsimused.

Viimane juhis on oluline. Kui käsite tehisintellektil suunata teadmata asjad jaotisse „Avatud küsimused“ selle asemel, et neid täita, saate palju aususe mustandi.

Samm 3: täpsustage iga jaotist

Käige mustand läbi jaotise kaupa. Need järelküsimused aitavad:

Probleem ja kasutajad

Kirjutage probleemi kirjeldus ümber ühes või kahes lauses kasutaja vaatenurgast. Ilma lahenduse sõnadeta.

Kui probleemi kirjeldus mainib teie toodet, kirjeldab see lahendust, mitte probleemi.

Eesmärgid ja edumõõdikud

Soovitage kolm edumõõdikut esimesele versioonile, mida ma saan mõõta esimese kuu jooksul väikese kasutajate arvuga. Igaühe kohta ütelge, kuidas ma seda mõõdaksin.

Valige üks või kaks. „Kakskümmend raamatupidajat kasutab seda iga nädal ühe kuu jooksul“ on mõõdetav. „Tõsta tootlikkust“ ei ole.

Ulatus

Loetlege kõik selles PRD-s, mida saaks hilisemasse versiooni lükata, ilma et põhivoog puruneks.

Tehisintellekti tööriistad kipuvad funktsioone lisama. See prompt paneb neid tegema vastupidist. Olge karm: enamik esimese versiooni PRD-sid on liiga suured. Mis on MVP selgitab, miks väikesed esimesed versioonid õpetavad teile rohkem.

Kasutajalood ja vastuvõtukriteeriumid

Kirjutage iga nõue kasutajalugudena („Kasutajana tahan [tegevust], et [tulemus]“) koos kahe kuni nelja vastuvõtukriteeriumiga Eeldusel / Kui / Siis vormis.

Vastuvõtukriteeriumid on kontrollnimekiri, mille vastu hiljem testite. „Eeldusel broneeritud aeg, kui teine klient vaatab kalendrit, siis aega ei kuvata“ on testitav. „Broneerimine toimib hästi“ ei ole.

Äärmuslikud juhtumid ja õigused

Iga kasutajalao kohta loetlege, mis juhtub tühjade andmete, vale sisendi, aeglase või ebaõnnestunud võrgupäringu ning kasutajaga, kes ei tohiks ligipääsu omada.

Siin tasub tehisintellekt end ära. See on kiire märkama tühje olekuid ja õiguste auke, mida inimesed unustavad.

Samm 4: vaadake üle nagu skeptik

Lugege kogu dokument veel kord läbi ja kontrollige:

• Iga väide kasutajate kohta pärineb teilt või uuringutest, mitte tehisintellektilt.
• Ulatus „väljas“ on vähemalt sama pikk kui ulatus „sees“.
• Igal kasutajalool on vastuvõtukriteeriumid, mida keegi saab testida ilma teilt küsimata.
• Andmete jaotis loetleb kõik rakenduse hoitavad kirjete liigid ja selle, kes neid näha võib.
• Avatud küsimustel on vastutaja ja kuupäev.
• Ükski tehniline detail ei ole sisse hiilinud, välja arvatud siis, kui see on tegelik piirang („peab töötama võrguühenduseta“ on nõue; „kasuta Redist“ ei ole).

Seejärel jagage seda ühe inimesega, kes toodet kasutab või ehitab, ja küsige, mis on ebaselge. Nende küsimused on lüngad.

Täidetav PRD mall

Kopeerige see dokumenti ja asendage sulud. Kustutage kõik jaotised, mis tõesti ei kehti.

Toote nimi: [nimi] Omanik: [isik, kes vastutab otsuste eest] Staatus: [mustand / ülevaatuses / kokku lepitud] — Viimati uuendatud: [kuupäev]

1. Kokkuvõte

[Kaks või kolm lauset: mis see on, kellele ja peamine tulemus.]

2. Probleem

[Probleem kasutaja vaatenurgast. Mida nad praegu teevad ja miks see valutab.]

3. Kasutajad

4. Eesmärgid ja edumõõdikud

• Eesmärk: [tulemus, mille esimene versioon peab saavutama]
• Mõõdik: [kuidas seda mõõdate ja sihtmärk]
• Mitte-eesmärk: [midagi, mida inimesed võivad eeldada, kuid mida see versioon ei püüa teha]

5. Ulatus

Esimeses versioonis:

• [funktsioon]
• [funktsioon]

Esimeses versioonis ei ole:

• [funktsioon ja miks see võib oodata]
• [funktsioon ja miks see võib oodata]

6. Kasutajalood

Lugu 1: Kasutajana tahan [tegevus], et [tulemus].

• Eeldusel [kontekst], kui [tegevus], siis [tulemus].
• Eeldusel [kontekst], kui [tegevus], siis [tulemus].

Lugu 2: Kasutajana tahan [tegevus], et [tulemus].

• Eeldusel [kontekst], kui [tegevus], siis [tulemus].

7. Andmed

8. Õigused

[Kes saavad sisse logida, millised rollid on olemas ja mida iga roll näha ja muuta saab.]

9. Äärmuslikud juhtumid

• [Tühi olek: mida näidatakse, kui andmeid veel pole]
• [Vale sisend: mis juhtub vale e-posti või puuduva väljaga]
• [Ligipääs: mis juhtub, kui keegi avab lehe, mida tal ei tohiks olla]

10. Integratsioonid ja piirangud

[Maksed, e-post, olemasolevad tööriistad, tähtajad, eelarve, seadmed, millel peab töötama.]

11. Avatud küsimused

PRD-st promptideks

Hea PRD muutub peaaegu otse promptideks tehisintellekti rakenduste koostajale:

• Kokkuvõte, kasutajad ja andmetabel saavad teie esimeseks promptiks.
• Iga kasutajalugu saab ühe järelprompti.
• Iga vastuvõtukriteerium on midagi, mida testite eelvaates.
• Nimekiri „ei ole esimeses versioonis“ on see, mida te veel ei palu.

Ühe loo kaupa ehitamine ja selle vastuvõtukriteeriumide kontrollimine enne järgmisele liikumist on palju usaldusväärsem kui kogu PRD kleepimine ja kõige küsimine korraga. Kuidas kirjutada prompte tehisintellekti rakenduste koostajale käsitleb promptimise poolt põhjalikumalt.

Levinud vead

• Lahenduse kirjutamine probleemina. „Kasutajad vajavad töölauda“ on lahendus. „Omanikud ei näe, millised arved on tähtaja ületanud, ilma et peaks igaüht avama“ on probleem.
• Puudub jaotis „ulatusest väljas“. Ilma selleta avatakse iga vestlus ulatust uuesti.
• Tehisintellekti lubamine kasutajaid välja mõelda. AI tehtud personad tunduvad tõelised, aga pole seda.
• Mõõdikud, mida te ei saa mõõta. Kui te ei saa seda lugeda, ei ole see mõõdik.
• Dokumendi mitte uuendamine. PRD, mis ei vasta enam sellele, mida ehitate, on halvem kui puuduv. Hoidke kuupäev „viimati uuendatud“ ja muutke seda, kui otsused muutuvad.

PRD kasutamine Mythexiga

Kui ehitate Mythexis, saate PRD otse vestlusesse kleepida. Režiim Plan sobib PRD jaoks hästi: agent loeb selle, pakub lähenemisviisi ja sammude nimekirja, mida saate planeerimisvahekaardil üle vaadata, ning hakkab faile muutma alles siis, kui vajutate Build. Ka need osad, mis peaksid alati kehtima — publik, bränd, reeglid — saate salvestada projekti teadmistena, et neid igas vestluses uuesti ei kordaks. Mythexi vestluse dokumentatsioon selgitab režiime Build, Plan ja Ask, ning mallid on kiire viis näha, kuidas esimene versioon võiks välja näha, enne kui kirjutate kogu dokumendi.

Küsimused