Jak utworzyć dokument wymagań produktowych (PRD)

Kluczowe wnioski

• Dokument wymagań produktowych (PRD) określa cel, funkcje i zachowanie produktu, co pozwala skoordynować działania interesariuszy i pokierować procesem rozwoju.

• PRD zgodne z metodyką Agile koncentrują się na wspólnym zrozumieniu, potrzebach klienta i elastyczności, co pozwala uniknąć zbyt szczegółowych specyfikacji.

• Skuteczne PRD zawierają cele, założenia, historyjki użytkowników, projekt i wyraźnie wskazane elementy wykraczające poza zakres, dzięki czemu wspierają współpracę i zdolność adaptacji.

• Współpracuj ze swoim zespołem, aby tworzyć i regularnie aktualizować zwięzły PRD, dbając o przejrzystość i spójność w całym projekcie.

Opracowanie udanego produktu zaczyna się od jasnego wyznaczenia kierunku i uzgodnienia celów. Właśnie tu przydaje się dokument wymagań produktowych (PRD).

PRD określa podstawowe cechy, cele i funkcjonalność produktu, stanowiąc harmonogram produktu, dzięki któremu zespoły mogą przekształcić pomysły w rzeczywistość. Jest to kluczowy etap dla każdego menedżera produktu, który musi zadbać o spójność działań zespołów, interesariuszy oraz ogólnych celów.

W tym artykule wyjaśnimy, czym jest dokument wymagań produktowych, dlaczego ma on znaczenie oraz w jaki sposób stanowi podstawę skutecznego opracowywania produktów.

Czym jest dokument wymagań produktowych?

Dokument wymagań produktowych (PRD) definiuje produkt, który ma zostać utworzony, przedstawiając jego przeznaczenie, cechy, funkcje i sposób działania.

Określa on przeznaczenie produktu, kluczowe funkcje produktu, potrzeby użytkowników oraz kryteria sukcesu, stanowiąc pojedyncze źródło rzetelnych informacji dla zespołów interdyscyplinarnych.

Dzięki jasnemu opisaniu wymagań i oczekiwań PRD pomaga zapewnić, że wszyscy — od projektantów i programistów po interesariuszy — działają w sposób spójny przez cały proces opracowywania produktu.

Dokument wymagań produktowych w metodyce Agile

Jak wygląda proces gromadzenia wymagań w świecie Agile? Wydaje się skomplikowany — i taki jest. Ale bez obaw.

W Atlassian wiemy wszystko o tworzeniu PRD w środowisku Agile. Wymagania Agile są najlepszym przyjacielem product ownera.

Product ownerzy, którzy nie stosują wymagań Agile, wpadają w pułapkę precyzowania każdego szczegółu, aby dostarczyć właściwe oprogramowanie (a potem trzymają kciuki, mając nadzieję, że wszystko dobrze określili). Z drugiej strony wymagania Agile zależą również od wspólnego zrozumienia potrzeb klienta.

Jest ono wspólne dla product ownera, projektanta i zespołu programistów. To wspólne zrozumienie i empatia wobec docelowego klienta uwalnia ukryty potencjał wykonawczy dla product ownerów.

Mogą oni skupić się na wymaganiach wyższego poziomu i pozostawić szczegóły implementacji zespołowi programistów, którzy są do tego przygotowani — właśnie dzięki wspólnemu zrozumieniu.

Porady dotyczące sporządzania skutecznego dokumentu wymagań produktowych

Jeśli podoba Ci się koncepcja wspólnego zrozumienia, ale nie masz pojęcia, jak je wypracować, wypróbuj poniższe wskazówki:

• Podczas przeprowadzania wywiadów z klientami zaangażuj członków zespołów projektowych i programistycznych, aby mogli bezpośrednio wysłuchać opinii klienta, zamiast polegać na notatkach product ownera. Da im to również szansę na głębsze zbadanie tematu, póki jest on świeży w umyśle klienta.

• Spraw, aby tworzenie i wykorzystanie person klienta było wysiłkiem zespołowym. Każdy członek zespołu ma inną perspektywę i spostrzeżenia i musi zrozumieć, w jaki sposób persony wpływają na rozwój produktu.

• Zadbaj, aby segregowanie zgłoszeń i porządkowanie backlogu także było działaniem zespołowym. To świetna okazja, aby zagwarantować, że wszyscy są na bieżąco i rozumieją, dlaczego product owner nadał poszczególnym zadaniom takie a nie inne priorytety.

Chcesz spróbować? Zarejestruj się w Confluence.

Utwórz szablon wywiadu z klientem, aby dokumentować analizę klienta. Skorzystaj z naszego poradnika, aby rozpocząć przeprowadzanie przydatnych wywiadów z klientami:

• Twórz wartościowe strony wywiadu z klientem.

• Zamieniaj informacje we wnikliwe analizy, korzystając z piramidy wywiadu z klientem.

Omówiliście zestaw historyjek użytkowników z inżynierem i projektantem. Wszystko przeanalizowaliście, odbyliście kilka sesji przy tablicy i doszliście do wniosku, że jest jeszcze kilka aspektów funkcji, nad którą pracujecie, które trzeba uwzględnić.

