Przedstawienie backlogu produktu

Gdy już określisz swoje wyniki, zespół może zebrać się i taktycznie podejść do pomysłów na produkty, które pomogą je stworzyć. Pierwszym pragmatycznym krokiem, który możesz zrobić w tym celu jest zastosowanie backlogu produktu.

W pracy napotkaliśmy wiele zespołów produktowych używających jednego backlogu Jiry do rejestrowania wszystkiego: wniosków o dodanie funkcji, małych i dużych możliwości, zadań głównych i podrzędnych, błędów i pilnych zgłoszeń oraz pomysłów na dalszy rozwój produktu.

Zawsze słyszeliśmy od nich tę samą historię. Backlog wymyka się spod kontroli wraz ze stale rosnącą listą zgłoszeń i staje się źródłem niepokoju. Te źle zorganizowane, przytłaczające backlogi nie wspierają ustalania priorytetów na żadnym poziomie, od zmian taktycznych po duże nowe inwestycje.

Zespoły ostatecznie przenosiły te dyskusje do arkuszy kalkulacyjnych, ale co kwartał był to dzień świstaka. Analizy gubiły się, nie rejestrowano decyzji, a zasoby były przydzielane pod presją czasu, w oparciu o przeczucie lub głośno wyrażane opinie.

Jest lepszy sposób: wyznaczony backlog produktu oparty na wynikach, odrębny od backlogu dostarczania przeznaczonego do codziennej pracy.

Czym jest backlog produktu?

Backlog produktu to miejsce, w którym pomysły się tworzy, ustala ich priorytety i dzieli na harmonogramy powiązane z wynikami i celami. Zawiera on wszystkie pomysły na produkty, analizy, możliwości i rozwiązania, a odpowiada za niego zespół produktowy. Zamiast do planowania konkretnych zadań do wykonania, miejsce to służy do omówienia tego, „w co powinniśmy zainwestować i dlaczego?”. Interesariusze w całej firmie mogą zostać zaproszeni do tego backlogu — do współpracy nad priorytetami i harmonogramami oraz do omawiania na bieżąco ogólnego postępu inicjatyw produktowych.

Pomyśl o backlogu produktu jako o domu zespołu produktowego, który można udostępniać współpracownikom z całej firmy. To wydzielona przestrzeń na wszystko, co chcą śledzić — od niejasnych pomysłów po w pełni ukształtowane możliwości — i doskonalić z czasem w oparciu o spostrzeżenia, opinie klientów i zmieniające się ogólne cele.

Backlog produktu vs. backlog dostarczania

Backlog produktu jest oddzielony od backlogu dostarczania, a każdy ma określony cel.

Backlog dostarczania służy do zarządzania dostarczaniem, tworzenia planów dostarczania oraz do śledzenia postępów. Zawiera podział pracy (epiki, historyjki, zadania główne i podrzędne) dotyczący sposobu realizacji zobowiązań, a odpowiada za niego zespół inżynierów. To tutaj cały zespół spotyka się i współpracuje, omawiając kwestie związane z dostarczaniem: sekwencjonowanie, zależności, potencjał wykonawczy i techniczne kamienie milowe.

Oczywiście backlogi produktu i dostarczania są ze sobą ściśle powiązane. Praca w backlogu dostarczania prowadzi do pomysłów w backlogu produktu, które same są powiązane z pożądanymi wynikami. Daje to liderom, menedżerom i programistom ogólne spojrzenie na to, jak zespół pracuje nad osiągnięciem wyników podczas powtarzania cykli odkrywania i dostarczania.

W odróżnieniu od backlogu produktu, wszystkie elementy backlogu dostarczania są pomyślane jako konkretne plany, które mają zostać ostatecznie ukończone. Natomiast backlog produktu służy do generowania pomysłów i przeprowadzania burz mózgów, a także do planowania. Niektóre pomysły na produkty nigdy nie będą miały ustalonych priorytetów i nie trafią do harmonogramów — i tak ma być.

