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.

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

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:

Zalecamy umieszczenie u góry strony głównych informacji 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?

Przejdź od razu do rzeczy. Informuj, ale nie zanudzaj.

Dlaczego to robimy? Jak to wpisuje się w ogólne cele firmy?

Wymień założenia techniczne, biznesowe lub dotyczące 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.

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

Gdy zespół zaczyna rozumieć problemy do rozwiązania, często pojawiają się pytania. Utwórz tabelę „kwestii, co do których musimy podjąć decyzje lub które musimy zbadać”, aby śledzić takie elementy.

Zadbaj o to, aby zespół skupił się na wykonywanej pracy, jasno określając, czego nie robicie. Oznacz elementy, 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:

Bez zbędnych komplikacji. Dokument wymagań produktowych staje się „stroną docelową” dla wszystkiego, co jest związane ze zbiorem problemów rozwiązywanych w ramach konkretnego epiku. Korzystanie z centralnej lokalizacji pozwala zaoszczędzić czas, który członkowie zespołu poświęcają na dostęp do tych informacji, i zapewnia im zwięzły widok.

Jedną z fantastycznych zalet korzystania z prostej strony do współpracy (zamiast dedykowanego narzędzia do zarządzania wymaganiami) jest możliwość zachowania elastyczności w kwestii dokumentacji. Nie trzeba za każdym razem korzystać z tego samego formatu — rób to, co trzeba i kiedy trzeba, zachowując przy tym elastyczność. W razie potrzeby możesz zmodyfikować szablon.

Często zapominamy, jak skuteczne może być zwykłe łącze. Osadzamy wiele łączy w dokumentach wymagań produktowych. Pomaga to wyeliminować złożoność i stopniowo ujawniać informacje czytelnikowi w razie potrzeby. 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

Widzę, że wielu klientów też to robi. Gdy historyjki zostały już z grubsza przemyślane i zapisane jako zgłoszenia w Jirze, zamieszczamy do nich łącze na naszej stronie (powoduje to również utworzenie łączy prowadzących ze zgłoszeń z powrotem do strony, co jest wygodnym rozwiązaniem). Dwukierunkowa synchronizacja między Confluence a Jirą pozwala automatycznie zobaczyć aktualny status każdego zgłoszenia bezpośrednio na stronie wymagań.

Rejestrowanie wymagań produktowych w 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.

Diagramy 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 treści dynamiczne.

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:

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ą opłacalne. Porozmawiaj ze swoim zespołem o tym, co zrobić w takiej sytuacji.

„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 wdrażania stron typu wiki w organizacji. Istnieje szereg zasobów, które mogą Ci z tym pomóc. W grę mogą też wchodzić 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.