Szablon roadmapy produktu: pola do skopiowania

Szablon roadmapy produktu to krótka tabela, w której każdy wiersz to jedna pozycja, a każda kolumna to pole, które obiecujecie utrzymywać wypełnione. Wersja, która sprawdza się w większości małych zespołów, ma sześć pól: rezultat, źródło, status, właściciela, pewność i datę przeglądu. Cała reszta, co spotkacie w szablonach do pobrania, czyli tory, story pointy i kolumny kwartałów, jest opcjonalna i zwykle to ona sprawia, że roadmapa przestaje być aktualizowana.

Co powinien zawierać szablon roadmapy produktu?

Dodajcie tylko pola, z których czytelnik korzysta przy podejmowaniu decyzji, i dopisujcie nowe wyłącznie wtedy, gdy umiecie wskazać, kto je przeczyta. Rezultat to powód istnienia wiersza. Źródło pozwala klientowi znaleźć w nim własną prośbę. Status mówi, czy praca się posuwa. Właściciel to osoba, której można zadać pytanie. Pewność chroni prognozę przed odczytaniem jej jako obietnicy, a data przeglądu nie pozwala wierszowi się zestarzeć.

Dwa pola warto dodać, jeśli zespół o nie prosi. Lista “nie robimy”, trzymana obok tabeli, zapisuje, przeciwko czemu zdecydowaliście się i dlaczego, co oszczędza tej samej dyskusji co kwartał. Kolumna “ostatnio zmienione” zapisuje, kiedy wiersz edytowano, więc czytelnik odróżni aktualną roadmapę od porzuconej.

W pierwszej wersji zostawcie poza szablonem: daty inne niż data przeglądu, szacunki nakładu pracy, story pointy i prognozy przychodów. Te rzeczy należą do dokumentów planistycznych, gdzie mogą się zmieniać, a nikt nie uzna ich za zobowiązania.

Jak wygląda wypełniony szablon roadmapy produktu?

Oto tabela z zmyśloną aplikacją do zadań jako produktem. Wszystkie pozycje są wymyślone, a kolumna statusu ma tylko trzy wartości.

Dwa wiersze niosą lekcję. “Tryb offline” nie ma właściciela i ma niską pewność, co jest uczciwym sposobem na powiedzenie “myślimy o tym”. “Masowa edycja terminów” jest zamknięta, a nie usunięta, więc klienci, którzy o nią prosili, nadal znajdą, dokąd trafiła.

Jeśli wolicie zwykły tekst, ta sama tabela działa jako plik Markdown w repozytorium, który trafia do kontroli wersji obok pracy:

| Outcome | Source | Status | Owner | Confidence |
|---|---|---|---|---|
| Keep the last filter | 14 requests | Building | Dana | Committed |
| Company SSO sign-in | 9 requests | Planned | Marcus | Forecast |

Jaki format powinien mieć szablon?

Użyjcie tabeli, jeśli roadmapa ma najwyżej dziesięć pozycji, a czytelnicy chcą szczegółów. Użyjcie trzech kolumn, Now, Next i Later, jeśli często zmieniacie kierunek i nie chcecie bronić dat. Układ Now/Next/Later opisuje przewodnik Atlassian po roadmapach produktu, razem z układem osi czasu i tematycznym.

Powyższa tabela i tablica z trzema kolumnami zawierają te same dane. Tabela jest lepsza dla osób, które pracują w roadmapie, a tablica dla tych, które tylko na nią zerkają. Przykłady roadmapy produktu pokazują sześć formatów z realistycznymi pozycjami i tłumaczą, jak każdy z nich zawodzi, więc układ wybierzecie, gdy pola będą już ustalone.

Jak wypełnić szablon, nie zgadując?

