Blog

Pojawia się już trzecia odsłona wywiadu z Andrzejem Brandtem na temat zadań i roli Product Ownera w jego codziennej pracy. W tej części omawiamy częste problemy w pracy Product Ownera, takie jak: wchodzenie nie w swoje role, niespójność pracy PO z oczekiwaniami klientów i biznesu oraz łączenie modelu tradycyjnego zarządzania z Agilowym Product Ownerem.

Problemy Product Ownera…

Nie da się ukryć, że zdarzają się przypadki wchodzenia Product Ownera w rolę Scrum Mastera i odwrotnie. Często się z tym spotykasz? Jakie idą za tym konsekwencje?

Na szczęście to jest relatywnie rzadkie. O ile bardzo często spotykam się z łączeniem roli developera i Scrum Mastera (co czasem się sprawdza świetnie a czasem jest fatalne), o tyle na szczęście rzadko spotykam się z rzeczywistym łączeniem roli Product Ownera i Scrum Mastera. Myślę, że wynika to z dość powszechnego zrozumienia, że choć role te są komplementarne zawierają w sobie inherentną sprzeczność interesów. Product Owner chce zrobić jak najwięcej, jak najlepiej w każdej iteracji – Scrum Master pilnuje procesu, jakości, zdrowia zespołu. Jest zdecydowanie lepiej, kiedy nie rozgrywa się ona w głowie jednej osoby lecz jest uzewnętrzniona, kiedy dwoje ludzi może otwarcie te stanowiska reprezentować i wypracowywać jakiś wspólny modus operandi.

Wiemy, że Produkt i praca nad nim to jedno, a oczekiwania idące od klientów i szefostwa firmy to drugie. Co najczęściej polecasz Product Ownerom w tych nierównych przepychankach?

Opieranie się o prawdę, o fakty.

Trudny do przełknięcia fakt jest taki, że zakres tego co zespół jest w stanie wykonać w danym czasie nie jest z gumy. Jest to określona wielkość możliwych do wprowadzenia zmian – nowych funkcjonalności, poprawek starych czy usuwania błędów. Rzeczywistości tej nie da się zmienić bez konsekwencji, złudzeniem jest przekonanie, że naciskiem, straszeniem czy nagrodami finansowymi można spowodować istotne poszerzenie wykonywalnego zakresu bez obniżenia jakości i gromadzenia się długu technicznego.

Wielkość wykonywalnego zakresu nie jest w pełni przewidywalna z góry, choć można poczyniwszy pewne obserwacje stawiać przyzwoite prognozy co do jej wielkości. Zadaniem Product Ownera jest takie dobieranie wymagań aby w obrębie tego wykonywalnego zakresu znalazły się wszystkie krytyczne dla produktu rzeczy. Wówczas kolejne wydania produktu rzeczywiście dostarczają wartości.

Trzeba tą rzeczywistość – zarówno ograniczoności możliwości zespołu czy zespołów jak i roli Product Ownera – cierpliwie tłumaczyć, uświadamiać. Pożyteczna jest tutaj metafora „długu technicznego” – zrozumienie jak on działa pozwala osobom nie posiadającym wiedzy technicznej zrozumieć jakie długofalowe konsekwencje ma robienie rzeczy „na już”, a w konsekwencji podejmować lepsze decyzje. Podobnie wyjaśnienie – a co najważniejsze pokazanie w praktyce – na czym polega empiryczne podejście do rozwoju produktu pomaga interesariuszom lepiej rozumieć w czym biorą udział i jak mogą na to wpływać.

Jest również dobrym pomysłem włączanie interesariuszy w przeglądy produktu po każdym sprincie oraz dyskusje nad kolejnością wymagań na backlogu. Dzięki wiedzy o wymaganiach innych, ich potrzebach i oczekiwaniach, interesariusz ma szanse lepiej rozumieć podejmowane przez Product Ownera decyzje w stosunku do „jego” wymagań.

Jak według Ciebie można połączyć zadania Product Ownera z tradycyjnym zarządzaniem projektami? Czy widzisz sens w takim postępowaniu?

Często się zdarza, że stworzenie jakiegoś oprogramowania lub wprowadzenie w nim zmian jest tylko częścią większego przedsięwzięcia – czy właśnie projektu – którego inne elementy mogą być nawet zupełnie nie związane z oprogramowaniem czy szerzej działalnością twórczą. Nie ma wówczas żadnych przeszkód by tymi pozostałymi elementami – czy nawet całym przedsięwzięciem – zarządzać z użyciem na przykład zarządzania projektami w oparciu o „Project Management Body of Knowledge„.

Często tak się zresztą dzieje, Product Manager występuje wtedy przed zespołem właśnie jako Product Owner. Od drugiej strony obszar związany z oprogramowaniem widać w planie projektu jako ten obszar, w którym (odmiennie niż gdzie indziej) czas jest niezmienny (ustalony), jakość jest ustalona a zakres się zmienia.

Przejdź do części IV