Blog

W pierwszej części artykułu omówiłem sam koncept wartości oraz czym jest „wartość biznesowa”. Wyjaśniłem też pojęcia outputu, outcomu i impactu. Są one ważne, bo definiując miary wartości musimy rozumieć, czym ona jest w kontekście naszego produktu.

W tej części pora przyjrzeć się uważniej samym miarom. Omówię też kilka przykładów – zarówno sensownych, jak i tych mocno dyskusyjnych.

Rodzaje miar

Jeśli już zrozumiemy, czym w przypadku naszego produktu jest output, czym outcome, a czym impact, możemy zacząć definiować miary. Zanim jednak to zrobimy, warto zdać sobie sprawę z dwóch sposobów, w jakie te miary mogą być używane.

Jedna grupa miar pozwoli nam zrozumieć, jaki jest obecny stan spraw poprzez ujawnienie skutków tego, co już się stało. Miary te stanowią lagging indicator, ponieważ możemy je zebrać dopiero po zaistnieniu jakiegoś zdarzenia (w naszym przypadku: po wprowadzeniu zmiany do produktu). To opóźnienie (do tego odnosi się słówko lagging) nie pozwala oczywiście na reakcję, która skutecznie zapobiegłaby znalezieniu się w niepożądanym miejscu.

Można więc powiedzieć, że takie „opóźnione wskaźniki” (to paskudne dosłowne tłumaczenie) są użyteczne i potrzebne, ale mają ograniczoną wartość przy sterowaniu procesem, bo ten już się zakończył. Są przydatne do podejmowania decyzji o tym, co robić dalej, zwłaszcza jeśli posługujemy się empiryczną kontrolą procesu i szukamy sposobu zapewnienia niezbędnej do tego przejrzystości.

Przykładem lagging indicatora jest np. EBITDA przedsiębiorstwa. Pokazuje stan finansów firmy, ale nie daje możliwości zmiany decyzji, które już zostały podjęte, i których skutki już się objawiły.

Druga grupa miar pozwala nam prognozować (z ograniczonym prawdopodobieństwem), czy uzyskanie pożądanej wartości lagging indicatorów jest możliwe, czy też zaczynamy się od tego oddalać. Miary takie stanowią leading indicator, ponieważ wskazują na trendy i pozwalają sterować procesem.

Takie „wskaźniki wyprzedzające” (znów paskudne dosłowne tłumaczenie) nie dają pewności, jak będzie, ale umożliwiają reakcję, jeśli trend zmian wartości tych miar wskazuje na istnienie jakiegoś problemu. Lub jeśli trend ten ujawnia nowe możliwości, z których możemy skwapliwie skorzystać.

Przykładem leading indicatora jest ilość zapytań od użytkowników, którzy nie radzą sobie z korzystaniem z produktu. Jeśli wartość takiej miary zaczyna być coraz wyższa, rośnie prawdopodobieństwo, że zdecydują się zrezygnować z opłacania subskrypcji.

Innym przykładem może być częstotliwość, z jaką udaje się udostępniać nowe funkcjonalności produktu użytkownikom: jeśli zaczyna ona spadać, prawdopodobnie proces developerski „zaciera się”, a od pewnego momentu przestanie być możliwe szybkie reagowanie na potrzeby użytkowników.

Przykładem bardziej pozytywnym może być rosnący NPS, który wskazuje, że najprawdopodobniej rozwijamy produkt zgodnie z oczekiwaniami użytkowników.

Jak więc widać, leading indicator podpowiada, jak może być, a lagging indicator pozwala zrozumieć, jak jest teraz i co się już stało. Czasami możliwe jest użycie jednego wskaźnika w obu funkcjach, jeśli interesuje nas zarówno wartość jak i trend zmian tej wartości. Wspomniany wcześniej NPS często jest używany w ten właśnie sposób.

Przykłady miar wartości

Miarą wartości dla użytkownika mogą być oceny w systemach ratingowych (np. w „sklepach” z aplikacjami na urządzenia mobilne). Może nią być odsetek użytkowników odnawiających subskrypcję. Może być ilość nowych użytkowników, którzy decydują się na zakup produktu dzięki poleceniu od kogoś, kto już z niego korzysta. Ale może taką miarą być również niska ilość problemów, jakie użytkownicy zgłaszają i ograniczona potrzeba wspierania ich przy korzystaniu z produktu. Albo wysoki poziom dostępności, bezpieczeństwa i stabilności usług, mierzony ilością zarejestrowanych incydentów.

