Zarządzanie produktem Scrum: kompletny przewodnik i przykłady

Scrum nie jest niczym nowym w obszarze zarządzania produktem. Większość z nas korzysta ze Scruma w swoich firmach i stara się poruszać w ramach ról i zasad tego modelu, aby osiągać wyznaczone cele.

Niestety firmy często błędnie interpretują zasady Scruma i niewłaściwie je stosują, pozbawiając tym samym użytkowników wielu korzyści płynących ze Scruma.

Ten niewielki, lecz przydatny przewodnik ma pomóc Ci lepiej korzystać z tego modelu, wyjaśniając, na czym on polega, dlaczego istnieją różne role w Scrumie, jakie są obowiązki związane z zarządzaniem produktem oraz jak doskonalić współpracę międzyfunkcyjną.

Czym jest Scrum w zarządzaniu produktem?

Wielu z nas lubi omawiać rolę menedżera produktu w rzeczywistości procesów Scrum i metodyki zwinnej (innymi słowy, to, co PM robi w zespole Scrum). Zamiast tylko to wyjaśniać, uważam, że łatwiej będzie po prostu pokazać Ci, gdzie PM znajduje się na schemacie organizacyjnym zespołu.

W tym przewodniku chcę jednak podejść do tego tematu z przeciwnej strony i pokazać, jak Scrum wpisuje się w Twoją rzeczywistość jako specjalisty ds. zarządzania produktem oraz jak może pomóc Ci osiągnąć cele związane z produktem.

Chcę rozpocząć od omówienia wpływu podstawowych zasad modelu Scrum na skuteczność naszej pracy.

Notatka autora

Jeśli potrzebujesz odświeżyć sobie te zasady, Agile Alliance ma dla Ciebie świetny przewodnik.

Prawdopodobnie najcenniejszą dla nas zasadą Scruma jest nieustanne dostarczanie wartości użytkownikom. Im szybciej ludzie mogą rozwiązywać problemy, tym lepiej będzie działać Twój produkt. Co więcej, uzyskujesz dostęp do wczesnych opinii osób, które korzystały z danej funkcji w rzeczywistym scenariuszu.

Drugą korzyścią, jaką daje Scrum, jest elastyczność. Jeśli zmieni się rzeczywistość rynkowa, możesz szybko się do niej dostosować, całkowicie przebudowując rejestr produktu i przekazując zespołowi nowe funkcje w kolejnym sprincie (może w tym pomóc sztuczna inteligencja w planowaniu sprintu).

Te dwie rzeczy są bardzo trudne (lub niemal niemożliwe) do osiągnięcia przy użyciu tradycyjnych modeli, takich jak model kaskadowy, w którym zakres jest od początku ustalony, a użytkownicy uzyskują dostęp do produktu dopiero na samym końcu cyklu życia oprogramowania.

Przykłady sukcesu produktów dzięki integracji ze Scrumem

Po latach pracy z zespołami Scrum jestem całkowicie stronniczy na rzecz tego zwinnego modelu. Nie traktuj więc moich słów jak prawdy objawionej. Zamiast tego przyjrzyjmy się rzeczywistym przypadkom, w których przejście na Scrum pomogło zespołom produktowym szybciej odnieść sukces.

Microsoft Visual Studio: Główne narzędzie giganta technologicznego do edycji kodu słynęło z powtarzających się cykli produkcyjnego chaosu, pełnych wadliwych wydań i niezwykle rzadkich publikacji. Od momentu, gdy zespół produktowy zaczął korzystać ze Scruma, firma odnotowała gwałtowny wzrost stabilności produktu, a także znacznie częstsze cykle wydań, odzyskując konkurencyjność na rynku.

Spotify: Wdrożenie Scruma przez nasz ulubiony serwis strumieniowego przesyłania muzyki należy do najbardziej znanych przypadków w branży. Spotify miało trudności z wystarczająco szybkim dostosowaniem się i skalowaniem, aby rozwiązać problemy procesowe... aż do momentu, gdy organizacja wdrożyła Scrum. Tym, co wyróżnia Spotify, jest jednak opracowanie własnego modelu zarządzania projektami Scrum, który zakładał istnienie grupy autonomicznych zwinnych zespołów mających dostęp do całej potrzebnej wiedzy specjalistycznej, aby szybko eksperymentować i uwzględniać opinie użytkowników.

