Jak utworzyć dokument określający wymagania dotyczące produktu

Podsumowanie: dokument wymagań produktowych (PRD) określa wymagania danego produktu, w tym jego przeznaczenie, funkcje, funkcjonalność i zachowanie. Służy jako przewodnik dla zespołów biznesowych i technicznych pomagający w budowaniu, wdrażaniu lub wprowadzaniu produktu na rynek.

Building a great product requires tons of research and comprehensive planning. But where do you start? Product managers often start with a product requirements document (PRD).

Dokument wymagań produktowych definiuje produkt, który masz zamiar stworzyć: przedstawia przeznaczenie produktu, jego cechy, funkcje i zachowanie.

Następnie udostępniasz PRD interesariuszom — zespołom biznesowym i technicznym, które pomogą w opracowywaniu produktu, wdrożeniu lub wprowadzeniu go na rynek.

Po zapoznaniu z nim wszystkich interesariuszy PRD służy jako kompas, który wyznacza kierunek pozwalający na osiągnięcie celu produktu, tworząc jednocześnie wspólną płaszczyznę porozumienia między zespołami biznesowymi i technicznymi.

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). Wymagania Agile wymagają z kolei wspólnego zrozumienia klienta przez product ownera, projektanta i zespół programistów. To wspólne zrozumienie i empatia dla klienta docelowego uwalnia ukryty potencjał 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 rejestru zadań także było działaniem zespołowym. To świetna okazja, aby dopilnować, by wszyscy byli tak samo poinformowani i zrozumieli, 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. Definiowanie specyfiki projektu
U góry strony zalecamy podanie ogólnego kierunku 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 strategiczne
Dlaczego to robimy? Jak to wpisuje się 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, 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
Widzę, że wielu klientów też tak robi. Gdy historyjki zostały już z grubsza przemyślane i zapisane jako zgłoszenia w Jira, zamieszczamy do nich łącze 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 oprogramowaniem Confluence i Jira pozwala nam automatycznie zobaczyć aktualny stan 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 marketing i wsparcie.

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.