Łukasz Kałużny: Cześć, słuchacie Patoarchitektów. Prowadzą Łukasz Kałużny…

Szymon Warda: I Szymon Warda. Wszystkie linki tego odcinka. Oczywiście na Patoarchitekci.io albo gdzieś na dole w opisie. Uważamy, że ogarniecie. No to co Łukasz, ogłoszenia parafialne, czyli szkolenia.

Łukasz Kałużny: Tak, szkolenia, ostatnie w tym roku na początku grudnia - Architektura101, które prowadzę, uczy podstaw myślenia jak architekt, jak wygląda system, design i o czym pamiętać tudzież porządkuje wiedzę, więc zapraszam. Link na dole w opisie odcinka. To o czym dzisiaj, Szymonie?

Szymon Warda: Dziś w sumie to już nasz zwyczaj, bo to jest trzecia iteracja tego raportu, czyli mianowicie DevOps Report, tudzież po prostu Dora Report.

Łukasz Kałużny: Tak, State of DevOps.

Szymon Warda: Tak, Ty to ładnie nazwałeś, niech będzie. Ale głównie się to zaczęło od całej Dory. I tu przypominamy o odcinku 1.2.1 z Kingą odnośnie właśnie wdrażania metryk, itd. Warto przesłuchać przy okazji, jeżeli ktoś teraz dołączy, albo nie pamięta o co chodzi, albo chce po prostu pogłębić wiedzę.

Łukasz Kałużny: I dorzucając, Kinga jest z grupy Pracuj czyli Pracuj.pl, więc można posłuchać jak to w firmie, którą możecie kojarzyć z zewnątrz, wygląda w środku.

Szymon Warda: Dokładnie. Co tam Łukaszu? No to lecimy w takim razie Dora Reports. Zacznijmy od tego, od czego to się właściwie zaczęło, czyli od tych czterech filarów, bo teraz ten raport się dość mocno rozrósł. Więc jakie mamy cztery filary tego?

Łukasz Kałużny: Dobra, cztery filary, to są cztery, w sumie trzeba to nazwać metrykami.

Szymon Warda: Okej.

Łukasz Kałużny: Trzeba nazwać to metrykami, czyli czas wprowadzenia zmiany pomiędzy, w zależności jak to zdefiniujemy, od commita do commita kodu, do wdrożenia na produkcję. To jest jedna rzecz. Druga, to jest jak często wdrażamy. Trzecia, jak często okazuje się, że wdrożenie było failem. I czwarta, jaki mamy czas recovery po wdrożeniu, które było failem. Tak można podsumować te cztery metryki.

Szymon Warda: Tak, ja bym tylko uzupełnił, że ten Change Failure Rate to jest bardziej jak często zmiana spowodowała błąd tak naprawdę, niekoniecznie wdrożenie. Dobra, tak kiedyś te metryki wyglądały i na tym się głównie cały DevOps skupiał. Chyba to było dwa lata temu jak sektor DevOps zaczęli klasyfikować osoby [niesłyszalne 00:02:42] czy też firmy właściwie na cztery kategorie. Jest Elite. To są ludzie, to są firmy, które właściwie mają Change Lead Time, jest poniżej dnia, częstotliwość wdrażania jest ok. powiedzmy na żądanie, fail rate około 5% i Failed Deployment Recovery Time, to jest mniej niż godzina. Bo przed tym czasem to było tak, że wszyscy dążyli do: maksymalizujemy te wszystkie metryki, a potem mamy jeszcze H, itd., i stwierdzili, że ok, nie wszyscy muszą być w klasie Elite. Tak naprawdę bycie w High w zupełności wystarcza. Czyli powiedzmy tam Change Lead Time jest pomiędzy dniem a tygodniem. Change Deployment Frequency jest pomiędzy jednym dniem a znowu tygodniem i tam mniej więcej jest… Change Failure Rate jest wysoki bo jest 20%, więc naprawdę jest wysoki, ale dalej możemy. Fail Deployment Recovery Time jest mniej niż jeden dzień, czyli takie bardzo sensowne metryki i tam mniej więcej widzą około 22% respondentów. I to jest to, do tego, żeby wszyscy dążyli, powyżej nie ma sensu.