Oddzielając ogólne obawy dotyczące produktów od planowania i śledzenia dostarczania, zespoły mogą skuteczniej ustalać priorytety, łączyć pracę z wynikami i unikać niekontrolowanych backlogów, które starają się być uniwersalne.

Zalety backlogu produktu

Korzystanie z oddzielnych backlogów produktu i dostarczania ma wiele zalet:

• Jest to bezpieczna przestrzeń dla zespołu produktowego do omawiania potencjalnych pomysłów oraz dostępnych danych, bez martwienia się o to, na ile są one wykonalne lub zdefiniowane.

• Łączy dyskusje o produktach w jednym miejscu, dzięki czemu zespoły mogą z czasem poszerzać wiedzę bez konieczności przeszukiwania dziesiątek arkuszy kalkulacyjnych.

• Tworzy wspólne źródło rzetelnych informacji i powszechne zrozumienie priorytetów produktu. Zwalcza to częsty problem, z którym borykają się zespoły produktowe: podejmowanie decyzji w oparciu o przeczucie lub najgłośniej artykułowane opinie klientów i interesariuszy.

• Zapewnia przejrzystość dyskusji dotyczących priorytetów, gromadząc wszystkich pracowników firmy we wspólnej przestrzeni. Eliminuje to wiele tarć podczas współpracy z interesariuszami i zespołami mającymi kontakt z klientami.

• Jest powiązany z dostarczaniem, dlatego harmonogramy się nie dezaktualizują i pozostają godne zaufania, ponieważ uwzględniają ograniczenia w dostarczaniu.

Jak zorganizować backlog produktu

Pomysły, możliwości, problemy, rozwiązania: zespół produktowy musi zdecydować, co umieścić w backlogu produktu. Powinno to być to, dla czego zespół stara się ustalić priorytety, oraz reprezentować sposób myślenia zespołu o inwestycjach i priorytetach dotyczących produktów.

Bardzo ważne jest, aby zespół produktowy kontrolował to, co trafia do backlogu produktu, a także strukturę wykorzystywaną do klasyfikowania pomysłów i ustalania dla nich priorytetów. W przeciwnym razie ryzykuje, czymś w rodzaju dryfowania backlogu ku dezorganizacji, której właśnie próbował uniknąć.

Aby kontrolować backlog, zewnętrznych interesariuszy należy zapraszać wyłącznie ze wstępnie zdefiniowanymi sposobami wnoszenia wkładu, a nie z bezpośrednimi uprawnieniami do tworzenia i edycji elementów. Przykładowo współpracownicy ci mogą dodawać komentarze, głosować na pomysły lub otagować klienta, który poprosił o dodanie jakiejś funkcji.

Poniżej znajdują się dwa przykłady zalecanych ram porządkowania backlogu produktu: głazy, kamienie i kamyki oraz długie, średnie i krótkie listy. Zalecamy zorganizowanie backlogu produktu wokół tych trzech zasobników oraz tych czynności.

W Jira Product Discovery odbywa się to przez skonfigurowanie określonych widoków w celu wyświetlenia odpowiednich pomysłów i wybranie pól, które mają być widoczne, aby pomóc w dyskusji (wybór, ocena) i zachęcić do współpracy (analizy, głosy, komentarze, reakcje).

Głazy, skały i kamyki

Wiele zespołów produktowych ma tylko jeden typ obiektu: „pomysł”. Ale backlog może zawierać elementy o różnych kształtach, rozmiarach i poziomach szczegółowości, od dużych nowych założeń po małe ulepszenia produktów.

Powszechną praktyką jest uporządkowanie backlogu za pomocą trzech kategorii elementu:

• głazy: duże inwestycje, możliwości strategiczne i duże nowe założenia;

• kamienie: średnie inwestycje, znaczące ulepszenia produktów, które przynoszą wyniki;

• kamyki: małe inwestycje, takie jak naprawianie drobnych błędów i zgłoszeń dotyczących środowiska użytkownika.

Najlepiej jest stworzyć dla nich oddzielne obszary w backlogu produktu oraz pomyśleć o zrównoważeniu inwestycji między nimi i zarezerwowaniu dla każdego z nich miejsca w budżecie i harmonogramie. Szczególnie dla kamyków trudno jest ustalać priorytety bez tego rodzaju intencjonalności. Duże nowe założenie jest ekscytujące, ale drobne usterki mają wyjątkowo negatywny wpływ na wrażenia użytkownika.

