Code Yellow: When Operations Isn’t Perfect

Od czasu do czasu zespoły inżynierskie wpadają w tarapaty z wielu powodów. Czasami, gwałtowny wzrost zaskakuje zespół. Albo dyżury wymknęły się spod kontroli, a alerty pojawiają się co pięć minut. Albo zespoły programistów i operatorów po prostu przestały się ze sobą spotykać. Niezależnie od przyczyny, zespół jest w złym miejscu i coś trzeba zrobić, aby go rozwiązać.

Jeśli jest to nowy problem, naprawa może być prosta: Dodaj kilka dodatkowych serwerów, roll back do znanej dobrej wersji aplikacji lub zebrać wszystkich razem na pizzy i piwa, aby oczyścić powietrze. Często jednak problem skrada się z czasem i nagle okazuje się, że dziura jest tak głęboka, że nie można znaleźć drogi wyjścia. W LinkedIn zespół, który dotarł do tego punktu, często ogłasza stan znany jako „Code Yellow”.”

Yellow Alert

Niektórzy zakładają, że nazwa „Code Yellow” odnosi się do sygnalizacji świetlnej, ale dokładniej – i z bardziej geekiem – pochodzi z ulubionego serialu „Star Trek”. Dokładniej, jest to sposób, w jaki załoga statku kosmicznego Enterprise wskazuje swój aktualny stan obronny. Tak czy inaczej, definicja jest jasna: coś jest nie tak i musimy postępować ostrożnie. Wierni obu metaforom, mamy również Kod Czerwony. Ten lepiej opisać jako natychmiastowy kryzys, w którym wszyscy pracują 24 godziny na dobę, aż do jego rozwiązania. Kod Żółty jest nieco bardziej spokojny: Wszyscy skupiają się na tym problemie, ale tylko w godzinach pracy. Kod Żółty ma również tendencję do trwania miesiącami, podczas gdy Kod Czerwony powinien trwać kilka dni.

Inne firmy mogą używać innego terminu niż Kod Żółty, ale efekt jest taki sam: zespół komunikuje reszcie firmy, że zidentyfikował poważny problem, który jest priorytetem do naprawienia, aby zapewnić sukces zespołu, a tym samym firmy. Umiejętność robienia tego jest ważnym aspektem otwartej i szczerej komunikacji, wartości, która jest kluczowa dla zdrowej kultury, a która często bywa pomijana. Rozmawianie o naszych problemach jest równie ważne, jeśli nie bardziej, niż świętowanie naszych sukcesów. Zespoły mogą nauczyć się więcej z rozwiązywania problemów niż z całkowitego sukcesu.

To nie jest porażka

Pierwszym krokiem w rozpoczęciu Code Yellow jest zrozumienie, że to nie jest porażka. Nie ma wstydu w przyznaniu, że zespół ma problem, który musi zostać naprawiony. Błędy się zdarzają, pomimo naszych najlepszych starań, aby ich uniknąć. Jedyne, co możemy zrobić, to zdiagnozować problem i naprawić go. Jedynym momentem, w którym ponosimy porażkę, jest przymknięcie oka na te problemy. Dotyczy to zarówno sposobu, w jaki nasze zespoły inżynierskie współdziałają ze sobą, jak i oprogramowania oraz systemów, które wytwarzamy i uruchamiamy.

Krytyczne jest jednak to, że zajmujemy się właściwymi problemami. W większości przypadków, znaleźliśmy się w obecnej sytuacji z powodu powolnego wrzenia – rosnącego długu technicznego, wielu małych problemów lub awarii w procesach – które w końcu przerodziły się w kryzys. Celem Code Yellow musi być nie tylko usunięcie bieżących problemów (komponent reaktywny), ale także upewnienie się, że nie powtórzą się one w przyszłości (komponent proaktywny).

Planowanie udanego Code Yellow

Istnieje kilka komponentów wymaganych do udanego Code Yellow, jak również niezbędne elementy do uzyskania akceptacji od reszty organizacji:

  • Zestawienie problemu: Musi istnieć jasne i uzgodnione oświadczenie o problemach stojących przed zespołem, które spowodowały Code Yellow. Powinno to obejmować nie tylko to, jakie są bieżące problemy, ale również to, jakie jest obecne rozumienie ich pierwotnej przyczyny.
  • Kryteria wyjścia: Następnie należy wyznaczyć konkretne cele, do których zespół będzie dążył, aby wyjść z Code Yellow. Powinny to być tradycyjne cele SMART: konkretne, mierzalne, osiągalne, istotne i określone w czasie. To właśnie te cele umożliwiają zespołowi wejście w Code Yellow, ponieważ obejmują ustalony zakres i nie są otwarte.
  • Komunikacja: Wszystkie informacje na temat Code Yellow, w tym ogłoszenie (które zawiera opis problemu i kryteria wyjścia), pomyślne zakończenie i okresowe aktualizacje statusu powinny być wysyłane do większej organizacji. Może to być Twój dział, lub cała organizacja inżynierska. Może to być nawet cała firma, w zależności od natury problemów.
  • Zarządzanie projektem: Jak w przypadku wszystkich dużych projektów, musi być ktoś odpowiedzialny za organizację pracy i przekazywanie informacji. Ponieważ jest to scenariusz „wszystkie ręce na pokład” dla dotkniętego zespołu, zwykle pomocne jest posiadanie dedykowanego kierownika projektu (PM), aby pomóc w tym. Zazwyczaj jest to PM, który posiada wiedzę na temat zespołu i pracy, ale nie jest bezpośrednio zaangażowany w jej wykonanie. To uwalnia menedżerów i indywidualnych współpracowników do skupienia się na pracy pod ręką.

