Tuotevaatimusmäärittelyn (PRD) mallipohja (+ täysi työstetty esimerkki kopioitavaksi)

Tuotevaatimusmäärittelyn (PRD) mallipohja (+ täysi työstetty esimerkki kopioitavaksi)

Viimeksi päivitetty: 28. heinäkuuta 2026.

Useimmat tuotevaatimusmäärittelyn mallipohjaa koskevat sivut antavat sinulle tyhjän lomakkeen. Atlassianin versio on neljä osiota ohjeita tyhjän tulosmittaritaulukon ympärillä. Product Schoolin mallissa lukee otsikossa "(with Example)", mutta esimerkkiä ei löydy mistään. Alla oleva 12-osainen Markdown-lohko on koko mallipohja, vapaasti saatavilla, suoraan kopioitavissa. Osio 4 täyttää sitten jokaisen näistä 12 osiosta täydelle työstetylle rakennukselle: asiakkaan laskujen käsittelyportaalille, joka lukee PDF-tiedostoja tekoälykielimallilla ja ohjaa epäselvät tapaukset ihmisen tarkistettavaksi. Kopioi tyhjä. Lue täytetty. Kirjoita oma.

Keskeiset huomiot

• PRD vastaa siihen, mitä rakennetaan ja miksi; tekninen suunnitteludokumentti vastaa siihen, miten.
• 12 osiota sopivat mihin tahansa projektin kokoon. Yksisivuinen versio on sama mallipohja, jossa on vähemmän rivejä.
• Ei-tavoitteet on kirjoitettava näkyviin. Tekoälykoodausagentti ei pysty päättelemään laajuutta poisjätöistä.
• Hyväksymiskriteerien on oltava koneella tarkistettavissa: "p95 alle 400 ms", ei koskaan "nopea".

Minkä muotoisen PRD:n pitäisi käyttää?

Valitse muoto sen mukaan, kuka dokumentin lukee, ei sen mukaan, miltä tuote tuntuu kokonsa puolesta. Yksittäinen ominaisuus, joka menee omille insinööreillesi, tarvitsee yksisivuisen version. Rakennus, joka annetaan ulkopuoliselle tiimille, tarvitsee täyden 12-osaisen PRD:n, koska hyväksymiskriteerit toimivat samalla hyväksymisportteina. Tekoälykoodausagentille menevä määrittely tarvitsee samat kaksitoista osiota, mutta vaiheisiin pilkottuna.

Yhden sivun tuotevaatimusmäärittelyn mallipohja, jota kaikki kysyvät, ei ole erillinen dokumentti. Lenny Rachitskyn laajalti kopioitu yksisivuinen versio, julkaistu oikeiden esimerkkien kanssa hänen uutiskirjeessään, on sama runko ilman turhaa muodollisuutta. Yksisivuinen versio ei ole eri dokumentti. Se on samat kaksitoista osiota, joista tyhjät rivit on poistettu.

Ketterät tiimit kysyvät tätä paljon myös, yleensä muodossa: pysyykö PRD käyttökelpoisena, kun backlog on olemassa. Pysyy, yksisivuisena versiona: PRD pitää sisällään syyn ja rajat, tiketit pitävät sisällään työn.

PRD-mallipohja (kopioi Markdown-muodossa)

Tässä koko juttu Markdown-muodossa, vapaasti saatavilla, ei sähköpostimuuria. Liitä se Notioniin, Confluenceen, Google Docsiin, Lineariin, Wordiin, tai commitoi se GitHubiin tiedostona PRD.md ja anna sen versioitua koodin rinnalla. Ihmiset pyytävät tätä mallipohjaa yhdeksässä eri muodossa; Markdown on se, joka selviää liittämisestä kaikkiin niihin, ja se on ainoa muoto, jota tekoälykoodausagentti lukee siististi.

# PRD: [Product or feature name]

