Kā uzrakstīt produkta prasību dokumentu ar MI (bezmaksas sagatave)

Produkta prasību dokuments (PRD) ir īss apraksts vienkāršā valodā par to, ko veidojat, kam tas domāts, ko tam jāspēj un kā zināsiet, ka tas strādā. MI to uzrakstīt ir daudz ātrāk: dodat aptuvenas piezīmes, un tas tās pārvērš strukturētās sadaļās, lietotāju stāstos un malas gadījumos. Jūsu uzdevums ir sniegt lēmumus, ko MI nespēj pieņemt, — mērķi, darbības apjomu un to, kas tiek atstāts ārpusē, — un pārbaudīt to, ko tas pievieno.

Šajā rokasgrāmatā aplūkots, kas PRD jāiekļauj, soli pa solim norādījumi, kā to izstrādāt ar jebkuru MI asistentu, uzvednes katrai sadaļai un aizpildāma sagatave, ko varat nokopēt.

Kam PRD ir paredzēts (un kam nav)

PRD atbild uz četriem jautājumiem:

1. Kāpēc mēs to veidojam? Kādu problēmu un kam?
2. Ko tam jāspēj pirmajā versijā?
3. Ko tas vēl nedarīs?
4. Kā mēs zināsim, ka tas strādā?

Tas nav tehnisks dizains. Tajā nav teikts, kuru datubāzi vai ietvaru izmantot, — tas pieder atsevišķai tehniskajai specifikācijai, ja tāda vispār vajadzīga. Tas nav arī mārketinga plāns vai biznesa plāns. Tas, ka PRD aprobežojas ar produkta darbību, padara to noderīgu ikvienam, kas to lasa: dizaineram, izstrādātājam, lēmumu pieņēmējam, kas to paraksta, vai MI lietotņu veidotājam, kas to pārvērš kodā.

Kam tas vajadzīgs

• Vienpašnieki, kuri vēlas apturēt darbības apjoma izplešanos, pirms tā sākas.
• Mazas komandas, kurām vajadzīga viena vieta, kur glabājas „par ko mēs vienojāmies”.
• Ikviens, kas pasūta izstrādātāju vai aģentūru, jo skaidrs PRD dod skaidrākus piedāvājumus. Skatiet pasūtiet izstrādātāju vai veidojiet ar MI.
• Ikviens, kas veido ar MI, jo PRD lietotāju stāsti un datu saraksts ir labākas uzvednes nekā nestrukturēts vēlmju saraksts.

Ko MI dara labi un ko nedara

Biežākā kļūda ir pretēja tam, ko rāda priekšpēdējā rinda: MI pārliecinoši aizpilda robus ar ticamiem minējumiem par jūsu lietotājiem. Visu, ko tas raksta par lietotājiem, tirgus lielumu vai uzvedību, uztveriet kā jautājumu, kas jāpārbauda, nevis kā faktu.

1. solis: uzrakstiet, ko zināt

Pirms jebkuras uzvednes sastādiet aptuvenas piezīmes. Punktveida saraksts ir pietiekams. Aptveriet:

• Problēmu vienā vai divos teikumos no lietotāja skatpunkta.
• Kam tā ir. Būt konkrētiem: „neatkarīgi grāmatveži ar 10–40 klientiem”, nevis „mazie uzņēmumi”.
• Ko viņi dara šobrīd (tabulu, e-pastu, rīku, kas viņiem nepatīk).
• Vienu rezultātu, kas padarītu pirmo versiju veiksmīgu.
• Visu, ko jau zināt, ka nedarīsiet.
• Stingrus ierobežojumus: termiņu, budžetu, jābūt darbspējīgam telefonos, jāintegrējas ar rīku, ko jau lietojat.

Ja neesat runājis ar nevienu, kam šī problēma ir, sāciet ar to. Kā pārbaudīt lietotnes ideju piedāvā praktisku veidu, kā to izdarīt. PRD, kas balstīts uz minējumiem, ir labi noformēts minējums.

2. solis: lūdziet MI pirmo melnrakstu

Ielieciet savas piezīmes un lūdziet melnrakstu noteiktā struktūrā. Uzvedne, kas labi darbojas:

