Co mierzę błędnie? Pułapki mierzenia

Typowe problemy z metrykami, jakie spotkałem w zespołach produktowych.

Niedawno rozmawiałem z zespołem, który był przekonany o swojej wysokiej efektywności.

Dowozimy zadania w 2-3 dni

Zapytałem wtedy o czas oczekiwania na odpowiedź od innych zespołów. Po szybkim
przeliczeniu wyszło, że takie uzgodnienia trwają nawet 2 tygodnie. Tego czasu zespół już jednak nie wliczał do swoich metryk.

Podobna sytuacja (choć w innych dziedzinach) powtórzyła się wielokrotnie. Zespoły wąsko mierzyły SLA. Narzekały na koszty zakupu, ale nie developmentu. Liczyły błędy zgłaszane przez klientów, nie zauważając tych, którzy po prostu rezygnowali z produktu.

Problem w tym, że mierzymy to, co jest łatwe do zmierzenia, zamiast tego, co faktycznie ma znaczenie. Patrzymy na to, co wygodne, a nie na to, co wpływa na efektywność. A tymczasem rzeczywistość wygląda zupełnie inaczej.

Przyjrzyjmy się więc najczęstszym błędom w mierzeniu naszej pracy.

Przykłady błędnego mierzenia

Przejdziemy sobie od kwestii technicznych, przez procesowe, po produktowe.

Dostępność systemu (SLA)

Zacznijmy od dostępności systemu (SLA). Temat, o którym kiedyś wspominali też Patoarchitekci w swoim podcaście.

Zespoły często pokazują imponujące metryki dostępności swoich systemów - 99.9%. Wszystko pięknie się świeci na zielono. Jest tylko jeden szkopuł - nikt nie patrzy na dostępność systemów zależnych. A to właśnie one często są źródłem problemów.

Spójrzmy na typowe wartości dostępności:

• Baza danych - 99% dostępności

• Bramka płatności - 95% dostępności

• System logistyczny - 90% dostępności

• System mailowy - 98% dostępności

I tutaj przychodzi matematyka - dostępność systemów zawsze się mnoży. 99.9% 99% 95% * 90% = 84.4%. W skali miesiąca to ponad 100 godzin przestoju. A my wciąż chwalimy się tymi 99.9% 🤦‍♂️

Jak pisałem w poprzednim newsletterze o niezawodności - klienta nie obchodzi czy system nie działa przez naszą bazę czy zewnętrzną bramkę płatności. Dla niego system po prostu nie działa. Kropka (nienawiści).

Decyzje Build vs Buy

Przejdźmy do klasycznego dylematu Build vs Buy. Stajemy przed decyzją - kupić gotowe rozwiązanie czy zbudować własne. Patrzymy na cenę zewnętrznego narzędzia - 50 tysięcy rocznie. "Za drogo" - pada decyzja. "Zbudujemy sami, będzie taniej".

Problem w tym, że patrzymy tylko na jeden wymiar kosztów. Pomijamy wszystkie pozostałe:

• Koszt pracy zespołu - dwóch seniorów na pół roku to już 100 tysięcy.

• Koszt utraconych możliwości - w tym czasie moglibyśmy dostarczyć funkcje generujące 200 tysięcy przychodu.

• Koszt utrzymania - jeden developer na stałe zajmuje się poprawkami.

• Koszt opóźnienia wejścia na rynek - konkurencja już sprzedaje, a my dopiero budujemy.

W efekcie "oszczędzamy" 50 tysięcy, tracąc 500 tysięcy w skali roku. 🤦‍♂️ Jak pisałem w artykule o Buy vs Build - 4 koszta, musimy spojrzeć znacznie szerzej na temat kosztów.

Mój ulubiony przykład? Pisanie od zera biblioteki do zarządzania transakcjami rozproszonymi, zamiast wykorzystania Mass Transit. Kopiemy się z koniem przez pół roku, zamiast zapłacić Chrisowi kilka tysięcy i mieć gotowe rozwiązanie na jutro.

Dług technologiczny

Czas na temat długu technologicznego. Część zespołów w ogóle nie zastanawia się nad tym tematem. Nie wiedzą nawet jak głęboko siedzą w problemach. Po prostu jadą do przodu, aż w końcu system się posypie. 😅

Ale załóżmy, że jednak próbujemy to mierzyć. Co zwykle robimy? Idziemy po linii najmniejszego oporu:

• Tworzymy tickety na każdy problem

• Wrzucamy je do backloga

• ...i tam umierają, bo nikt ich nie realizuje

W 90% przypadków takie zadania nigdy nie trafiają do sprint backloga. Bo zawsze jest coś ważniejszego. Coś, co "musi wejść na produkcję już".

Lepsze podejście proponuje Brandolini ze swoim Design integrity. Nie patrzmy na dług jako listę zaległości. Skupmy się na tym, jak mocno nasz kod pasuje do swoich celów. Wymaga to jednak mierzenia o wiele więcej:

• Wpływu długu na różnych interesariuszy.

• Potencjalnych zysków z naprawy.

• Czasu wymaganego na naprawę.

Więcej o tym, jak skutecznie mierzyć dług technologiczny opisałem w artykule Dług w produkcie - jak uzasadniać jego spłatę.

Czas dostarczania

