Polowanie na duchy: jak zobaczyć rzeczywisty wkład deweloperów

„Ghost engineers” — co dziesiąty deweloper praktycznie nie robi nic użytecznego, a jedynie przekonująco udaje zapracowanego. Prawdziwe przyczyny tej bezczynności — praca na boku, wypalenie albo zwykłe obijanie się — mogą bardzo długo pozostawać niewidoczne dla kierownictwa. (Badanie Stanforda z 2024 roku: oryginalny wątek)

Deweloperzy nie lubią, gdy zaczyna się rozmowa o ich efektywności. Po długich „złotych latach” tego zawodu w branży narosło tabu wokół prostego pytania: czy rezultat pracy inżynierskiej uzasadnia zainwestowany czas i pieniądze? Ale deweloperów również irytują koledzy-duchy — i zwykle to zespół, a nie kierownictwo, zauważa problem jako pierwszy.

W Rosji od dawna nie wypada „donosić”. Dlatego o problemie może wiedzieć wiele osób, ale nikt nie chce o nim mówić: po co wtrącać się w cudze konflikty? Wszystko wychodzi na jaw dopiero wtedy, gdy cierpliwość zespołu już się skończyła.

A może po prostu dać im spokój — tym duchom? Przecież firma nawet nie zauważy tych pieniędzy.

Jest tylko jeden haczyk…

Mówiąc o niskiej efektywności, nie mam na myśli sytuacji, w której Jan siedzi, dwoi się i troi, a mimo to robi o 10% mniej niż Piotr. Chodzi o coś innego: na każdym stand-upie cały zespół wysłuchuje kolejnej chwytającej za serce historii — inny zespół zawiódł, wymagania były niejasne, gwiazdy się nie ułożyły. Ale jutro zadanie na pewno będzie gotowe. Słowo honoru.

Tyle że to „jutro” było już wczoraj i przedwczoraj — i zdążyło stać się tradycją.

Zespół szybko dostrzega takie rzeczy. Ludzie, którzy naprawdę ciągną pracę, zaczynają sobie zadawać oczywiste pytanie: po co harować, skoro można opowiadać bajki i nie ponosić żadnych konsekwencji?

Samo zauważenie problemu jednak nie wystarczy. Bez liczb i faktów rozmowa szybko zamienia się w spór: zespół mówi „on pracuje słabo”, a deweloper odpowiada „nie pozwalają mi pracować”. Zwykle ktoś zaczyna wyjaśniać sytuację dopiero wtedy, gdy cierpliwość już się wyczerpała i zespół prosi bezpośredniego przełożonego o wymianę dewelopera.

Wtedy zaczyna się długa epopeja: zebrać fakty, wysłuchać obu stron, przekazać człowiekowi informację zwrotną i dać czas na poprawę. Z mojego doświadczenia najczęściej kończy się to przejściem ducha do nowego — i bardzo szczęśliwego — pracodawcy.

Problem nie polega wyłącznie na tym, że jedna osoba robi mniej. Firma płaci dwa razy: najpierw za pracę, która nie została wykonana, a potem za czas współpracowników i menedżerów, którzy wszystko sprawdzają, asekurują i próbują zrozumieć przyczyny. Ostatecznie słabiej działa już nie jeden deweloper, lecz cały zespół.

Czy menedżer może zauważyć problem wcześniej — dostrzec odchylenie, poprosić o kontekst i wyjaśnić sytuację, zanim zespół straci cierpliwość, a firma czas i pieniądze?

Przy odpowiednim doświadczeniu takie historie można rozpoznać z wyprzedzeniem po charakterystycznych wzorcach zachowania:

• Sukcesy są moje, porażki są twoje.
• Usprawiedliwianie porażki zadania, nad którym praca jeszcze się nie zaczęła.
• Brak kompetencji rekompensowany nadmierną gadatliwością.
• Z czasem to właśnie menedżer coraz częściej staje się wskazywanym „winowajcą”.
• W przeciwieństwie do osoby, która naprawdę ma trudności, takie zachowanie nie zmienia się na lepsze nawet po bezpośredniej informacji zwrotnej.

Do zweryfikowania podejrzeń potrzebny jest jednak cyfrowy ślad.

Przyjrzyjmy się najpopularniejszym narzędziom do oceny efektywności pracy inżynierskiej i sprawdźmy, czy pomagają wykrywać duchy.

Zanim je porównam, zaznaczę oczywisty konflikt interesów: czytasz oficjalny blog DevGhost, a ja jestem założycielem produktu. To autorska analiza, nie niezależne badanie.

Do oceny efektywności samego wytwarzania oprogramowania — nie całej firmy ani produktu — używam prostej triady: szybkość, jakość i wolumen pracy. Szybkość pokazują metryki DORA, jakość — testy i defekty. Z wolumenem jest trudniej: to najmniej rozpoznany obszar i właśnie tam ukrywają się duchy, których szukamy.

