Kaip parašyti produkto reikalavimų dokumentą su DI (nemokamas šablonas)

Produkto reikalavimų dokumentas (PRD) yra trumpas, paprasta kalba parašytas aprašymas, ką kuri, kam jis skirtas, ką jis turi daryti ir kaip sužinosi, kad jis veikia. DI jo rašymą gerokai pagreitina: duodi grubius užrašus, o ji paverčia juos struktūruotomis dalimis, naudotojų istorijomis ir kraštutiniais atvejais. Tavo darbas – pateikti sprendimus, kurių DI negali priimti, – tikslą, apimtį ir tai, kas lieka už ribų – ir patikrinti, ką ji pridėjo.

Šiame vadove aprašoma, ką turi apimti PRD, žingsnis po žingsnio pateikiamas būdas jį parašyti su bet kuriuo DI asistentu, raginimai kiekvienai daliai ir užpildomas šablonas, kurį gali nukopijuoti.

Kam skirtas PRD (ir kam ne)

PRD atsako į keturis klausimus:

1. Kodėl kuriame tai? Kokia problema ir kam?
2. Ką jis turi daryti pirmoje versijoje?
3. Ko jis dar nedarys?
4. Kaip sužinosime, kad tai veikia?

Tai nėra techninis projektas. Jame nenurodoma, kokią duomenų bazę ar karkasą naudoti – tam skirta atskira techninė specifikacija, jei jos apskritai reikia. Tai taip pat nėra rinkodaros brifas ar verslo planas. PRD laikymas prie produkto elgesio padaro jį naudingą visiems, kas jį skaito: dizaineriui, programuotojui, suinteresuotajam asmeniui, kuris pasirašo, ar DI programėlių kūrimo įrankiui, kuris paverčia jį kodu.

Kam jo reikia

• Vieni steigėjai, norintys sustabdyti apimties plitimą dar prieš jam prasidedant.
• Mažos komandos, kurioms reikia vienos vietos, kurioje gyvena „tai, dėl ko susitarėme“.
• Visi, kurie samdo laisvai dirbantį specialistą ar agentūrą, nes aiškus PRD sulaukia aiškesnių pasiūlymų. Žr. samdyti kūrėją arba kurti su DI.
• Visi, kurie kuria su DI, nes PRD naudotojų istorijos ir duomenų sąrašas duoda geresnes užklausas nei nestruktūruotas norų sąrašas.

Ką DI daro gerai – o ką ne

Dažniausia klaida – priešpaskutinės eilutės apvertimas: DI pasitikinčiai užpildo spragas įtikinamais spėjimais apie tavo naudotojus. Viską, ką ji rašo apie naudotojus, rinkos dydį ar elgesį, laikyk klausimu, kurį reikia patikrinti, o ne faktu.

1 žingsnis: surink tai, ką žinai

Prieš bet kokią užklausą užsirašyk grubius užrašus. Tinka punktai. Aptark:

• Problemą vienu ar dviem sakiniais, naudotojo akimis.
• Kas su ja susiduria. Būk konkretus: „laisvai dirbantys buhalteriai su 10–40 klientų“, o ne „mažos įmonės“.
• Ką jie daro dabar (skaičiuoklę, el. laišką, įrankį, kurio nemėgsta).
• Vieną rezultatą, kuris pirmąją versiją padarytų sėkminga.
• Tai, ko tikrai nedarysi.
• Griežtus apribojimus: terminą, biudžetą, būtinybę veikti telefonuose, integraciją su jau naudojamu įrankiu.

Jei dar nekalbėjai su nei vienu, kuris turi šią problemą, pirma tai padaryk. Kaip patikrinti programėlės idėją pateikia praktišką būdą. PRD, pagrįstas spėjimais, – tai gerai suformatuotas spėjimas.

2 žingsnis: paprašyk DI pirminio juodraščio

Įklijuok savo užrašus ir paprašyk juodraščio fiksuota struktūra. Veikiantis raginimas:

Štai mano užrašai apie produktą. Paverskite juos produkto reikalavimų dokumentu, naudodami tiksliai šias dalis: Santrauka, Problema, Naudotojai, Tikslai ir sėkmės metrikos, Apimtis (į / ne), Naudotojų istorijos su priėmimo kriterijais, Duomenys, Teisės, Kraštutiniai atvejai, Atviri klausimai. Laikykitės dviejų puslapių ribos. Neišgalvokite faktų apie naudotojus ar rinką – kur mano užrašai nepasako, parašykite klausimą skiltyje Atviri klausimai.

