Pułapki odpowiedzialności Product Ownera

W poprzednim odcinku rozmawialiśmy o tym, skąd brać Product Ownerów. Pozostajemy w obszarze produktowym i rozmawiamy o pułapkach odpowiedzialności Product Ownera. W tym odcinku poznasz pięć pułapek, które dokładnie analizujemy. Do każdej pułapki dajemy Ci kilka porad, które pomagają radzić sobie z nimi. Całość jak zawsze na bazie naszej praktyki.

W tym artykule poruszymy temat pułapek związanych z pełnieniem roli Product Ownera. Jest to kontynuacja poprzedniego tematu, w którym omawialiśmy, skąd brać Product Ownerów. Omówimy konkretne i praktyczne rozwiązania, które można zastosować w celu uniknięcia tych problemów.

Z tego artykułu dowiesz się, jakie są najczęstsze wyzwania, z którymi borykają się Product Ownerzy oraz co zrobić, gdy Product Owner nie ma uprawnień do podejmowania decyzji czy jest zbyt daleko od swojego klienta.

Product Owner nie jest decyzyjny ( nie ma uprawnień)

Kiedy myślimy o roli Product Ownera, jedną z pierwszych rzeczy, która nam przychodzi do głowy, jest oczekiwanie, że będzie on w stanie podejmować decyzje dotyczące rozwoju produktu. Brak tej decyzyjności oznacza, że Product Owner nie otrzymał uprawnień ani umocowania od organizacji do podejmowania takich decyzji.

1. Ustalenie granic odpowiedzialności Product Ownera 

Jest to niestety bardzo popularna pułapka. Żeby temu zaradzić, zarówno z pozycji Product Ownera, jak i z perspektywy Scrum Mastera czy Agile Coacha, pierwszym krokiem jest uzgodnienie z zarządzającymi w organizacji wizji roli Product Ownera.

• Może to być rozmowa z Dyrektorem Produktu, członkiem zarządu odpowiedzialnym za rozwój produktów, czy inną osobą zarządzającą obszarem, w którym działa Product Owner. 
• Kluczowe jest ustalenie wspólnego zrozumienia roli Product Ownera. 

Problem z brakiem decyzyjności może wynikać z niezgodnych wyobrażeń co do tej roli. My, reprezentując podejście scrumowe, możemy myśleć o Product Ownerze jako osobie decyzyjnej, podczas gdy management może mieć inne wyobrażenie – widzieć go jako nowy rodzaj Project Managera, analityka, pośrednika. Ważne jest wyjaśnienie tych różnic i uzgodnienie, czym naprawdę jest rola Product Ownera w organizacji.

2. Zdefiniuj produkt i jego cel

Kolejną naszą rekomendacją jest dobre zdefiniowanie produktu. W jaki sposób? 

• Określ co jest produktem oraz co wchodzi w jego skład.
• Zdefiniuj ramy, czyli bazowe informacje i kontekst potrzebny do jasnego określenia produktu, oraz bardzo konkretnie ustal cel produktu.

Należy dać Product Ownerowi wycinek organizacji, za który odpowiada i w którym ma decyzyjność. To powinno wyjaśnić, jakie decyzje Product Owner może podejmować, a które należą do innych Product Ownerów lub są poza ich zakresem. Takie zdefiniowanie obszaru, na którym Product Owner ma decyzyjność, jest kluczowe, aby uzyskał pełne uprawnienia do podejmowania decyzji.

Często spotykamy się z niezrozumieniem roli Product Ownera jako osoby realizującej projekty, a nie opiekującej się produktem. Jest to postrzeganie roli jako realizowanie zleconych inicjatyw z portfela projektów, zamiast rozwoju i opieki nad pewnym obszarem produktowym. Jeśli management rozumie rolę Product Ownera jako kogoś, kto ma dowieźć projekt zgodnie z wytycznymi, mamy problem z decyzyjnością.

3. Popraw umocowanie z wyższym managementem

Mamy tu na myśli sytuację, gdzie Product Owner jest odpowiedzialny za produkt i jest akceptowany jako kluczowy element procesu scrumowego, ale jego ramy decyzyjności są ograniczone. Na przykład, może nie mieć swobody decydowania, musi uzyskać zgodę, drugi podpis, czy regularne korekty.

W organizacjach przechodzących transformację i budujących świadomość zwinnego rozwoju produktu, umocowanie Product Ownera może być takie, jakie było wcześniej – zawsze trzeba było uzyskać zgodę. Warto przedyskutować z wyższym managementem, czy te ograniczenia są naprawdę potrzebne i jakie są ich konsekwencje. Może warto przenieść decyzyjność na nowy poziom, rozliczając Product Ownera za osiągnięte rezultaty, a nie za realizację konkretnych funkcji zgodnie z wyobrażeniem dyrektora.

4. Zmień Product Ownera 

Jest to dość kontrowersyjna porada, jednak pozwól, że ją rozwiniemy. Może się zdarzyć, że mimo spełnienia wszystkich powyższych punktów, konkretna osoba w tej roli się nie odnajduje. Patrzymy na to w ten sposób – tak jak nie chcielibyśmy, aby firmą zarządzała osoba, która nie radzi sobie z tym stanowiskiem, tak samo ważne jest, aby Product Owner był odpowiedzialny i kompetentny w swoim obszarze.

Spotkaliśmy na swojej drodze osoby, które w roli Product Ownera nie błyszczały, mimo wsparcia, ram i zmian, jakie wprowadzono. Z drugiej strony, obserwowaliśmy, jak odżywa zespół, gdy współpracuje z osobą, która potrafi skutecznie zarządzać produktem. Zmiana Product Ownera nie musi oznaczać rozstania z firmą. Może się okazać, że ta rola nie jest odpowiednia dla danej osoby, ale może ona nadal funkcjonować w ramach organizacji, tylko w innej roli, która lepiej pasuje do jej umiejętności i predyspozycji.

Będąc w tym zakątku związanym ze zmienianiem Product Ownera, to pozostańmy ostrożni. Zmiana Product Ownera nie zawsze rozwiąże wszystkie problemy. Ważne jest, aby przeanalizować cały proces i strukturę, w jakiej działał Product Owner. Jakie dostawał wsparcie? Jakie miał umocowanie? Te wszystkie czynniki mają znaczenie. Nawet jeśli jesteśmy pewni decyzji o zmianie, powinniśmy przejrzeć cały proces i posłuchać osoby, która opuszcza tę rolę. Zrozumienie trudności, z jakimi się zmagała, może pomóc uniknąć tych samych problemów w przyszłości.

Wprowadzenie nowego Product Ownera powinno odbywać się na najlepszych możliwych zasadach, być może z nową kartą i trochę zmienionymi regułami współpracy. Ważne jest, aby nie wpaść z deszczu pod rynnę, kontynuując te same problemy.

Product Owner, nie potrafi decydować (ma uprawnienia, ale nie decyduje) 

Przejdźmy teraz do kolejnej pułapki związanej z rolą Product Ownera, czyli sytuacji, gdy Product Owner nie potrafi decydować. To nie jest przypadek, gdy ktoś mu nie pozwala decydować. Ta osoba ma decyzyjność i zespół do dyspozycji, ale z jakiegoś powodu decyzje się nie pojawiają, są opóźniane lub nie zapadają. Tutaj musimy poznać powody tego stanu rzeczy i mamy kilka pomysłów, jakie zagadnienia warto by było eksplorować.

1. Zbuduj solidną  wiedzę o produkcie

 Im lepiej rozumiemy produkt i całe otoczenie biznesowe, tym łatwiej jest podejmować decyzje. Trudno oczekiwać, że ktoś będzie podejmował decyzje, jeśli nie ma solidnych fundamentów, na których te decyzje można oprzeć. W takich sytuacjach można wpaść w pułapkę przeciągających się decyzji, ponieważ brak wiedzy powoduje strach przed ich podjęciem. Często ten strach wynika z braku merytorycznego podłoża dla decyzji.

2. Rozwijaj  wiedzę o produkcie. 

To proces, w który warto zainwestować, aby mieć pełen zestaw danych, informacji, faktów i badań na temat naszego produktu. To jest punkt startowy. Jeśli mimo posiadania takiej wiedzy nadal nie jesteśmy w stanie podejmować decyzji, warto zastanowić się, z czego konkretnie to wynika.

3. Stwórz wizję produktu 

