Na czym polega praca z DevOps? Wywiad z Aleksandrem Czarnołęskim i Michałem Piotrowiczem

Pojęcie DevOps kryje za sobą wiele różnych ról i praktyk, które nie sposób opisać jednym zdaniem. Na temat pracy z DevOps, jej charakterystyce oraz drodze do zostania DevOps Engineerem rozmawialiśmy z Aleksandrem Czarnołęskim i Michałem Piotrowiczem z Sollers Consulting.

Co oznacza i jaka jest rola DevOps w projektach? 

Aleksander: To wszystko zależy od tego, jak definiujemy DevOpsa. Najczęściej spotykamy się z rolą DevOps Engineera, którego celem jest automatyzacja procesu wytwórczego oprogramowania. I to jest częściowo zgodne z całym podejściem DevOpsowym, ale pomija bardzo istotny aspekt kulturowy i organizacji procesów – źle zaprojektowany proces manualny, po automatyzacji będzie źle zaprojektowanym procesem automatycznym.  

DevOps jest bardzo szerokim pojęciem, pod które można podpiąć wiele praktyk – zazwyczaj sprowadzam je do następującej definicji: optymalizacja procesu wytwarzania i dostarczania oprogramowania poprzez zapewnienie odpowiedniej kultury organizacyjnej, procesów i, na samym końcu, narzędzi.  

Biorąc pod uwagę postrzeganie rynkowe oraz nasze doświadczenie z podejściem DevOps, najczęściej wyróżniamy dwa typy projektów: 

1. Jeżeli działamy na pojedynczym projekcie u naszego klienta i nie mamy większego wpływu na działanie całej organizacji, skupiamy się na zbudowaniu jak najwyższego poziomu dojrzałości i automatyzacji procesu wytwórczego na poziomie projektu. Polega to na optymalizacji i automatyzacji procesu wytwarzania i dostarczania oprogramowania, jak również na budowaniu odpowiedniej świadomości u klienta na temat praktych DevOpsowych, takich jak bliska współpraca zespołów developerskich z biznesem, wczesnego testowania, zwiększania umocowania (empowerment) zespołu do podejmowania decyzji, zapewniania zespołowi narzędzi do tworzenia rozwiązania end-to-end, itd.  
2. W przypadku projektów, których celem jest zmiana organizacji po stronie klienta, mamy zdecydowanie większy wpływ na postawienie odpowiednich fundamentów prawidłowej kultury organizacyjnej i zaprojektowania procesów na poziomie całej firmy. Staramy się wtedy znaleźć złoty środek pomiędzy zapewnianiem zespołom odpowiednich narzędzi i swobody tworzenia, jak również wprowadzania pewnych ram, które pozwalają utrzymać spójne podejście technologiczne i wspomagają re-używanie przygotowanych rozwiązań oraz utrzymanie spójności wytwórczej na poziomie całej organizacji.  

Oferty pracy z

Czy już na początku swojej kariery wiedzieliście, że chcecie związać ją z DevOps? Jak wyglądała Wasza droga? 

Ścieżka od pozycji Business Analyst do Senior Consultanta

Aleksander: U mnie ścieżka była dosyć nietypowa, ponieważ w Sollersie zaczynałem jako analityk biznesowy. Początkowo odpowiadałem za procesy zbierania i tworzenia wymagań funkcjonalnych, kontakt z ekspertami domenowymi, czasami przygotowywanie scenariuszy testowych i ich późniejsze testowanie. Z uwagi na to, że Sollers zapewnia dużo możliwości rozwoju poziomego – w ramach firmy, ale poza aktualnie wykonywanym projektem, dostałem propozycję koordynacji kompetencji DevOps wewnątrz firmy. Zadanie polegało bardziej na organizacji ludzi w ramach kompetencji niż tworzenie przeze mnie rozwiązań (na tamten moment ledwo rozumiałem pojęcie DevOps!). Początkowo nie widziałem miejsca, gdzie mógłbym dostarczać wartość, ponieważ nie byłem w żaden sposób osobą techniczną.

Dopiero z czasem zrozumiałem pełniejszą definicję DevOps i zorientowałem się, że jeżeli odpowiednio się doszkolę i lepiej zrozumiem proces wytwórczy oprogramowania, będę w stanie pomagać w budowaniu odpowiedniej kultury organizacyjnej oraz optymalizacji procesów. Zacząłem więc czytać dużo książek, prezentacji, szkoleń, a przede wszystkim rozmawiać więcej z developerami, architektami, inżynierami infrastruktury, żeby lepiej zrozumieć ich codzienność i problemy, z którymi się borykają. Wraz z nabywaniem wiedzy oraz decyzją strategiczną, by więcej inwestować w rozwój produktów DevOpsowych, moja kariera zaczęła coraz bardziej kręcić się wokół tego obszaru. Następnie pojawiły się projekty, gdzie pomagałem budować kulturę organizacyjną i optymalizować procesy wytwórcze u klientów. Tak trafiłem tu, gdzie jestem.  

