4 czerwca 2020

Awaria, a Scrum Master…

Jak zdefiniować poważną awarię w kontekście oprogramowania? Jeśli miałbym spróbować wskazałbym, że jest to brak możliwości jego uruchomienia lub też jego nieprawidłowe działanie, w sposób istotny utrudniające lub wypaczające jego wykorzystanie. Jakkolwiek zdefiniujemy ją mniej lub bardziej formalnie, jakkolwiek nazwiemy (incydent, problem. wyzwanie), po jakąkolwiek mniej czy bardziej sformalizowaną definicję sięgniemy (czy to w kontekście ISO czy ITIL), po ludzku, zwyczajnie chodzi o to, że na produkcji / u klienta nie działa. I jest problem.

Rodzajów, skali i konsekwencji  tych problemów nie sposób wymienić. Ważne jest to, że awarie produkcyjne oprogramowania się zdarzają i zdarzać się będą. Owszem, są takie systemy, gdzie nie mają prawa się one wystąpić i dokonuje się wszelkich starań, aby do nich nie dochodziło, zabezpieczając się odpowiednio restrykcyjnymi procedurami, testami i nadzorem jakości.  Czy mówimy o niezwykle kosztownych misjach kosmicznych czy kwestiach sterowania bezpieczeństwem – systemy wojskowe, sterujące elektrowniami czy samolotami. Przykładów każdy z nas wymieni bez liku. Tam po prostu musi działać, choć w praktyce… Historii spektakularnych awarii spowodowanych błędami oprogramowania, mających nierzadko tragiczne konsekwencje, znajdziemy bez liku, nie omijały one największych. Żyjemy w świecie, w którym oprogramowanie jest praktycznie wszędzie i steruje coraz ważniejszymi, coraz bardziej newralgicznymi procesami naszego życia. I coraz ważniejsze jest to, żeby działało ono prawidłowo, bo coraz poważniejsze problemy mogą wyniknąć z tego, że będzie inaczej…

I choć znacząca większość pracowników branży IT pracuje na co dzień przy mniej krytycznych systemach i brzemię odpowiedzialności, które dźwiga jest, powiedzmy sobie, umiarkowane, to jednak awaria zawsze jest źródłem dużego stresu. Zasada działania jest zawsze taka sama – trzeba ją naprawić i to możliwie najszybciej, a z każdą minutą problemów, pytań, nacisków i pospieszania jest coraz więcej, a wyrozumiałości coraz mniej.  Klienci eskalują do mediów społecznościowych, sprzedawca jest akurat w czasie prezentacji aplikacji ważnemu klientowi. Jest nerwowo.

I co w tej sytuacji powinien robić Scrum Master, pracujący w zespole, który awarię spowodował i/bądź powinien ją naprawić?

Według niemałej grupy osób, rolą Scrum Mastera w takiej sytuacji jest wyłącznie nie przeszkadzać, cicho wspierać, dopingować i zdać się na procedury IT.

A i owszem, na pierwszy rzut oka wydaje się, że Scrum Master, nawet ten techniczny, niewiele jest w stanie zrobić. I powinien w tej sytuacji rolę koryfeusza przekazać Architektowi, Team Leaderowi czy najbardziej doświadczonej osobie w zespole oraz zaufać wspomnianym zasadom wypracowanym w dziale IT.

Wbrew pozorom jednak pracy do wykonania znajdzie się całkiem sporo.  To, że nie jesteśmy programistami czy testerami, nie oznacza, że powinniśmy zostawić wszystko na barkach Zespołu, czy szerzej Działu IT, samemu się wycofując. W czasie awarii na wierzch bardzo wyraźnie wypływają bowiem wszelkie problemy istniejące w Zespole i jego okolicach. Jako osoby odpowiedzialne za proces, mamy tutaj bardzo ważną rolę do odegrania.

Przyjrzyjmy się zatem najważniejszym aspektom procesu obsługi awarii i zastanówmy się w jaki sposób Scrum Master może na nie wpłynąć i sprawić by cały proces przebiegł sprawnie i bezboleśnie.

  1. Zadbać o to, aby Zespół jak najszybciej wiedział o awarii i odpowiednio na nią reagował

Zaraz, zaraz.

