Jak zmieniają się zespoły, role i zatrudnienie

Projekt organizacji inżynierii agentowej wyznacza wielkość zespołów według zdolności weryfikacji, a nie według tego, ile kodu ludzie potrafią napisać. Agenci zwiększają tempo napływu zmian, więc wąskimi gardłami stają się przepustowość code review, pokrycie ewaluacjami i odpowiedzialni właściciele. Decyzje o zatrudnieniu wynikają z tych zmierzonych ograniczeń, a nie z mnożnika produktywności podanego przez dostawcę.

Ta strona jest dla członków zarządu i CTO, którzy dostali pytanie o zatrudnienie, na które jeszcze nie umieją odpowiedzieć: rada nadzorcza przeczytała, że w niektórych firmach agenci piszą większość kodu, a twoje zespoły scalają więcej pull requestów niż kiedykolwiek i coraz dłużej czekają na review.

Co możesz wdrożyć w swoim projekcie organizacji

Arkusz przepustowości code review, który zamienia tempo napływu pull requestów i strukturę ryzyka na godziny recenzentów, więc widzisz, które ograniczenie jest wiążące, zanim zmienisz zespół.
Karty ról dla trzech ról, które dochodzą w zespołach agentowych (harness engineer, właściciel ewaluacji i operator fabryki), wraz z obsadą przy 8, 40 i 200 inżynierach.
Tabelę decyzji o zatrudnieniu, która przypisuje decyzje do zmierzonych sygnałów i nie zawiera żadnego mnożnika.
Politykę uwolnionej przepustowości do przyjęcia bez zmian, aby zaoszczędzony czas trafiał tam, gdzie sam zdecydujesz.
Definicje metryk, które pokazują, czy nowy kształt działa, oraz kto zatwierdza każdą z nich.

Co mówią dowody o kształcie zespołów

Generowanie skaluje się szybciej niż weryfikacja. Telemetria Faros AI z 22 000 deweloperów i ponad 4000 zespołów (kwiecień 2026) pokazuje ukończone epiki na dewelopera +66,2% i przepustowość zadań na dewelopera +33,7%, a obok tego medianę czasu w review +441,5%, pull requesty scalane bez żadnego review +31,3% i incydenty na pull request +242,7%. Pracy przybywa, a jej weryfikacja spada na recenzentów.

Fundamenty organizacji decydują, kto zyskuje. Raport DORA 2025 (Google Cloud, 2025-09-23) wiąże adopcję AI z wyższą przepustowością dostarczania i niższą stabilnością. Jego wyjaśnienie: „Teams working in loosely coupled architectures with fast feedback loops see gains, while those constrained by tightly coupled systems and slow processes see little or no benefit” (zespoły z luźno powiązaną architekturą i szybką informacją zwrotną zyskują, a te ograniczone ściśle powiązanymi systemami i powolnymi procesami — niewiele albo nic).

Praca przesuwa się w stronę review, a recenzent zostaje. W wewnętrznym badaniu Anthropic obejmującym 132 inżynierów i badaczy (2025-12-02, deklaracje pracowników samego dostawcy) część inżynierów opisuje przesunięcie swojej pracy „70%+ to being a code reviewer/reviser rather than a net-new code writer” (w ponad 70% w stronę recenzowania i poprawiania kodu zamiast pisania nowego). Stripe scala co tydzień ponad 1300 pull requestów „completely minion-produced, human-reviewed, but containing no human-written code” (wytworzonych w całości przez agentów, zrecenzowanych przez ludzi, bez ani jednej linii napisanej przez człowieka; blog inżynierski Stripe, 2026-02-19). Usunięcie pisania nie usunęło recenzenta.

Wniosek projektowy jest prosty. Kiedy generowanie jest tanie, rzadkim zasobem stają się ludzie, którzy potrafią ocenić, czy zmiana jest poprawna, wyrocznie weryfikacyjne, dzięki którym ocenią to bez czytania każdej linii, oraz właściciele odpowiadający za wynik.

