IT Operations a zmiany organizacyjne, właścicielskie i fuzje zespołów IT

Ówczesny właściciel grupy Morizon-Gratka podjął decyzję o wydzieleniu portalu Gratka.pl i poszukaniu nowego inwestora. Jak każda zmiana, taka decyzja pociągnęła za sobą wiele obaw. Zarówno ze strony członków zespołu, jak i managerów.  W nowej rzeczywistości organizacyjnej wyzwaniem wydawało się zadbanie o ciągłość biznesu i stabilność zespołów, co wymagało nowego podejścia do IT Operations. Jednak na tym etapie Michał dostrzegł szansę na wdrożenie filozofii DevOps.

Obawy i szansę Managera IT towarzyszące wydzieleniu spółki

Podczas prelekcji, Michał Godlewski z Morizon-Gratka podzielił się swoimi przemyśleniami i obawami, które pojawiły się podczas przygotowywania działu IT do dużej transformacji.  

1. Niepewność co do przeprowadzenia procesu:
Michał wyraził wątpliwości dotyczące samego procesu wydzielenia. Jako menedżer, miał trudności z wyobrażeniem sobie, jak przeprowadzić ten proces „suchą nogą”, bez większych zakłóceń. Było to dla niego dużym wyzwaniem logistycznym i organizacyjnym.

2. Zapewnienie ciągłości biznesowej:
Jednym z głównych zadań było zaprojektowanie nowej struktury i zebranie niezbędnych kompetencji, aby zapewnić ciągłość organizacji i jej działalności biznesowej. Michał obawiał się, czy nowa organizacja będzie w stanie funkcjonować stabilnie od samego początku.

3. Stabilność i zasoby ludzkie:
Istniały obawy, czy nowa struktura będzie stabilna i czy będą potrzebne dodatkowe zasoby ludzkie, aby utrzymać operacje na dotychczasowym poziomie. Michał wskazał na ryzyko niedoszacowania liczby potrzebnych pracowników, co mogłoby prowadzić do problemów operacyjnych.

4. Koszty i ryzyko operacyjne:
Michał obawiał się, że zaprojektowana koncepcja może nie być wystarczająco dokładna, co mogłoby prowadzić do nieprzewidzianych kosztów. Istniało ryzyko, że operacje „wybuchną im w twarz”, jeśli liczba ludzi i inne zasoby nie zostaną odpowiednio zaplanowane.

5. Odpowiedzialność i zmiana kultury pracy:
Zespoły były przyzwyczajone do pewnego podziału odpowiedzialności, gdzie maintenance zajmował się problemami po wdrożeniach. Michał podjął ryzyko zmiany tego podejścia, chcąc zbudować organizację w modelu DevOps, gdzie zespoły są bardziej odpowiedzialne za całość procesu, w tym za utrzymanie.

6. Zabezpieczenia i zarządzanie ryzykiem:
Michał mówił o różnorodnych środkach zabezpieczających, które miały na celu ochronę organizacji przed nieprzewidzianymi problemami. Wskazał jednak, że te zabezpieczenia były bardziej odpowiedzią na potencjalne zagrożenia niż elementem przyszłościowej wizji rozwoju organizacji.

7. Szansa na rozwój poprzez DevOps:
Pomimo obaw, Michał dostrzegł w tym procesie szansę na rozwój. Wydzielenie spółki stało się okazją do wprowadzenia praktyk DevOps, co miało na celu poprawę efektywności operacyjnej i lepsze przygotowanie organizacji na przyszłe wyzwania.

Budowanie odpowiedzialności zespołów

Jednym z kluczowych elementów było wprowadzenie DevOps. Pracownicy zaczęli czuć odpowiedzialność za swoje działania i proponować liczne usprawnienia. W bardzo naturalny sposób zaczęła zwiększać się odpowiedzialność zespołów za ich produkty.  

Nowy właściciel i nowe szanse

Kolejnym etapem było przejęcie spółki przez nowego właściciela, co otworzyło nowe możliwości biznesowe. Michał podkreślił, że choć formalny proces fuzji trwał miesiącami, to już wcześniej pojawiły się potrzeby budowania wspólnej oferty. Zespoły, które wcześniej rywalizowały ze sobą, musiały teraz współpracować, co wymagało skutecznej komunikacji i wyjaśnienia wspólnych celów biznesowych.

Łączenie zespołów i budowanie nowej organizacji

Proces łączenia zespołów był trudnym wyzwaniem. Michał zwrócił uwagę na znaczenie transparentnej komunikacji i budowania wspólnych celów przed formalną fuzją. Warto zadbać o to, by zespół czuł się zaangażowany i odpowiedzialny za wspólne działania. Michał podkreślił także znaczenie przewietrzenia ról i struktur organizacyjnych, co pozwala lepiej wykorzystać kompetencje pracowników i dostosować organizację do nowych realiów.

Kluczowe lekcje i wnioski

Na zakończenie Michał podsumował swoje doświadczenia, wskazując na kilka kluczowych lekcji:

1. Odpowiedzialność za rolę: Kluczowe jest jasne określenie odpowiedzialności poszczególnych ról i zespołów.
2. Suwerenność zespołów: Ważne jest, aby zespoły miały swobodę działania w ramach określonych ram.
3. Wizja architektury: Nakreślenie docelowej wizji architektury technologicznej pomaga w zrozumieniu kierunku, w którym zmierza organizacja.
4. Eksperymentowanie: Zachęcanie do eksperymentowania i wprowadzania nowych metod pracy może przynieść znaczące korzyści.
5. Wartości organizacyjne: Wspólne wartości są fundamentem skutecznej współpracy i budowania zaangażowania.