Mierzenie zmian w produkcie2023-10-22Cześć! Nastąpiła mała zmiana w ramach newslettera – od tego wydania będą wychodziły w poniedziałki. 😊 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. Ale zanim to wszystko, jak co tydzień, przygotowałem też dla Ciebie 5 interesujących materiałów ze świata i branży. 🤔 A więc w dzisiaj mam dla Ciebie: Miłego czytania 😀 Inżynierska prasówkaW ramach podsumowania minionego dwutygodnia, przygotowałem dla Ciebie następujące materiały: 1. From Senior Engineer to Staff Engineer Alex Ewerlöf dzieli się swoją podróżą od stanowiska Senior Engineera do pozycji Staff Engineera, opisując wyzwania, które napotkał i jak je pokonał. Dobrze opisane wskazówki dla innych inżynierów, którzy chcą podążać tą samą ścieżką kariery. https://blog.alexewerlof.com/p/senior-engineer-to-staff-engineer 2. Designing Stripe for Black Friday: How to achieve 99.9999% uptime Stripe musi projektować swoją infrastrukturę tak, aby sprostać ogromnemu ruchowi. Kuloodporna architektura szczególnie pokazuje swoją istotność w wyprzedażowym okresie przed, po i w trakcie Black Friday, jednego z najbardziej ruchliwych dni w roku. A pamiętajmy, że Stripe to platforma umożliwiająca zapłacenie za te wszystkie zakupy. Warto dowiedzieć się, jakie podejścia i strategie zostały zastosowane, aby osiągnąć absurdalną wręcz dostępność usług. https://learningdaily.dev/designing-stripe-for-black-friday-how-to-achieve-99-9999-uptime-cd720232c14/ 3. Patoarchitekci – Technology Rada vol.29 - Review Dosłownie kilka dni temu pojawiło się nowe wydanie Technology Radar od Thought Works. No i powiedzmy sobie szczerze, kto lepiej go oceni, niż Patoarchitekci? Dużo gorzkich słów popłynęło w stronę rady programowej TW, ale zwrócono też uwagę na wiele wartościowych technologii. Jeśli nie chcecie, lub nie macie czasu samodzielnie analizować tego obszernego materiału, to Patoarchitekci dostarczają solidny skrót. https://open.spotify.com/episode/4gAnhevUukqhGsSwZaMCUN?si=98e281ea8ff148b0 4. The fallacy of freemium in SaaS Ciekawe case-study wprowadzenia modelu freemium w Equal, oraz negatywnych konsekwencji płynących z tej zmiany. Trafnie pokazuje, jak chociaż niektóre decyzje biznesowe wydają się być dobrym pomysłem na papierze, to mogą okazać się katastrofalne w praktyce. https://wraptext.equals.com/the-fallacy-of-freemium-in-saas/ 5. Facebook’s Automated Bug Detection and Repair Tool: SAPFIX Inżynierowie Facebooka przedstawili narzędzie o nazwie SAPFIX, które automatycznie wykrywa i naprawia błędy w oprogramowaniu. SAPFIX wykonuje wykrywanie awarii, identyfikację problemu, sugerowanie poprawek programistycznych, generowanie przypadków testowych. To co my mamy w takim razie robić? 😅 Otwierający oczy tweet autorstwa Milanovica. https://twitter.com/milan_milanovic/status/1711630789924860315?s=46&t=niXrxWwgzXn2NnDI_TYh5g Mierzenie zmian w produkcieGdy wdrażamy na okoWiele 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żynierowieKaż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żyW ramach dzisiejszego newslettera przykładem podzielił się Michał Białecki - .NET Developer z Guestline:
No to pozostaje nam mierzyć. Jak to w takim razie zrobić? Rodzaje miarZacznijmy 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:
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:
Można również zaadaptować kategoryzację od Amazona i pogłębić nasz podział:
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:
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:
Gdy nie ma żadnych informacjiCzasami 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:
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:
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.
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ść analizujemyZ lektury książki Lean Analytics, najmocniej zapadło mi w pamięć następujące zdanie o miarach:
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"
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:
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 mierzymyNa 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ą:
Zwykle są to takie zmiany, dla których:
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 mierzeniaPlan implementacjiWszystko 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.:
Dalej trzeba się zastanowić, gdzie będziemy trzymać zbierane informacje. Miejsce gromadzenia i wizualizacjiWię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 DoneCzęsto zauważam, że zadania monitorujące mają nadmierną tendencję do bycia:
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ówNa 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:
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 funkcjiPo wdrożeniu może się okazać, że wprowadzana zmiana wcale nie przyniosła pożądanych efektów. Wtedy często pojawia się zdanie:
Ja na to odpowiem to bardzo dobitnie:
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:
Dlatego w przypadku zmian, które nie dowiozły, trzeba być bezlitosnym – albo zmieniamy, albo usuwamy.🩻 🪦 MateriałyTu znajdziesz dodatkowe materiały, które polecam, aby pogłębić ten temat:
PodsumowanieOrganizacje, 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”? 📧 Prześlij dalejDzięki, że doczytałeś(aś) do końca. 😊 Wszystkie poprzednie wydania newslettera są dostępne tutaj. Jeśli spodobał Ci się mój newsletter, prześlij go proszę osobom, którym też mógłby się spodobać. Z góry dziękuję. A jeśli nie jesteś jeszcze w newsletterze, to zachęcam do zapisania się. Polecam się na przyszłość!  "Inżynierskie podejście do produktów cyfrowych." P.S. Co myślisz o tym newsletterze? Odpisz :) |
