Szablon dokumentu wymagań produktowych (PRD) + pełny przykład do skopiowania

Szablon dokumentu wymagań produktowych (PRD) + pełny przykład do skopiowania

Ostatnia aktualizacja: 28 lipca 2026.

Większość stron ze szablonem dokumentu wymagań produktowych podaje Ci pusty formularz. Szablon Atlassian to cztery sekcje instrukcji owinięte wokół pustej tabeli metryk sukcesu. Szablon Product School ma w tytule dopisek „(z przykładem)" i nie zawiera żadnego przykładu. Poniższy 12-sekcyjny blok w Markdown to cały szablon — bez rejestracji, gotowy do skopiowania. Sekcja 4 wypełnia następnie każdą z tych 12 sekcji na przykładzie kompletnej budowy: portalu do faktur dla klienta, który odczytuje PDF-y za pomocą LLM i kieruje wątpliwe przypadki do człowieka. Skopiuj pusty. Przeczytaj wypełniony. Napisz swój.

Najważniejsze wnioski

• PRD odpowiada na pytanie co budować i dlaczego; dokument projektu technicznego odpowiada na pytanie jak.
• 12 sekcji pasuje do projektu każdej wielkości. Wersja jednostronicowa to ten sam szablon z mniejszą liczbą wierszy.
• Cele wykluczone (non-goals) muszą być spisane. Agent AI do kodowania nie wywnioskuje zakresu z tego, co pominięto.
• Kryteria akceptacji muszą być sprawdzalne maszynowo: „p95 poniżej 400ms", nigdy „szybko".

Jaki kształt PRD powinieneś wybrać?

Wybierz format w zależności od tego, kto będzie czytał dokument, a nie od tego, jak duży wydaje się produkt. Pojedyncza funkcja trafiająca do własnych inżynierów potrzebuje wersji jednostronicowej. Budowa przekazana zespołowi zewnętrznemu wymaga pełnego 12-sekcyjnego PRD, ponieważ kryteria akceptacji pełnią też rolę bramek akceptacyjnych. Specyfikacja trafiająca do agenta AI do kodowania potrzebuje tych samych dwunastu sekcji podzielonych na fazy.

Jednostronicowy szablon dokumentu wymagań produktowych, o który wszyscy pytają, nie jest osobnym artefaktem. Powszechnie kopiowana wersja jednostronicowa Lenny'ego Rachitsky'ego, opublikowana z prawdziwymi przykładami w jego newsletterze, to ten sam szkielet, tylko bez zbędnej otoczki. Wersja jednostronicowa to nie inny dokument. To te same dwanaście sekcji, z których usunięto puste wiersze.

Zespoły agile'owe też często zadają to pytanie, zwykle w formie: czy PRD wytrzymuje zderzenie z backlogiem. Wytrzymuje — jako wersja jednostronicowa: PRD zawiera dlaczego i granice, tickety zawierają samą pracę.

Szablon PRD (Markdown do skopiowania)

Oto całość w Markdown, bez rejestracji, bez muru e-mail. Wklej go do Notion, Confluence, Google Docs, Linear, Word albo zacommituj do GitHuba jako PRD.md i pozwól mu wersjonować się razem z kodem. Ludzie proszą o ten szablon w dziewięciu różnych formatach; Markdown to ten, który przetrwa wklejenie do każdego z nich — i jedyny, który agent AI do kodowania odczyta bezbłędnie.

# PRD: [Nazwa produktu lub funkcji]

## 1. Header
- Właściciel (produkt):
- Lider inżynierii:
- Lider projektowania:
- Status: Draft | In review | Approved | Shipped
- Ostatnia aktualizacja:
- Historia zmian: data / autor / co się zmieniło

## 2. Opis problemu
Jeden akapit. Kogo to boli, jak często, ile to dziś kosztuje. Bez języka rozwiązań.

## 3. Cele i metryki sukcesu
| Cel | Metryka | Wartość bazowa | Cel docelowy | Sposób pomiaru | Data |
|---|---|---|---|---|---|