Czy oznacza to, że Scrum Master powinien śledzić logi, zgłoszenia o błędach spływające do backlogu czy wszelkie narzędzia monitorujące stan aplikacji?

Zdecydowanie nie, to nie jest robota dla Scrum Mastera. To odpowiedzialność zespołu deweloperskiego.

Dobry Scrum Master zadba wszakże o to, aby zespół nie dowiadywał się o awariach od klientów, tylko działał zanim ci dowiedzą się o jakimkolwiek problemie i go odczują.

A zatem dobry Scrum Master zadba o to, aby w zespole, a w zasadzie zespołach, bo takie rzeczy trzeba propagować i realizować nie lokalnie, a całościowo, istniały odpowiednie narzędzia ułatwiające identyfikację awarii, automatycznie o nich informujące i procesy, które zagwarantują należyte reakcje w przypadku wystąpienia problemu.

Nie jest tu potrzebna żadna wiedza techniczna. Potrzebne jest natomiast rozumienie tego, jaki awaria może mieć wpływ na naszych klientów, w konsekwencji jak może odbić się to na naszej firmie. Mając tę wiedzę trzeba budować w zespole świadomość i odpowiedzialność za wytwarzany produkt. A następnie, nawet poprzez zwykłe dopytywanie – doprowadzić do zaimplementowania odpowiednich narzędzi i procedur.

Skąd wiemy, że nasza aplikacja działa poprawnie? Skąd wiemy, że mamy problemy z infrastrukturą? Jak rozpoznać skalę i powagę błędu? Jak sprawić, żebyśmy o poważnych błędach dowiadywali się natychmiast po ich wystąpieniu? 

Już kilka tych prostych pytań, wspartych innymi technikami ze scrummasterskiego brulionu (ot, przykładowo,  5 x dlaczego), przy rozumiejącym swoją misję i odpowiedzialność zespole, absolutnie wystarczy, aby proces rozruszać. Właśnie, proces. Jest on równie istotne jak narzędzia. Co jeśli jakiś poważny błąd pojawi się w środku nocy? Do kogo zadzwonić, jeśli awaria wystąpi w sobotę? Co z tego bowiem, że stworzymy automatyczne systemy alarmowania o wszelkiego rodzaju systemowych anomaliach, skoro, nikt nie zareaguje na alarmy spływające po 16:00 lub w czasie weekendu.

Jeszcze raz podkreślę, że cały proces wymaga porządnej implementacji w obszarze całego działu IT, nie tylko jednego czy dwóch zespołów. Rolą Scrum Mastera nierzadko będzie jednak nie tylko tego typu rzeczy wspierać, ale i czasami inicjować czy uzmysławiać.

Z pożytkiem dla wszystkich, bo o zaletach tego, że będziemy wiedzieli o awarii szybciej, niż nasi klienci, chyba nie trzeba nikogo przekonywać. Aczkolwiek, niezmiennie zaskakuje mnie jak wiele osób odkrywa tę prostę prawdę dopiero z czasem.

  1. Upewnić się, że problem jest dobrze rozpoznany i wiadomo co robić

Kiedy awaria już wystąpiła, obecność Scrum Mastera jest moim zdaniem niezwykle ważna.

Pozostając w cieniu i obserwując sytuację, trzeba bowiem być gotowym do podjęcia odpowiednich działań. Istotne jest tu nie tylko budowanie wsparcia, pokazanie, że jest się z zespołem, gotowym do jego wsparcia.

Pytanie – jak mogę pomóc – prawie nigdy nie zaszkodzi, a czasem może przynieść nieoczekiwane zadania, w których można posłużyć przysłowiowym ramieniem. Zaszkodzi natomiast nadmierne dopytywanie i odpytywanie, manifestowanie swojej obecności i chęci do wspierania. Można przedobrzyć.

Najważniejszym zadaniem jest bycie w tej sytuacji ostoją spokoju – uzyskanie obiektywnej, pozbawionej emocji oceny sytuacji i upewnienie się czy są wykonywane odpowiednie działania naprawcze. I aż do momentu naprawienia sytuacji, bieżąca ocena sytuacji i podejmowanych działań – na chłodno!

