Mentionsy

Piotrek, zauważyłeś, że dużo rozmawiamy na temat developmentu, a z nas właściwie tacy deweloperzy jak z kozień dupy trąby za przeproszeniem, to znaczy obaj jesteśmy na takim etapie naszego życia, że więcej niż w kodzie to siedzimy w prezentacjach, w schematach, w raportach, w dashboardach, w mailach, w Wordach, Excelach i tego typu rzeczy.

A czy tacy ludzie jak my, którzy mogą się w końcu pochwalić, że jak mają wpisane w CV, że mają obsługę pakietu Office, to faktycznie jakoś to wykorzystują.

Czy my się powinniśmy tym martwić według Ciebie?

Pożyteczne tym, co my robimy na co dzień?

Bo tam jak gdyby dość dużo dyskutujemy, dyskutowaliśmy z Wojtkiem na tego typu tematy, ale na poważne, jak gdyby już przestając o autopromocję, na poważne, wiesz co, to wydaje mi się, że to trochę następuje takie spłycenie zespołu, bo popatrz, ostatnie, odkąd pamiętam, ile lat, na konferencjach IT mówi się, ej, deweloperzy, bądźcie bliżej klienta, porozmawiajcie z klientem, nie?

A teraz, jak patrzę nawet na własne doświadczenie, bo to jest jedna strona medalu, a pamiętam ileś takich doświadczeń z własnego życia, że na przykład koleżankę, która była naszym, powiedzielibyśmy chyba najbardziej, PO-sem, co kolegę PO-sa też kiedyś uczyłem,

Wystawić własną aplikację, że oni zmieniali teksty w aplikacji i im się zapalała taka magia, że to w ogóle działa, że to zbliżenie teraz może po prostu następuje, że dzięki tym narzędziom AI, dużo gadamy wewnętrznie czasami w podcaście o Google Stitchu, bo nam się najłatwiej robi interfejs, jak możesz zrobić ten mockup szybki w 15 minut,

I pogadać sobie, jak to może wyglądać, zobaczyć to, poczuć, to ta bariera trochę zanika, nie?

Nie no, to jest wiesz, te statystyki, które teraz są bardzo często przytaczane, że tworzenie kodu tak naprawdę to jest na poziomie już myślę seniora, to jest jakieś 15% czasu, który spędzamy nad tym.

Wiadomo, różne są zespoły.

Ale bardzo często, jeżeli mówimy o zespołach, które czasami nie mają tego Product Ownera, czasami gdzieś jest to jakaś tam rola, tak samo jak, wiesz, Scrum Masterzy, Product Ownerzy,

Często to jest gdzieś porozdzielane po rolach różnych ludzi.

Nie jest to pozycja jako taka, tylko jest to część pracy też jakiejś osoby.

Mam wrażenie, że w wielu zespołach jest tak, że to pisanie kodu to nie jest wcale największa część naszej pracy.

Natomiast znam też zespoły, w których deweloperzy faktycznie siedzą.

I tutaj też zacząłem się zastanawiać, bo rozmawialiśmy z Tomkiem Ducinem, który mówił o tym, nazwijmy to, spłyceniu gdzieś tam tych zespołów.

To też nie wydaje mi się, żeby nagle teraz wszyscy na hura musieli pójść do klienta, bo umówmy się, jeżeli klient zobaczy, że taki deweloper, który do tej pory siedział w kodzie, zacznie z nim gadać po technicznemu, to on powie, nie, weźcie mi, przyślijcie kogoś, kto mówi moim językiem.

Że nagle będzie się dawało takie, że rewolucja, która wydaje mi się, że nadal jest po prostu rewolucją, to są klikalne mockupy w firmie.

Ale łatwiej się rozmawia z ludźmi, jak się pokaże, tu będzie search bar, tu będziesz klikał button, tu się coś zamieli i będzie dobrze.

Pomimo tego, że główny kod, który tam jest do napisania, to jest po prostu mega skomplikowany algorytm dobrego wyszukiwania.

I ta rewolucja w firmie nagle dała w ogóle taki wow, w sensie po prostu taki efekt ładny.

