Tym razem rozkładamy na czynniki pierwsze świeżutki raport “State of DevOps Report” prosto z 2023 roku! Zagłębiamy się w DORA Metrics, aby zobaczyć, co naprawdę napędza wydajność naszych zespołów. Będzie też o user centricity – bo kto by pomyślał, że użytkownicy są ważni? 😉 Tune in i zobacz, co jeszcze wyłuskaliśmy z tego raportu!
Słuchasz Patoarchitektów dzięki Protopii. Sprawdź, jak Patoarchitekci i Protopia mogą Ci pomóc ➡️ protopia.tech
Linki i ciekawe znaleziska:
Łukasz Kałużny: Cześć, słuchacie Patoarchitektów. Prowadzą Łukasz Kałużny…
Szymon Warda: I Szymon Warda. Wszystkie linki do tego odcinka znajdziecie na Patoarchitekci.io z odpowiednim oczywiście numerkiem odcinka gdzieś w opisie na górze, na dole, po lewo, prawo, ogarniecie.
Łukasz Kałużny: Tak, a przy okazji pato to the moon, czyli poleć nas babci, albo lepiej koledze lub szefowi, tudzież daj lajka albo subskrypcję tu, gdzie słuchasz. Dobra Szymonie, co dzisiaj mamy na warsztat?
Szymon Warda: Dzisiaj na warsztat coś, co się zwie DevOps Report. Wydawany jest przez Google, bo to jest dość ważne, ale naszym zdaniem chyba to nie do końca jest już to DevOps Report tak naprawdę.
Łukasz Kałużny: Tak, co ważne, to jest już 10, 11 edycja. Już to ma kupę lat, jeżeli popatrzymy sam raport. I najważniejszą wartością z niego było DORA metrics.
Szymon Warda: Kiedyś, dawno temu bym powiedział.
Łukasz Kałużny: Tak. Dobra, to od czego zaczynamy?
Szymon Warda: Ja bym zaczął od tego,jak już ruszyłeś DORA metrics, to są oczywiście te 4 metryki, które mówią nam o tym ile mamy błędów, jak często deploy’ujemy, o tym jak szybko się podnosimy z tego, że coś się wywaliło i jak dobrze działamy. I to jest warte podkreślenia, że duża zmiana, co było też w raporcie, to było to, że stwierdzili, że nie ma sensu maksować te metryki. Dobrze jest być tym high to medium, żeby być w miarę ok. Nie trzeba deploy’wać kilka razy dziennie. Być pośrodku jest naprawdę bardzo, bardzo w porządku. Ten raport znowu parę rzeczy wywraca, bo się skupia dużo bardziej na czym? Na kulturze, naszym zdaniem. Przynajmniej tak patrząc.
Łukasz Kałużny: Tak. Jeszcze wracając na chwilę, zostały te Dora metrics przedstawione, zmierzone, jak wyglądają teraz i tyle. I chyba jedną rzecz, którą o metrykach samych zapraszamy do zeszłorocznego odcinka, który też podlinkujemy. A tutaj te high i medium to jest praktycznie dwie trzecie respondentów w tej ankiecie łapie się właśnie w high albo w medium.
Szymon Warda: Dokładnie. Dobrze, zacznijmy od, bo nawet sam Google jak publikował ten raport, to powiedział, że raport jest duży, 96 stron jest. Tego tekstu tam trochę jest i trochę obrazków. Opublikował 5 rzeczy, na które sami chcieliby zwrócić uwagę. Oni to fajnie nazywają, key findings tak naprawdę. Pierwszą rzeczą, która jest, to jest, żeby mieć zdrową kulturę pracy. I teraz czemu to jest? Czemu pokazują, że to jest ważne? I na bazie czego mierzą? Główną metryką, którą ten raport stara się zoptymalizować, to jest wydajność organizacyjna tak naprawdę. Czyli ile dany zespół, niekoniecznie w kontekście danego zespołu, czyli ile robi pojedynczych swoich tasków, tylko generalnie ile organizacja zyskuje na wydajności tego zespołu i pokazuje…
Łukasz Kałużny: Co jest ciekawe właśnie, mówimy bardzo mocno o rozbijaniu tej wydajności, a najważniejszą jest wydajność organizacji.
Szymon Warda: I słusznie, to się możemy zgodzić. I stwierdzili, że organizacje, które mają zdrową kulturę organizacji, są około 30% lepsze, wydajniejsze od organizacji, które tą kulturę mają trochę gorszą, nazwijmy to po prostu tak.
Łukasz Kałużny: Przy czym ja z tym się pokłócę, bo pojęcie “zmierzyć kulturę” to jest bardzo taka uciekająca rzecz.
Szymon Warda: Uciekająca, ale coraz fajniej, bo przechodzimy do tego, jak oni podzielili te metryki, bo w kontekście kulturowym mieszczą to, że generative culture, zespoły, które są generatywne, przystosowawcze, o tych też było w poprzednim odcinku, bo to było też główne odkrycie, główne stwierdzenie z tego raportu de facto. Stabilność organizacji, bezpieczeństwo pracy, elastyczność pracodawcy, dzielenie się wiedzą, ukierunkowanie się na użytkownika, to też jest dość ważnym elementem tego raportu i rozdzielenie pracy pomiędzy wiele osób, równomierne, niezależnie, bez silosowania. Tak mierzą kulturę organizacji, co ma w wielu sytuacjach jakieś tam i sensowne, powiedzmy sobie to tak. Dobra, idziemy dalej.
Szymon Warda: Kolejnym takim głównym odkryciem to jest budowanie z użytkownikami isocentric, czyli wokół użytkownika, wokół tego, co użytkownik potrzebuje, żeby się na tym użytkowniku głównie skupić.
Łukasz Kałużny: Wiesz co to jest, to określenie? Chyba nawet sam tytuł - Build with user in mind.
Szymon Warda: Tak, dokładnie. Czyli myślimy co użytkownik potrzebuje tak naprawdę, nie budujemy… Może tak różnicowo, czym to się różni? Bo mamy takie podejście, że robimy feature’y de facto i po prostu wykluwamy kolejne funkcjonalności. A to będzie takie, że generalnie patrzymy, żeby polepszyć. Niekoniecznie więcej feature’ów, ale jeszcze poprawiamy, żeby nam się żyło wszystkim ładniej, lepiej. I tutaj twierdzą, że takie zespoły zyskują około 40% wydajności organizacyjnej, ponownie mierząc tą taką metrykę wydajności organizacyjnej.
Łukasz Kałużny: Dobra, i tutaj wiesz co, powiem Ci tak, to jest takie, pokazuje troszeczkę do czego przejdziemy dalej, demografię tego, kto odpowiadał w tych ankietach, bo to jest rzecz dobra dla firm stricte produktowych.
Szymon Warda: Tak, i co więcej, produktowych dla B2C, czyli dla użytkownika końcowego, nie dla biznesu jako takich, bo tam ten format zakupowy i to bycie user centric nie jest tak super kluczowe, nie oszukujmy się.
Łukasz Kałużny: Raczej tak i przy korpo za to systemach, kiedy tworzysz dla takiego klienta końcowego B2B, w szczególności dedykowane, szyte na miarę, to te systemy… Nie można być tam user centric, bo kto inny ma pomysły i wymagania.
Szymon Warda: Kto inny płaci, a kto inny jest użytkownikiem końcowy, mówiąc bardzo prosto de facto. Użytkownik końcowy nie ma prawa głosu często.
Łukasz Kałużny: Tak. Proces jest tak wymyślony, że musisz go dopasować software do procesu i dziękujemy.
Szymon Warda: Tak, ale wydaje mi się, że się z tym zgodzę w zupełności. Jednak wydaje mi się to user centricity całe, czyli skupienie się na użytkowniku, pokazuje też jeszcze jedną rzecz, że są metryki, które wpływają bardzo na to. Jeżeli zespół jest user centric, to w tym momencie mamy lepszą produktywność, zadowolenie z pracy, mniejszy burnout, lepiej Operation Performance, czyli całą formę obsług mamy dużo lepiej zrobioną, lepszą wydajność zespołu i jeszcze wydajność organizacyjną. Wszystko jest generalnie super po prostu. Ale wydaje mi się, że to pokazuje bardziej to, że ludzie potrzebują czuć jakiś cel, że coś robią i to ma realny wpływ. Więc tutaj odbijam piłeczkę i to jest duża rola PO tak naprawdę, żeby to pokazać. I nawet jeśli jesteśmy zespołem B2B typowo i sprzedajemy do korporacji, większość przypadków, to jednak żeby pokazać jaki to ma wpływ, jak się zachowuje i że faktycznie to co robimy ma sens, a nie tylko klikamy w ekran. Więc piłeczka, niech się teraz wykazują.
Łukasz Kałużny: Kolejnym klockiem z tego, co zostało wykazane, to jest coś, o czym ciągle jest powtarzane w tym raporcie, czyli szybsze code review.
Szymon Warda: Tak. I to jest fajny case, bo to jest to zacieśnienie tej pętli zwrotnej, że coś robimy i to do nas szybko wraca, a nie czeka długi czas. I ja się przyznam, jestem winny tego, że niestety code review PR-ów zaniedbuje.
Łukasz Kałużny: Nie tylko Ty. Jakbym powiedział, że szybko review’uję, to ktoś by mnie znalazł zaraz i mi udowodnił, pokazałby mi w paru projektach wiszące. Chociaż akurat nie jestem regularnym członkiem zespołu, więc to troszkę inaczej wygląda i na co innego patrzę zupełnie.
Szymon Warda: Już nie usprawiedliwiaj się.
Łukasz Kałużny: Tak, dokładnie. Winny i koniec. Nie, wiesz co? I to jest rzecz, którą tam mamy gdzieś po boku w swoich dyskusjach, poza nagrywaniem właśnie, jak powinno wyglądać te code review, jak mu poświęcić czas. Bo zresztą jak wspominałeś, to jest bardzo trudna robota.
Szymon Warda: To jest robota, którą łatwo jest opitolić po łebkach de facto i zrobić, żeby było. To jest naprawdę trudna robota. Znam parę osób, które umieją robić dobre code review. Takie naprawdę głębokie i konkretne, ale to zajmuje, na pewno nie10 minut.
Łukasz Kałużny: Tak, albo z innej strony, code review na zasadzie: nie podoba mi się Twój styl kodowania. Bo bardzo często jest tak, że ludzie nie potrafią wyłączyć trochę ego i to, że nie jest coś zgodnie z ich myślą, bo zrobiliby to inaczej.
Szymon Warda: I zgodzę się, dlatego tutaj coraz większy sens dla mnie mają narzędzia, po prostu różne Lintery, które jednak ogarniają wszystkie zasady kodowania i ustaliliśmy, i na ten temat już nie dyskutujemy de facto.
Łukasz Kałużny: Wredny SonarQube nie jest taki zły pod tym względem. Jest bezwzględny.
Szymon Warda: Jeżeli go skonfiguruje dobrze, bo jeżeli się po prostu go doda, włączy i koniec, tyle, to jest ignorowany po mniej więcej miesiącu. Taka prawda. Ale jak jesteśmy przy code review, to drugi element, który podkreślają - dokumentacja.
Łukasz Kałużny: I to jest największe zaskoczenie moim zdaniem tego raportu.
Szymon Warda: To jest zaskoczeniem, ponieważ ten raport jeszcze przy każdym elemencie podaje takie trzy parametry. Podaje rozkład tego, kto co robi, podaje średnią, podaje medianę i podaje przedział między pierwszym a trzecim percentylem tak naprawdę. Czyli ogólnie przyjął, że te rzeczy powinny być po prostu Gauss’em ładnym, czyli że średnia i mediana mieszczą się w naszym przedziale percentylowym. No właśnie, a ta dokumentacja jest trochę inaczej. Dokumentacja - jest taki układ, że rozkład jest dokładnie odwrotny od Gaussa. Czyli jest masa firm, które go w ogóle nie robią, jest kilka pewnie firm, które to robią, a w środku po prostu nie ma nic. Więc to też jest ciekawe dlatego, że jak ktoś twierdzi, że wszyscy inni robią dokumentację, tylko my jej nie robimy, to dane pokazują coś odrobinkę innego, bym powiedział.
Łukasz Kałużny: Czyli większość rynku tego nie robi.
Szymon Warda: Powiedziałbym, że po równo, jest równa grupa, którzy nie robią tego, grupa tych, którzy robią. I jak już się zacznie robić to w którymś kierunku to musi pójść.
Łukasz Kałużny: Tak i najciekawszą rzeczą, bo też w ramach tego pojawia się Trunk Based Development, też jest bardzo mocno promowany w tym raporcie. Tutaj widać mocny Google way i pewnych trendów Big Techowych w całości. I ciekawa metryka jest to, że dobra dokumentacja wspomaga Trunk Based Development, że wpływa to ponad 12-krotnie na wydajność, jeżeli prowadzimy dobrą dokumentację.
Szymon Warda: Znaczy pytanie dotyczy też, nie jest w związku z tym, że generalnie Google bije ich monorepo gdzie to jest konieczne de facto. Trunk na pewno przy kolaboracji większej ilości developerów na jednym repo, to jest jedyna opcja, żeby to skoordynować tak naprawdę. To ma sens. Innym obszarem, który też bardzo jest mocno podkreślany, to jest też luźnie powiązana architektura, czyli Loosely Coupled Architecture. I fajnie pokazują, że to faktycznie ma wpływ po całej szerokości, wszystko staje się lepsze, świat staje się różowy. Trochę się nabijam, ale wpływ na wydajność zespołu i wszystko, jest do tego fajne usprawiedliwienie, znaczy uzasadnienie bardziej, może tak. To jest to, że jeżeli architektura jest luźnie powiązana, to zespoły mogą niezależnie od siebie wprowadzać zmiany bez koordynacji z innymi zespołami. Czyli faktycznie mamy niezależne zespoły, a nie to, że jak natrafimy na coś, to musimy robić nagle serię 10 spotkań z różnymi stakeholderami. Ma to sens, ma to ręce, ma to nogi, tak że generalnie faktycznie ciekawy wniosek z tej całej zabawy.
Łukasz Kałużny: Dobra. Wiesz co, chyba przejdźmy sobie do jeszcze Technical Capabilities, czyli jak wpływa performance, bo tam jest parę takich, moim zdaniem, zaskakujących jeszcze rzeczy. Mianowicie AI, który pojawił się też w tym raporcie w kontekście DevOpsu.
Szymon Warda: Ale pojawił się bez takiego błysku, raczej z opcją meh.
Łukasz Kałużny: No właśnie i to jest zaskoczenie. I co? Słuchajcie, najlepiej pokazuje, że w założeniu AI może powodować obniżenie wydajności, jeżeli chodzi o software delivery performance i operational performance, co zostało wskazane na podstawie tych ankiet. I to jest w ogóle ciekawa rzecz. Ja jeszcze nie zagłębiałem się w pytania, które w to celują.
Szymon Warda: Ale ja też odszukałem wpis na blogu, gdzie Google tłumaczył de facto wyniki tego raportu i te główne odkrycia, itd. I oni to podsumowali, jako że jeszcze tam nie jesteśmy, że AI tak, ale to jeszcze nie jest ten moment, żeby on był przydatny i żeby de facto to nie było potykanie się o własne nogi. Ale to jest ciekawe, że faktycznie on wpływał bardzo neutralnie, bo gdzieniegdzie wpływał negatywnie, a gdzieniegdzie wpływał pozytywnie na wyniki, ale nie było to w ogóle takie odkrycie i znaczący wpływ, tak jak byśmy się spodziewali.
Łukasz Kałużny: Tak i jeszcze taka ciekawostka w ramach technicznych możliwości, to, że jest to też przełożone na wypalenie zawodowe, satysfakcję z pracy, czy taką personalną produktywność. Też to zbadano, te techniczne możliwości. I to, co powiedziałeś, że właśnie ta loosely coupled architecture, czyli te mikroserwisowe, luźno powiązane rzeczy świetnie wpływają na produktywność i satysfakcję, czy zmniejszają wypalenie.
Szymon Warda: Znaczy ogólnie zmieszały frustrację, może tak to nazwijmy.
Łukasz Kałużny: Frustrację, to będzie chyba najlepsze określenie. To ciekawostka, że prawie podobnie zostało wskazane AI względem, czyli na performance wskazało, że nie ma wpływu, albo idzie, spada, a w przypadku tych rzeczy takich personalnych, związanych z człowiekiem jest zupełnie na odwrót.
Szymon Warda: To w ogóle fajnie nawiązuje do tego, co pokazywaliśmy parę shortów temu de facto, że w kontekście tego, co jest realnym obciążeniem dla zespołu, nie wiem czy to jest polskie słowo cognitive flow tak naprawdę, ten kontekst, który musimy trzymać w głowie i czemu ludzie odchodzą. To jest też frustracja, że to frustracja od niebycia decyzyjnym, brakiem możliwości wprowadzenia jakichkolwiek zmian, plus całe cognitive flow i to są powody czemu ludzie odchodzą z pracy. No i oczywiście czasami jeszcze są i menedżerowie, ale to zupełnie inna bajka. Tak że tak, ten raport fajnie to pokazuje. W ogóle ruszyliśmy trochę co on pokazuje. On się skupia bardzo mocno na rzeczach menedżerskich, na rzeczach ludzkich, na rzeczach kulturowych. I w tym momencie może być pół na pół, właśnie rzeczy techniczne i rzeczy kulturowe. Tak że on jest warty do przekartkowania. To jest taka dłuższa chwila kartkowania, żeby przejrzeć te wszystkie rzeczy miękkie. Bo jeszcze jest fajny wniosek, to jest to, jak zmierzyli kwestie osób nie reprezentowanych w zespołach. Czyli nas przykład generalnie mamy zespół z reguły męski i mamy np. jedną kobietę i okazuje się, że osoby, które mają mniejszą reprezentację w zespole, z reguły zajmują się mniej ryzykownymi zadaniami i z reguły częściej zajmują się pracą odtwórczą. Czemu? No bo praca odtwórcza ma mniejsze ryzyko poniesienia porażki, czyli nie wystawiamy się na jakąś możliwość oberwania albo pokazania, że coś nam nie wyszło. Dla mnie to jest ważne do podkreślenia, ponieważ nasze zespoły robią się coraz bardziej mieszane kulturowo, mieszane aspektowo i to jest dobra rzecz. Ale to nie może być na takiej zasadzie generalnie, że wrzucamy ludzi i jakoś tam będzie. Trzeba jednak się tym zainteresować i o to jakoś zadbać. Taki wniosek do przemyślenia dla wszystkich, którzy mają pod sobą jakichś ludzi, zespoły, itd.
Łukasz Kałużny: Ja jeszcze dwie rzeczy, które z tego raportu warto wynieść. Po pierwsze, te wszystkie rzeczy są zrzucone w takie modele graficzne, diagramy, które opisali, więc warto sobie, jest taki podrozdział The Models 10-stronicowy i warto sobie zobaczyć jak, co na co wpływa, bo pokazują te całe połączenia, co lepiej wygląda niż nawet tabele moim zdaniem, jak chcemy wejść w któryś szczegół i zobaczyć co na co ma wpływ. A druga rzecz, to jest demografia. Bo to, co Ty zacząłeś i patrząc się teraz na całość, najważniejsze kto odpowiadał na raport, jeżeli popatrzymy. Ja to, na co patrzę, to lata doświadczenia. Czyli jeżeli popatrzymy, to reprezentacja - 50% respondentów miało 15 albo i więcej lat doświadczenia.
Szymon Warda: I to jest już sporo.
Łukasz Kałużny: Tak, a dolna część, dolna dwudziestka piątka miała dziewięć lat doświadczenia albo poniżej. Czyli to jest bardzo ważne. W założeniu odpowiadały tutaj osoby, które mają już sporo tego doświadczenia nabitego.
Szymon Warda: Czyli dużo mniej hype’u będzie.
Łukasz Kałużny: Tak. I teraz co do hype’u, to, co powiedziałeś i to jest najciekawsze, 36% pochodzi z branży, którą określamy jako technologie i firmy technologiczne.
Szymon Warda: Ja się zaśmieje generalnie, bo właśnie chodzą słuchy, że WeWork będzie bankrutował, a oni reklamowali się jako firma technologiczna.
Łukasz Kałużny: Właśnie, ale wiesz, całość jest. Druga pozycja to jest 13% financial services i czwarta consumer 8%. Reszta jest gdzieś w tyle, więc w ten sposób to pokazuje rozkład. I jeszcze dwie metryki, które są ważne. Pierwsza trójka respondentów to byli Developer Engineer - 30%, DevOps albo SRE 18, menadżer 16%. I potem jest reszta IT. Więc to pokazuje, kto odpowiadał w tym w całości. I kolejną rzeczą to jest w jak dużych firmach respondenci pracują. 21% - ponad 10 i więcej, 18% - 1000-5000 i 17% 100-500. To są takie przedziały.
Szymon Warda: Czyli raczej spore firmy.
Łukasz Kałużny: Tak, ponad połowa pracuje w sporych firmach, powiedziałbym, że kulturowo poza Indiami, które mają tutaj 8% reprezentacji, reszta jest z zachodniego kręgu kulturowego, jeżeli popatrzymy na miejsce pracy. Więc oddaje to naszą rzeczywistość.
Szymon Warda: Tam jest też Anglia,z dość ciekawym opisem, ale w sumie Londyn i sektor finansowy to pewnie wszystko nabił.
Łukasz Kałużny: Pompują tą część.
Szymon Warda: Dobrze, ogólnie raport do polecenia chyba dla mnie bardziej dla menadżerów niż dla DevOps, jak mam być szczery. Może engineering directorów, menadżerów, ten poziom.
Łukasz Kałużny: Coś w ten deseń, tech-leadów, osób, które muszą spinać, że tak powiem, kleić organizacje, a nie interesuje ich sam DevOps.
Szymon Warda: Tak, to się nie powinno nazywać zdecydowanie [niesłyszalne 00:17:50]. Łukaszu, zapomnieliśmy jeszcze o tym ostatnim key finding de facto, które było, że użycie chmury polepsza organizację. To bardzo ważne było.
Łukasz Kałużny: Dobra, jak już szydera na koniec, tak, w tym miejscu Google wcisnął reklamę.
Szymon Warda: Co nie dziwi też trochę, ale nie jest nachalna, więc jest w porządku ten raport.
Łukasz Kałużny: Tak i tylko cloud zwiększa efektywność o 22%, 22-30%, więc tam w zależności którą dokładnie metrykę czytamy, więc nie jest to aż tak nachalne i naciągane.
Szymon Warda: Tak, dobrze kończymy chyba.
Łukasz Kałużny: Kończymy. Na razie.
Szymon Warda: Na razie.