Product Owner może nie znać technik związanych z zarządzaniem produktem, zwłaszcza technik priorytetyzacji. Może być tak, że Product Owner nie ma dostępu do odpowiednich narzędzi lub nie ma od kogo się uczyć. Tutaj z pomocą może przyjść Scrum Master, który może podpowiedzieć, pokazać, wytłumaczyć i dostarczyć potrzebne narzędzia. Nie będziemy wymieniać wszystkich możliwych narzędzi, ale jedno, które zawsze przychodzi do głowy, to wizja produktu. Można to osiągnąć poprzez zbudowanie Product Vision Board lub odpowiedzenie na podstawowe pytania, dlaczego w ogóle robimy dany produkt. To są proste techniki, które świetnie porządkują dyskusje o produkcie, wybieraniu priorytetów, skupianiu się na kluczowych aspektach i zrozumieniu, dla kogo ten produkt jest tworzony. Czasami w chaosie codzienności zapominamy o tych podstawach. Właśnie tutaj Scrum Master, lub ktoś z zespołu, może pomóc Product Ownerowi usystematyzować sposób myślenia, poukładać priorytety, zwizualizować pewne rzeczy i wesprzeć w podejmowaniu decyzji, selekcjonowaniu priorytetów oraz pokazywaniu alternatywnych scenariuszy. 

4. Zmniejsz konsekwencje podejmowania złych decyzji 

W tej poradzie chodzi o to, aby podzielić decyzje na mniejsze, bardziej zarządzalne części, co jest mocno powiązane z rozwojem produktu. Małe decyzje, które idealnie można cofnąć, są kluczowe. W szczególności polecamy podejmowanie drobnych eksperymentów, wprowadzanie małych kroków, iteracyjnych zmian oraz bazowanie na testach, hipotezach i badaniach. Takie podejście zwiększa pewność co do podejmowanych decyzji, ponieważ zbieramy dowody z rynku, że nasze decyzje mają sens.

Jeśli decyzje dotyczą małych obszarów produktu, a nie całego produktu czy dużych obszarów, łatwiej jest się z nich wycofać. Rekomendujemy iteracyjne i przyrostowe rozwijanie produktu, co pozwala na podobne podejście do podejmowania decyzji. Dzięki temu ryzyko złych decyzji jest mniejsze, a ich konsekwencje łatwiejsze do zarządzania.

5. Uzyskaj wsparcie 

W tym punkcie mam takie obrazowe porównanie: jeśli decyzja paraliżuje Product Ownera z powodu wielkich konsekwencji, nieodwracalnych skutków i braku możliwości cofnięcia się, to współczujemy Product Ownerom, którzy nie dostają odpowiedniego wsparcia. Wsparcie może przyjść w formie umocowania, odpowiednich narzędzi, środowiska czy systemowego rozwiązania, które zmniejsza wielkość i groźność decyzji.

Product Owner potrzebuje poczucia wsparcia, świadomości, że ktoś za nim stoi i wesprze go w jego działaniach. Zwłaszcza w przypadku rozwiązań innowacyjnych i rynkowych, gdzie błędy są nieodłącznym elementem procesu. Czasami zawodzi zespół, technologia, a konkurenci wpadną na coś lepszego.

Ważne jest, aby Product Owner otrzymywał sygnał od organizacji, zarządzających i partnerów biznesowych, że podejmowanie ryzyk i nauka na błędach jest częścią działania. Liderzy organizacji muszą wykazać się dojrzałością i panowaniem nad emocjami, zwłaszcza gdy coś nie wychodzi, coś się opóźnia, lub nie odnosimy sukcesów, na które liczyliśmy.

Pojedyncze negatywne przypadki mogą budować złą atmosferę i sytuację, w której Product Ownerzy boją się podejmować decyzje. Mogą obawiać się krytyki, przez co będą unikać podejmowania ryzykownych decyzji, przeciągać czas lub szukać kogoś, kto podejmie decyzję za nich. To niebezpieczne zjawisko, które spotykamy niestety w niektórych organizacjach.

Odległości Product Ownera od Klienta

Może być zaskakujące, że taka sytuacja ma miejsce, ponieważ Product Owner odpowiada za produkt, a częścią tej odpowiedzialności jest zrozumienie potrzeb Klienta. Często spotykamy się z sytuacją, w której Product Owner jest bardzo oddalony od Klienta.

Patrząc na Product Ownera w akcji, wszystko może wyglądać dobrze – jest wizja produktu, cel, Backlog Produktu, przyrosty, namacalny produkt. Jednak gdy przyjrzymy się bliżej, okazuje się, że odległość od końcowego Klienta jest ogromna. W skrajnych przypadkach Product Owner nigdy nie widział Klienta, nigdy się z nim nie spotkał. Klient jest gdzieś daleko, na orbicie, ale nigdy nie mają bezpośredniego kontaktu.

Co można tutaj zrobić? 

1. Zmiana dotychczasowego podejścia

Przede wszystkimi dostrzeżenie, że to, co dzieje się w środku firmy, może nie być najważniejszą wytyczną. Najważniejsza jest optyka, że zadowalamy Klienta, realizujemy to, co jest dla niego ważne, czujemy zmiany na rynku i potrzeby Klienta, a także obserwujemy konkurencję.

2. Wyjdź z pułapki korporacyjnej 

Oznacza to także wyjście z pułapki korporacyjnej, gdzie zakładamy, że wiemy, co się dzieje, rozwiązując potrzeby Klienta na podstawie narad, warsztatów i planów w biurze. Realne potrzeby Klienta są prawdopodobnie u Klienta, a nie w naszym biurze. Konkretnie mniej słuchania tego, co mówi przełożony, szef czy dyrektor, a więcej konfrontowania tych informacji z perspektywą rynku, odbiorcy i kupującego.

3. Przedstaw klientowi prototyp

Chcemy podzielić się również obserwacją, że często słyszymy obawy, gdy proponujemy zbliżenie się do użytkownika i rozmowę z nim. Pojawia się pytanie: Jak to miałoby wyglądać? Co to mogłoby być? Z naszej perspektywy bardzo dobrym sposobem na rozpoczęcie takiej rozmowy jest posiadanie czegoś namacalnego, co możemy pokazać użytkownikowi. To może być produkt w wersji prototypowej, niedoskonały jeszcze produkt, makiety lub koncepcje. Cokolwiek, co można pokazać użytkownikowi, aby mógł się do tego odnieść, skomentować, spróbować użyć i wyrazić swoją opinię.

Posiadanie czegoś namacalnego to bezpieczny sposób na rozpoczęcie dyskusji. Z jednej strony mamy gwarantowany temat rozmowy, a z drugiej strony, jakość feedbacku, jaką dostaniemy od użytkownika, jest znacznie wyższa, gdy może on poużywać produktu, niż gdybyśmy tylko rozmawiali o abstrakcyjnych koncepcjach. Dlatego im bardziej namacalne są te elementy, nad którymi pracujemy, tym lepsze będą efekty rozmowy z użytkownikami.

W tym punkcie bądź również czujny na to, aby pytać użytkownika o jego ogólną opinię lub zadawać otwarte pytania, a nie tylko dawać mu produkt i prosić o ocenę tego, co mu zaproponowaliśmy. Otrzymamy jakąś odpowiedź, ale możemy nie zauważyć lub nie usłyszeć ważnych informacji. Może użytkownik ma zupełnie inne pomysły, które nie pojawią się w zamkniętym formularzu ankietowym. Może zaznaczyć, że bardzo mu się podoba, ale w rzeczywistości nigdy tego nie użyje z powodu XYZ. Dlatego otwarte pytania i szeroka dyskusja są kluczowe, aby uzyskać pełny obraz i wartościowy feedback.

4. Zobacz w jaki sposób użytkownik korzysta z twojego produktu.

Ostatnia rada w temacie odległości od klienta, powiązana z naszym ostatnim zastrzeżeniem, to zwrócenie jak użytkownik korzysta z twojego produktu. 

• Pójdź do klienta, użytkownika, odbiorcy końcowego, wejdź w jego realne środowisko, w jego realny kontekst i rozmawiaj z nim jego językiem. 
• Obserwuj, jak funkcjonuje, jak wykonuje swoje codzienne czynności z twoją poprzednią wersją produktu, z twoim produktem, który próbuje użyć, lub z produktami konkurencji. 

Zwłaszcza w przypadku produktów bardziej złożonych niż strona WWW czy aplikacja, możesz uzyskać niesamowite rezultaty. Nagle okaże się, że użyteczność, łatwość wykorzystania, dodatkowe instrukcje czy materiały mają braki i trzeba coś jeszcze dopracować. Przegląd produktu, czy taki finalny odbiór produktu, koniecznie musi się dziać w kontekście odbiorcy docelowego i trzeba być bardzo czujnym na feedback. To wiąże się bardzo mocno z tematem projektowania interakcji z użytkownikiem czy z klientem. Z perspektywy Product Ownera, w kontekście pułapek, należy być na to strasznie wyczulonym i wręcz zachęcać zespół do kolejnych eksploracji, a nie zamykać się na to, że wie się wszystko, bo jest się wizjonerem, albo mój szef jest wizjonerem i powiedział mi, co mam myśleć.