Dobieraj wielkość zespołów do przepustowości code review, a nie do ilości kodu

Przepustowość zespołu była kiedyś liczbą zmian, które inżynierowie potrafili napisać. Z agentami jest to liczba zmian, które zespół potrafi zweryfikować i za które weźmie odpowiedzialność. Zaplanuj ją w trzech krokach.

Zmierz tempo napływu. Pobierz z repozytorium scalone pull requesty z ostatnich 8–12 tygodni. Poniższe polecenie uruchamiasz w terminalu z GitHub CLI; zapisuje jeden wiersz na pull request: numer, autor, otwarcie, pierwsze review, scalenie, zmienione linie, liczba różnych recenzentów-ludzi i ich loginy.
Okno terminala
```
gh pr list --state merged --limit 1000 \
  --search "merged:>=2026-07-01" \
  --json number,author,createdAt,mergedAt,additions,deletions,reviews \
  --jq '.[] | . as $pr
    | [.reviews[] | select((.author.login // "ghost") != $pr.author.login
        and ((.author.login // "ghost") | test("\\[bot\\]$|^app/|copilot|codex|claude|bugbot"; "i") | not))] as $h
    | [.number, .author.login, .createdAt,
       ([$h[].submittedAt] | min), .mergedAt,
       (.additions + .deletions),
       ([$h[] | .author.login // "ghost"] | unique | length),
       ([$h[] | .author.login // "ghost"] | unique | join(","))] | @tsv' \
  > review-load.tsv
```
Filtr pomija review autora jego własnego pull requesta i boty recenzujące, bo review bota ani samego autora nie jest review wykonanym przez człowieka. Sprawdź loginy botów we własnym eksporcie i dopisz te, których wzorzec nie łapie; wzorzec pomija też każdy ludzki login zawierający te słowa, więc przejrzyj listę. Pusta kolumna pierwszego review przy zerze recenzentów oznacza wtedy pull request scalony bez review człowieka. Policz je najpierw.
Wyceń każdą zmianę według klasy ryzyka. Użyj czterech klas ryzyka (niska, średnia, wysoka, krytyczna) ze strony governance i autonomia i ustalcie, ile minut kompetentny recenzent potrzebuje na zmianę w każdej klasie, łącznie z przeczytaniem pakietu dowodów. Zmierz pięć prawdziwych review na klasę zamiast szacować.
Porównaj popyt z chronioną podażą. Podaż to godziny tygodniowo, które każdy recenzent faktycznie rezerwuje na review, liczone tylko dla osób uprawnionych do zatwierdzania danej klasy. Zmiany wysokie i krytyczne mają zwykle znacznie mniej uprawnionych zatwierdzających niż zmiany klasy niskiej.

Poniższy arkusz to przykład poglądowy z okrągłymi liczbami, a nie benchmark. Zastąp każdą wartość własnym pomiarem. Praca tylko do odczytu, która nie wymaga review przed scaleniem, została pominięta. Trzej zatwierdzający dla klas wysokiej i krytycznej należą do ośmiu recenzentów, więc 48 godzin podaży jest wspólne dla wszystkich trzech kolumn.

Wiersz	Niska (odwracalne)	Średnia (współdzielone środowiska nieprodukcyjne)	Wysoka i krytyczna (produkcja lub regulacje)	Razem
Scalone PR tygodniowo	36	18	6	60
Minuty review na PR	10	30	90	—
Popyt na review, godziny tygodniowo	6	9	9	24
Uprawnieni recenzenci	8	8	3	—
Chronione godziny na recenzenta	6	6	6	—
Podaż review, godziny tygodniowo	48 (wspólne)	48 (wspólne)	18	48
Wykorzystanie	—	—	50%	50%

Przy 60 pull requestach tygodniowo ten zespół ma zapas. Jeśli agenci podwoją tempo napływu, a nic innego się nie zmieni, popyt dojdzie do 48 godzin: 100% wykorzystania kolejki. Kolejka nie pogarsza się stopniowo, gdy wykorzystanie zbliża się do 100%; czas oczekiwania rośnie gwałtownie, a recenzenci zaczynają zatwierdzać bez czytania. To prawdopodobny mechanizm stojący za liczbami Faros o czasie review i scaleniach bez review.

