Czym się różni Product Owner od analityka? I za co tak właściwie odpowiada Product Owner? Czy na pewno nie jest to „taki analityk co zarządza backlogiem”?
Czym zajmuje się Product Owner?
Ostatnimi czasy, zarówno na niniejszej liście mailingowej, jak i na kanale na YouTube, zajmowaliśmy się tematem odpowiedzialności. Product Owner służył nam zaś za przykład tego, jak tę odpowiedzialność możemy rozumieć. Jeżeli jakimś cudem umknęły Ci poprzednie teksty albo filmy, zdecydowanie warto do nich zajrzeć. Dziś zaś zestawimy ze sobą Product Ownera i analityka.
Zacznijmy od bardzo prostej rzeczy, czyli odpowiedzialności Product Ownera według Scrum Guide’a. Z jednej strony są one bardzo precyzyjnie opisane. Z drugiej zaś jedno drobne zdanie mówi, że PO może wykonywać wszystko samodzielnie albo delegować zadania do zespołu.
„The Product Owner is also accountable for effective Product Backlog management, which includes:
- Developing and explicitly communicating the Product Goal;
- Creating and clearly communicating Product Backlog items;
- Ordering Product Backlog items; and,
- Ensuring that the Product Backlog is transparent, visible and understood.
The Product Owner may do the above work or may delegate the responsibility to others” – Scrum Guide
I właśnie to ostatnie zdanie o delegowaniu zadań do innych jest problemem w większości miejsc, gdzie powstają konflikty odnośnie zakresu odpowiedzialności analityka i Product Ownera. Dlatego też w specjalnie poruszyliśmy temat macierzy RACI, czyli jednego ze sposobów, w którym możemy sobie jasno i wyraźnie powiedzieć, kto za co odpowiada.
W każdej jednej sytuacji, w której zespół narzeka na to, że Product Owner czegoś nie robi, a Product Owner nie widzi problemu, mamy do czynienia z konfliktem spowodowanym wzajemnym niezrozumieniem zakresu odpowiedzialności. To niezrozumienie z kolei wynika wprost z tego, że nigdy tego wspólnie nie ustaliliśmy. Każdemu wydaje się coś innego, a dobrze wiemy, że kiedy komuś się coś wydaje, to są z tego same problemy.
Niezależnie więc od tego, co mówi Scrum Guide, musimy wspólnie usiąść, przedyskutować i ustalić, za co odpowiedzialny jest Product Owner, a za co odpowiadają inne osoby, czy to z zespołu, czy spoza niego.
Za co Product Owner odpowiada?
„Regardless, the Product Owner remains accountable.” – Scrum Guide
Jeżeli chcemy być purystami, to oczywiście Product Owner jest accountable za wszystkie rzeczy, które wymienione są w Scrum Guide. W tym, zgodnie z literą podręcznika, za tworzenie Elementów Backlogu Produktu, czyli PBI. I tu zawsze warto przypomnieć sobie różnice pomiędzy responsibility i accountability. Cytowane „accountable” wcale nie znaczy, że ktoś musi wszystko robić samodzielnie. To znaczy, że odpowiada za rezultaty.
Skoro tak, to nie ma żadnego wymogu, żeby to Product Owner własnoręcznie tworzył cały backlog. Ba, nawet jeżeli chodzi o poszczególne elementy, również to też nie jest tak, że musi to robić. Na pewno PO musi wiedzieć, co się w backlogu znajduje, bo inaczej nie będzie w stanie układać kolejności poszczególnych elementów. Ale spokojnie może „zlecać” te prace czy to do „biznesu”, czy to do „analityków”. Pod warunkiem, że obdarowani tymi zadaniami wiedzą, co robią. A PO wie, co zrobili i umie tym zarządzać.
Pamiętajmy też, że Scrum ma nam pomagać, a nie nas usztywniać. Jeżeli znajdziemy jakieś lepsze rozwiązanie, to jak najbardziej możemy z niego skorzystać. Najważniejsze jest, żeby najpierw ustalić to wśród wszystkich zainteresowanych, a następnie w praktyce sprawdzić, że takie podejście działa.
PO jako lider
Patrząc na zapisy Scrum Guide, na pewno PO nie powinien rezygnować z bycia zarówno accountable, jak i responsible w kontekście określania Celu Produktu, wyjaśniania i omawiania Product Backlogu jako spójnej całości oraz ustalania kolejności poszczególnych elementów. Te rzeczy nie powinny być delegowane!
Product Owner to osoba, która powinna być faktycznym właścicielem rozwijanego produktu. Powinna też mieć jakąś wizję, zarówno jeżeli chodzi o stan docelowy – ten krótkoterminowy wyrażony Celem Produktu, jak i długoterminowy będący wizją. To nie znaczy jednak, że PO nie dostaje wytycznych od swoich przełożonych i zawsze musi być równie decyzyjny co prezes!
PO działa troszeczkę jak oficer, gdzie strategiczne plany i operacje do wykonania przychodzą z góry, ale ich realizacja oraz poszczególne działania są już inwencją samego/samej PO. Problem pojawia się, kiedy Product Owner sprowadzany jest do roli podoficera, gdzie jedyne, co może zaplanować, to tylko sposób wykonania konkretnych działań. To za mało. I co do zasady, to im lepiej umocowany PO, tym lepiej.
Na pewno Product Owner powinien mieć decyzyjność na wysokim poziomie. Zbyt wiele organizacji sprowadza PO de facto do roli Project Managera, który ma tylko i wyłącznie zaplanować prace, które już z góry zostały określone i rozpisane. Odłóżmy tę (niescrumową) sytuację na bok i wróćmy do kwestii tworzenia backlogu.
Czy Product Owner to analityk?
Skoro wiemy, że Product Owner odpowiada za backlog, ale jest to odpowiedzialność typu „accountable”, to nadal nie odpowiada to na pytanie o „tworzenie wymagań”. Mowa tu o faktycznym uzupełnianiu elementów Backlogu Produktu (PBI) treścią. Może to być na przykład pisanie User Stories oraz ustalenia z biznesem, użytkownikami i innymi interesariuszami. Jak powinno być?
Niestety muszę tutaj udzielić odpowiedzi, która zawsze powoduje spojrzenia pełne nienawiści, czyli: „to zależy”. Widziałem bowiem zespoły, w których PO był też de facto głównym analitykiem – spotykał się z interesariuszami, wydobywał wymagania od biznesu, a w zespołach znajdowali się bardziej analitycy systemowi, którzy brali udział w refinementach, dekompozycji tych wymagań na kawałki biznesowe i fragmenty pracy, które da się zrealizować Sprint po Sprincie.
Widziałem też takie sytuacje, w których Product Owner działał bardziej jako strateg, czyli zajmował się tworzeniem wizji produktu, układaniem priorytetów i zarządzaniem kolejnością wykonywanych prac z kamieniami milowymi (itp. itd.), natomiast do backlogu wrzucałne były tylko i wyłącznie hasła oraz nagłówki. Wtedy osoby z zespołu (mniejsza o to, czy analitycy), zajmowały się refinementami, ale też zbieraniem i ustalaniem szczegółów, rozmowami z użytkownikami, z biznesem i tak dalej.
Możliwe są też oczywiście wszystkie warianty pośrednie. Chyba najpopularniejszym jest taki, gdzie PO zaczyna wysokopoziomowe ustalenia i tworzy zarys wymagań i elementów w Backlogu Produktu. Następnie wspólnie z zespołem uczestniczy w spotkaniach z interesariuszami oraz w refinementach. Rezultatem tych działań jest dobre przygotowanie zespołu do planowania i do kolejnych Sprintów, a jednocześnie dużo pracy związanej z refinementowaniem należy do zespołów. Szczególnie: do analityków w zespołach.
Co robi analityk w Zespole Scrumowym?
Jeśli nasza praca scrumowa opiera się o refinement i dzielenie wymagań, to siłą rzeczy duża część „typowej analitycznej pracy” dzieje się właśnie podczas spotkań refinementowych. Co nie znaczy, że nie są one prowadzone przez osoby piastujące stanowisko analityka. Ani że analitycy nie dokonują analizy i dzielenia wymagań offline, poza refinementami.
Podobnie jak przy roli Product Ownera, tak i przy analityku – ile zespołów, tyle wizji. Niektórzy zajmują się zbieraniem i przetwarzaniem wymagań na Elementy Backlogu Produktu. Inni dostają „gotowe” wymagania, a prace analityczne dotyczą głównie detali, przypadków szczególnych, algorytmów oraz procesów i niekiedy nawet UX/UI.
Na pewno nigdy nikomu nie polecę, ani nawet pozytywnie nie zaopiniuję posiadania „osobnych zespołów analitycznych”, które są „poza Scrumem”. Jeśli mamy Scrum Team, to w naszym zespole powinni być wszyscy, którzy są potrzebni do wytworzenia produktu. W tym analitycy, którzy są potrzebni do ustalenia szczegółów.
Najlepiej, kiedy wszyscy rozumieją podział na refinement i analizę w Sprincie. Z jednej strony musimy wiedzieć wystarczająco dużo, żeby zacząć pracę nad danym elementem backlogu, a także upewnić się, że mieści się on w Sprincie i jest względnie samodzielny i niezależny. Z kolei w samym Sprincie musimy ustalić wszystkie te detale, które nie powstrzymują nas przed samym zrealizowaniem wymagania, ale mogą podnieść jakość bądź wartość rozwiązania.
Nie oszukujmy się, duża i ciężka praca analityczna zwykle wiąże się z odkrywaniem wymagań, ich zrozumieniem i dzieleniem, a więc dzieje się przed Sprintem – w ramach refinementów. Podobnie jeśli chodzi o zrozumienie algorytmów, procesów, procedur czy prawa i innych dokumentów. Ale nigdy nie zgodzę się z tym, że analityk nie jest potrzebny w (prawdziwym) Zespole Scrumowym w trakcie realizowania Backlogu Sprintu.
Co analityk potrzebuje od PO?
Gdy sam byłem analitykiem, najbardziej zależało mi na otrzymaniu wizji, kierunku rozwoju, uzasadnienia biznesowego oraz konkretnie opisanego stanu docelowego, do którego dążymy. Wszystko to oczywiście w kategoriach biznesowych, a nie zadań do realizacji. Całą resztę przygotowań, czyli pisanie, dzielenie i uszczegóławianie wymagań z kim tylko się da, traktowałem jako moją pracę analityczną. Przy czym działo się to najczęściej bez bezpośredniego udziału Product Ownera, chociaż z jego wiedzą.
Tu jednak wracamy do samego początku tej wiadomości, czyli do wspólnego ustalenia, kto i za co odpowiada. Szczególnie warto to zaadresować, jeśli faktycznie PO jest/był (głównym) analitykiem. W takim przypadku mogą istnieć wyraźne tendencje do robienia wszystkiego samemu, bądź właśnie wyciągania analizy jako etapu przed pracami Zespołu Scrumowego. To zaś może się skończyć wspomnianymi już „osobnymi zespołami analitycznymi”, których nie polecam.
Samostanowienie się Product Ownera
Bardzo częstym pytaniem, które dostaję przy wielu różnych okazjach jest: „A co jeśli Product Owner uważa, że jest tylko i wyłącznie od zlecenia prac zespołowi?”
Taka sytuacja najczęściej ma miejsce, jeżeli nasze środowisko nie jest scrumowe i PO to tak naprawdę Procjet Manager z inną nazwą. Ale jeżeli jesteśmy „zwinni”, a problem występuje, to pewnie PO pełni tę funkcję dla kilku różnych zespołów bądź ma też masę innych rzeczy na głowie. Wtedy najzwyczajniej w świecie nie wystarcza czasu na jakiekolwiek przygotowanie backlogu poza wrzuceniem haseł.
Oczywiście w mojej historii miały miejsce i takie przypadki. Najczęściej było to spowodowane tym, że liczba zespołów rosła, a Product Owner zostawał jeden. I równie często kończyło się to tym, że w każdym zespole pojawiał się proxyPO, czyli osoba pełniąca obowiązki Product Ownera dla pewnego konkretnego zakresu biznesowego. Ten zakres wymagań naturalnie stawał się też specjalizacją danego zespołu, chociaż oczywiście najlepiej, gdyby wszyscy potrafili zrobić każde wymaganie z backlogu.
W takiej sytuacji PO odpowiadał za strategię, wizję i produkt, a poszczególni proxyPO za pewne obszary wymagań. Analogiczną konstrukcję z nieco innymi nazwami możemy znaleźć w podejściu LeSS (Huge), gdzie będziemy mieli Product Ownerów i Area Product Ownerów. Gorąco zachęcam do zapoznania się z tą propozycją, bo zakres obowiązków Area PO i „klasycznego” proxyPO się różni.
Nasz własny Product Owner i analityk
I tu dochodzimy do punktu, w którym tak naprawdę powinniśmy wypracować sobie swoje własne rozwiązanie. Czasami przydaje się „strategiczny” Product Owner, który na wysokim poziomie załatwi, co trzeba, a czasami lepiej jest mieć „operacyjnego” PO, który będzie zbierał wymagania i tworzył elementy Backlogu Produktu. Dużo zależy od wielkości organizacji, liczby zespołów, liczby produktów, którymi się zajmujemy i tak dalej.
Nie jest możliwe stworzenie jednego rozwiązania pasującego do każdego przypadku. Natomiast śmiało mogę stwierdzić, że sytuacja, w której nigdy nie usiedliśmy razem i nie porozmawialiśmy o odpowiedzialnościach za backlog i wymagania, jest sytuacją, która będzie generowała nieskończoną liczbę problemów.
Dlatego dzisiejszą wiadomość odbitą piłeczką. Tu nie chodzi o to „Jak ma być?”, tylko o to „Jak my chcemy pracować?”. I to jest coś, co wszyscy powinni przedyskutować i zgodzić się w każdym aspekcie.