Product Owner nie ma czasu 

Przedostatnia pułapka, którą chcemy poruszyć, to sytuacja, w której Product Owner nie ma czasu. Nie ma czasu dla zespołu, na produkt, dla użytkowników, na Backlog. Większość z naszych odbiorców widziała taką osobę w swojej organizacji – tzw. wieczny niedoczas. Wszystkie te historie typu „spójrz na mój kalendarz” wskazują na ogromną zajętość.

Czasem tak po prostu jest, że tej pracy jest dużo. Z naszych obserwacji, wynika to z predyspozycji do brania na siebie więcej, niż jesteśmy w stanie zrobić. Jednak mamy kilka porad na przypadki, gdy Product Owner naprawdę nie ma wystarczająco czasu, jakiego byśmy oczekiwali. Oto kilka sugestii, które mogą pomóc w takiej sytuacji.

1. Przedstaw konsekwencje braku inwestycji czasowej 

Warto przeanalizować te obowiązki i pokazać konsekwencje braku inwestycji czasowej w pełnienie odpowiedzialności Product Ownera. Konsekwencje te mogą być ewidentne, ponieważ niedoinwestowanie czasowe w proces Refinementu czy Backlog Produktu rzutuje na słabe cele sprintu, wykonanie, zaangażowanie i konieczność kilkukrotnego powtarzania wykonania danego elementu produktu. To może prowadzić do namacalnych strat i spowolnienia prac. Jeśli jest to wynik racjonalnych decyzji, oczekiwałbym od zespołu scrumowego wspólnej refleksji na temat odpowiedniej proporcji czasowej przeznaczonej na różne zadania oraz pokazania ciągu przyczynowo-skutkowego. Być może dzisiejsze niedomagania w poszczególnych obszarach, takich jak wykonanie prac przez developerów, udane lub nieudane Sprinty, a nawet zaangażowanie, wynikają z niewystarczającego zaangażowania czasowego Product Ownera.

To na co warto zwrócić uwagę to, nie zarządzamy czasem, tylko sobą w czasie. To pokazuje, że mamy wpływ na to, co robimy. Często mówimy, że nie mamy czasu na coś, ponieważ decydujemy się robić inne rzeczy. Czas jest ograniczony i każdy z nas ma go tyle samo. 

2. Uprość procesy, które zabierają czas Product Ownera

Kolejna porada, szczególnie istotna w większych organizacjach, to uproszczenie procesów, które zabierają czas Product Ownerowi. Może to obejmować różne aktywności i obowiązki, narzucone na Product Ownera z racji jego roli: dodatkowe spotkania statusowe, spotkania synchronizacyjne, uzupełnianie tabelek, dokumentów czy inne czynności, które trzeba wykonywać. Oczekiwanie, że Product Owner będzie uczestniczył we wszystkich tych czynnościach, może prowadzić do tego, że faktycznego czasu na pełnienie roli Właściciela Produktu pozostaje bardzo niewiele.

Podobna rzecz, tylko przesunięta do zespołu, to odciążenie Product Ownera z obowiązków, które mogą być realizowane przez pozostałych członków zespołu scrumowego. Często oczekuje się od Product Ownera, że będzie fizycznie pisał Product Backlog, osobiście uczestniczył we wszystkich warsztatach z Interesariuszami czy Użytkownikami, a nawet brał udział w testach lub czynnościach około wdrożeniowych. Te obowiązki mogą bardzo mocno konsumować czas, a nawet jeśli nie zajmują dużo czasu, są żmudne i męczące, co powoduje, że Product Owner ma mniej energii na wizję produktu, podejmowanie decyzji czy układanie większych spraw.

Pamiętajmy, że rola Product Ownera polega na odpowiedzialności, ale realizacja tej odpowiedzialności może być przekazana członkom zespołu scrumowego. Zwłaszcza gdy Product Owner jest zajęty czasowo, ma więcej niż jeden zespół, czy wielkie rzeczy do zrobienia. W takich przypadkach lepszym rozwiązaniem może być, aby zespół, zwłaszcza jeśli posiada kompetencje analityczne, architektoniczne, UX-owe, podjął część zadań. Mogą one pomóc Product Ownerowi, aby ten mógł skupić się na decydowaniu i kierowaniu wizją produktu. Zespół scrumowy, wszyscy Developerzy, powinni wychodzić poza swoje ścisłe specjalizacje i angażować się w rozwój produktu. Warto, aby zespół przejął część obowiązków, które można realizować grupowo lub indywidualnie przez poszczególnych Developerów.

 Product Owner nie zna Scruma

Ostatnia pułapka odnosi się do Product Ownera, który nie zna Scruma. Oczekujemy, że Product Owner będzie funkcjonował przy wykorzystaniu frameworka scrumowego, natomiast okazuje się, że nie ma doświadczenia ani w korzystaniu ze Scruma, ani w rozwijaniu produktów w sposób iteracyjno-przyrostowy. Każdy z tych przypadków może prowadzić do nieefektywnego rozwoju produktu lub do myślenia projektowego zamiast produktowego. Żadne z tych podejść nie są optymalne. Oczekuje się, że Product Owner będzie myślał w sposób przedsiębiorczy o produkcie jako całości, a nie tylko o dostarczaniu kawałków tego produktu do użytkowników. Znajomość Scruma, backgroundu oraz wiedzy o tym, jak wykorzystać zwinność do wytwarzania produktów, jest kluczowa.

Pokazujemy tutaj konsekwencje dosyć prostej pułapki, która wydaje się łatwa do rozwiązania.

1. Zainwestuj w czas na poznanie technik przez Product Ownera

 Najprostsze rozwiązanie to zainwestować czas w poznanie technik zwinnych, takich jak Scrum.Nie oczekujemy od Product Ownera dorównania poziomem pasji i fascynacji metodami zwinnymi, jakich bym się spodziewał od Scrum Mastera, Agile Coacha czy lidera transformacji. Minimalny poziom znajomości, jak przeczytanie Scrum Guide’a czy udział w szkoleniu z podstaw Scruma, jest konieczny. Taka inwestycja jednego do trzech dni na zrozumienie podstaw pozwoli na minimalnym poziomie wykorzystać tę metodę.

Jeśli jesteś liderem, Agile Coachem czy Scrum Masterem, który pomaga wdrożyć zwinność: 

• zadbaj o zrozumienie Scruma przez Product Ownerów, 
• bądź czujny nawet na takie sytuacje, gdy ktoś mówi: „Jestem Product Ownerem z doświadczeniem z poprzedniej firmy”. Może się okazać, że to zupełnie nie ma znaczenia, ponieważ rola ta może być różnie definiowana w różnych firmach, 
• przeprowadzając transformację czy reorganizację, wkładając odpowiedzialność Product Ownera w nowe ręce, warto wysłać tę osobę na szkolenie. Być może zaprosić ją do jakiegoś kursu rozwojowego i zadbać o podstawową wiedzę o Scrumie i zwinności.

2. Wsparcie Scrum Mastera

Nasza kolejna porada to uzyskanie dobrego wsparcia od Scrum Mastera. Twórcy Scruma nieprzypadkowo wprowadzili tę rolę. Oczekuję, że Product Owner ma dostęp do Scrum Mastera. Taki Scrum Master zna framework Scrum i potrafi doradzić, jak wykorzystać zwinne techniki do rozwoju produktu. Nawet jeśli Scrum Master nie pracuje na pełen etat, jakiekolwiek wsparcie z jego strony może zrobić znaczącą różnicę.

3. Zainwestuj czas w dalszy konsekwentny rozwój Product Ownera 

W większych organizacjach można to zrealizować poprzez wewnętrzne społeczności, wymianę wiedzy, mentoring czy shadowing. Współpraca Product Ownerów między sobą, nie tylko na poziomie produktu, ale także rozmowy o warsztacie, mogą przynieść cenne wskazówki. Jak radzić sobie z Interesariuszami? Jak zarządzać danymi? Takie kontekstowo dopasowane porady mogą być bardzo pomocne.

Jeśli w organizacji nie ma takich osób, warto zwrócić uwagę na zwinne społeczności zewnętrzne. W realiach pandemicznych większość z nich działa zdalnie, a wiele webinarów jest nagrywanych. Jest mnóstwo dostępnej wiedzy, którą można odnaleźć i zainwestować trochę czasu poza typowymi godzinami pracy. Nawet jeśli nie ma czasu na webinary czy długie spotkania, krótkie, inspirujące artykuły mogą dostarczyć wartościowych przemyśleń.

Dodaliśmy też kilka linków do materiałów produktowych, które mocno polecamy z własnej praktyki. Koniecznie sprawdź nasze rekomendowane źródła inspiracji związanych ze zwinnym zarządzaniem produktem.

Dodatkowe materiały

