Product Owner odpowiedzialny jest za „maksymalizowanie wartości produktu”. Chociaż niektórzy wolą formę „maksymalizację”, a jeszcze inni PO nazywają Właścicielem Produktu. To jednak detale, dziś rozłożymy tę odpowiedzialność na czynniki pierwsze.
Co maksymalizuje Product Owner?
Jeżeli sięgniemy do oryginalnego Scrum Guide’a, to przeczytamy tam m.in. „The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team.” W wolnym tłumaczeniu, PO jest odpowiedzialny za maksymalizowanie wartości produktu, który jest rezultatem prac Zespołu Deweloperskiego.
To już wiemy i pisaliśmy o tym wielokrotnie. Mówiliśmy o wartości Rejestru Produktu, częściej zwanego backlogiem. Pokazywaliśmy nawet jak ująć tę wartość liczbowo w postaci Value Points oraz czym różni się ona od priorytetu. Zainteresowanych technicznymi aspektami „maksymalizowania wartości produktu” poprzez backlog, odsyłamy do wspomnianych tekstów. Dziś będzie zupełnie o czym innym.
Zanim jednak przejdziemy do meritum, zerknijmy w jeszcze jedno miejsce, a mianowicie na polskiego Scrum Guide’a, czyli „Przewodnik po Scrumie: Reguły gry”. Zacytowane powyżej zdanie zostało przetłumaczone na „Właściciel Produktu jest odpowiedzialny za maksymalizację wartości produktu i pracy Zespołu Deweloperskiego.”
Abstrahując już od nazywania Product Ownera Właścicielem Produktu, tłumaczenie sugeruje, że PO zajmuje się dwiema rzeczami. Jedną z nich jest oczywiście tytułowa maksymalizacja wartości produktu, ale drugą – maksymalizacja wartości prac Zespołu Deweloperskiego. Niby chodzi o to samo, ale trochę zmienia nam optykę.
Co ma PO do Development Team?
„Maksymalizowanie wartości prac Zespołu Deweloperskiego” może niektórym zasugerować, że PO powinien wchodzić z butami w codzienne życie zespołu i tłumaczyć/pomagać im w efektywnej pracy. Na nasze nieszczęście właśnie tak niektórzy PO widzą swoją rolę i zaczynają uprawiać ciężki mikromanagement, aby zadbać o wspominaną wartość prac.
To ja już chyba wolę, gdy PO patrzy na „maksymalizowanie wartości produktu, który jest rezultatem prac Development Teamu” przez pryzmat zarządzania backlogiem. No bo nie oszukujmy się, to, co PO umieści na samym szczycie listy wymagań, to zespół będzie realizował w pierwszej kolejności. A więc jakoś pośrednio steruje w ten sposób tym, co zespoły robią.
Aby oddać sprawiedliwości pomocnym PO, nie każda interwencja czy próby wpłynięcia na sposób pracy zespołu są złe. Zdarza się, że PO faktycznie ma dobre pomysły, wspiera zespół i pomaga im w efektywnym osiągnięciu celu. Zdrowy rozsądek mówi, że takie sytuacje jak najbardziej są ok.
Ale w dalszym ciągu nie o to nam chodzi w dzisiejszym tekście.
Maksymalizowanie wartości produktu
Powiedzieliśmy już sobie, że w tej całej maksymalizacji nie chodzi o sterowanie pracami zespołu. Nie mamy na myśli „technicznego” zarządzania backlogiem. Samo upewnianie się, że najbardziej wartościowe elementy Backlogu Produktu są na jego szczycie, to za mało. O wiele ważniejsze jest to, czego na liście wymagań w ogóle nie ma.
„Tu jest lista wymagań, tu jest zespół, a tu masz termin. A teraz zarządzaj tym tak, żeby się wyrobić.”
Zbyt często rola PO jest sprowadzana do „sekretarki backlogu”. Niby mamy jakiś zakres, który nawet możemy „maksymalizować” chociażby decydując o tym, jak wyznaczyć MVP. Ale to jeszcze nie to. Ciągle nie jesteśmy „właścicielem” tego produktu, tylko realizujemy czyjąś wizję. Decydujemy o kolejności, ale nie o wartości.
Napisałem, że często najważniejsze jest to, czego w backlogu nie ma. Bo „maksymalizowanie wartości produktu” to takie jego konstruowanie, żeby odpowiadał on potrzebom naszych odbiorców i był atrakcyjny na rynku, na którym walczymy. I jeżeli pojawi się jakaś szansa albo nowy pomysł, to powinniśmy z niego skorzystać. Nawet, jeżeli odpowiadających mu wymagań jeszcze w backlogu nie ma.
Co więcej, dobry Product Owner będzie aktywnie szukał tych szans, wymyślał nowe rzeczy i sterował rozwojem produktu tak, aby faktycznie zmaksymalizować jego wartość. To znaczy, że czasami trzeba będzie zmienić wymagania, a czasami w ogóle zmienić kierunek rozwoju.
Zwróćcie uwagę, że PO nie zajmuje się „wartością backlogu”, tylko „wartością produktu”. A to znaczy, że samo układanie PBI-ów nie wystarczy. To właśnie zawartość naszej listy wymagań jest tu kluczowa. Bo świat pędzi, rzeczywistość się zmienia i realizowanie wymagań z przed dwóch lat „bo w końcu nadszedł na nie czas” to nie zawsze jest najlepszy wybór. I może zdarzyć się tak, że wywrócimy nasz backlog do góry nogami, bo maksymalna wartość pojawiła się gdzieś indziej. I dobrze.
Maksymalizujmy wartość produktu, nie oglądając się na to, co już jest w backlogu. Przecież wszyscy wiemy, że backlog to nie jest nasze zobowiązanie względem klienta ani tym bardziej obietnica. Prawda?
