W pierwszej części cyklu omówiłem samo pojęcie 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. Każda z tych miar stanowi wskaźnik opóźniony (ang. 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ć. Każda z takich miar stanowi wskaźnik wyprzedzający (ang. leading indicator), ponieważ wskazują one na trendy i pozwalają sterować procesem.
Takie wskaźniki wyprzedzające (znów paskudne dosłowne tłumaczenie) nie dają pewności, jaka będzie przyszłość, ale umożliwiają reakcję, jeśli trend zmian wartości tych miar wskazuje na istnienie jakiegoś problemu i rozwój produktu wydaje się iść w niewłaściwą stronę. Pozwalają też na wykorzystanie nowych możliwości, jeśli się takowe pojawią i trend ten je ujawni.
Przykładem leading indicatora jest liczba 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 dającej możliwość używania produktu.
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.
Z kronikarskiego obowiązku wspomnę też, że czasami granica pomiędzy wskaźnikami wyprzedzającymi i opóźnionymi nie jest zbyt wyraźna. Nierzadko wystarczy zwiększyć częstotliwość zbierania wartości jakiejś miary, by dało się jej użyć jako leading indicatora. Przykładowo, jeśli wskaźnikiem opóźnionym jest liczba nowych klientów, jakich udało się pozyskać w ciągu roku, to sprawdzanie tej samej liczby z interwałem miesięcznym albo nawet tygodniowym może dobrze podpowiadać, czy sprawy zmierzają w dobrą stronę.
Częstym rozwiązaniem jest monitorowanie trendów zmian jakiejś miary, która stanowi docelowo lagging indicator, by wykorzystać uzyskaną w ten sposób informację jako wskaźnik wyprzedzający tej samej miary. Przy czym nie zawsze jest to możliwe, np. zysk netto firmy za określony rok podatkowy da się w oczywisty sposób policzyć tylko raz na rok, a wyliczanie takiego zysku co miesiąc nie będzie żadnym trendem tej pierwszej miary, tylko zupełnie innym wskaźnikiem wyprzedzającym dla niej.
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ć liczba nowych użytkowników, którzy decydują się na zakup produktu dzięki poleceniu od kogoś, kto już z niego korzysta. Może taką miarą być również niska liczba 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 liczbą zarejestrowanych incydentów.
Miarą wartości dla klienta może być liczba 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, wyrażona średnim czasem, jaki jest niezbędny 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 cyklu artykułów. 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 popełnianym błędem przy definiowaniu miar jest mylenie wartości z produktywnością Zespołów. Zaczyna się wtedy mierzyć liczbę 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 jej 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ła 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” (cudzysłów nieprzypadkowy, bo nie jest mierzona wartość, tylko czas pracy) 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 wynajętych Developerów – natomiast 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, czyli 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ą nowe wersje produktu są udostępniane użytkownikom – 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 liczbę 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. 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 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 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…