DORA: szybkość i niezawodność wydań

DORA pokazuje, jak szybko i niezawodnie zespół dostarcza zmiany na produkcję. Model obejmuje pięć metryk: czas od commita do produkcji, częstotliwość wdrożeń, odsetek wdrożeń powodujących awarie, czas przywrócenia oraz odsetek nieplanowanych poprawek.

To dobra ocena procesu delivery, ale nie indywidualnego wkładu. Jeśli jedna osoba pracuje za trzy, a druga chowa się za wspólnym wynikiem zespołu, DORA tego nie pokaże.

Te metryki są też niezwykle wygodne jako KPI. W jednej z firm, w których pracowałem, wyciskano je od 2018 roku: wszystkie dashboardy skutecznie malowano na zielono i wszyscy byli zadowoleni. Aktualny model DORA.

Testy i defekty: jak dobrze wykonano pracę

Te metody są znane od dawna i sprawdzają się w praktyce. Jakość kontroluje się przez code review, testy i analizę statyczną, a skutki śledzi za pomocą defektów i incydentów.

Sygnały te nie mówią jednak nic o wolumenie. Jedna niewielka, bezbłędna poprawka zmieni wszystkie wskaźniki na zielone — a duch pozostanie niewidoczny.

Jira i story points: ile zadań zamknięto

Jira pokazuje zamknięte zadania i story points, ale wyceny ustala sam zespół. Tę samą pracę można wycenić na trzy albo trzynaście punktów, podzielić na pięć zadań albo połączyć w jedno.

Story points są przydatne w planowaniu, ale nie sprawdzają się jako miara indywidualnego wkładu. Gdy punkty stają się celem, ludzie zaczynają optymalizować pracę pod punkty.

Jako KPI też są wygodne. Dane są wpisywane, a zadania przesuwane wyłącznie po to, by przejść przez bramki jakości. Mnóstwo bezsensownej pracy ręcznej.

Commity i linie kodu: fakty bez kontekstu

Git nie zależy od wycen zespołu, więc liczenie commitów i linii kodu wydaje się kuszące. Ale pięć commitów może oznaczać jedną drobną poprawkę, a jeden squash commit — tydzień pracy.

Formatowanie, generowanie, kopiowanie i przenoszenie kodu zawyżają liczbę linii, podczas gdy trudna poprawka może zajmować zaledwie dziesięć.

Swarmia, LinearB i Waydev: cały system inżynierski w jednym miejscu

Swarmia, LinearB i Waydev łączą dane z Git, systemu zadań oraz CI/CD. Menedżerowie widzą metryki DORA, kolejki do review, czas przejścia zmian i wyniki ankiet.

Daje to użyteczny obraz systemu inżynierskiego — i często pokazuje, że problem leży w procesie, a nie w człowieku. Porównywalny wolumen pracy konkretnego dewelopera nie jest jednak głównym pytaniem, na które odpowiadają te platformy. Swarmia, LinearB, Waydev.

GitClear: co zostaje po odfiltrowaniu szumu w kodzie

GitClear odróżnia dodawanie, przenoszenie i kopiowanie kodu, wyklucza pliki wygenerowane oraz uwzględnia, czy nowy kod został później przepisany lub usunięty.

W ten sposób powstaje Diff Delta — własna jednostka GitClear opisująca znaczące zmiany, które pozostały w bazie kodu. Kod skopiowany lub szybko wyrzucony waży mniej niż zwarta zmiana, która nadal działa na produkcji. Jak działa Diff Delta.

Diff Delta nie odpowiada na pytanie, ile pracy było potrzebne. Mówi, ile znaczących zmian pozostało po odfiltrowaniu szumu i poprawek. GitClear najlepiej radzi sobie z mierzeniem trwałości i jakości kodu oraz z analizą wpływu AI.

Robi się cieplej. Usługa publikuje benchmarki, lecz Diff Delta pozostaje jej własną jednostką: liczba 10 000 niewiele mówi bez odpowiedniego porównania i znajomości metodyki. Nie ma tu wyraźnego punktu odniesienia w rodzaju „100% to norma”. Benchmarki Diff Delta.

BlueOptima: to samo pytanie w skali korporacyjnej

BlueOptima znam z własnego doświadczenia. Zacząłem pracę z tą platformą w 2019 roku. To właśnie to doświadczenie zainspirowało mnie do stworzenia własnego produktu.

Algorytm Coding Effort analizuje każdą zmianę kodu źródłowego za pomocą zestawu metryk statycznych, uwzględnia jej rozmiar, złożoność i powiązanie z resztą kodu, a wynik wyraża w godzinach.