Łukasz Kałużny: Tak, jak zobazymy, w ogóle rozkład, to on jest ładny, bo jest taki prawie że… Na Elita to jest około 19%, High to jest 22, Medium - 35, Low - 25. Jak popatrzymy na High, to jest trochę powiedzenie… Powinno być to przykładem dla zespołów wszystkich agile’owych, scrumowych, które pracują iteracyjnie, gdzie sprint ma tydzień, dwa.

Szymon Warda: High jest naprawdę sensowną metryką. Bo też mówimy głównie o korporacjach, organizacjach dużych, nie rzeczach client facing, czyli takich rzeczach, które są dostępne z internetu. No, powiedzmy sobie, tutaj odzyskanie po jednym dniu jest trochę gorszą wartością. Ale dla aplikacji, powiedzmy sobie wewnętrznych czy też używanych przez biznes, to są naprawdę sensowne wartości, do których można spokojnie dojść. A jak byście chcieli dowiedzieć się jak albo chcielibyście pomocy, no to oczywiście nasza Protopia chętnie pomoże, bo takie konsultacje też robimy. Dobrze. Dobra, to w takim razie co się teraz zmieniło w całym raporcie State of the DevOps? Bo on jest długi, on ma chyba 60 stron, jakoś tak? 50?

Łukasz Kałużny: Ty, pomyliłeś się, 120 ze wszystkimi zapchajdziurami.

Szymon Warda: Tak, tego jest generalnie dużo, więc on jest długi. Więc powiedzmy sobie, że te metryki, o których mówiliśmy i poziom klasyfikacji to jest pierwsze, nie wiem, 15 stron?

Łukasz Kałużny: 16, coś takiego. Tak, 16 stron, to jest ten core starego raportu. I poprzedni raport, jak sobie zerknąłem, sprawdzał się na developer happiness i developer experience.

Szymon Warda: Tak, tego było dużo. Też w tej edycji, może omówmy to teraz, w tej edycji faktycznie tego happiness jest dużo mniej. Moja teoria, znaczy dalej podkreślają, że to zmniejsza wypalenie, zmniejsza ilość osób odchodzących z pracy, zwiększa produktywność, itd. Ale moja teoria jest taka, że na to teraz jest dużo mniejszy nacisk z prostego powodu, tego, jak obecnie rynek wygląda, czy że po prostu jest bardziej rynek pracodawcy. Więc no już nie chwalili się, bo ewidentnie developer experience jest mocno obcięty w tym raporcie.

Łukasz Kałużny: Tak. Przy czym wnioski tutaj są, wiesz, pominąłbym je tutaj w tym, a skupił się na tych dwóch rzeczach, które się tutaj bardzo mocno wybiły. Tak, raczej mocno po prostu je widać, czyli AI i Platform Engineering.

Szymon Warda: Tak, to od którego zaczynamy?

Łukasz Kałużny: Chyba od AI-a, bo jest pierwszy.

Szymon Warda: Może być, dobra argumentacja. Cóż tam wyłapałeś i jakie wnioski?

Łukasz Kałużny: Słuchaj, jeżeli popatrzymy, ale to jest… Inaczej, jeżeli popatrzymy całościowo, jak w naszych rozmowach, nie ma tutaj zachwytu.

Szymon Warda: Tak, jest kubeł zimnej wody, bym powiedział.

Łukasz Kałużny: Jest kubeł zimnej wody i tak patrzę jest, nie kłócę się z tym, jak tak popatrzę na całość, nie kłócę się z tym raportem, z tym co tutaj widzę. Jedna rzecz, jeżeli popatrzymy sobie, bo najciekawszą rzeczą z tego wszystkiego jest Individual Adaption of AI. Jeżeli popatrzymy sobie na kolejność wykorzystania po respondentach, to najwięcej jest na temat pisania kodu, potem jest sumaryzacja informacji, wyjaśnialność, optymalizacja, dokumentowanie, pisanie testów, debugowanie, analiza.

