Ryzyko manipulacji metrykami

Wprowadzenie

Prawo Goodharta mówi wprost: „Kiedy miara staje się celem, przestaje być dobrą miarą". W kontekście zespołów programistycznych oznacza to, że każda metryka powiązana z oceną ludzi lub decyzjami o premiach może zostać zmanipulowana. Wskaźnik wygląda wtedy dobrze, choć to, co miał mierzyć, się nie poprawia.

Campbell wskazał ten sam mechanizm od strony presji społecznej: im większa presja na dany wskaźnik, tym bardziej się on zniekształca i tym mocniej wypacza procesy, które miał monitorować.

W badaniu wśród praktyków IT (programistów, tech leadów, project managerów) 43,8% respondentów zgłosiło, że zaobserwowało manipulowanie metrykami w swoich organizacjach. W badanej próbie to zjawisko powszechne.

Dlaczego manipulacja jest niebezpieczna

Manipulacja nie polega tylko na zawyżaniu wskaźników. Jej konsekwencje sięgają głębiej:

Optymalizacja proxy zamiast wyniku. Zespół, który goni za pokryciem kodu testami (code coverage), może zacząć pisać testy bez asercji. Wskaźnik rośnie, a jakość zostaje bez zmian. Zespół uczy się, że premiowana jest wartość licznika, nie zawartość testu.

Erozja zaufania. Kiedy ludzie wiedzą, że metryki są manipulowane, przestają im ufać. Managerowie tracą narzędzie diagnostyczne, a zespoły czują się traktowane instrumentalnie. Dialog o jakości zamiera.

Ukryta degradacja jakości. Manipulacja ukrywa problemy pod warstwą „zielonych" wskaźników. Dług techniczny narasta niezauważony, bo dashboard wygląda dobrze. Kiedy problem w końcu ujawnia się w produkcie, naprawa kosztuje wielokrotnie więcej.

Wypieranie wewnętrznej motywacji. Badania z psychologii organizacji (Deci i Ryan) pokazują, że zewnętrzne nagrody i kary związane z metrykami zmniejszają autonomiczną motywację. Ludzie przestają robić „dobrą robotę", a zaczynają robić „robotę na wskaźnik".

Strategie obrony

Nie ma pojedynczego środka, który eliminuje manipulację. Potrzebna jest kombinacja podejść:

Wiele metryk naraz. Pojedyncza metryka jest łatwa do zmanipulowania. Zestaw powiązanych wskaźników (np. velocity + defect escape rate + team satisfaction) tworzy obraz trudniejszy do sfałszowania. Poprawa jednej metryki kosztem drugiej staje się widoczna.

Udział zespołu w doborze metryk. Kiedy ludzie sami wybierają, co mierzyć, traktują pomiar jako narzędzie samooceny, nie nadzoru. Poczucie wpływu ogranicza motywację do manipulowania.

Regularny przegląd i rotacja. Metryki powinny mieć „datę ważności". Co kwartał wraca pytanie: czy wskaźnik wciąż mierzy to, na czym zależy zespołowi, i czy zespół nie obłaskawił go na tyle, żeby obejść?

Uzupełnienia jakościowe. Retrospektywy, rozmowy 1:1, peer review: te mechanizmy wychwytują to, czego sam wskaźnik nie ujmuje. Metryka ilościowa bez kontekstu jakościowego zostawia najwięcej miejsca na obejście.

Transparentność celu pomiaru. Otwarte komunikowanie, po co mierzymy i co zrobimy z wynikami, zmniejsza poczucie zagrożenia. Bierze się ono zwykle z obawy, że spadek wskaźnika oznacza konsekwencje dla konkretnych osób.

Ryzyko manipulacji według grup metryk

Badanie ujawniło wyraźne różnice w podatności na manipulację między grupami metryk. Respondenci, którzy zaobserwowali manipulację, wskazywali grupy, w których ją widzieli. Poniżej rozkład wskazań:

Jakość kodu: ryzyko wysokie