Pozwala to porównywać deweloperów z różnych zespołów i stosów technologicznych, także z globalnym benchmarkiem. Dla mnie była to pierwsza przekonująca próba odpowiedzi nie na pytanie „Ile linii napisał ten deweloper?”, lecz „Ile istotnej pracy kryje się za tymi zmianami?”. Metodyka BlueOptima, globalny benchmark.

W moim przypadku uzyskanie tych korporacyjnych możliwości wymagało dość ciężkiego wdrożenia: agent musiał działać w zamkniętym środowisku sieciowym, cena była wysoka, a wyniki wymagały interpretacji eksperta.

Dla firmy zatrudniającej tysiące deweloperów może to mieć sens. Dla startupu lub małego zespołu — raczej nie. Ta luka stała się później jednym z powodów powstania DevGhost.

Ta sama miara, bez przetargu

Tworząc DevGhost, nie próbowałem budować kolejnej platformy zawierającej wszystkie możliwe metryki inżynierskie.

Chciałem uzyskać tę samą odpowiedź, którą dawała BlueOptima — ile istotnej pracy kryje się za zmianami — ale w formie dostępnej dla właściciela startupu lub małego zespołu bez przetargu, długiego wdrożenia i armii konsultantów.

Logika jest prosta: DevGhost analizuje same zmiany — co dodano, usunięto i przebudowano oraz jak trudno było stworzyć i zweryfikować rezultat. Formatowanie, przenoszenie kodu, masowe automatyczne zamiany i kod wygenerowany są oddzielane od istotnej pracy.

Wynikiem jest szacunek nakładu pracy wyrażony w godzinach ekwiwalentnych: tyle czasu potrzebowałby deweloper średniego szczebla, który zna bazę kodu i pracuje bez AI, aby napisać taki sam kod. Nie jest to rzeczywisty czas spędzony przy klawiaturze ani ocena jakości lub wartości biznesowej kodu, lecz wspólna miara do porównywania zmian. Więcej o metodyce DevGhost.

Ghost% porównuje ten szacunek z oczekiwanym wynikiem dewelopera średniego szczebla, uwzględniając, jaką część czasu dana osoba rzeczywiście poświęca na programowanie. Wynik 100% oznacza zgodność z normą. Niższy wynik jest powodem, by przyjrzeć się przyczynom; wyższy warto zbadać i być może przekształcić w dobrą praktykę.

Punkt odniesienia celowo zakłada pracę bez AI. DevGhost nie próbuje ustalać, kto napisał konkretny fragment — człowiek, Copilot czy autonomiczny agent. Ocenia końcowe zmiany: ile wysiłku potrzebowałby deweloper średniego szczebla, aby stworzyć je i sprawdzić bez pomocy AI.

Dzięki temu wpływ AI nie znika wewnątrz metryki, lecz staje się widoczny. Jeśli w danym okresie deweloper tworzy i weryfikuje rezultat, który wcześniej wymagałby dwu- lub trzykrotnie większego wysiłku, Ghost% to pokaże. Formatowanie, masowe generowanie i inny szum w kodzie nie powinny dawać takiego samego efektu.

A kto oceni oceniającego?

Najbardziej oczywiste pytanie brzmi: dlaczego w ogóle ufać ocenie maszyny? Krótka odpowiedź: nie należy ufać jej bezkrytycznie.

Ocena trudności pracy jest z definicji subiektywna. Sprawdziliśmy to: daliśmy te same zmiany kilku doświadczonym deweloperom i otrzymaliśmy zauważalnie różne liczby. Każdy ma inne tempo, doświadczenie i wyobrażenie o tym, co jest trudne.

DevGhost również może się mylić. Jego przewagą nie jest dostęp do prawdy absolutnej, lecz to, że każda zmiana jest oceniana według tej samej miary — bez sympatii, zmęczenia czy wyrobionej wcześniej opinii o autorze.

Dlatego Ghost% jest sygnałem, a nie wyrokiem. Niski wynik może oznaczać niewielki wkład, ale może też wynikać z obowiązków tech leada, pracy architektonicznej, mentoringu, incydentów lub blokad.

Liczba pokazuje, gdzie warto zadać pytanie. Odpowiedzi nadal musi poszukać menedżer — ale może już oprzeć się na niezależnej drugiej opinii, a nie tylko na intuicji.

„I tak wiem, jak pracuje każda osoba w moim zespole”

Jeden z klientów DevGhost jest liderem technicznym szybko rosnącej firmy AI. Początkowo sceptycznie podchodził do samego pomysłu mierzenia efektywności pracy inżynierskiej. Jego stanowisko było proste: dobry lider techniczny wie bez dashboardu, jak pracuje każda osoba.

