Panel metryk AI — 6 liczb które każdy CTO powinien śledzić

Q22 · Strategia i ROI Co mierzysz dla narzędzi AI? (multi-select — 1 pkt każde, max 3)

Maksymalna odpowiedź (3 pkt): Spend ($/dev/miesiąc) i throughput (PR/dev/tydzień) i jakość (bug regression rate, revert rate) i adopcja (active-user %, średnia liczba sesji) i review-to-merge time i cost-per-feature (koszt tokenów na ticket feature’a) — wszystko na jednym panelu.

Dlaczego to ważne: Nie poprawisz tego, czego nie mierzysz. Powyższy zestaw to minimalny panel na 2026 — większość CTO mierzy 1–2 z nich i traci dźwignię, która siedzi w pozostałych.

Dlaczego to ważne w 2026

Narracja z 2025 — “narzędzia AI sprawiają, że developerzy są szybsi, dowożą więcej, tu jest liczba miejsc, tu jest faktura” — się skończyła. W 2026 pytanie, które zadaje każdy board, finanse i CFO jest węższe: które z tych zdań jest faktycznie prawdziwe w tej organizacji inżynierskiej, w liczbach, w tym kwartale? Domyślna odpowiedź, którą większość CTO potrafi dać — “throughput jest w górze, vibes są dobre, tu jest trailing 30-day spend” — nie przeżywa poważnego ROI review. Nie przeżywa też kontaktu z operacyjną rzeczywistością samych narzędzi: PR-y co-authored przez AI dowożą około 1,7× więcej issue’ów niż PR-y human-only, sesje agentic palą 3–10× więcej tokenów niż sesje chatbotowe, a wariancja między najlepszym a najgorszym developerem na narzędziach AI jest dziś większa niż wariancja między najlepszym a najgorszym developerem w ogóle.

Najlepiej mierzalną zmianą branżową między 2024 a 2026 jest to, że zespoły, które mierzą — wygrywają, a te które nie mierzą — są out-shippowane przez zespoły dwa razy mniejsze. Raport Larridin Developer Productivity Benchmarks z 2026 sytuuje elitarne AI-native zespoły na poziomie 80%+ weekly active usage, 60–75% AI-assisted code share i sub-8-godzinnym PR cycle time — to nie są opinie, to dashboardy. Przewodnik Exceeds.ai AI Development Benchmarking dla CTO z 2026 formułuje to samo inaczej: “Dobry benchmark w 2026 mierzy co najmniej trzy z pięciu wymiarów: adopcja, AI code share, complexity-adjusted velocity, jakość kodu i ROI.” Gdy adopcja AI rośnie z 0% do 100% na zespole, publiczne dane branżowe pokazują, że median cycle time spada o 24% (z 16,7 do 12,7 godziny), a średnia liczba PR-ów na inżyniera rośnie o 113% — ale bug rate też idzie w górę o około 9%. Bez instrumentacji nie da się zdecydować, po której stronie tego trade-offu jest Twój zespół. Lecisz na nadziei.

Minimalny panel 2026 to sześć liczb, na jednym ekranie, odświeżane co najmniej tygodniowo: spend per developer per miesiąc, throughput (PR/dev/tydzień), jakość (bug regression rate, revert rate), adopcja (active-user %, średnia liczba sesji), review-to-merge time i cost-per-feature (koszt tokenów na ticket feature’a). Większość CTO w 2026 mierzy jedną lub dwie z nich — zwykle spend i seat-level adoption — i traci dźwignię, która siedzi w pozostałych. CTO Scorecard zatrzymuje Q22 na 3 punktach właśnie dlatego, że każda metryka niezależnie porusza realną decyzję, a panel ma sens dopiero wtedy, gdy widzisz wszystkie sześć trendów jednocześnie: gdy spend rośnie ale throughput nie, gdy adopcja jest płaska ale jakość spadła, gdy review-to-merge time wygląda świetnie ale cost-per-feature rozjechał się, bo wszyscy odpalają Opusa na wszystkim.

Jak naprawdę wygląda maksymalny wynik (wszystkie 6 metryk na jednym dashboardzie)

