Scorecard CTO: klucz odpowiedzi

Klucz odpowiedzi do scorecardu CTO wyjaśnia cztery przedziały, poziomy 1–4, które raportuje CTO Scorecard, i przypisuje każde z 25 pytań do strony, która poprawia tę odpowiedź. Jest napisany dla CTO lub VP Engineering, który ma już wynik i musi zdecydować, które mechanizmy kontroli naprawić najpierw i jakim dowodem potwierdzić poprawę.

Wynik mówi Poziom 2 · W parze, 34 punkty na 75, a przegląd budżetu jest za sześć tygodni. Każda sekcja ma luki, a 25 stron z omówieniami pytań to za dużo lektury przed poniedziałkiem. Ten klucz wybiera trzy pierwsze pytania, wskazuje, gdzie każde jest omówione, i nazywa artefakt, który uprawnia do wyższej odpowiedzi.

Co oznacza każdy z przedziałów poziomów 1–4?

Przedziały zapożyczają nazwy z drabiny autonomii, ale mierzą coś innego: mechanizmy kontroli wokół pracy z agentami, tak jak je deklarujesz. Drabina mierzy, jak każda pętla dostarcza zmergowane zmiany, a jedna mapa przekłada to na rozkład na poziomie organizacji. Porównaj z nim zadeklarowany przedział i sprawdź, co naprawdę trafia na produkcję. Odpowiadaj za typowy zespół, nie za najlepszy.

Przedział	Punkty	Co opisuje	Pierwszy ruch
Poziom 1 · Z asystą	0–18	Inżynierowie używają AI wbrew organizacji: niezatwierdzone narzędzia, brak śladu audytowego, wydatki, których nikt nie widzi. Największe ryzyka to incydent compliance i niekontrolowane koszty.	Sekcja 1: zinwentaryzuj, kto czego używa, przejdź na centralnie zarządzane konta i włącz widoczność kosztów per osoba.
Poziom 2 · W parze	19–37	Narzędzia są ustandaryzowane, podstawowe code review działa, każdy programista pracuje z jednym agentem.	Sekcja 2: wspólne reguły agentów, wspólne skille i zarządzane konta zespołowe.
Poziom 3 · Menedżer code review	38–56	Jest warstwowe review, wewnętrzne serwery MCP i metryki. Agenci piszą, inżynierowie recenzują.	Sekcje 4 i 6: praca równoległa z limitami współbieżności i sfinansowana roadmapa z bramkami stop.
Poziom 4 · Menedżer specyfikacji	57–75	Dostarczanie napędzają zaakceptowany zamiar i dowody, prawo do akceptacji zależy od ryzyka, zakłady o nowe możliwości mają bramki stop, a ciągłość przy zmianie dostawcy jest przećwiczona.	Doskonal pętlę, którą masz. Scorecard nie ma przedziału dla poziomu 5; prowadzenie fabryki oprogramowania to decyzja dla konkretnej pętli, a nie cel punktowy.

Jak wybrać trzy pierwsze pytania do poprawy?

Podziel punkty każdej sekcji przez jej maksimum. 6 na 15 w sekcji 3 (40%) to większa luka niż 6 na 9 w sekcji 4 (67%), choć punktów jest tyle samo.
Weź dwie sekcje z najniższym odsetkiem. W każdej wybierz pytanie, w którym twoja odpowiedź jest najdalej od 3 punktów.
Jeśli sekcja 3 ma mniej niż połowę punktów i nie jest już jedną z tych dwóch, dodaj jej najsłabsze pytanie; w przeciwnym razie weź najsłabsze pytanie z sekcji z trzecim najniższym odsetkiem. Równoległa i nienadzorowana praca agentów (sekcja 4) mnoży pull requesty, które muszą przejść przez bramki. Podniesienie sekcji 4 przed sekcją 3 przenosi wąskie gardło do kolejki code review.
Dla każdego pytania zapisz w pliku planu poniżej docelową odpowiedź i artefakt, który ją udowodni. Wyznacz jednego właściciela na pytanie.
Wypełnij scorecard ponownie po 30 dniach. Porównuj odsetki sekcji, nie przedział: pytanie, które przeszło z 1 na 3 punkty, rzadko zmienia przedział, ale widać je w jego sekcji.

Zacommituj plan do repozytorium z konfiguracją platformy agentów, żeby każda jego zmiana przechodziła review jak każda inna:

# ai-scorecard/plan.yaml — jeden wpis na każde pytanie, nad którym pracujesz
- question: 9          # Co dziś sprawdza wasze PR-y automatycznie?
  current_points: 1
  target_points: 3
  target_answer: "Checki deterministyczne, skupione review ryzyka, odtwarzalne dowody i nazwana osoba akceptująca, proporcjonalnie do wpływu"
  evidence: "Eksport branch protection z listą wymaganych checków; trzy zmergowane PR-y agenta z dołączonym pakietem dowodów"
  owner: "platform-lead"
  check_on: 2026-10-26

Która strona odpowiada na które pytanie?

Każda tabela podaje pytanie, stronę do przeczytania najpierw i drugą, oraz dowód, którego wymaga odpowiedź za 3 punkty. Pytania 4, 10 i 21 linkują od razu do strony tematycznej, bo ich strony z omówieniem pytania są do niej włączane.

Adopcja i wydatki (pytania 1–4, 12 punktów)

#	Pytanie	Przeczytaj	Dowód na 3 punkty
1	Jak szeroko i skutecznie zespół używa zatwierdzonych workflow AI?	Adopcja w zespole · Onboarding i adopcja w zespołach	Ukończone zatwierdzone workflow u uprawnionych inżynierów, z danymi o zaakceptowanych wynikach, jakości i kontrolach
2	Jaka jest polityka narzędzi?	Polityka narzędzi · Jedna polityka dla wszystkich agentów	Macierz zatwierdzonych workflow i wyjątki z datą wygaśnięcia oraz zapisem sprzątania
3	Jak zarządzacie kontami AI, cyklem życia dostępu, warunkami danych i kosztami?	Konta zespołu · Kwestionariusz zakupowy	Nazwany właściciel każdej usługi, działające procesy dołączenia, zmiany roli i odejścia, przejrzane warunki danych, audytowalne koszty
4	Czy potraficie połączyć pełny koszt workflow AI z zaakceptowanymi wynikami i jakością?	Zarządzanie kosztami użycia AI · Koszt zaakceptowanej zmiany	Pełny koszt na zaakceptowany wynik, z budżetami, alertami i nazwanym właścicielem

Wspólna infrastruktura (pytania 5–8, 12 punktów)

#	Pytanie	Przeczytaj	Dowód na 3 punkty
5	Czy zespół ma wspólne reguły dla agentów?	Wspólne reguły agentów · Współpraca zespołowa	Wersjonowany wspólny rdzeń z przetestowanymi adapterami per narzędzie, a twarde wymagania egzekwowane poza modelem
6	Czy zespół współdzieli skille?	Wspólne skille · Budowanie własnych skilli	Każdy skill ma właściciela, przypadki testowe: pozytywne, negatywne i brzegowe oraz dane o użyciu
7	Czy wewnętrzne serwisy MCP bezpiecznie zamykają zmierzone, powtarzalne luki w dostępie?	Wewnętrzne serwery MCP · Wprowadzenie do MCP	Każdy serwer wynika ze zmierzonej luki i ma właściciela, minimalne uprawnienia, monitoring i kryteria wycofania
8	Jaki jest wasz model bezpieczeństwa MCP?	Bezpieczeństwo MCP · Tożsamość agentów i sekrety	Przejrzana allowlista, autoryzacja per narzędzie, krótkotrwałe poświadczenia, logi audytowe i jawna zgoda na zapisy

Bramki jakości (pytania 9–13, 15 punktów)

#	Pytanie	Przeczytaj	Dowód na 3 punkty
9	Co dziś sprawdza wasze PR-y automatycznie?	Automatyzacja review PR · Code review PR-a agenta	Wymagane checki deterministyczne, skupione review ryzyka, odtwarzalne dowody i nazwana osoba akceptująca, proporcjonalnie do wpływu
10	Jak radzicie sobie z przepustowością ludzkiego review przy PR-ach od agentów?	Governance i autonomia · Kolejka code review	Granice ustalone na etapie projektu, automatyczne bramki dowodów, review ludzkie zależne od ryzyka i metryki kolejki
11	Jak zapisujecie pochodzenie zmiany i kierujecie PR-y według ryzyka?	Pochodzenie zmiany i routing ryzyka · Pakiet dowodów	Metadane PR o zamiarze, dotkniętych systemach, danych i odwracalności kierują akceptacje; autorstwo zostaje do pomiaru
12	Jakie są wymogi E2E przy zmianach UI?	Polityka E2E · Weryfikacja w przeglądarce przez agenta	Przebieg w przeglądarce według kryteriów akceptacji z zachowanymi artefaktami; ścieżki krytyczne przeniesione do deterministycznych testów w CI
13	Czy agenci są częścią samego CI/CD?	AI w CI/CD · Od zgłoszenia do pull requesta	Agent przygotowuje, recenzuje i testuje w pipeline; checki deterministyczne blokują PR; nazwana osoba zachowuje prawo do merge i do produkcji