## 4. Cele wykluczone (non-goals)
Sformułowane pozytywnie: „Ta faza nie obejmuje X".

## 5. Użytkownicy i persony
Kto z tego korzysta, co już wie, na jakim urządzeniu, jak często.

## 6. Historyjki użytkownika i kryteria akceptacji
Jako [persona], chcę [działanie], aby [rezultat].
- Given [kontekst], when [zdarzenie], then [obserwowalny rezultat].

## 7. Wymagania funkcjonalne
Numerowane. Jedno wymaganie w linii. Testowalne. Żadne zdanie nie zawiera „i".

## 8. Wymagania niefunkcjonalne
Wydajność / bezpieczeństwo i wielodostępność / rezydencja i retencja danych / dostępność / czas działania usługi.

## 9. Zależności i integracje
Systemy zewnętrzne, API, poświadczenia, kto posiada dostęp, czas realizacji.

## 10. Kamienie milowe i fazowanie
| Faza | Zakres | Kryteria wyjścia | Data docelowa |
|---|---|---|---|

## 11. Otwarte pytania i ryzyka
| Pytanie lub ryzyko | Właściciel | Termin | Wpływ w razie braku odpowiedzi |
|---|---|---|---|

## 12. Załącznik i linki
Projekty, badania, notatki o konkurencji, wcześniejsze tickety, umowy.

Dwanaście sekcji, w kolejności: nagłówek, opis problemu, cele i metryki sukcesu, cele wykluczone, użytkownicy i persony, historyjki użytkownika z kryteriami akceptacji, wymagania funkcjonalne, wymagania niefunkcjonalne, zależności i integracje, kamienie milowe i fazowanie, otwarte pytania i ryzyka, załącznik.

Co powinien zawierać PRD? 12 sekcji i słaba wersja każdej z nich

Dokument wymagań produktowych powinien zawierać opis problemu, mierzalne cele, jawnie wypisane cele wykluczone, persony, historyjki użytkownika z kryteriami akceptacji, wymagania funkcjonalne i niefunkcjonalne, zależności, kamienie milowe, otwarte pytania z właścicielami oraz historię zmian. Wszystko inne to załącznik. Test dla każdej linijki jest taki sam, jak ten, który norma ISO/IEC/IEEE 29148:2018 stosuje do wymagań w ogóle: weryfikowalna, jednoznaczna, pojedyncza.

Większość PRD nie przechodzi tego testu w tych samych trzech miejscach.

Dwie sekcje zasługują na więcej uwagi, niż zwykle dostają.

Wymagania niefunkcjonalne to miejsce, w którym zakres po cichu się podwaja. Wydajność, wielodostępność, rezydencja danych, retencja, dostępność, czas działania usługi — każde z nich to decyzja inżynierska z kosztem, a żadna nie pojawia się w historyjce użytkownika. Umieść tu linijkę o bezpieczeństwie zamiast zbywać temat ogólnikiem i zapisz ją tak, jak chciałbyś, żeby była sprawdzana — korzystając na przykład z naszej checklisty bezpieczeństwa przed premierą jako listy źródłowej. Jeśli budowa zawiera komponent AI, wymagania dotyczące gotowości produkcyjnej też należą tutaj, a nie do późniejszej fazy „utwardzania", która nigdy nie trafia do harmonogramu: nasza checklista od PoC do produkcji to wersja, której używamy.

Otwarte pytania potrzebują trzech kolumn, nie jednej. Pytanie, właściciel, termin. Pytanie bez właściciela to decyzja, której nikt nie podejmuje, i wypłynie jako żądanie zmiany w szóstym tygodniu. Warto dodać: PRD piszesz dopiero po tym, jak zdecydowałeś się budować, a nie kupować. Jeśli opis problemu wciąż czyta się jak lista zakupów funkcji, decyzja build-versus-buy jeszcze faktycznie nie zapadła.

Przykład praktyczny: wypełniony PRD portalu do faktur

