---
title: "Proces, który działa w jednym zespole, w dwudziestu się rozmywa"
url: "https://predictes.com/pl/blog/proces-ktory-dziala-w-jednym-zespole-w-dwudziestu-sie-rozmywa"
description: "Rozwój sterowany specyfikacją działa w zespole pilotażowym. W dwudziestu zespołach bramki są omijane, przeglądy płycieją, a pulpity dalej świecą na zielono."
---

# Proces, który działa w jednym zespole, w dwudziestu się rozmywa

5 września 2026·3 min czytania·predictes

Pilotaż poszedł dobrze. Jeden zespół, dobrze rozumiany kod, inżynierowie, którzy sami wybrali metodę i dbali o nią. Liczby były dobre, więc metodę rozciągnięto na dwadzieścia zespołów.

Rok później każdy zespół deklaruje, że trzyma się procesu, każdy pulpit jest zielony, a nikt nie potrafi powiedzieć, czy jakość jest taka jak w pilotażu. Nikt nie postanowił iść na skróty. Procesy rozmywają się po jednym rozsądnym wyjątku naraz.

## Jak rozmywa się proces dostarczania

**Tymczasowe obejście.** Bramkę wyłączono na czas pilnego wydania i nikt jej z powrotem nie włączył.

**Specyfikacja z szablonu.** Specyfikacje pisze się po to, żeby spełnić format, a nie żeby cokolwiek rozstrzygnąć. Każda sekcja jest wypełniona, a kryteria akceptacji powtarzają tytuł.

**Pieczątka.** Zatwierdzenia przychodzą szybciej, niż dałoby się zmianę przeczytać. Nic w narzędziach nie odróżnia ich od prawdziwych przeglądów.

**Odziedziczona metoda.** Zespoły, które dołączyły później, dostały reguły bez uzasadnień. Zostawiają te, które są tanie, i porzucają te, które bolą — a to zwykle właśnie te, które miały znaczenie.

**Milcząca bramka.** Kontrola, która od roku niczego nie złapała. Albo działa idealnie, albo niczego nie sprawdza, i nikt nie wie, które z tych dwóch.

Z poziomu pulpitu każde z nich wygląda dokładnie jak przestrzeganie procesu.

## Audytujcie wynik, nie papiery

Pytanie zespołów, czy trzymają się procesu, mierzy ich odpowiedź na to pytanie. Jedyny wiarygodny sygnał bierze się z przyjrzenia się temu, co proces wyprodukował.

**Pogłębiony przegląd na próbie.** Co miesiąc niewielka losowa próbka scalonych zmian z każdego zespołu jest przeglądana ponownie, porządnie, przez kogoś spoza zespołu i względem specyfikacji. Nie chodzi o wyłapanie tych zmian, bo są już na produkcji, tylko o zmierzenie różnicy między przeglądem, który dostały, a takim, jakiego potrzebowały. To jedyny sposób, żeby zobaczyć jakość przeglądu, bo pobieżne i staranne zatwierdzenie wyglądają w logach identycznie. Wyniki raportuje się dla zespołu, a nie dla recenzenta: celem jest kalibracja, a próbę, która prowadzi do szukania winnych, zespoły w ciągu kwartału nauczą się obchodzić.

**Jawny rejestr obejść.** Każde obejście bramki jest zapisywane: kto, dlaczego i do kiedy. Rejestr przegląda się co miesiąc, a obejście bez daty końca ją dostaje.

**Pochodzenie defektów w podziale na zespoły.** Defekty, które uciekły, są klasyfikowane według etapu, który powinien był je złapać. Przy dwudziestu zespołach ta klasyfikacja staje się mapą tego, czyj proces się rozjeżdża i w którym miejscu.

**Specyfikacje sprawdzane odtworzeniem.** Co jakiś czas moduł jest odtwarzany ze specyfikacji na osobnej gałęzi i testowany. Zespół, który nie chce spróbować, ma specyfikację, która przestała być źródłem prawdy.

## Przycinajcie też reguły

Rozmywanie nie jest jedyną porażką. Odwrotną jest narastanie: każdy incydent dokłada regułę, żadnej się nie usuwa, a proces robi się tak ciężki, że omijanie go zaczyna wyglądać na zdrowy rozsądek.

Droga w użyciuTania w użyciu

Przerobić albo usunąćKosztuje wszystkich czas; sprawdźcie, czy jeszcze czegoś pilnuje.

ZautomatyzowaćWarta zachowania; niech sprawdzaniem zajmie się potok.

Zostawić i testowaćCo jakiś czas wprowadźcie znany błąd, żeby sprawdzić, czy zadziała.

FundamentNigdy nieomijana i niepodlegająca dyskusji.

Rzadko coś łapieCzęsto coś łapie

Reguła, która nigdy nie reaguje, albo działa, albo niczego nie sprawdza; rozstrzyga tylko test.

Każda reguła powinna zapracować na swoje miejsce. Drogie, które rzadko cokolwiek łapią, przerabia się albo wycofuje. Tanie i milczące się testuje: co jakiś czas wprowadza się znany błąd i sprawdza, czy bramka zareaguje. Bramka, której nikt nie widział w działaniu, jest przekonaniem, a nie kontrolą.

## Dajcie procesowi właściciela

Potok, bramki, format specyfikacji i audyt są produktem z wewnętrznymi użytkownikami. Ktoś musi za niego odpowiadać, mieć na niego czas, publikować liczby i mieć uprawnienie do zmiany reguł dla wszystkich. Bez takiego właściciela każdy zespół edytuje własną kopię i po roku jest dwadzieścia procesów pod jedną nazwą.

Rzadko jest nim zespół pilotażowy. Pilotaż potrzebował kontekstu i entuzjazmu; ta rola potrzebuje teraz uprawnienia, żeby odmówić dwudziestu zespołom, i czasu, żeby co miesiąc patrzeć na ich liczby.

Pilotaż dowiódł, że metoda działa, gdy ludziom zależy. Skalowanie jej to praca nad tym, żeby działała także wtedy, gdy ludzie są zajęci. W [rozwoju sterowanym specyfikacją](https://predictes.com/pl/services/ai-agents-spec-driven-development) celem jest to, żeby Wasi inżynierowie prowadzili metodę z nazwanymi trybami porażki, łącznie z tymi, i żeby przetrwała ona zarówno rozszerzenie, jak i nasze odejście.

-   zarządzanie inżynierią
-   spec-driven
-   przegląd kodu
-   proces

## Czytaj dalej

-   [Dostawca wycofał model. Co dalej z Waszym systemem](https://predictes.com/pl/blog/dostawca-wycofal-model-co-dalej-z-waszym-systemem)
-   [Baza operacyjna i lakehouse: dwie pamięci systemu AI-native](https://predictes.com/pl/blog/baza-operacyjna-i-lakehouse-dwie-pamieci-systemu-ai-native)