ING: Holenderski gigant bankowy należał do grona pierwszych instytucji finansowych, które zdały sobie sprawę, że przyszłość bankowości jest cyfrowa. Zrozumiano również, że bardzo tradycyjne procesy zarządzania projektami nie sprawdzały się w tworzeniu oprogramowania. Dlatego szybko wdrożono metodyki szczupłe i Scrum, a następnie — co nie było zaskoczeniem — bank stał się liderem bankowości elektronicznej.

Najważniejsze role w zarządzaniu produktem w Scrumie

Jeśli jako PM zdecydujesz, że Scrum jest właściwym rozwiązaniem, oto krótki przegląd najważniejszych ról w tym modelu, który pomoże Ci odróżnić swoją rolę menedżera produktu od roli właściciela produktu w Scrumie.

Zacznijmy od ról. Typowy zespół Scrum składa się z następujących osób:

• Mistrz Scrum: Ta osoba pomaga zespołowi przestrzegać zasad Scrum i optymalizować procesy.
• Właściciel produktu: Ta osoba reprezentuje biznes i użytkowników w zespole Scrum. Właściciele produktu są odpowiedzialni za rejestr produktu oraz ustalanie celów sprintu i priorytetów historyjek użytkownika.
• Zespół Scrum: Twoi deweloperzy, projektanci, specjaliści ds. QA i inni specjaliści, którzy tworzą produkt.

Jeśli chodzi o zespół Scrum, może znajdować się w nim wiele innych typów specjalistów. Koncepcja zespołów interdyscyplinarnych zakłada, że zespół jest niezależny pod względem dostępu do specjalistycznej wiedzy. Jeśli więc na przykład Twój produkt w dużej mierze opiera się na analityce, możesz mieć w zespole również analityka danych.

Menedżer produktu a właściciel produktu: jaka jest różnica?

Podana przeze mnie definicja właściciela produktu może nieco Cię zdezorientować, ponieważ brzmi bardzo podobnie do tego, czym zazwyczaj zajmuje się menedżer produktu.

Jaka jest więc w tym przypadku różnica między menedżerem produktu a właścicielem produktu?

Aby zrozumieć tę różnicę, przyjrzyjmy się najpierw głównym obowiązkom każdej z tych osób.

Menedżerowie produktu

• Prowadzą analizę produktu i rozumieją potrzeby oraz problemy klientów.
• Określają wizję produktu i kierunek, za którym będzie podążać zespół.
• Opracowują rozwiązania produktowe, które mogą spełnić potrzeby klientów.
• Przewodzą procesowi dostarczania produktu.
• Udoskonalają produkt małymi krokami na podstawie opinii klientów i podejmowania decyzji w oparciu o dane.
• Zarządzają wizją produktu i jej realizacją w całej firmie oraz na wszystkich jej szczeblach.

Właściciele produktu

• Tworzą i utrzymują rejestr produktu.
• Są dla zespołu Scrum jednym, wiarygodnym źródłem informacji na temat strategii, projektu i logiki biznesowej.
• Ustalają priorytety elementów rejestru produktu i wyjaśniają zespołowi, co jest ważne.
• Określają kryteria akceptacji funkcji i na ich podstawie akceptują wyniki sprintu.
• Odblokowują członków zespołu, wyjaśniając wymagania i rozwiązując związane z nimi problemy.
• Uczestniczą w wydarzeniach Scrum i pełnią w zespole rolę głosu biznesu oraz klientów.

Jak widzimy, większość z nas wykonuje zadania, które można znaleźć na obu listach. Jest to całkowicie normalne i powszechne, ponieważ wiele osób jednocześnie pełni funkcję menedżera produktu i właściciela produktu.

Podstawowa różnica między tymi dwiema funkcjami polega na tym, że zarządzanie produktem jest zawodem i zestawem umiejętności, podczas gdy właścicielstwo produktu jest rolą w zespole Scrum.

Co to jednak oznacza?

Oznacza to, że właściciel produktu nie musi być menedżerem produktu. W małym startupie, w którym pracuje dyrektor generalny oraz trzech deweloperów, dyrektor generalny obejmie rolę właściciela produktu, dostarczając deweloperom rejestr produktu z ustalonymi priorytetami.

Możliwa jest również sytuacja odwrotna. Możesz być menedżerem produktu i nie być właścicielem produktu. Jestem dobrym przykładem, ponieważ jeden z moich poprzednich zespołów nie korzystał ze Scrum. Bez Scrum nie było w zespole właściciela produktu. Przestrzegaliśmy jednak zasad Lean i Agile.

