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ę.
6 plików Markdown w archiwum .zip, 8 kB
Za darmo, bez konta, bez e-maila. Używaj, zmieniaj, udostępniaj.
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ą.
Dokumenty
Plik Szablon PRD/Dokument wymagań produktowych.md
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.
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.
[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: dla kogo jest funkcja i badania stojące za problemem
- Wymagania: co musi robić, z priorytetami i kryteriami akceptacji
- Projekt i przepływy: przepływ, ekrany, stany i przypadki brzegowe
- Wdrożenie i metryki: metryki, wdrożenie i lista kontrolna premiery
- Decyzje i otwarte pytania: 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, gdzie te pliki importują się jako mapa połączonych dokumentów.
Plik Szablon PRD/Dokument wymagań produktowych/01 Użytkownicy i dowody.md
Użytkownicy i dowody
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.
- [Krok]
- [Krok]
- [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]
Plik Szablon PRD/Dokument wymagań produktowych/02 Wymagania.md
Wymagania
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]
Plik Szablon PRD/Dokument wymagań produktowych/03 Projekt i przepływy.md
Projekt i przepływy
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.
- Punkt wejściaPierwsza akcja
- Pierwsza akcjaKluczowy wybór
- Kluczowy wybórPotwierdzenie
- PotwierdzenieWynik
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
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]
Plik Szablon PRD/Dokument wymagań produktowych/04 Wdrożenie i metryki.md
Wdrożenie i metryki
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]
Plik Szablon PRD/Dokument wymagań produktowych/05 Decyzje i otwarte pytania.md
Decyzje i otwarte pytania
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] | [...] |
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.
- Otwórz mapę projektu i wybierz „Importuj”.
- Wybierz kartę „Folder lub ZIP”, a potem „Wybierz plik ZIP”.
- 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).
Nodary dla zespołów produktowych i inżynierskich
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.
Trzymaj wymagania tam, gdzie pracuje zespół.
Zaimportuj szablon do Nodary, a PRD stanie się mapą, którą twój zespół i twoi agenci AI utrzymują w aktualności. Za darmo dla dwóch członków, jednego projektu i dziesięciu dokumentów, bez karty.