W czasie awarii zdarzają się różne sytuacje. Panika, paraliż decyzyjny, strach przed podjęciem jakichkolwiek działań – nie są wcale rzadkością, i to u tych najlepszych deweloperów. Czasem ktoś po prostu nie jest w stanie nic zrobić. U niektórych wystarczy odpowiednio reagować – jednak trzeba tych ludzi dobrze znać. Niekiedy trzeba jednak dzwonić po pomoc, czy po staropolsku – eskalować.

Nerwowe zachowanie takie może zdarzyć się także u Product Ownera czy menedżera, którzy pod wpływem emocji mogą zachowywać się nieracjonalnie lub niewspółmiernie do skali problemu i oczekiwać od deweloperów działań, które niekoniecznie powinny być podejmowane. Na takie sytuacje trzeba być odpowiednio przygotowanym i należycie je mitygować.

W czasie awarii nie ma czasu na dywagację o rzeczach nieistotnych, trzeba działać. Jeśli nie ma wsparcia menedżera, Team Leadera lub role zostały rozpisane inaczej, pomóc skoordynować pracę powinien Scrum Master. To nie jest czas na na rozważanie jak daleko odchodzimy od tego, co opisano w Przewodniku po Scrumie. Potrzebne są krótkie, żołnierskie ustalenia i działania.

Po pierwsze – co wiemy o awarii.

Co się stało? Jakie to ma konsekwencje? Czy problem będzie narastał z czasem? Kogo trzeba poinformować? Czy potrzebne są dodatkowe ręce na pokład i pomoc?

Po drugie – czy wiemy kto ją naprawi.

Czy mamy ustalony plan działania? Czy wiemy kto się czym zajmuje, jaki jest podział obowiązków? Czy jesteśmy pewni, że nasz pomysł jest prawidłowy? Kto nam pomoże to zweryfikować?

W czasie awarii, gdy działa stres, emocje, nierzadko ludzie zachowują się zaskakująco i irracjonalnie. Przeoczane są najbardziej oczywiste rzeczy. Zdarzało mi się być świadkiem, wielu nocnych awarii, gdzie zespół nie był fizycznie obecny, a zatem komunikacja odbywała się telefonicznie, mailowo czy na różnego rodzaju zespołowych komunikatorach. W konsekwencji niedogadania, niezrozumienia, pośpiechu, kilka osób robiło te same czynności lub wręcz nie robiło nic… będąc przekonanym, że awarię właśnie naprawia inna osoba z zespołu. Widziałem też jak zespół szybko i sprawnie zareagował na awarię w czasie normalnego dnia w pracy – niezwłocznie zorganizowano wspólne spotkanie, omówiono co trzeba zrobić, po czym… część osób rozeszła się do domu, a ja po rozmowie z jedynym pozostałym na pokładzie deweloperem dowiedziałem się, że w sumie nikt do tematu nie usiadł. Zostało omówione co trzeba zrobić, ale nikt nie podjął się już samego zrobienia…

Bywa różnie, dlatego warto być na posterunku i upewnić się, że wszystko działa jak trzeba, a problem zostanie rozwiązany. 

  1. Zadbać o odpowiednią komunikację w czasie i po awarii – zapewnić spokój i możliwość spokojnego poradzenia sobie z problemem 

Jednym z najczęściej popełnianych błędów w czasie rozwiązywania błędów jest brak odpowiedniej komunikacji do pozostałych działów w firmie.

Kiedy występuje poważna awaria, znacząca część firmy siedzi jak na szpilkach i czeka na jakiekolwiek informacje. Dział Obsługi Klienta jest atakowany przez sfrustrowanych klientów i nie wie co odpowiadać, Sprzedawcom właśnie sypie się zbudowana narracja o bezawaryjności aplikacji, a Menedżerowie oczekują natychmiastowych wyjaśnień. Rodzi się masa pytań – co się stało, jakie są konsekwencje, czy ktoś to w ogóle naprawia, kiedy zostanie to naprawione, co komunikować wewnątrz i na zewnątrz.

Zaczyna się zestaw pytań do odpowiedzialnych i w konsekwencji nierzadko zdarza się, że deweloperzy zamiast rozwiązywać problem, co chwila są odciągani przez ważne telefony.