• Współpraca Scrum Mastera z Product Ownerem
• Blog Silicon Valley Product Group, na którym znaleźć można dużo artykułów na temat Product Discovery
• Blog Romana Pichlera, gdzie zamieszczone są m.in. poręczne szablony narzędzi Product Ownera – np. Product Vision Board
• Twitter Johna Cutlera, aktywnego produktowca i jednocześnie bardzo inspirującego twórcę merytorycznych treści o zarządzaniu produktami. Cenimy zwłaszcza jego krótkie wpisy prowokujące do myślenia
• Jak być dobrym Product Owenrem? – Ebook naszego współautorstwa, szczególnie polecamy wywiady z praktykującymi PO na temat wyzwań ich pracy

Transkrypcja podcastu „Pułapki odpowiedzialności Product Ownera”

Jacek: W dzisiejszym odcinku porozmawiamy o pułapkach roli Product Ownera. Jest to kontynuacja odcinka poprzedniego, w którym mówiliśmy o tym, skąd brać Product Ownerów. Natomiast dzisiaj skupimy się na najpopularniejszych pułapkach roli Product Ownera. No i oczywiście zaproponujemy konkretne i praktyczne rozwiązania, które możecie w kontekście tych pułapek spróbować.

Kuba: Na początek, żeby dać Ci wyobrażenie, o jakich tematach szczegółowo będziemy mówić, wymienię te pułapki. Zdecydowaliśmy się na to, żeby opowiedzieć o przypadkach, gdy Product Owner nie jest decyzyjny, czyli nie ma uprawnień do decydowania. Nie umie decydować. Nie wie, jak to robić. Jest w odległości od Klienta lub kompletnym braku kontaktu z tym Klientem. Nie ma czasu na współpracę z zespołem i nie zna Scruma. W kolejnych częściach tego podcastu opowiemy o tych konkretnych pułapkach i zaproponujemy rozwiązanie. No to zaczniemy od pierwszej. Jacek, co rozumiemy pod hasłem Product Owner nie jest decyzyjny i dlaczego jest to pułapka?

Jacek: Tak. Kiedy myślę o roli Product Ownera, no to jedna z pierwszych rzeczy, która mi przychodzi do głowy, to jest takie oczekiwanie, że Product Owner będzie w stanie decydować, jeśli chodzi o rozwój produktu. Kiedy mówimy o braku tej decyzyjności, mamy tutaj na myśli coś takiego, że ten Product Owner nie dostał uprawnień, czy nie dostał mandatu od organizacji, żeby takie decyzje podejmować. To jest taki wariant, że, nawet gdyby chciał, no to tak naprawdę na koniec dnia nie jest w stanie tego zrobić.

Kuba: No jest dosyć nieprzyjemna pułapka. Niestety dosyć popularna. Ale gdybyśmy mieli temu tematowi zaradzić, zarówno, gdy jesteśmy z pozycji Product Ownera, którego dotyka ta sytuacja, albo, gdy jesteśmy z perspektywy Scrum Mastera albo Agile Coacha, który próbuje zmienić proces w zespole, czy po prostu jesteśmy zainteresowani tym, żeby tę sytuację naprawić. Pierwsza rzecz, która nam przychodzi do głowy, jako taka super najważniejsza. Jeśli spotykamy taką sytuację, gdzie Product Owner jest niedecyzyjny, no to zaczęlibyśmy od uzgodnienia z zarządzającymi w organizacji. Być może zarządzającymi tym Product Ownerem, jakieś osoby typu Dyrektor Produktu, może jakiś członek zarządu odpowiedzialny za rozwój produktów, czy po prostu osoba zarządzająca obszarem, w ramach którego funkcjonuje Product Owner w firmie. Zgodzić się z tą osobą, jaka jest wizja roli Product Ownera. Jaka jest granica tej odpowiedzialności tegoż właśnie Product Ownera? Czyli tutaj jest taki trochę dorozumiane, czy taki trop myślowy, że ten Product Owner, o którym myślimy, nie jest decyzyjny, ponieważ mamy niezgodne wyobrażenia, co do tej odpowiedzialności Product Ownerskiej po stronie naszej, gdzie my, powiedzmy reprezentujemy być może jakąś taką rolę czysto scrumową, a może ta osoba po stronie managementu ma wyobrażenie, że Product Owner to jest taki nowy rodzaj Project Managera, albo nowy rodzaj analityka. Może taka osoba na posyłki. Pośrednik. Jest cała masa możliwych tutaj, powiedzmy nazewnictw na to, że to nie jest Product Owner w naszym rozumieniu i jest oczekiwane przez management.

Jacek: Kolejna porada, to porada, w której rekomendujemy, żeby zdefiniować sobie dobrze produkt. Określić, co jest produktem, co wchodzi w skład produktu, co nie wchodzi w skład produktu. Jakie są ramy, czyli takie no powiedzmy bazowe informacje, czy kontekst, który jest nam potrzebny, żeby taki produkt sobie jasno zdefiniować, plus do tego określić sobie też bardzo konkretnie, jaki jest cel produktu. Czyli w tym kontekście chcielibyśmy dać Product Ownerowi, jakby tak z ramienia organizacji pewien taki wycinek organizacyjny, za który odpowiada. Jakby, w którego obszarze ma decyzyjność, tak żeby było jasne, jakie decyzje Product Owner może podejmować, a jakie decyzje, bądź leżą już w odpowiedzialności innych Product Ownerów, albo być może w ogóle są poza decyzją Product Ownerów. Tak więc takie zdefiniowanie – bym powiedział obszaru, na którym Product Owner tę decyzyjność, o której mówimy właśnie, że na ten moment jeszcze jej nie ma, żeby mógł uzyskać.

Kuba: I nieprzypadkowo Jacek mówi o obszarze produktu, definicji produktu, celu produktu, ponieważ coś, no co spotykamy regularnie, to zrozumienie roli Product Ownera, jako osoby, która realizuje projekt, zlecone inicjatywy. Ma dookreślone cele do osiągnięcia, właśnie takie bym powiedział, bardziej z portfela projektów, niż z rozwoju, czy opieki nad pewnym obszarem produktowym. I tu ponownie, jak w przypadku tej pierwszej porady z uzgodnieniem oczekiwań, no, to jeśli ktoś, kto ma na to wpływ, prawdopodobnie jakiś management w firmie, rozumie rolę Product Ownera, jako kogoś, kto opiekuje się projektami, albo ma za zadanie zrealizować te projekty zgodnie z jakimiś tam wytycznymi, na przykład żelaznym trójkątem projektowym, no to tutaj też możemy mieć kłopot i się nigdy nie spotkać i ta decyzyjność Product Ownera jest właśnie taka, jaka zdaniem tego zarządzającego powinna być. Czyli ma dowieść projekt. Nie zajmujemy się dowożeniem projektów z wykorzystaniem frameworka Scrum. Następną poradą, którą też byśmy w takiej sytuacji, gdy mamy do czynienia z niedecyzyjnym Product Ownerem, to zrewidować umocowanie decyzyjne z zarządzającymi. Rozumiem, tu mam na myśli taki przypadek, że nie następują te poprzednie problemy. Czyli Product Owner jest osobą odpowiedzialną za jakiś produkt. Jest w ogóle akceptowany, jako ważny fundament funkcjonowania procesu scrumowego, tylko po prostu ramy decyzyjności tej osoby są bardzo ograniczone. Czyli na przykład nie ma swobody decydowania, albo musi uzyskać zgodę, jakiś drugi podpis. Są jakieś korekty regularnie realizowane. No i tutaj często jest tak, że w organizacjach zwłaszcza takich, które dopiero przechodzą pewną transformację, dopiero budują tę świadomość zwinnego rozwoju produktu, to to umocowanie product ownerskie jest takie, jakie było zawsze. No zawsze trzeba było dostać zgodę, jakiś akcept, jakąś korektę. No i tutaj warto wyjść naprzeciw takiej ewolucyjnej ścieżce i przedyskutować z wyższym managementem, czy na pewno są potrzebne te osłabienia decyzyjności, jakie są konsekwencje tej słabej decyzyjności? Czy czasami nie da się tego przenieść na nowy poziom. Jak mówię nowy poziom, to mam na myśli przede wszystkim takie jasne powiedzenie sobie – rozliczajmy Product Ownera za rezultaty, za osiągnięte efekty, a niekoniecznie za to, czy realizuje ten, czy tamten ficzer zgodnie z wyobrażeniem, jakiegoś na przykład dyrektora powyżej tego Product Ownera.

