Przystępniejsze dokumenty wymagań produktowych

Nikt nie lubi pisać rozdmuchanych, nadmiernie szczegółowych dokumentów wymagań produktowych. Okazuje się, że nikt nie lubi też z nich korzystać.

Dan Radigan Dan Radigan
Przeglądaj tematy

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.

Tworzenie wspaniałego produktu wymaga mnóstwa analiz i kompleksowego planowania. Ale od czego zacząć? Menedżerowie produktu 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.

Dokumenty wymagań produktowych Agile | Trener Atlassian z zakresu metodyk Agile

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.

Zbieranie wymagań w świecie Agile

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

Wypracowanie wspólnego sposobu rozumienia problemu przez różne zespoły

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 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ć wyciągnięte z niego wnioski. Skorzystaj z naszego poradnika, aby rozpocząć przeprowadzanie przydatnych wywiadów z klientami:

Błędy, których nie należy powielać
  • Cały projekt jest już szczegółowo opisany, zanim rozpoczną się jakiekolwiek prace inżynierskie
  • Przed rozpoczęciem pracy wymagany jest dokładny przegląd i zatwierdzenie przez wszystkie zespoły
  • Projektanci i programiści nie wiedzą, kiedy wymagania zostały zaktualizowane
  • Wymagania nigdy nie są aktualizowane (bo wszyscy je zatwierdzili)
  • Product owner pisze wymagania bez udziału zespołu

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?

Ograniczenie niepotrzebnego rozrostu wymagań za pomocą jednostronicowego pulpitu

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?
Wymagania Agile | Trener Atlassian z zakresu metodyk Agile

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?

Wymagania produktowe Agile | Trener Atlassian z zakresu metodyk Agile

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.

Historyjki związane z wymaganiami Agile | Trener Atlassian z zakresu metodyk Agile

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.

schemat porównania

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.

Wskazówka eksperta:

Manifest Agile przypomina nam, że możemy być elastyczni, jeśli chodzi o sposób tworzenia wymagań. Niektóre zespoły wykonują ćwiczenia z mapowania historyjek użytkowników, aby zidentyfikować problemy i rozwiązania. Czasami cała triada produktu (product owner, programista i projektant) odwiedza klienta, a następnie analizuje rozwiązania konkretnego problemu, o którym on wspomniał.

Bez względu na to, jak powstają wymagania, ważne jest, aby zespół uznał je za jeden z wielu sposobów, w jaki może definiować i komunikować problemy klientów. Zapoznaj się z naszą sekcją poświęconą projektowaniu Agile, aby dowiedzieć się, w jaki sposób product ownerzy mogą używać aplikacji Keynote i Powerpoint do szkicowania prawdziwych doświadczeń jako wymagań.

Przykład jednostronicowego PRD

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.

Przykładowy dokument wymagań produktowych | Trener Atlassian z zakresu metodyk Agile
Dokument wymagań produktowych | Trener Atlassian z zakresu metodyk Agile

Chcesz spróbować? Zarejestruj się lub zaloguj się do Confluence >>

Po zalogowaniu się wybierz schemat wymagań produktowych, a następnie skorzystaj z poniższego samouczka, który pomoże Ci rozpocząć konfigurowanie wymagań:

Kluczowe korzyści z podejścia jednostronicowego:

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 Software, 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 Software 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.

Wyzwania

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.

A teraz do pracy!

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.

Wskazówka eksperta:

Nie śledź historyjek użytkowników, które pochodzą z wymagań projektu, w jednym systemie, a usterek w innym. Zarządzanie pracą w dwóch systemach jest niepotrzebnie skomplikowane i oznacza marnowanie czasu.

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.