Aby tego uniknąć, znów konieczne jest zbudowanie odpowiedniego procesu, o którego stworzenie i wsparcie może pokusić się Scrum Master.

Musimy zapewnić tak naprawdę proste rzeczy. 

Po pierwsze, należy zapewnić spokój osobom rozwiązującym problem – one mają skupić się na tym co najważniejsze, a niech o komunikację zadba ktoś inny, ustalmy kto.

Po drugie, kiedy wystąpi awaria w jak najprostszy sposób musimy zapewnić informację do reszty firmy o tym, że jesteśmy jej świadomi i że rozwiązujemy problem. Jeżeli to możliwe, podajmy konsekwencję, skalę i potencjalny czas rozwiązywania problemu. 

Po trzecie – jeśli awaria jest poważniejsza, jej rozwiązanie zajmie dłuższy czas, informujmy na bieżąco jak wygląda sytuacja. To równie ważne jak początkowy komunikat. Jeżeli bowiem ograniczamy się  wyłącznie do niego, osoby spoza zespołu nie wiedzą co się dzieje i w głowie kołaczą się myśli – robią jeszcze? może już skończyli? a może odpuścili? Co się dzieje? W zależności od powagi i znaczenia sytuacji, można dawać komunikat raz na 30, 60 minut, czy raz na parę godzin, ważne żeby to jasno wskazać i konsekwentnie się  tego trzymać.

Po czwarte – jeśli problem został rozwiązany, też koniecznie o tym dajmy znać.

  1. Zadbać o wyciągnięcie wniosków

I na koniec – nasza ulubiona inspekcja i adaptacja.

Błędy – tak jak pisałem – zdarzają się i zdarzać się będą. Ważne, żeby nie popełniać tych samych ponownie.

Kiedy kurz bitewny opadnie, dowiedzmy się czego zespół nauczył się na bazie awarii, jakie wnioski, usprawnienia, pomysły z niej wynikają. Co możemy ulepszyć, zmienić? Jeżeli nic takiego się nie dzieje, to znów sygnał, że trzeba zadbać o odpowiedni proces.

Czasem potrzebne będzie dedykowane spotkanie – niekiedy w szerszym gronie, zwłaszcza kiedy problem wzbudził dużo emocji, nieporozumień. W takiej sytuacji trzeba zadbać o odpowiedni przebieg informacji i o to, żeby rozmowa o przyczynach odbyła się raz, bo miałem okazję obserwować jak nieszczęśni deweloperzy w ciągu 3 dni w tym samym temacie odwiedzali Dyrektora, Kierownika, Product Ownera, a kiedy sprawę awarii na retrospektywie wyciągnął jeszcze Scrum Master…

A może warto wprowadzić zespołowy czy firmowy Failure Log, Post-Mortem czy znany z działających z duchem lean fabryk – Cabbage Patch? Zapewni to nie tylko pewien sposób wizualizacji awarii i mocniej zmobilizuje do usuwania ich przyczyn, ale i uzyskamy dzięki temu przepływ wiedzy, nauki dla innych. Najważniejszym punktem takiego loga powinna być bowiem kolumna prezentująca wyciągnięte wnioski i działania podjęte, aby uniknąć podobnych sytuacji na przyszłość.

Ten moment “obsługi awarii” to chyba miejsce najbardziej naturalne dla Scrum Mastera i pozostawiające największe pole do popisu.

Nie bójmy się awarii

Scrum Master nie może uważać, że awaria to nie jego sprawa, twierdząc, że nie ma tu nic do zrobienia i dodania. Jest wręcz przeciwnie. Nie może się też bać takich sytuacji. Nawet jeśli, będąc Scrum Masterem, nie mamy wiedzy technicznej, działamy w ramach perfekcyjnie zorganizowanego działu IT, a zespół ma liderów technicznych, przejmujących w takich sytuacjach dowodzenie, nasza obecność jest istotna, a  wsparcie może być potrzebne. Jako, że tyle o sobie wiemy, ile w nas sprawdzono, jest to też okazja do obserwacji działania zespołu i ustalonych procesów w sytuacjach trudnych, momentami ekstremalnych. I na pewno znajdziemy coś, co można tu będzie usprawnić na przyszłość. 

#ScrumMaster