Więcej informacji na temat tych ram znajdziesz w sekcji Pomysły.

Długa lista, średnia lista i krótka lista

Autorem kolejnego prostego, pragmatycznego sposobu porządkowania backlogu produktu jest Brent Johnson, jeden z pierwszych użytkowników Jira Product Discovery. Brent opisał pracę nad produktem jako ciągłe posługiwanie się 3 zasobnikami: długą, średnią i krótką listą.

Zespół produktowy czerpie pomysły z długiej listy przez średnią po krótką w backlogu produktu, zachęcając interesariuszy z całej firmy do współpracy.

• Długa lista zawiera wszystko: pomysły potencjalne, problemy, możliwości lub rozwiązania. Na tej liście może znaleźć się ponad 200 pomysłów.

  • Zespół produktowy selekcjonuje tę długą listę, wykorzystując swoją wiedzę na temat rynku, zagadnień strategicznych i operacyjnych oraz potrzeb klientów i firmy, aby przekształcić ją w średnią listę.

• Średnia lista to wstępny wybór potencjalnych priorytetów: atrakcyjne możliwości, w które zespół mógłby zasadnie zainwestować. Z długiej listy 200 pomysłów kilkanaście może trafić na średnią listę.

  • Są to pomysły, które wyglądają jak dobre założenia, ponieważ są ważne strategicznie, często pojawiają się w dyskusjach z klientami lub mają duży potencjał, aby zachwycić użytkowników. Na jej podstawie powstaje krótka lista, zazwyczaj przy udziale różnych interesariuszy w firmie.

    • Aby uzyskać więcej informacji, zobacz sekcję Ustalanie priorytetów.

• Krótka lista to w zasadzie harmonogram produktu: pomysły, które zespół produktowy zobowiązał się dodatkowo zbadać. Zadania te wdrażają możliwości, problemy lub rozwiązania, aby rozpocząć tworzenie środowiska produktu lub ulepszyć istniejące.

  • Zespół regularnie przegląda tę listę w zależności od tego, czego się dowiaduje, i systematycznie ją aktualizuje. To lista, na której reszta firmy najczęściej może spodziewać się aktualizacji.

    • Aby uzyskać więcej informacji, zobacz Tworzenie harmonogramów.

Jak utworzyć backlog produktu w Jira Product Discovery

Stworzyliśmy Jira Product Discovery jako miejsce, w którym zespoły produktowe mogą gromadzić swoje pomysły, wspólnie nad nimi pracować i ustalać ich priorytety. W Jira Product Discovery możesz utworzyć backlog lub backlogi produktów, zwane „Projektami Discovery”.

Na ogół najlepiej jest zebrać ludzi, którzy codziennie pracują razem w tym samym projekcie (np. w grupie lub kilku grupach). Jednak wielu klientów Jira Product Discovery korzysta z jednego projektu do obsługi wielu zespołów i produktów. Szczególnie przydaje się to, gdy wymagana jest ścisła współpraca między tymi zespołami.

Poniżej pokazano, jak to zrobić:

Plan Premium Jira Product Discovery pozwala wizualizować pomysły z wielu projektów w jednym miejscu, tworząc widoki przedstawiające pomysły z wielu projektów i całą historię planów produktów organizacji.

Co dalej?

W dalszej części tego podręcznika wyjaśnimy szczegółowo, w jaki sposób wykorzystać backlog produktu do:

• zbieraj pomysły od powstania po dostawę;

• konfigurowania kanałów informacji zwrotnej i gromadzenia analiz w celu weryfikacji pomysłów;

• ustalania priorytetów dla pomysłów, które mogą wywrzeć wpływ;

• tworzenia harmonogramów, wokół których zespoły i interesariusze mogą się skupić.

Podamy przykłady, jak to robimy w zespole Jira Product Discovery, korzystając z Jira Product Discovery i innych produktów.