Dashboard max-score Q22 to jedna strona. Sześć kafli, sześć trendów, jeden rząd headline’owych liczb na górze. Engineering leadership otwiera go w poniedziałek rano, sala wie w ciągu 90 sekund, czy zeszły tydzień był dobry. Każdy kafel ma drill-down. Każda metryka ma ownera.

Spend ($/dev/miesiąc). Trailing 30-day spend tokenów per aktywny developer, rozbity per vendor (Anthropic, OpenAI, Cursor, Copilot) i per model (Opus, Sonnet, Haiku, GPT-5, Gemini). Mediana, 90-ty percentyl i top piątka. Liczba, którą wieszasz na ścianie, to mediana per aktywny developer per miesiąc — outliery są ciekawe, ale to po medianie sterujesz. Skalibruj do zakresu 2026: publiczne dane branżowe o power-userach lokują się na $50–$200/dev/miesiąc dla Claude Code i Cursora łącznie; jeśli Twoja mediana to $10 — masz problem z adopcją, jeśli $400 — masz problem z routingiem.
Throughput (PR/dev/tydzień). Zmerge’owane PR-y per aktywny developer per tydzień, ze średnią kroczącą z 4 tygodni. Krytycznie — rozbij to też na AI-authored vs human-only (używając labela ai-authored z Q11). Sam PR count to vanity metric; PR count rozbity po authorship to leading indicator tego, czy AI faktycznie dowozi pracę, czy tylko generuje szum. Sparuj to z widokiem complexity-adjusted (patrz “gotchas” niżej), żeby PR refaktorowy nie liczył się tak samo jak fix literówki.
Jakość (bug regression rate, revert rate). Dwie liczby. Bug regression rate = bugi zgłoszone w ciągu 14 dni od merge’a / zmerge’owane PR-y. Revert rate = reverty / zmerge’owane PR-y. Obie trended tygodniowo, obie rozbite AI-authored vs human-only. Publiczna liczba 2026 to mniej więcej 9% wyższy bug rate na kodzie AI-authored; chcesz widzieć swoją liczbę na poziomie branżowego baseline’u albo poniżej, nie powyżej.
Adopcja (active-user %, średnia liczba sesji). Weekly active users jako % licencjonowanych seatów, plus średnia liczba sesji per active user per tydzień. Pierwsza liczba mówi Ci, czy płacisz za shelfware; druga — czy ludzie, którzy używają narzędzi, używają ich jako codziennego nawyku czy raz-na-tydzień ciekawości. Elitarne zespoły siedzą na 80%+ WAU i 8–15 sesjach per user per tydzień.
Review-to-merge time. Median czas od otwarcia PR do merge’a, w godzinach. Ten sam podział — AI-authored vs human-only. To najczystszy pojedynczy proxy na “czy AI faktycznie przyspiesza shipping, czy tylko generuje PR-y, które piętrzą się w review?” Elitarne zespoły siedzą poniżej 8 godzin; zespoły w kłopocie siedzą na 30–48 godzinach i nie wiedzą dlaczego.
Cost-per-feature (koszt tokenów na ticket feature’a). Najambitniejsza z szóstki i ta, która spina cały panel. Każdy ticket feature’a w Linear/Jira dostaje całkowity koszt AI — sumę spend tokenów na każdym PR podlinkowanym do tego ticketa. Trended w czasie, pokrojona per zespół i per typ feature’a. To liczba, która odpowiada na pytanie head-of-product “co kosztował nas w AI epik checkout v2?” realną liczbą, nie wzruszeniem ramion.

Na szóstce kafli panel niesie dwie kontekstowe etykiety. Baseline: te same sześć liczb sprzed 90 dni, żeby każdy trend był widoczny od razu. Owner: nazwany człowiek, który jest na haku za ruszenie tej liczby w tym kwartale. Dashboard bez baseline’ów to dekoracja. Dashboard bez ownerów to tapeta.

Aktualny krajobraz (zweryfikowany przez web search)

Spend ($/dev/miesiąc) — skąd to ciągnąć

