Pięć wymiarów, dwa pytania. Na każde z nich uczciwa odpowiedź.
Każdy deweloper dostaje dwie liczby zbudowane z tych samych pięciu wymiarów. Wynik odpowiada na pytanie „jak dobry jest ten deweloper?” — Absolute Points na „ile dostarczył?”. Jeden radar nie odpowie na oba pytania, dlatego DevEval trzyma je osobno.
Każdy deweloper oceniany w pięciu ważonych wymiarach.
Oba widoki są zbudowane z tych samych pięciu wymiarów, każdy oceniany przez AI na podstawie realnych pull requestów — kodu, testów, dyskusji w review — nigdy z liczników aktywności.
Jakość kodu
Rzemiosło: pokrycie testami, projekt API, nazewnictwo, obsługa błędów. Jakość, którą reviewer może wskazać palcem — oceniana na każdym PR.
Szybkość
Przepustowość, która coś znaczy: Complexity Units dostarczone na dzień roboczy — nie commity, nie story pointy.
Stabilność
Niezawodność i ryzyko: bugi przypisane z powrotem do kodu, który je spowodował, reverty, hotfixy, wpływ długu technicznego.
Współpraca
Jakość i użyteczność review: czytelne PR-y szanujące czas recenzentów oraz wartościowe, konstruktywne recenzje pracy innych.
Efektywność kosztowa
Koszt na dostarczoną Complexity Unit, mierzony względem baseline'u Twojej organizacji.
Wagi są domyślne i konfigurowalne per organizacja — firma produktowa może podnieść Szybkość, bank Stabilność. Zawsze sumują się do 100.
Wynik odpowiada na „jak dobrze”. Absolute Points — na „ile”.
Te same pięć wymiarów, dwa różne pytania — więc obie liczby celowo zachowują się inaczej.
Jak dobry jest ten deweloper?
Mierzy umiejętności i jakość, nie ilość. Deweloper pracujący dwie godziny dziennie może mieć 95 z Jakości kodu — Wyniku nie obchodzi, ile zostało dowiezione, tylko jak dobre to było. Pokazywany jako radar na tle średniej organizacji, jedna oś na wymiar.
Ile dostarczył?
Mierzą dostarczony output w okresie — każdy przeanalizowany PR dodaje punkty, a punkty się kumulują. Ten sam deweloper na pół etatu wypadnie tu nisko, nawet jeśli jego praca jest znakomita. To liczba stojąca za leaderboardami i ocenami kwartalnymi.
Jedna liczba nie może być jednocześnie ratingiem umiejętności i licznikiem outputu. Udawanie, że może — tak właśnie wprowadzają w błąd narzędzia „engineering analytics”.
Wolumen liczy się tylko wtedy, gdy jakość przekracza poprzeczkę.
Każdy PR zdobywa punkty za velocity proporcjonalnie do swojej jakości. Poniżej poprzeczki te punkty topnieją; jakość poniżej baseline'u organizacji daje ujemne punkty jakości — to kara, nie mniejszy bonus. Ten mechanizm sprawia, że „AI slop” się nie opłaca: zalewanie repozytorium miernym kodem traci punkty, zamiast je farmić.
Developer A
Dowozi 2,5× więcej kodu. Idzie na skróty. Nie robi review.
Developer B
Dowozi mniej. Dowozi lepiej. Robi review dla innych.
Więcej kodu niskiej jakości przegrywa z mniejszą ilością kodu wysokiej jakości — celowo. 2,5× większy wolumen, mniej więcej jedna siódma punktów.
Nikt nie musi przegrać, a brakujących danych nie uzupełniamy domysłami.
Zaufanie do systemu oceny wymaga przejrzystych reguł, które są częścią jego konstrukcji, a nie tylko obietnicą.
Nikt nie jest skazany na przegraną
Wyniki są odnoszone do oczekiwań, zamiast wymuszać podział od najniższego do najwyższego wyniku. Cały mocny zespół może uzyskać wyniki powyżej 80. Nikt nie jest sprowadzany do zera tylko po to, aby ktoś inny mógł uzyskać 100.
Poziom pewności zawsze widoczny
Każdy wymiar ma oznaczony poziom pewności: wysoki (co najmniej 5 przeanalizowanych PR-ów w okresie), średni (od 2 do 4) lub niski (1). Wymiary o niskiej pewności są przedstawiane na wykresie linią przerywaną, a ich niepewność nie jest ukrywana w wyniku.
Brakujące dane są wykluczane, nie zmyślane
Jeśli wymiaru nie da się policzyć w danym okresie, jest pomijany, a wagi pozostałych są odpowiednio przeliczane. Braków nie uzupełniamy średnimi ani wymyślonymi zerami.
Przeliczane co noc
Wyniki są budowane od nowa każdej nocy na podstawie aktualnych analiz PR-ów, bez korzystania z nieaktualnych wyników zapisanych na początku kwartału.
Zobacz radar swojego zespołu.
Podłącz repozytoria i patrz, jak radar pięciu wymiarów buduje się z realnych pull requestów — dla każdego dewelopera, w ciągu 30-dniowego trialu.