Kolejnym problemem jest mierzenie czasu dostarczania. Zespoły zwykle skupiają się tylko na czasie developmentu. "Zrobiliśmy to w 2 dni!" - krzyczą z dumą. Tylko że to nie jest pełny obraz.

Co zwykle pomijamy w pomiarach?

• Czas oczekiwania na tłumaczenia

• Czas na security review

• Czas na compliance check

• Czas na code review (o którym pisałem w newsletterze o PR Review)

• Czas na faktyczne uruchomienie na produkcji (zobacz na Przyśpieszaj uruchamianie, zamiast tylko dostarczać)

W efekcie zespół widzi 2 dni pracy, a zadanie realnie trwa 2 tygodnie.

To trochę jak z liczeniem średniej prędkości w mieście - jazda między światłami może być szybka, ale i tak głównie stoimy w korkach. 😅

Skuteczność testów

A teraz rzućmy okiem na temat testów. Duża część firm ma rozbudowane testy E2E sprawdzające scenariusze między domenami. Mierzymy pokrycie kodu, liczymy ile przypadków obsługujemy, patrzymy na szerokość testów. Wskaźniki wyglądają świetnie - 80% pokrycia!

Tylko że kompletnie pomijamy inne aspekty:

• Czas wykonywania testów - dziesiątki czy setki minut.

• Niestabilność testów - raz przechodzą, raz nie.

• Brak pewności - nie wiemy, czy faktycznie znaleźliśmy błąd, czy to tylko niestabilny test

W efekcie nikt już nie ufa testom. Kiedy testy nie przechodzą, to nie słychać "O kurde, mam błąd w kodzie", tylko "Znowu te testy E2E się popsuły". Testy stały się wrogiem zespołu, zamiast być jego sprzymierzeńcem.

A skoro nikt nie ufa testom, to po co w ogóle je mamy? Jak pisałem w artykule o zapewnianiu jakości przez obserwowalność, często lepiej jest zainwestować w monitoring produkcji. Mała inwestycja potrafi dać znacznie większy zwrot niż kolejne niestabilne testy.

Wykorzystanie produktowe

Przejdźmy do mierzenia wykorzystania produktu. Chwalimy się na spotkaniach:

Mamy 1000 aktywnych użytkowników miesięcznie.

Liczby może i wyglądają świetnie, ale czy na pewno mierzą to, co istotne? Warto zadać pytanie:

• Ile czasu użytkownicy faktycznie spędzają w systemie?

• Które funkcje naprawdę wykorzystują?

• Czy w ogóle wracają do produktu po pierwszym użyciu?

• Jak głęboko wchodzą w nasz produkt?

W efekcie cieszymy się z tysiąca użytkowników, podczas gdy 900 z nich zagląda do aplikacji raz w miesiącu, klika jeden przycisk i wychodzi. To trochę jak chwalenie się, że mamy dużo followersów na LinkedIn - liczba może i imponująca, ale co z tego? 😅

To klasyczny przykład metryki próżności - wygląda świetnie w prezentacji, ale kompletnie nie pokazuje realnej wartości naszego produktu. Zamiast liczyć użytkowników, może warto zacząć mierzyć ich faktyczne zaangażowanie?

Problemy użytkowników

Na koniec został temat zgłoszeń od użytkowników. Liczymy, że mamy tylko 10 zgłoszeń miesięcznie. Wydaje się dobrze, ale jak poszukamy głębiej, to okazuje się że pomijamy:

• Klientów, którzy po prostu zrezygnowali bez słowa

• Użytkowników, którzy znaleźli obejście problemu

• Osoby, które przestały korzystać z problematycznej funkcji

• Tych, którzy nawet nie spróbowali, bo przeczytali negatywne opinie

Działa tu tzw. błąd przeżywalności - docierają do nas tylko te przypadki, które "przeżyły".

W efekcie, chwaląc się małą liczbą zgłoszeń, kompletnie pomijamy sygnały od niezadowolonych klientów. Oni po prostu odpuszczają i idą do konkurencji. A my dalej żyjemy w przekonaniu, że wszystko jest super, bo nikt nie narzeka.

No cóż, martwi też nie narzekają. 💀

Mierzenie, które daje wartość

Aby faktycznie wyciągać wartość z naszych pomiarów, musimy unikać typowych pułapek.

Po pierwsze, nie możemy patrzeć lokalnie. Musimy widzieć szerszy obraz - nie tylko nasz system, ale też systemy zależne. Nie tylko nasz zespół, ale całą organizację.

Po drugie, trzeba zastanawiać się nad konsekwencjami mierzenia. Łatwo grywalizować metryki, które nie wprowadzają długofalowej wartości.

Po trzecie, nie możemy zrzucać odpowiedzialności na innych. To, że problem leży w innym zespole nie znaczy, że nie jest to nasz problem. Końcowy użytkownik widzi całość, nie pojedyncze kawałki.

Po czwarte, nie skupiajmy się tylko na miarach ilościowych. Liczby to nie wszystko - informacje jakościowe mogą nam powiedzieć o czymś, co trudno skwantyfikować.

Po piąte, mierzmy to, co warto, a nie to, co łatwo zmierzyć. Tak, to wymaga więcej wysiłku. Tak, to trudniejsze. Ale tylko wtedy nasze pomiary będą miały rzeczywistą wartość.

W przeciwnym przypadku możemy skończyć w gorszej sytuacji, niż gdybyśmy w ogóle nie mierzyli.