Zaawansowani Właściciele Produktu

Autorzy tekstu: Tom & Kai Gilb
Przekład: Tomasz Piętka, Anna Maria Karłowska

Od tłumaczy:

Tom Gilb i Kai Gilb tworzą kompleksowe, zwinne metodyki wytwarzania oprogramowania od lat. W szerokiej opinii (łącznie z opinią samych autorów) opisy metod w postaci książkowej nie są lekturą łatwą. Seria artykułów “Gilb Mythology Column” ma w przystępny sposób przybliżyć koncepcje zawarte m.in w pozycjach “Value Planning” oraz “Competitive Engineering” szerokiej publiczności. W tych publikacjach autorzy krytycznym okiem analizują mity dotyczące zwinnego wytwarzania oprogramowania utarte w świadomości osób związanych z branżą. Niniejszy artykuł nie jest ostateczną krytyką koncepcji “Pojedynczego Właściciela Produktu” pochodzącej z metodyki Scrum i szeroko stosowanej w obecnym świecie. Autorzy wskazują tutaj luki i niedoskonałości w stosowanych w rzeczywistości implementacjach tej koncepcji.

Zaawansowani Właściciele Produktu

W projektach, w których występują złożone wymagania jakościowe oraz wynikająca z nich skomplikowana architektura rozwiązania, tradycyjnie zdefiniowana rola Właściciela Produktu (Product Owner, PO) jest niewystarczająca aby dostarczyć odpowiedni poziom jakości i wydajności produktu.

Projekty, o których mowa w tym artykule to duże, poważne przedsięwzięcia rządowe lub korporacyjne na szeroką skalę. W niniejszym artykule nie bierzemy pod uwagę mniejszych projektów, lub projektów w których nie występują wielopoziomowe zależności pomiędzy jakością, efektywnością oraz kosztami. Pod uwagę bierzemy projekty, w których złożoność przekracza próg, w którym metody odpowiednie dla projektów mniejszych przestają działać. Można to porównać do próby zastosowania metod budowniczego małego domku jednorodzinnego, które nie zadziałają dla 200 piętrowego drapacza chmur.

Wskaźnik niepowodzenia projektów prowadzonych metodyką Scrum wynosi około 19% i dzięki wbudowanym w tę metodykę procesom zbierania szybszej informacji zwrotnej, ten wskaźnik jest lepszy w porównaniu do projektów prowadzonych metodami kaskadowymi (ang. “waterfall” – wodospad), który wynosi 40% [3]. Jednak jeśli porównamy problem do wypadku drogowego na przejściu dla pieszych – zabicie tylko jednej z pięciu osób w porównaniu do dwóch z pięciu będzie wciąż wynikiem niedopuszczalnym. Wspomniany wskaźnik niepowodzenia projektów IT powinien wynosić 0% i należy do takiego wyniku dążyć. W dzisiejszych czasach często powtarzanym dogmatem jest to, iż konwencjonalnie zdefiniowana rola Właściciela Produktu (ang. Product Owner) jest uniwersalna i skaluje się na każdy typ projektu. Powinniśmy lepiej zrozumieć ograniczenia obecnego dogmatu oraz zidentyfikować praktyki odpowiednie dla metodyk zwinnych (ang. Agile Software Development) w bardziej wymagających przedsięwzięciach.