Spend per developer per miesiąc to fundamentalna liczba. Jest też najłatwiejsza do złego pomiaru, bo większość CTO przyjmuje fakturę vendora jako odpowiedź i zatrzymuje się tam.

Anthropic Console Admin Usage & Cost API (mid-2025) plus Enterprise Analytics API (marzec 2026) dają per-user, per-day, per-model spend z historią do 90 dni. Dla subskrybentów Claude Code API zwraca też commity, PR-y i linie kodu per user — czyli połowę Twojego throughput dashboardu za darmo.
Cursor admin dashboard pokazuje per-member credit consumption per model, z eksportem CSV/REST dla planów Team i Business. Przejście Cursora w 2025 na usage-based credits oznacza, że każda akcja niesie credit cost widoczny dla admina; konwersja credit-to-dollar jest na stronie billingu.
OpenAI usage exports są per-user przez project-scoped API keys (model post-2026). Admin console eksportuje CSV; cross-referencuj user ID przeciwko Twoim git identities po e-mailu.
GitHub Copilot admin pokazuje per-seat activity i acceptance rates, ale spend per seat jest funkcjonalnie zafiksowany planem — więc FinOps interest leży raczej w acceptance rate per dev niż w spend per dev.

Spend ląduje na dashboardzie jako mediana $/active-dev/miesiąc z annotacjami top decyl i bottom decyl. Obie skrajności to sygnał — top spenderzy często korelują z top throughputem, bottom spenderzy zwykle płacą za nieużywany seat. Q4 (Widoczność kosztów) to głębsza wersja tej metryki; Q22 wymaga tylko headline’u.

Throughput (PR/dev/tydzień) — pułapki wokół AI authorship

Throughput wygląda prosto — policz zmerge’owane PR-y, podziel przez aktywnych developerów, podziel przez tygodnie — i jest najczęściej źle mierzoną metryką w panelu.

Ryzyko vanity PR-ów. Bez podziału po authorshipie zespół może wyglądać tak, jakby 2× zwiększył throughput, generując low-value PR-y, których nikt nie zmerge’owałby po starannym przeglądzie. Podział na AI-authored vs human-only to dyscyplina, która temu zapobiega. Użyj labela ai-authored z Q11 (albo commit trailerów), żeby zbucketować każdy PR.
Complexity-adjusted throughput (CAT). Benchmarki branżowe w 2026 coraz częściej używają PR count ważonego trudnością: Easy = 1 pkt, Medium = 3, Hard = 8. Larridin i Exceeds.ai oba publikują używając CAT. Możesz tanio przybliżyć CAT po rozmiarze diffa i liczbie plików (Easy = <50 linii / 1–2 pliki, Medium = 50–300 linii / 3–8 plików, Hard = >300 linii / 9+ plików) albo rygorystycznie tagować ręcznie na próbce. Każde z tych jest lepsze niż surowy PR count.
Mianownik active-developer. Developer, który zmerge’ował zero PR-ów w tym tygodniu, dalej jest w mianowniku, jeśli płaci za seat. Nie wyrzucaj go — to ukrywa problem z adopcją.
Reverty i superseded PR-y. Odejmij je od licznika. PR, który dostaje revert w ciągu 14 dni, nie dowiózł wartości; liczenie go pompuje headline.

Gdy widzisz publikowane liczby typu “średnia PR-ów na inżyniera wzrosła o 113%, gdy adopcja AI rosła z 0% do 100%” — to prawie na pewno surowy PR count. Uczciwa liczba jest bliżej 30–60% na complexity-adjusted throughput — wciąż istotna, ale nie ta z nagłówka.

Jakość (bug regression rate, revert rate)

Jakość to metryka, która zapobiega temu, żeby throughput stał się kłamstwem. Dwie liczby, tygodniowo:

Bug regression rate. Bugi zgłoszone w ciągu 14 dni od merge’a / PR-y zmerge’owane w tym okresie. Okno 14-dniowe to publikowana branżowa konwencja — wystarczająco długie, żeby złapać bugi wywołane zmianą, wystarczająco krótkie, żeby je do niej przypisać.
Revert rate. PR-y zrevertowane w ciągu 14 dni / PR-y zmerge’owane. Czysty sygnał, bo reverty są jednoznaczne.