Szymon Warda: Wiesz co, bo Ty powiedziałeś, że zgodziłbyś się z tym, co napisali. Też się zgadzam. Ja mam lekki problem z pytaniem, które zadali. Bo pytanie brzmiało, że: czy w swojej pracy polegasz na AI? I 75% respondentów powiedziało, że tak, polega w pewien sposób. I to jest bardzo szerokie pytanie, bym powiedział. No bo w to możesz wpakować niemalże wszystko i to też trochę widać po tym tak naprawdę, kto dalej, jakie będą grupy wykorzystywały. Więc ogólnie tak, zgodzę się, raport jest dobry, jest nieprzehype’owany. Pytanie jest trochę za szerokie, ja bym trochę tu szczegółów chętnie zobaczył.

Łukasz Kałużny: Wiesz co, tak, pytanie jest za szerokie. Ale wiesz, jeżeli zobaczymy, bo ja patrzę sobie tą kolejność i najsmutniejszą rzeczą jest to, że pisanie kodu jest na pierwszym miejscu, takiego czystego. Inaczej, tak jak sumaryzacja informacji zgodzimy się, że jest ok. Jeżeli popatrzymy sobie, zmartwiło mnie, że tak mało jest wykorzystywany do dokumentacji względem kodu, że wsparcia do dokumentacji, debugowania. I co ciekawe, najmniej spodziewałem się i myślałem, że w tym miejscu poleci to dalej, ale to jest może bardziej pytanie do menedżerów ich, że chcieliby, tak, jako code base migration. To zobaczysz, że to jest scenariusz, który jest pompowany wszędzie, że to jest przyszłość. Zresztą zobacz, rozmawialiśmy nawet i chwaliliśmy AWS-a za te pluginy do upgrade’ów Javy i tego podejścia.

Szymon Warda: Chwaliliśmy Slacka o migrację testów.

Łukasz Kałużny: Tak. Gdzie to są, to naprawdę pozwala przyśpieszyć robotę, taką bardzo, nie boimy się tego słowa użyć, chujową do wykonania.

Szymon Warda: Nie przeklinamy, słuchają tego też dzieci.

Łukasz Kałużny: Dobra.

Szymon Warda: To jak mówimy teraz, to teraz ja parę rzeczy, to co mnie… Bo faktycznie raport jest fajny, itd., ale to co… Metryki negatywne, bo one też są. Są dwie metryki, które są zaobserwowane głównie jako efekt uboczny posiadania AI i zauważyły spadek wydajności o 1,5% i obniżenie stabilności o 7,2%. I dla mnie, szczególnie tę drugą wartość, gdzieś w tym raporcie namierzyłem takie zdanie, że ktoś się wypowiadał, że adopcja AI jest jak wczesne dni Stack Overflow. Kiedy wchodzisz na stronę, myślisz, że tam są sami eksperci, kopiujesz kod i to ci wszystko wybucha w twarz.

Łukasz Kałużny: Ale wiesz co i to jest…

Szymon Warda: Idealne.

Łukasz Kałużny: Słuchaj, to jest trust in quality of AI generated code. Inaczej, pokażę Ci, szkoda, że nie będę już share’ował moją dyskusję z Claude, jak sobie pomagam wygenerować pewien frontend. I kończyło się irytacją: ty debilu, wskazujesz mi pliki, które nie istnieją. Przecież ci wkleiłem. Przeanalizuj jeszcze raz.

Szymon Warda: Oto teraz przechodzimy do jeszcze jednej rzeczy, którą wygrzebałem i która świetnie pokazuje realne użycie. Kto najwięcej korzystał i kto zobaczył największy wzrost produktywności korzystając z AI? Ludzie od bezpieczeństwa, admini i full stack developerzy. Pierwsze dwie grupy to są grupy, które produkują bardzo małe snippety kodu realnie tak naprawdę, jakieś skrypty, itd.

Łukasz Kałużny: I są w stanie…

Szymon Warda: I do tego AI jest świetny, powiedzmy sobie szczerze.

Łukasz Kałużny: Inaczej, jesteś w stanie to rzutem oka zdebugować, czy jest okej czy nie okej. A jak potrzebujesz zrobić coś zaawansowanego, to trochę inaczej wygląda tego testowanie. I to są jednorazówki zazwyczaj.

