Przestań walczyć z objawami: problemem jest struktura

Dzień foundera to głównie gaszenie pożarów: a to awaria, a to wściekły klient, a to deploy, który znów się wywalił. Pułapka w tym, że każdy pożar wygląda na problem, podczas gdy pożary są outputami struktury, która wciąż je produkuje. Myślenie systemowe stawia niewygodną tezę — powracające problemy to nie pech, to twój system działający tak, jak go zbudowano — i wskazuje o wiele tańszą interwencję: zmień strukturę, nie objaw.

Zachowanie bierze się ze struktury

Donella Meadows ujęła sedno wprost: zachowanie systemu wynika z jego struktury — zasobów, przepływów, a przede wszystkim pętli sprzężenia zwrotnego. Jeśli problem wraca po tym, jak go „naprawiłeś”, nie naprawiłeś go; ulżyłeś objawowi, zostawiając nietkniętą strukturę, która go generuje. Meadows nazwała skłonność systemów do pokonywania napraw objawowych podejmowanych w dobrej wierze „oporem polityki” i właśnie dlatego tyle wysiłku przynosi tak niewiele trwałej zmiany.

Peter Senge skatalogował powtarzające się postaci tej porażki jako archetypy systemów. Najczęstszym w firmie jest „przerzucanie ciężaru”: naprawa objawowa ulży presji tak skutecznie, że problem u podstaw nigdy nie doczekuje się rozwiązania, a co gorsza, zdolność organizacji do jego rozwiązania zanika, bo szybka łatka jest zawsze pod ręką. Dajesz rabat, by zatrzymać odejścia, rabat działa i nigdy nie naprawiasz onboardingu, który odejścia powodował — i teraz jesteś zależny od rabatu.

Ruch: znajdź strukturę, która wciąż produkuje pożar

Dyscyplina operacyjna każe traktować powracający objaw jak pytanie o strukturę. Ciągłe pożary on-call to nie problem on-call; to problem kruchego deployu. Powtarzające się złe rekrutacje to nie seria pecha; to problem systemu rekrutacji. Odejścia rzadko są problemem cenowym; zwykle to problem dostarczania wartości albo onboardingu, który przebrał się za cennik. W każdym przypadku naprawa objawowa — więcej heroizmu, kolejna runda rozmów, rabat — leczy sam output, a trwała naprawa zmienia to, co go wytwarza.

Pierwotny problem Systemu 1.0 nie został rozwiązany, a doszedł nowy — zależność.Donella Meadows, o przerzucaniu ciężaru

To cała logika pracy nad resilience, czyli mojej roboty na etacie: niezawodności systemu nie osiągniesz szybszym reagowaniem na awarie; osiągniesz ją, przebudowując strukturę tak, żeby te awarie przestały wracać. W „Leverage Points” Meadows pokazuje, że interwencje o największej dźwigni nie leżą na poziomie zdarzeń (pożar), tylko na poziomie reguł, bodźców i celów kształtujących przepływy. Founderzy zaś najchętniej pomijają właśnie te poziomy, bo są one wolne i niewidoczne, podczas gdy pożar jest szybki i głośny.

Naprawa na przykładzie: deploy, który wciąż się wywala

Weź najzwyklejszy powracający pożar: co kilka tygodni deploy kładzie produkcję, ktoś się miota, łata się to o północy i wszyscy z ulgą wracają do swoich zajęć. Odpowiedź objawowa to miotać się coraz sprawniej — szybsze alerty, gładszy rollback, bohater, który zna zaklęcie. Każda z tych rzeczy leczy output, czyli awarię, i każda czyni zespół trochę bardziej zależnym od heroizmu, który trzyma całość przy życiu. Meadows nazwałaby to przerzucaniem ciężaru: szybka łatka działa na tyle dobrze, że struktury generującej awarie nikt nigdy nie musi zbadać, a zdolność organizacji do jej właściwej naprawy po cichu zanika.