Miarą wartości dla klienta może być ilość długoterminowych umów na świadczenie usług na rzecz pracowników tego klienta (pracownicy ci będą użytkownikami). Może być taką wartością czas reakcji na zgłoszony problem z działaniem produktu lub zapytanie o nową funkcjonalność. Innym przykładem miary jest łatwość instalacji i konfiguracji produktu, odzwierciedlona czasem niezbędnym do wykonania takich prac lub kosztem utrzymywania specjalistów, którzy je wykonują.

Dla twórcy produktu miarą wartości może być całkowity koszt utrzymania produktu, uwzględniający nie tylko jego rozwój, ale również podtrzymywanie rozwiązania w działaniu. Może być taką miarą procentowy udział w rynku albo czas wdrożenia rozwiązań (time to market), który pozwala skutecznie reagować na zmiany rynku.

Oczywiście to tylko przykłady, do tego dość ogólne. Nie ma „uniwersalnych miar wartości”, które pasowałyby do każdego produktu. Dlatego trzeba najpierw zrozumieć, kto jest użytkownikiem, kto klientem i co jest dla nich wartością tak, jak pisałem w pierwszej części artykułu. Dopiero nakładając na to potrzeby twórcy produktu, da się skutecznie definiować miary, pamiętając zawsze, by patrzeć na impact lub przynajmniej outcome, a niekoniecznie na output, który jest zaledwie potencjalnie nośnikiem wartości.

Sporo przykładów miar, jakimi można się posługiwać, znaleźć można w przewodniku opisującym Evidence-Based Management (dokument w języku angielskim). Oczywiście nie wszystkie zaproponowane tam miary nadają się do określenia wartości i nie wszystkie będą pasować do specyficznych produktów.

Przykłady marnych miar wartości

Często spotykanym błędem przy definiowaniu miar jest mylenie wartości z produktywnością zespołów. Zaczyna się mierzyć ilość wyprodukowanych funkcjonalności bez sprawdzenia, czy są one rzeczywiście potrzebne i podnoszą wartość dla użytkowników lub klientów. Niektóre organizacje dążą do uzyskania jak najwyższego velocity w przekonaniu, że im ono wyższe, tym większą wartość da się uzyskać – co również jest nieporozumieniem. Możemy wszak szybko budować rzeczy zbędne lub wręcz szkodliwe.

Nie jest dobrą miarą wartości time to market, jeśli definiujemy tę miarę jako „czas od zidentyfikowania potrzeby do udostępnienia produktu odpowiadającego na tę potrzebę użytkownikom i klientom”. Dlaczego? Bo rozwiązanie, jakie zostało wytworzone, może być niewłaściwe. Dlatego time to market powinien być raczej definiowany jako „czas od zidentyfikowania potrzeby do jest skutecznego zaspokojenia”.

Fatalnym, a wcale nierzadkim pomysłem, jest mierzenie wartości przez policzenie, ile godzin zostało zużytych na wyprodukowanie produktu. Fatalnym, bo nie jest wykluczone, że większość tego czasu poszło na potykanie się o własne nogi nieogarniętych zespołów, borykanie się z brakiem wizji produktu, ograniczeniami organizacji, mnożącymi się zależnościami, skutkami nietrafionych decyzji technologicznych… Być może ogromnym kosztem produkowane są mizerne lub wadliwe rozwiązania. Taki sposób mierzenia „wartości” pojawia się często tam, gdzie mamy do czynienia z relacją klient-dostawca. Dla nieetycznego dostawcy wartością może być to, czy klient zapłaci za czas wynajmu developerów – zaś to, czy zrobili oni cokolwiek użytecznego, ma małe znaczenie.

Miary wartości to nie wszystko

Dbanie o wartość budowanego produktu nie sprowadza się tylko do patrzenia na miary tej wartości. Wiele czynników wpływa przecież na to, czy w ogóle uda się wytworzyć produkt – nośnik wartości. Dlatego poza miarami wartości, powinno się również monitorować inne parametry produktu i procesu jego wytwarzania.