## 1. Header
- Owner (product):
- Engineering lead:
- Design lead:
- Status: Draft | In review | Approved | Shipped
- Last updated:
- Change history: date / author / what changed

## 2. Problem statement
One paragraph. Who hurts, how often, what it costs today. No solution language.

## 3. Goals & success metrics
| Goal | Metric | Baseline | Target | Measured by | Date |
|---|---|---|---|---|---|

## 4. Non-goals
Stated positively: "This phase does not include X."

## 5. Users & personas
Who uses it, what they already know, which device, how often.

## 6. User stories & acceptance criteria
As a [persona], I want [action], so that [outcome].
- Given [context], when [event], then [observable result].

## 7. Functional requirements
Numbered. One requirement per line. Testable. No sentence containing "and".

## 8. Non-functional requirements
Performance / security & tenancy / data residency & retention / accessibility / availability.

## 9. Dependencies & integrations
External systems, APIs, credentials, who owns access, lead time.

## 10. Milestones & phasing
| Phase | Scope | Exit criteria | Target date |
|---|---|---|---|

## 11. Open questions & risks
| Question or risk | Owner | Needed by | Impact if unanswered |
|---|---|---|---|

## 12. Appendix & links
Designs, research, competitor notes, prior tickets, contracts.

Kaksitoista osiota, järjestyksessä: otsikkotiedot, ongelmakuvaus, tavoitteet ja tulosmittarit, ei-tavoitteet, käyttäjät ja persoonat, käyttäjätarinat hyväksymiskriteereineen, toiminnalliset vaatimukset, ei-toiminnalliset vaatimukset, riippuvuudet ja integraatiot, virstanpylväät ja vaiheistus, avoimet kysymykset ja riskit, liite.

Mitä PRD:n pitäisi sisältää? 12 osiota, ja kunkin heikko versio

Tuotevaatimusmäärittelyn pitäisi sisältää ongelmakuvaus, mitattavat tavoitteet, selkeät ei-tavoitteet, persoonat, käyttäjätarinat hyväksymiskriteereineen, toiminnalliset ja ei-toiminnalliset vaatimukset, riippuvuudet, virstanpylväät, avoimet kysymykset omistajineen sekä muutoshistoria. Kaikki muu on liitettä. Testi jokaiselle riville on sama, jota ISO/IEC/IEEE 29148:2018 soveltaa vaatimuksiin yleisesti: todennettavissa, yksiselitteinen, yksittäinen.

Useimmat PRD:t epäonnistuvat tässä testissä samoissa kolmessa kohdassa.

Kaksi osiota ansaitsee enemmän huomiota kuin ne yleensä saavat.

Ei-toiminnalliset vaatimukset ovat se kohta, jossa laajuus kasvaa huomaamatta kaksinkertaiseksi. Suorituskyky, vuokralaiseristys, datan sijaintimaa, säilytysaika, saavutettavuus, käytettävyys: jokainen niistä on insinöörityön päätös, jolla on hintansa, eikä yksikään niistä näy käyttäjätarinassa. Kirjoita tietoturvarivi tähän sen sijaan, että vetoat epämääräisyyteen, ja kirjoita se niin kuin haluaisit sen tarkistettavan — käytä esimerkiksi omaa julkaisua edeltävää tietoturvatarkistuslistaamme lähdeluettelona. Jos rakennuksessa on tekoälykomponentti, tuotantovalmiuden vaatimukset kuuluvat myös tähän, ei myöhempään "kovennus"-vaiheeseen, jota ei koskaan aikatauluteta: PoC:sta tuotantoon -tarkistuslistamme on versio, jota me käytämme.