Obie rozbite po authorshipie. Publikowany baseline 2026 dla kodu AI-authored to około 9% wyższy bug rate i podobne podniesienie na revertach, z issue’ami w kształcie security wyraźnie wyżej (Veracode GenAI Code Security Report 2025 i CodeRabbit State of AI vs Human Code Generation z grudnia 2025 oba sytuują security issues na poziomie około 2,74× human-authored). Liczba, którą chcesz mieć na dashboardzie, to to, czy Twój zespół siedzi na, poniżej, czy powyżej tych baseline’ów branżowych — i w którą stronę idzie trend, gdy zaciskasz review gates (Q9, Q10, Q11).

Adopcja (active-user %, liczba sesji)

Adopcja to pierwsza metryka, która driftuje, jeśli nikt nie patrzy — bo seaty wyglądają “wdrożone” w chwili, gdy są zalicencjonowane.

Weekly active users jako % zalicencjonowanych seatów. Wyciągnięte z admin API vendora. Anthropic, Cursor, OpenAI i Copilot — wszystkie wystawiają per-seat activity. Elitarne zespoły siedzą na 80%+ WAU; mediana zespołu 2026 siedzi na 50–65%; zespoły poniżej 40% płacą za shelfware i nie wiedzą tego.
Średnia liczba sesji per active user per tydzień. “Sesja” jest definiowana przez vendora, ale proxy jest wystarczająco dobre. Codzienny nawyk wygląda jak 8–15 sesji/tydzień; raz-na-tydzień ciekawość wygląda jak 1–2. Różnica między tymi dwoma reżimami to miejsce, gdzie żyją realne zyski produktywności.
Koncentracja power-userów. Przydatna metryka wspierająca: jaki % całkowitego użycia idzie od top 20% userów? Zdrowe zespoły siedzą na 40–60% (wzorzec Pareto); niezdrowe na 80–90% (jeden champion robi całą robotę, reszta milczy).

Cross-referencuj adopcję z Q1 (Adopcja w zespole). Q22 potrzebuje tylko, żeby pomiar był żywy na dashboardzie.

Review-to-merge time

Review-to-merge time to najczystszy pojedynczy wskaźnik tego, czy AI faktycznie przyspiesza shipping, czy tylko generuje PR-y, które się piętrzą.

Definicja. Median czas od otwarcia PR do merge’a, w godzinach, ostatnie 7 i 30 dni. Rozbij po authorshipie.
Źródło. GitHub API (pull_requests.merged_at - created_at) albo cokolwiek ships z Twoją platformą DevEx (Jellyfish, LinearB, DX, Faros, Swarmia).
Benchmarki 2026. Elitarne zespoły poniżej 8 godzin, zdrowe 8–24 godziny, w kłopocie 30–48+ godzin. Publiczne dane branżowe pokazują, że median cycle time spada o 24%, gdy rośnie adopcja AI — ale tylko jeśli review capacity skaluje się razem. Jeśli Twój throughput rośnie, a review-to-merge time rośnie razem z nim — masz bottleneck w review (Q9, Q10) ukryty za zwycięstwem na throughpucie.
Pułapka “ghost-PR”. Niektóre zespoły raportują review-to-merge time dla wszystkich PR-ów łącznie z auto-merge botami (Renovate, Dependabot itd.). Wyłącz je — biasują medianę w dół i ukrywają realne problemy.

Cost-per-feature (połącz tickety Linear/Jira ze spendem tokenów na PR)

Cost-per-feature to najambitniejsza metryka panelu i ta, która zamienia spend w jednostkę-ekonomiczną odpowiedź. Jest też metryką, która wymaga najwięcej hydrauliki, bo wymaga zmostkowania trzech systemów: Twoich danych o koszcie AI (per-PR), Twojego VCS-a (PR-y → tickety) i Twojego trackera (tickety → feature’y).