Masz teraz trzy dźwignie i żadna z nich nie brzmi „zatrudnij więcej autorów”:

Skróć minuty na PR dzięki mocniejszym wyroczniom i pakietowi dowodów, tak aby recenzent oceniał dowody, a nie linie.
Przenieś klasę ryzyka na review oparte tylko na dowodach przez etapowy protokół transferu zaufania, gdy jego wyrocznia na to zasłuży.
Ogranicz napływ limitami WIP i budżetami rozmiaru PR, tak jak opisuje to strona o kolejce code review.

Read review-load.tsv (tab-separated: pr number, author, created_at,
first_review_at, merged_at, lines_changed, distinct_reviewers,
reviewers (comma-separated)). Bots and self-reviews are already removed.
Treat an empty first_review_at with 0 reviewers as merged without review.
Per ISO week, report: merged PRs, median and p90 hours from created_at to
first_review_at, median lines_changed, share merged without review, and the
top 5 reviewers by number of PRs reviewed, with their share of reviewed PRs.
Then flag any week where median time to first review rose more than 25%
week over week, and any reviewer on more than 30% of reviewed PRs.
Output one markdown table and five bullet findings. Do not speculate about
causes you cannot see in the data.

Czym jest stosunek budujących do weryfikujących?

Stosunek budujących do weryfikujących to udział godzin inżynierskich zespołu poświęcanych na wywoływanie zmian w porównaniu z godzinami poświęcanymi na rozstrzyganie, czy zmiana jest poprawna. To liczba, która pokazuje, czy schemat organizacyjny pasuje do pracy z agentami.

Pole	Definicja
Godziny budowania	Pisanie intencji i specyfikacji, prowadzenie agentów, poprawianie tego, czego agenci nie dali rady zrobić, kod pisany ręcznie
Godziny weryfikacji	Review pull requestów i dowodów, pisanie i utrzymanie testów, ewaluacji i kryteriów akceptacji, analiza defektów, które przeszły na produkcję
Stosunek	Godziny budowania ÷ godziny weryfikacji, na zespół, na miesiąc
Źródło	Dwutygodniowa próbka czasu raz na kwartał (bloki w kalendarzu plus znaczniki czasu review), a nie ciągłe śledzenie
Właściciel	Engineering manager zbiera dane; CTO przegląda trend w zespołach
Czytaj razem z	Medianą czasu w review i change failure rate z tego samego okresu

Żaden opublikowany benchmark nie podaje „właściwego” stosunku, więc nie przyjmuj żadnego. Czytaj trend. Jeśli agenci przejmują coraz więcej budowania, a stosunek nie przesuwa się w stronę weryfikacji, praca weryfikacyjna albo się nie odbywa, albo chowa się w zatwierdzeniach „na pieczątkę”. Jeśli stosunek przesuwa się w stronę weryfikacji, a czas w review i tak rośnie, twoje wyrocznie są za słabe i każde review oznacza pełne czytanie kodu.

Jakich nowych ról potrzebują zespoły agentowe?

Gdy agenci piszą większość kodu, pojawiają się trzy obowiązki. Zaczynają jako zadania na część etatu i stają się rolami, gdy organizacja rośnie. Każdą definiuje to, o czym dana osoba decyduje, a nie tytuł na wizytówce.

