Close

Poznaj Jira Service Management i inne zaawansowane narzędzia podczas wydarzenia Atlassian przedstawia: ITSM o wysokiej dynamice.

Zarejestruj się bezpłatnie

Chcesz wdrożyć proces ITSM o wysokiej dynamice?

Podział ról i obowiązków związanych z zarządzaniem zmianą w zespołach

Podstawowym celem każdej praktyki zarządzania zmianami jest ograniczenie incydentów podczas wysyłania aktualizacji, dzięki czemu klienci są zadowoleni, a Ty wyprzedasz konkurencję. A praktyka stanowi konsekwencję. Obecnie klienci mają większe oczekiwania w zakresie zawsze dostępnych, wysokowydajnych usług. W coraz bardziej dynamicznym środowisku ważne jest ostrożne zarządzanie usługami i dostarczanie częstych ulepszeń. Nowoczesne zespoły przyjęły praktyki umożliwiające ograniczanie ryzyka, jednocześnie dostarczając wartość klientom w najbardziej usprawniony i zręczny sposób.

Aby osiągnąć te cele, organizacje wyznaczyły różne role i obowiązki związane z zarządzaniem zmianami. W dużej firmie można je udostępniać różnie opisanym stanowiskom i zespołom.

W mniejszych organizacjach obowiązki związane z zarządzaniem zmianami wraz z innymi elementami swojej pracy może przejąć jedna osoba. Osoba mająca obowiązki związane z zarządzaniem zmianami może być również programistą lub kierownikiem zespołu. W innych przypadkach procesy mogą być powoli wbudowane i dzielone między istniejące zespoły.

Nie ma jednego właściwego modelu przypisywania obowiązków związanych z zarządzaniem zmianami. Organizacje muszą wykoncypować konfigurację najlepiej odpowiadającą ich potrzebom. Przy tym wszystkie zespoły mogą skorzystać na przemyśleniu podejścia, w którym delegaci zmieniają obowiązki na mające określone tytuły, często są odległe od tych samych projektów, które przeglądają.

Wykorzystując nowe możliwości automatyzacji i usprawnienia praktyki w istniejących przepływach pracy, możemy pozwolić osobom zaangażowanym w zarządzanie zmianami przejąć bardziej strategiczne role, i zwrócić zespołom czas, umożliwiając skupienie się na swoich najważniejszych priorytetach.

Wspólne role zarządzania zmianami

Role związane z zarządzaniem zmianą zależą od wielu czynników, w tym wielkości i rodzaju organizacji IT. Oto niektóre z najczęstszych stanowisk.

Menedżer/koordynator zmian

Menedżerowie zmian, czasami nazywani również koordynatorami zmian, są zazwyczaj odpowiedzialni za zarządzanie wszystkimi aspektami zmian w zakresie IT. Priorytetowo traktują wnioski o zmianę, oceniają ich wpływ oraz akceptują lub odrzucają zmiany. Dokumentują również procesy zarządzania zmianami i zmieniają plany. Co ważne, przygotowują się, organizują, i pełnić funkcję przewodniczącego spotkań CAB. Sukces menedżera zmian jest zazwyczaj oceniany na podstawie tego, czy spełniają one cele czasowe i budżetowe.

Organy/osoby zatwierdzające zmianę

Organ zmiany to osoba, która podejmuje decyzję, czy zezwolić na zmianę. Czasami jest to jedna osoba, na przykład menedżer lub dyrektor wykonawczy. Czasami jest to grupa ludzi w radzie doradczej ds. zmian. Czasami jest to weryfikator. Według ITIL 4, „W organizacjach o dużej szybkości działania powszechną praktyką jest decentralizacja zatwierdzania zmian, dzięki czemu wzajemna weryfikacja jest najlepszym predyktorem wysokiej wydajności”.