Pytanie strukturalne jest inne: co w systemie niezawodnie produkuje tę awarię? Zwykle odpowiedzią jest kruchy pipeline deployu — brak stagingu odzwierciedlającego produkcję, brak automatycznych testów na ścieżce, która wciąż się psuje, ręczny krok, który zmęczony człowiek wykonuje za każdym razem inaczej. To struktura, nie zdarzenia, i tam jest dźwignia. Napraw pipeline, a klasa awarii przestaje wracać; naprawiaj dalej awarie, a bierzesz na siebie naprawianie ich na zawsze, za każdym razem szybciej.

Ale tu puryzm systemowy musi ustąpić triażowi, bo uczciwa kolejność ma znaczenie. Gdy strona leży o północy, nie otwierasz dyskusji o architekturze pipeline'u; chwytasz wiadro, przywracasz usługę i trzymasz system przy życiu. Naprawa strukturalna to robota na jutro: wpisujesz ją do planu z rozmysłem, gdy pożar już zgasł, zamiast filozofować, póki się pali. Dyscyplina polega na tym, żeby ją faktycznie zaplanować — nie pozwolić, by ulga z działającej łatki stała się powodem, dla którego struktury nigdy się nie dotyka. Ustabilizuj objaw teraz; zmień strukturę świadomie potem, żeby ten sam pożar nie obudził cię o tej samej północy za miesiąc.

Ten sam ruch działa poza deployem: ciągły on-call to problem kruchości, powtarzające się złe rekrutacje to problem systemu rekrutacji, powracające odejścia to zwykle problem onboardingu. W każdym przypadku powracający objaw jest pytaniem o strukturę, a odpowiedź jest warta więcej niż każde kolejne przyspieszanie reakcji.

Gdzie „napraw źródło” samo staje się pułapką

Puryzm systemowy zawodzi równie realnie jak gaszenie pożarów. Na trzy sposoby.

Pierwszy: czasem objaw jest sytuacją awaryjną. Gdy budynek płonie, „zajmijmy się przyczyną źródłową” to zaniedbanie. Najpierw triaż: ustabilizuj objaw, utrzymaj system przy życiu i dopiero potem napraw strukturę. Founder filozofujący o architekturze deployu, gdy strona leży, pomylił esej z robotą.

Drugi: „przyczyna źródłowa” to często mit. Złożone systemy rzadko wyrastają z jednego korzenia; mają współdziałające przyczyny i pętle sprzężenia bez wyraźnego początku. Kto z pełnym przekonaniem poluje na jedną prawdziwą przyczynę, bywa równie redukcyjny jak ten, kto goni objawy, tylko wolniejszy. Sama Meadows wskazuje, że szukasz dźwigni, a nie jednego złoczyńcy.

Trzeci: przebudowa jest droga, a opcjonalność przemawia przeciw przedwczesnym systemom. Dla młodej lub małej firmy budowanie rozbudowanego systemu, by zapobiec problemowi, który zdarzył się raz, to przeinżynierowanie — tania łatka objawowa jest właściwym wyborem, dopóki nawroty nie dowiodą, że to wzorzec. Napraw strukturę, gdy pożar jest wzorcem, nie za pierwszym razem, gdy się pali.

Gdy więc problem wraca, przestań sięgać po szybsze wiadro i zapytaj, jaka struktura wciąż wznieca ten pożar. Potem napraw ją — chyba że budynek naprawdę płonie w tej chwili; wtedy najpierw chwyć wiadro i uczciwie przyznaj, że naprawa strukturalna jest od jutra twoim długiem.

Bibliografia

1. primaryDonella H. Meadows, Thinking in Systems: A Primer (2008); „Leverage Points: Places to Intervene in a System” (1999).
2. primaryPeter M. Senge, Piąta dyscyplina (1990) — archetypy systemów.
3. secondaryTaiichi Ohno, Toyota Production System (1978) — metoda „5 razy dlaczego”.
4. secondaryW. Edwards Deming, o zmienności z przyczyn wspólnych i specjalnych.