Przegląd prototypowego dokumentu zarządzania produktem
 |
Kenton Kivestu, ex-Google, ex-BCG, Founder at RocketBlocks Publikacja: September 11, 2019 | Last updated: November 8, 2019
|
Podstawy PRD | Zawartość PRD | PRD walkthrough | PRD pełny przykład
PRD to uporządkowany zestaw wytycznych dotyczących tego, czym powinien być produkt (lub cecha).
W ostatecznym rozrachunku PRD jest złotym środkiem wśród dokumentów związanych z rozwojem produktu: nie może być zbyt wyświechtany (np, informacja prasowa), ani nie może być zbyt techniczny (np. szczegółowy inżynierski plan wdrożenia).
W związku z tym, jednym z pomocnych sposobów myślenia o PRD jest myślenie jak o dokumencie pomostowym, który może wziąć wysokopoziomową wizję produktu i zdefiniować ją oraz określić jej zakres na tyle, aby inżynier mógł na jej podstawie napisać wiarygodny plan wdrożenia.
Dlaczego firmy zawracają sobie głowę pisaniem PRD? PRD służy jako fundamentalny artefakt, który określa powód istnienia produktu / funkcji, odpowiadając na fundamentalne pytania: Dlaczego powinniśmy go zbudować? Jaki problem rozwiążemy? Jak powinien wyglądać? Jak będzie wyglądał sukces?
Które firmy używają PRD i kto je pisze? (Top)
Dodatkowo, preferowana nomenklatura różni się w zależności od firmy (a czasem nawet od zespołu!). Na przykład, Google historycznie określa te dokumenty jako PRD, podczas gdy firma Zynga, zajmująca się grami, określa je jako specs, co jest skrótem od specyfikacji produktu.
Wreszcie, kierownicy produktu są często autorami PRD, ale nie jest to prawdą w każdym przypadku. W szczególności, w mniejszych firmach i startupach, PRD może być napisany przez założyciela, CTO, szefa działu inżynierii lub innego lidera pomagającego w rozwoju produktu. Niezależnie jednak od tego, kto jest autorem PRD, wkład kluczowych członków zespołu jest krytyczny dla stworzenia dobrego PRD.
Jakie sekcje i treści powinny znaleźć się w PRD? (Góra)
Zespoły, które korzystają z PRD mają tendencję do ustalania listy sekcji „must have” w PRD, które mają sens dla wielkości organizacji, cyklu wydawniczego, etapu produktu i złożoności. W tym miejscu skupimy się na kilku „zwykle podejrzanych” sekcjach, które są powszechnie zawarte w wielu PRD:
- Kontekst & uzasadnienie: dlaczego to budujemy?
- Cele & metryka sukcesu: jaki jest konkretny cel robienia tego?
- Przypadki użycia: jakie konkretne przypadki użycia powinno to umożliwić?
- Wymagania: co musi zostać zbudowane?
- Pytania otwarte: na jakie pytania należy odpowiedzieć, zanim zaczniemy?
Aby przejrzeć każdą z tych sekcji PRD, wyobraźmy sobie, że piszemy PRD dla małego dodatku do aplikacji mobilnej Ubera skierowanej do kierowców. Wyobraźmy sobie, że piszemy PRD, aby dodać mały wycinek tekstu deskryptora do strony, którą Uber pokazuje kierowcom, gdy otwierają aplikację po zakończonej jeździe (zrzut ekranu poniżej).
Przykładowy PRD: Aktualizacje aplikacji Ubera skierowane do kierowców (góra)
Teraz, przejdźmy przez każdą sekcję i wyobraźmy sobie, jak może wyglądać PRD rozwiązujący ten problem.
Sekcja 1: Kontekst & uzasadnienie
Ta sekcja powinna przedstawiać podstawowy kontekst, który wyjaśnia dlaczego dana funkcja lub produkt jest rozważany. Może ona zawierać anegdoty z zespołu wsparcia, obserwacje z badań UX, dane rynkowe lub spostrzeżenia zespołu na temat kierunku, w jakim produkt powinien się rozwijać.
W zależności od kultury zespołu i zakresu funkcji, ta część może być krótka lub długa. Niektóre organizacje uwielbiają przeprowadzać szczegółowe, bardzo ilościowe analizy, które uzasadniają potrzebę wprowadzenia danej funkcji.
W przypadku naszego przykładowego PRD dla Ubera, moglibyśmy sobie wyobrazić coś takiego:
Ostatnie sesje badawcze z użytkownikami pokazały, że wielu kierowców często pomija ocenę swojego kierowcy na tym ekranie, ponieważ nie pamiętają, którego kierowcę oceniają (np, wielu kierowców nigdy nawet nie widzi swojego kierowcy twarzą w twarz, ponieważ siedzą z tyłu).
Ponieważ oceny kierowców są ważnym zbiorem danych dla naszych algorytmów i operacji, każda „zachęta”, jaką możemy dać użytkownikom do oceniania kierowców, będzie miała istotny, potęgujący się wpływ na działalność firmy.
Sekcja 2: Cele & metryki sukcesu
Następnie, sekcja celów będzie, co nie jest zaskakujące, określać konkretny cel(y), który ma być osiągnięty przez funkcję / produkt. Podczas gdy sekcja kontekstowa namaluje obraz tego, dlaczego zespół może uważać, że wysiłek jest ważny, sekcja celów powinna wbić konkretny kołek w ziemię na temat tego, jak firma / zespół / produkt skorzysta i jak to zmierzyć.
Powracając do naszego PRD Ubera, sekcja celów może wyglądać następująco:
Zwiększenie o 5% liczby kierowców ocenianych przez kierowców w obliczu ekranu oceny ukończenia jazdy.
Sekcja 3: Przypadki użycia
Przypadki użycia opisują, w jaki sposób klienci będą wchodzić w interakcje z proponowanymi zmianami funkcji. Celem jest opisanie konkretnego kontekstu, w jakim klienci będą korzystać z funkcji i w jaki sposób pomoże to klientom w wykonaniu określonych zadań.
Powrócimy do naszego przykładu ekranu oceny ukończenia jazdy Uberem:
Travis ostatnio wziął Ubera późnym wieczorem w piątek po spotkaniu z przyjaciółmi. Nie korzysta z Ubera ponownie aż do następnej środy podczas pracowitego dnia w pracy, w którym to momencie otwiera aplikację i widzi ocenę realizacji przejazdu dla jazdy w piątek wieczorem. Nie pamięta, kiedy ostatnio korzystał z Ubera i nie rozpoznaje kierowcy. W rezultacie, naciska przycisk „Pomiń” zamiast oceniać kierowcę.
Sekcja 4: Wymagania
To może być uważane za „mięso” PRD, gdzie to, co jest faktycznie budowane, zostanie nakreślone. W zależności od funkcji lub produktu, o którym mowa, ta część może zawierać schematy funkcji, makiety w pełnej wierności, szczegóły dotyczące zmian, które będą musiały być dokonane na front-endzie (np. aplikacje mobilne) i/lub backendzie (np. bazy danych, przetwarzanie, itp.).
Spójrzmy na to, jak to może wyglądać dla przykładu Uber:
Front-end
- Wyświetl nowy wycinek tekstu deskryptora poniżej aktualnej podpowiedzi oceny
- Kopiuj (przykład): „Twój przejazd z piątku wieczorem”
API
- Podczas żądania szczegółów przejazdu (np, kierowca, zdjęcie kierowcy, itp.), należy również pobrać deskryptor przejazdu (nie ma potrzeby budowania nowej logiki, wystarczy użyć tych samych deskryptorów przejazdu, które już umieściliśmy w tematach mailowych potwierdzeń przejazdu, zamiast konkretnych znaczników czasu).
Sekcja 5: Pytania otwarte
Wreszcie, pytania otwarte to sekcja używana jako „parking” do zadawania pytań, które autor musi zbadać, podjąć decyzję lub uzyskać informację zwrotną zanim uzna PRD za ukończony.
- Jaki kolor i rozmiar powinien mieć tekst deskryptora na ekranie? Cc @design – czy możesz polecić odpowiednie parametry tutaj?
- Jak bardzo ziarniste są deskryptory przejazdów, które są generowane (np, czy są one bardziej szczegółowe niż, powiedzmy, piątek wieczorem?)
- Jeśli ta funkcja nie przyniesie pożądanych rezultatów, jakie kolejne kroki powinniśmy rozważyć?
Połączenie wszystkiego razem: pełny przykład PRD (góra)
Jeśli połączysz wszystko, co omówiliśmy razem, ostatecznie otrzymasz dokument, który wygląda jak ten poniżej (link do fikcyjnego dokumentu tutaj). UWAGA: To *nie* jest prawdziwy PRD Ubera – jest to reprezentatywny, fikcyjny przykład oparty na prawdopodobnym scenariuszu.
Nawet bardzo prosta funkcja, jak ta opisana powyżej, może wygenerować PRD przekraczający stronę! Jak możesz sobie wyobrazić, bardziej skomplikowane funkcje mogą skończyć generując PRD o wiele, wiele dłuższe niż omawiany tutaj przykład.
Podsumowanie: końcowe przemyślenia na temat PRD
To co przejrzeliśmy powyżej jest reprezentatywną migawką tego jak wygląda PRD dzisiaj.
Jak wspomniano, jest to reprezentatywna próbka, ale powinna zapewnić kierunkowo dokładne wyobrażenie o tym jak może wyglądać PRD. Nie zdziw się jednak, jeśli zobaczysz tam różne formaty lub różne rodzaje treści (np. sekcję z szacunkami pracy od lidera inżynierii na temat tego, jak długo potrwa budowa, itp.) Na przykład, tutaj znajduje się świetny szablon PRD przygotowany przez Kevina Yiena, Product Lead w Square.
Na koniec, nowoczesne platformy komunikacyjne i narzędzia produktywności, takie jak Slack, Google Docs, Notion, Quip, Office Online, Dropbox Paper, Asana, będą miały znaczący wpływ na ewolucję PRD w nadchodzących dekadach. Już teraz widzimy, jak dokumenty PRD ewoluują, stając się „żywymi” dokumentami, które oznaczają kluczowych współpracowników, wymagają komentarzy i informacji zwrotnych oraz zawierają dodatkowe dane (np. tabele, zrzuty ekranu itp.).
Jednakże, mimo wszystko, jedna kluczowa rzecz nie ulegnie zmianie: potrzeba pewnego rodzaju dokumentu produktowego, który pozwoli dostosować interesariuszy, posłuży jako wysokopoziomowy plan i przełoży wizję na konkretne wymagania dotyczące produktu.
P.S. Czy przygotowujesz się do rozmów kwalifikacyjnych z PM?
Prawdziwe pytania z rozmów kwalifikacyjnych. Przykładowe odpowiedzi od liderów PM w Google, Amazon i Facebook. Dodatkowo arkusze do nauki kluczowych pojęć.