Z Jakubem Doboszem o dobrym product ownershipie

Anna Adamkiewicz: Pytanie na rozgrzewkę: kim według Ciebie jest Product Owner?

Jakub Dobosz (Agile Delivery Lead w Pragmatic Coders): Jest osobą, która skupia się na rozwiązaniu jakiegoś problemu albo wyzwania biznesowego, myśląc o wartości, której dostarcza. I dba o to, żeby osiągnąć to w najbardziej efektywny sposób.

Słyszałam kiedyś stwierdzenie, że Product Owner jest kimś w rodzaju mediatora między oczekiwaniami czy potrzebami klienta – a zespołem deweloperskim. Czy zgodziłbyś się z tym?

Nie. Rolą Product Ownera jest dbanie o efektywne dostarczanie wartości. Jeżeli w danym momencie, żeby dostarczyć wartość, jest potrzebna rola mediatora to tak – wtedy jest mediatorem. Natomiast nie zakładałbym, że mediowanie to jego główna rola. Mogą się natomiast zdarzyć sytuacje, w których Product Owner będzie wykorzystać takie umiejętności. Dam Ci prosty przykład. Pracowaliśmy z zespołem nad dostarczeniem ważnego celu biznesowego w bardzo krótkim czasie. Był to rynek finansowy i chodziło konkretnie o wyjście z pożyczką do klientów bankowych. Pojawiła się kwestia wyświetlania dokumentów i regulaminów w PDF-ach. Najlepszy UX wymagałby tego, żeby każdy PDF wyświetlał się w aplikacji, był responsywny, a użytkownik mógł go łatwo zamknąć i wrócić do procesu. Tymczasem zespół deweloperski od razu zaznaczył, że wdrożenie tego będzie zbyt czasochłonne, szybszym rozwiązaniem będzie otwieranie PDF-ów w zewnętrznej aplikacji. Omówiłem tę kwestię z głównym interesariuszem, który zgodził się, że to nie jest tak istotne dla całego procesu, a kluczowe jest wdrożenie całości w zakładanym czasie. Stanęło więc na zewnętrznym rozwiązaniu. Z tą informacją wróciłem do zespołu na następny dzień. W międzyczasie zespół zrobił research, z którego wynikało, że przygotowanie lepszego UXowo rozwiązania nie zajmie znacząco więcej czasu. Ale klient już nie chciał do tego tematu wracać. I w pewnym sensie doszło tu do mediacji. Jednocześnie ten przykład pokazuje też, jaki wpływ mogą mieć wybory techniczne zespołu na decyzje podejmowane na poziomie biznesowym.

Problem z rolą mediatora może prowadzić do wytworzenia sytuacji, w której większość albo wszystkie komunikaty od sponsora czy klienta trafiają do zespołu przez Product Ownera. Wtedy jego funkcja jest zredukowana do roli przekaźnika czy tłumacza z języka biznesowego na techniczny – a tego powinniśmy totalnie unikać, to patologia.

Czy Product Owner jest potrzebny Developerom? Jeśli czasem zadajesz sobie to pytanie, ten MeetUp jest dla Ciebie! Weź udział w wydarzeniu i posłuchaj głosu doświadczonych praktyków!

12 grudnia | poniedziałek | godz. 18.30|
Kraków | Pragmatic Coders
Wstęp WOLNY, liczba miejsc ograniczona
✅ Obowiązują ZAPISY

Do rozmowy zapraszamy zarówno Developerów, jak i Product Ownerów. Przyjdź i Ty!

A jakie miejsce Product Owner zajmuje w zespole?

W Pragmatic Coders budujemy zespoły scrumowe w modelu T-shaped. To oznacza, że wszyscy mamy szeroką wiedzę w wielu dziedzinach na podstawowym poziomie. Dzięki temu wykazujemy sporą zastępowalność w różnych czynnościach, co pozwala płynnie dostarczać wartość. Ale do tego dochodzą głębokie specjalizacje, czyli nóżka litery “T” – bo jednocześnie każdy z nas ma swoją domenę działania. I dla mnie domeną działania Product Ownera jest dbanie o to, żeby na koniec dnia została dostarczona wartość. Z uwagi zaś na górną belkę w “T” zależy nam na tym, żeby zespół był w stałym kontakcie z klientem i rozumiał dany biznes. To pozwala złapać ten szeroki horyzont naszych działań całemu zespołowi scrumowemu.

A czym według ciebie jest dobry Product ownership? Co go wyróżnia?

