Wartość Produktu z perspektywy Product Ownera

Jako pierwsza zasada Manifestu Programowania Zwinnego widnieje „Najwyższy priorytet ma dla nas zadowolenie klienta dzięki wczesnemu i ciągłemu wdrażaniu wartościowego oprogramowania.” Dodatkowo w „Przewodniku po Scrumie” [2] jest napisane, że „Product Owner ponosi odpowiedzialność za maksymalizowanie wartości produktu będącego efektem pracy Scrum Teamu”.

Skoro wartościowe oprogramowanie stoi na czele manifestu agile, a głównym zadaniem Product Ownera jest dbanie o jego maksymalizację to dobrze rozumieć czym rzeczona wartość jest.

wartość ma wiele twarzy

[3] Słownik języka polskiego określa wartość jako: «to, ile coś jest warte pod względem materialnym»; «cecha tego, co jest dobre pod jakimś względem»; «posiadanie zalet». Mnogość definicji dobrze pokazuje, że wartość może być rozumiana w różny sposób. W procesie tworzenia Produktów również spotkamy się z różnymi definicjami.

Warto sobie uświadomić, że wartość zawsze zależy od kontekstu, dlatego Scrum Guide nie definiuje jej wprost. Czym innym będzie wartość dla klientów (Interesariuszy, którzy płacą za tworzenie produktu), czym innym dla użytkowników, a jeszcze czym innym dla organizacji.

[4] Artykuł „10 Tips for Product Owners on (Business) Value” dzieli wartość na wewnętrzną i zewnętrzną. Wewnętrzna wartość, to taka, którą dostarczamy wewnątrz organizacji. Zewnętrzna natomiast to ta, którą dostarczamy Klientowi lub użytkownikowi końcowemu. PO powinien zadbać o to, by znaleźć balans w dostarczaniu obu typów wartości.

Określ czym Dla produktu jest wartość

Od ogółu do szczegółu…

Dobrym punktem wyjściowym jest określenie wynikającego z wizji Celu Produktu i umieszczenie go na szczycie Product Backlogu. Ułatwi to tworzenie mindsetu produktowego w Zespole oraz organizacji [6] (ciekawe wnioski o wpływie mindsetu skupionego na wartości znajdziecie tutaj). Zdefiniowany wokół wartości Cel Produktu będzie zawsze drogowskazem i narzędziem ułatwiającym podejmowanie decyzji o realizowanych pracach. Przy tak określonym celu, kiedy prace zbliżają nas do jego osiągnięcia to najpewniej przynoszą też wartość.

Dobrze jednak wiedzieć jaka to będzie wartość, gdyż znacznie ułatwi to ustalenie miar umożliwiających jej weryfikacje po wdrożeniu. Warto wykonać klasyfikację wartości dla własnego Produktu, by jasno określić czym ona jest. Czytając artykuły spotkałam ciekawy podział wartości na typy. Osobiście, bardzo mi odpowiada metodyczne podejście do wartości.

Typy wartości

[5] Autorzy przeanalizowali różne backlogi i zaproponowali podział na 5 typów dostarczanej wartości:

Commercial Value czyli wartość komercyjna, dostarczana jest poprzez zapewnienie bezpośrednich przychodów organizacji, która wytwarza Produkt. Może być to na przykład nowy produkt w sklepie lub nowa płatna funkcjonalność.

Market Value czyli wartość rynkową, przynoszą te działania, które zwiększają liczbę osób świadomych istnienia Produktu. Najprostszym przykładem działań przynoszących ten rodzaj wartości są kampanie reklamowe, gdyż pozawalają one dotrzeć do większej liczby użytkowników i rynków. Z perspektywy rozwoju oprogramowania, może to być na przykład wytworzenie nowej funkcjonalności, realizowanej dla nowej grupy odbiorców, lub rozbudowanie produktu na inne platformy (np. z Androida na iOS)

Customer Value czyli wartość dla Klienta, która pomaga w utrzymaniu obecnego użytkownika przy Produkcie. Będą to wszystkie działania zwiększające jego atrakcyjność – łatwość obsługi, bezawaryjność, czy spełnianie nowych potrzeb istniejących użytkowników. Dobrym przykładem jest usprawnienie UX/UI.

