To potrzebujemy tego Product Ownera, czy nie?

superPOOstatnimi czasy coraz więcej słyszę i widzę osób spierających się o zasadność utrzymywania roli Product Ownera w firmie. Dla przykładu: w zeszłym miesiącu David Anderson, twórca Kanbana, opublikował artykuł Czy Agile kosztuje cię zbyt dużo? (swoją drogą polecam jego publikacje, bo choć jako remedium na każde zło wskazuje li i jedynie Kanbana, to podaje również przepiękne przykłady źle stosowanego Scruma), otwarcie krytykując koszty Scruma i jego przerost formy nad treścią. Uzasadnia to między innymi przypadkami, w których konsultanci scrumowi każą zatrudnić 400 Product Ownerów, bo w firmie jest 2400 programistów, a więc musi być jeden PO dla 6 developerów, żeby było lege artis, i takich, w których Product Ownerzy tak naprawdę okazali się być analitykami biznesowymi, spisującymi jedynie wymagania dla zespołów. Oczywista oczywistość – koszty utrzymania tylu i takich pracowników były znaczącym elementem dla budżetów firm i często kończyły się rezygnacją z osobnej roli PO w przedsiębiorstwie.

Drugi, ciekawy przykład na eliminowanie roli PO dostarczył mi Jacek Wieczorek, który podczas styczniowego spotkania poznańskiej społeczności Agile wysłuchał opowieści Piotra Trojanowskiego o zmianach, które dzieją się w firmie Currency One. Najciekawszym punktem prezentacji była część dotycząca właśnie roli Product Ownerów w firmie, a  precyzując – decyzja o zlikwidowaniu tej roli na poziomie zespołów. W dużym skrócie, rolę Chief Product Ownera przejął jeden z członków zarządu, natomiast na poziomie zespołów rolę PO zastąpili liderzy projektu w myśl zasady “MKPL”, czyli “osoba z największą wiedzą dowodzi” (ang. most knowledgeable person leads). Powód zmiany wg. Piotra był prozaiczny – wcześniej urzędujący Product Ownerzy często pełnili rolę “proxy”, i funkcjonowali bardziej jako Product Managerowie.

Jak zatem jest? W mojej skromnej opinii powyższe przypadki powyżej świadczą nie o braku uzasadnienia dla roli Product Ownera, ale o nadal pokutujących nadinterpretacjach i nieumiejętności właściwego wykorzystania tej roli dla dobra firmy. Rozprawiając się zatem z nimi po kolei:

  • 400 PO, bo musi być jeden PO dla 6 developerów? Gdyby do mnie przyszedł konsultant Agile z podobnym pomysłem, przede wszystkim poprosiłabym o wskazanie, gdzie w Scrum Guidzie, czy innej oświeconej księdze wyczytał podobne przykazanie. A potem bym mu uprzejmie podziękowała za konsultacje. Jeden Product Owner może współpracować i z 9 zespołami – pisze o tym Ken Schwaber w NexusGuide, czyli przewodniku po skalowaniu Scruma. Również Scrum Guide wskazuje jedynie, że w zespole scrumowym powinien być PO, ale nie wymaga, by każdy zespół scrumowy miał osobnego PO. To właśnie szkodliwa nadinterpretacja.
  • PO jako analityk biznesowy spisujący jedynie wymagania? PO jako proxy i Product Manager? Wyborny strzał w stopę. Jeśli Product Owner nie ma autonomii, nie może samodzielnie podejmować decyzji i wskazywać, co jest dla rozwoju produktu najważniejsze, jeśli nie odpowiada własną głową za błędy i jednocześnie nie firmuje swoją osobą sukcesów, to nie mówcie, że macie PO. Product Owner to nie jest osoba do zarządzania czasem pracy, wrzucania elementów do backlogu, czy przekazywania poleceń od innych. Product Owner to wizja produktu, to jego roadmapa, to znajomość konkurencji, trendów, przewidywanie preferencji klientów, analizowanie rynku, współpraca z użytkownikami i głęboka, ekspercka wiedza na temat produktu, którym się zajmuje. Jeśli pozwolicie Product Ownerowi być Product Ownerem pełną gębą, wówczas może się zdziwicie, jak dobrze wasze produkty mogą być rozwijane.