Po tym, jak każdy z tych aspektów został przemyślany, a decyzja została podjęta, aby wprowadzić Żółty Kod, pierwszym działaniem zespołu jest reorganizacja ich priorytetów wokół kryteriów wyjścia. Często oznacza to odłożenie na półkę celów kwartalnych. Może być również konieczne ustanowienie dedykowanego spotkania wokół omawiania statusu kryteriów wyjścia.

Przestrzeń do oddychania

Wszystko jest dobrze i dobrze dla zespołu, aby wejść do Code Yellow i pracować z pojedynczą koncentracją na celach, które zostały ustalone, aby naprawić rzeczy, ale to nie wystarczy, aby zespół odniósł sukces. Aby odnieść prawdziwy sukces, wszyscy wokół zespołu muszą zrozumieć sytuację i dać im przestrzeń do wykonania ich pracy. To jest miejsce, w którym zdrowa kultura inżynierska wznosi się, aby sprostać wyzwaniu.

  • Spodziewaj się opóźnień: Najczęstszym sposobem, w jaki zespół tangencjalny zostanie dotknięty, są opóźnienia. Muszą oni oczekiwać, że wszelkie żądania, które zostały złożone przez zespół dotknięty mogą być opóźnione, jeśli nie są w zakresie kryteriów wyjścia. Code Yellow obejmuje, w swojej istocie, zmianę kolejności priorytetów w celu rozwiązania określonego problemu. Zespoły zewnętrzne muszą wziąć to pod uwagę i zrozumieć, że ich własne harmonogramy projektów mogą wymagać korekty.
  • Minimalizuj nowe żądania: Inne zespoły powinny również powstrzymać się od proszenia zespołu, na który wywierany jest wpływ, o nowe rzeczy, które wykraczają poza zakres zdefiniowanych kryteriów wyjścia. Minimalizacja takich próśb, oprócz akceptowania opóźnień w realizacji istniejących próśb, pozwala dotkniętemu zespołowi poświęcić swoje ograniczone godziny pracy inżynierów na przejście na drugą stronę Code Yellow.
  • Prośby o pomoc od innych zespołów: Zespół w Code Yellow może uznać, że potrzebuje pomocy z zewnątrz, aby osiągnąć swoje cele. Na przykład, jeśli nastąpi nagły, gwałtowny wzrost ruchu, może być konieczne przyspieszenie dostarczenia nowego sprzętu. Znalezienie się po stronie odbiorcy takiej prośby może wymagać zmiany własnych priorytetów. Zawsze pamiętaj, że zespół jest częścią tej samej firmy, i jako taki, każdy odnosi sukces lub ponosi porażkę razem.

Zespoły inżynierskie rzadko stoją same, i ważne jest, aby każdy zrozumiał wartość w posiadaniu tych zespołów pracujących dobrze, i pracując razem dobrze. Małe tymczasowe opóźnienie w realizacji celów, aby upewnić się, że tak jest, jest tego warte.

Światło na końcu tunelu

Kod żółty reprezentuje znaczną ilość pracy o wysokim priorytecie i praca nad nim będzie często stresująca dla zespołu. Mówienie „nie” współpracownikom, którzy składają rozsądne prośby jest trudne, a praca, która jest w zakresie rzadko wiąże się ze spędzaniem czasu nad interesującymi nowymi funkcjami. Dodatkowo, jeśli problemy, którymi się zajmujemy, obejmują problemy komunikacyjne pomiędzy grupami, będzie kilka trudnych rozmów, które muszą się odbyć. Jednakże, gdy zespół zbliża się do końca pracy, będzie o wiele łatwiej zobaczyć, co leży po drugiej stronie kryteriów wyjścia.

Ostatnim celem Code Yellow jest wyprowadzenie zespołu z trybu reaktywnego, w którym biega on od kryzysu do kryzysu i przejście w stan proaktywny, w którym jest w stanie pracować nad właściwymi dużymi projektami. Osiągnięcie kryteriów wyjścia oznacza, że inżynierowie są bardziej efektywni i zdolni do proaktywnej pracy. To silniejszy zespół – inżynierowie są szczęśliwsi, ponieważ nie są pod dużym stresem związanym z pracą operacyjną, zespół pracuje dobrze, ponieważ skutecznie ze sobą rozmawia, a klienci są zadowoleni, ponieważ zgłoszenia są obsługiwane albo poprzez automatyzację, albo w rozsądnym czasie.

Czy Twoja firma ma wewnętrzny proces, który jest podobny do tego, jak LinkedIn robi Code Yellow?

– Todd Palino

.

Dodaj komentarz