Reguła łączenia. Koszt AI ticketa = suma kosztu tokenów każdego PR podlinkowanego do tego ticketa. Linki PR → ticket pochodzą z nazw branchy (mjas/PROJ-1234/checkout-v2), wiadomości commitów albo opisów PR-ów. Większość zespołów wymusza jedną z tych konwencji w CI.
Granulacja. Użyteczna jednostka to ticket feature’a (epik albo top-level user-story ticket), nie sub-task implementacyjny. Zagreguj w górę po parent-child relationship w Linear/Jira.
Co to odsłania. Publikowane przykłady 2026 są uderzające: epik checkout-v2 na jednym Series-B fintechu został opublikowany jako $4 200 spendu AI na 47 PR-ach w sześć tygodni — średnio około $90/PR, ale z outlierem $300, który okazał się agentem zapętlonym na flaky teście. Bez widoku cost-per-feature ten PR za $300 jest niewidzialny. Z nim — outlier jest nagłówkiem.
Tooling. CloudZero, Vantage, Holori i Finout wszystkie marketingują AI cost observability w 2026 z alokacją feature-level. Blogpost Nvidia z 2026 Rethinking AI TCO formułuje koszt-per-token jako jednostkę bazową, ale argumentuje — słusznie — że metryką, która znaczy na poziomie executive, jest koszt per output, który biznes obchodzi, co dla inżynierii sprowadza się do cost-per-feature. Framing Gartnera z 2026 dla tego samego problemu zauważa, że modele agentic wymagają 5–30× więcej tokenów niż standardowe chatboty, co czyni per-feature cost-tracking jedyną drogą do utrzymania adopcji agentic na sustainable poziomie.

Sparuj cost-per-feature z tagiem value na tickecie (T-shirt size, business-value rating albo ręczny osąd od PM-a). Para, nie sam koszt, to jest to, po czym sterujesz.

Wdrożenie krok po kroku