Szymon Warda: Tak, jednorazówki i co więcej, to są z reguły małe kawałki łączące rzecz A z rzeczą B i w tym momencie kontekst AI wystarczy. Natomiast full stack developerzy czemu? Moja teoria ponownie, jest to, że tam po prostu generujemy kod, użycie jakiejś biblioteki, więc to są znowu małe kawałki kodu, które po prostu mówią jakiej funkcji, gdzie po prostu użyć.

Łukasz Kałużny: I łatwo zazwyczaj, jeżeli projekt jest już zbootstrapowany, łatwo wziąć wzorzec. I teraz kurde, mam nawet teraz z kopiowaniem generycznej formatki do CRUD’a nawet, mam taką formatkę: wygeneruj mi na podstawie tego API ten frontend korzystając z tych reguł.

Szymon Warda: Tam też mówisz w jakim frameworku z reguły pracuje, więc to jest dużo łatwiejsze dla AI, ten kontekst nie musi być taki duży. A np. ludzie, którzy najmniej korzystali z AI, to właśnie byli backend developerzy, gdzie już masz więcej kodu biznesowego, więcej kontekstu i tego już AI-owi w pełni nie wytłumaczysz. On nie będzie miał tej informacji.

Łukasz Kałużny: A co potrzebujesz, żeby zacząć? I tak copy-paste’ujesz z innej części projektu.

Szymon Warda: Często tak. Już teraz wiemy jak Łukasz developuje projekty.

Łukasz Kałużny: A Ty Szymon, zażartowałbym o tej kobyle, którą kiedyś zbudowaliście, żeby nie trzeba było copy-paste’ować.

Szymon Warda: Ale to teraz idziemy jeszcze z warsztaciku, co Warda wygrzebał z tego raportu? Dwie mega ciekawe rzeczy odnośnie AI-a. Największa adopcja AI-a jest wiesz u kogo?

Łukasz Kałużny: U kogo?

Szymon Warda: U ludzi pracujących nad AI-em. Nie robię sobie jaj, tak jest w raporcie. A najmniejsza jest u ludzi pracujących nad hardware’em, co ma całkowity sens. Druga ciekawostka. Czy wygrzebałeś jaki jest największy motywator do adopcji AI-a?

Łukasz Kałużny: Nie.

Szymon Warda: Fakt, że konkurencja to robi. Nie robię sobie jaj, jest to w raporcie.

Łukasz Kałużny: Raczej… Inaczej, wiesz co, tylko z drugiej ten…

Szymon Warda: To jest prawdziwe.

Łukasz Kałużny: Raczej wiesz co, tak, powiedziałbym jest to prawdziwe. Ale to jest tak samo jak z chmurą i podejściem biznesowym i tyle. I tak by to wyglądało.

Szymon Warda: Dobra, jeszcze mam parę rzeczy wygrzebanych. Pytanie, czy coś jeszcze masz do tej sekcji?

Łukasz Kałużny: Nie, ja tak nie patrzyłem aż detalicznie, bardziej patrzyłem na te ogólne wnioski i przesłanie. Ty widzę, że szczegółowo się tym razem…

Szymon Warda: Tak, ja tam zagrzebałem się. To mam jeszcze parę rzeczy. 1/3 developerów uważa, że AI będzie problemem w ciągu najbliższej dekady. Nie jest określone jakim będzie problemem. Dla mnie, wydaje mi się, że problem będzie wcześniejszy, w ciągu powiedzmy 3 lat, odnośnie tego braku juniorów. To niestety będzie element konieczny.

Łukasz Kałużny: Wiesz co, braku juniorów… Inaczej, przy szerszej adopcji bez… Wiesz co, problemem są cały czas te okna kontekstowe i tego, że to jest po prostu losowanie kolejnych słów, jak sobie popatrzymy zupełnie i że z jednej strony jest teraz zachłyśnięcie, z drugiej strony ludzie… Będzie trochę wprowadzał… Moim zdaniem problem jaki będzie, to będzie wprowadzał nadmierne ogłupienie, czyli że ludzie nie będą wiedzieli, co tak naprawdę zostało wygenerowane.