Rola	Odpowiada za	Decyduje	Mierzona przez
Harness engineer	Wspólną konfigurację agentów: pliki instrukcji, skille, hooki, konfigurację serwerów MCP, profile sandboxa i uprawnień, pętle CI, w których pracują agenci	Jakie możliwości dostają agenci i które sprawdzenia uruchamiają się, zanim zapyta się człowieka	Udział przebiegów agentów, które przechodzą bramki bez ludzkich poprawek; czas wdrożenia zmiany harnessu we wszystkich repozytoriach
Właściciel ewaluacji	Wyrocznie dla jednej domeny: testy akceptacyjne, testy własności, sprawdzenia oceniane przez model, zestaw regresyjny dla samej konfiguracji agentów	Czy sprawdzenie jest na tyle mocne, by zastąpić ludzkie czytanie w danej klasie ryzyka	Defekty z domeny wykryte po wydaniu; mutation score lub odsetek wykrytych celowo wstrzykniętych błędów
Operator fabryki	Pętle bez nadzoru: kolejkę, budżety, warunki stopu, rejestr autonomii, wstrzymywanie i wycofywanie pętli	Kiedy pętla rusza, zatrzymuje się albo traci autonomię	Odsetek udanych przebiegów pętli, koszt zaakceptowanej zmiany, czas zatrzymania źle działającej pętli

Te role nie mają własnego prawa do scalania. Odpowiedzialnym człowiekiem za zmianę pozostaje wskazany assignee i code owner. Linear wpisał tę zasadę w swój produkt w 2025 roku: „issues can only be assigned to humans, and only delegated to agents” (zgłoszenia można przypisywać tylko ludziom, a agentom jedynie delegować; Linear, 2025-08-01). Agenta nie da się pociągnąć do odpowiedzialności, więc projekt organizacji musi wskazać, kto odpowiada.

Obsada zależy od skali. To punkty wyjścia do dostosowania, a nie proporcje z badań.

Wielkość inżynierii	Harness engineer	Właściciel ewaluacji	Operator fabryki
Około 8 osób (jeden zespół)	Jeden inżynier, jeden dzień w tygodniu, rotacja co kwartał	Tech lead dla krytycznej domeny zespołu	Niepotrzebny, dopóki nie ruszy pierwsza pętla bez nadzoru
Około 40 osób (pięć zespołów)	Jedna lub dwie osoby w funkcji platformowej	Jeden na krytyczną domenę, na część etatu, wpisany do rejestru autonomii	Jedna osoba prowadzi rejestr pętli i dyżur dla pętli
Około 200 osób	Zespół platformowy agentów, który prowadzi harness jak produkt	Wskazany właściciel dla każdej domeny z chronionym czasem; ewaluacje przechodzą review jak kod	Mały zespół dyżurny z tym samym procesem incydentów co usługi produkcyjne

Strona o modelu operacyjnym umieszcza te role w macierzy RACI dla całego łańcucha artefaktów, a strona o ścieżkach kariery opisuje, jak je nagradzać, żeby najlepsi inżynierowie chcieli je pełnić.

Jak zmienia się rozpiętość kierowania?

Rozpiętość kierowania mierzono kiedyś liczbą ludzi. Z agentami obciążenie menedżera to liczba decyzji review, pętli i incydentów, za które odpowiada zespół, a jeden inżynier nadzorujący kilku równoległych agentów generuje popyt na review kilku inżynierów.

Trzy zasady utrzymują rozpiętość w rozsądnych granicach:

Licz pętle, nie tylko ludzi. Każda pętla bez nadzoru w rejestrze autonomii dodaje popyt na review i ścieżkę incydentową. Pięcioosobowy zespół z ośmioma pętlami nie jest małym zespołem.
W każdym zespole utrzymuj jednego właściciela na krytyczną domenę. Gdy agenci szybko poruszają się po całym kodzie, wiedza domenowa skupia się w coraz mniejszej liczbie głów. Wskaż właściciela i zastępcę, zanim zespół się zmniejszy.
Świadomie chroń dopływ talentów. Wewnętrzne badanie Anthropic (2025-12-02) opisuje „paradox of supervision” (paradoks nadzoru): nadzór nad agentami wymaga umiejętności, które nadmierne delegowanie osłabia. Zespół bez juniorów nie ma przyszłych recenzentów. Zobacz stronę o rozwoju juniorów.

Gdzie przesuwa się granica między produktem a inżynierią?