Aby lepiej wyjaśnić różnicę między tymi dwiema rolami, poniżej przedstawiam bezpośrednie porównanie ich zadań.

Jaki był jednak sens tworzenia specjalnej roli w zespole Scrum? Czy nie mogli po prostu współpracować z menedżerami produktu, którzy nie są częścią zespołu? Bardzo podoba mi się odpowiedź, której udziela na to Teresa Torres.

Głównym powodem istnienia konkretnej roli związanej z produktem w zespole Scrum jest więc wnoszenie wewnętrznej wiedzy i doświadczenia dotyczących produktu oraz dalsze wzmacnianie interdyscyplinarności zespołu. 

Jak menedżer produktu współpracuje z zespołami Scrum

Zakładając, że zdecydowałeś się wybrać ścieżkę Scrum, musisz wiedzieć, jak być członkiem zespołu i jak współpracować ze swoimi ludźmi. Pozwól, że krótko omówię to w odniesieniu do każdego wydarzenia Scrum i artefaktu.

• Codzienny Scrum (tzw. stand-upy): Najważniejszym zadaniem podczas tych spotkań odbywających się w określonych ramach czasowych jest udzielanie odpowiedzi na pytania zespołu deweloperskiego dotyczące produktu oraz usuwanie przeszkód.
• Spotkanie planowania sprintu: To Ty wyznaczasz cel sprintu, jasno określając swoje oczekiwania dotyczące funkcji, które mają zostać dostarczone.
• Retrospektywa sprintu: Procesy, których używasz do przekazywania zespołowi priorytetów i wymagań, mogą przesądzić o jego skuteczności. Możesz więc wykorzystać to spotkanie do zebrania opinii zespołu i usprawnienia swoich procesów.
• Przegląd sprintu: Twoim zadaniem jest zaakceptowanie ukończonych funkcji sprintu oraz przekazanie zespołowi opinii na temat jego pracy.
• Dopracowywanie produktu (tzw. dopracowywanie): Jesteś właścicielem tego spotkania i musisz wykorzystać przeznaczony na nie czas do omówienia priorytetów oraz szczegółów historyjek użytkownika, które masz dla zespołu. Zawsze zachęcaj zespół do kwestionowania Twoich wymagań i znajdowania „błędów produktu”, które się w nich znalazły.
• Rejestr produktu: Twoim obowiązkiem jest zarządzanie rejestrem produktu oraz utrzymywanie go w uporządkowanym i priorytetyzowanym stanie, ponieważ zespół będzie na jego podstawie budować swój sprint.
• Rejestr sprintu: To nie jest Twoja własność. Twoim głównym obszarem współpracy jest pokierowanie zespołem tak, aby wybrał właściwe historyjki do rejestru sprintu i mógł osiągnąć cel sprintu.

Oprócz tego będziesz zajmować się innymi rodzajami pracy związanej z produktem, takimi jak zarządzanie interesariuszami czy odkrywanie produktu. Jako członek zespołu Scrum Twoim zadaniem jest dbanie o to, aby zespół znał zarówno potrzeby interesariuszy, jak i użytkowników po ich wyjaśnieniu.

Jeśli na przykład przeprowadzisz wywiad z użytkownikiem i odkryjesz, że korzystanie z procesu logowania jest ogólnie dezorientujące, ważne jest, aby podzielić się tą informacją z zespołem i upewnić się, że zwróci on uwagę na ten obszar w kolejnych sprintach.

Najlepsze praktyki zarządzania produktem w Scrumie

Zarządzanie produktem może wydawać się łatwe, gdy spojrzymy na nie przez pryzmat Scruma (i ogólnie zwinnego wytwarzania oprogramowania), jednak podczas pracy w samoorganizujących się zespołach często popełniamy wiele błędów.

Oto kilka najlepszych praktyk Scruma, które pomogą Ci ich uniknąć:

• Ustal jasne oczekiwania: Największym błędem, jaki możesz popełnić, jest przekazywanie zespołowi niejasnych priorytetów i wymagań. Brak klarowności jest jedną z głównych przyczyn opóźnień w wytwarzaniu oraz napięć między Tobą a zespołem. Wkrótce szczegółowo omówimy, jak to osiągnąć.
• Nie nadużywaj elastyczności: Możliwość zmiany kierunku jest świetna, ale możesz to robić wyłącznie w rejestrze produktu, a nie w rejestrze sprintu. Gdy tylko sprint się rozpocznie, nie dodawaj do niego ani nie usuwaj z niego żadnych historyjek. Zakłóca to plany i postępy zespołu oraz prowadzi do niedokończonych sprintów.
• Stwórz bezpieczne emocjonalnie środowisko: Jesteś członkiem zespołu, a nie jego szefem. Nie wywieraj więc na zespół presji, aby podejmował większe zobowiązania lub kończył pracę wcześniej. Wszystkie przewodniki po Scrumie, w tym przewodnik Scrum.org, kładą duży nacisk na utrzymywanie zdrowych relacji z członkami zespołu, ponieważ jest to jeden z fundamentów skutecznej pracy zespołowej.

Te trzy najlepsze praktyki są najważniejsze na podstawie mojego doświadczenia. Jeśli jednak potrzebujesz więcej wskazówek dotyczących zwinnych przepływów pracy i najlepszych praktyk Scruma dla menedżerów produktu, koniecznie zapoznaj się z naszym osobnym przewodnikiem po zwinnym zarządzaniu produktem.

Skuteczne zarządzanie rejestrem produktu

Jak wspomniałem wcześniej, zapewnienie zespołowi jasnych informacji jest jednym z najważniejszych zadań menedżera produktu. Dobrą wiadomością jest to, że rejestr produktu jest prawdopodobnie najlepszym narzędziem do osiągnięcia tego celu. Oto kilka wskazówek dotyczących zarządzania rejestrem produktu, które Ci w tym pomogą:

Dopracowywanie: Niezależnie od tego, jak dobrze napiszesz swoje historyjki użytkownika, pozostawisz w nich „błędy” i będziesz potrzebować zespołu deweloperskiego, aby je sprawdził i wskazał. Dochodzi do tego fakt, że nie jesteś deweloperem i możesz napisać wymagania, które są trudne do wdrożenia. Zespół poinformuje Cię o tym podczas procesu dopracowywania.

Techniki priorytetyzacji: Wykorzystaj liczne ramy priorytetyzacji, aby zrozumieć, które funkcje są ważniejsze od innych. Moją ulubioną jest MoScoW ze względu na jej prostotę.

Zgodność z planem rozwoju i wizją: Epiki i historyjki w Twoim rejestrze powinny odzwierciedlać ogólne cele produktu oraz wskaźniki, które chcesz osiągnąć. Pamiętaj więc, aby stale przeglądać plan rozwoju podczas dodawania czegokolwiek do rejestru.

Uzgadnianie stanowisk interesariuszy w Scrumie

Istota roli menedżera produktu w Scrumie polega na tym, że jesteś zasadniczo ogniwem łączącym samoorganizujący się zespół ze światem zewnętrznym, czyli użytkownikami, interesariuszami lub innymi zespołami.

Oprócz wykonywania standardowych obowiązków związanych z zarządzaniem interesariuszami jako menedżer produktu musisz również przekazywać te informacje swojemu zespołowi i odwrotnie. Zdarzają się także sytuacje, w których musisz przekazać interesariuszom informacje od zespołu.

Dobrym przykładem jest pojawienie się wyzwań technicznych, takich jak problemy z ciągłą integracją, które mogą wpłynąć na harmonogram lub zakres danej funkcji. Jest to coś, co musisz omówić z interesariuszami, a następnie zaakceptować nowy harmonogram lub zakres albo opracować inne rozwiązanie (np. wzmocnić zespół dodatkowymi kompetencjami związanymi z daną kwestią).

Zdarzają się również sytuacje, w których zespół mógł wpaść na interesujący pomysł dotyczący funkcji lub rozwiązania, które warto dodać do mapy drogowej. Ponownie przekazujesz te informacje interesariuszom i decydujesz, czy ostatecznie dodać ten pomysł do planu.

Znaczenie zwinnego tworzenia mapy drogowej w Scrumie

Choć zwinne mapy drogowe nie są bezpośrednią częścią Scruma, są jednym z narzędzi, które umożliwiają jego stosowanie. W końcu jaki jest sens iteracyjnego planowania, jeśli zamiast zwinnej mapy drogowej używasz modelu kaskadowego dla swojego produktu?