Szymon Warda: Wracamy do tego, właśnie to widzimy już obecnie, że zmniejsza się stabilność o 7,2%, to jest dużo, 7,2. To jest naprawdę taka już… Dobra inna rzecz wygrzebana, że faktycznie, jeżeli chodzi o właśnie developer experience cały, że AI zwiększa stan flow. Czemu? Bo jeśli się zatniemy, to mamy się kogoś łatwo zapytać i łatwo jest po prostu trzymać się dalej, że to robimy. Mamy mniej przeszkadzajek i też jednocześnie ludzie się rzadziej pytają. Więc całkiem fajnie opisany kawałek.

Łukasz Kałużny: Wiesz co, ja do tego, tak jest dobre, do tego flow bym dodał, że to jest to co mieliśmy przy Thoughtworksie, niby AI pair programming zrób na holda, z drugiej strony to jest gumowa kaczka, która zawsze jest na miejscu.

Szymon Warda: Tak, do prostej generacji.

Łukasz Kałużny: Do prostej…

Szymon Warda: Albo zapytania się.

Łukasz Kałużny: Tak, albo na zasadzie: weź poszukaj mi buga w tym kodzie. Albo: jak powinienem to rozbić? Może zmodularyzowa, kontynuować? Możesz te głupie, proste pytania, na których w pewnym momencie poległeś i się zastanawiasz, zacząć z kimś uprawiać ping ponga, pytać i patrzeć się czy to w ogóle ma sens.

Szymon Warda: Dobrze, to co, lecimy do Platform Engineering?

Łukasz Kałużny: Tak, chyba tak.

Szymon Warda: To dajesz. Co wyszukałeś?

Łukasz Kałużny: Znaczy pierwsze w ogóle mnie nie zaskoczyło, że się pojawiło, o tak. Wiedziałem… Inaczej, nie patrząc nawet na pytania jakie były, wiedziałem, że to się pojawi. I teraz tak, jak popatrzymy sobie na całość, że początkowe, co jest ciekawe, taki cytat: Platform Engineering had unexpected down site. We also found that for output and change stability decrease.

Szymon Warda: I super, że to ruszasz właśnie, bo jest stabilność i wydajność. I teraz najfajniejsze jest, że spodziewalibyśmy się, że platforma obniży stabilność albo wydajność w ciągu czasu developmentu. Ale tak nie jest. Ten spadek wydajności następuje od 2 do… w obszarze między 2 a 5 lat po wdrożeniu platformy, czyli w momencie, jak to już jest stabilne raczej. I to jest ciekawy fakt tak naprawdę, którego oni do końca nie tłumaczą w raporcie. Ja mam jedną teorię odnośnie tego, że platformy są czasami budowane na zasadzie generalnie, że kto ma dłuższe grabie, czyli developerzy przerzucają do zespołu platformowego i platformowe wrzuca. Oczywiście oznacza, że to nie jest platforma, ale powiedzmy sobie, że tak to często wygląda. I jeżeli firma zajmuje się budowaniem dłuższych grabi, to niestety będzie, w tym momencie tracimy całkowicie taki ownership.

Łukasz Kałużny: Ale wiesz co, to jest znowu temat, o którym mówimy, że przy całym IT i porządkowaniu procesów są dwie rzeczy. Jedno to taki produkt management, który prawdopodobnie to jest rzecz, która leży w takich przypadkach, że product management idzie. Druga rzecz the commissioning rzeczy, które nie są używane albo są przestarzałe. Bo zobacz, że platforma, to też mieliśmy dyskusję w odcinku o platformach, że problemem jest cały cykl życia i wycofywanie potem feature’ów.

Szymon Warda: Wygaszanie, itd. Często platforma jest zbudowana totalnie przyrostowo. Fajnie jest w tym raporcie, pokazują, nacisk kładą bardzo mocny na to, jak platformę budować, że ona musi być wokoło użytkownika, w niezależności developera i produktu. I to jest dla mnie, szczególnie ten drugi element jest bardzo ważny, bo platforma ma być taką formą API, czymś, co developer albo ktoś bierze i wkłada tam swój system, a nie na zasadzie, że developer developuje system, zespół i mówi: to teraz platformę macie i używajcie. Bo to nie jest platforma w tym momencie, to dalej ma być coś uproszczone i jak mogą ludzie hostować i zespoły, itd. Więc ta platforma często wydaje mi się nie rozumiana tak naprawdę.