Ścieżka od pozycji IT admin do IT Manager/ Head of DevOps

Michał: Swoją karierę rozpoczynałem jako administrator systemów oraz infrastruktury. Z biegiem czasu angażowałem się coraz bardziej w zewnętrzne projekty dla klientów, ponieważ chciałem rozwiązywać problemy, z którymi mierzyli się moi koledzy z zespołów wytwórczych. Wcześniej bardzo często spotykałem się z ironicznymi pytaniami kolegów z biznesu, którzy komentowali swoje bieżące zaangażowanie, mówiąc „czemu to nie może działać tak jak u nas?”. W tamtym czasie termin DevOps był jeszcze mocno raczkujący – sami nie wiedzieliśmy, jak nasze pomysły i inicjatywy definiować. Wówczas popularność zdobywała metodologia Agile, którą przekładaliśmy na pracę nad infrastrukturą. Realizując kolejne projekty, rozwiązując problemy – coraz częściej docieraliśmy do nowych narzędzi i materiałów, w których pojawiał się termin DevOps jako praktyka wspierająca efektywne dostarczanie oprogramowania. To wszystko ugruntowało to, czym teraz jest kompetencja DevOps w Sollersie. 

Patrząc z perspektywy czasu, w moim przypadku dojście do roli IT Managera, to wypadkowa przede wszystkim dwóch rzeczy. Z jednej strony wiedza technicza połączona z pewnością siebie, dzięki którym często kwestionowałem standardowe „nie da się”, które w IT pada zaskakująco często. Z drugiej strony to chęć pracy zespołowej – dość szybko zrozumiałem, jak dużo zależy od samych ludzi oraz ich zaangażowania – tego, czy mamy wspólne cele, czym się kierują, czy rozumieją, jaką wartość przynosi nasza praca. 

Wszystko, o czym za mało mówi się w branży IT.

Prosto na Twoją skrzynkę.

Oświadczam, że zapoznałem/am się z Polityką Prywatności oraz akceptuję jej treść.

Leave this field empty if you’re human:

Jak znaleźliście się w Sollers? Co cenicie w tej pracy? 

Aleksander: Praca w Sollersie była moją drugą pracą, którą zacząłem jeszcze w czasie studiów. Miałem wcześniej doświadczenie w rekrutacji IT, co było dobrym punktem startowym, ponieważ dawało mi lepsze zrozumienie branży.

Po 4 latach tutaj doceniam przede wszystkim płaską kulturę organizacyjną oraz możliwość angażowania się w różne projekty i inicjatywy, czego sam jestem przykładem, bo zacząłem pracę jako analityk, ale miałem możliwość rozwoju w innym kierunku. Czuję, że Sollers dba o pracownika i przykłada uwagę do tego, by każda zmiana realnie poprawiała komfort pracy. Wszystkie takie zmiany są konsultowane i nie wychodzą z góry, ale właśnie w wyniku pracy zespołowej – tutaj istotna jest otwartość na feedback. Jeśli dana zmiana spotyka się z niezadowoleniem, jest to brane pod uwagę i dostosowywane do prawdziwych potrzeb pracownika. To chyba dobre podejście, bo od mojego startu (czyli od ponad 4 lat), firma urosła o kilkaset nowych osób.

Ważne jest dla mnie też to, że w Sollersie jest mnóstwo możliwości integracji – począwszy od comiesięcznych spotkań, poprzez wyjazdy integracyjne (jak np. do Malagi czy na Kretę), do budżetów integracyjnych, które pracownicy mogą wykorzystać na wspólne wypady. W tym roku były to kilkukrotnie góry, żagle czy wypady rowerowe po Europie.

Michał: Dla mnie Sollers był pierwszym poważnym zaangażowaniem po kilku krótszych epizodach w karierze. To, co podobało mi się od samego początku i nie zmieniło się do tej pory, to duże zaangażowanie ludzi i wielka otwartość na zmiany oraz ciągłe dążenie do poprawy jakości. To, w połączeniu z płaską strukturą, o której wyżej mówił Aleksander, sprawiło, że mogę realizować się na dwóch płaszczyznach: wspierać klientów przy projektach transformacji cyfrowych, a jednocześnie pracować nad rozwojem swoim i całej firmy. A rozwój to jedno z kluczowych słów w Sollersie, nie tylko w kontekście biznesowym, ale i indywidualnym w kontekście pracownika, który chce podnosić swoje kompetencje.

Co łączy DevOps i Agile? 