Ja też mam takich ludzi w firmie, że nagle ktoś zrobił coś, co jest ci w stanie przynieść i powiedzieć, że to mniej więcej ma tak wyglądać, tak się utrzymasz.

Ale pomimo to, że robiłem, nie?

Tylko, że nagle się okaże, że to spłaszczanie nie jest tylko właśnie w zespołach, tylko że jest w całości.

Bo nagle będą mogli łatwo wejść na poziom danych i spróbować z tych danych coś wyciągnąć.

To będzie oznaczało nie to, że oni zrobili bzdurę, bo tak im wybajkodowało, to też jest opcja, ale może wyjść tak, że my po prostu nie raportujemy rzeczy, więc jest bzdura.

PO-sa, że on przyjdzie z taką bardziej dokładną specyfikacją, nie?

Biznes-analityka, który będzie w stanie zanalizować ilość tych dokumentów, które jest w firmie, wrzucić trochę z analizy kodu i powiedzieć mniej więcej, gdzie czego brakuje, nie?

I tak naprawdę tutaj mamy bardzo duże pole do popisu.

Jeżeli ludzie typu PO, typu PM, typu Scrum Masterzy będą chcieli też wykorzystywać jak najbardziej te narzędzia,

Z których korzystamy my deweloperzy, to znaczy jeżeli zaczną korzystać z narzędzi nie tylko z czata GPT w przeglądarce i do zadawania pytań, ale zbudują sobie jakiś workflow, zbudują sobie jakiś workflow pracy, bo w tym momencie już na dzisiaj można spokojnie

Nie zapomnijcie zasubskrybować oraz zafollowować mnie na Facebooku!

I w końcu też skończą się tematy typu, czy możesz mi wygenerować taki raport.

One mają jakieś tam ograniczenia, bo czasami wymyślimy sobie nawet sami dla swoich potrzeb coś, czego po prostu twórcy nie przemyśleli, ale...

Zarówno Jira, jak i Devops mają niesamowite API, z którym jeżeli się połączymy, a Devops nie wiem jak Jira, ale Devops ma jeszcze swój serwer MCP, jeżeli się podłączymy pod to, no to właściwie może Jira prawdopodobnie też, tak się spodziewałem.

Oczywiście, będzie do tego potrzebne kilka rund, kilka iteracji, żeby to dopracować tak, żeby to nie było zmyślone, bo czasami może być zmyślone, bo już nieraz też próbowałem i on czasami jak czegoś nie wie, to faktycznie nadal zmyśla.

Ale wydaje mi się, że jeżeli na przykład pójdziemy bardziej w spec-driven development, o którym się bardzo dużo mówi, no to wtedy te osoby właśnie typu product owner będzie musiał też być bliżej w ogóle codebase'u, czyli naszych repozytoriów kodu, no bo tam będzie zbudowany cały workflow.

I teraz jeżeli będziemy mieli agentów, którzy będą nam pomagali w ogarnianiu tego projektu i od strony implementacji, i od strony specyfikacji, i od strony testowania, to cały nasz zespół, i QA, i deweloperzy, i product ownerzy, i team leaderzy po prostu będą musieli być bliżej kodu.

Oczywiście nie będą musieli czytać tego kodu, tylko raczej pliki typu markdown, albo jakieś jasony, albo coś w tym stylu, ale będą mogli bardziej kontrybuować, że tak powiem, do tego projektu w pewien sposób.

To właśnie powiedziałeś to słusznie, że właśnie nie będą bliżej kodu, one będą bliżej specyfikacji.

Że popatrz, że to nagle ta specyfikacja będzie bardzo żyła, bo z jednej strony kod będzie, znaczy pisanie kodu będzie wpływało na tą dokumentację, ile będziemy ją utrzymywać, bo w tej chwili do dzisiaj, przynajmniej przez całą moją karierę, dokumentacja to się na ogół robiło na ostatni moment, nie chcę użyć brzydkiego słowa tutaj, bo ona dużo nikomu nie wnosiła i nikt nie wiedział po co.