Avoimet kysymykset tarvitsevat kolme saraketta, ei yhtä. Kysymys, omistaja, tarvitaan-mennessä-päivämäärä. Kysymys ilman omistajaa on päätös, jota kukaan ei tee, ja se nousee esiin muutospyyntönä kuudennella viikolla. Kannattaa muistaa: PRD on se, mitä kirjoitat sen jälkeen, kun olet päättänyt rakentaa ostamisen sijaan. Jos ongelmakuvaus lukee edelleen kuin ostoslista ominaisuuksista, rakenna-vai-osta-päätöstä ei ole vielä oikeasti tehty.

Työstetty esimerkki: laskujen käsittelyportaalin PRD, täytettynä

Tässä on täydellinen työstetty esimerkki, kaikki 12 osiota täytettyinä. Rakennus: asiakkaan laskujen käsittelyportaali keskikokoiselle logistiikkatoimijalle. Asiakkaat lataavat PDF-laskuja, tekoälykielimalli poimii rivikohdat, järjestelmä merkitsee poikkeamat tilaustietoihin verrattuna, ja kaikki epävarma menee ihmisen tarkistusjonoon. Teknologiapino: Next.js, Supabase/Postgres, yksi tekoälykielimallin poimintavaihe. Kopioi se, tulosta se, vie se PDF-muotoon, mitä ikinä tarvitset.

# PRD: Client Invoice Portal, Phase 1

## 1. Header
- Owner (product): Ops director, client side
- Engineering lead: Delivery lead, Techsy
- Design lead: Product designer, Techsy
- Status: Approved for build
- Last updated: 2026-07-28
- Change history:
  - 2026-07-14 / product / first draft
  - 2026-07-21 / engineering / added confidence-threshold rule to 6.2
  - 2026-07-28 / product / moved ERP write-back to non-goals

## 2. Problem statement
Ops staff receive customer invoices as emailed PDFs and re-key them into the
order system by hand. Volume runs past 300 invoices a week, average handling
time is about 6 minutes each, and roughly 4% carry a keying error caught only
at month-end reconciliation. Every correction costs a second pass and a call.

## 3. Goals & success metrics
| Goal | Metric | Baseline | Target | Measured by | Date |
|---|---|---|---|---|---|
| Cut manual handling | Avg. handling time | 6 min | under 90 sec | Ops dashboard, weekly median | 2026-11-01 |
| Cut keying errors | Invoices corrected at reconciliation | 4% | under 1% | Finance month-end report | 2026-12-01 |
| Contain review load | Share routed to human review | n/a | under 25% | Portal queue metrics | 2026-11-01 |

## 4. Non-goals
This phase does not support multi-currency invoices, ERP write-back, customer
self-service credit notes, or a mobile app. Extraction covers PDF only.
Photographs of paper invoices and scans below 200 DPI are rejected at upload
with a message explaining why.

## 5. Users & personas
- Ops clerk (primary, 6 people): works the exception queue all day, deep
  domain knowledge, desktop only.
- Customer AP contact (external, ~140 accounts): uploads invoices, low
  tolerance for account-setup friction.
- Finance manager (secondary): pulls the month-end report, needs a per-invoice
  audit trail.

## 6. User stories & acceptance criteria
6.1 As a customer AP contact, I want to upload an invoice PDF, so that I don't
have to email it and wait.
- Given a PDF under 20 MB at 200 DPI or better, when I upload it, then the
  portal returns a reference number within 5 seconds and shows "Processing".

6.2 As an ops clerk, I want low-confidence extractions held back, so that
nothing wrong is auto-approved.
- Given a parsed invoice, when extraction confidence for any line item is
  below 0.85, then the invoice routes to the review queue and is never
  auto-approved.

6.3 As an ops clerk, I want to see the mismatch in one place, so that I can
resolve it without opening the order system.
- Given an invoice matched to an order, when any line quantity or unit price
  differs from the order record, then the portal shows both values side by
  side and flags the delta.

6.4 As a finance manager, I want to filter invoices, so that I can close the
month.
- Given the invoice list, when I filter by vendor, date range and status, then
  results return in under 400ms at p95 and the empty state offers "Clear
  filters".