Paskutinė instrukcija svarbi. Nurodymas DI nežinomus dalykus nukreipti į „Atviri klausimai“, o ne užpildyti, duoda gerokai sąžiningesnį juodraštį.

3 žingsnis: sutvirtink kiekvieną dalį

Pereik juodraštį dalis po dalies. Šie tolesni raginimai padeda:

Problema ir naudotojai

Perrašyk problemos aprašymą vienu ar dviem sakiniais naudotojo akimis. Be sprendimo žodžių.

Jei problemos aprašyme mini tavo produktą, jis aprašo sprendimą, o ne problemą.

Tikslai ir sėkmės metrikos

Pasiūlyk tris sėkmės metrikas pirmai versijai, kurias galėčiau išmatuoti per pirmą mėnesį su nedideliu naudotojų skaičiumi. Kiekvienai nurodyk, kaip ją matuočiau.

Pasirink vieną ar dvi. „Dvidešimt buhalterių naudoja jį kas savaitę per mėnesį“ yra išmatuojama. „Pagerinti produktyvumą“ – ne.

Apimtis

Išvardyk visa, kas šiame PRD galėtų būti perkelta į vėlesnę versiją, nesugriaunant pagrindinio srauto.

DI įrankiai linkę pridėti funkcijų. Ši užklausa daro priešingai. Būk nuoseklus: dauguma pirmos versijos PRD per dideli. Kas yra MVP paaiškina, kodėl mažos pirmos versijos moko daugiau.

Naudotojų istorijos ir priėmimo kriterijai

Kiekvieną reikalavimą parašyk kaip naudotojo istoriją („Kaip [naudotojas], noriu [veiksmo], kad [rezultatas]“) su dviem–keturiais priėmimo kriterijais Duota / Kai / Tada forma.

Priėmimo kriterijai – tai kontrolinis sąrašas, pagal kurį vėliau testuosi. „Duota užimta laiko vieta, kai kitas klientas žiūri kalendorių, tada ta vieta nerodoma“ yra patikrinama. „Rezervavimas veikia gerai“ – ne.

Kraštutiniai atvejai ir teisės

Kiekvienai naudotojo istorijai išvardyk, kas nutinka su tuščiais duomenimis, neteisingu įvedimu, lėta arba nepavykusia tinklo užklausa ir naudotoju, kuris neturėtų turėti prieigos.

Čia DI duoda naudos. Ji greitai pastebi tuščias būsenas ir teisių spragas, kurių žmonės dažnai nepastebi.

4 žingsnis: peržiūrėk kaip skeptikas

Perskaityk visa dar kartą ir patikrink:

• Kiekvienas teiginys apie naudotojus kilo iš tavęs ar tyrimo, o ne iš DI.
• Apimties „ne“ dalis bent tokia pat ilga kaip „taip“ dalis.
• Kiekviena naudotojo istorija turi priėmimo kriterijus, kuriuos kas nors gali patikrinti neklausdamas tavęs.
• Duomenų skyrius išvardija kiekvieno įrašo tipą, kurį programa saugo, ir kas jį mato.
• Atviri klausimai turi atsakingą asmenį ir datą.
• Nieko techninio neįsliūkino, nebent tai tikras apribojimas („turi veikti be interneto“ yra reikalavimas; „naudoti Redis“ – ne).

Tada parodyk vienam asmeniui, kuris naudos ar kurs produktą, ir paklausk, kas neaišku. Jų klausimai – tai spragos.

Užpildomas PRD šablonas

Nukopijuok tai į dokumentą ir pakeisk laužtinius skliaustus. Ištrink visas dalis, kurios iš tikrųjų netinka.

Produkto pavadinimas: [pavadinimas] Atsakingas asmuo: [asmuo, atsakingas už sprendimus] Būsena: [juodraštis / peržiūroje / suderinta] – Paskutinį kartą atnaujinta: [data]

1. Santrauka

[Du ar trys sakiniai: kas tai yra, kam tai skirta ir pagrindinis rezultatas.]

