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

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.

Infografika

Które reguły procesu zostawić

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

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ą 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.