Przeanalizowaliśmy historię repozytorium, które dobrze znał. Już wcześniej pojawiały się obawy dotyczące trzech deweloperów: ich zadania posuwały się wolno, ale pracowali nad oddzielną usługą, więc trudno było porównać ich z resztą zespołu. DevGhost pokazał u całej trójki stale niski wynik przez mniej więcej pół roku.

Później, gdy deweloperzy zaczęli odchodzić, okazało się, że przez cały ten czas równolegle budowali własne produkty. DevGhost nie mógł znać przyczyny. Pokazał jedynie coś, czego nie było widać po liczbie commitów, pull requestach i codziennych rozmowach na Slacku: wolumen ich pracy był zauważalnie niższy od oczekiwanego.

Analiza nie zmieniła się jednak w listę osób do zwolnienia. W przypadku dwóch innych deweloperów niski wynik pomógł przekazać konkretną informację zwrotną, znaleźć przyczyny i poprawić efektywność. Obaj zostali w zespole.

Deweloperzy, których uważał za mocnych, również znaleźli się dokładnie tam, gdzie się ich spodziewał. Teraz widział nie tylko, kto osiąga ponadprzeciętne wyniki, ale także jak regularnie to robi.

Jeden przypadek oczywiście nie dowodzi dokładności metody. Klienta zaskoczyło jednak, jak dobrze ogólny obraz pokrywał się z tym, co wcześniej było znane jedynie na poziomie intuicji, a w niektórych przypadkach stało się oczywiste dopiero po fakcie.

A jeśli jeden deweloper dostarcza wynik za trzech?

Polowanie na duchy to najbardziej widowiskowa część tej historii. Górna część wykresu może być jednak bardziej użyteczna.

Jeśli deweloper regularnie dostarcza wynik kilkukrotnie wyższy od średniego, warto ustalić, jak dokładnie to osiąga.

Dziś pytanie nie brzmi już, czy deweloper korzysta z AI — dla wielu stało się ono zwykłym elementem pracy. Pytanie brzmi, jak skutecznie dana osoba zamienia agentów w dodatkową moc wytwórczą.

Jedna osoba ogranicza się do autouzupełniania. Inna potrafi przekazać agentom właściwy kontekst, ustalić jasne zasady, prowadzić kilka zadań równolegle i uważnie sprawdzać rezultat. Taki sam dostęp do AI może więc dawać zupełnie różny wzrost produktywności.

Wysoki Ghost% pomaga znaleźć deweloperów, u których współpraca człowieka z agentami już przynosi świetne wyniki — i zrozumieć, które praktyki może przejąć reszta zespołu.

Jeśli wysoki wynik znajduje potwierdzenie w jakości pracy i ocenie menedżera, takiego dewelopera warto docenić, zatrzymać i rozważyć jego awans. Jego praktyki warto natomiast badać i upowszechniać w zespole.

Nie zamieniajmy miary w pałkę

Każdą metrykę spotyka ten sam los: wcześniej czy później ktoś próbuje zrobić z niej KPI. Ghost% się do tego nie nadaje.

Zrób z Ghost% KPI zespołu, a ludzie zaczną optymalizować pod niego pracę. Opublikuj ranking, a zaufanie zniknie. Zamień wynik w przycisk do zwalniania, a błędy staną się nieuniknione.

Ustaliłbym cztery zasady:

• Nie wyciągać wniosków z pojedynczego pomiaru ani krótkiego okresu.
• Uwzględniać rolę danej osoby, część jej czasu przeznaczoną na programowanie oraz pracę wykonywaną poza kodem.
• Pokazywać wynik deweloperowi i dawać mu możliwość wyjaśnienia kontekstu.
• Nie używać Ghost% jako jedynej podstawy decyzji kadrowej.

Jeśli niski wynik utrzymuje się przez dłuższy czas, menedżer powinien najpierw poznać przyczyny. Być może dana osoba rzeczywiście sobie nie radzi. A być może zajmuje się architekturą, ratuje cudze incydenty albo blokują ją procesy zespołu.

Jeśli problem się potwierdzi, potrzebny jest konkretny plan poprawy i ponowna ocena po uzgodnionym czasie.

Rezygnacja z metryk nie oznacza rezygnacji z oceniania ludzi. Zamiast liczb zostają po prostu odczucia, historie ze stand-upów i osobiste sympatie menedżera.

Szybkość, jakość i wolumen wymagają różnych narzędzi. DORA pokazuje drogę zmian na produkcję. Testy i defekty pokazują jakość. DevGhost dodaje szacunek pracy kryjącej się za zmianami w kodzie.

Żadna z tych metryk nie powinna podejmować decyzji za menedżera.

Wartość liczby nie polega na tym, że wydaje wyrok. Polega na tym, że trudna rozmowa zaczyna się wcześniej i opiera się na faktach.

Jak oceniasz wolumen pracy deweloperów — i gdzie przebiega dla ciebie granica między użyteczną przejrzystością a inwigilacją?