Najczęściej manipulowana grupa: 40,8% wskazań wśród respondentów obserwujących manipulację. Wskaźniki takie jak code coverage, liczba bugów czy złożoność cyklomatyczna są łatwo mierzalne i podatne na obejście. Programista może podzielić dużą funkcję na wiele małych (obniżając cyklomatykę bez realnej poprawy czytelności) albo dodać testy, które technicznie pokrywają kod, ale niczego nie weryfikują. Automatyzacja pomiaru sprawia, że efekt takiej pracy pod wskaźnik jest natychmiastowy i widoczny na dashboardzie.

Relacje i satysfakcja: ryzyko średnie

35,2% wskazań. Metryki relacyjne i satysfakcji (np. eNPS, wyniki ankiet nastrojów) bywają naginane inaczej, przez presję społeczną. Managerowie mogą sugerować „właściwe" odpowiedzi w ankietach, a zespoły mogą zawyżać oceny, żeby uniknąć trudnych rozmów. Manipulacja jest tu społeczna, nie techniczna. Średnie ryzyko wynika z tego, że wymaga koordynacji lub presji grupowej, więc jest trudniejsza niż samodzielne zawyżenie wskaźnika kodu.

Produkt i biznes: ryzyko średnie

31,0% wskazań. Metryki produktowe (np. NPS, retencja, czas wdrożenia funkcji) mają średnią podatność na manipulację. Naginanie ich zwykle wymaga zmiany definicji (co liczymy jako „wdrożoną funkcję"?) lub selektywnego raportowania (pokazujemy tylko kohorty, które wyglądają dobrze). Jest to trudniejsze niż przy metrykach kodu, bo dane produktowe są zwykle agregowane wyżej i audytowane przez więcej osób.

Metryki procesowe i organizacyjne: ryzyko średnie

29,6% wskazań. Wskaźniki takie jak lead time, deployment frequency czy MTTR (Mean Time to Recovery) dają się manipulować przez redefinicję, np. rozbijanie dużego wdrożenia na wiele mniejszych (sztuczne zawyżanie częstotliwości) albo zamykanie incydentów „na papierze" przed faktycznym rozwiązaniem. Ryzyko średnie, bo metryki procesowe są często zbierane automatycznie z narzędzi CI/CD, co ogranicza pole manewru, choć go nie eliminuje.

Jakość wymagań: ryzyko niskie

26,8% wskazań. Metryki jakości wymagań (np. completeness, zmienność zakresu, traceability) są trudne do manipulowania, bo wymagają współpracy wielu stron (PM, dev, QA) i nie przekładają się bezpośrednio na ocenę jednostki. Nikt nie dostaje premii za „niską zmienność wymagań", a tam, gdzie nie ma nagrody za wynik, motywacja do manipulacji jest słabsza.

Wydajność: ryzyko niskie

15,5% wskazań, najniższy wynik ze wszystkich grup. Metryki wydajności (np. response time, throughput, LCP, czyli Largest Contentful Paint) są najtrudniejsze do manipulowania. Mierzy się je automatycznie, obiektywnie i ciągle: system albo odpowiada w 200 ms, albo nie. Manipulacja wymagałaby ingerencji w infrastrukturę pomiarową, co jest kosztowne i ryzykowne.

Podsumowanie

Manipulacji metrykami nie da się wyeliminować całkowicie. Dopóki ludzie są oceniani przez wskaźniki, znajdą sposoby na ich optymalizację. Można jednak świadomie zarządzać ryzykiem:

1. Grupy o wysokim ryzyku (jakość kodu) wymagają szczególnej ostrożności. Łącz je z metrykami trudniejszymi do zmanipulowania i uzupełniaj oceną jakościową (code review, pair programming).
2. Grupy o średnim ryzyku (relacje, produkt, procesy) potrzebują transparentności i rotacji: regularne zmiany zestawu metryk utrudniają adaptację.
3. Grupy o niskim ryzyku (wymagania, wydajność) są bezpieczniejsze, ale nie odporne. Nadal wymagają obserwacji, czy nie pojawiają się nowe sposoby manipulacji.

Metryki najlepiej służą zespołowi jako narzędzie samooceny i doskonalenia. Tam, gdzie pomiar wspiera rozwój, a nie nadzór, presja na manipulację słabnie.

---

Oparte na danych: badanie praktyków IT na polskim rynku (2026). Pełne wyniki: DevMetrics Raport 2026.