Są dwie rzeczy. Po pierwsze – jak najszybsze opieranie się na danych i faktach. Na początku mamy jakieś hipotezy, które stawiamy. Dobry product ownership powinien dążyć do tego, żeby jak najszybciej je walidować, opierając się na pozyskanych informacjach, takich jak rozmowy z użytkownikami, dane z rynku – cokolwiek, co może nam pomóc podjąć jak najbardziej obiektywną decyzję. A drugą cechą wyróżniającą jest umiejętność mówienia nie. Dlaczego? Na przykładzie produktu – mając jego zarys, pojawia się mnóstwo pomysłów jakie może być jego najlepsze zastosowanie, czy też jak należałoby go zrobić. I pomysły te pochodzą z różnych źródeł: od autorów danej inicjatywy, od interesariuszy w organizacji czy zespole klienta, od członków zespołu scrumowego, czy wreszcie od użytkowników. Tym samym są różne oczekiwania względem rozwoju produktu. I teraz umiejętność mówienia nie – czego nie zrobimy albo co zrobimy w późniejszym czasie – to też jest cecha dobrego product ownershipu.

A jak dobry Product Ownership wspiera według Ciebie pracę zespołu deweloperskiego?

Jeżeli działamy opierając się na danych, to układamy drogę bardziej solidną i pewną. To jest istotne dla wyznaczania krótkoterminowych i długoterminowych celów. Te pierwsze pozwalają zachować skupienie na najbliższe sprinty, a dodatkowo, jak mamy je zdefiniowane i pozyskujemy nowe dane oraz informacje, możemy intencjonalnie wpływać na ich kształt. Zaś w dłuższej perspektywie ważne jest, żeby Product Owner pracował na widocznej dla wszystkich, zrozumiałej, opartej na celach Roadmapie. I to też daje zespołowi poczucie sensu. Czyli z jednej strony efektywne planowanie i realizacja bieżących wyzwań, z drugiej znana dla całego zespołu perspektywa przyszłych celów.

Chciałabym to teraz zderzyć z inną perspektywą. Rola Product Ownera wywodzi się z Agile, a konkretnie wprost z ramy Scrumowej. W innych organizacjach spotkałam się z takim stwierdzeniem, że Scrum nie działa. Co byś im odpowiedział?

Scrum nie działa – akceptuję to stwierdzenie. Pytanie natomiast jest takie: dlaczego nie działa? Może nie działać, bo ktoś się łudzi, że go implementuje. Ktoś uważa, że jak robi Daily, to pracuje w Scrumie i potem dziwi się, że nie działa.

Po drugie, są miejsca, gdzie Scrum nie będzie działał. Bo Scrum nie jest rozwiązaniem na wszystkie problemy. W przypadku czynności bardzo powtarzalnych, gdzie nie występuje innowacyjność i nie dochodzi do walidacji hipotez, Scrum się nie sprawdzi. Najprostszym przykładem może być fabryka, która dostarcza regularnie ten sam produkt. Tam są potrzebne inne mechanizmy do zarządzania procesami.

Tutaj warto przywołać model Cynefin. Scrum jest stosowany na przełamaniu problemów Complex i Complicated. Czyli są już jakieś praktyki wypracowane, ale jednocześnie mamy dużo niewiadomych co do tego, jak coś zrobić. Wszędzie tam, gdzie zachodzi potrzeba szybkiej pętli zwrotnej, ustawienia celów, które będziemy realizować w krótkim czasie i zbierania danych w kontekście podejmowania kolejnych decyzji. Czyli w środowisku, gdzie coś odkrywamy. Dlatego Scrum najlepiej sprawdza się w sytuacji wytwarzania nowego produktu (bądź jego części) czy usługi, gdzie jest przestrzeń na eksperymentowanie. Scrum dostarcza ram, które pozwalają ułożyć pracę zespołu.

A jak zmieniła się Twoja praca, odkąd pracujesz w tym frameworku?

Trafiłem na Twitterze na taki wpis: Paradoxes don’t actually exist in physics. When we see an apparent paradox, it’s really a clue pointing to a gap in our understanding. I to skojarzyło mi się ze Scrumem, parafrazując: Exceptions don’t actually exist in Scrum. When we see an apparent exception, it’s really a clue pointing to a gap in our understanding. Przykładowo może pojawić się myśl, że w tym momencie nie jest nam potrzebna Retrospektywa. I teraz pytanie czy ona rzeczywiście nam nie jest potrzebna? Czy ja czegoś nie rozumiem? I to skłania znowu do powrotu do tych ram określonych w Scrum Guidzie – bo może coś omijamy?