Łukasz Kałużny: Jest tak, wiesz co, tylko ja wrócę do tego, że zobacz, że platforma to jest kolejna, bo jak popatrzymy sobie na Platform Engineering, to co mi się układa w myśleniu, to jest kolejna ewolucja na temat, nie mówię, że rewolucja, tylko ewolucja i przepakowywanie sreberka w to, co znamy od dawna. Zobacz, że CI/CD zostało zdefiniowane bardzo dawno temu. Standaryzacja tego wiesz, że leży. To co Ty masz w swojej prezentacji, którą gdzieś pokazywałeś na różnych konferencjach na temat Platform Engineeringu i z czego to tak naprawdę się składa pod spodem. To zobacz, że te rzeczy procesowe, ludzie od razu skupiają się na technologii, a proces, który jest wokół platformy, leży.

Szymon Warda: Nazywajmy rzeczy po imieniu, ludzie skupiają się na Kubernetesie z tego wszystkiego.

Łukasz Kałużny: Tak, bo Kubernetes to platforma.

Szymon Warda: Tak, dokładnie tak. To była ironia. Niektórzy mogli nie załapać generalnie.

Łukasz Kałużny: Tak, nie jest… Jest komponentem do budowy platformy, którym można dużo zrobić. Można dużo zrobić, jeszcze więcej się skrzywdzić.

Szymon Warda: Tak.

Łukasz Kałużny: Podchodząc do tego podejścia. Ale wracając do mojej myśli, jak popatrzysz na to, to z jednej strony te wszystkie rzeczy były. Developer experience też przez lata był, o tym się mówiło. Zobacz, że przy CI-u, że… Inaczej, teraz będę dinozaurem, powiem zanurkując do extreme programmingu i tego natychmiastowego feedbacku CI-a i innych takich rzeczy, które gdzieś w tamtym już momencie się pokazywały. To wszystko było.

Szymon Warda: Wiesz co było, ale wydaje mi się, że jednak dostęp do tego, żeby stworzyć rzeczy, stworzyć infrastrukturę, położyć ją szybko, mieć łatwiejsze API, itd., tego nie było. Tak, CI/CD był, ale to dalej musiałeś… Znaczy też był czas takich ludzi, którzy po prostu umieli od administracji sieci aż po programowanie, SQL-a, itd., umieli zrobić wszystko. I tam, w takich właśnie warunkach ludzie błyszczeli. Obecnie mamy dość mocną granulację tak naprawdę. No sorry, ale masa developerów nie ma pojęcia na przykład jak skompilować iOS-a albo jakikolwiek serwer HTTP albo cokolwiek innego zrobić. Więc tak, CI/CD był, ale teraz dajemy tą możliwość żeby tworzyć na żądanie.

Łukasz Kałużny: Spróbować przykryć. Dobra, patrząc się na inne ciekawe rzeczy. Nie wiem czy wyłapałeś J-Curve, czyli właśnie tą, bardzo ładnie określone, że produktywność początkowa wzrasta, spada w trakcie adopcji i ostatecznie się stabilizuje na wyższym poziomie.

Szymon Warda: Tak, tam powyżej 5 lat tak naprawdę.

Łukasz Kałużny: I to jest ciekawa rzecz. Patrząc się zobacz, że tak, produktywność właśnie wzrasta, ale za to przepustowość i stabilność… To jest w ogóle ciekawa rzecz, jak je połączysz, te dwa cytaty ze sobą na temat tego for output i stabilności zmiany względem tego produktu, nakładając na to produktywność.

Szymon Warda: To w ogóle fajnie wygląda. Wydaje mi się, że dalej kręcimy się wokół tego tematu, że platforma była zbudowana źle, że to jest dalej sposób na przerzucanie grabiami odpowiedzialności tak naprawdę. I nie robimy tego shift left, bo platforma właśnie ma umożliwić zrobienie tego shift left, a to się nie dzieje do końca tak naprawdę z tego powodu, że jest zbudowana albo z tego powodu, że organizacja nie chce, albo że ona jest po prostu…

Łukasz Kałużny: Albo że silosy, robimy Platform Engineering, silosy zostały.