Musisz sprecyzować pewne założenia, zastanowić się dokładniej, jak wpisują się one w ogólny schemat prac, i śledzić wszelkie otwarte pytania, na które musisz odpowiedzieć. Co dalej?

Co powinien zawierać PRD?

Podczas pisania dokumentu wymagań warto użyć spójnego szablonu dla całego zespołu, aby każdy mógł się zapoznać z tematem i przekazać opinie. W Atlassian tworzymy wymagania produktowe w Confluence przy użyciu przygotowanego w tym celu szablonu.

Naszym zdaniem poniższa sekcja zawiera odpowiedni kontekst, aby zrozumieć wymagania projektu i jego wpływ na użytkowników:

1. Określenie szczegółów projektu

Zalecamy umieszczenie w górnej części strony ogólnych wskazówek w następujący sposób:

• Uczestnicy: kto jest zaangażowany? Określ product ownera, zespół, interesariuszy

• Status: Jaki jest aktualny status programu? Zgodny z celem, zagrożony, opóźniony, odroczony itp.

• Docelowy termin wydania: kiedy planowane jest wydanie?

2. Cele zespołu i cele biznesowe

Przejdź od razu do rzeczy. Informuj, ale nie zanudzaj. Odpowiednie oprogramowanie, które pozwala szczegółowo przedstawić te cele w przejrzystej formie, jest pomocne dla wszystkich zainteresowanych.

Cele biznesowe muszą być jasne i zwięzłe, ale jednocześnie na tyle wyczerpujące, aby zapewnić koordynację działań wszystkich interesariuszy. Nie należy pozostawiać pola do domysłów.

3. Tło i dopasowanie strategiczne

Sekcja dotycząca tła zawiera wyjaśnienie, skąd wziął się pomysł na produkt lub funkcję oraz w jaki sposób wpisuje się on w szersze cele firmy. Przedstawione są w niej powody, dla których projekt jest ważny, oraz problemy, które ma on rozwiązać.

Dokładne wyjaśnienie dopasowania strategicznego gwarantuje, że wszyscy zrozumieją, jak ta praca wspiera wizję i priorytety organizacji. Ta przejrzystość pomaga zespołom skupić się na dostarczaniu wartości, która ma znaczenie.

4. Założenia

Ta sekcja zawiera opis założeń przyjętych przez zespół w odniesieniu do technologii, potrzeb biznesowych lub zachowań użytkowników. Jasne sformułowanie założeń pomaga zidentyfikować potencjalne ryzyka oraz obszary, które mogą wymagać weryfikacji.

Gwarantuje również, że wszyscy są świadomi czynników wpływających na podejmowanie decyzji i planowanie. Regularne weryfikowanie tych założeń w trakcie realizacji projektu może pomóc zespołom w elastycznym reagowaniu na pojawiające się nowe informacje.

5. Historyjki użytkowników

Wymień odpowiednie historyjki użytkowników lub podaj do nich łącza. Zamieść też łącza do wywiadów z klientami i wykonanych zrzutów ekranu. Podaj wystarczająco dużo szczegółów, aby utworzyć kompletną historyjkę, i uwzględnij wskaźniki sukcesu.

6. Interakcja z użytkownikiem i projektowanie

Po opracowaniu przez zespół rozwiązania każdej historyjki użytkownika zamieść na stronie łącze do analiz projektowych i szkieletów projektu.

7. Pytania

Kiedy zespół rozumie problemy, które ma rozwiązać, często ma pytania. Stwórz tabelę „kwestii, co do których musimy podjąć decyzje lub które musimy zbadać”, aby śledzić takie elementy.

8. Czego nie robimy

Spraw, aby zespół skupił się na wykonywanej pracy, jasno określając, czego nie robicie. Oznacz sprawy, które są w tej chwili poza zakresem prac, ale mogą wymagać uwzględnienia w późniejszym czasie.

Korzyści płynące z dobrze napisanego dokumentu wymagań produktowych

Jeśli masz coś wynieść z tego bloga, skup się na pytaniu „dlaczego” — a nie „co” — ponieważ „dlaczego” pomoże Ci ustalić, co jest najlepsze dla Twojego zespołu.

Oto korzyści i wyzwania, jakie zaobserwowaliśmy w podejściu opartym na jednostronicowym pulpicie:

1. Jedna strona, jedno źródło

Prostota rozwiązania. Dokument wymagań produktowych staje się „stroną startową” dotyczącą wszystkich problemów rozwiązywanych w ramach epiku.

Centralne repozytorium pozwala zaoszczędzić czas, jaki członkowie zespołu poświęcają na znalezienie tych informacji, i udostępnia im zwięzły widok.

2. Dodatkowa zwinność

Jedną z fantastycznych zalet korzystania z prostej strony do współpracy (zamiast dedykowanego narzędzia do zarządzania wymaganiami) jest możliwość zachowania zwinności w kwestii dokumentacji. Nie trzeba za każdym razem postępować zgodnie z tym samym formatem — działania można dostosować do aktualnych potrzeb. W razie potrzeby przycinaj i modyfikuj szablon.