Menedżerowie zmian zazwyczaj ściśle współpracują z organem zmiany w celu zatwierdzania zmian i przenoszenia ich do przodu w organizacji. W niektórych przypadkach, szczególnie w małych organizacjach, kierownik zmian jest organem zmiany i ma prawo podejmować te decyzje bez zaangażowania dodatkowych osób lub zespołów.

Interesariusze biznesowi

Interesariusze biznesowi są często zaangażowani w zarządzanie zmianami i mogą być zaangażowani w proces autoryzacji. Jest to coraz bardziej powszechne, biorąc pod uwagę kluczowe znaczenie usług oprogramowania dla większości firm.

Na przykład jeśli zmiana wpływa na połączenie między oprogramowaniem do śledzenia płatności zespołu finansowego a CRM zespołu sprzedaży, zainteresowane osoby z zespołów ds. finansów i sprzedaży mogą potrzebować udziału w spotkaniach CAB i ostatecznych decyzjach podjętych w sprawie zmiany.

Inżynierowie/programiści

Zespoły programistów zazwyczaj składają zmiany do zatwierdzenia i dokumentują sprawę w aspekcie konieczności. Po zatwierdzeniu zmiany, w firmach, które przyjęły podejście „generujesz-uruchamiasz”, zespoły te wdrażają zmianę, monitorują ją, i często reagują na wszelkie incydenty lub problemy związane ze zmianą. W innych przypadkach zespół zarządzający incydentami odpowiedzialny za wszelkie incydenty spowodowane zmianą może być oddzielony od programistów wprowadzających zmianę.

Agenci działów obsługi

Przedstawiciele pomocy technicznej mogą wnieść unikalne, pochodzącą z pierwszej linii perspektywę dotyczącą incydentów i typowych problemów serwisowych, które może spowodować zmiana.

Menedżerowie operacji

Jako odpowiedzialni za utrzymanie systemów działających na co dzień, menedżerowie operacji rozważają ryzyko i zależności.

Menedżerowie ds. relacji z klientem

Aby reprezentować głos klienta, menedżerowie ds. relacji mogą dostarczyć wiedzy na temat sposobu myślenia klientów, frustracji, i ciągle zmieniających się potrzeb.

Dyrektorzy ds. bezpieczeństwa informacji i inżynierowie sieci

Eksperci ds. bezpieczeństwa sieci i infrastruktury chmury przedstawiają ważne informacje na temat zagrożeń i luk w zabezpieczeniach.

Zmieniająca się rola CAB (zmiany rad doradczych)

Co to jest CAB?

Gromadzące pracowników pełniących role mające obowiązki opisane powyżej rady doradcze ds. zmian (CAB) są grupami, których zadaniem jest ocena ryzyka wynikającego z każdego wniosku o zmianę i zatwierdzenie (lub niezatwierdzenie) go. Zwykle CAB organizuje regularnie zaplanowane spotkania w celu przeglądu wszystkich proponowanych nadchodzących zmian, i w razie potrzeby wzywa ekspertów, aby wspólnie z nimi wyjaśnić, bronić lub ocenić zmianę. Tradycyjne CAB są znane jako strażnicy kontrolujący wdrażanie zmian.

Z tego powodu, a także żmudnego przebiegu spotkań, zaległości w żądaniu długich zmian, i oddalenia od samej pracy, CAB są często postrzegane z niechęcią. Na szczęście wiele CAB ewoluuje, aby ułatwić sprawne dostarczanie oprogramowania, przyjmując bardziej strategiczną rolę doradczą. CAB przekształcają się w doradców odpowiedzialnych za monitorowanie trendów zmian, rekomendowanie odnoszących się do nich praktyk i szukanie sposobów na lepsze umożliwienie zespołom dostarczania wartości klientom i zmniejszenia ryzyka.

Wyzwanie stojące przed CAB

Obiegowe opinie dotyczące nieudanych spotkań dotyczą również CAB. Dość mocno krytykujemy je jako marnujące czas, za niewystarczające osiągnięcia, angażowanie zbyt wielu przypadkowych osób i istnienie, podczas gdy mogłaby je zastąpić komunikacja mailowa. Wynika to częściowo ze sposobu, w jaki tradycyjne CAB zostały przeciążone odpowiedzialnością.

Aby zilustrować wyzwanie, przeanalizujmy metaforę pochodzącą z lotnictwa. Możemy sobie wyobrazić CAB jako wieżę kontrolną na lotnisku. Ta wieża kontrolna ma jedno zadanie — powiedzieć załodze samolotu, kiedy będzie mogła wylądować. Nigdy jej zadaniem nie jest ocena czy samoloty są strukturalnie bezpieczne, czy też pilot ma odpowiednie referencje, ponieważ czynniki te są już potwierdzone przez FAA i inne organy .

Tymczasem zbyt wiele CAB gromadzi różnych interesariuszy i ma za zadanie podejmowanie należących do szerokiego zakresu decyzji dotyczących bezpieczeństwa dotyczących wszelkiego rodzaju różnych zmian. Przy tym zdarza się to często pod koniec tygodnia, kiedy zmęczeni ludzie chętnie wyjeżdżają na weekendy. Rady CAB po prostu nie jest skonfigurowane, aby odnieść sukces.

Ponadto spotkania CAB często dotyczą przede wszystkim ryzyka zmian powodujących incydenty. Jest to oczywiście ważne, ale rady muszą również rozważyć ryzyko opóźnienia cennych zmian. Zbyt powolne działanie może zaszkodzić klientom, a w ultrakonkurencyjnym świecie oprogramowaniu jako usługi zniszczyć samą organizację.

Możliwe jest wydźwignięcie zasadniczej roli CAB i skupienie się na niej. Przy odpowiednich praktykach wiele zmian można zautomatyzować. W ten sposób CAB może stać się ważnym doradcą, śledzić trendy i współpracować z zespołami w zakresie sposobów umożliwienia szybszych zmian przynoszących korzyści klientom.

Jak ustanowić CAB jako strategicznego doradcę

Pierwszym krokiem w zmianie pozycjonowania CAB jest rozwianie poglądu, że zarządzanie zmianami najwyższego znaczenia daje pozytywne rezultaty. Dane z raportu State of DevOps 2019 wykazały, że procesy wymagające zatwierdzenia CAB miały negatywny wpływ na wydajność dostarczania oprogramowania, a respondenci po tych procesach byli 2,6 razy bardziej narażeni na niską wydajność. Ponadto nie było dowodów na poparcie tego, że formalny proces zatwierdzania wiązał się z niższymi wskaźnikami niepowodzeń zmian!

Z tego powodu nowoczesne zespoły podejmują te kroki, aby ulepszyć swoje CAB.

Należy przestać traktować wnioski o zmianę na zasadzie „uniwersalnego rozwiązania dla wszystkich”.

Każdy wniosek o zmianę jest okazją do śledzenia i zbierania informacji. Możemy dowiedzieć się o wskaźnikach sukcesu, powiązanych incydentach i czynnikach z nimi skorelowanych. Z biegiem czasu, przy zastosowaniu danych, powinno być możliwe wstępne zatwierdzanie i automatyzowanie coraz większej liczby zmian. Tylko mające najdalej idące konsekwencje i ryzykowne zmiany powinny wymagać osobistej zgody.

Przybliżenie zarządzanie zmianami i wydaniami

Starsze podejście do wydań polegało na łączeniu ich ze sobą i uruchomieniu wszystkich naraz. CAB następnie pozostawiono skrupulatny przegląd i zatwierdzenia ogromnych pakietów zmian. Takie podejście może prowadzić do poważnych incydentów i utrudnia znalezienie źródła problemu, gdy się pojawi. Spowalnia również tempo, dzięki któremu zespoły mogą dostarczać wartość swoim klientom. Oznacza to również, że menedżerowie zmian i wydań mogą przeznaczyć mniej czasu na zadania związane z zarządzaniem projektami.