## 7. Functional requirements
1. Upload accepts PDF only, 20 MB maximum, one file per submission.
2. Extraction returns vendor, invoice number, date, currency, and line items
   with quantity, unit price and total.
3. Each line item carries a confidence score between 0 and 1.
4. Matching compares the extracted invoice to the open order by PO number.
5. Exceptions enter a queue ordered oldest first, assignable to one clerk.
6. Every state change writes an audit entry with actor, timestamp, prior value.
7. Approved invoices export as a CSV batch for the finance system.

## 8. Non-functional requirements
- Performance: invoice list p95 under 400ms. Extraction completes within 90
  seconds of upload at p95.
- Security & tenancy: per-tenant isolation enforced at the database row level.
  A customer can never read another customer's invoice. Verified by an
  automated test on every release.
- Data residency & retention: documents stored in the EU. Originals retained 7
  years, extraction payloads 90 days.
- Accessibility: queue fully keyboard-operable, WCAG 2.2 AA contrast.
- Availability: 99.5% monthly, support during business hours.

## 9. Dependencies & integrations
- Order records: read-only Postgres replica. Access owned by client IT,
  credentials needed by 2026-08-15.
- LLM extraction provider: contract and data-processing agreement signed
  before build starts.
- Email notifications: existing transactional provider, sender domain verified
  by the client.

## 10. Milestones & phasing
| Phase | Scope | Exit criteria | Target date |
|---|---|---|---|
| P1 | Upload, extraction, confidence routing | 50 real invoices end to end, under 25% queued | 2026-09-19 |
| P2 | Order matching and mismatch view | Mismatch flagged correctly on 20 seeded cases | 2026-10-10 |
| P3 | Audit trail, CSV export, reporting | Finance closes one month in the portal | 2026-11-01 |

## 11. Open questions & risks
| Question or risk | Owner | Needed by | Impact if unanswered |
|---|---|---|---|
| Which PO number is authoritative when an invoice shows two? | Client ops director | 2026-08-08 | Matching logic blocked |
| Do the 12 largest customers send scanned or native PDFs? | Delivery lead | 2026-08-08 | Confidence threshold may be wrong |
| Is 7-year retention confirmed with client counsel? | Client finance manager | 2026-08-22 | Storage design and cost change |
| Extraction cost per invoice at 300/week | Delivery lead | 2026-09-05 | Unit economics unknown |

## 12. Appendix & links
Anonymized sample invoice set (40 files), order-table schema, current
handling-time study, Figma flows for upload and queue, signed statement of work.

Neljä valintaa siellä ansaitsee erityismaininnan, koska kunkin laiska versio maksaa oikeaa rahaa.

Osio 3, lähtötaso. "6 minuuttia" ei ole koristetta. Ilman lähtötasoa ei voi tietää, toimiko asia, ja kuusi kuukautta myöhemmin joku väittelee siitä kokouksessa ilman dataa. Laiska versio, "paranna tehokkuutta", tekee projektista kumoamattoman.

Osio 4, ei-tavoite. ERP-takaisinkirjoitus siirrettiin ei-tavoitteisiin 2026-07-28, sen jälkeen kun se oli oletettu olemassa olevaksi katselmointipuhelun aikana. Sen kirjoittaminen ei-tavoitteeksi maksoi yhden rivin ja säästi laajuuskiistan.

Osio 6.2, luottamuskynnys. Tämä on sääntö, jonka omat ensimmäiset luonnoksemme jättävät useimmin väliin. Jätä se pois, ja järjestelmä hyväksyy automaattisesti laskuja, jotka ihmisen olisi pitänyt nähdä — mikä on juuri se epäonnistuminen, joka mitätöi osiossa 3 luvatut ajansäästöt.

Osio 11, omistajat. Jokaisella avoimella kysymyksellä on nimi ja päivämäärä. Se sarake on ero dokumentin ja sellaisen tehtävälistan välillä, jota kukaan ei omista.