Szymon Warda: Tak. Jeszcze bym doszedł do tego, jakie wartości platforma buduje, bo jest wzrost produktywności. Ale drugie najważniejsze to jest przede wszystkim wzrost bezpieczeństwa i compliance, czyli zgodności z regulacjami. To jest w ogóle bardzo, bardzo fajne, bo wydaje mi się, że to będzie coraz większy i częstszy temat, szczególnie też w rynkach, w których my się operujemy i dla których klientów pracujemy. I pewnie też kto nas słucha tak naprawdę, nie oszukujmy się, regulacje będą i będzie ich coraz więcej, tak że to bardzo mocno ułatwi. Co masz jeszcze? Bo jeszcze jeden fajny wykres znalazłem.

Łukasz Kałużny: No to dawaj, bo miałem właśnie Ciebie o to samo zapytać, co z ciekawych rzeczy.

Szymon Warda: Jest jeden mega ciekawy wykres. Jest estimated productivity factor, czyli podzielili respondentów na dwie grupy. Ci, którzy mają platformę i którzy nie mają platformy. I teraz co wyszło? Że rozrzut w estymowanej wydajności productivity, produktywności, dla firm, które nie mają platformy, on może mieć takie same wartości jak dla zespołów platformowych, ale rozrzut jest bardzo duży, od mniej więcej 6,5 do 8. Natomiast firmy, które mają platformę, ten rozrzut jest mniej więcej od powiedzmy, 7,5 do 8. Czyli jest dużo większa przewidywalność tego, jak firmy się będą zachowywały. I według mnie to jest element, który jest w tym raporcie, który jest za mało doceniony i za mało na wierzchu, bo platforma właśnie ok. Są pewnie firmy i na pewno jest sporo takich firm, które spokojnie sobie bez platformy poradzą, ale mając platformę mamy większą przewidywalność. Czyli to jest to, o co w biznesie chodzi.

Łukasz Kałużny: Ale to jest właśnie proces. Inaczej, ja bym się cofnął. Standaryzacja Ci daje przewidywalność.

Szymon Warda: Tak, bo platforma wymusza standaryzację. Musimy pewne rzeczy zrobić, żeby mieć platformę.

Łukasz Kałużny: Inaczej, platforma równa się standaryzacja, inaczej się nie da. I to jest też dyskusja, którą mieliśmy chyba z rok temu albo z dwa lata temu na jednej prezentacji. Nie wiem, czy pamiętasz, ale właśnie standaryzacja versus innowacja.

Szymon Warda: Tak, dokładnie, że to jest takie balansowanie, że niestety jak coś ustandaryzujemy, to potem sorry, ale ciężej jest to zmienić, nie? Czyli musimy balansować, bo standaryzacja zabija trochę innowacyjność w organizacji, ale też powoduje to, że nagle nie mamy 20 bibliotek do logowania i jest nam po prostu łatwiej pewne rzeczy ogarnąć na poziomie organizacji i potem ewentualnie wprowadzać zmiany globalne, bo będziemy musieli je po prostu robić.

Łukasz Kałużny: Dobra. Co sądzisz o Leading Transformation?

Szymon Warda: Doprecyzuj generalnie, bo tak trochę rzuciłeś…

Łukasz Kałużny: Nie, nie, nie, właśnie o tym rozdziale, bo jest też ta leading transformation, rozdział w raporcie.

Szymon Warda: Przekartkowałem go tak naprawdę, przekartkowałem i nic tam ciekawego nie znalazłem. Sorry.

Łukasz Kałużny: Znaczy to mam wrażenie, żeby upchnąć jeszcze tematy menedżerskie tutaj.

Szymon Warda: To powiem, że ja go przeleciałem, przekartkowałem i tak patrzę ok, tu nie ma nic ciekawego, tak że śmiało otwieraj swoje wnioski.

Łukasz Kałużny: Ja nie mam tutaj wniosków, bo zrobiłem dokładnie to samo. Po prostu na zasadzie, bo wiesz… Inaczej, kurde, jest na przykład tekst “Become a data informed organization”. Albo “Be all in on cloud or stay in the data center”. Takie nagłówki, jak sobie popatrzymy, mocno clickbaitowe, to są najbardziej clickbaitowe nagłówki w tym raporcie, w tym miejscu.