Šeit ir manas piezīmes par produktu. Pārvērtiet tās produkta prasību dokumentā, izmantojot tieši šīs sadaļas: Kopsavilkums, Problēma, Lietotāji, Mērķi un sasniegumu metrikas, Darbības apjoms (iekšā / ārpusē), Lietotāju stāsti ar pieņemšanas kritērijiem, Dati, Atļaujas, Malas gadījumi, Atvērtie jautājumi. Turiet to zem divām lappusēm. Neizdomājiet faktus par lietotājiem vai tirgu — kur manas piezīmes neko neteic, uzrakstiet jautājumu sadaļā Atvērtie jautājumi.

Pēdējai instrukcijai ir nozīme. Ja MI lūdzat nezināmos jautājumus ievietot sadaļā „Atvērtie jautājumi”, nevis tos aizpildīt, melnraksts kļūst daudz godīgāks.

3. solis: sasmalciniet katru sadaļu

Pārskatiet melnrakstu pa sadaļām. Šīs papildu uzvednes palīdz:

Problēma un lietotāji

Pārrakstiet problēmas formulējumu vienā vai divos teikumos no lietotāja skatpunkta. Bez risinājuma vārdiem.

Ja problēmas formulējumā minēts jūsu produkts, tas apraksta risinājumu, nevis problēmu.

Mērķi un sasniegumu metrikas

Ieteiciet trīs sasniegumu metrikas pirmajai versijai, ko varu izmērīt pirmajā mēnesī ar nelielu lietotāju skaitu. Katrai pateiciet, kā to mērītu.

Izvēlieties vienu vai divas. „Divdesmit grāmatveži to lieto katru nedēļu mēneša garumā” ir izmērāms. „Uzlabot produktivitāti” nav.

Darbības apjoms

Uzskaitiet visu, kas šajā PRD varētu tikt pārcelts uz vēlāku versiju, neizjaucot galveno plūsmu.

MI rīki mēdz pievienot funkcijas. Šī uzvedne liek tiem darīt pretējo. Esiet nežēlīgi: vairums pirmās versijas PRD ir par lieliem. Kas ir MVP paskaidro, kāpēc mazas pirmās versijas dod vairāk mācību.

Lietotāju stāsti un pieņemšanas kritēriji

Katru prasību uzrakstiet kā lietotāja stāstu („Kā [lietotājs] es vēlos [darbību], lai [rezultāts]”) ar diviem līdz četriem pieņemšanas kritērijiem Dots / Kad / Tad formā.

Pieņemšanas kritēriji ir kontrolsaraksts, pret ko vēlāk pārbaudīsiet. „Dots aizņemts laiks, kad cits klients skata kalendāru, tad šis laiks nav redzams” ir pārbaudāms. „Rezervēšana strādā labi” nav.

Malas gadījumi un atļaujas

Katram lietotāja stāstam uzskaitiet, kas notiek ar tukšiem datiem, nederīgu ievadi, lēnu vai neizdevušos tīkla pieprasījumu un lietotāju, kuram nevajadzētu piekļuves.

Šeit MI ir noderīgs. Tas ātri atrod tukšos stāvokļus un atļauju robus, ko cilvēki bieži aizmirst.

4. solis: pārskatiet to kā skeptiķis

Vēlreiz izlasiet visu dokumentu un pārbaudiet:

• Katrs apgalvojums par lietotājiem nāca no jums vai pētījuma, nevis no MI.
• Darbības apjoma „ārpus” ir vismaz tikpat garš kā „iekšā”.
• Katram lietotāja stāstam ir pieņemšanas kritēriji, ko kāds varētu pārbaudīt, neprasot jums.
• Datu sadaļa uzskaita katru ierakstu veidu, ko lietotne glabā, un to, kas to var redzēt.
• Atvērtajiem jautājumiem ir atbildīgā persona un termiņš.
• Nekas tehnisks neieslīdēja, ja vien tas nav īsts ierobežojums („jādarbojas bezsaistē” ir prasība; „izmantot Redis” nav).

Pēc tam parādiet to vienam cilvēkam, kas izmantos vai veidos produktu, un jautājiet, kas nav skaidrs. Viņu jautājumi ir jūsu robi.

Aizpildāma PRD sagatave

Nokopējiet to dokumentā un aizstājiet iekavās ievietoto. Dzēsiet visas sadaļas, kas patiesi neattiecas uz jums.

Produkta nosaukums: [nosaukums] Atbildīgais: [persona, kas atbild par lēmumiem] Statuss: [melnraksts / pārskatīšanā / saskaņots] — Pēdējoreiz atjaunināts: [datums]

1. Kopsavilkums

