Skuteczne wydania zaczynają się od dokumentu wymagań produktu (PRD), który zawiera pięć następujących kroków:
- Zdefiniuj cel produktu.
- Rozłóż cel na cechy.
- Określ cele dla kryteriów wydania.
- Określ harmonogram.
- Upewnij się, że interesariusze dokonają przeglądu.
Przeanalizujemy każdy z tych kroków poniżej. Czytaj dalej lub przeskocz do sekcji, którą chcesz:
- Co to jest PRD (Dokument Wymagań Produktowych) Excel
- Co z zwinnym dokumentem wymagań?
- Jak napisać PRD (Dokument Wymagań Produktowych)
- Szablon PRD: A Product Requirements Document Example
- A PRD and Traceability
Co to jest dokument wymagań produktu (PRD)?
Dokument PRD (dokument wymagań produktu) przedstawia wymagania dotyczące tego, co zamierzasz zbudować, aby ludzie wiedzieli, co gotowy produkt powinien robić.
Dokument PRD jest najlepszym przyjacielem menedżera produktu. Wyznacza kierunek dla wydania. I zapewnia, że dostarczysz to, czego oczekują klienci – na czas.
Każdy interesariusz związany z wydaniem produktu – programiści, testerzy, kierownicy projektu – powinien wiedzieć, co znajduje się w PRD.
PRD zazwyczaj zawiera następujące elementy:
- Purpose – Dla kogo jest to produkt i dlaczego go budujesz.
- Features – Co zamierzasz zbudować.
- Release Criteria – Cele wydania (np, funkcjonalność).
- Timeline – przybliżone okno dla wydania.
Co z dokumentem wymagań Agile?
Dokumentacja jest zazwyczaj przeciwieństwem Agile. Ale zwinne zespoły deweloperskie również korzystają z PRD.
W zwinnym rozwoju, tworzy się historie użytkowników zamiast tradycyjnych wymagań. Tak więc, dokument wymagań Agile zbiera historie użytkowników niezbędne do wydania.
Obejmuje on wciąż te same elementy – cel, cechy, kryteria wydania, harmonogram. Ale dokument wymagań Agile zazwyczaj robi to w formie tablicy zadań lub interaktywnego dokumentu, a nie statycznego dokumentu.
Ponadto, PRD nie musi być powieścią. Możesz zawrzeć najważniejsze informacje o wydaniu produktu w jednym dokumencie – i zapewnić, że Twój zespół programistów będzie trzymał się kursu Agile.
👉🏼 PRZECZYTAJ: Jak zrobić hybrydę Agile w regulowanej branży >>
Jak napisać PRD (Product Requirements Document)
Pisanie skutecznego PRD jest ważne.
Mimo, że możesz mieć za zadanie napisanie właściwego dokumentu, powinien on być efektem współpracy. Będziesz współpracować z wieloma interesariuszami z całego działu rozwoju. To gwarantuje, że wszyscy są po tej samej stronie, jeśli chodzi o cele wydania produktu. Daje również pewność, że to, co tworzysz, spełnia potrzeby klienta i może zostać ukończone na czas.
Pamiętaj: ogólnym celem PRD jest określenie, co zamierzasz zbudować – a nie jak to zrobisz.
Oto pięć kroków do napisania skutecznego PRD, który pozwoli na udane wydanie produktu.
Zdefiniuj cel produktu
Każdy pracownik działu rozwoju musi być zgodny co do celu produktu. Cel musi napędzać cechy.
Cel powinien określać:
- Jakie problemy rozwiązuje ten produkt.
- Kto będzie korzystał z produktu.
- Dlaczego jest on ważny.
Każdy z interesariuszy powinien zgodzić się na cel – i być go świadomym w miarę postępu prac rozwojowych.
Rozłóż cel na funkcje
Następnym krokiem jest określenie wymagań dotyczących funkcji dla wydania. Każda funkcja powinna wspierać ogólny cel produktu.
Najlepszą praktyką przy określaniu wymagań dotyczących funkcji jest zdefiniowanie najpierw tematów i inicjatyw.
Temat ustawia organizację na lata.
Kilka przykładów tematów może być następujących:
- API
- Performance
- Mobile
Tematy mogą obejmować wiele lat i cykli wydawniczych.
Inicjatywy są używane do dostosowania wysiłków rozwojowych w celu osiągnięcia tematu. Dzięki inicjatywom wiesz, że sprawy zmierzają we właściwym kierunku. Inicjatywa może obejmować wiele tematów, na przykład włączenie funkcji dla API, wydajności i urządzeń mobilnych.
Od tego momentu, inicjatywa rozbija się na wymagania dotyczące funkcjonalności.
▶️ WATCH: From Planning a Theme to Setting Requirements >>
Set the Goals For the Release Criteria
Ustalenie właściwych celów dla kryteriów wydania pomoże Ci osiągnąć cel wydania produktu.
Twoje cele powinny być:
- Łatwe do zrozumienia.
- Aktywne.
- Achievable.
- Measurable.
A kryteria wydania powinny obejmować pięć obszarów.
Funkcjonalność
Będziesz musiał zdefiniować minimalną funkcjonalność, której potrzebujesz, aby wydać produkt. Przykładem jest zdefiniowanie wymagań, które są krytyczne dla wydania.
Usability
Będziesz musiał zapewnić, że produkt jest łatwy w użyciu. Przykładem jest określenie zakresu testów z użytkownikami – i co zrobisz z ich wynikami.
Reliability
Będziesz musiał określić, czy Twój produkt jest niezawodny. Przykładem może być upewnienie się, że jest on w stanie odzyskać sprawność po awarii systemu.
Wydajność
Będziesz musiał ustalić bazę dla wydajności. Przykładem jest określenie jak szybko produkt musi się ładować.
Wsparcie
Będziesz musiał określić, że wydanie może być wspierane. Przykładem może być zapewnienie, że będzie ono mogło być zainstalowane i skonfigurowane przez użytkowników.
Określ ramy czasowe
Każde wydanie produktu potrzebuje docelowej daty wydania – nawet jeśli jest to tylko przybliżone oszacowanie.
To powinno dać Ci elastyczność, aby dostosować się do zmiany priorytetów. Powinno to jednak ograniczać rozrost zakresu projektu poprzez ograniczenie liczby funkcji, które mogą dodać interesariusze.
Zarządzanie procesem wydawania – i osiąganie docelowej daty wydania – może być trudne.
▶️WATCH: How to Fix Your Release Process >>
Make Sure Stakeholders Review It
Kiedy tworzysz PRD, ważne jest, aby kluczowi interesariusze przejrzeli ten dokument.
To może być trudne, gdy zarządzasz dokumentem wymagań w Microsoft Word.
Najlepszą praktyką jest posiadanie centralnego rozwiązania, w którym można zarządzać przeglądami wymagań online. Wtedy można mieć pewność, że wszyscy patrzą na najbardziej aktualną wersję dokumentu. Można też cofnąć się i prześledzić, w jaki sposób coś się zmieniło.
Ważne jest również, aby wszyscy zaangażowani w rozwój produktu wiedzieli, co znajduje się w PRD. Powinien on być udostępniony wszystkim, od deweloperów, przez testerów, aż po managerów.
📑 GET WHITE PAPER: 9 Tips for Writing Useful Requirements >>
PRD Template: A Product Requirements Document Example
Wiele zespołów używa Microsoft Word do tworzenia i zarządzania PRD.
Oto przykład dokumentu wymagań produktu w Microsoft Word:
Uaktualnianie PRD jest trudne w narzędziu takim jak Microsoft Word. Trudno jest zapewnić dokładność, gdy wymagania są śledzone w jednym miejscu – z dala od reszty rozwoju. Upewnienie się, że każdy ma dostęp do najnowszej wersji jest wyzwaniem. Trudniej jest współpracować. I praktycznie niemożliwe jest bycie Agile.
Dlatego wiele zespołów programistycznych używa oprogramowania do zarządzania wymaganiami, aby stworzyć PRD. To pozwala im pozbyć się silosów informacji. Wymagania są zawsze aktualne. I może być używany przez każdy zespół deweloperski, niezależnie od tego, czy podążają za procesami Waterfall czy Agile.
Oto przykład tego samego PRD w Helix ALM:
Dokument wymagań Agile może być również tworzony w tablicy zadań. Daje to możliwość wglądu w status wymagań.
Na przykład na tej tablicy Kanban zobaczysz, w jaki sposób historyjki użytkownika (wymagania) są przeglądane i wdrażane.
Jeśli rozwijasz się w sprintach (jak większość zespołów Agile), możesz wykorzystać Helix ALM do monitorowania postępu każdego sprintu. Zobaczysz, które historyjki użytkownika zostały zaimplementowane i zatwierdzone.
A PRD and Traceability
Pisanie PRD to tylko jeden krok w kierunku efektywnego rozwoju i lepszego procesu wypuszczania produktów. Udane wydania zależą również od dokładnych testów i szybkiego usuwania błędów.
Dlatego najlepszą praktyką jest posiadanie narzędzia – takiego jak Helix ALM – w którym można śledzić historie użytkowników (lub wymagania), testy i problemy w jednym miejscu. Następnie, możesz nawet użyć swojego PRD do zapewnienia pokrycia testowego poprzez tworzenie przypadków testowych z historyjek użytkownika. Możesz też śledzić wyniki aż do rozwiązania błędu.
✏️ Poznaj 6 ćwiczeń wzmacniających identyfikowalność >>
W Helix ALM odbywa się to poprzez macierz identyfikowalności (która jest generowana automatycznie przez narzędzie):