#056 – 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.

Zobacz wersję wideo:

Dyskusje o pułapkach odpowiedzialności Product Ownera.

O czym usłyszysz w odcinku?

  • 01:18 – Product Owner nie jest decyzyjny
  • 03:38 – Dobre zdefiniowanie produktu i celu produktu
  • 05:56 – Zrewidowanie umocowania decyzyjnego z zarządzajacymi
  • 07:44 – Zmiana Product Ownera
  • 10:23 – Product Owner nie umie decydować
  • 11:07 – Zbudowanie wiedzy o produkcie
  • 12:23 – Product Owner nie zna techniki priorytetyzacji i zarządzania produktem
  • 14:14 – Zmniejszenie konsekwencji podejmowania złych decyzji
  • 16:11 – Bezpieczeństwo psychologiczne
  • 18:25 – Odległość Product Ownera od Klienta
  • 22:22 – Pokaż nawet niedoskonały produkt
  • 26:41 – Product Owner nie ma czasu
  • 27:46 – Panowanie nad brakiem czasu
  • 29:59 – Uproszczenie procesów, które zabierają czas Product Ownerowi
  • 31:13 – Odciążenie Product Ownera z obowiązków, które nie są konieczne dla Product Ownerów
  • 33:57 – Product Owner nie zna Scruma
  • 35:20 – Poznanie Scruma przez Product Ownera
  • 37:28 – Wsparcie Product Ownera przez Scrum Mastera
  • 38:15 – Zainwestowanie w dalszy rozwój Product Ownera

Dodatkowe materiały, które wspominamy w nagraniu:

Daj nam znać co sądzisz o tym odcinku

TRANSKYPCJA

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.


Jeden komentarz do wpisu “#056 – Pułapki odpowiedzialności Product Ownera”

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Wymagane pola są oznaczone *

Newsletter „Porządny Agile”

.

Jesteśmy też tutaj

Podcast od kuchni. Tak nagrywamy dla Ciebie!

Jacek Wieczorek i Kuba Szczepanik
scenariusz do nagrania podcastu
Jacek Wieczorek Kuba Szczepanik podcast

Opinie naszych słuchaczy.

„To jest to! Ekstremalnie dobra dawka potrzebnej wiedzy. Część podcastów otwiera oczy, część porządkuje wiedzę. Polecam!”

„Mimo iż nie jestem bardzo związany z agilem/scrumem, jakieś doświadczenia z nim miałem („retrożale” ;), to bardzo przyjemnie się Panów słucha. Duża i bardzo konkretna dawka wiedzy, bez przynudzania, widać „napracowanie” przy każdym odcinku, jakość ścieżki audio na poziomie, całość w odbiorze sprawia profesjonalne wrażenie. Życzę obu prowadzącym sił do kontunuowania tego (nie)małego dzieła. :)”.

„Takich podcastów nam potrzeba!”

Oceń podcast. Kliknij poniżej.

Apple Podcast logo
logo stitcher
Wordpress Social Share Plugin powered by Ultimatelysocial