[Divi vai trīs teikumi: kas tas ir, kam tas domāts un galvenais rezultāts.]

2. Problēma

[Problēma no lietotāja skatpunkta. Ko viņi dara šobrīd un kāpēc tas sagādā grūtības.]

3. Lietotāji

4. Mērķi un sasniegumu metrikas

• Mērķis: [rezultāts, ko pirmajai versijai jāsasniedz]
• Metrika: [kā to mērīsiet un mērķa vērtība]
• Nemērķis: [kaut kas, ko cilvēki varētu pieņemt, bet ko šī versija necenšas darīt]

5. Darbības apjoms

Pirmajā versijā:

• [funkcija]
• [funkcija]

Nav pirmajā versijā:

• [funkcija un kāpēc tā var pagaidīt]
• [funkcija un kāpēc tā var pagaidīt]

6. Lietotāju stāsti

1. stāsts: Kā [lietotājs] es vēlos [darbību], lai [rezultāts].

• Dots [konteksts], kad [darbība], tad [rezultāts].
• Dots [konteksts], kad [darbība], tad [rezultāts].

2. stāsts: Kā [lietotājs] es vēlos [darbību], lai [rezultāts].

• Dots [konteksts], kad [darbība], tad [rezultāts].

7. Dati

8. Atļaujas

[Kas var pieteikties, kādas lomas pastāv un ko katra loma var redzēt un mainīt.]

9. Malas gadījumi

• [Tukšs stāvoklis: kas tiek rādīts, kad vēl nav datu]
• [Nederīga ievade: kas notiek ar nepareizu e-pastu vai trūkstošu lauku]
• [Piekļuve: kas notiek, kad kāds atver lapu, kuru nedrīkstētu atvērt]

10. Integrācijas un ierobežojumi

[Maksājumi, e-pasts, esošie rīki, termiņi, budžets, ierīces, uz kurām jādarbojas.]

11. Atvērtie jautājumi

No PRD līdz uzvednēm

Labs PRD gandrīz tieši pārvēršas uzvednēs MI lietotņu veidotājam:

• Kopsavilkums, lietotāji un datu tabula kļūst par jūsu pirmo uzvedni.
• Katrs lietotāja stāsts kļūst par vienu turpmāko uzvedni.
• Katrs pieņemšanas kritērijs kļūst par kaut ko, ko pārbaudāt priekšskatījumā.
• Saraksts „nav pirmajā versijā” ir tas, ko vēl neprasāt.

Viena stāsta veidošana un tā pieņemšanas kritēriju pārbaude, pirms ejat tālāk, ir daudz uzticamāka nekā visa PRD ielīmēšana un prasīšana par visu uzreiz. Kā rakstīt uzvednes MI lietotņu veidotājiem sīkāk aplūko uzvedņu rakstīšanu.

Biežākās kļūdas

• Risinājuma rakstīšana kā problēma. „Lietotājiem vajag informācijas paneli” ir risinājums. „Īpašnieki nevar redzēt, kuri rēķini ir kavēti, neatverot katru no tiem” ir problēma.
• Nav sadaļas „ārpus darbības apjoma”. Bez tās katra saruna atver darbības apjomu no jauna.
• Ļaut MI izdomāt lietotājus. MI izveidotie tēli šķiet īsti, bet nav.
• Metrikas, ko nevar izmērīt. Ja nav veida, kā to saskaitīt, tā nav metrika.
• Nekad neatjaunināt. PRD, kas vairs neatbilst tam, ko veidojat, ir sliktāks par neko. Turiet datumu „pēdējoreiz atjaunināts” un mainiet to, kad mainās lēmumi.

PRD izmantošana ar Mythex

Ja veidojat Mythex, PRD varat ielīmēt tieši tērzēšanā. Sākt Plāna režīmā ir labi piemērots PRD: aģents to izlasa, ierosina pieeju un soļu kontrolsarakstu, ko varat pārskatīt plāna cilnē, un sāk mainīt failus tikai tad, kad nospiežat Veidot. Varat arī saglabāt daļas, kam vienmēr jābūt spēkā — auditoriju, zīmolu, noteikumus — kā projekta zināšanas, lai tās neatkārtotu katrā tērzēšanā. Tērzēšanas dokumentācija izskaidro režīmus Veidot, Plāns un Jautāt, un sagataves ir ātrs veids, kā redzēt, kā varētu izskatīties pirmā versija, pirms rakstāt pilno dokumentu.

Jautājumi