Zdecyduj, kto jest ownerem panelu. Jeden nazwany człowiek — zwykle VP Engineering albo head of DevEx — jest ownerem dashboardu, jakości danych i tygodniowego review. Bez nazwanego ownera panel zgnije w kwartał. Jego rola to nie zbudowanie go; jego rola to trzymanie go uczciwym i widocznym.
Zinwentaryzuj źródła danych. Dla każdej z sześciu metryk spisz źródło (Anthropic Admin API, Cursor admin export, GitHub API, Linear API itd.) i credentiale dostępowe. Większość zespołów odkrywa na tym kroku, że nie ma adminowego dostępu do jednego z vendorów — napraw to, zanim pójdziesz dalej. Q3 (Billing zespołowy) i Q4 (Widoczność kosztów) to prekursory; jeśli scoringujesz tam nisko, najpierw obsłuż je.
Wyciągnij 90-dniowy backfill dla wszystkich sześciu. Tydzień danych nie wystarczy — każda metryka potrzebuje co najmniej 90 dni, żeby pokazać trend, idealnie 180. Wciągnij spend, throughput, jakość, adopcję, review-to-merge i cost-per-feature do jednej tabeli (jeden wiersz per developer per tydzień to naturalny grain). Scratchowy BigQuery / Snowflake / DuckDB jest okej; Google Sheet jest okej na pierwszy tydzień, jeśli pcha sprawę do przodu.
Zbuduj podział po authorshipie. To pojedynczy krok modelowania danych o najwyższej dźwigni. Dla każdego zmerge’owanego PR w backfillu otaguj go jako ai-authored albo human-only używając swojego labela (Q11), konwencji commit trailerów — albo, gdy nie masz żadnego z tych — heurystyki na opisie PR / nazwie brancha. Bez podziału throughput i jakość to vanity metrics. Z nim — to decyzje.
Zdefiniuj mianownik active-developer. “Active developer” = ktokolwiek, kto zmerge’ował co najmniej jeden PR w trailing 14 dni. Użyj tego jako mianownika dla spendu per dev, throughputu per dev i active-user %. Zafiksuj to na piśmie, żeby metryka nie driftowała z kwartału na kwartał.
Postaw sześć kafli na jednej stronie. Metabase, Hex, Looker, Grafana, Mode, nawet Notion embedy — tool nie ma znaczenia. Ma znaczenie to, żeby sześć kafli było na jednej stronie, odświeżanych co najmniej tygodniowo, z 90-dniowymi trend lines. Dodaj rząd headline’owych liczb na górze: dzisiejsza wartość i 90-dniowa delta dla każdej. Zrób stronę bookmarkowalną.
Dorzuć cost-per-feature. Najtrudniejszy z szóstki. Zbuduj join od spendu tokenów na PR (pipeline z Q4) → PR → ticket (przez konwencję nazewnictwa brancha) → feature/epik (przez parent links w Linear/Jira). Zacznij od top 20 epików po liczbie PR-ów; rozszerz, gdy join działa.
Annotuj baseline’y i ownerów na każdym kaflu. Każdy kafel pokazuje: dzisiejszą liczbę, 90-dniowy baseline, kierunek ruchu i nazwanego ownera, który jest na haku. Annotacja jest tym, co zamienia wykres w accountability.
Wpisz tygodniowe 20-minutowe review do kalendarza. Engineering leadership + owner panelu. Otwierajcie dashboard. Patrzcie na każdy kafel. Decydujcie jeden action item z panelu na nadchodzący tydzień. Action items są krótkie; dyscyplina dowożenia ich co tydzień składa się procentowo.
Re-shareuj panel kwartalnie z finansami i produktem. Cały sens mierzenia leży w tym, że możesz odbyć rozmowę z finansami o ROI (Q23) i z produktem o cost-per-feature bez wzdrygania się. Raz na kwartał przeprowadź panel przez review CFO/CPO. Ćwiczenie nauczy Cię, którym metrykom faktycznie ufasz, a za którymi się chowałeś.
Dodaj complexity-adjusted throughput w drugim kwartale. Gdy podstawowy panel jest stabilny, dorzuć CAT. Albo przybliż z rozmiaru diffa + liczby plików, albo ręcznie taguj na próbce (50–100 PR-ów per kwartał wystarczy). Przejście z surowego PR count na CAT zwykle odsłania, że “wzrost” throughputu z AI jest mniejszy niż dashboard sugerował — i to dokładnie ten typ odkrycia, dla którego dashboard istnieje.
Wycofuj metryki, na które przestałeś reagować. Jeśli kafel nie wymusił decyzji w kwartał — zabij go albo zastąp. Panel ma sześć liczb nie bez powodu; dyscyplina trzymania go na sześciu liczbach to większość wartości.

Częste pułapki