Oczywiście, ile jest firm i ile jest produktów, tyle jest zupełnie niepowtarzalnych przypadków. Niemniej jednak, zanim zaczniecie się zastanawiać nad zwolnieniem Product Ownera, lub jego zatrudnieniem – zapytajcie sami siebie, czy rola ta w waszej firmie jest, lub będzie wykorzystywana, jak należy. Czy potraficie stworzyć takie środowisko pracy, by Product Owner faktycznie mógł wznieść się na wyżyny, czy może potrzebujecie następnego przesuwacza dokumentów. Jeśli to ostatnie – ok, ale nie mówcie naokoło, że macie Product Ownera i mimo to wasz Agile, czy Scrum nie działają.

P.S. Tak, wiem, znalezienie bądź wykształcenie prawdziwego Product Ownera wymaga rokującego człowieka, czasu i odrobiny cierpliwości ze strony pracodawcy, co jest zadaniem trudnym, ale nadal łatwiejszym od poszukiwań świętego Graala.

Komentarze do wpisu: “To potrzebujemy tego Product Ownera, czy nie?

  1. Ewa,
    ciekawy artykuł. Porusza ważną kwestię jaką jest zasadność…no właśnie – roli czy stanowiska? Mam wrażenie, że te rzeczy są tutaj mieszane.

    Czy pisząc o Product Ownerze odwołujesz się do roli jaka opisana jest w Scrum Guide?

    Jeśli tak, to kwestia „potrzebujemy czy nie potrzebujemy PO” jest nieuzasadniona. W innym przypadku nie mówimy o Scrumie.

    Ja interpretuję to tak, że roli Product Ownera nie można zwolnić, można ją co najwyżej pełnić w mniejszym wymiarze godzin.

    • Hej Bartek,
      jak najbardziej wychodzę od roli opisanej w Scrum Guide. I pytam zaczepnie, czy potrzebujemy, bo właśnie w wielu przypadkach firmy rezygnują z PO lub nie pozwalają mu wykonywać swoich obowiązków zgodnie z zasadami, jednocześnie podkreślając, że pracują Scrumem, co jak zauważyłeś, jest wówczas nadużyciem. Innymi słowy, niektóre firmy uważają, że PO nie jest potrzebny w Scrumie, bo nie zadały sobie trudu, żeby wesprzeć tę rolę we właściwy sposób, i usuwając ją leczą skutki, a nie przyczyny problemu – i to powinien być dla nich przyczynek do dyskusji.

      • Przepraszam, ale ja nadal do końca nie rozumiem, czy chodzi o rolę czy stanowisko 🙁
        Podam przykład. Piszesz: „Drugi, ciekawy przykład na eliminowanie roli PO dostarczył mi Jacek Wieczorek (…)”, a po chwili, opisując przykład podany przez Jacka: „(…) na poziomie zespołów rolę PO zastąpili liderzy projektu”.
        Czyli z jednej strony eliminacja, a z drugiej nie do końca, ponieważ w rolę weszli liderzy projektu, zatem nie została ona wyeliminowana.

        • Obawiam się, że tu do odpowiedzi muszę wezwać Jacka, bo on był nausznym świadkiem tych słów i może znać szerszy kontekst.
          Z tego, co ja zrozumiałam, liderzy projektów nie pełnią roli PO i nie mają kompetencji Product Ownera zgodnych ze Scrum Guide. Choćby kwestia podejmowania decyzji – nie robią tego samodzielnie, tylko realizują zadania zlecone przez Chief Product Ownera. Wydaje mi się, że są raczej liderami technicznymi, ale tak jak wspomniałam, poproszę Jacka o szerszy kontekst.

  2. Możemy pozostać przy tym poziomie szczegółów. Mnie intryguje to co padło już w artykule. Spróbuję jeszcze inaczej napisać co dokładnie.

    W pierwszym przykładzie mamy: ” rolę Chief Product Ownera przejął jeden z członków zarządu”. Do tego, jak rozumiem, wyeliminowano rolę PO będącego w relacji 1:1 z zespołem.

    To dla mnie oznacza, że nadal jest PO, tylko jeden na wiele zespołów. Czyli mamy do czynienia nie z wyeliminowaniem roli, lecz wybraniem innej osoby do jej pełnienia. W tej sytuacji to nie narusza wytycznych Scrum Guide i jest zrozumiałym zachowaniem, jeśli poprzedni układ nie spełniał oczekiwań udziałowców.

    Jak rozumiem twierdzisz, że trzeba było od razu wprowadzić takie rozwiązanie, zamiast sztucznie wyznaczać PO?

    • Jak najbardziej zgadzam się – członek zarządu jako PO dla wielu zespołów jest zgodny „z wytycznymi”. To, co było wcześniej, czyli POsi przy zespołach, ale bez samodzielności, proxy, w roli PMów, to niestety nie byli Product Ownerzy ze Scrum Guide. I o ile nowe rozwiązanie, czyli jeden PO dla wielu zespołów brzmi dobrze, zastanawia mnie, dlaczego wcześniej Product Ownerzy nie pełnili swoich funkcji. Sami z siebie stali się proxy, nie mieli kompetencji, by samodzielnie zarządzać produktem, czy ich przełożeni/interesariusze/zarząd nie pozwalali im podejmować samodzielnie decyzji? Dlaczego firma zdecydowała się na takie, dość radykalne, posunięcie? Czy próbowano wcześniej jakoś naprawić tę sytuację? Bo jak dla mnie to jednak przykład na pattern pt. „PO nie wypełnia poprawnie swoich obowiązków = zaorać”, bez refleksji, co stoi za tymi problemami. I pozostaje mi gdybać, na ile członek zarządu będzie pracował jak prawdziwy PO z zespołami, backlogiem, przekazując wizję, a na ile postanowiono, że będzie po prostu przekazywał, co zespoły mają zrobić.

  3. Ewa,

    Pozwól że wypowiem się jako autor prezentacji „In pursuit of lean agility” na którą się powołujesz, którą przedstawiłem w styczniu 2016 na Poznan Agile User Group.

    Sensem zmian w Currency One było przywrócenie właściwego znaczenia roli Product Ownera. Ten sens gdzieś umykał i rozmywał się pod płaszczykiem nazwy.

    Obecnie w Currency One istnieje dwupoziomowy zespół produktowy: CPO + PO. PO nazywają się co prawda Project Leadami, natomiast wpływ zespołu produktowego na rzeczywistość produktową jest nieograniczony. I tak, oczywiście że produktowcy pracują ciasno z zespołami,

    p.s. Serdecznie zapraszam wszystkich zainteresowanych do Zwinnej Łodzi gdzie przypadek Currency One będę przedstawiał 29 lutego 2016.
    p.p.s. Rzeczywiście bardzo ciekawe są trendy które podnoszą słabości jednoosobowego product ownerstwa (Patton, Hussman, etc.). Odbieram je nie jako negację scrumowego PO, lecz jako próbę wzbogacenia rzeczywistości poprzez stosowanie podejścia partycypacyjnego, a więc podejścia które leży u podstaw idei Agile. W ten nurt wpisuje się np. idea Davida Hussmana „Product Developer” (patrz ABE2014).

    • Hej Piotr,
      dzięki za zabranie głosu w dyskusji – w takim razie mogę u źródła dopytać o szczegóły 🙂
      Wyżej w odpowiedzi dla Bartka zastanawiam się, dlaczego firma zdecydowała się na taką zmianę. Sam piszesz, że chodziło o przywrócenie właściwego znaczenia roli Product Ownera. Co stało na przeszkodzie, żeby dotychczasowi POsi na poziomie zespołów stali się POsami pełną gębą? Skoro byli proxy czy PMami, to może wystarczyłoby ich wesprzeć, zamiast decydować się na oddanie roli PO jednemu z członków zarządu? I drugie pytanie – co takiego mają Project Leadzi, że zastąpili w roli PO dotyczasowych Product Ownerów, bo jeśli, jak piszesz, nadal są POsi na poziomie zespołów (choć z inną nazwą stanowiska), to dlaczego są to inni ludzie?
      P.S. Jeśli ktoś z naszych czytelników wybiera się na prezentację w Zwinnej Łodzi, gorąco zachęcam do podzielenia się w komentarzu swoimi uwagami. Chętnie dowiem się, jak wy odebraliście prezentację Piotra.

      • Paweł Polaczyk

        Z tego co zrozumiałem z prezentacji Piotra: Project Lead nie jest na stałe związany z zespołem. Pojawia się projekt i osoba o największej wiedzy w danej dziedzinie (ekspert dziedzinowy) w sposób niemalże naturalny zostaje leaderem takiego projektu. Podejrzewam, że to co mają Project Lead’zi, a czego nie mieli poprzedni etatowi PO, to wiedza dziedzinowa. Jako, że reprezentują jakiś konkretny obszar działalności firmy, mogą mieć też największą wewnętrzną motywację, zaangażowanie i wiedzę by daną zmianę, projekt przeprowadzić. Tak to sobie przynajmniej wyobraziłem podczas prezentacji 🙂 Czy tak jest w rzeczywistości, to pytanie do Piotra i pracowników Currency One, bo podczas spotkania wypowiadali się z mniejszym entuzjazmem niż Piotr na temat tej zmiany 😉
        Co do Chief Product Ownera – PO to powinien być człowiek z wizją. Jeśli to akurat członek zarządu jest głównym wizjonerem produktu, to jest to chyba właściwa osoba by kierować rozwojem produktu.

      • Byłem na tej prezentacji, więc i ja się odniosę. Tak to zrozumiałem:
        1. Organizacja się na przestrzeni ost. 1,5 roku mocno rozrosła (o 250%) i zaczęła tracić swoje oryginalne lean DNA.
        2. Dotychczasowi POsi byli jedynie proxy, bardziej takimi project managerami (a nie Product Managerami). Stali się więc jedynie ogniwem w głuchym telefonie (ostatni z 5 poziomów).
        3. Po zmianach zastąpili ich prawdziwi, decyzyjni POsi, tutaj nazywani MKPL (skrócenie do 3 poziomów, od CPO, przez bodaj Zarząd akceptujący wizję, po MKPL), wywodzący się z biznesu, ściśle współpracujący z CPO (wizjonerem). Przypisywani do zespołów dynamicznie.
        4. Część dotychczasowych POsów stała się MKPL. Dla części jednak zabrakło miejsca i zmienili stanowiska / opuścili organizację. U części ta zmiana wywołała niezadowolenie, co zostało wyrażone głosem z sali.

        btw: jestem prawie pewien, że ani razu framework w C1 nie został nazwany scrumem 😉

        • Dzięki, Bartek, za rzucenie dodatkowego światła na prezentację Piotra i przedstawienie twojego jej rozumienia!

  4. Agile jest tak zwinny jak zwinni są ludzie.
    Dogmatyczne lub naiwne podejście do agile kończy się porażkami.
    Product Owner to klasyczny Product Manager (nie project manager), czyli nic nowego w biznesie.
    Nowomowa, która pojawia się w metodyce scrum często mydli oczy niedoświadczonym entuzjastom, a przecież wiele analogicznych ról i metod oraganizacyjnych w wytwarzaniu softu funkcjonuje nie od dziś. Wiele firm małych i średnich stosuje praktyki zwinne zanim dowiadują się o ich istnieniu od nowoczesnych konsultantów 🙂
    Na ostatniej rozmowie kwalifikacyjnej kandydatka z zapałem opowiadała, że koniecznie chce pracować w zespole scrumowym. W CV miała m. in. Scrum Master Foundation I a także PRINCE 2 Foundation. Spytałem czym jej zdaniem Scrum góruje nad PRINCE 2. Powiedziała, że jest krótka iteracja i częstsza kontrola rezultatów. W odpowiedzi narysowałem jej wykres aktywności w PRINCE 2, gdzie wyraźnie wzrasta zarządzanie zmianami i kontrole wraz z aktywnością developerów (faza wytwarzania oprogramowania). Zaległa Cisza. Kandydatka nie zauważyła analogii pomiędzy zarządzaniem zmianami w klasycznych metodykach a iteracją w Scrumie.
    Z drugiej strony zauważyłem, że atrakcyjność, nowoczesność, prostota (a właściwie Uproszczenie) i „nowomowa” Scruma przyciąga mnóstwo młodych, niedoświadczonych ludzi, którzy po przeczytaniu Scrum Guide natychmiast są managerami.
    Ale biznes nie jest taki prosty…

  5. Dla mnie osobiście najważniejsza część dotycząca Product Ownership dotyczy odpowiedzialności, za którą idą w parze decyzyjność oraz odpowiednia „przestrzeń”. Zauważam, że wiele firm poszło póki co w innym kierunku niż chcieliby tego twórcy Agile Manifesto, a mianowicie w kierunku micromanagement’u na poziomie pełnionych ról w zespołach Scrumowych. W efekcie odchodzi się od źródeł wartości i ducha Agile, o czym zgrabnie i krótko napisał powyżej Wacław. Zamiast zastanawiać się nad biznesem, firmy zastanawiają się czy potrzeba Product Ownera, czy może trzech, ale odpowiedzialnych za zarządzanie backlogiem. Dla mnie Product Ownerem jest osoba lub zespół ludzi (mniej efektywna struktura), która ponosi odpowiedzialność produktową. Gdy tej odpowiedzialności nie ma, wszelkie decyzje podejmowane przez PO obarczone są dużym ryzykiem, związanym z podejściem „ważne by poprawnie robić swoje”.

    • Nie sposób się nie zgodzić, Paweł, autonomia i odpowiedzialność są nierozerwalnie związane z rolą PO. Jeśli mamy do czynienia z mikromanagementem, to prędzej czy później pojawią się problemy.

    • Grzegorz Łoziński

      Jednak należy czytać wszystkie komentarze przed postawienie swojego. Napisałbym dokładnie to co Wacław, bo dokładnie się z tym zgadzam. A poparte jest to doświadczeniem ostatnich 8-10 lat. Czy nie wydaje się Wam (tu zwracam się ku bardziej doświadczonym analitykom), że tworzenie biznesu przechodzi pewne ‚mody’, niestety nie zawsze wprowadzające zmianę (czy dobra to inna kwestia;-)). Tak jest nowomowa scrumowa, opisująca integracyjne realizowanie produktu.
      Chyba nie ma wątpliwości że za produkt odpowiada jego manager. Poziomy poniżej (ich ilość i zakres odpowiedzialności) zależą od wielkości produktu. Innego zespołu potrzeba do zrobienia sklepu internetowego, a innego do systemu zarządzania lotniskiem.


Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

*

Ta strona używa Cookies. Korzystając ze strony wyrażasz zgodę na używanie ciasteczek zgodnie z aktualnymi ustawieniami przeglądarki.
Akceptuję, bo lubię Was czytać.
x