Oczywiście dla potomnych, ale jak gdyby nikt nie miał na to czasu, a teraz to się trochę zmienia, bo jak gdyby z tej dokumentacji łatwo jest po prostu popchnąć rzeczy dalej, więc jak gdyby strona, nazwijmy to deweloperska, będzie jej zależało na tym, żeby jak gdyby dodawać te rzeczy, zresztą ma łatwość dodawania, to trzeba sobie powiedzieć.

To samo w kwestii testerskiej, że jak gdyby będziemy żyli właśnie na tej dokumentacji, to dokumentacja po prostu będzie funkcjonowała.

Tylko trzeba sobie powiedzieć, że dzisiaj jeszcze tam nie jesteśmy.

W sensie, że ten kontekst po prostu jest taki, że po prostu ciężko to ogarnąć, że to jeszcze tam nie do końca jesteśmy, jeszcze nie do końca, ale to się dynamicznie rozwija.

Bo to, że sobie Scrum Masterzy czy analitycy wygenerują jakieś dashboardy, czy tymi liderzy, bo będzie im to bardziej potrzebne, to po prostu jedyne co zasypuje to dziurę tego, że nigdy nie było dewelopera, bo nie chcieliśmy go odciągać od projektu, żeby on to dewelopował, żeby się dowiedzieć czegoś tam.

Ale że tu w ogóle jest taka olbrzymia, olbrzymia po prostu możliwość przyspieszenia, tak na moim ekranie olbrzymia, przyspieszenia tak naprawdę tej współpracy, uproszczenia tej współpracy, której wcześniej nie było.

Coś jeszcze chciałem powiedzieć na ten temat, a właśnie, że analitycy.

Nie wiem, czy miałeś takie do tej pory doświadczenia, ale ja pracowałem z kilkoma, może kilkunastoma analitykami i tylko dosłownie z dwoma albo z trzema do tej pory pracowało mi się dobrze.

Bo bardzo często miałem problem z tym, że jeżeli analityk poszedł do klienta, dowiedział się co mamy zrobić, to nie potrafił dogadać się bardzo często z zespołem deweloperskim, żeby przedstawić to w taki sposób, żeby przekazać intencje biznesu właśnie tym deweloperom.

I miałem problem z tym, że byli analitycy, tacy typowi skrybowie, którzy po prostu chodzili na spotkania i robili transkrypcje z tego, co biznes mówił, zamiast ich tam challenge'ować.

Byli tacy, którzy przychodzili potem na spotkania z deweloperami i uprawiali cały storytelling i nam opowiadali historię i siedzieliśmy na trzygodzinnym spotkaniu, które mogłoby się zamknąć w 15 minutach.

I teraz mam wrażenie, że jeżeli oni zaczną pracować z LLM-ami i nawet jeżeli sobie zaczną przepisywać to, co biznes powiedział, albo opowiedzą temu LLM-owi całą historię swojego życia po to, żeby stworzyć nowego PBI czy nowe user story, no to niech tam będzie, to tam się zmieści.

A potem LLM to przemieli tak, żeby deweloperzy byli zadowoleni.

Popatrz, wybrałeś sobie jedną z naprawdę trudniejszych ról w tej branży.

Bo to po prostu było ten.

A jeszcze co do dashboardów, to już tak totalnie na zakończenie, tak sobie pomyślałem a propos tego, że tych dashboardów nigdy się nie tworzyło, bo deweloperzy nigdy nie mieli czasu, albo deweloperzy bardzo specjalnie nie chcieli mieć czasu, bo na przykład wiesz, jak przychodzi taki team leader i mówi zrób mi taki dashboard, żebym zobaczył jaka jest produktywność każdego dewelopera.

Stoły point, tak.

Story pointa.

Także drogi PO-sie, PM-ie, Scrum Masterze, analityku, apel do Ciebie.

I codziennie też staramy się ulepszać naszą pracę właśnie za pomocą LLM-ów sztucznej inteligencji, narzędzi typu Copilot, OpenClo, nie, OpenClo nie, już nie, nie, przepraszam, tu się zapędziłem, ale wielu innych.

Także zachęcamy Cię do tego, żebyś słuchała naszych podcastów i cóż, możemy powiedzieć do zobaczenia za tydzień.