Co ten KPI incentywizuje
To jest serce tego tekstu. Bo KPI rzadko jest po prostu wskaźnikiem. KPI jest systemem zachęt. Mierząc X, mówisz ludziom: optymalizuj pod X.
Co się dzieje, gdy mierzysz stosunek linii AI do linii ludzkich?
Scenario 1: Generuj więcej AI-kodu, nie usuwaj. Masz zadanie. Możesz napisać 50 eleganckich linii - albo poprosić AI o 300 rozwlekłych. Wynik funkcjonalny: identyczny. Wpływ na KPI: ogromny. Wybór jest oczywisty... jeśli masz zły system motywacyjny.
Scenario 2: Pomijaj refaktor. Refaktoryzacja to usuwanie kodu - zmniejsza licznik. AI-generowany kod po refaktorze jest "bardziej ludzki" (mniej AI-wierszy zostaje). Oba ruchy psują KPI. Więc po co refaktorować?
Scenario 3: Verbosity over elegance. Dobry programista pisze zwięźle. AI potrafi pisać zwięźle - ale może też pisać rozwlekle. Jeśli KPI nagradza ilość, nagradzasz verbosity. "Czytelność kodu"? "Maintainability"? Nikt nie pyta.
Scenario 4: Ukrywanie AI. Niektóre organizacje, które słyszałem o tym KPI z komentarzy pod postem, zrobiły coś odwrotnego niż zamierzały - programiści zaczęli ukrywać użycie AI, żeby nie "zepsuć" stosunku na swoją niekorzyść, bo obawiali się oceny.
Chciałeś zmierzyć adopcję AI. Zmierzyłeś coś zupełnie innego i wywołałeś zachowania, których nie chciałeś wywołać.
Goodhart's Law - po ludzku
Jest prawo, które ekonomiści znają od lat, a organizacje wciąż odkrywają na nowo.
Goodhart's Law: kiedy miara staje się celem, przestaje być dobrą miarą.
Po ludzku: jak tylko powiesz, że mierzysz X - ludzie przestają robić to, co dawało X jako efekt uboczny. Zaczynają robić X bezpośrednio. I tracisz informację, którą X miało dawać.
Trzy przykłady z życia organizacyjnego - nie z AI:
Ilość zamkniętych ticketów jako KPI działu supportu. Efekt: support zamykał zgłoszenia bez rozwiązania problemu, bo "rozwiązanie" nie było mierzone. Klienci zgłaszali ten sam problem wielokrotnie. Tickety zamknięte - zadowolenie klientów na dnie.
Story points w sprincie jako miara velocity. Efekt: story points zaczęły rosnąć niezależnie od rzeczywistej pracy. Każde zadanie było "bardziej skomplikowane niż myśleliśmy". Team velocity wzrosła o 40% - a nic nie dostarczano szybciej.
Liczba spotkań z klientami dla handlowców. Efekt: handlowcy organizowali spotkania, które nie miały sensu biznesowego, żeby wyrobić normę. Relacje były słabsze, bo klienci czuli, że jest to gra w liczby.
Ten sam mechanizm. Inna skala. Zawsze ten sam efekt.
Czym naprawdę mierzyć adopcję AI w zespole deweloperskim
Dobrze. Więc jak mierzyć? Bo "nie mierzymy" to też nie jest odpowiedź.
Lista mierników, które rzeczywiście coś mówią:
| Co mierzyć | Dlaczego to ma sens |
|---|---|
| Time to feature | Czy AI przyspiesza dostarczanie wartości do użytkownika? |
| Defect rate (błędy na produkcji) | Czy AI-generowany kod jest jakościowy? |
| Deployment frequency | Czy zespół dostarcza częściej dzięki AI? |
| Developer Experience Score | Czy programiści czują się bardziej produktywni i zadowoleni? |
| Code review cycle time | Czy AI skraca czas review czy go wydłuża (bo kod jest nieczytelny)? |
| Lead time for changes | Czas od pomysłu do produkcji - czy AI go skraca? |
To są metryki z DORA (DevOps Research and Assessment) - sprawdzone, oparte na badaniach, niezależne od tego, kto (lub co) pisze kod. Warto dodać zastrzeżenie: badania DORA opierają się w dużej mierze na danych deklaratywnych (self-reported) i mają swoje ograniczenia metodologiczne. Nie są dogmatem - są dobrym punktem startowym.
Żadna z nich nie pyta "ile linii napisało AI". Wszystkie pytają: "czy lepiej dostarczacie wartość?"
To jest właściwe pytanie.
Czemu organizacje wpadają w tę pułapkę
Nie dlatego, że zarząd jest głupi. Naprawdę.
Jest kilka mechanizmów, które prowadzą do takich KPI:
Presja na "coś mierzalnego". Zarząd inwestuje w AI i chce wiedzieć, czy to działa. To uzasadnione. Problem: "mierzalne" jest łatwiejsze do osiągnięcia niż "wartościowe". Liczba linii kodu jest mierzalna od razu - deployment frequency wymaga narzędzi i kultury.
KPI jako substytut zrozumienia. Kiedy lider nie rozumie technologii, KPI staje się protezą. "Nie wiem, co to robi, ale wiem, że liczba rośnie." Wskaźnik zastępuje wiedzę. To jest wygodne i niebezpieczne jednocześnie.
Cargo cult adopcji. "Inne firmy mierzą AI. My też musimy mierzyć AI." Kopiujemy formę bez treści. Mamy KPI, mamy dashboard, mamy liczby na slajdzie dla zarządu. Że te liczby nie mówią nic o rzeczywistości - tego na slajdzie nie widać.
Czas i trudność. Dobre metryki wymagają inwestycji: narzędzia do mierzenia, kultura otwartości na dane, umiejętność interpretacji. Zły KPI można wdrożyć w tydzień.
Jeden z komentarzy pod oryginalnym postem był celny: "W mojej firmie mamy KPI z liczbą linii kodu od lat 90. Dodaliśmy do tego AI. I teraz mamy dwa złe KPI zamiast jednego."
Pytanie na koniec
Jakie KPI w Twojej organizacji mierzą aktywność zamiast wartości?
Masz kandydatów? Pewnie tak. Każda organizacja ma. Różnimy się tylko tym, czy ktoś ma odwagę powiedzieć to głośno na spotkaniu z zarządem.
I tu jest drugie pytanie: jeśli wiesz, że jakiś wskaźnik jest bezsensowny - co Cię powstrzymuje od tego, żeby to powiedzieć?
Bo problem z KPI mierzącym linie kodu AI nie jest techniczny. Jest organizacyjny. Ktoś to zaproponował. Ktoś to przyjął. Ktoś teraz raportuje te liczby co kwartał.
I wszyscy przy stole wiedzą, że to jest absurd.
Tylko nikt nie mówi tego głośno.