PRD (dokument wymagań produktu)

Co zawiera PRD

PRD opisuje produkt z punktu widzenia osób, które będą z niego korzystać. Odpowiada na pytania, co zbudować i po co, a rozwiązania techniczne zostawia zespołowi, który go buduje. Zwykle pisze go osoba odpowiedzialna za produkt, a czytają go projektanci, programiści i testerzy.

Większość PRD obejmuje te same tematy, choć w różnych zespołach nagłówki brzmią inaczej:

• Cel. Problem, który rozwiązuje produkt albo funkcja, i dlaczego jest ważny właśnie teraz.
• Użytkownicy. Dla kogo jest produkt i w jakich sytuacjach będzie używany.
• Wymagania. Co produkt ma robić, często w formie historyjek użytkownika albo listy funkcji, oraz cechy takie jak szybkość, bezpieczeństwo czy dostępność.
• Zakres. Co należy do tego wydania, a co świadomie zostaje poza nim.
• Kryteria sukcesu. Po czym zespół pozna, że produkt robi to, co powinien, na przykład mierzalne cele albo kryteria akceptacji.
• Założenia i otwarte pytania. Co zespół przyjmuje za pewne, co zależy od innych prac i co jest jeszcze do rozstrzygnięcia.

PRD ma kilka pokrewnych dokumentów. Dokument wymagań rynkowych (MRD, market requirements document) opisuje potrzebę rynku, na którą odpowiada produkt, zanim sam produkt zostanie określony. Dokument wymagań funkcjonalnych (FRD, functional requirements document), nazywany też specyfikacją funkcjonalną, schodzi poziom niżej i szczegółowo opisuje, jak zachowuje się system. PRD znajduje się między nimi: mówi, co produkt robi dla swoich użytkowników.

Jak napisać PRD

Zacznij od problemu, nie od rozwiązania: w kilku zdaniach opisz, kto ma problem i ile go to dziś kosztuje. Potem zapisz wymagania tak, żeby każde dało się sprawdzić. „Szybko” nie da się sprawdzić, a „wyniki wyszukiwania pojawiają się w ciągu sekundy” już tak. Napisz, co jest poza zakresem, bo właśnie tam często zaczynają się nieporozumienia.

PRD to dokument roboczy. Zmienia się, gdy zespół dowiaduje się więcej, więc warto trzymać go w jednym miejscu, w którym wszyscy czytają aktualną wersję, i zapisywać decyzje na bieżąco.

Gdy z PRD pracuje agent AI, te zasady liczą się jeszcze bardziej. Zapisz otwarte pytania, zamiast je pomijać: czego dokument nie mówi, tego agent kodujący musi domyślić się sam. PRD całego produktu jest zwykle zbyt duży na jedną sesję agenta. Zespoły, które tak pracują, dzielą go na mniejsze zadania, każde z własnymi kryteriami akceptacji. Na tym polega spec-driven development.

PRD w featureloom

W featureloom jednostką pracy jest plan: dokument w markdownie na tablicy, który opisuje jedną pracę; agent dostaje go w całości, realizuje i zgłasza. PRD zwykle opisuje więcej, więc powstaje z niego kilka planów zgrupowanych w epiku, a ich kolejność wyznaczają zależności.

Nie musisz przepisywać PRD ręcznie. Na ekranie Zbieranie wklej jego tekst w pole Materiał albo wyślij go jako dokument PDF lub Word, a featureloom wygeneruje z niego plan według szablonu planu projektu. Samouczek Plan z wklejonego tekstu albo dokumentu PDF lub Word pokazuje każdy krok. Od ustawienia Twojej organizacji zależy, czy z tego samego materiału dostaniesz więcej niż jeden plan.

Wbudowany szablon planu prosi o cel, zakres, kroki, kryteria akceptacji i definicję ukończenia: te części PRD, których agent potrzebuje, żeby zrealizować jedną pracę. Szablon dopasujesz do zespołu na ekranie Ustawienia projektu, w zakładce Szablon planu.

PRD możesz też dać agentowi w konsoli jako plik tekstowy, razem z poleceniem z promptem Planista. Prompt każe agentowi przeczytać szablon planu projektu, założyć epik dla tematu, który go jeszcze nie ma, pisać każdy plan w sekcjach szablonu jako jedną pracę dla jednej sesji agenta i zapisać kolejność w zależnościach. Do tego osoba, która podłączyła konsolę, potrzebuje prawa Pisze plany.