Przejdź do treści
Nodary

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

PoleTa 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.

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.

Pobierz szablon6 plików Markdown w archiwum .zip, 8 kB

Jak z niego korzystać

  1. 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.

  2. 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.

  3. 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.

  4. 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).

Nodary dla zespołów produktowych i inżynierskich
Widok tablicy na żywo w Nodary grupujący dokumenty według statusu (szkic, w przeglądzie, gotowe, zablokowane), każda karta z osobą przypisaną i terminem; pokazany przykładowy projekt to gra.

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.