Szablon PRD w Markdown:skopiuj go i uzupełnij.

Szablon

Skopiuj to do nowego pliku i zastąp wszystko, co jest w nawiasach ostrych. Usuń sekcję tylko wtedy, gdy masz pewność, że nie dotyczy, a zamiast zostawiać ją pustą, napisz "brak", żeby czytelnik wiedział, że ją rozważono.

# PRD: <Feature name>

Status: Draft | In review | Approved
Owner: <name>
Last updated: <date>

## 1. Problem
Who has the problem, what it is, and what it costs them today.
One short paragraph. No solution here.

## 2. Goals
- <Outcome 1, measurable>
- <Outcome 2, measurable>

## 3. Non-goals
Things this work will NOT do, so nobody builds them by accident.
- <Not in scope 1>
- <Not in scope 2>

## 4. Users and scenarios
- As a <role>, I want <action>, so that <benefit>.
- As a <role>, I want <action>, so that <benefit>.

## 5. Requirements
Number each one so it can be referenced in plans and tests.
- R1. The system must <behavior>.
- R2. The system must <behavior>.
- R3. The system should <optional behavior>.

## 6. Acceptance criteria
- [ ] R1: Given <state>, when <action>, then <result>.
- [ ] R2: Given <state>, when <action>, then <result>.

## 7. Edge cases and errors
- <Empty state>
- <Invalid input>
- <Network or permission failure>

## 8. Data and interfaces
- Data stored or changed: <fields, formats, migrations>
- APIs or screens affected: <names>

## 9. Success metrics
- <Metric>: from <baseline> to <target> by <date>.

## 10. Rollout and rollback
- Release plan: <flag, staged, all at once>
- How to turn it off if it goes wrong: <step>

## 11. Open questions
- [ ] <Question> (owner: <name>)

## 12. Context for the agent
Files to read first: <paths>. Constraints: <stack, style, limits>.

Dlaczego jest napisany właśnie tak

PRD dla agenta AI ma to samo zadanie co dla człowieka, ale z mniejszym polem do domysłów. Człowiek zapyta cię na korytarzu, co miałeś na myśli. Agent wypełni lukę najlepszym domysłem i pójdzie dalej.

• Poza zakresem to najtańsza ochrona przed rozrostem zakresu. Agenci dodają "pomocne" dodatki, dopóki im tego nie zabronisz.
• Numerowane wymagania (R1, R2) pozwalają planowi, testowi i komentarzowi z przeglądu wskazywać to samo.
• Kryteria akceptacji jako pola listy zadań zamieniają się w listę do odhaczania. Składnię opisują listy zadań w Markdown.
• Przypadki brzegowe to miejsce, w którym wygenerowany kod zawodzi najpierw: puste dane, błędne wejście, utracone połączenie.
• Wycofanie zmusza do przemyślenia, jak cofnąć zmianę, zanim ją wdrożysz.

Jak go uzupełnić

1. Opisz problem bez rozwiązania

   Jeśli nie umiesz opisać problemu bez wskazania funkcji, ta funkcja jest domysłem. Napisz, kogo to dotyczy i co dzieje się dziś.

2. Zrób każdy cel mierzalnym

   "Szybsze zamówienie" to życzenie. "Mediana zamówienia poniżej 30 sekund" to cel.

3. Pisz wymagania jako zachowanie

   "System musi pokazać błąd, gdy plik jest większy niż 10 MB" da się przetestować. "Dobra obsługa błędów" nie.

4. Połącz każde wymaganie z kryterium

   Użyj schematu given, when, then (dane, gdy, wtedy). Jeśli nie umiesz napisać sprawdzenia, wymaganie jest niejasne.

5. Zakończ otwartymi pytaniami

   Wskaż właściciela każdego. Agent ma o nie pytać, a nie je rozstrzygać.

Diagramy pomagają przy przepływach i stanach; blok Mermaid w pliku łatwo zmienić. Zobacz składnię diagramów przepływu Mermaid.

Przekazanie PRD agentowi AI

Wskaż agentowi plik zamiast go wklejać: "Przeczytaj docs/prd/export.md i zaproponuj plan; nie pisz jeszcze kodu." Najpierw poproś o plan, sprawdź go z numerowanymi wymaganiami, a dopiero potem pozwól budować. PRD, plan i lista zadań to zwykle trzy osobne pliki. PRD mówi co i dlaczego, plan mówi jak, a zadania to kroki.

Reguły całego projektu (polecenia, styl, foldery) trzymaj poza PRD, w CLAUDE.md lub AGENTS.md, żeby PRD zawierał tylko to, co dotyczy tej funkcji.

Częste błędy

• Rozwiązanie przebrane za problem. "Potrzebujemy listy rozwijanej" to nie problem.
• Brak elementów poza zakresem. Wszystko w pobliżu wchodzi do zakresu.
• Wymagania, które nie mogą zawieść. Jeśli żaden test nigdy by ich nie oblał, nic nie mówią.
• PRD, do którego nikt nie wraca. Aktualizuj status i otwarte pytania na bieżąco.
• Dziesięć stron na małą zmianę. Funkcja na jeden dzień pracy potrzebuje pół strony.

Product managerowie mogą czytać i przeglądać PRD w DotMD jako wyrenderowane dokumenty, z komentarzami do dokładnego fragmentu. Czytanie jest bezpłatne; zobacz cennik edycji i przeglądów.

Pytania o szablony PRD w Markdown

Więcej pytań