Zarządzanie incydentami dla dynamicznych zespołów
Czy zasada „odpowiadasz za to, co tworzysz” się sprawdza?
Zasada „odpowiadasz za to, co tworzysz” obowiązuje już od 13 lat. Czy spełniła związane z nią obietnice?
Trzynaście lat temu nowe wezwanie do powiązania wdrażania i obsługi oprogramowania wkradło się do wywiadu, zmieniając procesy IT na całym świecie. Obecnie coraz więcej firm praktykuje podejście DevOps oparte na współpracy i właściwe dla niego nastawienie „odpowiadasz za to, co tworzysz”. Czy jednak teraz, po ponad dekadzie zmian, ta koncepcja jest wciąż aktualna? Czy przyniosła obiecane korzyści?
Historia zmiany podejścia
Wszystko zaczęło się od wywiadu z dyrektorem ds. technicznych Amazon, Wernerem Vogelsem, w 2006 roku:
„Przekazanie programistom obowiązków związanych z eksploatacją IT znacznie poprawiło jakość usług, zarówno po stronie klienta, jak i z technologicznego punktu widzenia. W tradycyjnym modelu bierzesz oprogramowanie i zanosisz je pod ścianę oddzielającą zespoły programistyczne i operacyjne, po czym przerzucasz je i o nim zapominasz. Ale nie w Amazon. Tutaj odpowiadasz za to, co tworzysz. Dzięki temu programiści mają styczność z codzienną obsługą swojego oprogramowania. Mają również na co dzień kontakt z klientami. A pętla informacji zwrotnych od tych klientów ma zasadnicze znaczenie dla poprawy jakości usługi”.
To dało początek zasadzie „odpowiadasz za to, co tworzysz” — nowemu podejściu, które doskonale uzupełniło wprowadzony nieco później oparty na współpracy ruch DevOps, w którym istotne było obalenie muru między tymi, którzy tworzą, a tymi, którzy udzielają wsparcia.
Pomysł się przyjął — i to nie bez powodu. Zbudowanie mostu między z zespołami programistycznymi i operacyjnymi jest sensowne z wielu powodów. Dlaczego zespół, który napisał kod — a zatem jest najlepiej zaznajomiony z produktem — nie miałby być tym, który przywdzieje pelerynę superbohatera, gdy dojdzie do incydentu? Taka praktyka nie tylko przyspiesza rozwiązywanie, ale także zbliża programistów do informacji zwrotnych od klientów i rzeczywistych problemów, ułatwiając przez to dostarczanie zawsze dostępnych usług.
Oczywiste korzyści i równie oczywiste wyzwania
Jak w przypadku każdej zmiany w procesie, także tutaj korzyściom towarzyszyło sporo trudności, a przede wszystkim duży opór ze strony firm o bardziej tradycyjnej strukturze.
Wśród korzyści można wskazać mniejszą presję wywieraną na zespoły IT, projekty gotowe do wdrażania w środowisku produkcyjnym, krótsze czasy reakcji i dokładniej przetestowany kod (w końcu jeśli to Ty ryzykujesz, że otrzymasz o 1 nad ranem prośbę o rozwiązanie błędu, szanse, że sprawdzisz dokładnie kolejne wdrożenie, są zdecydowanie większe). Doszło również do podniesienia kompetencji i zwiększenia wszechstronności programistów, którzy uczą się nowych umiejętności, a sposób ich myślenia o firmie się zmienia.
W związku z tym, że ten sam zespół ponosi odpowiedzialność za kod, podejście to wpływa również korzystnie na zapobieganie incydentom. Według jednego z raportów firmy, w których przed wdrożeniem kodu zespoły zewnętrzne przeprowadzały jego przegląd, miały taki sam wskaźnik powodzenia, jak firmy, w których w ogóle nie stosowano przeglądów kodu. Z kolei przegląd przeprowadzany przez programistów współpracujących z autorem, którzy już znają produkt, wpływał korzystnie na zapobieganie incydentom.
Jeśli chodzi o trudności, nasz zespół uporał się z niektórymi wyzwaniami towarzyszącymi zmianie podejścia do zarządzania incydentami tutaj: „Trudność [z decentralizacją zarządzania incydentami] polega na tym, że organizacje wciąż potrzebują pewnej dozy centralizacji. Kierownictwo musi mieć dostęp do raportów i dokumentacji. Interesariusze w firmie chcą otrzymywać aktualne informacje. Chcą obserwować wskaźniki dotyczące incydentów, takie jak średni czas rozwiązywania lub potwierdzenia. Oczekują precyzyjnych aktualności na temat incydentów, raportów z analiz post-mortem incydentów i działań naprawczych.
Dla wielu firm, które z powodzeniem kroczą w kierunku decentralizacji [i podejścia „odpowiadasz za to, co tworzysz”], odpowiedzią na to wyzwanie jest technologia zapewniająca decentralizację i autonomię zespołu w celu sprawnego rozwiązywania incydentów, a jednocześnie centralizację informacji, aby cała firma była na bieżąco”.
Inna podstawowa trudność polega na tym, że dla wielu firm wdrożenie zasady „odpowiadasz za to, co tworzysz” oznacza zmianę struktury i wewnętrznej kultury zespołów. Wymaga to otwartości na współpracę, nowych sposobów myślenia o produkcie oraz nowych struktur zespołów pozbawionych barier komunikacyjnych. Tego rodzaju zmiany bywają trudne, a ich powodzenie wymaga przyjęcia bardzo konkretnego podejścia.
Czy zatem zasada „odpowiadasz za to, co tworzysz” spełnia oczekiwania?
Pomimo tych trudności, nasze doświadczenia wskazują, że odpowiedź na to pytanie jest twierdząca. Zasada „odpowiadasz za to, co tworzysz” wciąż prowadzi do przekształceń w branży i nawet bardziej tradycyjne zespoły IT zaczynają powoli próbować tego podejścia.
Nie ma żadnych dostępnych badań dotyczących wdrażania zasady „odpowiadasz za to, co tworzysz”, jednak nasze doświadczenia pokazują, że często idzie ona w parze z wdrożeniem ogólnych zasad DevOps. A w tym przypadku możemy posiłkować się liczbami. Według raportu firmy Forrester w 2017 roku 63% organizacji potwierdzało wdrożenie DevOps. Kolejne 27% miało w planach takie wdrożenie w ciągu kolejnego roku. A zaledwie 1% respondentów nie wykazał zainteresowania wprowadzeniem tej zmiany.
Co ciekawsze, po wdrożeniu zasad DevOps firmy odnotowały wzrost zadowolenia klientów średnio o 45% i wzrost produktywności pracowników o 43%.
Rozpoczynanie wdrażania podejścia „odpowiadasz za to, co tworzysz”
Nie da się wdrożyć podejścia opartego na zasadzie „odpowiadasz za to, co tworzysz” bez elastycznej platformy umożliwiającej współpracę. Cała obietnica opiera się na założeniu, że zespoły programistyczne i operacyjne mogą bezproblemowo współpracować — a taki rodzaj współpracy można osiągnąć tylko przy użyciu właściwych narzędzi.
Jira Service Management jednoczy zespoły dzięki zintegrowanej komunikacji opartej na współpracy, umożliwiając im korzystanie z preferowanego sposobu komunikacji — od kanałów na czacie (Slack, Microsoft Teams) po wideokonferencje (przy użyciu natywnego mostka konferencyjnego lub platformy Zoom). Niemal każdy aspekt rozwiązania Jira Service Management (od alertów po reguły przekierowywania i wiele innych) można dostosować do potrzeb każdego zespołu, aby zaangażować odpowiednie osoby reagujące i udostępnić kontekst wszystkim podmiotom — od początkowych etapów reakcji po raporty z analizy post-mortem i zarządzanie problemami.
Dowiedz się więcej o tym, jak Jira Service Management może uwolnić potencjał współpracy drzemiący w Twoim zespole.
Konfigurowanie harmonogramu dyżurów domowych za pomocą Opsgenie
W tym samouczku nauczysz się konfigurować harmonogram dyżurów domowych, stosować reguły zastępujące, ustawiać powiadomienia o dyżurach domowych oraz wykonywać inne czynności w Opsgenie.
Przeczytaj ten samouczekPlusy i minusy różnych podejść do zarządzania dyżur domowy
Zespoły na dyżurach domowych szybko się rozwijają. Poznaj zalety i wady różnych podejść do zarządzania dyżurami domowymi.
Przeczytaj ten artykuł