Stosowanie kolejnych wydań do testowania i iteracji

Korzystne jest stopniowe wdrażanie testów kanarka lub flagę funkcji z małą grupą użytkowników, aby przetestować i udowodnić stabilność przed pełnym wdrożeniem. Ogranicza to zakres potencjalnych incydentów i dowodzi powodzenia wdrożenia przed dokonaniem go we wszystkich środowiskach.

Stosowanie automatyzacji i narzędzi, aby usprawnić zarządzanie zmianami

Zespoły o wysokiej dynamice zaczynają zastanawiać się na nowo nad dotychczasowymi modelami zatwierdzania. Zamiast zajmować się zaległymi od dawna wnioskami o zmianę na cotygodniowym spotkaniu, możliwe jest skorzystanie z wirtualnej współpracy. Może to sprowadzać się do wiadomości e-mail z wyszczególnieniem wniosków o zmianę, aby można je było przejrzeć przed spotkaniem CAB. W innych przypadkach takie elementy, jak zgłoszenia Jira i strony Confluence, mogą zapewnić recenzentom zmiany kontekstu, którego potrzebują do asynchronicznej współpracy i zatwierdzania zmian. Korzystając z Jira Service Management, mogą korzystać z tych sposobów współpracy, a nawet przejść na wideokonferencję lub utworzyć specjalny kanał Slack. Niezależnie od preferowanej formy kontaktu Twój zespół nadal znajduje się w tym samym miejscu, więc wszyscy są na bieżąco.

Starsze narzędzia ITSM utrudniają zespołom ds. infrastruktury, operacji i programistycznym zgłoszenie wniosku o zmianę. Postaw na automatyzację i nowoczesne oprogramowanie, aby zmniejszyć obciążenie związane z ręcznym wprowadzaniem informacji o zmianach. Ostatnią rzeczą, jaką chce robić programista, jest wypełnianie zgłoszeń w niewygodnym, odseparowanym systemie, jeśli ta praca może być monitorowana automatycznie. W Jira Service Management zespoły mogą skorzystać z funkcji automatyzacji, aby usprawnić proces zmian, zminimalizować ryzyko i skrócić czas przestojów.

Przesunięcie w lewo i przybliżenie zarządzanie zmianami do praktyków

Jedną z najczęstszych strategii, która często zastępuje lub zmniejsza zatwierdzenia CAB, jest wzajemna weryfikacja, która nakłada odpowiedzialność za identyfikację problemów w kodzie na tych, którzy najlepiej rozumieją kod. Według ITIL 4, „W organizacjach o dużej szybkości działania powszechną praktyką jest decentralizacja zatwierdzania zmian, dzięki czemu wzajemna weryfikacja jest najlepszym predyktorem wysokiej wydajności”. Podobnie w raporcie State of DevOps 2019 zalecono, aby „organizacje dokonywały „przesunięcia w lewo” w celu zatwierdzenia opartego na wzajemnej weryfikacji w trakcie procesu rozwoju”.

Aby zachować zgodność z przepisami, podejście to musi być skrupulatnie udokumentowane, w czym świetnie sprawdzają się rozwiązania takie jak Bitbucket, które automatycznie śledzą autorów i wzajemne weryfikacje oraz zapobiegają wprowadzaniu zmian bez wymaganego procesu.

W firmie Atlassian wzajemna weryfikacja jest podstawową częścią naszego procesu zatwierdzania. Jak wyjaśniajeden z naszych ekspertów ds. ryzyka i zgodności IT: „Cały kod Atlassian jest przechowywany w Bitbucket. Kiedy programista chce dokonać zmiany, sprawdza kod z Bitbucket i na swoim laptopie. Gdy sprawdzi go ponownie w repozytorium Bitbucket, zamiast aktualizować kod, system jest skonfigurowany tak, aby wymagał wzajemnej weryfikacji. Dopiero po zakończeniu tej weryfikacji i zatwierdzeniu kod zostanie wciągnięty z powrotem do repozytorium. A jeśli kod nie zostanie zatwierdzony? Zostanie odesłany do pierwotnego programisty wraz z notatkami weryfikatora. Naprawi on to, co jest nie tak, i prześle kod do kolejnej wzajemnej weryfikacji”.