Szymon Warda: Też dla kontekstu, ten cały rozdział zaczyna się od strony 69, gdzie jest główna strona i on się kończy na stronie…

Łukasz Kałużny: 76.

Szymon Warda: Dokładnie, więc tutaj treści jest bardzo, bardzo mało. To właśnie go kartkuję. Tak, tutaj nie ma prawie nic. A potem wchodzimy w rozdział o właśnie, o historii Dory, itd., podsumowanie, bo to już dekada jest tego raportu. I co? Ten raport się kończy tak naprawdę.

Łukasz Kałużny: Raczej powiem, nadal wartościową rzeczą jest popatrzenie sobie jako na snapshot rynku. To jest jedna rzecz. I najważniejsze z tego są te pierwotne kilka pierwszych stron i te Dora Metrics.

Szymon Warda: Znaczy, ja bym powiedział, że dalej to takie trzeźwe spojrzenie bardzo mocno na AI i na Platform Engineering. To było dobre, to było naprawdę sensowne, pod wieloma względami było okej i też nawet takie elementy, które obniżają hype, nie bali się tego dodać. Więc…

Łukasz Kałużny: To jest ciekawe. Może Google nie radzi sobie w Platform Engineeringu i AI od strony marketingowej i może dlatego…

Szymon Warda: Tego właśnie nie powiedzieliśmy, bo teraz cały DevOps jest z ramienia Google’a robione tak naprawdę, więc to też może mieć jakiś, powiedzmy sobie, wpływ.

Łukasz Kałużny: Tak. I druga ciekawa rzecz, jeszcze jedna taka myśl na koniec. Zobacz, że było mało tutaj rzeczy związanych z typową statystyką i pokazanie rozkładu w tym raporcie.

Szymon Warda: To jest dobra uwaga, bo faktycznie zeszły raport z poprzedniego roku miał bardzo dużo statystyk, bardzo dużo liczb i można było ciekawe też wnioski znaleźć i samemu sobie pogmerać, że tak powiem, w tym, co tam się w ogóle dzieje. No okej, to ominąłem.

Łukasz Kałużny: To jest taka rzecz, którą wiesz, zobaczyłem, rzuciła mi się. Przepraszam Was, ale nie chciałem też już zagłębiać się, czy gdzieś są dane surowe, tylko surowych już mi się nie chciało na przykład przeglądać, szukać, analizować ich. A w poprzednim raporcie one były na tacy i też można było zobaczyć rozstrzał. Z rzeczy, które były dobrymi w tych danych, to był rozrzut po krajach i po wielkościach firm.

Szymon Warda: Są takie ogólne na samym dole tego raportu, ale to nie jest ten poziom szczegółowości, który był wcześniej, mimo że chwalą się, że jest 8000 respondentów, itd. Więc dalej grupę mają niezłą, no ale tak, trochę brakuje.

Łukasz Kałużny: Na pierwszy rzut oka, 120 stron, ale nie wiesz, nie znasz dokładnie respondentów.

Szymon Warda: Łukasz, od strony 85, bo właśnie przeglądam, są acknowledgments, czyli podziękowania, kto brał udział, itd. Więc ten raport ma trochę mniej tych stron mimo wszystko.

Łukasz Kałużny: Tak. A mówisz o tym. Tak, jest recommended readings model, jest tam… A, przepraszam, jest demografia, chyba za bardzo przeskipowałem, więc… Moment… Zobaczmy. A, jest race and ethnicity jest tutaj. Ale czy po country? No dobra, jest, ale bez procentów, jest po country. To dlatego ja to chyba olałem, bo brakowało mi tego po procentach. A rozkład, kto odpowiadał, jest tutaj standardowy jak w zeszłym roku, więc nie było w tym. Disability i gender się pojawiło, więc to mnie zaskoczyło w tych na przykład.

Szymon Warda: Tak. Dobrze. Chyba co? Kończymy tak naprawdę?

Łukasz Kałużny: Kończymy.

Szymon Warda: Dobra, dzięki.

Łukasz Kałużny: Na razie. Trzymajcie się.