Efficiency Value czyli wartość wydajności, którą przynoszą elementy oszczędzające czas i pieniądze w procesie wytwórczym przy utrzymaniu tej samej wartości dla użytkownika końcowego. Jest to głównie obniżanie kosztów wytworzenia, wdrażania i utrzymania produktu. Na przykład może być to zmiana w kodzie, która umożliwia obniżenie kosztów utrzymania środowiska produkcyjnego; lub automatyzacja żmudnych, powtarzalnych zadań; lub bardziej pośrednio – walka z długiem technologicznym, która powoduje stabilniejsze działanie Produktu, zmniejszając liczbę zgłoszeń do Help Desk w organizacji.

Future Value, przyszła wartość, uzyskiwana jest z pewnym przesunięciem w czasie. Spotykamy taką sytuację, jeżeli brak realizacji zadań może przynieść straty w przyszłości. Przykładem może być research innowacyjnych rozwiązań, aby nie pozostać w tyle za konkurencja; lub redukcja długu technicznego, który wpływać może na stabilność produktu w przyszłości.

Autorzy tego podziału podkreślają, że lista może nie być kompletna we wszystkich przypadkach. Jednak już podjęcie próby takiej kategoryzacji jest świetną możliwością do rozpoczęcia rozmowy o dostarczanej wartości z Interesariuszami i Zespołem. Jeżeli coś nie pasuje do żadnej z przedstawionych kategorii Product Owner powinien z duża starannością przemyśleć, czy element na pewno powinien pozostać w Backlogu.

Zmierz dostarczoną wartość

Podejmując decyzje o wykonywaniu elementów PB trzeba zastanawiać się jaką wartość dostarczamy. I choć trzeba to robić regularnie i dokładnie, to jednak nie warto poświęcać na to zbyt dużej ilości czasu, ponieważ wszystkie te działania to jedynie budowanie hipotez [4]. Dopiero wdrożenie ukończonego Przyrostu umożliwi nam pomiar realnie dostarczonej wartości [4,6]. Pisałam o tym w artykule o empiryzmie.

Dla każdego realizowanego elementu produktu warto określić typ wartości, który potencjalnie przyniesie, a także oczekiwany rezultat. Porządkując sobie w ten sposób Product Backlog, łatwiej będzie nam zdefiniować odpowiednie miary, które umożliwią walidacje naszych początkowych hipotez. O metodach definiowania miar opowiem w kolejnych wpisach.

Wdrażajmy nowe oprogramowania dla użytkowników i mierzmy dostarczoną wartość jak najwcześniej i jak najczęściej. Analizujmy wyniki pomiarów. Uczymy się i wyciągajmy wnioski, umożliwiające podejmowanie lepszych decyzji dotyczących rozwoju produktu.

Zmieniaj definicje wartości

[4] W zależności od tego na jakim etapie rozwoju znajduje się Produkt i co realizujemy, wartość może mieć różne oblicza. Wraz ze zmianą definicji wartości, zmieniać się będą również jej miary. Warto cyklicznie weryfikować, czy to co mierzymy, wciąż ukazuje nam wartość, na której nam zależy.

Wyobraźmy sobie, że tworzymy aplikację mobilną. Po pierwszym wydaniu aplikacji, główną wartością może być informacja czy są osoby zainteresowane produktem. Liczba pobrań aplikacji może być dobrą miarą obrazującą oczekiwany rezultat.

Wiedząc, że jest popyt na produkt, istotne staje się, czy użytkownicy rzeczywiście korzystają z aplikacji. Średni czas spędzony przez użytkowników na korzystanie z aplikacji może nam ukazać tę wartość.

W dalszych etapach rozwoju aplikacji, istotniejsze może stać się utrzymanie obecnych klientów. Dobrą miarą badającą zadowolenie użytkownika i umożliwiającą dokładną analizę, może być na przykład NPS – Net Promoter Score.

PODSUMOWANIE

Wartość może mieć wiele obliczy, które w dużej mierze zależą od kontekstu. Product Owner powinien być świadomy różnych perspektyw, by móc globalnie maksymalizować wartość Produktu. Uzmysłowienie sobie różnych rodzajów wartości dostarczanych przez Produkt, ułatwi zdefiniowanie odpowiednich miar. Zakładając, że dopiero wdrożenie dostarcza realną wartość, to właśnie miary i ich analiza pozwalają walidować początkowe hipotezy. Tylko taki, empiryczny proces pozwala wyciągać sensowne wnioski na przyszłość i tworzyć bardziej wartościowe Produkty.