# Szablon dokumentu wymagań produktowych (PRD)

Sześć połączonych dokumentów, które prowadzą funkcję od problemu do wdrożenia: dla kogo jest, co musi robić, jak wygląda przepływ, po czym poznasz, że zadziałała, i każda decyzja po drodze. Pobierz je jako pliki Markdown: otworzysz je w dowolnym edytorze, pokażą swój diagram na GitHubie i w Obsidianie, a do Nodary zaimportujesz je jako mapę.

Za darmo, bez konta, bez e-maila. Używaj, zmieniaj, udostępniaj.

[Pobierz szablon (.zip)](https://nodary.ai/downloads/szablon-prd.zip)

## Przeczytaj każdą stronę przed pobraniem

Przegląd mieści się na jednym ekranie i linkuje do pięciu części: programiści, projektanci i wsparcie znajdą swoją stronę, a zmiana pozostaje mała. Kursywa mówi, co napisać; przykłady dotyczą jednej przykładowej funkcji, linków udostępniania, które wygasają.

- Dokument wymagań produktowych: Strona, którą wszyscy czytają najpierw: problem, cele, co jest w zakresie, a co poza nim, i link do każdej części.
- Użytkownicy i dowody: Dla kogo jest funkcja, co ci ludzie robią dziś bez niej i badania stojące za problemem.
- Wymagania: Co funkcja musi robić, każde wymaganie z priorytetem i sprawdzeniem, które go dowodzi.
- Projekt i przepływy: Jak użytkownik przechodzi przez funkcję: przepływ, ekrany, stany i przypadki brzegowe.
- Wdrożenie i metryki: Po czym poznasz, że zadziałało, jak funkcja trafia do użytkowników i co sprawiłoby, że się wycofasz.
- Decyzje i otwarte pytania: Każda decyzja, która zmieniła PRD, z tym, kto i dlaczego ją podjął, oraz pytania wciąż otwarte.

### Dokument wymagań produktowych

_Jak korzystać z szablonu: wiersze kursywą to wskazówki. Zastąp je własnymi słowami, a potem usuń. Wartości w nawiasach kwadratowych uzupełniasz sam. Utrzymaj tę stronę na jednym ekranie: to ją najpierw czyta zabiegany czytelnik, nowa osoba w zespole albo agent AI._

#### W skrócie

| Pole | Ta funkcja |
| --- | --- |
| Funkcja | [Nazwa] |
| W jednym zdaniu | [Co użytkownik może zrobić po wydaniu] |
| Właściciel produktu | [imię i nazwisko] |
| Lider techniczny | [imię i nazwisko] |
| Lider projektowania | [imię i nazwisko] |
| Status | [szkic, w przeglądzie, zatwierdzony, wydany] |
| Docelowe wydanie | [data lub wersja] |

#### Problem

_Kto ma problem, ile go to dziś kosztuje i skąd o tym wiesz. Problem bez dowodów to przypuszczenie: podlinkuj badania w_ [Użytkownicy i dowody](https://nodary.ai/pl/templates/prd#doc-users).

_Przykład (przykładowa funkcja): Ludzie udostępniają dokument klientowi do przeglądu, a potem zapominają, że link istnieje. Po miesiącach wciąż się otwiera. W zeszłym kwartale trzech klientów pytało, jak sprawić, by link przestał działać w określonym dniu._

[Problem w dwóch lub trzech zdaniach]

#### Cele i nie-cele

_Cele mówią, co zmienia się dla użytkownika, a nie co buduje zespół. Nie-cele to decyzje, które nie pozwalają zakresowi po cichu rosnąć._

- Cel: [co użytkownik może zrobić albo czego już nie musi robić]
- Cel: [...]
- Nie-cel: [co ta wersja celowo pomija]
- Nie-cel: [...]

#### Sukces w jednym wierszu

_Jedna miara, która miesiąc po wdrożeniu powie ci, czy to zadziałało. Pełna lista jest w_ [Wdrożenie i metryki](https://nodary.ai/pl/templates/prd#doc-launch).

[Metryka] rośnie z [wartość wyjściowa] do [cel] do [data].

#### Reszta PRD

_Każda część to osobny dokument. Linkuj do niej, zamiast kopiować, żeby każdy fakt żył i zmieniał się w jednym miejscu._

- [Użytkownicy i dowody](https://nodary.ai/pl/templates/prd#doc-users): dla kogo jest funkcja i badania stojące za problemem
- [Wymagania](https://nodary.ai/pl/templates/prd#doc-requirements): co musi robić, z priorytetami i kryteriami akceptacji
- [Projekt i przepływy](https://nodary.ai/pl/templates/prd#doc-design): przepływ, ekrany, stany i przypadki brzegowe
- [Wdrożenie i metryki](https://nodary.ai/pl/templates/prd#doc-launch): metryki, wdrożenie i lista kontrolna premiery
- [Decyzje i otwarte pytania](https://nodary.ai/pl/templates/prd#doc-decisions): co postanowiono, kto i dlaczego, i co jest wciąż otwarte

_Z tego szablonu możesz swobodnie korzystać, a także go zmieniać i udostępniać. Pochodzi z_ [Nodary](https://nodary.ai/pl)_, gdzie te pliki importują się jako mapa połączonych dokumentów._

### Użytkownicy i dowody

**Właściciel:** [imię i nazwisko] · **Status:** szkic · **Ostatni przegląd:** [data]

_Dla kogo jest funkcja i co o tych ludziach wiesz. Każde stwierdzenie tutaj powinno wskazywać swoje źródło._

#### Dla kogo

| Kto | Co próbuje zrobić | Co mu przeszkadza |
| --- | --- | --- |
| [Główny użytkownik] | [...] | [...] |
| [Dodatkowy użytkownik] | [...] | [...] |

_Przykład (przykładowa funkcja): Opiekunka klienta udostępnia szkic oferty klientowi na tydzień komentarzy. Dziś ustawia sobie przypomnienie, żeby wyłączyć link, i czasem o nim zapomina._

#### Dziś, bez tej funkcji

_Co użytkownicy robią dziś, krok po kroku, z obejściami włącznie. Obejście to często najlepsza specyfikacja, jaką dostaniesz._

1. [Krok]
2. [Krok]
3. [Obejście]

#### Dowody

| Źródło | Co mówi | Data | Link |
| --- | --- | --- | --- |
| [Wywiad z klientem] | [...] | [data] | [...] |
| [Zgłoszenia do wsparcia] | [...] | [...] | [...] |
| [Dane o użyciu] | [...] | [...] | [...] |

#### Otwarte pytania

- [ ] [Pytanie], [kto odpowiada], [do kiedy]

Zobacz też: [Dokument wymagań produktowych](https://nodary.ai/pl/templates/prd#doc-overview) · [Wymagania](https://nodary.ai/pl/templates/prd#doc-requirements) · [Projekt i przepływy](https://nodary.ai/pl/templates/prd#doc-design)

### Wymagania

**Właściciel:** [imię i nazwisko] · **Status:** szkic · **Ostatni przegląd:** [data]

_Jeden wiersz na wymaganie, zapisane jako coś, co użytkownik może zrobić. Priorytet to musi, powinno lub może: wersja wychodzi, gdy spełnione jest każde „musi”._

#### Historyjki użytkownika

| ID | Jako | chcę | aby | Priorytet |
| --- | --- | --- | --- | --- |
| W1 | [użytkownik] | [...] | [...] | [musi, powinno, może] |
| W2 | [...] | [...] | [...] | [...] |
| W3 | [...] | [...] | [...] | [...] |

_Przykład (przykładowa funkcja): W1. Jako osoba udostępniająca dokument chcę wybrać dzień, w którym link przestaje działać, aby klient tracił dostęp po zakończeniu projektu. Musi._

#### Kryteria akceptacji

_Dla każdego „musi” sprawdzenia, które dowodzą, że działa. Pisz je tak, żeby tester albo agent AI mógł je wykonać bez pytania cię o nic._

| Wymaganie | Zakładając, że | Gdy | Wtedy |
| --- | --- | --- | --- |
| W1 | [sytuacja wyjściowa] | [działanie] | [wynik, który ktoś może sprawdzić] |
| W1 | [...] | [...] | [...] |

#### Wymagania niefunkcjonalne

| Obszar | Wymaganie |
| --- | --- |
| Wydajność | [...] |
| Bezpieczeństwo i prywatność | [...] |
| Dostępność | [...] |
| Języki | [...] |
| Zgodność | [przeglądarki, urządzenia, wersje] |

#### Poza zakresem

- [Czego ta wersja nie robi i dlaczego]
- [...]

#### Otwarte pytania

- [ ] [Pytanie], [kto odpowiada], [do kiedy]

Zobacz też: [Użytkownicy i dowody](https://nodary.ai/pl/templates/prd#doc-users) · [Projekt i przepływy](https://nodary.ai/pl/templates/prd#doc-design) · [Wdrożenie i metryki](https://nodary.ai/pl/templates/prd#doc-launch)

### Projekt i przepływy

**Właściciel:** [imię i nazwisko] · **Status:** szkic · **Ostatni przegląd:** [data]

_Linkuj pliki projektowe, zamiast je wklejać. Trzymaj tutaj przepływ i decyzje, które go wyjaśniają, żeby tekst i ekrany nigdy sobie nie przeczyły._

#### Przepływ użytkownika

_Główna ścieżka, od miejsca, w którym użytkownik zaczyna, do tego, co dostaje. Jeśli zespół nie potrafi jej narysować, nie jest jeszcze ustalona._

```mermaid
flowchart LR
  n0["Punkt wejścia"]
  n1["Pierwsza akcja"]
  n2["Kluczowy wybór"]
  n3["Potwierdzenie"]
  n4["Wynik"]
  n0 --> n1
  n1 --> n2
  n2 --> n3
  n3 --> n4
```
_Główny przepływ, od [gdzie użytkownik zaczyna] do [co dostaje]_

#### Ekrany

| Ekran | Cel | Link do projektu | Status |
| --- | --- | --- | --- |
| [Ekran] | [...] | [...] | [szkic, makieta, wersja końcowa] |
| [Ekran] | [...] | [...] | [...] |

#### Stany

_Każdy ekran ma więcej stanów niż ścieżka szczęśliwa. Odhacz każdy, gdy zostanie zaprojektowany, albo napisz, dlaczego nie może wystąpić._

- [ ] Pusty: jeszcze nic do pokazania
- [ ] Ładowanie
- [ ] Błąd, z tym, co użytkownik może zrobić dalej
- [ ] Brak uprawnień
- [ ] Wolne lub zerwane połączenie
- [ ] Bardzo długi tekst i bardzo duże liczby

#### Przypadki brzegowe

| Przypadek | Co się dzieje |
| --- | --- |
| [...] | [...] |
| [...] | [...] |

_Przykład (przykładowa funkcja): Ktoś otwiera link minutę po jego dacie końcowej: widzi, że link wygasł i kogo poprosić o dostęp, a nigdy stronę błędu._

#### Otwarte pytania

- [ ] [Pytanie], [kto odpowiada], [do kiedy]

Zobacz też: [Wymagania](https://nodary.ai/pl/templates/prd#doc-requirements) · [Wdrożenie i metryki](https://nodary.ai/pl/templates/prd#doc-launch)

### Wdrożenie i metryki

**Właściciel:** [imię i nazwisko] · **Status:** szkic · **Ostatni przegląd:** [data]

_Jedna metryka główna, dwie lub trzy dodatkowe i jedna metryka ochronna: coś, co nie może się pogorszyć, gdy główna rośnie._

#### Metryki

| Metryka | Rodzaj | Wartość wyjściowa | Cel | Mierzona przez | Data przeglądu |
| --- | --- | --- | --- | --- | --- |
| [...] | [główna] | [...] | [...] | [...] | [data] |
| [...] | [dodatkowa] | [...] | [...] | [...] | [...] |
| [...] | [ochronna] | [...] | [...] | [...] | [...] |

#### Wdrażanie

| Etap | Kto ją dostaje | Data | Dalej, gdy |
| --- | --- | --- | --- |
| [Wewnętrznie] | [zespół] | [...] | [...] |
| [Beta] | [...] | [...] | [...] |
| [Wszyscy] | [...] | [...] | [...] |

#### Lista kontrolna premiery

- [ ] Artykuł pomocy napisany
- [ ] Zespół wsparcia poinformowany
- [ ] Informacja o wydaniu przygotowana
- [ ] Zdarzenia analityczne sprawdzone
- [ ] Wycofanie przetestowane

#### Wycofanie

_Co sprawiłoby, że wyłączysz funkcję, i jak. Zdecyduj o tym przed wdrożeniem, póki nikt nie jest przywiązany do wyniku._

- Wycofujemy, jeśli: [...]
- Jak: [flaga, wydanie, skrypt]
- Kto decyduje: [imię i nazwisko]

Zobacz też: [Dokument wymagań produktowych](https://nodary.ai/pl/templates/prd#doc-overview) · [Wymagania](https://nodary.ai/pl/templates/prd#doc-requirements) · [Decyzje i otwarte pytania](https://nodary.ai/pl/templates/prd#doc-decisions)

### Decyzje i otwarte pytania

**Właściciel:** [imię i nazwisko] · **Status:** szkic · **Ostatni przegląd:** [data]

_Gdy decyzja zmienia PRD, dodaj tu wiersz i zaktualizuj stronę, której dotyczy. Rejestr mówi dlaczego; strona mówi, co jest prawdą teraz._

#### Rejestr decyzji

| Data | Decyzja | Kto zdecydował | Dlaczego | Zmieniona strona |
| --- | --- | --- | --- | --- |
| [data] | [...] | [...] | [...] | [...] |

_Przykład (przykładowa funkcja): Linki działają do końca ostatniego dnia w strefie czasowej właściciela, a nie do północy UTC. Zdecydowali właścicielka produktu i lider techniczny, bo w becie klienci z innych stref czasowych tracili dostęp dzień za wcześnie. Zmieniona strona: Wymagania._

#### Otwarte pytania

| Pytanie | Kto odpowiada | Do kiedy | Odpowiedź |
| --- | --- | --- | --- |
| [...] | [imię i nazwisko] | [data] | [...] |

Zobacz też: [Dokument wymagań produktowych](https://nodary.ai/pl/templates/prd#doc-overview) · [Wymagania](https://nodary.ai/pl/templates/prd#doc-requirements) · [Wdrożenie i metryki](https://nodary.ai/pl/templates/prd#doc-launch)

## Jak z niego korzystać

### Najpierw problem, potem rozwiązanie

Najpierw wypełnij problem, cele i nie-cele w przeglądzie, razem z programistką i projektantem, którzy zbudują funkcję. Jeśli we troje nie zgadzacie się co do problemu, zatrzymajcie się tutaj.

### Każde „musi” ma być sprawdzalne

Daj każdemu wymaganiu z priorytetem „musi” kryteria akceptacji, które ktoś inny może sprawdzić. Wymaganie, którego nikt nie przetestuje, jest życzeniem.

### Daj do przeglądu, potem aktualizuj

Poproś o przegląd, gdy wymagania są gotowe, i aktualizuj PRD, gdy decyzja je zmienia. PRD, który zatrzymał się na starcie projektu, w dniu wdrożenia jest już nieaktualny.

### Zapisuj, co się zmieniło i dlaczego

Każda decyzja trafia do rejestru decyzji z informacją, kto ją podjął. Gdy ktoś zapyta, dlaczego funkcja działa w ten sposób, odpowiedź jest o jeden link dalej.

## Zaimportuj go do Nodary jako mapę

Nodary to przestrzeń robocza oparta na AI, w której dokumenty zespołu łączą się ze sobą, zamiast się piętrzyć. Zaimportuj .zip, a PRD pojawi się z pięcioma częściami pod sobą, z zachowanymi linkami między stronami i narysowanym diagramem. Ustaw go „W przeglądzie” i poproś właściciela lub administratora przestrzeni albo projektu o zatwierdzenie, zobacz, co się zmieniło od twojej ostatniej wizyty, i pozwól agentom AI połączonym przez MCP przeczytać wymagania, zanim napiszą kod.

1. Otwórz mapę projektu i wybierz „Importuj”.
2. Wybierz kartę „Folder lub ZIP”, a potem „Wybierz plik ZIP”.
3. Wskaż pobrany plik, sprawdź drzewo i zaimportuj.

Plan Free mieści dziesięć dokumentów na przestrzeń roboczą, wliczając stronę samego projektu: sześć dokumentów szablonu zmieści się w nowej przestrzeni i zostanie miejsce na trzy kolejne. Nodary ma też wbudowany jednostronicowy szablon specyfikacji produktu (PRD).

## Jak pisać PRD, z którego zespół naprawdę korzysta

PRD zawodzi na dwa sposoby: opisuje rozwiązanie, którego nikt nie zakwestionował, albo przestaje być aktualizowany po starcie projektu. Te nawyki zapobiegają obu.

### Zacznij od problemu

Napisz, kto ma problem i ile go to kosztuje, zanim pojawi się jakiekolwiek rozwiązanie. Zespoły zgodne co do problemu mniej się kłócą o ekrany.

### Powiedz, czego nie zrobisz

Nie-cele też są decyzjami. Spisanie ich sprawia, że funkcja nie rośnie z tygodnia na tydzień.

### Wymagania mają być sprawdzalne

„Szybko” i „prosto” nie da się sprawdzić. „Link przestaje się otwierać w ciągu minuty od daty końcowej” da się zbudować i przetestować.

### Priorytety: musi, powinno, może

Wersja wychodzi, gdy spełnione jest każde „musi”. „Powinno” i „może” to to, z czego rezygnujesz, gdy termin się zbliża.

### Linkuj dowody

Każde stwierdzenie o użytkownikach linkuje do wywiadu, zgłoszenia albo danych, na których się opiera, żeby recenzent mógł je sprawdzić, a nie przyjąć na wiarę.

### Utrzymuj go przy życiu

Aktualizuj PRD, gdy zmienia go decyzja, i zapisuj dlaczego. Na koniec ma opisywać to, co zostało wydane, a nie to, co planowano w pierwszym tygodniu.

## Pytania o PRD

### Czym jest PRD?

Dokument wymagań produktowych (product requirements document, PRD) opisuje funkcję lub produkt, zanim powstanie: jaki problem rozwiązuje, dla kogo jest, co musi robić, jak mierzy się sukces i co jest poza zakresem. Zwykle odpowiada za niego product manager; czytają go programiści, projektanci, wsparcie i coraz częściej agenci AI do programowania.

### Co powinien zawierać PRD?

Co najmniej problem i dowody na niego, cele i nie-cele, użytkowników, wymagania z priorytetami i kryteriami akceptacji, główne przepływy i przypadki brzegowe, metryki sukcesu, plan wdrożenia oraz rejestr decyzji i otwartych pytań. Ten szablon ma dokument dla każdej grupy.

### Jak długi powinien być PRD?

Na tyle długi, żeby zespół mógł zbudować i przetestować funkcję, nie zadając ci dwa razy tego samego pytania. Przegląd powinien mieścić się na jednym ekranie; wymagania rosną razem z decyzjami, a nie z pomysłami.

### Czym PRD różni się od technicznego dokumentu projektowego?

PRD mówi, co funkcja musi robić i dlaczego. Techniczny dokument projektowy mówi, jak zrobi to system: architektura, dane, interfejsy i ryzyka. Najpierw napisz PRD, a potem połącz oba dokumenty.

### Czy agenci AI mogą korzystać z PRD?

Tak. PRD w połączonych dokumentach daje agentowi potrzebny kontekst. W Nodary agenci połączeni przez MCP, tacy jak Claude, ChatGPT czy Cursor, czytają wymagania i rejestr decyzji z twoimi uprawnieniami, zanim cokolwiek napiszą.

### Czy mogę używać szablonu poza Nodary?

Tak. Pliki to zwykły Markdown: Obsidian otworzy rozpakowany folder jako sejf z działającymi linkami, a GitHub pokaże pliki z diagramem. Narzędzia, które importują Markdown plik po pliku, zachowają tekst i tabele; sprawdź, jak traktują linki między plikami.

Strona: https://nodary.ai/pl/templates/prd