Vanity metrics bez baseline’u. “Throughput w górze o 30%” — przeciwko czemu? Bez 90-dniowego baseline’u na każdym kaflu dashboard jest dekoracją. Wpiecz baseline w kafel, nie w przypis.
Śledzenie tylko jednej lub dwóch metryk. Większość CTO w 2026 mierzy spend i może adopcję, i tam się zatrzymuje. Dźwignia siedzi w cross-tile odczytach — spend w górę + throughput płaski = problem z routingiem; throughput w górę + jakość w dół = problem z review gate’ami; adopcja w górę + cost-per-feature w górę = problem z wyborem modelu. Tych odczytów nie da się zrobić na dwóch kaflach.
Brak podziału po authorshipie. Bez podziału PR-ów AI-authored vs human-only throughput i jakość są nieinterpretowalne. 9% podniesienie bug rate i 2,74× mnożnik security na kodzie AI-authored to średnie — Twój zespół jest gdzieś na rozkładzie i nie powiesz gdzie bez podziału.
Brak mianownika active-developer. Użycie “ogółu seatów” zamiast “aktywnych developerów” ukrywa problem z adopcją. Użycie “zmerge’ował co najmniej jeden PR w 30 dni” ukrywa wszystkich, którzy spróbowali narzędzi przez tydzień i przestali. Wybierz ścisłą definicję (14 dni, jeden PR) i trzymaj się jej.
Brak kadencji review. Dashboard, który istnieje, ale nikt go nie review’uje, to najdroższy pojedynczy artefakt w org inżynierskiej — zajął tygodnie budowy i nie zmienia żadnych decyzji. 20-minutowy tygodniowy review jest nienegocjowalny. Jeśli leadership nie może zrobić tego spotkania — dashboard nie jest użyteczny.
Framing czystego cost-cuttingu. Q22 nie chodzi o sprowadzanie spendu w dół. Chodzi o uczynienie spendu czytelnym relatywnie do outcome’ów. Zespół, którego spend się podwaja, a cost-per-feature się połowi — wygrywa. Zespół, którego spend stoi płasko i throughput stoi płasko — też przegrywa, tylko wolniej.
Mylenie acceptance rate z adopcją. Copilot raportuje acceptance rate, który niektóre zespoły wieszają na dashboardach jako “AI productivity”. Acceptance rate mierzy, jak często sugestie są przyjmowane; nie mierzy, czy dowiozły wartość. Nie podstawiaj go pod panel; sparuj go z throughputem i jakością.
Budowanie panelu przed bazową instrumentacją. Q22 stoi na Q3, Q4, Q9, Q11. Jeśli nie zrobiłeś billing zespołowego, widoczności kosztów, layered PR review albo labelowania AI-PR — panel będzie wydrążony. Kolejność: napraw prekursory, potem buduj panel.
Przedziały ufności, których nie uznajesz. Z małymi zespołami (<20 developerów) liczby tygodniowe są zaszumione. Trenduj na 4-tygodniowych średnich kroczących i nakładaj confidence bands na kafle; inaczej sala eng-leadership będzie przereagowywać na jeden zaszumiony tydzień.

Jak zweryfikować, że jesteś na miejscu

Wszystkie sześć metryk — spend, throughput, jakość, adopcja, review-to-merge, cost-per-feature — jest widoczne na jednej stronie, odświeżane co najmniej tygodniowo, z 90-dniowymi baseline’ami na każdym kaflu.
Każdy kafel ma nazwanego człowieka na haku za ruszenie liczby w tym kwartale.
Throughput i jakość są rozbite AI-authored vs human-only, i obie liczby potrafisz zacytować z pamięci.
Tygodniowe 20-minutowe review jest w kalendarzu, leadership na nim bywa, z co najmniej jednym action itemem z ostatnich dwóch tygodni dowiezionym.
Najdroższy ticket feature’a ostatniego kwartału jest identyfikowalny po nazwie, z realną liczbą dolarów, nie zakresem.
Gdy CFO pyta “ile kosztuje nas narzędzia AI per zdowieziony feature?” — potrafisz odpowiedzieć w ciągu dwóch minut używając panelu.
Gdy head of product pyta “czy AI przyspiesza zespół?” — potrafisz odpowiedzieć kaflami throughputu i review-to-merge, rozbitymi po authorshipie, zamiast odpowiedzią opartą na vibes.
Co najmniej jedna z Twoich sześciu metryk istotnie ruszyła się w dobrą stronę w ostatnich 90 dniach jako rezultat świadomej zmiany udokumentowanej w tygodniowym review.
Nowy inżynier po zatrudnieniu potrafi przeczytać panel w pięć minut i powiedzieć Ci, w którą stronę zespół trenduje na narzędziach AI.
Panel przeżył review CFO bez konieczności cofania się przez Ciebie z którąkolwiek liczbą — co znaczy, że jakość danych jest na tyle wysoka, że ufasz własnemu dashboardowi.

Dalsza lektura

Q4 · Widoczność kosztów Per-dev + per-repo + per-PR spend tokenów z taggingiem i alertami — fundament pod kaflem spendu.

Q23 · Pomiar ROI Zamień panel metryk w liczbę ROI: koszt na zmerge'owanego PR vs godziny seniora zaoszczędzone.

Q24 · Roadmapa narzędzi AI Użyj panelu do prowadzenia kwartalnej roadmapy narzędzi AI — nie vibes, nie demka vendorów.

Wykonaj CTO Scorecard Zobacz, gdzie stoisz na wszystkich 25 pytaniach.