Gdy budowanie trwa godziny, wąskie gardło przesuwa się w górę strumienia: do decyzji, co budować i jak poznać, że jest dobrze. Boris Cherny z Anthropic przewidział, że tytuł software engineer zamieni się w „builder” albo „product manager” (relacja z drugiej ręki: The San Francisco Standard, 2026-02-19, cytujący podcast). Traktuj to jako prognozę. Decyzja projektowa, przed którą stoisz dziś, jest węższa: kto pisze który artefakt.

Artefakt	Pisze	Zatwierdza	Dlaczego taki podział
Intencja: problem, użytkownik, dlaczego teraz	Produkt	Lider inżynierii, pod kątem wykonalności i klasy ryzyka	Produkt odpowiada za „dlaczego”; inżynieria sygnalizuje, ile będzie kosztować weryfikacja
Kryteria akceptacji w formie przykładów	Produkt i inżynieria razem	Właściciel ewaluacji	Stają się wyrocznią, więc muszą być testowalne
Projekt i klasa ryzyka	Inżynieria	Code owner albo przegląd architektury dla klas wysokiej i krytycznej	Architektura decyduje, ile przyspieszenia zespół zachowa (DORA 2025)
Implementacja	Agenci prowadzeni przez inżynierów	Sprawdzenia, potem wskazany recenzent	Decyzja człowieka to akceptacja, a nie autorstwo
Wydanie produkcyjne	Platforma	Wskazany właściciel dla klas wysokiej i krytycznej	Rozdział obowiązków przetrwa zmianę

Największa praktyczna zmiana polega na tym, że product managerowie sami piszą kryteria akceptacji. Roadmapę i priorytetyzację opisuje strona Zarządzanie produktem, gdy budowanie trwa godziny.

Planuj zatrudnienie bez mnożników

Mnożnik produktywności zamienia nadzieję w zamrożenie rekrutacji. Planuj na podstawie zmierzonych ograniczeń. Zanim użyjesz tej tabeli dla zespołu, zbierz dla niego co najmniej 8 tygodni poniższych metryk i czytaj wiersze po kolei: wygrywa pierwszy pasujący.

Sygnał mierzony przez 8+ tygodni	Co oznacza	Decyzja o zatrudnieniu
PR są scalane bez review poza zatwierdzoną klasą ryzyka „tylko dowody”	Kontrola nie działa	Nie zmieniaj niczego w organizacji, dopóki bramka nie zostanie naprawiona
Rośnie change failure rate albo liczba wycofanych zmian	Narasta dług jakościowy	Wstrzymaj rozszerzanie autonomii; zwiększ godziny weryfikacji; żadnych redukcji
Rośnie czas w review, wykorzystanie recenzentów powyżej celu	Wiąże weryfikacja	Nie dodawaj budujących. Przesuń ludzi do pracy właściciela ewaluacji i harnessu; zatrudnij seniorów do review zmian wysokich i krytycznych, jeśli ograniczeniem są uprawnieni zatwierdzający
Kolejka review zdrowa, brak przygotowanej pracy	Wiąże intencja	Przesuń przepustowość do discovery i specyfikacji produktu; nie dodawaj inżynierów
Kolejka zdrowa, backlog pełny, stabilność bez zmian lub lepsza	Przepustowość naprawdę się zwolniła	Zastosuj politykę uwolnionej przepustowości; dostosowuj stan przez plan rekrutacji i naturalne odejścia, z przeglądem co kwartał

Strona o ekonomii przelicza te same pomiary na koszt zaakceptowanej zmiany, a strona o business case pokazuje, jak przedstawić decyzję z przedziałami i bramkami stopu.

Gdzie powinna trafić uwolniona przepustowość?

Uwolniona przepustowość, której nikt nie przydzielił, zamienia się w kolejne pull requesty, a te muszą potem przejrzeć recenzenci. W tym samym raporcie z kwietnia 2026 Faros podaje wzrost code churn o 861%: to kod przepisany albo usunięty wkrótce po scaleniu, czyli miejsce, w którym zwykle widać nieprzydzieloną pracę. Wewnętrzne badanie Anthropic (2025-12-02, deklaracje pracowników) wykazało, że 27% pracy wspomaganej przez Claude to zadania, których bez tego w ogóle by nie wykonano. Zdecyduj z góry, których z tych zadań chcesz.