3. Wystarczająco dużo kontekstu i szczegółów

Często zapominamy, jak skuteczne może być proste łącze. Osadzamy wiele łączy w dokumentach dotyczących wymagań produktowych. Pomaga to uprościć informacje i ujawniać informacje czytelnikowi w miarę potrzeb.

Można zamieszczać łącza do takich szczegółowych zasobów, jak:

• Wywiady z klientami zapewniające tło, uzasadnienie lub dalszy kontekst funkcji

• Strony lub wpisy na blogu, gdzie zaproponowano podobne pomysły

• Poprzednie dyskusje lub dokumentacje techniczne oraz schematy

• Filmy przedstawiające prezentacje produktów lub inne powiązane treści pochodzące ze źródeł zewnętrznych

4. Żywe historyjki

Gdy historyjki zostały już z grubsza przemyślane i wprowadzone jako zgłoszenia w Jirze, zamieszczamy do nich łącza na naszej stronie (powoduje to również utworzenie łączy ze zgłoszeń z powrotem do strony, co jest wygodnym rozwiązaniem).

Dzięki dwukierunkowej synchronizacji między aplikacjami Confluence i Jira można automatycznie sprawdzić aktualny status każdego zgłoszenia bezpośrednio na stronie wymagań.

5. Zbiorowa mądrość

Rejestrowanie wymagań produktowych w programie Confluence ułatwia innym osobom z różnych zespołów wnoszenie wkładu i przedstawianie sugestii. To niesamowite, jak często ktoś z innego zespołu przyłącza się do rozmowy, dostarczając przydatnych opinii, sugestii lub wniosków płynących z podobnych projektów.

Dzięki temu w dużej organizacji można się poczuć jak w małym zespole.

6. Atrakcyjne dodatki

Diagramy utworzone za pomocą narzędzi, takich jak tablice Confluence, pozwalają skuteczniej komunikować problemy zespołowi. Możesz także osadzać zewnętrzne obrazy, filmy i treści dynamiczne.

7. Współpraca

Najważniejsze jest zaangażowanie wszystkich. Nigdy nie pisz dokumentu wymagań produktowych samodzielnie — zawsze musisz mieć programistę, z którym go przygotujesz. Udostępnij stronę swojemu zespołowi i zdobądź informacje zwrotne.

Komentuj, zadawaj pytania, zachęcaj innych do przekazywania refleksji i pomysłów. Jest to szczególnie ważne w przypadku rozproszonych zespołów, które nie mają często sposobności, by omówić projekty osobiście.

Wyzwania związane z dokumentami wymagań produktowych

Każde podejście ma wady. Istnieją dwa główne wyzwania, z którymi się spotkaliśmy i które zaobserwowaliśmy także u klientów:

1. Dokumentacja może stać się nieaktualna

Co się stanie, gdy wdrożysz historyjkę, a potem zmodyfikujesz rozwiązanie na podstawie otrzymanej opinii? Czy ktoś ma wrócić do strony wymagań i zaktualizować ją zgodnie z ostateczną implementacją?

Jest to wyzwanie w przypadku każdego rodzaju dokumentacji i zawsze warto zastanowić się, czy takie kompromisy są warte zachodu. Zastanów się wspólnie z zespołem, co byście zrobili w takiej sytuacji.

2. Brak uczestnictwa

„Co mogę zrobić, aby zachęcić ludzi do komentowania?”, „Jak zachęcić ludzi do częstszego pisania specyfikacji i historyjek w naszym intranecie?”.

To twardy orzech do zgryzienia, a wszystko sprowadza się do różnych technik stosowania wiki w organizacji. Istnieje szereg zasobów, które mogą Ci tutaj pomóc. Rolę odgrywać mogą też głębiej zakorzenione kwestie kulturowe.

Wykorzystanie aplikacji Jira i Confluence do przygotowania PRD

Gdy wymagania są zwinne, product owner ma więcej czasu, aby zrozumieć rynek i za nim nadążyć. A utrzymanie ich w krótkiej, lecz treściwej formie umożliwia zespołowi programistów zaimplementowanie ich w postaci, która będzie najlepiej pasować do używanej architektury i stosu technologicznego.

Kiedy wymagania projektu są już dość dobrze dopracowane, zalecamy powiązanie historyjek użytkownika z punktu 5 powyżej z odpowiadającymi im historyjkami w wykorzystywanym przez zespół programistyczny narzędziu do śledzenia zgłoszeń.

To sprawia, że proces programistyczny jest bardziej przejrzysty: łatwo jest dostrzec status każdego elementu prac, co przekłada się na bardziej świadome decyzje product ownera, a także zespołów działających na dalszych etapach, takich jak marketingowy i wsparcia.

Pamiętaj, aby zachować podejście Agile przy dostosowywaniu wymagań projektowych. Modyfikowanie historyjek użytkownika w miarę tworzenia, wydawania i zbierania opinii przez zespół jest całkowicie dopuszczalne. Zawsze dbaj o wysoką jakość i zdrową kulturę inżynierską — nawet jeśli oznacza to dostarczanie mniejszej liczby funkcji.