2. Problema

[Problema naudotojo akimis. Ką jie daro dabar ir kodėl tai skaudina.]

3. Naudotojai

4. Tikslai ir sėkmės metrikos

• Tikslas: [rezultatas, kurio pirma versija turi pasiekti]
• Metrika: [kaip tai matuosi ir tikslas]
• Ne tikslas: [kas, ką žmonės gali manyti, kad ši versija bando daryti, bet nedaro]

5. Apimtis

Pirmoje versijoje:

• [funkcija]
• [funkcija]

Ne pirmoje versijoje:

• [funkcija ir kodėl ji gali palaukti]
• [funkcija ir kodėl ji gali palaukti]

6. Naudotojų istorijos

1 istorija: Kaip [naudotojas], noriu [veiksmo], kad [rezultatas].

• Duota [kontekstas], kai [veiksmas], tada [rezultatas].
• Duota [kontekstas], kai [veiksmas], tada [rezultatas].

2 istorija: Kaip [naudotojas], noriu [veiksmo], kad [rezultatas].

• Duota [kontekstas], kai [veiksmas], tada [rezultatas].

7. Duomenys

8. Teisės

[Kas gali prisijungti, kokie yra vaidmenys ir ką kiekvienas vaidmuo gali matyti ir keisti.]

9. Kraštutiniai atvejai

• [Tuščia būsena: kas rodoma, kai duomenų dar nėra]
• [Neteisingas įvedimas: kas nutinka su neteisingu el. paštu ar trūkstamu lauku]
• [Prieiga: kas nutinka, kai kas nors atidaro puslapį, kurio neturėtų matyti]

10. Integracijos ir apribojimai

[Mokėjimai, el. paštas, esami įrankiai, terminai, biudžetas, įrenginiai, kuriuose turi veikti.]

11. Atviri klausimai

Nuo PRD iki užklausų

Geras PRD beveik tiesiogiai virsta užklausomis DI programėlių kūrimo įrankiui:

• Santrauka, naudotojai ir duomenų lentelė tampa tavo pirmąja užklausa.
• Kiekviena naudotojo istorija tampa viena tolesne užklausa.
• Kiekvienas priėmimo kriterijus tampa tuo, ką patikrini peržiūroje.
• Sąrašas „ne pirmoje versijoje“ yra tai, ko dar neprašai.

Kurti po vieną istoriją ir prieš judant toliau patikrinti jos priėmimo kriterijus yra gerokai patikimiau, nei įklijuoti visą PRD ir prašyti viso iš karto. Kaip rašyti užklausas DI programėlių kūrimo įrankiams išsamiau aprašo užklausų pusę.

Dažniausios klaidos

• Sprendimo rašymas kaip problemos. „Naudotojams reikia skydelio“ yra sprendimas. „Savininkai negali matyti, kurios sąskaitos pradelstos, neatidarę kiekvienos“ yra problema.
• Nėra skyriaus „ne apimtyje“. Be jo kiekvienas pokalbis atidaro apimtį iš naujo.
• Leidimas DI išgalvoti naudotojus. DI sugalvoti personažai atrodo tikri, bet tokie nėra.
• Metrikos, kurių negali išmatuoti. Jei neturi būdo tai suskaičiuoti, tai nėra metrika.
• Niekada neatnaujinimas. PRD, kuris nebeatitinka to, ką kuri, yra blogesnis nei jokio. Laikyk datą „paskutinį kartą atnaujinta“ ir keisk ją, kai pasikeičia sprendimai.

PRD naudojimas su Mythex

Jei kuri Mythex, gali įklijuoti savo PRD tiesiai į pokalbį. Plan režimas tinka PRD: agentas jį perskaito, pasiūlo metodą ir žingsnių sąrašą, kurį gali peržiūrėti plano skirtuke, ir pradeda keisti failus tik tada, kai paspaudi Build. Taip pat gali išsaugoti dalis, kurios turi galioti visada – auditoriją, prekės ženklą, taisykles – kaip projekto žinias, kad nekartotum kiekviename pokalbyje. Pokalbio dokumentacija paaiškina Build, Plan ir Ask režimus, o šablonai – greitas būdas pamatyti, kaip gali atrodyti pirma versija, prieš rašant visą dokumentą.

Klausimai