Mierzenie zmian w produkcie
Praktyki Inżynierskie Najlepszych Firm Produktowych
Aby zebrać w jednym miejscu praktyczną i aktualną wiedzę dotyczącą praktyk inżynierskich, postanowiłem swoje doświadczenia zebrać w serii artykułów pod wspólną nazwą Praktyk Inżynierskich. Mam nadzieję że to kompendium będzie miejscem, do którego możesz wracać po wskazówki i rozwiązania.
W cyklu Praktyk Inżynierskich:
Mierzenie zmian w produkcie [TEN ARTYKUŁ]
W poprzedniej części cyklu omawialiśmy temat automatyzacji wdrożeń i zapewniania jakości.
W dzisiejszym wydaniu ponownie poruszymy zagadnienie Inżynierskich Praktyk Firm Produktowych, a dokładniej - analizę wdrażanych zmian. Ta umiejętność przyjdzie nam z pomocą za każdym razem, kiedy będziemy chcieli dowiedzieć się, jak zachowuje się opracowywane rozwiązanie na produkcji. Celem jest mierzenie wprowadzanej zmiany, w taki sposób, aby zrozumieć, czy osiągnęliśmy pożądany efekt.
Gdy wdrażamy na oko
Wiele firm, w ocenie zmian, kieruje się intuicją lub subiektywnymi opiniami. Niestety, jak można się domyślić, takie podejście nierzadko prowadzi do nieprzewidywalnych i zwykle niepożądanych wyników.
Czasem efekty wprowadzonych zmian okazują się na tyle nieistotne lub wręcz bezużyteczne dla organizacji, że najbardziej zauważalny jest zmarnowany czas i zasoby. No bo przecież nie każda wprowadzona zmiana przynosi oczekiwane rezultaty (Faster. Faster. Faster.)
My się jednak dowiemy o tym zbyt późno.
Bez systematycznego monitorowania wprowadzanych zmian istnieje ryzyko, że nie zauważymy niepożądanych skutków naszych działań. Przykładowo, część funkcji może sabotować pracę naszego systemu. My akurat na co dzień nie będziemy tego widzieć, ale za to klienci z jakiegoś powodu zaczną odpadać w procesie zakupowym. No tak, nowa zmiana zakłóca któryś z kroków.
Dodatkowo, zwykle zmiany są wprowadzane po kilka naraz. W efekcie, może się zdarzyć, że pewne aspekty działania produktu ulegają poprawie, ale nikt nie jest w stanie wskazać, co dokładnie za to odpowiada. Więc dalej zmieniamy nasz produkt “na czuja”. I ostatecznie rozwijamy części produktu, które nie dostarczają wystarczającej wartości.
Z perspektywy inżynierskiej pojawia się jeszcze jeden bardzo ważny problem: nadmierne rozrastanie się produktu:
Nie mając dostępu do szczegółowych danych na temat funkcji, pozornie każda z nich wydaje się tak samo istotna. Wobec tego rozwojowi i utrzymaniu każdej z nich poświęcamy tyle samo uwagi Ostatecznie kończymy z wysokimi kosztami aktualizacji i wsparcia.
Organizacje z wysoką kulturą inżynierską postępują inaczej.
Monitorować zmiany jak inżynierowie
Każdy proces inżynieryjny wymaga ciągłego uczenia się, budowania, mierzenia i ponownego uczenia się. Tylko takie podejście pozwala na systematyczne i skuteczne wprowadzanie zmian.
Dobrze to opisał Mina Iskarous w swoim artykule Why we prototype:
Pierwszym krokiem będzie zdefiniowanie, jaki powinien być mierzalny rezultat naszych zmian. Czy chodzi tylko o zwiększenie ilości zakupów? Może o poprawę wydajności działania procesu? A może o zredukowanie kosztów obsługi klienta?
Następnie, w ramach wdrażania zmiany nie wolno zapominać o właściwej implementacji monitorowania. Rozbijamy poszczególne miary na bardziej prostsze obserwacje i to je właśnie wbudowujemy do rozwiązania.
Po wdrożeniu zmiany, kolejnym kluczowym krokiem jest jej dokładne zmierzenie.Porównując te dane z naszymi początkowymi oczekiwaniami i celami, możemy ocenić, czy zmiana przyniosła pożądane efekty.
Na podstawie zebranych danych i przeprowadzonej analizy, podejmujemy decyzje o dalszych krokach. Czy podejmować następne kroki? Czy wprowadzone zmiany są satysfakcjonujące? A może najlepiej byłoby całą tę funkcję wyrzucić do kosza?
Dopiero na podstawie zebranych danych, możemy odpowiedzieć sobie na to pytanie.
Przykład z branży
W ramach dzisiejszego newslettera przykładem podzielił się Michał Białecki - .NET Developer z Guestline:
Q: W jaki sposób przygotowujecie się do analizy, a następnie analizujecie wpływ danej funkcji po jej wdrożeniu?
A: Na etapie planowania zadajemy sobie pytanie: jak możemy zmierzyć daną zmianę? Ustalamy z biznesem, jakie metryki w danych przypadku mają sens, a w sprincie pojawia się zadanie, aby je dodać. Jeżeli chodzi o nowe funkcjonalności, najczęściej jest to dodatkowe logowanie, kiedy dana funkcja jest używana, abyśmy mogli porównać np. jaki procent użytkowników z niej korzysta. Sprawdzamy również, czy nie wygenerowała ona nowych błędów.
W przypadku zmiany istniejących funkcjonalności, metryki mogą być bardziej złożone, jak np. porównanie czasu działania obu wersji albo sprawdzenie, czy dana opcja w ogóle jest używana. Wszystkie nasze logi i metryki wrzucamy do Azure Application Insights, gdzie z łatwością można wygenerować uwielbiane, zwłaszcza przez biznes, wykresy i dashboardy.
Q: Jakie przynosi to benefity dla twojego zespołu i organizacji?
A: Podczas tworzenia nowej implementacji okienka płatności, dodaliśmy logowanie do istniejącej wersji na poszczególnych etapach. Okazało się, że niektóre opcje w ogóle nie są używane, jak np. drukowanie potwierdzenia. Ta obserwacja pozwoliła nam znacznie uprościć proces płatności, a dodatkowo skróciła czas o ponad połowę. Metryki to również wspaniały, nieoficjalny feedback od naszych klientów. Po wprowadzeniu zmiany czasami dostajemy nieprzychylne komentarze, ale z zebranych danych możemy łatwo wybronić swoją decyzję, zwłaszcza jeżeli wpływa ona tylko na 0.1% klientów.
No to pozostaje nam mierzyć. Jak to w takim razie zrobić?
Rodzaje miar
Zacznijmy od krótkiego wprowadzenia, co właściwie można mierzyć.
Większość artykułów branżowych (Picking the Right Product Metrics, Product Success Metrics) opisuje wskaźniki takie, jak:
Stały miesięczny przychód - Monthly recurring revenue (MRR)
Całościowa wartość danego klienta - Customer Lifetime Value
Koszt pozyskania klienta - Customer Acquisition Cost
Chociaż same w sobie są wartościowe, stanowią jedynie bardzo ogólne podsumowanie. Kiedy zaczynamy je mierzyć, to zwykle jest już zdecydowanie za późno. Dlatego mierzymy wcześniej i częściej.
Aby lepiej zrozumieć zagadnienie, warto wprowadzić tu definicje wskaźników wyprzedzających i opóźnionych:
Wskaźnik wyprzedzający – pokazuje nam daną aktywność, daje szybkie sygnały – np. klient wchodzi w nową podstronę.
Wskaźnik opóźniony – pokazuje nam podsumowanie, realizację wyniku – np. klient wysłał zapytanie ofertowe.
Można również zaadaptować kategoryzację od Amazona i pogłębić nasz podział:
Input – wprowadziliśmy zmianę, przez co np. pokazujemy klientom nowe informacje na stronie – klient widzi rekomendację podobnych produktów.
Activity – klient wykonuje pewne akcje, które nie dają bezpośredniego rezultatu z naszej perspektywy – np. klika otwierając nowe produkty, czyta opisy, porównuje produkty.
Output – pokazuje pożądane zmiany zachowania – np. klient dodaje te produkty do koszyka.
Impact – …a następnie to, jak przekładają się na wyniki biznesowe – np. większą średnią wartość sprzedanych produktów.
Istotne jest tutaj spektrum analizy, za którą się zabieramy. Można mierzyć rzeczy na końcu, można na początku, można w środku. Na dobrą sprawę ile osób, tyle metod.
Logicznie więc nasuwa się na myśl kolejne pytanie.
Co chcemy mierzyć?
W tym momencie zakładam, że jesteś na bieżąco z newsletterem i przeczytałeś/aś Cele -> Możliwości -> Rozwiązania (jeśli nie, zatrzymaj się na moment i wróć tutaj, po zapoznaniu się z tekstem w linku). Jak pamiętasz, rozmawialiśmy tam o wyborze rozwiązania w oparciu o cele. I to właśnie na tej podstawie będziemy określać pożądane i/ niepożądane zachowania naszych użytkowników.
Załóżmy, że naszym celem jest zwiększenie średniej wartości koszyka w sklepie internetowym. W tym celu tworzymy silnik rekomendacji podobnych produktów, które kupili inni klienci. Możemy tutaj zmierzyć kilka wskaźników:
Jak wiele rekomendowanych produktów zostało wyświetlonych klientowi – Input.
Jak szybko rekomendacja pojawiła się na stronie – Input.
Jak wielu klientów kliknęło w rekomendowany produkt – Activity.
Jak wielu z tych klientów dodało produkt do koszyka – Outcome.
Każda z tych informacji daje nam pewien wgląd w proces klienta.
Aby wybrać elementy warte mierzenia, warto sobie zwizualizować proces pozyskiwania klienta. Można wykorzystać do tego np. Event Modeling zaproponowany przez Yves Goelevena:
Dzięki tej metodzie możemy pokazać zarówno powierzchowne, jak i wewnętrzne aspekty funkcjonowania produktu i na tej podstawie wybrać, co dla nas jest najważniejsze.
Dopiero teraz, z pełnym zestawem informacji, możemy sobie zadać pytanie- po co mierzymy:
Aby zrozumieć.
Aby poprawić.
Gdy nie ma żadnych informacji
Czasami rozpoczynamy od pustej kartki papieru. Nie ma żadnych ustalonych miar tego, co działa i w jaki sposób. Co na to poradzić?
Warto wykorzystać oświadczenie / intuicję, aby znaleźć najważniejsze dla nas aspekty:
Zastanawiamy się na jakich kryteriach jakościowych pracy produktu zależy naszemu klientowi.
Określamy główne punkty procesu.
Poszukujemy miejsc zawracania / ucieczki klienta z procesu.
Definiujemy akcje, które są kontrproduktywne z perspektywy biznesu.
Następnie właśnie te aspekty rozpoczynamy mierzyć, aby je lepiej zrozumieć.
Dokąd zmierzamy?
Kiedy już posiadamy jakieś miary, to zwykle chcemy je zoptymalizować. Jak to zrobić krok po kroku?
Zadajemy sobie pierwsze pytanie:
Jaki wskaźnik chcemy poprawić?
Wybór metryki docelowej pozwala skupić się na czymś, co naprawdę przynosi wartość. Dzięki temu unikamy błędu poznawczemu - efektu potwierdzenia. Rosnąca liczba klientów odwiedzających na produkt może nie zwiększać zysków mimo tego, jak dobrze wygląda w statystykach. Lepiej się skupić na dodawaniu do koszyka.
O ile wskaźnik powinien się poprawić?
W ramach wdrażania nowej zmiany, warto skwantyfikować pożądaną poprawę wskaźnika.
Dlaczego? Powstrzymujemy w ten sposób inny błąd poznawczy, nazywany przesuwaniem bramki (moving the goalposts). Nasze rozwiązanie może zostać uznane za zakończone sukcesem tylko dlatego, że dana miara drgnęła. A przecież nie chodzi nam o 1% zmiany, prawda? 😅
Jaką wartość analizujemy
Z lektury książki Lean Analytics, najmocniej zapadło mi w pamięć następujące zdanie o miarach:
A good metric is a ratio or a rate. Accountants and financial analysts have several ratios they look at to understand, at a glance, the fundamental health of a company. You need some, too.
Dużym problemem w trakcie mierzenia mogą być „gołe" wartości, które dostajemy. Często zatrzymujemy się na analizie pojedynczych wartości. Pytanie tylko, która informacja daje nam lepszy wgląd w sytuację „Jak wiele klientów kliknęło w rekomendowany produkt"
1234 klientów.
10% wszystkich klientów, którzy otworzyli koszyk.
Pierwsza z wartości jest wystarczająca na samym początku analizy, gdy w ogóle rozpoczynamy mierzenie. Ale szybko okazuje się, że nie daje wystarczająco dogłębnego zrozumienia stanu produktu. Może się przykładowo okazać, że:
Liczba klientów wzrosła 2 razy.
Procent klientów, którzy kliknęli rekomendowane produkty zmalał o 20%.
Całkowita liczba klientów, którzy kliknęli rekomendowane produkty wynosi więc 1.6 raza więcej niż wcześniej.
Jeśli nie będziemy mierzyć zmian procentowych, może zacząć nam się wydawać, że rekomendacja działa super, a tak naprawdę to tylko rezultat większego ruchu na stronie.
Jak długo mierzymy
Na samym końcu procesu, warto się zastanowić, po jakim czasie oczekujemy poprawy wskaźników.
W przytoczonym wcześniej przykładzie rekomendowanych produktów, zmieniając Input, można podejrzewać, że Activity powinno się zmienić prawie natychmiastowo.
Niestety, niektóre zmiany mają dłuższy horyzont czasowy i możemy się trochę naczekać, zanim metryki nie drgną:
Input – wprowadzenie systemu lojalnościowego / Activity – wykorzystywanie punktów.
Input – inny szablon wysyłanej oferty / Activity – odpowiedź na zapytanie ofertowe.
Zwykle są to takie zmiany, dla których:
Input i Activity nie dzieje się w tym samym momencie.
Input i Activity są przeprowadzane w innych urządzeniach / systemach.
Dla takich rozwiązań warto zdefiniować, ile czasu dajemy im, zanim zaczniemy oceniać daną zmianę. Dzięki temu unikniemy odrzucenia zmiany, gdy ona się dopiero „rozgrzewa".
Wdrażanie mierzenia
Plan implementacji
Wszystko rozpoczyna się od dobrego planu. 🗺️
Najpierw trzeba zaplanować dodatkowe implementacje monitoringu. Tutaj możecie wykorzystać powyżej opisany Event Modeling. W mojej ocenie szczególnie dobrze sprawdza się User Story Mapping – przez większą dokładność opisu zmian:
W ramach zadania dopisujemy jakie akcje chcemy wysyłać do mierzenia oraz informacje, które powinny być wysłane. To może być np.:
Źródło akcji, ścieżka nawigacji.
Identyfikator użytkownika (bądź jego charakterystykę, aby uniknąć problemów z RODO).
Dodatkowe charakterystyki (np. w domenie ecommerce, czyli produktu, koszyka, zamówienia)
Typ urządzenia, wersja aplikacji/strony.
Długość trwania akcji.
Dalej trzeba się zastanowić, gdzie będziemy trzymać zbierane informacje.
Miejsce gromadzenia i wizualizacji
Większość firm korzysta Google Analytics lub podobnego narzędzia. I ta większość nie liczy prawie niczego, poza prostymi wyświetleniami stron. 🤯 A przecież można wdrożyć wbudowane zdarzenia (recommended events) lub tworzyć własne (custom events). A następnie tworzyć proste wizualizacje.
Z kolei, jak pokazuje przykład Michała Białeckiego, można wykorzystywać narzędzia, które tak czy inaczej posiadamy w naszym technologicznym stacku. Application Insights w Azure, Amazon CloudWatch w AWS, czy inne inżynierskie narzędzia mogą być z powodzeniem wykorzystane do mierzenia produktu.
Oczywiście, to jest jedynie pewien punkt startowy. Bardziej rozbudowane firmy posiadają cały stack oparty o narzędzia Business Inteligence (np. Power BI), czy dedykowane do mierzenia produktów (np. Amplitude). Proponuję jednak rozpoczynać od prostszych narzędzi i, dopiero przy osiągnięciu limitu, migrować.
Niestety to wszystko może się nie udać, jeśli na samym końcu nie zaimplementujemy monitorowania.
Mierzenie jako Definition of Done
Często zauważam, że zadania monitorujące mają nadmierną tendencję do bycia:
przesuniętymi na później,
zapomnianymi.
Dzieje się tak dlatego, że większość z nas nie jest przyzwyczajona do brania monitoringu pod uwagę. Implementujemy więc go dopiero po wdrożeniu całości (jeśli w ogóle). Kończymy z wdrożeniem produktu, który nie jest monitorowany.
Moją poradą jest dodanie monitoringu jako kryterium, bez którego dane zadanie nie jest zakończone. Dzięki temu zespół odpowiednio zacznie priorytetyzować swoją pracę. Nie ma przerzucania na kolejny sprint, bo równie dobrze to testy można by sobie przerzucić. 😬
To jednak zadziała jedynie wtedy, gdy na początku zaplanujemy dodanie monitoringu (punkt Plan implementacji). Inaczej w ramach dowożenia musimy to dodatkowo przemyśleć, co monitorować. A wtedy presja czasowa nierzadko powoduje, że machamy na to ręką.
Ocena rezultatów
Na samym końcu pętli Build->Measure->Learn, jest Learn.
To, że po prostu wdrożyliśmy rozwiązanie, nie jest jeszcze w żadnym wypadku sukcesem. Sukcesem jest dopiero doprowadzenie do pożądanej zmiany zachowania naszych klientów.
I to też jest praca, jak każda inna. I, tak jak każdą inną pracą, nią też zarządzać warto i należy. Jak kilka tygodni temu mówiliśmy o Upstream Kanbanie, tak tutaj warto by mieć wyznaczony jakiś Sea Level Kanban (trademark!).
Powyżej widzisz przykład prostej tablicy, która może służyć do oceny zmian:
Po wdrożeniu, zmiana przechodzi do:
Waiting – jeśli wymagany jest czas „wygrzania się" na produkcji.
To Review – jeśli zmiana jest od razu gotowa do oceny.
Gdy minie określona data, zmiana przechodzi z Waiting do To Review.
Następnie oceniamy zmianę:
Jeśli odrobiliśmy swoją pracę to mamy kryteria by ocenić, czy zmiana przyniosła oczekiwany rezultat.
Jeśli tak, to przesuwamy do Success – To Expand. W kolejnej iteracji możemy się zastanowić jak wzmocnić daną funkcję, aby przyniosła dalsze zyski.
Jeśli nie, to przesuwamy do Failure – To Assess. W kolejnej iteracji określamy czy chcemy coś poprawić, czy jednak usuwamy wprowadzoną zmianę.
Warto też spojrzeć na pozostałe kryteria, by sprawdzić, czy nie poprawiliśmy jednych wskaźników, kosztem drugim.
Dzięki temu jesteśmy w stanie zarządzić pracą, która zwykle niby się dzieje, ale nikt nie wie jak gdzie i kiedy.
Modyfikacja, bądź usuwanie funkcji
Po wdrożeniu może się okazać, że wprowadzana zmiana wcale nie przyniosła pożądanych efektów. Wtedy często pojawia się zdanie:
Skoro już jest to zostawmy.
Ja na to odpowiem to bardzo dobitnie:
Więcej funkcji =/= lepszy produkt
Wartość produktu zależy od połączenia wszystkich funkcji ze sobą, a nie ich ilości. Klient kupuje doświadczenie, a…
Słaba funkcja => Gorsze funkcje zależne => Gorszy produkt
Efekt? Możemy pogorszyć cały produkt jedną słabą funkcją.
Dodatkowo funkcje, które istnieją w produkcie, pociągają za sobą stałe koszty, np:
Złożoności systemu.
Wsparcia i obsługi.
Dokumentacji.
Testowania.
Zachowywania bezpieczeństwa.
Dlatego w przypadku zmian, które nie dowiozły, trzeba być bezlitosnym – albo zmieniamy, albo usuwamy.🩻 🪦
Materiały
Tu znajdziesz dodatkowe materiały, które polecam, aby pogłębić ten temat:
Prezentacja “Jak tworzyć product, a nie zbiór funkcjonalności”
Artykuł “How Amazon Uses Input Metrics” - Huy Nguyen
https://www.holistics.io/blog/how-amazon-uses-input-metrics/Książka “Lean Analytics” - Alistair Croll, Benjamin Yoskovitz
https://www.amazon.com/Lean-Analytics-Better-Startup-Faster-ebook/dp/B00AG66LTM/Artykuł “Lean Startup Series: Traveling the Build-Measure-Learn Cycle” - Romuald Członkowski
https://www.boldare.com/blog/build-measure-learn-cycleArtykuł “Build Measure Learn vs. Learn Measure Build” - Tristan Kromer
https://kromatic.com/blog/build-measure-learn-vs-learn-measure-build/Artykuł “Product Development – 5 przemyśleń” – Radek Maziarka
https://radekmaziarka.pl/2021/02/07/product-development-5-przemyslen/
Podsumowanie
Organizacje, które mierzą wprowadzane zmiany, są w stanie szybciej zrozumieć, jaki miały one wpływ na funkcjonowanie produktu. Ich oceny są bardziej obiektywne. Łatwiej o konsensus, czy mamy sukces, czy porażkę. Dzięki temu ostatecznie to te organizacje szybciej się adaptują, a więc i zdobywają szersze rynki.
A jak u Ciebie wygląda analiza wprowadzanych zmian? Mierzenie i ocenianie, czy kompletnie “na czuja”?
Niezawodność
W kolejnym wydaniu wydaniu na tapet bierzemy niezawodność – czyli o tym, w jaki sposób zapewniać stabilne działanie produktu: