Pielęgnacja, bądź inaczej – udoskonalenie, rejestru produktu (ang. Product Backlog Refinement) pomaga podejmować właściwe decyzje dotyczące produktu i przygotować rejestr produktu (ang. Product Backlog) do kolejnego przebiegu. Jest to niezbędna aktywność, którą śmiało mogę porównać do podlewania. Jeżeli nie będziemy tego robić – roślina padnie. Analogicznie się dzieje z produktem, z tym, że to nieco bardziej skomplikowane zadanie…
W tym artykule przedstawię w pięciu krokach, jak skutecznie udoskonalam swój backlog produktowy. Mam nadzieję, że dla wielu z Was ścieżka ta stanie się inspiracją do stworzenia swojego indywidualnego modelu.
Krok 1: Analiza informacji zwrotnych i danych
Udoskonalenie rejestru produktu rozpoczynam od analizy informacji zwrotnych i danych zebranych w wyniku ujawnienia przyrostu produktu docelowym użytkownikom i klientom. Przyrostem może być już działające oprogramowanie ale także prototyp (ten papierowy również). Zawsze zależy mi na tym żeby możliwie jak najszybciej podzielić się „ze światem” wytworzonym kawałkiem pracy, bowiem im wcześniej uzyskam informację zwrotną i zwaliduję pomysł – tym szybciej będę mogła go dostrajać.
Uzyskane dane mają charakter ilościowy, jakościowy lub oba – w zależności od zastosowanej techniki walidacji. Lubię pracować zarówno z danymi jakościowymi, jak i ilościowymi i łączyć na przykład bezpośrednią obserwację z testami A/B. Najczęściej przydają mi się tutaj ankiety, wywiady czy statystyki z zewnętrznych narzędzi mierzących zachowania użytkowników (np. heatmapy). Oceniając opinie, skupiam się na danych, które są istotne, by móc zrozumieć, czy tworzę właściwy produkt lub jak mogę go dalej ulepszać i optymalizować.
Mam odwagę powiedzieć „nie” nowym pomysłom i prośbom, jeśli nie są one pomocne w osiągnięciu obecnego celu produktu. Nauka mówienia nie to nie lada wyzwanie, ale też ważna umiejętność w pracy każdego produktowca – w przeciwnym razie produkt może stać się po prostu zlepkiem funkcji z niewielkim lub żadnym połączeniem.
Zawsze pamiętam i również podkreślam to w pracy z zespołem, że negatywna informacja zwrotna to najlepsza informacja zwrotna. Jeśli wszystko co słyszę jest pozytywne, to wiem, że nie nauczę się niczego nowego i tracę szansę na ulepszenie produktu. Wolę więc usłyszeć brutalną prawdę, która pozwoli mi na refleksję bądź zmianę kierunku działania.
Krok 2: Wyciąganie wniosków
Po przeanalizowaniu informacji zwrotnych rozpoczynam proces wyciągania wniosków. Na ich podstawie klasyfikuję (akceptuję i odrzucam) pomysły i zarządzam backlogiem produktu – usuwam, dostosowuję i dodaję do niego elementy, w tym epiki, wymagania niefunkcjonalne, szkice projektu czy też diagramy opisujące przepływy prac. W wyniku analiz może się również okazać, że cel produktu, do którego dążyliśmy, nie jest już aktualny lub w ogóle wykonalny w ramach ograniczeń czasowych i budżetowych, bądź po prostu na ten moment nie ma już sensu (jest „nierynkowy”, nieopłacalny)… Jeśli tak się zdarzy to również uaktualniam roadmapę produktu i przedstawiam zmiany interesariuszom.
Krok 3: Wstępne oszacowanie
Mając zidentyfikowane pomysły, przedstawiam je zespołowi. Wspiera to transparentność oraz pozwala na szybką identyfikację ewentualnych zagrożeń. Ponieważ zebrane pomysły to najczęściej tylko idee, głos zespołu i ich „czelendżowanie” jest dla mnie niezwykle ważne. Proszę również zespół, aby wyszacował elementy backlogu, które zostały dodane lub dostosowane, a także nowo utworzone historie. Pozwala to zrozumieć z grubsza, ile wysiłku jest zawarte w backlogu, aby ustalić później priorytety według kosztów i korzyści oraz śledzić postępy rozwoju, na przykład za pomocą wykresu realizacji wersji.
Krok 4: Decyduję, co robić dalej
Po włączeniu nowych spostrzeżeń do backlogu i po wstępnym oszacowaniu, decyduję, co robić dalej. Zadaję sobie pytania: Jakie pomysły i założenia chcę zweryfikować? Jakim ryzykiem muszę się zająć? Jaką funkcjonalność chcę zapewnić lub ulepszyć?
Priorytetyzacja zadań jest niezwykle ważna – choć bardzo bym chciała, wiem, że nie da się zrealizować wszystkich inicjatyw na raz. Pomysły które chciałabym zwalidować najszybciej zajmują pierwsze pozycje na liście – chcę możliwie jak najszybciej wiedzieć czy warto inwestować w nie energię swoją i zespołu. Priorytetyzuję elementy backlogu w oparciu o technikę MoSCoW (akronim od ang.: Must, Should, Could, Would not). Nie będę się w nią teraz zgłębiać, jeżeli jeszcze jej nie znasz – jest wiele wiarygodnych źródeł wiedzy w tym temacie na internecie. Ważny w priorytetyzacji jest dla mnie efekt kroku poprzedniego, czyli znajomość poniesionego nakładu pracy w kontekście uzyskanych korzyści.
Krok 5: Dekomponuję i przygotowuję zadania
W tym momencie w backlogu produktu mam jeszcze duże, niezdekomponowane zadania. Przystępuję więc do ich dekompozycji a następnie wyszacowuję je oraz ponownie priorytetyzuję backlog.
Mając rejestr w takim stanie upewniam się, że wszystkie jego elementy są odpowiednio przygotowane. Zajmuję się wówczas zadaniami, które jako pierwsze wejdą w kolejkę zadań programistycznych, czyli zadań z najwyższym priorytetem. Zawsze korzystam tutaj z rady, którą usłyszałam na jednym ze szkoleń: zadania rozpisuję tak późno, jak to jest możliwe. Dzięki temu unikam sytuacji, w której mam rozpisane zadania ze średnim priorytetem, i może się okazać, że w kolejnych przebiegach, zostaną zmodyfikowane bądź usunięte z rejestru na skutek kolejnej pielęgnacji backlogu.
Odpowiednie rozpisanie oznacza dla mnie, że zadania są przygotowane zgodnie z ustaloną definicją gotowości (ang. Definition of Ready). W niej między innymi wpisana jest zasada, że zadania muszą być zgodne z techniką INVEST (akronim ang. Independent, Negiotiable, Valuable, Estimable, Small, Testable). Jeżeli nie znasz tej techniki koniecznie się z nią zapoznaj. W zadaniach również przypominam definicję gotowości zadania (ang. Definition of Ready). Te dwa artefakty, to moim zdaniem must have dla wszystkich zespołów programistycznych. Dzięki nim można uniknąć nieporozumień co do tego, co jest potrzebne do zadania oraz kiedy zadanie uznaje się za zakwalifikowane do potencjalnego wdrożenia. Odpowiednio przygotowane zadanie wspiera weryfikację zależności między zespołami, jeżeli nad produktem pracuje więcej niż jeden zespół, co bezpośrednio pomaga w planowaniu prac.
Udoskonalanie Backlogu Produktu to praca zespołowa!
Kiedy rozmawiam z produktowcami o ulepszaniu ich backlogów, często słyszę, że poszczególne osoby wykonują tę pracę samodzielnie – zresztą sama w przeszłości tak robiłam. Szybko jednak odkryłam, że to marnuje ogromną szansę: złagodzenie moich uprzedzeń poznawczych, stworzenie współwłasności backlogu produktu oraz wykorzystanie zbiorowej kreatywności i wiedzy zespołu. Angażuję członków zespołu w prace nad udoskonalaniem backlogu i odkąd to robię, widzę masę korzyści. Zmniejsza to moje obciążenie pracą i owocuje lepszymi wymaganiami – a co za tym idzie – lepszym produktem. Nie boję się „czelendżowania” i podejmowania decyzji, jeśli podczas sesji z zespołem nie uda się osiągnąć konsensusu. Pamiętaj, że praca z zespołem jest kluczowa w maksymalizowaniu korzyści minimalizując nakłady pracy!
Fot. Arina Krasnikova z Pexels
Project Leader o technicznym backgroundzie i product managementowej przeszłości. Ex-perfekcjonistka po „odwyku” identyfikująca się z mottem „bądź najlepszym niedoskonałym sobą, jakim zdołasz”. Fanka specyficznego humoru półświatka IT, wiernego kompana (psa) Astona i kryminalnych podcastów!