Zwoływanie ekspertów w celu umożliwienia dobrych praktyk

W miarę jak organizacje stają się coraz bardziej złożone, ułatwianie przepływu informacji i koordynacji między zespołami ma coraz większe znaczenie. Zamiast zatwierdzać poszczególne wnioski o zmianę, CAB mogą skupić się na doskonaleniu praktyki. W tym paradygmacie mogą szukać zaleceń dotyczących poprawy praktyki, wdrażać lepsze możliwości, oraz zapewnić zasoby i narzędzia, które skutkują lepszą wydajnością. Poszerza to pole widzenia CAB, aby zaradzić ryzyku zbyt powolnego wysyłania wartości na rynek.

Nawet w bardziej tradycyjnych organizacjach IT CAB może stać się miejscem wymyślania kreatywnych rozwiązań. W jednym przypadku, uniwersytet niechętny ryzyku, stosujący się do starszych narzędzi i praktyk ITSM potrzebował sposobu informowania studentów o niedostępności ważnej usługi. CAB stał się forum burzy mózgów nowych taktyk komunikacyjnych. Zdecydowali się na rozsyłanie cukierków i plakatów w ramach kampanii, która skutecznie odwracała przychodzące wnioski o planowane uaktualnienie systemu.

Przypisywanie obowiązków w praktyce zarządzania zmianami w organizacji

Jeśli chodzi o definiowanie ról i obowiązków w praktyce zarządzania zmianami, należy wyjść od zrozumienia, że nie ma jednej uniwersalnej odpowiedzi. Trzeba wziąć pod uwagę kulturę swojej firmy, struktury zespołu, dostępne umiejętności, wymogi regulacyjne, itp.

Aby uzyskać pełne przekonanie do wszelkich ról i obowiązków, których wymaga Twoja firma, zalecamy prowadzenie naszych ról i obowiązków, co polega na zebraniu wszystkich razem, aby zrozumieć wkład każdego członka w zespół i czego wszyscy potrzebują, aby odnieść sukces.

Aby doskonalić swoje role i obowiązki w kontekście zarządzania zmianami, zalecamy rozpoczęcie od zebrania zespołu i omówienia poniższych pytań.

  • Co różne ramy oznaczają dla naszego zespołu? DevOps, CI/CD, ITIL itp.
  • Czy przyjęliśmy ramy całościowo? Czy nasze rozumienie ogranicza się do taktycznych rzeczy, takich jak automatyzacja?
  • W jaki sposób te ramy zwłaszcza DevOps i ITIL, wpływają na nasze praktyki zmian i uwalniania oraz na to, jak współpracują?
  • Jaki jest nasz obecny proces zmian?
    • Kto jest w niego zaangażowany?
    • Gdzie możemy dokonać poprawy?
    • Co możemy zrobić, aby zmienić bardziej powszednie zmiany na standardowe lub wstępnie zatwierdzone?
      • Jakie były najczęstsze zmiany?
      • Jakie zmiany są „standardowymi zmianami”?
      • Jakie usługi mają wpływ?
      • Które zmiany zakończyły się sukcesem?

Zarządzanie zmianami jest ważną praktyką — i nie zmieni się to w najbliższym czasie. Niezależnie od stanu praktyk zarządzania zmianami, zawsze jest miejsce na poprawę, czy to w zakresie śledzenia zmian, czy wdrażania systemów oceny ryzyka i automatyzacji. Dowiedz się, jak funkcje zarządzania zmianami w Jira Service Management mogą zwiększyć możliwości Twoich zespołów operacyjnych IT.