Jak utworzyć dokument wymagań produktowych (PRD)

Opracowanie świetnego produktu wymaga mnóstwa badań i kompleksowego planowania. Ale od czego zacząć? Menedżerowie produktów często zaczynają od dokumentu wymagań produktowych (PRD).

A product requirements document defines the product you are about to build: It outlines the product's purpose, its features, functionalities, and behavior.

Next, you share the PRD with (and seek input from) stakeholders - business and technical teams who will help build, launch or market your product.

Once all stakeholders are aligned, the PRD serves as a compass, providing clear direction toward a product's purpose while creating a shared understanding among business and technical teams.

Jak wygląda zbieranie wymagań w świecie Agile? Wydaje się złożone — i takie jest. Ale bez obaw. W Atlassian wiemy wszystko o tworzeniu PRD w środowisku Agile. Oto kilka rzeczy, o których trzeba pamiętać:

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 kolei wymagania Agile zależą również od wspólnego zrozumienia klienta przez product ownera, projektanta i zespół programistyczny. 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 wymagań klienta (a to niespodzianka).

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ę lub zaloguj się do 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

• Zamień informacje we wnikliwe analizy, korzystając z piramidy rozmowy z klientem

Więc tak: 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?

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łowe i cele biznesowe Przejdź prosto do sedna. Informuj, ale nie zanudzaj.

3. Tło i dopasowanie strategiczneDlaczego to robimy? Jak się to wpisuje w ogólne cele firmy?

4. Założenia

Wymień założenia techniczne, biznesowe lub dotyczące użytkownika.

5. Historyjki użytkowników

Wymień odpowiednie historyjki użytkowników lub zamieść do nich łącza. Zamieść też łącza do wywiadów z klientami i zrzutów ekranu. Podaj wystarczająco dużo szczegółów, aby stworzyć kompletny obraz, 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.

Oto dopracowany dokument wymagań produktowych (PRD), który stworzyliśmy przy pomocy Confluence. Pamiętaj, że każdy tego typu dokument jest nieco inny. Jest to tylko przykład pomagający zrozumieć różne elementy, które powinny być zawarte w Twoim PRD, ale nie jest to definitywny sposób postępowania.

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). Dwukierunkowa synchronizacja między aplikacjami Confluence i Jira pozwala automatycznie zobaczyć 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

Schematy wykonane za pomocą narzędzi takich jak Visio, Gliffy czy Balsamiq pozwalają skuteczniej komunikować problemy zespołowi. Możesz także osadzać zewnętrzne obrazy, filmy i zawartość dynamiczną.

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.

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

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 niższego szczebla, takich jak marketingowy i wsparcia.

Pamiętaj, stosuj podejście Agile do ewolucji wymagań projektu. W miarę tworzenia i wydawania oprogramowania oraz pozyskiwania opinii klientów historyjki użytkowników mogą ulec zmianie. Zawsze dbaj o wysoką jakość i zdrową kulturę inżynierską — nawet jeśli oznacza to wydawanie mniejszej liczby funkcji.