Tuotevaatimusdokumentin (PRD) pohja
Kuusi linkitettyä asiakirjaa, jotka vievät ominaisuuden ongelmasta julkaisuun: kenelle se on, mitä sen pitää tehdä, miten se kulkee, mistä tiedät sen onnistuneen, ja jokainen päätös matkan varrella. Lataa ne Markdown-tiedostoina: ne aukeavat missä tahansa editorissa, näyttävät kaavionsa GitHubissa ja Obsidianissa ja tuodaan Nodaryyn karttana.
6 Markdown-tiedostoa .zip-paketissa, 7 kt
Ilmainen, ei tiliä, ei sähköpostia. Käytä, muokkaa ja jaa vapaasti.
Lue jokainen sivu ennen lataamista
Yleiskatsaus mahtuu yhdelle näytölle ja linkittää viiteen osaan, joten kehitys, suunnittelu ja tuki löytävät kukin oman sivunsa ja muutos pysyy pienenä. Kursivoidut rivit kertovat, mitä kirjoittaa; esimerkit seuraavat yhtä esimerkkiominaisuutta, vanhenevia jakolinkkejä.
Asiakirjat
Tiedosto PRD-pohja/Tuotevaatimusdokumentti.md
Tuotevaatimusdokumentti
Näin käytät pohjaa: kursivoidut rivit ovat ohjeita. Korvaa ne omilla sanoillasi ja poista ne sitten. Hakasulkeissa olevat arvot täytät itse. Pidä tämä sivu yhdellä näytöllä: sen lukee ensin kiireinen lukija, uusi kollega tai tekoälyagentti.
Lyhyesti
| Kenttä | Tämä ominaisuus |
|---|---|
| Ominaisuus | [Nimi] |
| Yhdellä lauseella | [Mitä käyttäjä voi tehdä julkaisun jälkeen] |
| Tuotteen omistaja | [nimi] |
| Tekninen vastaava | [nimi] |
| Suunnittelun vastaava | [nimi] |
| Tila | [luonnos, tarkistettavana, hyväksytty, julkaistu] |
| Tavoiteversio | [päivämäärä tai versio] |
Ongelma
Kenellä ongelma on, mitä se maksaa nyt ja mistä tiedät sen. Ongelma ilman todisteita on arvaus: linkitä tutkimus kohtaan Käyttäjät ja todisteet.
Esimerkki (esimerkkiominaisuus): Ihmiset jakavat asiakirjan asiakkaalle tarkistettavaksi ja unohtavat sitten, että linkki on olemassa. Kuukausia myöhemmin se aukeaa yhä. Kolme asiakasta kysyi viime neljänneksellä, miten linkin saa lakkaamaan toimimasta tiettynä päivänä.
[Ongelma kahdella tai kolmella lauseella]
Tavoitteet ja rajaukset
Tavoitteet kertovat, mikä muuttuu käyttäjälle, eivät sitä, mitä tiimi rakentaa. Rajaukset ovat päätöksiä, jotka estävät laajuutta kasvamasta huomaamatta.
- Tavoite: [mitä käyttäjä voi tehdä tai mitä hänen ei enää tarvitse tehdä]
- Tavoite: [...]
- Rajaus: [mitä tämä versio jättää tarkoituksella pois]
- Rajaus: [...]
Onnistuminen yhdellä rivillä
Se yksi mittari, joka kuukauden kuluttua julkaisusta kertoo, toimiko tämä. Koko luettelo on kohdassa Julkaisu ja mittarit.
[Mittari] nousee lähtötasosta [lähtöarvo] tasolle [tavoite] mennessä [päivämäärä].
PRD:n muut osat
Jokainen osa on oma asiakirjansa. Linkitä siihen kopioimisen sijaan, jotta jokainen tieto on ja muuttuu yhdessä paikassa.
- Käyttäjät ja todisteet: kenelle ominaisuus on ja ongelman taustalla oleva tutkimus
- Vaatimukset: mitä sen pitää tehdä, prioriteetit ja hyväksymiskriteerit
- Suunnittelu ja käyttäjäpolut: käyttäjäpolku, näkymät, tilat ja reunatapaukset
- Julkaisu ja mittarit: mittarit, julkaisu ja julkaisun tarkistuslista
- Päätökset ja avoimet kysymykset: mitä päätettiin, kuka ja miksi, ja mikä on vielä auki
Pohjaa saa käyttää, muokata ja jakaa vapaasti. Se on peräisin Nodarysta, jossa nämä tiedostot tuodaan linkitettyjen asiakirjojen karttana.
Tiedosto PRD-pohja/Tuotevaatimusdokumentti/01 Käyttäjät ja todisteet.md
Käyttäjät ja todisteet
Kenelle ominaisuus on ja mitä tiedät heistä. Jokaisen väitteen tässä pitää osoittaa lähteeseensä.
Kenelle
| Kuka | Mitä hän yrittää tehdä | Mikä on esteenä |
|---|---|---|
| [Pääkäyttäjä] | [...] | [...] |
| [Toissijainen käyttäjä] | [...] | [...] |
Esimerkki (esimerkkiominaisuus): Asiakkuuspäällikkö jakaa tarjousluonnoksen asiakkaalle viikon kommentointia varten. Nyt hän asettaa muistutuksen linkin sulkemisesta ja unohtaa sen joskus.
Nyt, ilman ominaisuutta
Mitä käyttäjät tekevät nyt, vaihe vaiheelta, kiertotiet mukaan lukien. Kiertotie on usein paras määrittely, jonka saat.
- [Vaihe]
- [Vaihe]
- [Kiertotie]
Todisteet
| Lähde | Mitä se kertoo | Päivämäärä | Linkki |
|---|---|---|---|
| [Asiakashaastattelu] | [...] | [päivämäärä] | [...] |
| [Tukipyynnöt] | [...] | [...] | [...] |
| [Käyttödata] | [...] | [...] | [...] |
Avoimet kysymykset
- [Kysymys], [kuka vastaa], [mihin mennessä]
Tiedosto PRD-pohja/Tuotevaatimusdokumentti/02 Vaatimukset.md
Vaatimukset
Yksi rivi vaatimusta kohden, kirjoitettuna asiana, jonka käyttäjä voi tehdä. Prioriteetti on pakollinen, tärkeä tai toivottava: versio julkaistaan, kun jokainen pakollinen täyttyy.
Käyttäjätarinat
| ID | Roolissa | haluan | jotta | Prioriteetti |
|---|---|---|---|---|
| V1 | [käyttäjä] | [...] | [...] | [pakollinen, tärkeä, toivottava] |
| V2 | [...] | [...] | [...] | [...] |
| V3 | [...] | [...] | [...] | [...] |
Esimerkki (esimerkkiominaisuus): V1. Asiakirjan jakajana haluan valita päivän, jona linkki lakkaa toimimasta, jotta asiakas menettää pääsyn projektin päättyessä. Pakollinen.
Hyväksymiskriteerit
Jokaiselle pakolliselle tarkistukset, jotka todistavat sen toimivan. Kirjoita ne niin, että testaaja tai tekoälyagentti voi ajaa ne kysymättä sinulta.
| Vaatimus | Kun | Ja | Niin |
|---|---|---|---|
| V1 | [lähtötilanne] | [toiminto] | [tulos, jonka joku voi tarkistaa] |
| V1 | [...] | [...] | [...] |
Ei-toiminnalliset vaatimukset
| Alue | Vaatimus |
|---|---|
| Suorituskyky | [...] |
| Tietoturva ja yksityisyys | [...] |
| Saavutettavuus | [...] |
| Kielet | [...] |
| Yhteensopivuus | [selaimet, laitteet, versiot] |
Laajuuden ulkopuolella
- [Mitä tämä versio ei tee, ja miksi]
- [...]
Avoimet kysymykset
- [Kysymys], [kuka vastaa], [mihin mennessä]
Tiedosto PRD-pohja/Tuotevaatimusdokumentti/03 Suunnittelu ja käyttäjäpolut.md
Suunnittelu ja käyttäjäpolut
Linkitä suunnittelutiedostot liittämisen sijaan. Pidä tässä polku ja sen taustalla olevat päätökset, jotta teksti ja näkymät eivät koskaan ole ristiriidassa.
Käyttäjäpolku
Pääpolku siitä, mistä käyttäjä aloittaa, siihen, mitä hän saa. Jos tiimi ei osaa piirtää sitä, sitä ei ole vielä päätetty.
- AloituskohtaEnsimmäinen toiminto
- Ensimmäinen toimintoKeskeinen valinta
- Keskeinen valintaVahvistus
- VahvistusTulos
Mermaid
flowchart LR n0["Aloituskohta"] n1["Ensimmäinen toiminto"] n2["Keskeinen valinta"] n3["Vahvistus"] n4["Tulos"] n0 --> n1 n1 --> n2 n2 --> n3 n3 --> n4
Näkymät
| Näkymä | Tarkoitus | Suunnittelulinkki | Tila |
|---|---|---|---|
| [Näkymä] | [...] | [...] | [luonnos, mallikuva, valmis] |
| [Näkymä] | [...] | [...] | [...] |
Tilat
Jokaisella näkymällä on enemmän tiloja kuin onnistunut polku. Rastita jokainen, kun se on suunniteltu, tai kirjoita, miksi sitä ei voi tapahtua.
- Tyhjä: vielä ei mitään näytettävää
- Latautuu
- Virhe, ja mitä käyttäjä voi tehdä seuraavaksi
- Ei oikeuksia
- Hidas tai katkennut yhteys
- Hyvin pitkä teksti ja hyvin suuret luvut
Reunatapaukset
| Tapaus | Mitä tapahtuu |
|---|---|
| [...] | [...] |
| [...] | [...] |
Esimerkki (esimerkkiominaisuus): Joku avaa linkin minuutin päättymispäivän jälkeen: hän näkee, että linkki on vanhentunut ja keneltä kysyä, eikä koskaan virhesivua.
Avoimet kysymykset
- [Kysymys], [kuka vastaa], [mihin mennessä]
Tiedosto PRD-pohja/Tuotevaatimusdokumentti/04 Julkaisu ja mittarit.md
Julkaisu ja mittarit
Yksi päämittari, kaksi tai kolme toissijaista ja yksi suojamittari: jokin, joka ei saa heikentyä päämittarin parantuessa.
Mittarit
| Mittari | Laji | Lähtöarvo | Tavoite | Mitataan | Tarkistuspäivä |
|---|---|---|---|---|---|
| [...] | [pää] | [...] | [...] | [...] | [päivämäärä] |
| [...] | [toissijainen] | [...] | [...] | [...] | [...] |
| [...] | [suoja] | [...] | [...] | [...] | [...] |
Käyttöönotto
| Vaihe | Kuka sen saa | Päivämäärä | Jatketaan, kun |
|---|---|---|---|
| [Sisäinen] | [tiimi] | [...] | [...] |
| [Beta] | [...] | [...] | [...] |
| [Kaikki] | [...] | [...] | [...] |
Julkaisun tarkistuslista
- Ohjeartikkeli kirjoitettu
- Tukitiimi perehdytetty
- Julkaisutiedote luonnosteltu
- Analytiikkatapahtumat tarkistettu
- Peruminen testattu
Peruminen
Mikä saisi sinut sammuttamaan ominaisuuden, ja miten. Päätä se ennen julkaisua, kun kukaan ei ole vielä kiintynyt lopputulokseen.
- Perumme, jos: [...]
- Miten: [lippu, versio, skripti]
- Kuka päättää: [nimi]
Tiedosto PRD-pohja/Tuotevaatimusdokumentti/05 Päätökset ja avoimet kysymykset.md
Päätökset ja avoimet kysymykset
Kun päätös muuttaa PRD:tä, lisää tähän rivi ja päivitä sivu, jota se koskee. Loki kertoo miksi; sivu kertoo, mikä pätee nyt.
Päätösloki
| Päivämäärä | Päätös | Päättäjä | Miksi | Muutettu sivu |
|---|---|---|---|---|
| [päivämäärä] | [...] | [...] | [...] | [...] |
Esimerkki (esimerkkiominaisuus): Linkit toimivat viimeisen päivänsä loppuun omistajan aikavyöhykkeellä, eivät UTC-keskiyöhön. Päättäjinä tuotteen omistaja ja tekninen vastaava, koska betassa muiden aikavyöhykkeiden asiakkaat menettivät pääsyn päivää liian aikaisin. Muutettu sivu: Vaatimukset.
Avoimet kysymykset
| Kysymys | Kuka vastaa | Mihin mennessä | Vastaus |
|---|---|---|---|
| [...] | [nimi] | [päivämäärä] | [...] |
Näin käytät sitä
Kirjoita ongelma ennen ratkaisua
Täytä ensin yleiskatsauksen ongelma, tavoitteet ja rajaukset yhdessä ominaisuuden rakentavan kehittäjän ja suunnittelijan kanssa. Jos te kolme ette ole samaa mieltä ongelmasta, pysähtykää siihen.
Tee jokaisesta pakollisesta testattava
Anna jokaiselle pakolliselle vaatimukselle hyväksymiskriteerit, jotka joku muu voi tarkistaa. Vaatimus, jota kukaan ei voi testata, on toive.
Pyydä tarkistus ja pidä se totena
Pyydä tarkistusta, kun vaatimukset ovat valmiit, ja päivitä PRD, kun päätös muuttaa niitä. Aloitukseen jäänyt PRD on julkaisussa väärässä.
Kirjaa, mikä muuttui ja miksi
Jokainen päätös menee päätöslokiin tekijänsä kanssa. Kun joku kysyy, miksi ominaisuus toimii näin, vastaus on yhden linkin päässä.
Tuo se Nodaryyn karttana
Nodary on tekoälylle rakennettu työtila, jossa tiimin asiakirjat linkittyvät sen sijaan, että ne kasautuisivat. Tuo .zip, niin PRD saapuu viiden osansa kanssa, sivujen väliset linkit säilyvät ja kaavio piirretään. Merkitse se tarkistettavaksi ja pyydä työtilan tai projektin omistajaa tai ylläpitäjää hyväksymään se, katso, mikä on muuttunut edellisen käyntisi jälkeen, ja anna MCP:n kautta yhdistettyjen tekoälyagenttien lukea vaatimukset ennen kuin ne kirjoittavat koodia.
- Avaa projektin kartta ja valitse Tuo.
- Valitse välilehti ”Kansio tai ZIP” ja sitten ”Valitse ZIP-tiedosto”.
- Valitse ladattu tiedosto, tarkista puurakenne ja aloita tuonti.
Free-paketissa on kymmenen asiakirjaa työtilaa kohden projektin oma sivu mukaan lukien: pohjan kuusi mahtuvat uuteen työtilaan, ja tilaa jää kolmelle lisää. Nodaryssa on myös sisäänrakennettu yhden sivun tuotemäärittely (PRD).
Nodary tuote- ja kehitystiimeille
PRD, jota tiimi oikeasti käyttää
PRD epäonnistuu kahdella tavalla: se kuvaa ratkaisun, jota kukaan ei kyseenalaistanut, tai sen päivittäminen loppuu aloituksen jälkeen. Nämä tavat estävät molemmat.
Aloita ongelmasta
Kirjoita, kenellä ongelma on ja mitä se hänelle maksaa, ennen mitään ratkaisua. Ongelmasta yksimieliset tiimit riitelevät vähemmän näkymistä.
Kerro, mitä et tee
Rajauksetkin ovat päätöksiä. Niiden kirjaaminen estää ominaisuutta kasvamasta viikko kerrallaan.
Tee vaatimuksista testattavia
”Nopea” ja ”helppo” eivät ole tarkistettavissa. ”Linkki lakkaa aukeamasta minuutin kuluessa päättymispäivästä” voidaan rakentaa ja testata.
Priorisoi: pakollinen, tärkeä, toivottava
Versio julkaistaan, kun jokainen pakollinen täyttyy. Tärkeä ja toivottava ovat se, mistä joustetaan päivän lähestyessä.
Linkitä todisteet
Jokainen väite käyttäjistä linkittää haastatteluun, tikettiin tai dataan, jolla se perustellaan, jotta tarkistaja voi varmistaa sen eikä vain uskoa.
Pidä se elävänä
Päivitä PRD, kun päätös muuttaa sitä, ja kirjaa miksi. Lopuksi sen pitää kuvata se, mikä julkaistiin, ei sitä, mitä ensimmäisellä viikolla suunniteltiin.
Kysymyksiä PRD:stä
Mikä on PRD?
Tuotevaatimusdokumentti (product requirements document, PRD) kuvaa ominaisuuden tai tuotteen ennen sen rakentamista: ratkaistavan ongelman, kenelle se on, mitä sen pitää tehdä, miten onnistumista mitataan ja mikä jää ulkopuolelle. Yleensä siitä vastaa tuotepäällikkö; kehittäjät, suunnittelijat, tuki ja yhä useammin koodia kirjoittavat tekoälyagentit lukevat sitä.
Mitä PRD:n pitää sisältää?
Vähintään ongelman ja sen todisteet, tavoitteet ja rajaukset, käyttäjät, priorisoidut vaatimukset hyväksymiskriteereineen, tärkeimmät käyttäjäpolut ja reunatapaukset, onnistumisen mittarit, julkaisusuunnitelman sekä lokin päätöksistä ja avoimista kysymyksistä. Tässä pohjassa on asiakirja jokaiselle ryhmälle.
Kuinka pitkä PRD:n pitäisi olla?
Niin pitkä, että tiimi voi rakentaa ja testata ominaisuuden kysymättä sinulta samaa asiaa kahdesti. Yleiskatsauksen pitää mahtua yhdelle näytölle; vaatimukset kasvavat päätösten, eivät ideoiden mukana.
Mitä eroa on PRD:llä ja teknisellä suunnitteludokumentilla?
PRD kertoo, mitä ominaisuuden pitää tehdä ja miksi. Tekninen suunnitteludokumentti kertoo, miten järjestelmä sen tekee: arkkitehtuuri, data, rajapinnat ja riskit. Kirjoita ensin PRD ja linkitä sitten ne yhteen.
Voivatko tekoälyagentit käyttää PRD:tä?
Kyllä. Linkitetyistä asiakirjoista koostuva PRD antaa agentille sen tarvitseman kontekstin. Nodaryssa MCP:n kautta yhdistetyt agentit, kuten Claude, ChatGPT tai Cursor, lukevat vaatimukset ja päätöslokin sinun oikeuksillasi ennen kuin kirjoittavat.
Voinko käyttää pohjaa Nodaryn ulkopuolella?
Kyllä. Tiedostot ovat tavallista Markdownia: Obsidian avaa puretun kansion holvina, jossa kaikki linkit toimivat, ja GitHub näyttää tiedostot kaavioineen. Työkalut, jotka tuovat Markdownia tiedosto kerrallaan, säilyttävät tekstin ja taulukot; tarkista, miten ne käsittelevät tiedostojen välisiä linkkejä.
Pidä vaatimukset siellä, missä tiimi työskentelee.
Tuo pohja Nodaryyn, niin PRD:stä tulee kartta, jonka tiimisi ja tekoälyagenttisi pitävät ajan tasalla. Ilmainen kahdelle jäsenelle, yhdelle projektille ja kymmenelle asiakirjalle, ilman korttia.