Taką miarą jest na przykład częstotliwość, z jaką odbywają się wydania produktu – im większa, tym efektywniejszy jest proces developerski i tym większa zdolność organizacji do reagowania na zmiany potrzeb użytkowników i rynku. Innym przykładem sensownej miary jest ilość czasu, jaką zespoły spędzają nad wytwarzaniem wartości, odniesiona do ilości czasu niezbędnego do utrzymywania produktu w działaniu, rozwiązywania problemów, naprawiania błędów itd.

Innym dobrym przykładem jest miara jakości opisująca ilość błędów (ich „gęstość”) w produkcie, który został udostępniony użytkownikom. Oczywiście nie jest możliwe zbudowanie w pełni bezbłędnego produktu i nie da się znaleźć wszystkich problemów w trakcie testów. Ale im skuteczniej działa proces developerski (obejmujący również testowanie, a najlepiej zapewniający jakość produktu poprzez obniżanie ryzyka powstawania błędów), tym mniej defektów znajdować będą użytkownicy.

Natomiast wbrew obiegowej opinii velocity nie jest dobrym przykładem miary efektywności pracy developerów. W ograniczonym stopniu velocity może być użyteczne tylko wewnątrz zespołu budującego produkt. Próba sterowania taką miarą przez ustanawianie jej „wymaganej wartości” jest skazana na niepowodzenie i najczęściej wiedzie do dysfunkcji. Więcej o tym w artykule na temat velocity.

Uważajmy na to, jak używamy miar

Na koniec kilka ostrzeżeń. Nieprzemyślany wybór miar zazwyczaj prowadzi do marnych rezultatów, a czasami bywają one katastrofalne. Można powiedzieć, że dostajemy zawsze to, czego oczekujemy. To przede wszystkim dlatego z punktu widzenia produktowego bezużyteczną miarą jest velocity lub throughput – można bowiem budować coraz gorszy produkt, jednocześnie „pompując” w górę wartości takich miar. I niekoniecznie chodzi tu o celowe działanie developerów, którzy nie mają ochoty się zmęczyć. Często ogromnym wysiłkiem usprawniają swoją pracę, ale pożytek z niej niewielki, jeśli budują niepotrzebne rozwiązania.

Unikajmy miar, które łatwo zmanipulować, a najlepiej szukajmy więcej niż jednej miary (na przykład w formie uzupełniającego się wzajemnie zestawu leading indicator + lagging indicator), które pozwolą nam uniknąć „zaślepienia” pozytywnymi liczbami i ułatwią ustalenie, jak jest naprawdę.

Pamiętajmy też, że wartości niektórych miar nie da się zbierać bez poniesienia znaczących kosztów. Na przykład trudno całkowicie za darmo zmierzyć NPS, bo potrzebujemy chociażby zbudować mechanizm, który pozwoli użytkownikom na ocenę produktu.

Regularnie sprawdzajmy nie tylko wartości miar, ale również ich adekwatność. I bądźmy gotowi miary zmieniać, jeśli ujawni się taka potrzeba. W praktyce lepiej mierzyć mniej rzeczy, ale robić to skutecznie i być w stanie w miarę szybko zmienić lub przedefiniować wykorzystywane miary, niż kolekcjonować informacje o dziesiątkach wskaźników i unikać jak ognia konieczności weryfikowania, czy pokazują one cokolwiek sensownego.

No i wreszcie: na negatywne wskazania miar można się „uodpornić”, tłumacząc sobie, że „już za chwilę będzie lepiej”. Taka znieczulica wynika też często z braku reakcji na niepożądane wartości miar. Jeśli już coś mierzymy, musimy być gotowi działać od razu, gdy ujawni się taka potrzeba. Inaczej lepiej być może abyśmy w ogóle nic nie mierzyli.

Co ciekawe, „znieczulający” efekt może też dać zestaw miar, które w długotrwały i powtarzalny sposób pokazują pozytywny obraz sytuacji. Z jednej strony to pożądane i być może powinniśmy się cieszyć, bo „jest dobrze!”. Z drugiej „sukces” to stan niestabilny, zależny od czynników, które nieustannie się zmieniają, a zatem miary pokazujące, że niezmiennie odnosimy „sukces”, powinny skłonić do refleksji (sprawdzenia ich adekwatności). Nie jest bowiem wykluczone, że umyka coś istotnego, co mocno zaburzyłoby ten piękny obrazek…

Przeczytaj część pierwszą