DevOps - trudno, ale warto

Najprostsza odpowiedź brzmi - o wspólny cel biznesowy dla deweloperów i administratorów jakim jest dostarczanie najlepszego z możliwych produktu. Zatem ideą DevOps jest dążenie do doskonalenia dostarczania wartości klientom i biznesowi, a jej realizacja w strukturach i procesach IT może być różna. Redukcja kosztów czy automatyzacja nie stanowią celów samych w sobie.

Dla wielu takie ujęcie tematu brzmi jak otworzenie Puszki Pandory. Macie rację, praca nad relacjami między obszarem produkcji i operacji nie jest łatwa i napotka wiele trudności, o których później. Pytanie czy warto?

Doroczne badania [2] pokazują ogromny i bezpośredni wpływ współpracy Dev i Ops na wysoką wydajność IT i całych organizacji. Optymalizacja całego procesu wytwarzania produktu, zamiast wybranych obszarów nie tylko przyspiesza dostarczanie, ale podnosi jakość i bezpieczeństwo. Gdzie w tym pieniądze?

Po pierwsze w oszczędnościach związanych z redukcją kosztów pracy nadmiarowej (co najmniej 2 mln dolarów rocznie w przypadku małych i średnich przedsiębiorstw [2]) i czasu niedostępności systemów (różnica na poziomie 2 mln dolarów przy pojedynczym wdrożeniu między organizacjami nisko i wysoko wydajnymi [2]).

Po drugie w zyskaniu 10 proc.  więcej czasu pracy nad nowymi rozwiązaniami (tu ROI jest już bardzo zależne od danego biznesu) [2]. Inaczej mówiąc IT odgrywa bardzo istotną rolę w redukcji czasu między pomysłem a dochodem, a szeroko rozumiany DevOps ten czas skraca.

Warto

DevOps jest drogą do minimalizacji ryzyka błędów aplikacji produkcyjnych. Podejście organizacyjne, na które nie ma jednej prawidłowej recepty (choć istnieją zalecane, sprawdzone typologie), jest wpierane przez grupę technologii automatyzujących proces (continuous integration i continuous deployment) czy pracę z infrastrukturą oraz ujednolicenie i łatwiejsze zarządzanie środowiskami. Są to elementy stanowiące wyzwania dla informatyków, którymi wielu z nich chętnie się zajmuje.

Rosnące zaangażowanie załogi zaczyna się często od indywidualnych inicjatyw, które odpowiednio wsparte, doprowadzają do szerszego sprawdzania rozwiązań usprawniających pracę nad produktem. Na tej drodze można często usłyszeć “my” i “oni”, aż do pierwszej wspólnej inicjatywy Dei i Ops, kiedy to obie strony zaczynają rozumieć perspektywę “tych drugich”.

Wraz z zaangażowaniem rośnie odpowiedzialność za rozwiązania - od ich propozycji, przez realizację, po wdrożenie, a co za tym idzie dbanie o jakość na każdym etapie rozwoju produktu. Wymiernym rezultatem jest 22 proc.  redukcja  czasu poświęcanego na nieprzewidziane zadania i poprawki [2].

Na kanwie zaangażowania, zaufania i poczucia odpowiedzialności można budować organizację korzystającą z eksperymentalnego podchodzenia do rozwoju produktów. DevOps wspiera transparencję procesu od pomysłu po produkcji (Lean), interacyjność i przyrostowość (Scrum) i sposoby realizacji próbkowania pomysłów (Lean Startup, Design Thinking). Przy czym nie stwierdzono ograniczeń w osiąganiu wysokiej wydajności przez rozmiar firmy, czy rodzaj realizowanych projektów (greenfield, brownfield, czy legacy). [4]

Ma to znaczący wpływ na kulturę pracy i poczucie zespołowości. Employee Net Promoter Score (eNPS) [2] pokazuje, że pracownicy bardzo wydajnych (high-performance) organizacji dwa razy częściej polecają pracę w swoim zespole i u danego pracodawcy swoim kolegom i koleżankom, niż pracownicy organizacji mało wydajnych.

Trudno

Środowisko pracy nad produktami IT jest z reguły złożone i w odróżnieniu od skomplikowanego, zgodnie z modelem Cynefin, powinno czerpać z empirycznego podejścia próbkowania. Kluczowym staje się stworzenie środowiska dla bezpiecznych eksperymentów. To z kolei kładzie dużą odpowiedzialność na liderów organizacji, których należy wspierać w tworzeniu otoczenia sprzyjającego międzyfunkcjonalnym (cross-functional) i samoorganizującym się zespołom [3].

Zmiana dokonuje się nie tylko w procesie, ale również (a może przede wszystkim?) w kulturze organizacyjnej [3]. Organizacje, które opisują swoją drogę do DevOps podkreślają, że aspekt kulturowy jest czynnikiem mogącym zapewnić trwałość zmian. Zatem pojawia się kolejna trudność z zakresu zarządzania zmianą i to ta najtrudniejszą, bo dotykającą ludzkich przekonań, zachowań i nawyków.

Istotne, aby pamiętać jaka jest wizja dokonywanej zmiany [5], gdyż pozwala ona obrać prawidłowy kierunek. Podczas, gdy odkrycie najlepszej dla danej organizacji drogi będzie trwało dłużej i samo w sobie powinno być serią eksperymentów. Czynniki mające wpływ na finalnie wybrane rozwiązanie (struktura, proces, narzędzia) to między innymi rodzaje produktów, poziom rozproszenia decyzyjności, indywidualne chęci rozwojowe pracowników czy nawet kultura kraju, w którym znajduje się biuro.

Im później zaczynamy budować środowisko zaangażowane w ciągłe doskonalenie, tym trudniej jest o inwestycję czasową i tym trudniej o utrzymanie regularnego procesu plan - do - study - act.

Nie czy, a kiedy?

Potencjalna nagroda DevOps w postaci wysoko wydajnej organizacji jest odpowiedzią na dynamikę rynku. W zależności od otoczenia biznesowego może pozwolić na przetrwanie lub nawet na osiągnięcie pozycji lidera. Decyzja o próbie zbudowania kultury DevOps jest kusząca. Przy odpowiednio zdefiniowanych potrzebach i reakcjach na pojawiające się przeciwności, realizacja jest  w zasięgu wielu.

Najwięksi gracze już realizują tę strategię. Nie warto ich kopiować, bo sposobów realizacji jest wiele. Warto zrozumieć, dlaczego podjęli takie kroki. Zostanie liderem może się przytrafić, pozostać nim na długo to dzisiejsze wyzwanie.

[1] “DevOps War Stories”, InfoQ, styczeń 2014
[2] “2016 State od DevOps Report”, Puppet Labs
[3] “The DevOps mindset, real-world insights fromtech leaders”, Rackspace
[4] “2015 State od DevOps Report”, Puppet Labs
[5] “8 steps to accelerate change in 2015”, Kotter International