Oto kompletny przykład praktyczny, ze wszystkimi 12 wypełnionymi sekcjami. Budowa: portal do faktur dla klienta — średniej wielkości operatora logistycznego. Klienci wgrywają faktury PDF, LLM wyodrębnia pozycje, system oznacza niezgodności z rekordem zamówienia, a wszystko, czego nie jest pewien, trafia do kolejki przeglądu przez człowieka. Stos technologiczny: Next.js, Supabase/Postgres, jeden krok ekstrakcji LLM. Skopiuj, wydrukuj, wyeksportuj do PDF — cokolwiek potrzebujesz.

# PRD: Portal do faktur dla klienta, Faza 1

## 1. Nagłówek
- Właściciel (produkt): Dyrektor operacyjny, strona klienta
- Lider inżynierii: Lider dostawy, Techsy
- Lider projektowania: Projektant produktu, Techsy
- Status: Zatwierdzony do budowy
- Ostatnia aktualizacja: 2026-07-28
- Historia zmian:
  - 2026-07-14 / produkt / pierwszy szkic
  - 2026-07-21 / inżynieria / dodano regułę progu pewności do 6.2
  - 2026-07-28 / produkt / przeniesiono zapis zwrotny do ERP do celów wykluczonych

## 2. Opis problemu
Pracownicy operacyjni otrzymują faktury klientów jako PDF-y w e-mailu i ręcznie
przepisują je do systemu zamówień. Wolumen przekracza 300 faktur tygodniowo,
średni czas obsługi to około 6 minut na fakturę, a około 4% zawiera błąd
wpisania wychwytywany dopiero przy uzgadnianiu na koniec miesiąca. Każda
korekta kosztuje drugie podejście i telefon.

## 3. Cele i metryki sukcesu
| Cel | Metryka | Wartość bazowa | Cel docelowy | Sposób pomiaru | Data |
|---|---|---|---|---|---|
| Skrócić obsługę ręczną | Śr. czas obsługi | 6 min | poniżej 90 sek | Dashboard operacyjny, mediana tygodniowa | 2026-11-01 |
| Ograniczyć błędy wpisania | Faktury korygowane przy uzgadnianiu | 4% | poniżej 1% | Raport finansowy na koniec miesiąca | 2026-12-01 |
| Ograniczyć obciążenie przeglądem | Udział kierowany do przeglądu przez człowieka | n/d | poniżej 25% | Metryki kolejki portalu | 2026-11-01 |

## 4. Cele wykluczone (non-goals)
Ta faza nie obsługuje faktur wielowalutowych, zapisu zwrotnego do ERP,
samoobsługowych not kredytowych klienta ani aplikacji mobilnej. Ekstrakcja
obejmuje wyłącznie PDF. Zdjęcia papierowych faktur i skany poniżej 200 DPI są
odrzucane przy wgrywaniu z komunikatem wyjaśniającym dlaczego.

## 5. Użytkownicy i persony
- Pracownik operacyjny (główny, 6 osób): pracuje w kolejce wyjątków cały
  dzień, głęboka wiedza domenowa, wyłącznie desktop.
- Kontakt AP klienta (zewnętrzny, ~140 kont): wgrywa faktury, niska tolerancja
  na tarcie przy zakładaniu konta.
- Kierownik finansowy (drugorzędny): pobiera raport na koniec miesiąca,
  potrzebuje ścieżki audytu dla każdej faktury.

## 6. Historyjki użytkownika i kryteria akceptacji
6.1 Jako kontakt AP klienta, chcę wgrać PDF faktury, aby nie musieć wysyłać
go e-mailem i czekać.
- Given plik PDF poniżej 20 MB o rozdzielczości 200 DPI lub lepszej, when go
  wgrywam, then portal zwraca numer referencyjny w ciągu 5 sekund i pokazuje
  „Przetwarzanie".

6.2 Jako pracownik operacyjny, chcę, aby ekstrakcje o niskiej pewności były
wstrzymywane, aby nic błędnego nie zostało zatwierdzone automatycznie.
- Given sparsowana faktura, when pewność ekstrakcji dla dowolnej pozycji jest
  poniżej 0.85, then faktura trafia do kolejki przeglądu i nigdy nie jest
  zatwierdzana automatycznie.