PRD kertoo, mitä. Se ei kerro, kuinka kauan tai kuinka paljon, mikä on eri asia: katso rakennuksen rajaaminen siitä puoliskosta. Ja ei-tavoite, jota et kirjoittanut ylös, on ominaisuus, jonka joku rakentaa.

Miten kirjoitat PRD:n, josta tekoälykoodausagentti pystyy oikeasti rakentamaan?

Tekoälykoodausagentille kirjoitettu PRD vaihtaa lyhyyden selkeyteen. Agentilla ei ole epävirallista jaettua kontekstia, ei yhteistä historiaa, eikä vaistoa sille, mitä ilmiselvästi et tarkoittanut. Neljä sääntöä kattaa suurimman osan erosta, ja ne perustuvat siihen, mitä olemme havainneet omissa tekoälyavusteisissa rakennusprojekteissamme onnistuneiden ja epäonnistuneiden määrittelyjen kautta.

1. Ilmaise ei-tavoitteet myönteisesti. Ihmiset päättelevät laajuuden poisjätöistä. Agentit eivät. "Älä lisää todennusta tähän vaiheeseen" pitää olla kirjoitettu lause dokumentissa, tai todennus rakennetaan, testataan ja annetaan sinulle takaisin.

2. Mitoita työ vaiheisiin. Yksi 40-sivuinen monoliitti tuottaa itsevarman, rönsyilevän, puoliksi oikean pull requestin. Pilko PRD osiin, jotka agentti saa valmiiksi yhdellä rajatulla ajolla, kullakin omat päätöskriteerinsä.

3. Tee hyväksymiskriteereistä koneella tarkistettavia. "Nopea" ei ole vaatimus, vaan fiilis. "p95 alle 400 ms laskulistan päätepisteessä" on testi, jonka agentti voi kirjoittaa ennen kuin se kirjoittaa ominaisuuden.

4. Laita tiedostopolut ja teknologiarajoitteet dokumenttiin, ei chattiin. Chat-konteksti haihtuu istuntojen välillä. Määrittely ei haihdu. Tämän vuoksi myös Claude Coden suunnittelutila on tärkeä: se lukee tiedostosi ja ehdottaa suunnitelman muokkaamatta mitään ennen kuin hyväksyt sen, ja tuo hyväksymisvaihe on paljon hyödyllisempi, kun suunnitelmaa tarkistetaan kirjoitettua määrittelyä vasten eikä sitä vasten, mitä muistat pyytäneesi.

Tässä laskujen käsittelyportaali, pilkottuna yhteen vaiheeseen, jonka agentti pystyy suorittamaan yhdellä ajolla.

# Build task: Invoice upload and extraction (Phase 1 of 3)

## Stack constraints (do not substitute)
Next.js 15 App Router, TypeScript, Supabase Postgres with row-level security,
Vercel deploy. No new dependencies without asking first.

## Files you may create or edit
- app/(portal)/invoices/upload/page.tsx
- app/api/invoices/route.ts
- lib/extraction/parse-invoice.ts
- supabase/migrations/0007_invoices.sql