Aleksander: Agile zaczyna być obecny praktycznie w każdej firmie, która zajmuje się wytwarzaniem oprogramowania. Z naszych obserwacji wynika jednak, że większość implementacji zwinnych praktyk, jest robiona tylko do pewnego stopnia i tylko w części organizacji. Powstało już nawet pojęcie, które to obrazuje – water-scrum-fall i oznacza, że zespoły wytwórcze działają zgodnie z praktykami Agile, jednak wszystkie rzeczy, które dzieją się przed procesem wytwarzania (np. budowanie celów, budżetowanie, dekompozycja celów), jak również późniejszy proces utrzymania, odbywa się w podejściu kaskadowym (waterfall). Wtedy organizacje rozczarowane są Agilem, ponieważ pomimo jego wprowadzenia, tempo dostarczania produktów na rynek zmieniło się nieznacznie lub wcale.

I tutaj z pomocą przychodzą praktyki DevOps, które rozbijają te silosy w procesie wytwarzania i dostarczania oprogramowania. Pomagają również zespołom wytwórczym wypracować wszystkie narzędzia oraz kompetencje (biznesowe i techniczne), tak aby mogły odpowiadać za proces od początku do końca. 

Michał: Zgadzam się z przedmówcą! Nie można osiągnąć zwinności biznesowej bez odpowiednich fundamentów w postaci zwinności technicznej. Dopóki techniczna strona dostarczania oprogramowania jest ograniczeniem, dopóty firmy nie osiągną pełnej wartości biznesowej z wdrożenia metodologii agile. Wdrażając praktyki DevOpsowe w naszych projektach, umożliwiamy zespołom skupić się na tym, co jest istotne, co w dłuższej perspektywie przełoży się na rezultat biznesowy.  

Jaka przyszłość czeka DevOps? 

Michał: Myślę, że dalej będziemy doprecyzowywać to, czym DevOps jest i jak organizacje rozumieją to hasło. Już obserwujemy zmianę w kierunku większej świadomości, że w kulturę DevOps warto inwestować, a samo hasło przestaje być jedynie re-brandingiem dla zwykłego IT Operations. Nasi klienci zaczęli dostrzegać wartość w tym, że wdrażając praktyki DevOpsowe w połączeniu z podejściem zwinnym, są w stanie osiągać dużo lepsze rezultaty i to nie tylko w obszarze wytwarzania oprogramowania. Przykładem jest liczba ofert tytułowanych różnymi wariacjami „DevOps” – „DataOps”, „SysOps”, „SecOps”, itp. Pod tymi nazwami kryje się implementacja praktyk, które mają przynieść wartość, usprawnić pracę w danym obszarze i wyeliminować silosowość zespołów. Value Stream Management (VSM) to kolejne hasło komplementarne z DevOps. To technika pozwalająca patrzeć holistycznie na jakość wytwarzanych przez nas produktów i na to, czy znajdują one odbiorców. Agile i DevOps odpowiadały przede wszystkim za to, aby dostarczać sprawnie i w technicznie dobrej jakości. VSM dokłada to tego kolejny czynnik – analizę tego, czy to, co tworzymy, jest wartościowe dla końcowego użytkownika.

Aleksander: Mam wrażenie, że z czasem DevOps i praktyki, które kryją się pod tym hasłem, staną się naturalną częścią każdej firmy, która ma coś wspólnego z IT (co w obecnych czasach oznacza praktycznie każdą firmę). Wymaga to oczywiście licznych procesów transformacyjnych, które przygotują kulturę organizacyjną do nowego tempa pracy i innego podejścia do rozwiązywania problemów. Wierzę, że tak, jak obecnie naturalne jest, że większość firm prowadzi projekty w duchu agile, tak niedługo to samo stanie się z praktykami DevOps. Z uwagi na to, jak szerokim pojęciem jest DevOps uważam, że jego wdrażanie będzie się coraz bliżej wiązało z innymi, obecnie kluczowymi technologiami — jak chmura, big data, AI czy machine learning. Ułatwi to skorzystanie z tego, co najlepsze na rynku, a w rezultacie pozwoli na wypracowanie najefektywniejszych metod wytwarzania oprogramowania.

---

Aleksander Czarnołęski – Senior Consultant w Sollers Consulting. Ukończył studia na kierunku Zarządzanie w Szkole Głównej Handlowej w Warszawie. Od blisko 5 lat wdraża rozwiązania IT dla międzynarodowych firm z sektora finansowego. Przez ostatnie 3 lata skupiony w większości na wdrożeniach praktyk i narzędzi zwiększających efektywność dostarczania oprogramowania IT zgodnie z podejściem DevOps i Agile.

Michał Piotrowicz – IT Manager w Sollers Consulting. Ukończył studia na wydziale Cybernetyki na Wojskowej Akademii Technicznej w Warszawie. Od 11 lat pracuje w projektach związanych z wdrażaniem i administrowaniem systemów IT, a od ostatnich 8 skupia się na efektywności procesów wytwórczych oraz wdrażaniu praktyk DevOps w obszarze IT. 

Zdjęcie główne pochodzi z unsplash.com