6.3 Jako pracownik operacyjny, chcę widzieć niezgodność w jednym miejscu, aby
móc ją rozwiązać bez otwierania systemu zamówień.
- Given faktura dopasowana do zamówienia, when dowolna ilość lub cena
  jednostkowa różni się od rekordu zamówienia, then portal pokazuje obie
  wartości obok siebie i oznacza różnicę.

6.4 Jako kierownik finansowy, chcę filtrować faktury, aby móc zamknąć
miesiąc.
- Given lista faktur, when filtruję po dostawcy, zakresie dat i statusie,
  then wyniki zwracane są w mniej niż 400ms przy p95, a pusty stan oferuje
  „Wyczyść filtry".

## 7. Wymagania funkcjonalne
1. Wgrywanie akceptuje wyłącznie PDF, maksymalnie 20 MB, jeden plik na zgłoszenie.
2. Ekstrakcja zwraca dostawcę, numer faktury, datę, walutę oraz pozycje
   z ilością, ceną jednostkową i sumą.
3. Każda pozycja ma wynik pewności między 0 a 1.
4. Dopasowanie porównuje wyodrębnioną fakturę z otwartym zamówieniem po
   numerze PO.
5. Wyjątki trafiają do kolejki uporządkowanej od najstarszych, przypisywalnej
   do jednego pracownika.
6. Każda zmiana stanu zapisuje wpis audytowy z aktorem, znacznikiem czasu i
   poprzednią wartością.
7. Zatwierdzone faktury eksportowane są jako paczka CSV do systemu
   finansowego.

## 8. Wymagania niefunkcjonalne
- Wydajność: lista faktur p95 poniżej 400ms. Ekstrakcja kończy się w ciągu 90
  sekund od wgrania przy p95.
- Bezpieczeństwo i wielodostępność: izolacja per tenant wymuszona na poziomie
  wiersza bazy danych. Klient nigdy nie może odczytać faktury innego klienta.
  Weryfikowane automatycznym testem przy każdym wydaniu.
- Rezydencja i retencja danych: dokumenty przechowywane w UE. Oryginały
  przechowywane 7 lat, dane ekstrakcji 90 dni.
- Dostępność: kolejka w pełni obsługiwana z klawiatury, kontrast WCAG 2.2 AA.
- Czas działania usługi: 99.5% miesięcznie, wsparcie w godzinach pracy.

## 9. Zależności i integracje
- Rekordy zamówień: replika Postgres tylko do odczytu. Dostęp posiada dział
  IT klienta, poświadczenia potrzebne do 2026-08-15.
- Dostawca ekstrakcji LLM: umowa i umowa powierzenia przetwarzania danych
  podpisane przed rozpoczęciem budowy.
- Powiadomienia e-mail: istniejący dostawca transakcyjny, domena nadawcy
  zweryfikowana przez klienta.

## 10. Kamienie milowe i fazowanie
| Faza | Zakres | Kryteria wyjścia | Data docelowa |
|---|---|---|---|
| P1 | Wgrywanie, ekstrakcja, routing wg pewności | 50 rzeczywistych faktur od początku do końca, poniżej 25% w kolejce | 2026-09-19 |
| P2 | Dopasowanie zamówień i widok niezgodności | Niezgodność prawidłowo oznaczona na 20 przygotowanych przypadkach | 2026-10-10 |
| P3 | Ścieżka audytu, eksport CSV, raportowanie | Finanse zamykają jeden miesiąc w portalu | 2026-11-01 |

## 11. Otwarte pytania i ryzyka
| Pytanie lub ryzyko | Właściciel | Termin | Wpływ w razie braku odpowiedzi |
|---|---|---|---|
| Który numer PO jest wiążący, gdy faktura pokazuje dwa? | Dyrektor operacyjny klienta | 2026-08-08 | Logika dopasowania zablokowana |
| Czy 12 największych klientów wysyła skany czy natywne PDF-y? | Lider dostawy | 2026-08-08 | Próg pewności może być błędny |
| Czy 7-letnia retencja jest potwierdzona z prawnikiem klienta? | Kierownik finansowy klienta | 2026-08-22 | Zmiana projektu i kosztu przechowywania |
| Koszt ekstrakcji na fakturę przy 300/tydzień | Lider dostawy | 2026-09-05 | Nieznana ekonomika jednostkowa |