## Do not touch
- lib/auth/*  (auth ships in Phase 2; do not add sign-in flows now)
- Anything under app/(marketing)/
- The existing orders schema. Read it. Never migrate it.

## Acceptance criteria (write these as tests first)
1. POST /api/invoices rejects non-PDF with 415 and files over 20 MB with 413.
2. A line item with confidence < 0.85 sets invoice.status = 'review',
   never 'approved'.
3. Every insert writes an audit row with actor_id, action, created_at.
4. GET /api/invoices?vendor=&from=&to=&status= returns under 400ms on a
   10,000-row seed.

## Out of scope for this pass
Order matching, mismatch UI, CSV export, email notifications.

Kolme asiaa muuttui ihmisversioon verrattuna: tiedostopolut ilmestyivät, älä-koske-lista ilmestyi, ja hyväksymiskriteereistä tuli väittämiä lauseiden sijaan. Sillä, kenelle agentille sen antaa, on vähemmän merkitystä kuin luulisi, vaikka koodausagenttien vertailu kannattaa lukea ennen sitoutumista. Pidä vaatimukset ja projektisäännöt eri tiedostoissa: Cursor rules ja CLAUDE.md pitävät sisällään käytännöt ja työkalut, PRD pitää sisällään sen, mitä rakennetaan. Jos haluat tekoälyn apua laajuuden tuottamiseen alun perin sen kuluttamisen sijaan, se on eri työnkulku. Ja itse poimintavaiheelle mallivalinta ja arviointisilmukka ovat oma tekoälyintegraatiotyönsä.

Mitä muuttuu, kun PRD menee ulkopuoliselle tiimille?

Kun PRD menee toimistolle tai alihankkijalle, se lakkaa olemasta yhteisymmärrysdokumentti ja alkaa olla sopimuskieltä. Epäselvyys, jonka sisäinen tiimi ratkaisisi kahden minuutin keskustelulla, muuttuu muutospyynnöksi, jolla on hinta. PMI:n Pulse of the Profession -tutkimus havaitsi, että 47 % epäonnistuneista projekteista jää tavoitteistaan epätarkan vaatimustenhallinnan takia. Se on koko syy tämän dokumentin olemassaoloon.

Kolme osiota kantaa suhteettoman suurta painoa tässä asetelmassa. Hyväksymiskriteereistä tulee hyväksymisportteja, joten niiden pitää olla havaittavissa jonkun toimesta, joka ei ole insinööri. Avoimilla kysymyksillä tarvitsee olla nimetty omistaja asiakkaan puolella, koska toimittaja ei voi vastata niihin ja rakentaa aukon ympärille. Ja muutoshistoria lakkaa olemasta byrokratiaa: se on tallenne siitä, mitä sovittiin ja milloin, mikä on ensimmäinen asia, johon kaikki tarttuvat erimielisyyden sattuessa.

Rivi, jonka olemme nähneet menevän pieleen useammin kuin kerran, on jokin versio lauseesta "käyttäjät voivat viedä datansa ulos". Kukaan ei kirjoita ylös, missä muodossa. Kallis versio tästä meille toteutui CSV-vientinä, kun asiakas oli tarkoittanut muotoiltua PDF-laskupakettia omalla brändäyksellään, ja sen uudelleentekeminen poltti suunnilleen viikon insinöörityötä, jota kukaan ei ollut rajannut. Rehellinen tulkinta on, että vika oli dokumentissa, ei toimituksessa. Hyväksymiskriteeri olisi kiinni sen viidessä minuutissa: kun vientipyyntö tehdään, kun tiedosto luodaan, silloin se on PDF, joka vastaa annettua asettelua. Ei-tavoite-rivi olisi kiinni sen myös, toisesta suunnasta. Joten se on nyt sääntö meidän tarvekartoituksessamme: mikä tahansa vaatimus, joka riippuu substantiivista kuten "vienti", "raportti" tai "ilmoitus", saa muodon, laukaisijan ja työstetyn esimerkin liitettynä ennen kuin työsopimus allekirjoitetaan.

Suurin osa siitä, mitä tapamme toteuttaa verkkosovellusrakennuksia tarkoittaa, on juuri tätä: asiakkaan määrittelyn epämääräisen puoliskon muuttaminen testattaviksi riveiksi ennen kuin kukaan kirjoittaa koodia.

Mitä r/ProductManagement oikeasti sanoo PRD-mallipohjista?

Hae product requirements document template reddit, ja löydät saman valituksen toistuvan uudelleen ja uudelleen alafoorumilla r/ProductManagement: mallipohjan paisuminen. PRD:t, joita kukaan ei lue. Osioita täytetty, koska mallipohjassa oli otsikko, ei siksi, että kukaan tarvitsi sisältöä. Dokumentteja, jotka vanhenevat heti käynnistyksen jälkeen ja korvataan hiljaa Slack-keskustelulla. Se on reilu kritiikki useimmille mallipohjille, myös useille tämän haun kymmenen kärkituloksen joukossa.

Meidän vastauksemme: poista osioita sen sijaan, että täyttäisit ne tyhjällä. Persoonat menevät ensin, kun käyttäjät ovat ilmeisiä. Liite menee toiseksi. Virstanpylväät voivat asua seurantatyökalussa mallipohjan sijaan. Se, jota emme koskaan poista, on ei-tavoitteet, koska se on ainoa osio, joka lyhenee mitä enemmän työtä teet, ja ainoa, joka luotettavasti estää sen väittelyn, joka muuten syntyisi kuudennella viikolla.

Kirjoittajasta

Mert Batur Gurbuz, perustajaosakas, Techsy.io. Meriitit: perustajaosakas, Techsy.io, University of Birmingham. LinkedIn

Mert Batur Gurbuz on Techsy.io:n perustajaosakas, jossa tiimi toimittaa tekoälyagentteja, automaatiojärjestelmiä sekä ääni- ja SDR-putkia B2B-asiakkaille. Hän opiskelee University of Birminghamissa ja kirjoittaa LLM-työkalupinosta, jota Techsy-tiimi oikeasti käyttää tuotannossa.

Usein kysytyt kysymykset

Mikä on tuotevaatimusmäärittely?

Tuotevaatimusmäärittely (PRD) kertoo, mitä tiimi rakentaa ja miksi: ongelman, tavoitteet mittareineen, ei-tavoitteet, kenelle se on tarkoitettu, sekä vaatimukset, jotka määrittelevät "valmiin". Se sulkee tarkoituksella pois toteutuksen yksityiskohdat, jotka kuuluvat teknisiin suunnitteludokumentteihin, jotka insinöörit kirjoittavat myöhemmin.

Miten kirjoitat tuotevaatimusmäärittelyn?

Aloita ongelmakuvauksesta ja kieltäydy käyttämästä siinä ratkaisukieltä. Lisää mitattavat tavoitteet lähtötasoineen ja tavoitepäivämäärineen, kirjoita sitten ei-tavoitteet. Täytä persoonat, käyttäjätarinat Given/When/Then-hyväksymiskriteereineen, toiminnalliset ja ei-toiminnalliset vaatimukset, riippuvuudet, virstanpylväät sekä avoimet kysymykset omistajineen.

Mitä PRD:n pitäisi sisältää?

Kaksitoista osiota: otsikkotiedot muutoshistorioineen, ongelmakuvaus, tavoitteet ja tulosmittarit, ei-tavoitteet, käyttäjät ja persoonat, käyttäjätarinat hyväksymiskriteereineen, toiminnalliset vaatimukset, ei-toiminnalliset vaatimukset, riippuvuudet ja integraatiot, virstanpylväät ja vaiheistus, avoimet kysymykset ja riskit, sekä liite. Kaikki, mikä ei sovi mihinkään näistä, ei todennäköisesti ole vaatimus.

Kuinka pitkä PRD:n pitäisi olla?

Yhdestä kahteen sivua yksittäiselle ominaisuudelle, kolmesta viiteen tuotevaiheelle, viidestä kahdeksaan, kun ulkopuolinen tiimi rakentaa sitä ja hyväksymiskriteerit toimivat hyväksymisportteina. Pituus seuraa kirjattujen päätösten määrää, ei tuotteen kokoa. Tyhjät osiot pitäisi poistaa, ei täyttää täytteellä.

Onko PRD sama asia kuin BRD?

Ei. Liiketoimintavaatimusdokumentti (BRD) kertoo kaupallisen lopputuloksen, jota organisaatio haluaa, ja siihen liittyvät rajoitteet, yleensä ennen kuin ratkaisu on valittu. PRD kuvaa tuotteen, joka toimittaa sen: käyttäjät, käyttäytymisen, hyväksymiskriteerit, ei-tavoitteet. Pienemmissä yrityksissä BRD on usein pelkästään ongelmakuvausosio.

Kirjoittavatko ketterät tiimit yhä PRD:itä?

Kyllä, yleensä yksisivuisena versiona. Backlog pitää sisällään työn, mutta tiketit ovat surkeita pitämään sisällään syyn, ei-tavoitteet ja tulosmittarin. Tiimit, jotka jättävät PRD:n kokonaan pois, yleensä keksivät sen uudelleen Confluence-sivuna nimeltä "konteksti" kolmen sprintin jälkeen.

Voiko PRD:n kirjoittaa Markdown-muodossa?

Markdown on paras muoto sille. Se liittyy siististi Notioniin, Confluenceen, Google Docsiin ja Lineariin, versioituu Gitissä koodin rinnalla tiedostona PRD.md, näyttää muutokset oikein pull requestissa, ja on ainoa muoto, jota tekoälykoodausagentti lukee menettämättä rakennetta. Yllä oleva mallipohja on Markdown-muodossa juuri näistä syistä.

Miten kirjoitat PRD:n tekoälykoodausagentille?

Ole selkeä siellä, missä normaalisti olisit lyhytsanainen. Ilmaise ei-tavoitteet myönteisesti, koska agentti ei pysty päättelemään laajuutta poisjätöistä. Pilko dokumentti vaiheisiin, jotka saa valmiiksi yhdellä ajolla. Kirjoita hyväksymiskriteerit väittäminä, joissa on lukuja. Nimeä tiedostot, joita agentti saa muokata, ja ne, joihin se ei saa koskea.

Mitä eroa on PRD:llä ja teknisellä suunnitteludokumentilla?

PRD vastaa siihen, mitä ja miksi: ongelma, käyttäjät, käyttäytyminen, hyväksymiskriteerit, ei-tavoitteet. Tekninen suunnitteludokumentti vastaa siihen, miten: arkkitehtuuri, datamalli, API-sopimukset, harkitut kompromissit. Tuotetiimi omistaa yleensä ensimmäisen, insinöörit toisen, ja suunnitteludokumentin pitäisi olla luettavissa vastauksena PRD:hen.

Kuka omistaa PRD:n — tuote, insinöörit vai asiakas?

Tuotetiimi omistaa dokumentin ja siinä olevat päätökset. Insinöörit omistavat toteutettavuuspalautteen ja ei-toiminnalliset vaatimukset. Toimistorakennuksissa asiakas omistaa ongelmakuvauksen, tavoitteet ja jokaisen avoimen kysymyksen omasta liiketoiminnastaan. Koko dokumentin jaettu omistajuus tarkoittaa yleensä sitä, että kukaan ei ylläpidä sitä.

Lopuksi

Kolme asiaa, jotka kannattaa muistaa. Mallipohja on hyödyllinen vasta, kun se on täytetty, joten kopioi työstetyn esimerkin muoto tyhjän sijaan. Ei-tavoitteet ovat dokumentin arvokkain osio sanaa kohden ja ensimmäinen, jonka ihmiset jättävät väliin. Ja hyväksymiskriteerit, jotka on kirjoitettu testattavina väittäminä, palvelevat kahta lukijaa yhtä hyvin: insinööriä, joka hyväksyy toimituksen, ja agenttia, joka kirjoittaa testin.

Jos kirjoitat PRD:tä annettavaksi ulkopuoliselle tiimille ja haluat toisen parin silmiä siihen ennen kuin siitä tulee sopimus, luemme sen mielellämme ja merkitsemme epäselvät rivit. Se on sama tarkistus, jonka teemme omille verkkosovellusrakennuksillemme.