Jacek: I ostatnia porada, którą mamy dla Ciebie, to jest porada, która brzmi kontrowersyjnie, natomiast rozwinę ją. To jest porada pod tytułem – zmienić Product Ownera. No i oczywiście, co tutaj mamy na myśli? Może być taka sytuacja, no, że po prostu, mimo spełnienia tych powyższych wszystkich punktów, jakaś konkretna osoba może w tej roli się nie odnajdywać. Ja na to patrzę w ten sposób, tak jak nie chcielibyśmy, żeby firmą, spółką, organizacją, zarządzała osoba, która nie radzi sobie z tym stanowiskiem. Tak samo dosyć tak agresywnie podchodzę do roli Product Ownera, że tam jest odpowiedzialność, nie za całą firmę, ale za pewien jej wycinek. No i po prostu spotkałem na swojej drodze osoby, które no akurat konkretnie w tej roli nie błyszczały. Powiedzmy sobie, jakieś działania, wsparcie, jakieś ramy, jakieś zmiany, po prostu nie przynosiły efektów. Natomiast fajnie było zobaczyć, jak odżywa zespół, kiedy dostaje do współpracy osobę, która faktycznie jest w stanie takim produktem zarządzać. Też, żeby tak trochę zmiękczyć tą taką dosyć wyraźną rekomendację, to nie musi oznaczać rozstania się. Takiego na zasadzie, że Product Owner opuszcza firmę. Być może po prostu ta rola nie jest odpowiednia, no i ta osoba może dalej sobie funkcjonować w ramach organizacji, tylko po prostu nie konkretnie w roli Product Ownera.

Kuba: No i jak jesteśmy w tym zakątku związanym ze zmienianiem Product Ownera, to bądźmy bardzo, bardzo ostrożni na takie podejście szukania kozła ofiarnego, że tutaj Product Owner się nie sprawdził, więc zmieniamy i będzie już wszystko tip-top. No to często będzie suma wielu czynników. Jakie dostawał wsparcie? Jakie dostał umocowanie? Czyli te wszystkie rzeczy, które już wymieniliśmy, ale też wszystkie rzeczy, które dopiero przed nami w tym odcinku. Więc nawet jesteśmy pewni tej decyzji o zmianie Product Ownera, to i tak przejrzyjmy cały ten proces, przejrzyjmy struktury, jak to jest być Product Ownerem. Być może posłuchajmy też tej osoby. Z czym miała trudności? Co sprawiało, że ta rola nie była wypełniana tak, jakby wszyscy tego chcieli. No i zwłaszcza nowy Product Owner, ważne, żebyśmy wprowadzili go najlepiej, jak tylko potrafimy. Być może z nową kartą, ale również na trochę nowych zasadach. Czasami już stylu współpracy z pewną osobą się nie poprawi, ale z rozpędu czasem nie wpadnijmy z deszczu pod rynnę. Dobra, to pójdźmy dalej. Kolejny przypadek, który może nas spotkać, kolejna pułapka pełnienia tej product ownerskiej odpowiedzialności, to jest Product Owner, który nie umie decydować. I tutaj wyraźnie odgraniczmy. To nie jest ten przypadek z poprzedniej puli, ktoś mu nie pozwala decydować. Ta osoba jest wręcz oczekiwanie, że ma decyzyjność, że ma do dyspozycji zespół. Tylko z jakiegoś powodu te decyzje się nie pojawiają, nie zapadają. Przedłużają się. Z tych nieznanych powodów prawdopodobnie trzeba coś zmienić i między innymi poznać te powody. Mamy tutaj kilka pomysłów, w którą stronę byśmy poszukali, jakie zagadnienia byśmy eksplorowali.

Jacek: Zdecydowanie pomocne w podejmowaniu decyzji, jest zbudowanie sobie wiedzy o produkcie. Czyli, im lepiej rozumiemy produkt i całe otoczenie biznesowe, w którym się poruszamy, tym łatwiej jest nam podejmować decyzje. Trudno oczekiwać, że ktoś będzie podejmował decyzje, jeżeli nie ma tak naprawdę żadnych fundamentów, żeby te decyzje podejmować. Wtedy możemy wpaść w taką pułapkę przeciągających się decyzji, których nie jesteśmy w stanie podjąć. Bardzo często ten strach przed podjęciem decyzji wynika z tego, że tak naprawdę nie czujemy tego, żeby ta decyzja miała jakieś sensowne podłoże merytoryczne. Stąd, celowo tutaj mówię o budowaniu wiedzy o produkcie. Jest to pewien proces ciągły, w który zdecydowanie warto zainwestować. No i po prostu mieć komplet, szereg najróżniejszych danych, informacji, faktów, badań, na temat naszego produktu, bo wtedy tak naprawdę, to jest generalnie punk startowy. Jeżeli to mamy i nadal nie jesteśmy w stanie podjąć konkretnych decyzji, no to możemy się zastanowić, z czego konkretnie to wynika.

Kuba: Jacka porada była na temat tego, co jest treścią decyzji. Natomiast kolejną poradę, którą bym dorzucił do możliwego rozwiązania problemu niedecyzyjności, no to może – Product Owner nie zna technik związanych z zarządzaniem produktem, czy konkretnie punktowo tutaj patrząc, techniki priorytetyzacji. No i tutaj jest całe pokłosie, być może nieuwagi na temat takiego powiedziałbym „narzędziownika” roli product ownerskiego. Być może nie ma od kogo się uczyć taki Product Owner. Być może w firmie nie przykłada się tak bardzo wagi do tego, jak wygląda proces pracy. Jak wyglądają narzędzia? Tu z pomocą może przyjść Scrum Master, który może podpowiedzieć, pokazać, wytłumaczyć, opowiedzieć, przynieść te wszystkie narzędzia, które mogą być bardzo potrzebne. W zależności od tego, co dokładnie jest kontekstem produktu, ja nie będę tutaj bardzo szczegółowo, tych możliwych przykładowych narzędzi wymieniał, ale pierwsza, która mi przychodzi do głowy, zawsze jest wizja produktu. Czy to poprzez zbudowanie Product Vision Board, czy poprzez odpowiedzi na pytanie jakieś takie podstawowe, dlaczego w ogóle robimy ten produkt? To są bardzo proste rzeczy, bardzo proste techniki, które świetnie układają całą resztę dyskusji o produkcie. O wybieraniu, co jest ważne. Na czym się skupiamy? Dla kogo to robimy? To w gruncie rzeczy nie są żadne kosmosy. Czasami, być może w jakimś takim chaosie codzienności zapominamy o tych rzeczach. Tu świetnie może się przydać właśnie Scrum Master, czy ktoś z zespołu, kto Product Ownerowi usystematyzuje pewien sposób myślenia. Może poukłada pewne priorytety, czy zwizualizuje pewne rzeczy i po prostu wesprze Product Ownera w podejmowaniu pewnych decyzji, selekcjonowaniu pewnych rzeczy, czy pokazaniu scenariuszy alternatywnych – co powinniśmy robić w pierwszej kolejności, co może czekać, co nie powinno być robione w ogóle.

Jacek: Kolejną poradą jest zmniejszenie konsekwencji podejmowania złych decyzji. I tutaj mamy na myśli, żeby podzielić sobie trochę te wszystkie decyzje, które mamy. Oczywiście to jest mocno powiązane z tym, jak rozwijamy nasz produkt. Taki szereg małych decyzji, idealnie, jeśli te decyzje jesteśmy w stanie cofnąć. Tak więc tutaj w szczególności takie rzeczy, jak drobne eksperymenty, małe kroki, iteracyjne zmiany. Czy też bazowanie na testach? Bazowanie na hipotezach, na badaniach. To są wszystko takie rzeczy, które z jednej strony pomagają nam zwiększyć pewność co do podejmowania decyzji. Czyli zbieramy dowód z rynku, że nasze decyzje mają sens. Z drugiej strony, jeżeli to są faktycznie małe decyzje, a nie zmiany, które dotyczą całego produktu, czy jakichś takich dużych obszarów produktowych. No to o wiele prościej jest nam się z takich zmian wycofać. Tak więc tak jak rekomendujemy, co do zasady – iteracyjne i przyrostowe rozwijanie produktu, tak samo można powiedzieć, że takie prowadzenie produktu implikuje to, że jesteśmy w stanie w podobny sposób podchodzić do podejmowania decyzji.