Poniżej przytaczamy mity na temat roli Właściciela Produktu (http://www.mountaingoatsoftware.com/agile/scrum/roles/product-owner). Nasze komentarze przedstawiają pokrótce inny punkt widzenia – z perspektywy wymagających projektów. Ten zabieg nie pozwoli nam na szczegółową argumentację, ale referencje powinny pomóc tym, którzy potrzebują bardziej dogłębnych informacji. Celem tej sekcji jest otwarcie debaty na temat roli Właściciela Produktu oraz zadań jakie są związane z prawidłowym wypełnianiem tej roli.

Mit Pierwszy:

Właściciel Produktu w metodyce Scrum jest zwykle głównym interesariuszem projektu.

[1] Właściciel Produktu w rzeczywistości musi sprawować co najmniej trzy bardzo odrębne funkcje, które są dobrze zrozumiane w projektach IT wykonywanych na szeroką skalę:

• Inżynieria wymagań;
• Inżynieria architektury;
• Dynamiczna priorytetyzacja;

Inżynieria Wymagań: to NIE zadania związane z pisaniem User Stories. Jest to przede wszystkim kwestia wyspecyfikowanych i opisanych liczbowo wysokopoziomowych, głównych czynników wpływających na projekt [5]: wartości takich jak bezpieczeństwo, użyteczność, zdolność do adaptacji produktu [4], ograniczeń projektowych (przypis tłumacza tj. harmonogramu, zasobów, zakresu) oraz wymagań związanych z wydajnością. Metodyka Scrum oraz inne popularne obecnie zwinne metodyki wytwarzania oprogramowania pomijają zadania i etapy związane z doprecyzowaniem wymagań, czyli inżynierią wymagań.

Rys. 1 Skala kwantyfikacji

Rys. 2 Abstract Strategy model

Osoba pełniąca funkcję Zaawansowanego Właściciela Produktu w złożonych projektach musi być zdolna do zarządzania wielorakimi wysokopoziomowymi i krytycznymi celami na przykład dotyczącymi usprawniania wydajności, równocześnie zarządzając wielorakimi zasobami i ograniczeniami. Prosta specyfikacja w postaci User Stories czy mierzenie wydajności zespołu w postaci jedynie Burn Down chart (przypis tłumacza – Wykres Wypalenia mierzący stopień realizacji zadań przyjętych przez zespół do realizacji w iteracji) nie jest wystarczająca.

Inżynieria Architektury: to proces odnajdywania zestawu wysokopoziomowych rozwiązań technicznych, które prawdopodobnie dostarczą pożądany poziom jakości i wydajności produktu, który został opisany w procesie tworzenia listy wymagań (inżynieria wymagań) określających cechy produktu, które da się przetestować. Rozwiązania powinny być weryfikowane w każdej iteracji dostarczania projektu poprzez mierzenie dostarczanej wartości oraz kosztów. Metodyka Scrum oraz inne popularne obecne zwinne metodyki wytwarzania oprogramowania pomijają zadania i etapy związane z projektowaniem rozwiązania technicznego czyli inżynierii architektury.

Dynamiczna Priorytetyzacja [7]: czyli decydowanie o kolejności wykonania prac. Jak odpowiednio wykonać priorytetyzację wykonywanych prac? Absolutnie nie poprzez opisywanie priorytetów, poprzez przypisywanie do nich wag lub prostych wartości liczbowych. Priorytety powinny być dynamicznie i ciągle obliczane oraz powinny bazować na wartościach, zasobach i ryzykach projektu. Poniżej kilka uwag odnośnie obecnie używanych metod nadawania priorytetów:

• Wagi Priorytetów (jak w metodzie Zrównoważonej Karty Wyników, ang. Balanced Scorecard) są złymi i niebezpiecznymi metodami pochodzącymi z metodyk kaskadowych. Aby przetrwać i osiągnąć sukces potrzebujemy zwinnej priorytetyzacji bazującej na szybko zmieniających się faktach.
• Metoda MOSCOW, której założenia są odpowiednie, jest zbyt statyczna na warunki zwinnego wytwarzania oprogramowania. Bardziej zaawansowane metody takie jak “Impact Estimation Table” lub “Quantified Value Requirements” powinny być użyte, aby odpowiednio zrozumieć priorytety.
• Należy wprowadzić dużo bardziej zaawansowaną kulturę analizy interesariuszy. W trakcie prowadzenia skomplikowanych projektów musimy zanalizować około 40 różnych interesariuszy projektu oraz wiele potrzeb, które każdy z nich ma. Pod lupę należy wziąć potrzeby, które są sprzeczne z potrzebami innych, oraz takie, które z siebie wynikają.

Mit Drugi:

Częścią obowiązków Właściciela Produktu jest posiadanie wizji tego, co należy zbudować oraz komunikowanie tej wizji zespołowi Scrumowemu [1].

Duże projekty mają 40 lub więcej interesariuszy, z których każdy ma po kilka swoich wymagań. Żadna pojedyncza osoba nie jest w stanie znać kompletnej wizji produktu oraz być w pełni za nią odpowiedzialna. W najlepszym wypadku pojedynczy Inżynier Wymagań (lub Analityk Biznesowy, lub bardziej prawdopodobnie – zespół) może zbierać, specyfikować, zatwierdzać  i wyjaśniać iteracyjnie informacje przychodzące od interesariuszy, w miarę trwania projektu. Następnie należy te informacje przeformułować w jasną i testowalną specyfikację.

Mit Trzeci:

Właściciel Produktu jest kluczem potrzebnym do rozpoczęcia każdego projektu prowadzonego zgodnie z metodykami zwinnymi.

Istnieje wiele metod rozpoczęcia oraz zakończenia z sukcesem projektu prowadzonego zgodnie z metodykami zwinnymi. Właściciel Produktu wyposażony w User Stories nie jest kluczowym zasobem w przypadku projektów prowadzonych na dużą skalę [2]. Najważniejszym działaniem (jest ich jednak wiele więcej) w naszej opinii jest ustalenie wymiernych, najważniejszych dziesięciu usprawnień, które projekt dostarczy odpowiadając na podstawowe potrzeby interesariuszy wyrażone poprzez wartości takie jak bezpieczeństwo, czy np. skalowalność produktu, użyteczność [5]. User Stories są w rzeczywistości jednym z wielu formatów opisu wysokopoziomowych wartości. Zadania Właściciela Produktu opisane w metodyce Scrum nie zbiegają się z wyżej opisaną koncepcją.

Mit Czwarty:

Właściciel Produktu (PO) w metodyce Scrum posługuje się Rejestrem Wymagań (ang. Product Backlog), listą wymagań której nadano priorytety.

Inteligentna priorytetyzacja w skomplikowanych systemach na szeroką skalę jest wysoce dynamicznym procesem, który jest zależny od wielu czynników [7]. Analityk Biznesowy może w najlepszym przypadku zbierać różnorodny zestaw informacji, który może być użyty do określenia priorytetów na kolejną iterację. Wartość i koszt zakończonej iteracji (w skwantyfikowanej formie), muszą zostać wzięte pod uwagę przy określaniu aktualnych priorytetów. Twierdzimy, iż ta informacja zwrotna uzyskana z arkuszy (przypis tłumacza: impact estimation table) powinna być używana do obliczania aktualnych priorytetów. Przydatnym narzędziem jest “Impact Estimation Table”. Właściciel Produkt nie jest konieczny w przeciwieństwie do kluczowych faktów i miar postępu.

Rys 3. Impact Estimation Table

Mit Piąty:

Właściciel Produktu jest głównym użytkownikiem systemu. Alternatywnie Właściciel Produktu jest osobą z marketingu albo działu zarządzania produktem lub kimkolwiek z solidnym zrozumieniem użytkowników systemu, rynku, konkurencji oraz przyszłych trendów domeny lub rodzaju systemu w produkcji.

Dla małych projektów, powyższe stwierdzenie może być prawdziwe. W dużych i złożonych projektach potrzebujemy profesjonalnych inżynierów, którzy posiadają kompetencje w obszarze zbierania wymagań. Ich zadaniem jest zebranie i opisanie wszystkich kluczowych wymagań interesariuszy oraz, wraz z architektem systemu, stworzenie odpowiedniej architektury dla budowanego produktu.

Mit Szósty:

Właściciel Produktu w metodyce Scrum motywuje zespół jasnym celem [1].

W przypadku projektów, których cel nie jest złożony czyli prosty do osiągnięcia ta koncepcja może być odpowiednia. W złożonych projektach (sytuacji dużej niepewności) zawsze występuje zestaw kluczowych celów, stąd motywacją powinno być ich osiągnięcie. Obawiamy się, iż ta czynność leży w kompetencjach osoby pełniącej rolę Menadżera Projektu (ang. Project Manager), która powinna być (i często jest) pełniona przez inną osobę. Zgadzamy się jednak, iż motywowanie zespołu jest istotne.

Mit Siódmy:

Członkowie zespołu wiedzą najlepiej, do czego są zdolni, więc sami wybierają,  wytworzenie których User Stories (przypis tłumacza – w oryginale występuje znaczne uproszczenie – w rzeczywistości zespół pracuje nie tylko nad User Stories, które są jedną z form opisu wymagań funkcjonalnych, ale również m.in. nad defektami, wymaganiami niefunkcjonalnymi oraz nad analizą – tzw. “spikes”) z wysokich pozycji listy backlogu mogą się zaangażować i dostarczyć w każdym sprincie [1].

Zgadzamy się, iż zespół deweloperski najlepiej rozumie swoje zdolności dostarczania w trakcie sprintu. Właściciel Produktu nie powinien być zaangażowany w ten proces. (Przypis tłumacza: W tym punkcie autorzy nie obalają dogmatu, ale dla zachowania ciągłości wywodu odnoszą się do oryginału.)

Mit Ósmy:

Od osoby pełniącej rolę Właściciela Produktu wymaga się odpowiednich kompetencji i cech, jak również dostępność, zrozumienie biznesu i zdolności komunikacyjne. Po pierwsze, Właściciel Produktu musi być dostępny dla swojego zespołu deweloperskiego. Najlepsi Właściciele Produktu robią wszystko, co jest konieczne aby zbudować najlepszy możliwy produkt – to oznacza, że aktywnie uczestniczą w działaniach swojego zespołu.

Dla większych projektów koncepcja pojedynczego Właściciela Produktu jest niedoszacowana. Kompetencje, które Właściciel Produktu powinien posiadać to połączenie zdolności do analizy wymagań wielu interesariusz, umiejętności projektowania architektury rozwiązania oraz kompetencji technicznych polegających na dopasowaniu odpowiedniej technologii, tak aby było możliwe dostarczenie wartości interesariuszom. Jest to opis kompetencji wysoko wyspecjalizowanego zespołu. W obecnie zdefiniowanej roli Właściciela Produktu nie znajdziemy powyższych kompetencji i ekspertyzy potrzebnych do wykonywania tej pracy w złożonych projektach.

Mit Dziewiąty:

Zrozumienie biznesu jest ważne dla Właściciela Produktu, ponieważ to on/ona podejmuje decyzje odnośnie funkcjonalności budowanego produktu. To oznacza, iż Właściciel Produkt powinien rozumieć rynek, klientów i biznes aby podejmować odpowiednie decyzje [1].

To jest kompetencja i zakres wiedzy zespołu marketingu, który jest jednym z interesariuszy złożonych projektów.

Mit Dziesiąty:

Ostatecznie, komunikowanie stanowi dużą części zadań przypisanych Właścicielowi Produktu. Od osoby pełniącej rolę Właściciela Produktu wymaga się bliskiej współpracy z kluczowymi interesariuszami w organizacji oraz poza nią. Stąd on/ona musi być zawsze zdolna do przekazywania informacji związanych z projektem różnym, zainteresowanym osobom.[1].

Ma to sens, ale musimy nauczyć się komunikować krytyczne wartości, które stanowią 70% wszystkich wartości interesariuszy. Obecna kultura związana z wypełnianiem roli Właścicieli Produktu wraz z kulturą opartą na wykorzystaniu User Stories jako pełnowartościowej specyfikacji nie uznaje za zasadne wypełnianie wyżej wymienionych zadań. Jest ona zbyt nastawiona na dostarczanie kodu i funkcjonalności. Potrzebujemy kultury, której głównym założeniem będzie uznanie, iż kod nie jest centrum wszechświata. Powinniśmy się skupić na budowaniu systemów i dostarczaniu wartości interesariuszom. Obecny model roli Właściciela Produktu i User Stories jest niebezpiecznie niewystarczający do wypełnienia tego zadania z należytą starannością. Jeśli ludzie zrozumieją granice swoich koncepcji, oraz to że potrzebujemy kultury inżynierskiej (czyli używania naukowych i matematycznych metod w procesie budowania narzędzi IT) aby dostarczać duże, złożone produkty, wierzymy że nasz zawód może przybliżyć się w stronę dostarczania rozwiązań nie posiadających błędów.

Who you gonna call! The Myth Busters!

Tom and Kai Gilb www.gilb.com

Przeczytaj oryginalny tekst

Referencje:

1. http://www.mountaingoatsoftware.com/agile/scrum/roles/product-owner
2. User Stories: A Skeptical View, Agile Record 2012, www.gilb.com/dl46
3. Jeff Sutherland’s ABE Warsaw video, 2014, https://www.youtube.com/watch?v=YUaywvsfe78
4. Chapter 5: Scales of Measure: http://www.gilb.com/dl26
5. The Top 10 Critical Requirements are the Most Agile Way to Run Agile Projects, Agile Record August 2012. https://www.agilerecord.com/agilerecord_11.pdf
6. Agile Architecture Engineering: Dynamic Incremental Design Selection and Validation, Agile Record, Nov 2013 Issue 13. https://www.agilerecord.com/agilerecord_13.pdf
7. Managing Priorities, http://www.compaid.com/caiinternet/ezine/gilb-managingpriorities.pdf

O tłumaczach: 

Tomasz Piętka, analityk biznesowy z wieloletnim doświadczeniem, zarówno w budowaniu skomplikowanych produktów IT na szeroką skalę jak i mniejszych, dostarczanych w krótkich okresach czasu (do 6 miesięcy). Entuzjasta zwinnych metodyk wytwarzania oprogramowania oraz wszelkich metod inżynierii wymagań. Ukończył Ekonomię z tytułem magistra oraz Informatykę Stosowaną z tytułem inżyniera na renomowanych polskich uczelniach.

Anna Maria Karłowska, analityk biznesowy i projektant produktów, ma doświadczenie w pracy ze startupami oraz w środowisku bardziej korporacyjnym, gdzie projekty były dostarczane za pomocą zwinnych metodyk. Zajmuje się również stosowaniem zwinnych metodyk w urbanistyce.