Zacznijcie od próśb, które już macie, a rezultat zapiszcie na końcu. Pogrupujcie otwarte prośby według problemu, który opisują, policzcie je i wpiszcie liczbę do kolumny źródła. Wiersz bez źródła to opinia, a opinia jest dozwolona, ale powinna tak wyglądać.

Potem uszeregujcie wiersze regułą, którą potraficie wytłumaczyć klientowi. Priorytetyzacja próśb o funkcje omawia metody punktacji i to, dlaczego same głosy wprowadzają w błąd. Kolejność wierszy odpowiada na pytanie “co pierwsze”, a kolumna statusu na pytanie “co się dzieje”.

Pewność oceniajcie uczciwie. Wiersz z zobowiązaniem oznacza, że zespół byłby zaskoczony, gdyby nie wydał go w tym oknie. Wiersz z prognozą oznacza, że to plan, o ile nic się nie zmieni. Wiersz “badamy” oznacza brak jakiejkolwiek obietnicy, a roadmapa, która pokazuje klientom takie wiersze, powinna wyjaśnić, co to słowo znaczy.

Jak często aktualizować szablon?

Aktualizujcie go przy każdej zmianie statusu pozycji i przeglądajcie każdy wiersz w jego dniu przeglądu. Roadmapa się starzeje, gdy jej aktualizowanie jest osobnym obowiązkiem, więc trzymajcie ją tam, gdzie już toczy się praca. Jeśli źródłem prawdy jest wasz system zgłoszeń, etykiety mogą sterować kolumną statusu i nikt niczego nie przepisuje. Jak publiczna roadmapa pozostaje uczciwa pokazuje układ “etykieta na kolumnę”, którego używa Changeloop.

Gdy wiersz zostaje wydany, powiedzcie o tym osobom, które o niego prosiły. Tego nie zrobi za was żadne pole szablonu i właśnie dlatego warto zachować kolumnę źródła. Pętla feedbacku klienta opisuje całą drogę od prośby do ogłoszenia.

Czy szablon powinien być publiczny?

Opublikujcie wersję okrojoną, jeśli chcecie, by klienci widzieli, że ich prośba została usłyszana. Publiczny szablon zachowuje rezultat i status, a pomija właściciela, pewność i datę przeglądu. Pomija też wszystko, czego nie bronilibyście w rozmowie handlowej. Mniejsza lista, która pozostaje aktualna, robi dla zaufania więcej niż długa, która cichnie; strona szablonu ProdPad pokazuje, jak jeden z dostawców ją układa.

FAQ

Czym jest szablon roadmapy produktu? To wielokrotnego użytku tabela lub tablica ze stałym zestawem pól dla każdej pozycji roadmapy, takich jak rezultat, status, właściciel i pewność. Kopiujecie ją, wypełniacie jeden wiersz na pozycję i utrzymujecie aktualną.

Jakie kolumny powinna mieć roadmapa produktu? Minimum to rezultat, status i właściciel. Gdy roadmapa ma więcej niż kilka pozycji, dodajcie źródło prośby, poziom pewności i datę przeglądu.

Czy roadmapa produktu powinna zawierać daty? W większości zespołów tylko datę przeglądu. Daty kalendarzowe zamieniają się w zobowiązania, które sprzedaż i klienci cytują potem z powrotem, więc użyjcie etykiety pewności i okna czasowego, takiego jak Now, Next i Later.

Czy mogę trzymać roadmapę w arkuszu lub pliku Markdown? Tak. Arkusz pasuje zespołowi, który edytuje ją wspólnie, a tabela Markdown w repozytorium zespołowi, który chce ją mieć w kontroli wersji. Wybierzcie miejsce, w którym praca jest już śledzona, żeby aktualizacje nie były osobnym obowiązkiem.

Twierdzenia techniczne w tym artykule nie zostały niezależnie zweryfikowane. Jeśli coś się nie zgadza, daj nam znać, a poprawimy to.

Powiązane w changeloop: Dokumentacja dla deweloperów, Przykłady changeloga