POLITYKA UWOLNIONEJ PRZEPUSTOWOŚCI INŻYNIERSKIEJ (przegląd co kwartał)

1. Najpierw weryfikacja. Dopóki mediana czasu w review i change failure
   rate zespołu nie mieszczą się w celu, jego uwolnione godziny idą na
   wyrocznie, ewaluacje, pakiet dowodów i pracę nad harnessem.
2. Potem odłożona niezawodność: niestabilne testy, aktualizacje,
   obserwowalność, znaleziska bezpieczeństwa starsze niż 90 dni.
3. Na końcu zakłady produktowe, każdy ze spisaną hipotezą i datą stopu.
4. Zmiany zatrudnienia wyłącznie przez plan rekrutacji i naturalne
   odejścia, rozstrzygane na przeglądzie kwartalnym według metryk
   projektu organizacji, nigdy na podstawie prognozowanego mnożnika.
5. Każdy zespół zatrzymuje co najmniej jednego inżyniera na wczesnym
   etapie kariery.

Właściciel: CTO. Przegląd z: CFO, VP Product. Dowody: panel metryk.

Jak poznać, że nowy kształt działa

Reorganizacja to zmiana w systemie produkcyjnym, więc przed startem nadaj jej kryteria akceptacji i przygotuj rollback na wypadek, gdyby ich nie spełniła. Nikt nie czyta każdego diffa, żeby ją ocenić; oceniasz ją po tych sygnałach z repozytorium, CI i systemu incydentów.

Metryka	Definicja	Pożądany kierunek	Zatwierdza
Mediana czasu do pierwszego review	Otwarcie → pierwsze review człowieka, dla każdej klasy ryzyka	Stała lub malejąca mimo rosnącego napływu	Engineering manager
Udział scaleń bez review	Scalone PR bez review człowieka ÷ scalone PR, poza klasami „tylko dowody”	Zero	CTO
Change failure rate	Wdrożenia powodujące awarię na produkcji ÷ wdrożenia	Stały lub malejący	Właściciel platformy
Defekty po wydaniu na domenę	Defekty znalezione po wydaniu, według domeny	Malejące tam, gdzie wskazano właściciela ewaluacji	Właściciel ewaluacji
Stosunek budujących do weryfikujących	Jak zdefiniowano wyżej	Przesuwa się w stronę weryfikacji, gdy agenci budują więcej	CTO
Koncentracja review	Udział zrecenzowanych PR, w których brał udział najaktywniejszy recenzent zespołu (kolumna `reviewers`)	Nikt powyżej jednej trzeciej review	Engineering manager

Umieść je na jednym panelu razem z frameworkami pomiaru dostarczania w erze AI, uzgodnij cele przed zmianą i wyznacz datę jej odwrócenia, jeśli dwa kolejne odczyty miesięczne nie trafią w cel.

Jak każde narzędzie przesuwa obciążenie review

Projekt organizacji jest ten sam dla każdego narzędzia. Różni się tym, jaką część pracy review narzędzie może zdjąć z ludzkiego recenzenta, a więc tym, ile godzin recenzentów planujesz. We wszystkich trzech przypadkach decyzja o zatwierdzeniu pozostaje rolą człowieka.

Inżynierowie uruchamiają /code-review na lokalnym diffie przed otwarciem pull requesta, a claude ultrareview (w sesji /code-review ultra) uruchamia w chmurze wieloagentowe review, które odtwarza każde znalezisko. Zarządzana usługa Code Review publikuje komentarze w liniach pull requestów na GitHubie; według stanu na 26 września 2026 r. jest to research preview dla planów Team i Enterprise. Żadna z tych usług nie jest dostępna dla organizacji z Zero Data Retention, a Ultrareview nie działa w Bedrock, Google Cloud ani Foundry. Planuj obie jako pierwsze przejście, które skraca minuty na PR, a nie jako zatwierdzającego; harness engineer stroi je przez CLAUDE.md i REVIEW.md (dokumentacja Code Review, sprawdzone 2026-09-26).