W takim przypadku to, co nazywasz strategią produktu w Scrumie, byłoby po prostu podzieleniem z góry ustalonego i niezmiennego planu opartego na klasycznym cyklu życia oprogramowania (SDLC) na części trwające 2 tygodnie (lub tyle, ile trwają twoje sprinty). Aby Scrum miał dla twojego zespołu sens, musisz prowadzić interaktywne zwinne planowanie i budować mapę drogową, która może zmieniać się z czasem.

Aby właściwie połączyć zwinną mapę drogową z procesami Scrum twojego zespołu, proponuję:

• Połącz elementy mapy drogowej (zwykle epiki) z historyjkami użytkownika w rejestrze produktu. W ten sposób powstaje bezpośrednie połączenie między pracą taktyczną (historyjkami) a strategią (mapą drogową).
• Przedstaw mapę drogową swojemu zespołowi Scrum. Dzięki temu zespół będzie wiedział, w jakim kierunku zmierza produkt, i będzie uwzględniał nadchodzące funkcje podczas projektowania architektury interfejsu użytkownika lub zaplecza.
• Wykorzystaj specjalistyczne narzędzia, takie jak Jira, Monday.com i Clickup, aby usprawnić proces tworzenia mapy drogowej i zarządzania rejestrem produktu.

Jeśli chodzi o ostatni punkt, są to trzy narzędzia, z których korzystałem w praktyce. Istnieje jednak wiele innych narzędzi do zarządzania produktem, które również możesz rozważyć.

Wyzwania związane z zarządzaniem produktem w Scrumie

Choć Scrum jest świetnym środowiskiem do realizacji celów produktu, korzystanie z niego wiąże się z własnym zestawem wyzwań, takich jak:

• Twój zespół lub interesariusze mogą nie rozumieć, na czym polega Scrum. Może to oczywiście prowadzić do poważnych problemów z wdrożeniem Scruma, takich jak odmowa korzystania z określonych artefaktów. Zalecam zapobiec temu, przedstawiając pożądany „stan docelowy”, czyli pokazując, jak będą wyglądać zespół i przepływ pracy po pełnym wdrożeniu tego frameworka.
• Ludzie (w tym Ty) mogą mieć wątpliwości co do swojej roli w zespole i poza nim. Każda firma, w której pracowałem w swojej karierze, miała własne rozumienie tego, czym zajmuje się właściciel produktu w Scrumie. Najlepiej jasno określić, czym ta rola jest — i czym nie jest — dla Twojego zespołu.
• Zakres funkcji, nad którymi pracujesz, ma tendencję do niekończącego się rozszerzania. Nic dziwnego, że bardzo łatwo w ten sposób doprowadzić do niekontrolowanego rozszerzania zakresu. Zespoły Scrumowe muszą bezkompromisowo decydować, czym się zajmować, a czemu mówić „nie”.
• Plan rozwoju produktu może łatwo zejść z właściwego toru. Jeśli masz stosunkowo niezależny zespół, który może wybierać, nad czym pracować, może się okazać, że zacznie tworzyć rzeczy niezgodne z Twoim planem rozwoju produktu. Wyraźne koncentrowanie się na celu końcowym ma kluczowe znaczenie dla uniknięcia tej pułapki.

Choć te wyzwania są dość powszechne, dobra wiadomość jest taka, że kierownikowi produktu wystarczy kilka sprintów, aby zrozumieć proces Scrumowy i przezwyciężyć zdecydowaną większość z nich. Osoby, które chcą sformalizować swoją wiedzę, mogą dzięki nauce tego, jak zostać Scrum Masterem zyskać wiarygodną przewagę w prowadzeniu zespołów przez ten framework.

Podsumowanie

Scrum to jeden z najlepszych prezentów dla menedżerów produktu. Dzięki równowadze między stosowaniem podejścia zwinnego w długiej perspektywie a ścisłym przestrzeganiem zasad w ramach krótkich iteracji możesz uniknąć chaosu zwinnego procesu tworzenia produktu pozbawionego frameworka, zachowując jednocześnie możliwość zmiany kierunku rozwoju produktu w zależności od reakcji rynku.

Mamy nadzieję, że nasz przewodnik Ci się spodobał. Jeśli tak, nie zapomnij zapisać się do naszego newslettera, aby otrzymywać więcej materiałów i przewodników dotyczących zarządzania produktem, a także najnowsze podcasty, wywiady i inne spostrzeżenia liderów oraz ekspertów z branży.