Kuba: W tym punkcie mam takie obrazowe porównanie, że, zwłaszcza jeśli ta decyzja paraliżuje, bo jest jakieś takie poczucie wielkich konsekwencji, nieodwracalnych skutków. Brak możliwości cofnięcia się. To czasem współczuję Product Ownerom, którzy nie dostają odpowiedniego wsparcia w takich momentach. Czasem to wsparcie jest w postaci umocowania. Czasem to wsparcie może być właśnie w całym narzędziu, środowisku, czy w systemowym rozwiązaniu, które powoduje, że ta wielkość tych decyzji nie jest aż tak kolosalna, czy tak groźna. Co nawiązuje do ostatniej porady z tej puli, czyli bezpieczeństwie psychologicznym. Product Owner potrzebuje dostać takie bezpieczeństwo. Posiadać poczucie wsparcia. Posiadać poczucie, że ktoś za nim stoi i go wesprze w tym, jak działa w swojej roli. Gdzie nieodłączne jest, zwłaszcza jeśli mówimy tutaj o rozwiązaniach innowacyjnych, o rozwiązaniach takich rynkowych. Nieodłączne jest to, że będziemy się od czasu do czasu mylić, że jednocześnie może zawieść może nas i zespół i technologia i być może nasi konkurenci wpadną jeszcze na coś jeszcze lepszego, niż nam przyszło do głowy. No to wszystko może powodować, że to nie będzie tylko pasmo sukcesów, że to nie będą tylko kolejna wspaniałe decyzje. No i tutaj fajnie, jeśli Product Owner dostaje sygnał od organizacji, od swoich zarządzających, od może partnerów biznesowych, że nieodłączną częścią naszego działania jest również podejmowanie pewnych ryzyk i posiadanie w związku z tym lekcji, takiej bym powiedział negatywnych. Chociaż, nie rozpatrujmy tego pozytyw-negatyw. No czasem się uczymy, czasem nam coś wychodzi, czasem nam nie wychodzi. No i tu jest wielka rola liderów organizacji. Wielka rola też dojrzałości, panowania nad emocjami w tych momentach, gdy na przykład coś nie wychodzi. Coś się opóźnia, gdy właśnie nie odnosimy tych sukcesów, na które liczyliśmy, gdy jakaś inicjatywa była uruchamiana lub dalej kontynuowana. No bo pojedyncze, dosłownie pojedyncze negatywne przypadki mogą budować taką pewną famę i taką pewną brzydką sytuację, która będzie w przyszłości już traktowana, jako taki punkt odniesienia. Nie podejmę tej decyzji, ponieważ poprzednio kolega, koleżanka dostali opieprz, to ja też nie chcę dostać opieprzu. To może przeczekam, może przeciągnę, może znajdę kogoś, kto za mnie podejmie tę decyzję? Bardzo i niebezpieczne i sączące się zjawisko, które spotykam niestety w niektórych organizacjach.

Jacek: Albo te decyzje będą takie bardzo, bardzo zachowawcze, co może kompletnie udusić wszelkiego rodzaju innowacje i eksperymenty. Trzecia pułapka, którą chcemy się z Tobą podzielić dotyczy odległości Product Ownera od Klienta. No, można by było być nieco zaskoczonym, że taka sytuacja może mieć miejsce. No bo jak? Skoro Product Owner odpowiada za produkt, no to oczywiście częścią odpowiadania, czy może kreowania, jest odpowiadanie na potrzeby Klienta. Natomiast zarówno ja i też nieśmiało mogę powiedzieć za Kubę, Kuba również. Bardzo często spotykamy się z taką sytuacją, w której patrzymy na Product Ownera w akcji. No niby wszystko jest. Jest jakaś wizja produktu, jakiś cel produktu, Backlog Produktu. Są przyrosty. Jest namacalny produkt. Można powiedzieć, że wszystko wygląda OK. Kiedy zaczynamy się przyglądać, no to okazuje się, że tak naprawdę ta odległość od końcowego Klienta z perspektywy Product Ownera jest potężna. Jakby w skrajnym przypadku może oznaczać i to też takie przykłady widziałem na własne oczy, że Product Owner de facto nie widział Klienta. Nigdy z nim się nie spotkał. No i po prostu ten Klient jest tam gdzieś na orbicie, ale tak odległej, że właściwie nie spotykają się.

Kuba: No i przepraszam, jeśli to, co powiem, jest powtarzaniem się. Tu zdecydowanie podpisuję się pod tym, co Jacek definiuje. Dla mnie to jest taki przykład prawie że idealnego Scruma, jeśli chodzi o mechanikę, a jednocześnie wielkiego, wielkiego oddalenia od rynku, od potrzeb, od rozwiązywania tego, co jest naprawdę ważne dla Klienta. Bo w to miejsce wchodzi takie podporządkowanie się organizacji, zadowoleniu Interesariuszy i szereg tego typu haseł, które same w sobie są poprawne z perspektywy takiej korporacyjnej, czy perspektywy bezpieczeństwa kariery, wydają się być dobrymi decyzjami. No, ale w praktyce oznaczają, że ten zwinny mindset nie funkcjonuje. Czy to taki zwinny framework de facto nie jest zwinny, no bo zadowolenie Klienta jest gdzieś daleko, daleko na liście priorytetów. Ważniejsze są te perspektywy wewnętrzne. I co można tutaj zrobić? Taka rada, która brzmi bardzo hasłowo i będzie wymagała z mojej strony dalszej definicji, to jest wyjdź z biura. Wyjdź z biura, oznacza nie tyle stricte fizyczne wyjście przed budynek firmy, ale takie podejście, że rzeczy, które dzieją się w firmie w środku, mogą nie być najważniejszą wytyczną. To, co jest optyką najważniejszą, powinno być to, że zadowalamy Klienta, że realizujemy to, co jest dla niego ważne. Czujemy też, jak nam się zmienia rynek, potrzebę Klienta. Widzimy też oczywiście naszą konkurencję. To wyjdź z biura, oznacza też między innymi wyjście z takiej pułapki, bardzo popularnej w korporacjach, że my doskonale wiemy, co się dzieje, że tutaj panowie i panie mądre siedząc w gabinetach, siedząc na jakichś naradach, siedząc w jakichś pokojach, spędzają całe dni warsztatowe na różnych planach, rysunkach i mapach po prostu rozwiązują realne potrzeby Klienta. Realne potrzeby Klienta są prawdopodobnie u Klienta. Być może w biurze u Klienta, raczej rzadko u nas. Ale też konkretnie, bo trochę poironizowałem, konkretnie również mam na myśli to, że to wyjdź z biura oznacza, może mniej słuchaj tego, co Ci jakiś przełożony, szef, dyrektor, prezes mówi, co jest ważne. Tylko naprawdę za każdym razem kontroluj, czy wręcz konfrontuj to wszystko z perspektywą rynku odbiorcy, kupującego, czy jakkolwiek jest to w naszym biznesie poukładane, czy nazwane.

Jacek: I kontynuując to, co Kuba powiedział, to chciałem się podzielić taką obserwacją, że często słyszę obawę, kiedy przedstawiam w ogóle taką koncepcję generalnie – a może warto by było się zbliżyć do Użytkownika? Porozmawiać z nim, zapytać. To widzę taką pewną obawę na zasadzie. Jakby to miało wyglądać? Co by to mogło być? I to, co z mojej perspektywy jest takim bardzo dobrym uruchamiaczem rozmowy, to jest posiadanie czegoś namacalnego, co możemy pokazać Użytkownikowi. To może być albo produkt w takiej niedoskonałej jeszcze wersji, albo może być jakiś prototyp. To nawet mogą być jakieś makiety. To mogą nawet być jakieś koncepcje. W każdym razie coś, co możemy pokazać Użytkownikowi, żeby mógł się do tego odnieść, skomentować, spróbować użyć, powiedzieć, co myśli. Tak więc, z mojej perspektywy posiadanie czegoś takiego, co jest namacalne, do czego można się odnieść, jest takim bardzo bezpiecznym sposobem, żeby wejść w dyskusję. Z jednej strony mam już gwarantowany temat dyskusji, no a z drugiej strony, jakość feedbacku, jaką dostaniemy od Użytkownika, jeżeli on faktycznie będzie mógł poużywać produktu, kontra porozmawianie sobie, co by chciał i co by powiedział na to, że w produkcie będzie XYZ, to są dwie zupełnie różne rozmowy. Tak więc z mojej perspektywy, im bardziej to jest namacalne, im bardziej pracujemy nad czymś, co imituje, bądź jest bliskie naszym produktom, tym de facto efekty tej rozmowy będą lepsze. 

Kuba: Tylko w tym punkcie bądźmy też czujni na to, żeby zapytać również Użytkownika, co w ogóle sądzi, albo jakieś takie inne otwarte pytanie, a nie tylko dać mu produkt i kazać mu powiedzieć, jak bardzo mu się podoba to, co mu zaproponowaliśmy. No bo dostaniemy jakąś tam odpowiedź, natomiast możemy czasem nie zauważyć, albo nie usłyszeć, albo nie dostać informacji, że tak w ogóle, to zupełnie jeszcze co innego mi przychodzi do głowy, tylko zamknięty formularz ankietowy nie przewidział takiej możliwości, więc zaznaczyłem – bardzo mi się podoba, i na pewno tego nie użyję, bo X, Y, Z.

Jacek: Naprawcie tę funkcjonalności, które nie działają.

