Zarządzanie kryzysem w projekcie IT

Jak nie pogłębiać chaosu i odzyskać kontrolę?

Horyzont Lidera Lunch #4 to rozmowa o realiach pracy pod presją. Jak podejmować decyzje, gdy sytuacja jest niejasna, a zespół oczekuje jasnego kierunku? Oto sprawdzone praktyki Jakuba Kubryńskiego.

Skąd biorą się kryzysy w IT?

Nie zawsze przyczyną jest błąd w kodzie. Często problemy mają charakter organizacyjny:

brak jasnych ustaleń z biznesem,
rozmyta odpowiedzialność w zespole,
opóźniona lub niepełna komunikacja,

unikanie trudnych tematów aż do momentu eskalacji.

Drobne niedopowiedzenia mogą w ciszy urosnąć do rangi poważnego kryzysu.

Jak nie pogłębiać kryzysu?

Komunikuj, nawet jeśli nadal nie wiesz wszystkiego

Regularne statusy, nawet w stylu „jeszcze badamy sprawę”, są lepsze niż cisza. Brak komunikacji powoduje panikę i domysły.

Nie szukaj winnych, szukaj rozwiązania

W środku kryzysu nie ma czasu na wskazywanie palcem. Zespół musi działać wspólnie, a analiza przyczyn przyjdzie później: na post-mortem.

Nie czekaj na pełen obraz, żeby zacząć działać

Plan awaryjny trzeba ustalić jak najszybciej. Kto co robi? Co jest najważniejsze na dziś? Opóźnianie decyzji paraliżuje wszystkich.

Jak odzyskać kontrolę w projekcie IT?

Zatrzymanie chaosu to dopiero pierwszy krok. Kolejnym jest przejęcie inicjatywy i nadanie sytuacji nowej struktury. Lider techniczny powinien jak najszybciej odbudować poczucie kierunku i bezpieczeństwa.

1. Ustal minimum operacyjne i działaj od razu

Nie czekaj na pełne rozpoznanie. Wyznacz zakres „awaryjnej stabilności”: co musi działać tu i teraz? Kto za to odpowiada? Jakie decyzje podejmujemy dziś?

2. Stwórz rytm komunikacyjny

Zorganizuj stały kanał informacji: krótki sync, update na Slacku, komunikat dla biznesu. Ważna jest nie tylko treść, ale i powtarzalność. Zespół musi wiedzieć, gdzie szukać aktualnych informacji.

3. Prowadź zespół przez dane, nie przez domysły

Zbieraj fakty, dokumentuj ustalenia, unikaj spekulacji. Jasność co do tego, co już wiemy i czego jeszcze nie: to podstawa dobrego zarządzania kryzysem.

Jak wyciągnąć wnioski z awarii w projekcie? Praktyczne case study

W trakcie lunchu #4 omawialiśmy realny przypadek awarii produkcyjnej, która sparaliżowała system na około 6 godzin.

Co wdrożono po kryzysie?

Zamiast wrócić do pracy „jak gdyby nigdy nic”, zespół:

Zorganizował retrospektywę po awarii, żeby wspólnie zastanowić się, co dokładnie zawiodło.
Przeprowadził post-mortem, czyli szczegółową analizę zdarzenia krok po kroku.
Skorzystał z metody root cause analysis, by dojść do przyczyny źródłowej, a nie tylko naprawić objawy.

Wnioski: pożar ujawnia, co naprawdę działa

Czasem to nie awaria jest największym problemem, ale brak przygotowania: brak metryk, brak logów i brak procedur, które pozwoliłyby szybko znaleźć źródło błędu.