|
Cześć MailingR, tu Jarek 👋
Czy kiedykolwiek mierzyłeś/mierzyłaś coś tylko dlatego, że łatwo to zmierzyć, a duża wartość podbija ego?
Coś koło roku 2017. Pracowałem wtedy jako szeregowy deweloper w średniej wielkości firmie. Nasz team lead, jedyna osoba z uprawnieniami do mergowania bez checków w CI, właśnie wyjechał na majówkę do Chorwacji.
"Kodzik musi mieć co najmniej 80% pokrycia testami, inaczej nie można mergować do developa." - brzmi jak rozsądna zasada, prawda?
Tymczasem musieliśmy zrobić pilny release. Zmiana była banalna - aktualizacja jednej linii w configu. Po zrobieniu PR okazało się jednak, że pokrycie testami spadło o 0.3% poniżej magicznego progu 80%.
Co zrobiliśmy?
1. Usunęliśmy kilka pustych linii z kodu, ify zamieniliśmy na jednolinijkowce
2. Dodaliśmy test sprawdzający czy stała ma... stałą wartość (tak, serio)
3. Voilà! Coverage wrócił do 80.2% i mogliśmy mergować
👉 nie rozwiązaliśmy żadnego problemu
👉 nie poprawiliśmy jakości kodu
👉 nie zwiększyliśmy rzeczywistego pokrycia funkcjonalności testami
Po prostu spełniliśmy arbitralny wymóg narzucony przez system.
To klasyczny przykład vanity metrics - metryki, która wygląda dobrze na papierze, ale nie przekłada się na rzeczywistą wartość.
Vanity metrics to wskaźniki, które:
- Wyglądają imponująco w raportach
- Łatwo je manipulować
- Niekoniecznie przekładają się na rzeczywistą wartość biznesową
- Często prowadzą do optymalizacji niewłaściwych zachowań
---
W marketingu klasycznymi przykładami są liczba followersów czy wyświetleń strony. W zespołach developerskich mamy swoje odpowiedniki.
---
✅ vanity metrics w zespołach programistycznych:
1 / Pokrycie kodu testami (test coverage)
Test coverage to jak BMI w medycynie - może być użytecznym wskaźnikiem, ale nigdy nie powinien być jedynym kryterium. 100% pokrycia może oznaczać zarówno świetnie przetestowany kod, jak i
bezsensowne testy sprawdzające czy 2+2=4.
💬 Dlaczego to vanity metric? Ponieważ prowadzi do pisania testów dla samych testów, a nie dla zapewnienia jakości.
2 / Liczba pull requestów
"Nasz team zrobił w tym sprincie 73 PR-y!" - brzmi nieźle.
Ale czy te PR-y faktycznie dostarczały wartość? Czy może były to drobne poprawki, które można było zgrupować? A może właśnie powinno być ich więcej, ale niektóre zmiany były zbyt duże i trudne do przejrzenia?
💬 Dlaczego to vanity metric? Bo zachęca do dzielenia pracy na sztuczne jednostki, które pasują do metryki, a nie do logicznego podziału zadań.
3 / Liczba zamkniętych ticketów/zadań
Podobnie jak z PR-ami, liczba zamkniętych zadań może prowadzić do sztucznie małych tasków lub, co gorsza, do "kreatywnego" interpretowania definicji "done".
💬 Dlaczego to vanity metric?
Bo zadania o różnej złożoności są liczone tak samo, a zespoły są zachęcane do wybierania łatwych zadań.
4 / Story pointy
"Dostarczyliśmy 120 story pointów w tym sprincie!" I co z tego?
Story pointy miały być względną miarą złożoności, ale często zmieniają się w system, gdzie 1 story point = 1 man hour.
💬 Dlaczego to vanity metric? Ponieważ prowadzi do inflacji story pointów i optymalizacji pod system punktowy, a nie pod rzeczywistą wartość.
5 / Liczba commitów
Jeszcze bardziej absurdalna metryka niż powyższe. Liczba commitów nie mówi nic o jakości, wartości ani nawet ilości wykonanej pracy.
💬 Dlaczego to vanity metric? Bo można ją łatwo zmanipulować przez częstsze commitowanie mniejszych zmian.
---
Co faktycznie warto
mierzyć?
Najlepsza metryka, z jaką miałem okazję prasować, to czas od pojawienia się wymagań do dostarczenia rozwiązania do klienta.
To złożony wskaźnik, który:
- Wymaga współpracy między biznesem a developerami
- Obejmuje cały proces, nie tylko kodowanie.
- Bezpośrednio przekłada się na wartość biznesową
- Jest cholernie trudny do zmanipulowania.
Co jeszcze warto wziąć pod uwagę? 👇
- Rzeczywisty wskaźnik błędów na produkcji
- Częstotliwość deploymentów (ale bez presji na ich liczbę)
- Czas naprawy krytycznych błędów (MTTR)
To, co mierzymy, determinuje to, co optymalizujemy. Jeśli mierzymy niewłaściwe rzeczy, będziemy optymalizować niewłaściwe zachowania.
A jeśli kiedykolwiek przyłapiesz się na podbijaniu metryki, by podpić metrykę - wiedz, że coś poszło nie tak.
|
