Wymagania produktowe: jak napisać PRD na podstawie wywiadów
Zamień wywiady w dokument wymagań: problem, scenariusze, ograniczenia, zakres wersji i kryteria weryfikacji. Z szablonem i przykładem.
Prośba o przycisk nie wyjaśnia zadania
Klient mówi: „Dodajcie przycisk eksportu”. Nie wiadomo, kto potrzebuje pliku, co ma zawierać i co z nim zrobi. Dokument wymagań produktowych, czyli PRD, pomaga zespołowi wspólnie zrozumieć zadanie i zakres wyniku.
Tu chodzi o krótki dokument dla jednej funkcji. Architektura, umowy i wymagania techniczne nadal mają własną rolę. PRD pozwala zweryfikować problem użytkownika przed wyborem wdrożenia.
Od prośby użytkownika do wymagań
Wróć do ostatniego przypadku
Zapytaj, kiedy potrzebny był eksport, co osoba zrobiła zamiast niego, jakie dane przenosiła i gdzie utknęła. Zaznacz przykład i skutek. Ogólne „niewygodne” trzeba doprecyzować, aby móc sprawdzić usprawnienie.
Opisz scenariusz przed wyborem interfejsu
Zapisz, kto zaczyna, z jakimi danymi i czego oczekuje. Przycisk, e-mail i automatyczny raport to możliwe rozwiązania. Najpierw zbadaj potrzebę i ograniczenia, zanim pierwsza propozycja stanie się wymaganiem.
Ustal zakres wersji
Zapisz, co wchodzi w zadanie, a co celowo zostaje poza nim. Oddzielnie wymień uprawnienia, pola i sytuacje z pustym wynikiem. Uzgodnij warunki pomiaru przed określeniem wymagań dotyczących szybkości i wolumenu.
Sformułuj kontrolę
Podaj dla każdego wymagania obserwowalny wynik i przykładowe dane. Powiąż próbę z pierwotnym problemem. Niepotwierdzony punkt zapisz jako otwarte pytanie, z osobą odpowiedzialną i terminem decyzji.
Eksport listy zamkniętych zgłoszeń
Przykład jest fikcyjny. Imiona, warunki i wyniki służą wyjaśnieniu metody.
W każdy piątek ręcznie kopiuję zamknięte zgłoszenia do arkusza. Kierownik potrzebuje tematu, daty zamknięcia i osoby odpowiedzialnej. Korespondencja nie jest potrzebna.
Chodzi o przekazanie określonych danych z danego okresu. Wywiad nie uzasadnia eksportu całej bazy, załączników ani całej korespondencji.
Przykładowe kryterium: po wyborze okresu eksport zawiera zamknięte wtedy zgłoszenia i tylko uzgodnione pola. Zasady dla dat granicznych ustal osobno.
| Element PRD | Przykładowy wpis | Status |
|---|---|---|
| Użytkownik | Kierownik wsparcia | Potwierdzono w wywiadzie |
| Pola | Temat, data zamknięcia, osoba odpowiedzialna | Sprawdzić z odbiorcą |
| Poza zakresem tej wersji | Korespondencja i załączniki | Do uzgodnienia |
| Pytanie otwarte | Która strefa czasowa wyznacza granice okresu? | Wymaga odpowiedzi |
Szablon PRD dla jednej funkcji
Powiąż każde wymaganie z obserwacją. Jedno źródło może wspierać kilka punktów, ale ich uzgodnienie trzeba potwierdzić.
Nazwa funkcji i wersja: Problem użytkownika: Konkretny przypadek z wywiadu: Użytkownik i kontekst: Główny scenariusz: Oczekiwany wynik: Dane i ograniczenia: Co wchodzi w zakres i co jest poza nim: Kryteria weryfikacji: Założenia i pytania otwarte: Źródła i znaczniki czasu: Kto zatwierdził i kiedy:
Czy da się sprawdzić wymagania bez autora?
- Każde wymaganie wyjaśnia, jaki problem rozwiązuje.
- Sprawdzalny wynik oddzielono od wybranej realizacji.
- Zakres bieżącej wersji jest jawny.
- Pytania otwarte są oznaczone.
Przyjrzyjmy się szczegółom
Czy PRD można napisać tylko z życzeń zlecającego?
Można przygotować szkic. Sprawdź rzeczywiste scenariusze i ograniczenia. Życzenie opisuje przypuszczalne rozwiązanie i może nie wyjaśniać problemu użytkownika.
Jak długi ma być dokument?
Na tyle, aby wyjaśniał scenariusz, zakres, ograniczenia i weryfikację. Przy małej funkcji krótki dokument z przykładami zwykle jest wygodniejszy od długiego opisu ogólnych celów.