codex review uruchamia nieinteraktywne review zmian --uncommitted, gałęzi --base albo --commit (sprawdzone w CLI 0.157.1), więc pasuje jako krok CI, za który odpowiada harness engineer. Na GitHubie @codex review zleca review pull requesta, a właściciel ewaluacji zapisuje reguły review dla domeny w AGENTS.md (dokumentacja dostawcy, sprawdzone 2026-08-28).

Co się psuje, gdy zespoły zmieniają kształt pod agentów

Etaty są cięte na podstawie prognozowanego mnożnika. Popyt na review zostaje, recenzenci odchodzą, a w ciągu kilku tygodni pojawiają się scalenia bez review. Jak z tego wyjść: wstrzymaj dalsze redukcje, opublikuj udział scaleń bez review i przywróć podaż review dla zmian średnich, wysokich i krytycznych, zanim zrobisz cokolwiek innego.

Rola weryfikującego zamienia się w pieczątkę. Objawem jest wykorzystanie bliskie 100% i malejący czas review przy rosnącym change failure rate. Jak z tego wyjść: ogranicz napływ limitami WIP, wyrywkowo sprawdzaj zatwierdzenia względem pakietu dowodów i nadaj priorytet pracy nad ewaluacjami, aż minuty na PR naprawdę spadną.

Harness engineer staje się bramką. Każdy zespół czeka na jedną osobę, żeby dodać skill albo hook. Jak z tego wyjść: opublikuj harness jako wersjonowany produkt z zasadami kontrybucji, jak opisuje strona o zespole platformowym, aby zespoły mogły zmieniać własną warstwę.

Juniorzy przestają być zatrudniani. Zespół przez rok wygląda na wydajny, a potem nie ma kogo awansować do review. Jak z tego wyjść: przywróć rekrutację osób na wczesnym etapie kariery w ramach polityki uwolnionej przepustowości i dawaj juniorom review do nauki, a nie tylko prowadzenie agentów.

Produkt wypuszcza prototypy na produkcję. Szybsze budowanie kusi zespoły produktowe, by pominąć klasę ryzyka. Jak z tego wyjść: uczyń klasę ryzyka polem obowiązkowym w intencji i trzymaj wydanie produkcyjne za wskazanym właścicielem.

Pytania do twojego CTO

Które ograniczenie jest dziś wiążące w każdym zespole: review, intencja czy prawdziwa przepustowość? Pokaż mi dane z ośmiu tygodni.
Jaki odsetek scalonych pull requestów nie miał review w zeszłym miesiącu i w których klasach ryzyka?
Kto jest wskazanym właścicielem ewaluacji dla każdej krytycznej domeny i ile ma chronionego czasu?
Kto może zatrzymać pętlę bez nadzoru i ile to trwało ostatnim razem?
Co stanie się z uwolnioną przepustowością w przyszłym kwartale i gdzie to jest zapisane?
Co sprawi, że odwrócimy reorganizację, i kiedy to sprawdzamy?

Dokąd dalej w projekcie organizacji

Mapa drogi dla całej organizacji Rozłóż zmianę kształtu na etapy w całej firmie, z bramkami stop/go dla każdej pętli.

Model operacyjny RACI dla harnessu, bramek i ewaluacji, z szablonem karty zespołu.

Kolejka code review Limity WIP, budżety rozmiaru PR i kierowanie według ryzyka dla tech leada.

Przewodzenie zmianie Jak pociągnąć za sobą inżynierów, menedżerów i sceptyków.

Przed tą stroną przeczytaj o ekonomii oprogramowania budowanego przez agentów i o business case. Rekrutację pod nowe profile ról opisuje strona o rekrutacji w inżynierii agentowej, a to, dlaczego przepustowość review ogranicza Poziom 3 drabiny autonomii, wyjaśnia Poziom 3: przeglądasz diffy.