Równoległość w skali zespołu (pytania 14–16, 9 punktów)

#	Pytanie	Przeczytaj	Dowód na 3 punkty
14	Czy zespół uruchamia równoległe zadania agentów w izolowanych worktree?	Paralelizm zespołu · Równoległe agenty w worktree	Izolowany stan każdego zadania, zmierzony limit współbieżności, właściciel integracji i limit kolejki recenzentów
15	Czy uruchamiacie zadania agentów bez nadzoru według harmonogramu lub zdarzenia?	Przebiegi agentów bez nadzoru · Backlog dla agentów	Wyselekcjonowany backlog niskiego ryzyka, ograniczona liczba prób, zachowane dowody i review przed merge lub jakimkolwiek działaniem zewnętrznym
16	Jak zespół klasyfikuje i promuje szybko generowane prototypy?	Polityka prototypów · Governance i autonomia	Kryteria awansu dla każdej klasy ryzyka: dane, właściciel, testy, bezpieczeństwo, obserwowalność i rollback

Wzmacnianie organizacji (pytania 17–21, 15 punktów)

#	Pytanie	Przeczytaj	Dowód na 3 punkty
17	Czy zmiany wrażliwe wymagają zaakceptowanego zamiaru, specyfikacji i planu przed wykonaniem?	Polityka planowania · Plan: zapisz intent.md	Zaakceptowany zamiar, specyfikacja i plan przed dostępem do zapisu; hook lub job CI je weryfikuje; nazwana osoba zatwierdza ryzykowne działania
18	Jak zarządzacie wspólnymi hookami agentów i ich adapterami per narzędzie?	Zarządzanie wspólnymi hookami · Jedna polityka dla wszystkich agentów	Wersjonowane, przejrzane hooki z minimalnymi uprawnieniami, przypadkami testowymi, stopniowym wdrożeniem, logami audytowymi i przetestowanym rollbackiem
19	Ile czasu mija, zanim nowy inżynier ma produktywny workflow z AI?	Onboarding developera · Ścieżka dewelopera	Test onboardingu (`fixture`), który przechodzi w ciągu jednego dnia roboczego, bez współdzielonych sekretów
20	Jak zespół dzieli się wiedzą o narzędziach AI?	Dzielenie się wiedzą · Jak utrzymać zespół na bieżąco	Wersjonowane wzorce z właścicielami i dowodami, aktualizowane na podstawie review i incydentów
21	Czy zarządzacie danymi i compliance dla każdej zatwierdzonej usługi i workflow AI?	Prywatność danych i polityki firmowe · Standardy bezpieczeństwa i zgodność	Przegląd przepływu danych dla każdej usługi: minimalizacja, retencja, audyt, obsługa incydentów, mapowanie prawne i cykliczna ponowna akceptacja

Strategia i ROI (pytania 22–25, 12 punktów)

#	Pytanie	Przeczytaj	Dowód na 3 punkty
22	Co mierzycie w obszarze narzędzi AI?	Panel metryk AI · Frameworki metryk	Co najmniej trzy z: koszt, przepustowość, jakość, adopcja, czas od review do merge, koszt funkcji, każda przeglądana według harmonogramu
23	Czy macie liczbowe ROI z narzędzi AI?	Koszt zaakceptowanej zmiany · ROI toolingu AI	Dopasowane kohorty bazowa i bieżąca: zaakceptowany lead time, jakość, wynik i pełny koszt, z zapisaną niepewnością
24	Czy macie roadmapę narzędzi AI na 6–12 miesięcy?	Mapa drogi dla organizacji · Pozycja portfela w roadmapie	Roadmapa z właścicielem, hipotezy o nowych możliwościach z bramkami awansu i stop, kwartalny przegląd i budżet
25	Jak zarządzacie ryzykiem dostawców?	Zarządzanie ryzykiem vendora · Jak uniknąć uzależnienia od dostawcy	Przetestowany fallback i tryb ograniczonego działania, eksportowalne artefakty, przegląd umowy i lokalizacji danych oraz ćwiczenie odtworzenia

Jak udowodnić wyższą odpowiedź bez czytania każdego diffa?