## 12. Załącznik i linki
Zanonimizowany zestaw przykładowych faktur (40 plików), schemat tabeli
zamówień, aktualne badanie czasu obsługi, przepływy Figma dla wgrywania i
kolejki, podpisany statement of work.

Cztery decyzje w tym dokumencie warto wyróżnić, bo leniwa wersja każdej z nich kosztuje realne pieniądze.

Sekcja 3, wartość bazowa. „6 minut" to nie ozdobnik. Bez wartości bazowej nie da się stwierdzić, czy coś zadziałało, a sześć miesięcy później ktoś kłóci się o to na spotkaniu bez żadnych danych. Leniwa wersja, „poprawić wydajność", czyni projekt niefalsyfikowalnym.

Sekcja 4, cel wykluczony. Zapis zwrotny do ERP przeniesiono do celów wykluczonych 2026-07-28, po tym jak został wcześniej milcząco założony podczas rozmowy przeglądowej. Zapisanie go jako celu wykluczonego kosztowało jedną linijkę i oszczędziło kłótnię o zakres.

Sekcja 6.2, próg pewności. To reguła, którą nasze własne pierwsze szkice najczęściej pomijają. Pomiń ją, a system automatycznie zatwierdzi faktury, które powinien zobaczyć człowiek — a to dokładnie ten błąd, który wymazuje oszczędności czasu obiecane w sekcji 3.

Sekcja 11, właściciele. Każde otwarte pytanie ma imię i datę. Ta kolumna to różnica między dokumentem a listą zadań, którą nikt się nie opiekuje.

PRD mówi Ci co. Nie mówi, jak długo ani ile to będzie kosztować — to osobne ćwiczenie: zobacz określanie zakresu budowy po tę drugą połowę. A cel wykluczony, którego nie zapisałeś, to funkcja, którą ktoś kiedyś zbuduje.

Jak napisać PRD, z którego agent AI do kodowania rzeczywiście zbuduje produkt?

PRD napisany dla agenta AI do kodowania wymienia zwięzłość na jednoznaczność. Agent nie ma nieformalnego kontekstu, wspólnej historii ani intuicji co do tego, czego oczywiście nie miałeś na myśli. Cztery reguły pokrywają większość tej różnicy — wynikają z obserwacji, które specyfikacje działały, a które zawodziły w naszych własnych budowach wspieranych przez agentów.

1. Formułuj cele wykluczone pozytywnie. Ludzie wnioskują zakres z pominięcia. Agenci nie. „Nie dodawaj uwierzytelniania w tej fazie" musi być zdaniem w dokumencie, inaczej uwierzytelnianie zostanie zbudowane, przetestowane i oddane Ci z powrotem.

2. Dziel pracę na fazy odpowiedniej wielkości. Jeden 40-stronicowy monolit tworzy pewny siebie, rozrośnięty, w połowie poprawny pull request. Podziel PRD na przebiegi, które agent skończy w jednym ograniczonym uruchomieniu, każdy z własnymi kryteriami wyjścia.

3. Spraw, by kryteria akceptacji dało się sprawdzić maszynowo. „Szybko" to nie wymaganie, to nastrój. „p95 poniżej 400ms na endpoincie listy faktur" to test, który agent może napisać, zanim napisze funkcję.

4. Umieszczaj ścieżki plików i ograniczenia stosu technologicznego w dokumencie, nie na czacie. Kontekst czatu wyparowuje między sesjami. Specyfikacja nie. Dlatego właśnie liczy się tryb planowania Claude Code: odczytuje Twoje pliki i proponuje plan, nic nie edytując, dopóki nie zatwierdzisz — a ten krok zatwierdzenia jest dużo bardziej użyteczny, gdy plan jest sprawdzany względem spisanej specyfikacji, a nie Twojej pamięci o tym, o co prosiłeś.

