Przyśpieszaj dostarczanie wartości, nie tylko rozwiązań
Czyli jak wyjść z kołowrotka Więcej funkcji -> Więcej funkcji -> Więcej funkcji...
W poprzednim newsletterze mówiłem o przyśpieszaniu uruchamiania. To pozwala nam optymalizować czas pomysł -> działające rozwiązanie.
Ale to nie wystarcza, by szybciej dostarczać wartość klientom.
Build -> Build -> Build
W wielu zespołach panuje przekonanie, że najważniejsze to jak najszybciej dowieźć kod na produkcję. I teoretycznie wszyscy są zadowoleni - przecież dostarczamy! Jednak to podejście ma jeden zasadniczy problem - kompletnie pomijamy kwestię tego, po co w ogóle to robimy.
A to prowadzi do typowych problemów w zespołach produktowych:
Dostarczamy funkcję, ale nie wiemy co chcemy przez nią osiągnąć - więc nie wiemy czy nam się udało.
Mierzymy wszystko jak leci, co sprawia, że w zasadzie nie mierzymy niczego konkretnego.
Nie mamy zdefiniowanego czasu, po jakim oceniamy sukces - przez co zapominamy sprawdzić efekty.
Nie wiemy jak określić czy funkcja się przyjęła, czy jednak nie.
Interesariusze kłócą się, czy osiągnięto sukces czy nie.
W efekcie marnujemy czas na funkcje, które nie przynoszą wartości. Stajemy się chomikiem w kołowrotku - więcej funkcji -> więcej funkcji -> więcej funkcji.
Build -> Measure -> Learn
Właściwe podejście powinno być zbliżone do Build -> Measure -> Learn:
Buduj - Dostarcz określone rozwiązanie.
Mierz - Sprawdź jak to działa, czy się podoba klientom.
Ucz się - Podejmuj decyzje w oparciu o faktyczne zachowania twoich użytkowników
Wtedy faktycznie potwierdzamy, że dowieźliśmy wartość dla naszych klientów.
A więc jak tego dokonać?
Cele i miary sukcesu
Wszystkie opisywane elementy znajdziesz na tablicy Miro, którą wykorzystywaliśmy w poprzednim artykule. Będziemy się do niej odwoływać również w kolejnych punktach, więc zachęcam do zerkania na nią podczas czytania:
https://miro.com/app/board/uXjVLF0JQGE=/
Aby dostarczyć wartość, musimy jasno określić czego oczekujemy po naszym rozwiązaniu. Skupiamy się na wpływie naszego rozwiązania na klientów i sposobach mierzenia ich zachowania.
Na tym etapie warto zdefiniować:
Cel i grupę docelową - co chcemy osiągnąć i dla kogo to robimy.
Metryki potwierdzające sukces - jasno określone wskaźniki pokazujące, że nam się udało.
Kryteria sukcesu i porażki - przy jakich wartościach uznamy, że warto kontynuować, lub trzeba się zwijać
Sygnały ostrzegawcze - jak wykryjemy, że rozwiązanie pogarsza inne funkcje (np. kanibalizacja innych produktów).
Czas oceny - po jakim okresie sprawdzimy efekty (tydzień? miesiąc? kwartał?).
Zadania już na początku
Za późno myśleć o mierzeniu, gdy już coś wdrożyliśmy. Nie będziemy mieć historycznych danych, nie będziemy wiedzieć jak było "przed". Dlatego kluczowe jest zaplanowanie metryk jeszcze przed rozpoczęciem prac programistycznych.
Rozpocznij od określenia:
Jakie punkty procesu musimy monitorować.
Gdzie w kodzie wysyłać zdarzenia analityczne.
Które metryki techniczne są dla nas istotne.
Jakie dashboardy musimy przygotować.
Kto będzie korzystał z tych informacji.
W ramach tego planowania nie możemy zapomnieć o obsłudze niestandardowych scenariuszy:
Jak wykryjemy problemy z działaniem rozwiązania.
Co zrobimy, gdy liczby znacząco odbiegną od normy.
Kogo powiadomić w przypadku wykrycia anomalii.
Jakie raporty będą wymagane do analizy problemów.
W jaki sposób cofniemy/naprawimy błędne działanie.
O wadze automatyzacji zbierania danych pisałem w artykule o
[obserwowalności](https://newsletter.radekmaziarka.pl/p/
obserwowalnosc). Im więcej zautomatyzujemy na starcie, tym mniej czasu stracimy na ręczne zbieranie danych. A to przełoży się na szybszą reakcję, gdy coś pójdzie nie tak.
Ocena wdrożonych rozwiązań
Na samym końcu pętli Build->Measure->Learn, jest Learn. Samo uruchomienie rozwiązania nie jest jeszcze sukcesem - to dopiero początek faktycznej weryfikacji. Teraz kluczowe jest sprawdzenie czy nasze założenia się sprawdziły i czy dostarczyliśmy wartość.
Jak uporządkować ocenę rozwiązania? Warto użyć prostej tablicy kanban:
Waiting - rozwiązania, które "wygrzewają się" na produkcji, czekając na zebranie odpowiedniej ilości danych.
To Assess - gotowe do oceny, mamy już wystarczająco dużo informacji by podjąć decyzję.
Success - To Expand - rozwiązania, które spełniły założone kryteria i można planować ich rozwój.
Failure - To Assess - funkcje, które nie spełniły oczekiwań - do decyzji czy naprawiamy, czy jednak wycofujemy.
Taka wizualizacja pomaga zespołowi aktywnie zarządzać oceną wdrożonych rozwiązań. Nie ma sytuacji, że o czymś zapominamy. Widzimy dokładnie które funkcje wymagają naszej uwagi i jakie decyzje musimy podjąć.
Ogólny proces
Sama tablica i metryki to za mało. Trzeba wprowadzić praktyki w życie zespołu. Aby zmiana się zakorzeniła musimy obudować nasze działania praktykami zespołowymi.
Warto wykorzystać istniejące elementy procesu, zamiast dodawać kolejne spotkania:
Ocena rozwiązań podczas Sprint Review - przechodzimy przez tablicę i oceniamy wdrożone rozwiązania.
Pole w Jirze określające datę kolejnej oceny rozwiązania.
Automatyczne przypomnienia na Slacku/Teams o zbliżającym się terminie oceny.
Automat przesuwający zadania na tablicy, gdy minie określony czas.
Cykliczny przegląd dashboardów podczas Daily/Weekly.
W poprzednim newsletterze o Value Stream Mappingu pisałem jak ważne jest, by proces był powtarzalny. Tu działamy podobnie - automatyzujemy co się da, a resztę wpinamy w istniejący sposób pracy. Dzięki temu ocena rozwiązań staje się naturalną częścią pracy zespołu, a nie kolejnym ciężarem.
Podsumowanie
Mam nadzieję, że przekonałem Cie, że warto ustalać cele dla dostarczanych rozwiązań. Chcemy szybciej dostarczać nie tylko rozwiązania, ale wartość dla nas i naszych klientów.
Jeśli interesuje Cię ten temat to zerknij na inne materiały, które mogą Ci pomóc:
Jak tworzyć produkt, a nie zbiór funkcjonalności -
Product development - 5 przemyśleń - https://radekmaziarka.pl/2021/02/07/product-development-5-przemyslen/
Cele -> Możliwości -> Rozwiązania - https://newsletter.radekmaziarka.pl/p/cele-mozliwosci-rozwiazania