Kuba: I ostatnia rada w tym temacie odległości od Klienta i bardzo powiązana z tym ostatnim moim zastrzeżeniem, to zobacz, jak Twojego produktu używa Użytkownik. Pójdźmy do Klienta, pójdźmy do Użytkownika, pójdźmy do Odbiorcy końcowego. Do jego realnego środowiska, do jego realnego kontekstu i rozmawiajmy z nim jego językiem. Patrzmy, jak funkcjonuje. Patrzmy, jak wykonuje swoje codzienne czynności z naszą poprzednią wersją produktu. Z naszym produktem, który próbuje użyć, lub korzystając z produktów naszej konkurencji. No i tutaj zwłaszcza do takich produktów trochę szerszych, niż tylko strona WWW albo apka. To jest obietnica kosmicznych rezultatów. Nagle się okaże, że użyteczność, że łatwość wykorzystania, że tutaj jakieś nie wiem – dodatkowe instrukcje, materiały, mają jakieś braki i coś jeszcze trzeba dorobić. Mam całą masę przypadków, czy przykładów, których akurat w ramach tego nagrania pewnie nie zmieszczę. Jestem mocno przekonany o tym, że przegląd produktu, czy taki finalny odbiór produktu, koniecznie się musi dziać w kontekście odbiorcy docelowego i też być trzeba czujny na ten właśnie feedback. Widzieć, czy próbować znaleźć ten feedback i również ten niewypowiedziany, czyli te momenty, gdy ktoś tam się drapie po głowie, albo próbuje kliknąć nie trzeba, albo zaznaczyć nie tam, gdzie my planowaliśmy, że powinno to być zrobione. To wiąże się bardzo mocno z tematem projektowania interakcji z Użytkownikiem, czy z Klientem. Warto, jeśli mamy kompetencje w zespole tego typu, to warto te kompetencje właśnie w tym momencie mocno użyć. Z perspektywy Product Ownera, no bo w kontekście pułapek Product Ownera tu jesteśmy, być na to strasznie wyczulonym i być może wręcz zachęcać zespół do kolejnych jakichś takich eksploracji, a nie zamykać się na to, że ja doskonale wiem, bo jestem wizjonerem, albo mój szef jest wizjonerem i powiedział mi, co mam myśleć.

Jacek: Przedostatnia pułapka, którą chcemy poruszyć dzisiaj, to jest pułapka, w której Product Owner nie ma czasu. Nie ma czasu dla zespołu. Nie ma czasu na produkt. Nie ma czasu dla Użytkowników. Nie ma czasu na Backlog. No myślę, że większość z naszych słuchaczy widziała taką osobę w swojej organizacji. Taki wieczny niedoczas, wieczne, lekkie spóźnianie się, bo poprzednie spotkanie. Te wszystkie historie, spójrz na mój kalendarz. No, czyli bardzo duża zajętość. No i czasem tak po prostu jest, że tej pracy jest dużo. Czasem z moich obserwacji, to jest jakaś tam pewna predyspozycja do tego, żeby sobie brać trochę więcej, niż jesteśmy w stanie zrobić. Natomiast mamy też na ten przypadek, kiedy ten nasz Product Owner czasu nie ma, na tyle, ile byśmy się spodziewali. Kilka porad, które lada moment przedstawimy.

Kuba: No i zaczniemy od takiej porady, która zakłada, że ten brak czasu, to jest coś, nad czym się panuje, czy to jest jakaś taka racjonalna decyzja. Product Owner, który po prostu nie ma czasu na te czynności, które od niego oczekujemy, ponieważ realizuje jakieś inne czynności. No i tutaj być może jest miejsce na to, żeby po prostu sobie te rzeczy przeanalizować. Pokazać konsekwencje braku inwestycji czasowej w te zagadnienia związane z pełnieniem odpowiedzialności Product Ownera. Pokazać, jakie są konsekwencje dalsze w zespole. A one są na pewno ewidentne, ponieważ niedoinwestowanie czasowe, na przykład procesu Refinementu, czy niedoinwestowanie w ogóle Backlogu Produktu, później się rzutuje konsekwencjami na słabe cele sprintu, słabe wykonanie, słabe zaangażowanie. Być może konieczność kilkukrotnego powtarzania wykonania jakiegoś kawałka produktu. No i to potrafi być namacalny koszt, czy namacalna strata, czy też spowolnienie pewnych prac. Więc tutaj, jeśli dzieje się to na poziomie racjonalnym, to oczekiwałbym od zespołu scrumowego refleksji, wszyscy wspólnie, na temat, czy tutaj odpowiednia proporcja czasowa, jest przeznaczana na pewne rzeczy, ale też pokazanie pewnego ciągu przyczynowo-skutkowego, że być może dzisiejsze nasze niedomagania, również w tych odległych miejscach. Jak właśnie poszczególne wykonania prac przez developerów. Czy udane, nieudane Sprinty? Czy nawet jakieś takie miękkie rzeczy typu zaangażowanie, czy one nie mają w sobie jednego ze składowych właśnie doinwestowania czasowego ze strony Product Ownera?

Jacek: Do mnie jakiś czas temu, no już spory czas temu, trafiła taka myśl, że de facto nie zarządzamy czasem, tylko sobą w czasie i to bardzo fajnie pokazuje, że de facto mamy wpływ. To jest bardziej kwestia, co decydujemy się robić, zamiast robić jakąś inną rzecz. Więc nie mam czasu na coś, bo po prostu robię inne rzeczy. No bo czas każdy z nas ma taki sam. I on oczywiście jest ograniczony. Kolejna porada, która w szczególności może mieć znaczenie w większych organizacjach, to jest porada, która brzmi – uprośćmy procesy, które zabierają czas Product Ownerowi. I to może być cała masa różnych aktywności i obowiązków, które są narzucone na Product Ownera z racji pełnionej przez niego, czy przez nią roli. Od dodatkowych spotkań statusowych. Spotkań synchronizacyjnych. Przez jakieś uzupełnianie tabelek, dokumentów. Jakichś takich miejsc, które trzeba wyklikać. No poprzez oczekiwanie, że Product Owner będzie uczestniczył w jakichś czynnościach, procesach, aktywnościach, no i de facto musi tam być, no bo X, no bo Y, no bo Z. Może się okazać, że ta ilość obowiązków, która jakby jest zepchnięta tak domyślnie spychaczem organizacyjnym na Product Ownera jest tak duża, że na faktyczne pełnienie roli, powiedzmy sobie to tak wyraźnie – Właściciela Produktu, no może tego czasu pozostać bardzo niewiele.

Kuba: I podobna rzecz, tylko taka przesunięta do zespołu, to odciążenie Product Ownera z obowiązków, które nie są konieczne dla Product Ownera, a mogą być zrealizowane przez pozostałych członków zespołu scrumowego. I mam tu na myśli całą sferę, która często jest oczekiwana od Product Ownera, a wcale nie musi być. Mam na myśli, chociażby faktyczne takie fizyczne pisanie Product Backlogu, czy osobisty udział w każdym jednym ustawieniu warsztatowym z jakimś Interesariuszem, czy Użytkownikiem. Osobisty udział czasami w niektórych firmach na przykład w testach, czy czynnościach około wdrożeniowych. To potrafią być rzeczy, które konsumują czas bardzo mocno. Nawet jeśli nawet nie inwestuje się tu dużo czasu, to też są to po prostu rzeczy, czynności, takie żmudne, wyniszczające organizm, czy męczące, które powodują, że mniej już mamy mocy przerobowych. Mniej już mamy energii tego danego dnia na na przykład wizję produktu, na przykład decydowanie, na przykład jakieś tutaj układanie pewnych większych spraw, bo jesteśmy utopieni w takim bardzo, bardzo operacyjnym działaniu. No i tutaj pamiętajmy o tym, że Product Owner, to jest właśnie no – odpowiedzialność. Realizacja tej odpowiedzialności może być przekazana w praktyce członkom zespołu scrumowego. Zwłaszcza w sytuacjach, gdy ten Product Owner jest osobą właśnie zajętą czasowo, może ma więcej niż jeden zespół, może ma jakieś takie wielkie rzeczy do zrobienia, no i ta taka przyziemność pracy w pojedynczym Sprincie po prostu, no nie jest możliwa do wykonania lub będzie wykonana bardzo, bardzo pobieżnie. Może lepszym rozwiązaniem jest, zwłaszcza jeśli w zespole mamy kompetencje analityczne, architektoniczne, UX-owe. No to są wszystko osoby, które mogą spokojnie podjąć całą masę całego takiego warsztatu produktowego. Pomóc Product Ownerowi i ułożyć w jakiś taki cywilizowany sposób, żeby Product Ownera przesunąć w taką pozycję decydenta. Osoby, która kieruje wizją, ale realizuje to razem z całym zespołem scrumowym. I sam zespół scrumowy, oczywiści wszyscy Developerzy, siłą rzeczy trochę wychodzą z takich ścisłych swoich specjalizacji. Jestem osobą, która rozwija produkt, a nie programistą back-endu, który, no korona mu z głowy spadnie, jak chwilę posiedzi i pozastanawia się, co jeszcze można dla naszego Klienta zrobić. Więc tutaj trochę ironizuję, ale to często spotykam takie oczekiwanie – przeciążenie Product Ownera obowiązkami, które byłyby spokojnie do realizacji, albo grupowo przez cały zespół, albo nawet przez poszczególnych Developerów. 