Każda odpowiedź za 3 punkty wskazuje artefakt, a nie zamiar: eksport branch protection, log audytowy, pakiet dowodów przy zmergowanych PR-ach, raport kosztów, zapis ćwiczenia odtworzenia. Deklaruj wyższą odpowiedź tylko wtedy, gdy możesz podlinkować ten artefakt. Właściciel z pliku planu go przygotowuje, a druga osoba, na przykład lider platformy albo dział bezpieczeństwa, sprawdza go przed ponownym wypełnieniem scorecardu. Przy bramkach jakości żądaj pakietu dowodów; czytanie dowodów zamiast kodu wyjaśnia, dlaczego zastępuje on review linia po linii.

Agent może zebrać dowody za ciebie, jeśli działa tylko do odczytu. Nie polegaj na samym prompcie: uruchom agenta w trybie, który każde narzędzie do tego udostępnia, w repozytorium, którego bramki oceniasz.

Rozpocznij sesję w trybie planowania, w którym agent analizuje i planuje bez edytowania plików: claude --permission-mode plan (sprawdzone w claude --help, v2.1.283). Wklej poniższy prompt.

Uruchom prompt nieinteraktywnie w piaskownicy tylko do odczytu: codex exec --sandbox read-only "<prompt>" (sprawdzone w codex exec --help, v0.157.1).

Sam tekst promptu jest taki sam we wszystkich trzech narzędziach.

Read-only task. Do not edit files, run git commands that write, or call any network API.
I am answering CTO Scorecard questions 9, 11, 12 and 13 for this repository. For each question, list the evidence that exists in the repo today:
- CI workflow files and the checks they run on pull requests (name each job and what it fails on)
- PR templates or scripts that require intent, affected systems, data class, risk, or test evidence
- Browser or E2E test suites, and whether CI runs them on UI changes
- Any agent step in CI, the permissions it has, and whether a human approval gates merge or deploy
Cite each item as path:line. Then state, per question, which answer on a 0-3 scale the evidence supports and what is missing for 3. Say "not found" rather than guessing.

Branch protection i wymagani recenzenci są w ustawieniach hostingu Git, nie w repozytorium, więc wyeksportuj je osobno i dołącz do tego samego wpisu w planie.

Kiedy wynik scorecardu wprowadza w błąd?

Oceniłeś zamiary. Dokument polityki, którego nikt nie egzekwuje, dostaje tę samą odpowiedź co egzekwowana bramka, jeśli na to pozwolisz. Naprawa: każdą odpowiedź, której nie potwierdzasz podlinkowanym artefaktem, oceń o punkt niżej. Ten spadek to twój prawdziwy punkt startu.
Odpowiedziałeś za najlepszy zespół. Jeden zespół platformowy z pipeline’ami strzeżonymi dowodami nie robi z dziesięciu zespołów produktowych poziomu 3. Naprawa: odpowiadaj za typowy zespół.
Pytanie 22 stało się liczeniem checkboxów. Sześć miar, których nikt nie przegląda, daje 3 punkty i nie wspiera żadnej decyzji. Naprawa: zostaw tylko miary powiązane z decyzją, którą wywołały w ostatnim kwartale, zdefiniowane jak we frameworkach metryk.
Sekcja 4 urosła przed sekcją 3. Więcej równoległych i nocnych przebiegów agentów przy tej samej przepustowości review: kolejka rośnie, a recenzenci zaczynają akceptować bez czytania dowodów. Naprawa: ogranicz współbieżność, najpierw popraw pytania 9 i 10, dopiero potem podnieś limit.
Przedział stał się celem. Skok z poziomu 2 na 3 w jednym kwartale potraktuj jako sygnał, by sprawdzić każdą zmienioną odpowiedź z jej artefaktem. Naprawa: raportuj kierownictwu odsetki sekcji z artefaktami, a nie przedział. Format pokazuje raportowanie do zarządu.

Dokąd iść dalej z wynikiem scorecardu CTO

Wypełnij CTO Scorecard 25 pytań, około 8 minut: przedział poziomów 1–4, plan na 30, 60 i 90 dni oraz rejestr trzech największych ryzyk.

Ścieżka CTO Uporządkowany plan czytania dla CTO i VP Engineering: model operacyjny, mechanizmy kontroli, pomiar.

Model operacyjny Kto odpowiada za harness, bramki i ewaluacje, gdy plan z tej strony już działa.

Scorecard tech leada: klucz odpowiedzi Te same decyzje w skali jednego zespołu, dla liderów, którzy realizują twój plan.