Miałem kiedyś takie doświadczenie, że zrezygnowaliśmy w zespole z Review prowadzonego na koniec Sprintu. Mieliśmy poczucie, że codziennie rozmawiamy z klientem, że w sposób ciągły dostarczamy wartość i nie czekamy do końca Sprintu, żeby dowieźć przyrost. Na bieżąco omawialiśmy cele i otrzymywaliśmy feedback. Natomiast jednym z elementów Review jest też spojrzenie w przyszłość. Review daje czas na to, żeby zastanowić się nad tym, jakie decyzje podejmujemy w dłuższej perspektywie: czy zmieniamy obrany kurs? Czy mamy dobrze określony cel kolejnego sprintu? W jakim miejscu Roadmapy jesteśmy? Czy wiedza zdobyta w ostatnim okresie wpływa na nasze plany? A przy rezygnacji z Review tego nam właśnie zabrakło.

Zaś z perspektywy całej firmy Pragmatic Coders Scrum nadaje ramy naszej pracy we wszystkich zespołach. Czyli pracujemy z Backlogiem, prowadzimy Refinement, mamy Planning, Retrospektywę etc. I wdrożenie tych ram standaryzuje nasze działania i procesy, umożliwia nam porozumiewanie się w tej samej domenie.

I myślę, że to co jest ważne dla nas w PC w Scrumowym frameworku, to są filary. Z nich wynika nasza postawa, podejście do produktu i osiągania celów.

Zgadza się. Istotne oczywiście są filary Scruma, które w rezultacie mogą zbudować zaufanie jako fundament.. Weźmy na przykład transparentność. Nie malujemy trawy na zielono i jesteśmy otwarci na to, co klient do nas mówi. Bo transparentność powinna działać w obie strony. My pokazujemy klientowi nasze podwórko, to jak działamy i w jaki sposób chcemy dowieźć tę wartość. A z drugiej strony klient daje nam feedback – i co ważne, my tego feedbacku szczerze chcemy. Trochę jak w restauracji, gdzie kuchnia jest otwarta i możesz zobaczyć, jak kucharze gotują i gdzie oczekuje się Twojej opinii o posiłku.

Transparentność, inspekcja i adaptacja. Czyli walidujemy to, co dostarczamy i nie skupiamy się wyłącznie na własnych rozwiązaniach, tylko stale jesteśmy ciekawi tego, co może przyjść z zewnątrz.

To na koniec jeszcze jedno pytanie. Co lubisz w swojej pracy?

Lubię widzieć, że to, co dostarczamy, rozwiązuje problemy i odpowiada na potrzeby ludzi. Jest przydatne i rzeczywiście używane. W natłoku bieżących, codziennych zadań łatwo zapomnieć na przykład o tym, że z produktu korzysta już kilkadziesiąt tysięcy osób.

Na koniec dnia dla mnie jako Product Ownera istotna jest satysfakcja i wygoda użytkownika. Za tym oczywiście stoi więcej elementów, jak biznes, dostarczanie wartości interesariuszom po stronie sponsora, który koniec końców chce na tym rozwiązaniu zarobić. Natomiast dla mnie jest to wynik dobrze zrobionego produktu, a nie cel sam w sobie.

W kontekście zaś zespołu Scrumowego – to współpraca i poczucie, że wspólnie możemy dużo zrobić. Kształt produktu na koniec dnia jest zasługą całego zespołu, bo każdy dołożył do tego swoje cegiełki. I widzieć to, że udało się połączyć wszystkie elementy, które przygotował zespół i dostarczyć coś, co ułatwia ludziom życie – to jest satysfakcjonujące.

Myślę, że to bardzo uniwersalne co powiedziałeś. Największe spełnienie w pracy daje nam to, że widzimy sens tego, co robimy. Dziękuję Ci za rozmowę.

Z Jakubem Doboszem rozmawiała Anna Adamkiewicz.

Jakub Dobosz /on LinkedIn/ Agile Delivery Lead w Pragmatic Coders. Skupiony na wartości biznesowej i szukaniu dróg dostarczenia jej w optymalny sposób. Ceni synergię zespołu, przejrzystość działania i otwartą komunikację. W branży IT od ponad 10 lat w różnych rolach (programista, PM, PO, lider). Zbiera energię poprzez medytację, muzykę, podróże oraz jazdę na rowerze.

#PCjoinus
Jeżeli podoba Ci się to, co robimy – dołącz do nas! Sprawdź nasze OFERTY PRACY i aplikuj.