Jacek: Ostatnia pułapka, którą dzisiaj poruszymy, to pułapka, w której Product Owner nie zna Scruma. Czyli oczekujemy, że Product Owner będzie funkcjonował przy wykorzystaniu frameworka scrumowego, natomiast okazuje się, że nie ma doświadczenia w bądź korzystaniu ze Scruma, bądź tak mówiąc nawet szerzej, być może wcześniej nie rozwijał produktów, bądź nie rozwijał produktów w sposób iteracyjno-przyrostowy. Każdy z tych przypadków może implikować to, że albo będzie ten rozwój produktu nieefektywny, albo to będzie bardziej takie myślenie projektowe. Jakby oba te podejścia moim zdaniem nie są optymalne. Raczej bym się tutaj spodziewał, że taki Product Owner będzie myślał w sposób przedsiębiorczy o produkcie jako takim w całości, a nie tylko o tym, żeby dostarczać kawałki tego produktu do Użytkowników. Tak więc ta znajomość Scruma i tego całego backgroundu, całej tej wiedzy, jak wykorzystać zwinność do wytwarzania produktów, jest kluczowa.

Kuba: No i Jacek pokazujesz tutaj konsekwencje w sumie dosyć prostej pułapki. Takiej łatwej do przewidzenia, czy też wydaje nam się dosyć łatwej do rozwiązania. No najprostsze rozwiązanie, które nam przychodzi, może nawet banalne, to jednak zainwestować czas w poznanie tych technik zwinnych. Poznanie Scruma. Żebyśmy się dobrze zrozumieli – na pewno nie oczekuję od Product Ownera dorównania poziomem pasji i fascynacji metodami zwinnymi, jakich bym się spodziewał od Scrum Mastera, czy od Agile Coacha, czy od lidera transformacji. No ale jakiś taki minimalny poziom przeczytania Scrum Guide’a, może wzięcia udziału w jakimś szkoleniu z podstaw Scruma, czy szkoleniu z podstaw roli Product Ownera. No to potrafi być jeden, dwa, trzy dni zainwestowane w sumie i zrozumienie pewnych absolutnych podstaw, absolutnych fundamentów, które pozwolą dalej już, no na jakimś minimalnym poziomie wykorzystać tę metodę. Pamiętajmy o tej perspektywie zwłaszcza jeśli słuchamy tego odcinka z perspektywy transformacji zwinnej. Jeśli jesteś w roli lidera, jesteś w roli Agile Coacha, czy Scrum Mastera, który pomaga nakręcić taką zwinną transformację, no to zaopiekujmy ten temat zbudowania, zrozumienia Scruma po stronie Product Ownerów. I to jest o tyle istotne, że kolejne lata mijają, kolejne firmy się transformują, bądźmy bardzo czujni nawet na takie sytuacje, gdy ktoś mówi – Jestem Product Ownerem z doświadczeniem z poprzedniej firmy. Siedem lat to już robię, pięć lat to robię, dwa lata to robię, trzy firmy już to robiłem. Może się okazać, że to zupełnie nie ma żadnego znaczenia. Ta rola potrafi być bardzo lekką ręką dysponowana. W różnych firmach kształtowana według własnego uznania tych zarządzających z tamtych organizacji. Więc mimo wszystko, jeśli przeprowadzamy transformację, jeśli przeprowadzamy jakąś reorganizację, wkładamy tę odpowiedzialność Product Ownera w nowe ręce, no to moim zdaniem nie zaszkodzi dla takiego podstawowego BHP wysłać taką osobę na jakieś fajne szkolenie. Być może zaprosić ją do jakiegoś kursu rozwojowego i zadbać o tę podstawową wiedzę o Scrumie i zwinności.

Jacek: Kuba, wspomniałeś, że nie oczekujesz od Product Ownera takiej wiedzy, jak od Scrum Mastera. Nasza kolejna porada, to jest dostać dobre wsparcie właśnie od Scrum Mastera. Czyli jednak nie przypadkowo twórcy Scruma wymyślili tę odpowiedzialność. No i jakby tego bym się spodziewał, że Product Owner ma dostęp do Scrum Mastera. Rozmawialiśmy we wcześniejszych odcinkach podcastu o tym, jak Scrum Master mógłby współpracować z Product Ownerem. No i od takiego Scrum Mastera bym się spodziewał, że i zna framework, jako taki, ale też jest w stanie doradzić, jak wykorzystać zwinne techniki do rozwoju produktu. Tak więc w sytuacji, w której możemy mieć Scrum Mastera, to nawet nie musi być Scrum Master na pełen etat, ale jakiekolwiek wsparcie, z mojej perspektywy może zrobić już znaczącą różnicę.

Kuba: No i ostatnia rada w temacie znajomości Scruma i technik zwinnych, to jest zainwestowanie czasu przez tego konkretnego Product Ownera jednak w dalszy, konsekwentny rozwój. W większych organizacjach można to zrealizować poprzez wewnętrzne społeczności. Jakąś wymianę wiedzy. Może mentoring, shadowing? Po prostu współpracę Product Ownerów pomiędzy sobą, nie tylko na tej warstwie produktu, jakichś takich integracji między produktami, ale też rozmowa o warsztacie. Jak sobie radzę z Interesariuszami? Jak sobie radzę z danymi? Cała masa spraw, która zwłaszcza w takim wewnętrznym kontekście, takim naszym własnym, w naszej domenie, w naszej branży, w naszej firmie, prawdopodobnie będą najlepszą możliwą poradą, jaką dany Product Owner może uzyskać. Czyli taka bardzo kontekstowo dopasowana porada, jak sobie z czymś radzę, co sprawdziłem, co mi się sprawdza, albo co jeszcze chcę spróbować zrobić. Zwłaszcza jeśli możemy tutaj robić jakieś takie procesowe eksperymenty. Ale nawet jeśli w naszej organizacji nie ma takich osób, albo to my czujemy, że jesteśmy najbardziej na topie w porównaniu do wszystkich pozostałych, no to warto rzucić okiem na społeczności zwinne. Obecnie w realiach pandemicznych większość tych społeczności jest realizowana w sposób zdalny. Wiele webinarów jest nagrywanych. Jest tej wiedzy dużo, tylko trzeba być może ją odnaleźć, być może trzeba też zainwestować trochę czasu poza swoimi typowymi godzinami pracy. Ale nawet jeśli to, nawet jeśli nie mamy czasu na webinary, na wielogodzinne spotkania, sami z Jackiem mamy kilka takich materiałów, które po prostu krótkie parę minut przeczytania jakiegoś inspirującego artykułu, już daje nam jakiś materiał do przemyśleń. No i myślę, że tutaj na stronie odcinka zawrzemy kilka takich linków do tych materiałów takich produktowych, które my sami mocno z własnej praktyki, czy z własnych przemyśleń mocno polecamy. Tutaj koniecznie zajrzyjcie na stronę odcinka, ponieważ będzie kilka rekomendowanych źródeł, z których my czerpiemy inspirację związaną ze zwinnym zarządzaniem produktem.

Jacek: Wszystkie te linki, o których Kuba mówił, transkrypcje oraz zapis wideo, znajdziesz na stronie porzadnyagile.pl/56.

Kuba: I na koniec mam do Ciebie prośbę. Chce Cię zachęcić do tego, żeby zapisać się na nasz newsletter, ponieważ 22 lutego wyślemy do naszych subskrybentów listę z poradami, jak porządnie realizować Scruma. Ten odcinek domyka nam pewien taki rozłożony w długim czasie cykl rozmowy o tym, jak robić Scruma porządnie. Zbierzemy materiał. Skompilujemy pewne porady i wyślemy tylko do osób zapisanych na naszą listę malingową. Zapisać się możesz się pod adresem: porzadnyagile.pl/lista. Natomiast jeśli słuchasz tego odcinka po 22 lutego 2021, to każdy kolejny zapisujący się dostanie automatycznie tę wiadomość również jako taki nasz sposób, właśnie na kontakt z Tobą.

Jacek: I to by było wszystko na dzisiaj. Dzięki Kuba.

Kuba: Dzięki Jacek.

Jacek: I do usłyszenia wkrótce.