Większość zespołów DevOps żyje w przekonaniu, że zajmuje się jednym: dostarczaniem zmian. Nowe featuresy, bugfixy, poprawki bezpieczeństwa – to widać, to da się policzyć, to trafia do raportów dla zarządu. Problem w tym, że to tylko wierzchołek góry lodowej.
Gene Kim w “The Phoenix Project” wyróżnił cztery rodzaje pracy, które walczą o ten sam czas, te same ręce do klawiatury. I większość organizacji śledzi dokładnie… jeden z nich.
Praca biznesowa – czyli to, za co płacą
To właśnie te zmiany. Nowe funkcjonalności wynikające z user stories, projekty które mają przynieść przychód albo ograniczyć koszty. Widoczne, mierzalne, priorytetyzowane przez Product Ownerów którzy wiedzą swoje.
Pytanie brzmi: ile procent czasu zespołu faktycznie idzie na ten rodzaj pracy?
Praca wewnętrzna – dług techniczny który udaje że nie istnieje
Refaktoring. Upgrade’y bibliotek. Przepisanie tego kawałka kodu który wszyscy omijają szerokim łukiem. Dokumentacja która od dwóch lat czeka na aktualizację. Nikt tego nie widzi – a przynajmniej nikt poza zespołem. Nie trafia do backlogu produktowego, bo jak zmierzyć wartość biznesową “przepisania modułu uwierzytelniania”?
I nagle okazuje się, że praca biznesowa trwa dwa razy dłużej, bo zespół goni własny ogon.
Praca nieplanowana – awarie, eskalacje, pilne poprawki
Produkcja się sypie o trzeciej nad ranem. Klient z enterprise’owej umowy dzwoni bo “nie działa” – i nagle cały sprint leci w diabły. To nie jest wyjątek. To norma którą udajemy że jest wyjątkiem.
Kim zauważył coś brutalnego: im więcej pracy nieplanowanej, tym mniej czasu na pracę wewnętrzną. Im mniej pracy wewnętrznej, tym więcej awarii. Błędne koło które każdy zna – niewiele osób umie je nazwać.
Zmiany – bo przecież DevOps to automatyzacja
Czwarty rodzaj to praca nad samym procesem dostarczania. CI/CD, monitoring, infrastructure as code, usprawnienia pipeline’ów. Paradoks? To jedyna praca która redukuje wszystkie pozostałe – i właśnie dlatego schodzi na sam koniec listy priorytetów.
Bo jak wytłumaczyć biznesowi że zamiast dostarczać featury, będziemy przez dwa tygodnie przepisywać deploymenty?
Większość organizacji śledzi pierwszy rodzaj pracy. Niektóre liczą trzeci – awarie da się zmierzyć, zwłaszcza gdy SLA jest w umowie. Drugi i czwarty? Niewidoczne. A przecież to one decydują o tym, czy zespół przyspiesza – czy zwalnia z każdym sprintem.
Może warto zacząć od pytania: ile godzin w zeszłym tygodniu poszło na każdy z tych czterech typów? I czy ktokolwiek w ogóle wie.
Zdjęcie: Vitaly Gariev / Pexels
