Jak DevGhost ocenia produktywność deweloperów
Zaktualizowano 23 października 2026
DevGhost niezależnie ocenia produktywność każdego dewelopera na podstawie treści i złożoności poznawczej jego zmian w Git. Właściciele firm i CTO mogą zobaczyć zwrot z inwestycji w rozwój oprogramowania: wykrywać utrzymujący się niski wkład oraz dostrzegać silnych deweloperów, których praca pozostawała niezauważona.
Rozmiar zmiany nie jest miarą nakładu pracy
Dodanie gotowej biblioteki może zająć kilka minut i wygenerować tysiące dodanych wierszy. Niewielka zmiana zachowania w kilku plikach może jednak wymagać zrozumienia zależności, zaprojektowania rozwiązania i starannego sprawdzenia go. DevGhost szacuje pracę inżynierską stojącą za zmianą, aby widoczna aktywność nie zastępowała rzeczywistego wkładu.
Uczenie maszynowe oparte na kodzie
DevGhost łączy uczenie maszynowe i własną sieć neuronową z analizą strukturalną zmian w Git oraz wyspecjalizowanymi algorytmami. Razem szacują wysiłek poznawczy na wspólnej skali dewelopera referencyjnego.
DevGhost nie używa LLM do analizy kodu. Oszacowanie obliczają jego własne wytrenowane modele i algorytmy.
- Zmiany są rozpatrywane w kontekście istniejącego kodu, w tym relacji między zmienionymi częściami i oznak ponownego wykorzystania.
- Rozpoznane zmiany mechaniczne i wygenerowane artefakty są traktowane oddzielnie, aby ich objętość nie uchodziła za nową pracę inżynierską.
- Merytoryczny kod napisany przy wsparciu AI jest oceniany na tej samej skali. Liczy się rezultat przedstawiony w kodzie.
Dwie zmiany, różna praca
Te publiczne commity pokazują, dlaczego sam rozmiar diffu nie wystarcza do oceny wkładu.
k6: gotowe pliki React do testów
Zmiana dodaje ponad 33 000 wierszy, głównie gotowych plików React, aby testy nie zależały już od zawodnego dostępu do sieci. DevGhost oddziela dostarczone pliki od pracy potrzebnej do ich integracji. Oszacowanie DevGhost: około 0,8 godziny referencyjnej.
Zobacz publiczny commitRedis: asynchroniczne operacje wejścia i wyjścia
Około 2300 dodanych i usuniętych wierszy zmienia sposób współpracy wątków Redis: obsługę zdarzeń sieciowych, przekazywanie pracy między wątkami i synchronizację dostępu do danych. Jest to istotna zmiana architektoniczna, która wymaga prawidłowej współpracy kilku części systemu. Oszacowanie DevGhost: około 23 godzin referencyjnych.
Zobacz publiczny commitCo oznaczają godziny referencyjne
Punktem odniesienia jest deweloper średniego szczebla z 3–4-letnim doświadczeniem, który zna projekt i pracuje bez AI. Oszacowanie obejmuje pracę potrzebną do zrozumienia odpowiedniego kodu, zaprojektowania i wdrożenia rozwiązania, sprawdzenia go oraz wprowadzenia niezbędnych poprawek. Obejmuje także samodzielne testowanie: uruchomienie odpowiednich testów i interpretację ich wyników, ręczne sprawdzenie zachowania w razie potrzeby oraz końcowy przegląd własnej zmiany.
Wspólna skala pozwala porównywać wkład deweloperów i obserwować jego zmiany w czasie. Godziny referencyjne opisują szacowaną pracę reprezentowaną przez kod, a nie czas rzeczywiście poświęcony przez autora.
Od godzin referencyjnych do Ghost%
Rozkład oszacowań w czasie opiera się na badaniach empirycznych i praktycznych pomiarach. DevGhost używa wspólnej skali referencyjnej do porównywania wyników. Ghost% pokazuje wynik względem bazy, uwzględniając Share i wybraną metodę liczenia dni. Przy 100% wynik odpowiada bazie; powyżej 100% ją przekracza. Pomoc AI może być jednym z powodów, ale sama liczba nie potwierdza użycia AI.
Uwzględnij kontekst
Analizuj utrzymujące się wyniki w kilku okresach, a następnie przejrzyj zmiany i obowiązki danej osoby. DevGhost nie mierzy rzeczywistych godzin, jakości kodu ani pełnej wartości zawodowej dewelopera. Liczy się również praca poza analizowanymi zmianami. Decyzje kadrowe wymagają niezależnej, merytorycznej oceny człowieka; Ghost% nie może być ich jedyną ani główną podstawą.
Sprawdź historię projektu, który znasz
Wybierz repozytorium i okres, których wyniki zespołu dobrze znasz. Porównaj ocenę DevGhost ze swoim doświadczeniem: kto wniósł duży wkład, gdzie rozwój oprogramowania stale nie spełniał oczekiwań i które trudne zadania pozostały niewidoczne w statystykach aktywności. Otwórz poszczególne zmiany i przeanalizuj zarówno zgodności, jak i rozbieżności. Pozwoli Ci to ocenić przydatność systemu w decyzjach zarządczych na podstawie pracy, którą już znasz.