Oto portal do faktur, podzielony na jedną fazę, którą agent może wykonać w jednym przebiegu.

# Zadanie budowy: Wgrywanie i ekstrakcja faktur (Faza 1 z 3)

## Ograniczenia stosu technologicznego (nie zastępuj)
Next.js 15 App Router, TypeScript, Supabase Postgres z row-level security,
wdrożenie na Vercel. Żadnych nowych zależności bez wcześniejszego pytania.

## Pliki, które możesz tworzyć lub edytować
- app/(portal)/invoices/upload/page.tsx
- app/api/invoices/route.ts
- lib/extraction/parse-invoice.ts
- supabase/migrations/0007_invoices.sql

## Nie dotykaj
- lib/auth/*  (uwierzytelnianie wdrażane w Fazie 2; nie dodawaj teraz przepływów logowania)
- Niczego pod app/(marketing)/
- Istniejącego schematu zamówień. Przeczytaj go. Nigdy go nie migruj.

## Kryteria akceptacji (napisz je najpierw jako testy)
1. POST /api/invoices odrzuca pliki inne niż PDF kodem 415, a pliki powyżej 20 MB kodem 413.
2. Pozycja z pewnością < 0.85 ustawia invoice.status = 'review',
   nigdy 'approved'.
3. Każdy insert zapisuje wiersz audytowy z actor_id, action, created_at.
4. GET /api/invoices?vendor=&from=&to=&status= zwraca odpowiedź w mniej niż 400ms na
   10,000-wierszowym seedzie.

## Poza zakresem tego przebiegu
Dopasowanie zamówień, UI niezgodności, eksport CSV, powiadomienia e-mail.

Trzy rzeczy zmieniły się względem wersji dla człowieka: pojawiły się ścieżki plików, pojawiła się lista „nie dotykaj", a kryteria akceptacji stały się asercjami zamiast zdań. To, któremu agentowi to przekażesz, ma mniejsze znaczenie, niż się wydaje, choć porównanie agentów do kodowania warto przeczytać przed podjęciem decyzji. Trzymaj wymagania i reguły projektu w osobnych plikach: Cursor rules i CLAUDE.md przechowują konwencje i narzędzia, PRD przechowuje co budować. Jeśli chcesz, żeby AI pomogło Ci najpierw wypracować zakres, zamiast go tylko konsumować, to inny workflow. A dla samego kroku ekstrakcji, wybór modelu i pętla ewaluacji to osobna praca integracyjna AI.

Co się zmienia, gdy PRD trafia do zespołu zewnętrznego

Gdy PRD trafia do agencji lub kontraktora, przestaje być dokumentem uzgodnieniowym, a staje się językiem kontraktu. Niejasność, którą wewnętrzny zespół rozwiązuje dwuminutową rozmową, staje się żądaniem zmiany z ceną. Raport PMI Pulse of the Profession wykazał, że 47% nieudanych projektów nie osiąga celów z powodu niedokładnego zarządzania wymaganiami. To cały powód istnienia tego dokumentu.

W takim układzie trzy sekcje mają nieproporcjonalnie duże znaczenie. Kryteria akceptacji stają się bramkami akceptacyjnymi, więc muszą być obserwowalne przez kogoś, kto nie jest inżynierem. Otwarte pytania potrzebują nazwanego właściciela po stronie klienta, bo dostawca nie może na nie odpowiedzieć i zbuduje coś naokoło tej luki. A historia zmian przestaje być biurokracją: to zapis tego, co i kiedy zostało uzgodnione — pierwsza rzecz, po którą ktoś sięga podczas sporu.

Linijka, która niejednokrotnie zawodziła na naszych oczach, to jakaś wersja „użytkownicy mogą eksportować swoje dane". Nikt nie zapisuje, w jakim formacie. Kosztowna wersja tego u nas została wdrożona jako eksport CSV, podczas gdy klient miał na myśli sformatowaną paczkę faktur PDF z jego brandingiem, a poprawka pochłonęła około tygodnia pracy inżynierskiej, której nikt nie zaplanował w zakresie. Uczciwe spojrzenie mówi, że wina leżała w dokumencie, nie w dostawie. Kryterium akceptacji wychwyciłoby to w pięć minut: given żądanie eksportu, when plik jest generowany, then jest to PDF zgodny z dostarczonym układem. Linijka celów wykluczonych też by to wychwyciła, z drugiej strony. Dlatego to teraz reguła w naszym discovery: każde wymaganie zawieszone na rzeczowniku takim jak „eksport", „raport" czy „powiadomienie" dostaje format, wyzwalacz i dołączony przykład praktyczny, zanim statement of work zostanie podpisany.

To właśnie w większości jest to, jak prowadzimy budowy aplikacji webowych: zamienianie niejasnej połowy specyfikacji klienta w testowalne linijki, zanim ktokolwiek napisze kod.

Co r/ProductManagement naprawdę mówi o szablonach PRD

Wyszukaj product requirements document template reddit, a znajdziesz tę samą skargę powtarzaną w kółko na r/ProductManagement: rozdęcie szablonu. PRD-ki, których nikt nie czyta. Sekcje wypełnione, bo szablon miał nagłówek, a nie dlatego, że ktoś potrzebował tej treści. Dokumenty, które się dezaktualizują dzień po starcie i po cichu zostają zastąpione wątkiem na Slacku. To uczciwa krytyka większości szablonów, w tym kilku z pierwszej dziesiątki wyników dla tego zapytania.

Nasza odpowiedź: usuwaj sekcje, zamiast wypełniać je niczym. Persony idą pierwsze do usunięcia, gdy użytkownicy są oczywiści. Załącznik drugi. Kamienie milowe mogą zamiast tego żyć w trackerze. Ta, której nigdy nie usuwamy, to cele wykluczone — bo to jedyna sekcja, która robi się krótsza im więcej pracy wykonasz, i jedyna, która niezawodnie zapobiega kłótni, którą inaczej miałbyś w szóstym tygodniu.

O autorze

Mert Batur Gurbuz, współzałożyciel, Techsy.io. Kwalifikacje: współzałożyciel, Techsy.io, University of Birmingham. LinkedIn

Mert Batur Gurbuz jest współzałożycielem Techsy.io, gdzie zespół dostarcza agentów AI, systemy automatyzacji i pipeline'y głosowe/SDR dla klientów B2B. Studiuje na University of Birmingham i pisze o stosie narzędzi LLM, którego zespół Techsy faktycznie używa produkcyjnie.

Najczęściej zadawane pytania

Czym jest dokument wymagań produktowych?

Dokument wymagań produktowych (PRD) określa, co zespół buduje i dlaczego: problem, cele i ich metryki, cele wykluczone, dla kogo to jest, oraz wymagania, które definiują „gotowe". Celowo pomija szczegóły implementacyjne, które należą do dokumentu projektu technicznego pisanego później przez inżynierię.

Jak napisać dokument wymagań produktowych?

Zacznij od opisu problemu i nie używaj w nim języka rozwiązań. Dodaj mierzalne cele z wartością bazową i datą docelową, a następnie zapisz cele wykluczone. Wypełnij persony, historyjki użytkownika z kryteriami akceptacji w formacie Given/When/Then, wymagania funkcjonalne i niefunkcjonalne, zależności, kamienie milowe oraz otwarte pytania z właścicielami.

Co powinien zawierać PRD?

Dwanaście sekcji: nagłówek z historią zmian, opis problemu, cele i metryki sukcesu, cele wykluczone, użytkownicy i persony, historyjki użytkownika z kryteriami akceptacji, wymagania funkcjonalne, wymagania niefunkcjonalne, zależności i integracje, kamienie milowe i fazowanie, otwarte pytania i ryzyka oraz załącznik. Wszystko, co nie mieści się w żadnej z nich, prawdopodobnie nie jest wymaganiem.

Jak długi powinien być PRD?

Od jednej do dwóch stron dla pojedynczej funkcji, od trzech do pięciu dla fazy produktu, od pięciu do ośmiu, gdy buduje go zespół zewnętrzny, a kryteria akceptacji pełnią rolę bramek akceptacyjnych. Długość wynika z liczby zapisywanych decyzji, nie z rozmiaru produktu. Puste sekcje należy usuwać, a nie wypełniać na siłę.

Czy PRD to to samo co BRD?

Nie. Dokument wymagań biznesowych (BRD) określa oczekiwany wynik komercyjny organizacji oraz ograniczenia wokół niego, zwykle zanim wybrane zostanie rozwiązanie. PRD opisuje produkt, który ten wynik dostarcza: użytkowników, zachowanie, kryteria akceptacji, cele wykluczone. W mniejszych firmach BRD to często po prostu sekcja opisu problemu.

Czy zespoły agile'owe wciąż piszą PRD?

Tak, zwykle jako wersję jednostronicową. Backlog przechowuje pracę, ale tickety fatalnie radzą sobie z przechowywaniem dlaczego, celów wykluczonych i metryki sukcesu. Zespoły, które całkowicie pomijają PRD, zwykle odkrywają go na nowo jako stronę Confluence o nazwie „kontekst" trzy sprinty w projekt.

Czy można napisać PRD w Markdown?

Markdown to najlepszy format dla PRD. Wkleja się bezbłędnie do Notion, Confluence, Google Docs i Linear, wersjonuje się w Git obok kodu jako PRD.md, prawidłowo pokazuje różnice w pull requeście i jest jedynym formatem, który agent AI do kodowania odczytuje bez utraty struktury. Powyższy szablon jest w Markdown właśnie z tych powodów.

Jak napisać PRD dla agenta AI do kodowania?

Bądź jednoznaczny tam, gdzie normalnie byłbyś zwięzły. Formułuj cele wykluczone pozytywnie, bo agent nie wywnioskuje zakresu z pominięcia. Podziel dokument na fazy możliwe do ukończenia w jednym przebiegu. Zapisz kryteria akceptacji jako asercje z liczbami. Wymień pliki, które agent może edytować, i te, których nie może dotykać.

Jaka jest różnica między PRD a dokumentem projektu technicznego?

PRD odpowiada na pytania co i dlaczego: problem, użytkownicy, zachowanie, kryteria akceptacji, cele wykluczone. Dokument projektu technicznego odpowiada na pytanie jak: architektura, model danych, kontrakty API, rozważane kompromisy. Produkt zwykle jest właścicielem pierwszego, inżynieria — drugiego, a dokument projektowy powinien czytać się jak odpowiedź na PRD.

Kto jest właścicielem PRD — produkt, inżynieria czy klient?

Produkt jest właścicielem dokumentu i podejmowanych w nim decyzji. Inżynieria jest właścicielem informacji zwrotnej o wykonalności i wymagań niefunkcjonalnych. Przy budowach agencyjnych klient jest właścicielem opisu problemu, celów oraz każdego otwartego pytania dotyczącego jego własnego biznesu. Wspólna własność całego dokumentu zwykle oznacza, że nikt go nie utrzymuje.

Podsumowanie

Trzy rzeczy do zapamiętania. Szablon jest przydatny dopiero po wypełnieniu, więc kopiuj kształt wypełnionego przykładu, a nie pustego. Cele wykluczone to sekcja o najwyższej wartości na słowo w całym dokumencie i pierwsza, którą ludzie pomijają. A kryteria akceptacji zapisane jako testowalne asercje służą równie dobrze dwóm czytelnikom: inżynierowi zatwierdzającemu dostawę i agentowi piszącemu test.

Jeśli piszesz PRD, który trafi do zespołu zewnętrznego, i chcesz, żeby ktoś jeszcze na niego spojrzał, zanim stanie się kontraktem — chętnie go przeczytamy i oznaczymy niejednoznaczne linijki. To ten sam proces, który stosujemy przy naszych własnych budowach aplikacji webowych.