To jest 285. odcinek podcastu Porozmawiajmy o IT, w którym z moim gościem rozmawiamy o tym, dlaczego w IT tworzymy koło na nowo, czyli o sztuce prostoty w projektach technologicznych.Wszystko, co potrzebujesz, notatka, linki i transkrypcja czekają na Ciebie na porozmawiajmyoit.pl/285.

Myślisz o zmianie pracy lub przebranżowieniu się do IT? Zajrzyj na SolidJobs, gdzie znajdziesz przejrzyste oferty z informacją co do zarobków, technologii i projektów.

Nazywam się Krzysztof Kempiński, prowadzę ten podcast oraz jestem autorem książki Marka osobista w branży IT. Mam misję polegającą na poszerzaniu horyzontów ludzi z branży IT. Tak się składa, że możesz bardzo mi pomóc w jej realizacji poprzez wystawienie oceny w aplikacji, w której tego słuchasz lub podzielenie się tym odcinkiem w social mediach. A teraz zapraszam Cię już do odcinka.

Odpalamy!

 

Cześć!

Mój dzisiejszy gość to doświadczony manager branży technologicznej, który łączy świat biznesu z nowoczesnymi rozwiązaniami cyfrowymi. CEO w Eversis, gdzie kieruje zespołami programistów, inżynierów DevOps oraz analityków UX. Specjalizuje się w budowaniu mostów między technologią a strategią biznesową, wspierając średnie i duże organizacje w wykorzystaniu AI, automatyzacji i nowoczesnych technologii chmurowych. Moim i Waszym gościem jest Bartosz Szkudlarek. 

Cześć, Bartku, bardzo miło mi gościć Cię w podcaście. 

 

Cześć, Krzysztof, cała przyjemność po mojej stronie. 

 

Dzisiaj będziemy mówić o bardzo trudnym temacie, mianowicie jak osiągnąć prostotę w projektach technologicznych. Bo jako branża, a jako też indywidualni kontrybutorzy mamy taką tendencję do komplikowania rzeczy i często wymyślania koła na nowo. 

Zanim jednak przejdziemy do tego właściwego tematu, to chciałbym Cię, Bartek, zapytać, czy słuchasz podcastów. Jeśli tak, to może jakieś ciekawe audycje będziesz w stanie zarekomendować. 

 

Oczywiście w pierwszej pewności zarekomenduję Twoją audycję, bo jak najbardziej jej słucham. Staram się tak naprawdę słuchać głównie podcastów ze Stanów Zjednoczonych, bo tam jest chyba ta dynamika tego, co się tam dzieje i tego, o czym tam się mówi, chyba jest na tyle fajna, że warto być z tym na bieżąco. U nas w Polsce, w ogóle w Europie, ten poziom tematów, z którymi się zmagamy, no niestety ze względu na skalę jest niższy, więc słucham amerykańskich podcastów. Najbardziej chyba Tima Ferrissa, bo to jest taki bardziej biznesowy podcast, więc lubię czerpać gdzieś tam z biznesu, ale słucham też technologicznych podcastów. 

 

Mam wrażenie, że myślimy o sobie jako branży, jako takiej bardzo innowacyjnej, jako branży, w której cały czas tworzy się coś nowego, wymyśla się coś nowego, ale gdyby się tak trochę pod maskę temu wszystkiemu zajrzeć, to okazuje się, że mnóstwo z tych rzeczy, które wydają się efektem ostatnich kilku lat, to de facto wymyślono to już znacznie wcześniej. Programowanie funkcyjne, którym się niedawno gdzieś tam zachłysnęliśmy, sztuczna inteligencja, to są wszystko dziesiątki lat do tyłu już badań i rozwijania tych technologii i tych przykładów pewnie by tutaj można było mnożyć. 

Zatem, no właśnie, często wymyślamy coś, co zostało już kiedyś opracowane i rozwijane przez wiele lat i dodajemy taki trochę lukier, trochę komplikujemy to niepotrzebnie. Czy też masz takie obserwacje, też to tak widzisz? 

 

Może z perspektywy efektu takiego końcowego można mieć takie wrażenie, ale nie do końca się z Tobą zgodzę, że to jest branie rzeczy, które gdzieś tam funkcjonowały już z wielu lat i dopiero teraz odświeżanie ich itd. Bo na pewno na technologię trzeba spojrzeć z perspektywy, po pierwsze, kontekstu. 

Wspomniałeś tutaj o programowaniu funkcyjnym, wspomniałeś o sztucznej inteligencji. Absolutnie, rzeczywiście sztuczna inteligencja i algorytmy, deep learning, machine learning to są zagadnienia, które gdzieś tam początki miały miejsce w latach 80, ale wiesz, z drugiej strony wtedy moc obliczeniowa tego, co można było przetworzyć, zbiory danych, które wtedy funkcjonowały, nie pozwalały na wygenerowanie takiej sztucznej inteligencji, jaka ona jest teraz. 

Jeśli chodzi o dodawanie nowych rzeczy, nie oszukujmy się, troszkę jest tak, że w informatyce to, co już miało powstać, już powstało. Wszystkie algorytmy, wszystkie rozwiązania. Tak naprawdę już trudno znaleźć miejsce dla nowego ERP-a, dla nowego CRM-a, bo to już od dawna funkcjonuje. 

Tutaj rynek SaaS-owy szczególnie chyba wyeksploatował wszystkie możliwe nisze, wszystkie możliwe potrzeby, które mogą zaistnieć. Na każdą potrzebę znajdzie się jakiś SaaS, więc rzeczywiście trudno jest jakby wymyślić coś na nowo, ponieważ większość rzeczy już jest. 

Natomiast z drugiej strony, z jakiegoś powodu niektóre rzeczy powstają od nowa, mimo że to czasami wydaje się, że nie ma sensu. I wiesz, i tutaj powodów moim zdaniem jest wiele. Jednym chyba z takich kluczowych jest po prostu gdzieś tam nadmiar informacji i nie wiem, może taka potrzeba tworzenia, bo to chyba z tego się bierze. 

 

Mówimy dzisiaj o tworzeniu tych systemów albo wymyślaniu rzeczy na nowo. Mówimy też o komplikowaniu, które się często z tym wiąże. O tych różnych powodach pewnie jeszcze sobie dzisiaj troszkę porozmawiamy. Myślę sobie, że często dzieje się to tak trochę przez przypadek, bo np. nie wiemy, że mamy dostępne już jakieś pomysły, algorytmy na rozwiązanie tego problemu. Często stoi za tym oczywiście też ego, często stoi potrzeba właśnie stworzenia sobie takiego pomnika, z którego byśmy byli dumni. 

Wiele tych różnych powodów jest. Ale chciałbym Cię zapytać o pewien taki szczególny powód, dla którego komplikujemy rzeczy, dla których wymyślamy rzeczy na nowo. Mianowicie takie trochę z premedytacją robienie tego, aby nie dzielić się z innymi tym, co już osiągnęliśmy, aby inni nie byli w stanie tego naszego poletka tutaj zabrać, może nas wygryźć z tej pozycji. 

 

Wydaje mi się, że to jest w ogóle taki najbardziej krzywdzący chyba stereotyp programisty albo DevOpsa, który tam, wiesz, te skrypty pisze po to, żeby nikt się do tego nie dobrał. Prawdę mówiąc, przez dwadzieścia parę lat swojej kariery spotkałem jednego programistę, który komplikował kod specjalnie. To na początku swojej kariery, ale on miał cel w tym, ponieważ nienawidził języka programowania, w którym wtedy tworzyliśmy aplikację. Naprawdę komplikował ten kod specjalnie. 

Poza tym nigdy nie spotkałem nikogo, kto robiłby to celowo po to, żeby zachować sobie jakąś swoją pozycję. 

To, co mówisz, czyli ten element ego, bierz pod uwagę, że pracujemy w branży, która jest kreatywna, w sensie takim, że my lubimy tworzyć, w sensie informatycy, programiści lubią tworzyć, więc nie ma nic przyjemniejszego niż proces tworzenia. I to jest jedna taka rzecz. To, co mówisz à propos ego, na pewno to, na pewno to ma duże znaczenie. 

Jakbym miał powiedzieć tak naprawdę, jaki jest jeden element, który tak naprawdę  jest taką największą barierą, dlaczego rzeczywiście te systemy powstają, zwielokrotniają istniejące rzeczy, bądź replikują to, co już jest, to wydaje mi się, że to, czego brakuje nam, branży IT i nad tym musimy bardzo pracować, to jest taki pragmatyzm biznesowy. 

I dlatego tutaj wrócę do tych moich podcastów amerykańskich. W amerykańskim świecie takim startupowym liczy się rezultat. Trochę nie liczą się kroki, jakich potrzebujesz, żeby dojść do tego rezultatu. Liczy się rezultat i efekt biznesowy. 

To bardzo fajnie upraszcza te rzeczy, ten cały proces, bo wtedy, jeśli Twoje zorientowanie jest bardziej na to, żeby mieć tu i teraz szybko, to automatycznie chcesz wykorzystać jak najmniej pracy. I tutaj wydaje mi się, że pochodną tego – to jest takie moje wrażenie – jest nasz system edukacyjny i w ogóle to, skąd my pochodzimy, w sensie, te wszystkie lata komunizmu, w których wychowywali się nasi rodzice, ten taki kult pracy, w którym pracowanie, tworzenie, wytwarzanie jest tak dużą wartością w nas, że my czasami się wstydzimy zrobić coś sprytnie. 

Ja mam np. takie doświadczenia, że na rozmowach kwalifikacyjnych bardzo często ludzie  boją się mi powiedzieć, że korzystali z Chata GPT, mimo że dla mnie to jest wartością, bo to jest po prostu wykorzystywanie nowych technologii. Więc jak sobie to podsumujesz, czyli tę chęć tworzenia, brak takiego pragmatyzmu biznesowego – i to uważam, że jest takim sporym brakiem w IT – plus ten kult pracy: większość tych młodych ludzi, którzy teraz wchodzi na rynek, mimo że oni nie wychowali się w takim systemie edukacyjnym, pewnie jak ja, ale rodzice, starsi bracia, to jednak jeszcze potrzeba kilku pokoleń, żeby to zmienić i to powoduje, że my, Polacy, Europejczycy, bo to też dotyczy Europy, lubimy sobie troszeczkę czasami po prostu potworzyć, zamiast zrobić coś tak pragmatycznie, żeby działało i żeby przynosiło pieniądze. 

 

Faktycznie, też mam podobne obserwacje z tym tworzeniem dla tworzenia. Myślę sobie, że za tym stoi też taka potrzeba bycia przydatnym dla firmy, dla projektu, a jeśli nie czujemy tego, że tworzymy coś, co się faktycznie przydaje, no, to po pierwsze jakaś taka satysfakcja z pracy chyba gdzieś umyka, znika, a po drugie może rodzić się jakaś obawa, że za chwilę jednak to nasze stanowisko zniknie, ponieważ szef, przełożony, manager nie będzie widział tutaj takiej potrzeby, żeby nas zatrudniać, więc nie twierdzę, że wszyscy programiści i programistki tworzą do samego tworzenia, ale tych powodów, niekoniecznie właśnie takich biznesowych związanych z dostarczeniem wartości może być tutaj pewnie całkiem sporo. 

 

Właśnie, i teraz jeszcze wracając chwilę do tej przydatności, ja np. zarządzam firmą, która zatrudnia 70 osób, więc to nie jest duża firma, i u nas, patrząc na to, co jest skuteczniejsze, co jest lepiej postrzegane, każdy element sprytu, automatyzacji, wykorzystania gotowych komponentów, on się tak naprawdę liczy, ponieważ dzięki temu możemy sprawnie realizować projekty dla naszych klientów. Więc to stoi w kontrze z tym wrażeniem, o którym mówisz, czyli o tym, że chcemy być przydatni w pracy poprzez wykonywanie pracy, a nie wykonywanie pracy w sposób, powiedzmy, efektywny, sprytny. 

Właśnie, i teraz jeszcze wracając chwilę do tej przydatności, ja np. zarządzam firmą, która zatrudnia 70 osób, więc to nie jest duża firma, i u nas, patrząc na to, co jest skuteczniejsze, co jest lepiej postrzegane, każdy element sprytu, automatyzacji, wykorzystania gotowych komponentów, on się tak naprawdę liczy, ponieważ dzięki temu możemy sprawnie realizować projekty dla naszych klientów. Więc to stoi w kontrze z tym wrażeniem, o którym mówisz, czyli o tym, że chcemy być przydatni w pracy poprzez wykonywanie pracy, a nie wykonywanie pracy w sposób, powiedzmy, efektywny, sprytny. 

 

Tak, ta zajętość jest tutaj trochę mylnie postrzegana jako faktycznie przerzucanie łopatą piasku z jednej kubki na drugą, a tu oczywiście nie chodzi o wykonywanie samej pracy, ale dostarczanie wartości. 

No właśnie, porozmawiajmy może chwilkę o tym ego, które tutaj już padło, bo myślę sobie, że to jest taki istotny czynnik, dla którego wiele osób, pomimo tego, że wie, że np. pewne rozwiązanie już istnieje, można by to wykorzystać, można by to użyć, to jednak postanawia własnym sumptem stworzyć coś nowego, coś według tej osoby unikalnego, niezwykłego i dużo lepszego od już istniejących rozwiązań i myślę sobie, że ego jest często właśnie tym motorem, który pcha ludzi do tworzenia w ogóle. 

 

To chyba też troszeczkę zależy od etosu pracy w danym miejscu. Ciekawa historia jest, jak zaczynałem swoją pracę tam w 2000 roku i wtedy pracowałem w dosyć unikatowym zespole takich, powiedziałbym, hakerów prawdziwych, w sensie takim, że to byli goście, którzy w ogóle, wiesz, my nie mieliśmy takiego procesu stricte, gdzie byli testerzy, gdzie był quality assurance, po prostu wrzucałeś na produkcję samemu, to była firma, która mimo tego procesu realizowała naprawdę poważne projekty, ale tam etos pracy, taki, w którym jakość rozwiązania i jego efektywność plus nastawienie na automatyzację… 

My rozmawialiśmy na temat tego, jak automatyzować swoją pracę w 2000 roku, gdzie to byli programiści piszący w Perlu, i jeśli w organizacji jest taki etos, w którym szukamy efektywności bądź szukamy fajnych rozwiązań, to też przekłada się później na to, jak realizowane są projekty. 

A wiesz, jeśli masz gdzieś taki etos, gdzie liczy się jednostka, gdzie liczy się ktoś, kto ma takie wielkie ego, które nie potrafi zmieścić się w jednym pokoju i jeszcze też organizacja to kultywuje, bo to też organizacje potrafią kultywować to, to pewnie taka atmosfera pracy powstaje. Ale nie wiem, czy to ego jest tak naprawdę takim kluczowym. Raczej z mojej jego doświadczenia powiedziałbym, że nie ego, bardziej ta chęć bycia kreatywnym. Bo to jest chyba takie najbardziej kręcące, możesz się w końcu wyżyć, w końcu napisać, w końcu możesz usiąść sobie, to nic, że ten tam, nie wiem, CRM już istnieje, ale jak Ty go napiszesz, to on będzie tak napisany ładnie.

To jest też taka potrzeba wewnętrznej jakości, że jak ja to napiszę, to on będzie lepiej, niż coś tam – a może rzeczywiście, może masz rację, to jest ego – będzie lepsze to, niż tamtego, co to napisał.

 

O ile potrafię trochę zrozumieć takie indywidualne podejście właśnie w tym kontekście kreatywności, że chcemy coś stworzyć, chcemy być kreatywni, chcemy wymyślać coś nowego, tworzyć coś lepiej, o tyle ta perspektywa firmy, która powinna być jednak skierowana głównie na zysk, na wartość dostarczaną na rynek dla klientów, powinna być już inna.

W sensie nie powinniśmy brać pod uwagę takiej konieczności tworzenia dla samego tworzenia, ale faktycznie próbę wyboru takiego narzędzia, które będzie optymalne dla danej sytuacji, dla danego klienta, ale pamiętam, jak też na początku lat 2000 swoją karierę rozpoczynałem i wówczas każda firma posiadała swój CMS, swój CRM, tworzyła po prostu te rozwiązania dla siebie, pomimo tego, że już zaczynały się pojawiać jakieś rozwiązania na rynku.

I miałem wrażenie, że to taki będzie krótkoterminowy tylko trend, ale okazuje się, że nawet dzisiaj mamy tego typu podejścia, gdzie mimo mnóstwa różnych rozwiązań firmy i tak stwierdzą, że będą w stanie zaproponować coś, coś lepiej. 

I to mnie troszkę dziwi, że ta perspektywa firmy powinna być jednak inna, powinna być skierowana na zysk, na wartość, a tutaj często pojawia się właśnie wymyślanie tego koła na nowo po raz kolejny. 

 

I to jest w ogóle bardzo ciekawe temat. Ja jakbym miał powiedzieć o swojej opinii, jak ja to widzę, to wydaje mi się, że on się bierze stąd, że troszeczkę ta perspektywa biznesowa z tą perspektywą technologiczną się rozjeżdża, głównie ze względu na to, że jest moim zdaniem duży rozjazd między biznesem a technologią. 

To znaczy, to jest w ogóle tak, jak masz takie bariery organizacyjne w firmach, np. nie wiem, jest odwieczna walka sprzedaży z marketingiem, to wydaje mi się, że jest taka nawet nie walka, bo oni nie walczą ze sobą, tylko taka ściana milczenia między biznesem, a technologią. 

Dlaczego? Bo te dwa światy kompletnie się nie rozumieją. Generalnie ludzie biznesowi, czyli np. właśnie szefowie firm, którzy są bardzo zorientowani na biznes, nie rozumieją, o czym mówi informatyka. Ludzie, którzy są technologiczni, zupełnie nie rozumieją, na czym polega biznes. To jest naturalne, nie można w tej sytuacji mówić, że ktoś jest zły, ktoś jest dobry, no po prostu to są dwie zupełnie inne bańki, zupełnie inne przestrzenie wiedzy itd. Więc to jest duży problem, żeby one się przenikały. 

I teraz, wiesz, organizacje, które potrafią troszeczkę zaglądać do siebie, tzn. ci szefowie biznesowi, którzy potrafią powiedzieć: no dobrze, na czym ta technologia polega, jakie są jej rezultaty, potrafią stymulować to środowisko do szukania rozwiązań efektywnych, ale teraz liderzy, ci techniczni, którzy szukają zrozumienia, bo to też trzeba sobie powiedzieć wprost,  jeśli znam się na IT, na informatyce, to nigdy nie będę takim turbo sprzedawcą, czy turbo biznesmenem. I w drugą stronę, jeśli jestem super sprzedawcą, super biznesmenem, to nigdy nie będę dobrym technologiem. 

Więc cała sztuka polega jakby w szukaniu tego organizacyjnie, polega na przenikaniu się tych światów, czyli to, żeby ten biznes troszeczkę zrozumiał rezultaty i koszty i konsekwencje technologii, ale też, i to jest taki w ogóle w kontekście chyba następnych rzeczy, które się będą działy w świecie technologii, żeby technologia potrafiła pochylić się nad prawdziwym biznesem, zrozumieć mechanikę biznesu i zobaczyć, jak to wygląda, czyli jeśli ja tutaj spalę tyle kasy, to ile firma na tym zarobi.I liderzy technologiczni, którzy potrafią tak myśleć, im jest łatwiej. 

 

Myślę sobie, że takim pewnym panaceum na nieodkrywanie koła na nowo jest to, żeby wykorzystywać narzędzia, które już stworzyliśmy albo kod, który stworzyliśmy, ale tu chciałbym Cię zapytać, czy to nie jest swego rodzaju mit, ta reużywalność kodu właśnie, bo często mamy różnego typu problemy, czy bariery takie organizacyjne, technologiczne, które zatrzymują tą reużywalność. Byłbyś w stanie powiedzieć o tego typu blokadach i czy według Ciebie kod da się sensownie ponownie wykorzystać? 

 

Trochę będę znów wracał do tej jakby części biznesowej, bo to jest wszystko kwestia troszeczkę kosztów i konsekwencji. Bo trzeba spojrzeć na to z perspektywy kosztów, konsekwencji, ryzyk itd., nie? Ponieważ wracając do tego biznesowego punktu widzenia, jeśli masz do osiągnięcia jakiś rezultat, to czy wykorzystasz technologię istniejącą i będziesz miał pewne ograniczenia z nią związane, to jest kwestia tego, czy jesteś w stanie biznesowo to zaakceptować. Bo do tego to się sprowadza. 

Dam Ci przykład, ostatnio rozmawialiśmy z klientem, który chciał napisać aplikację zupełnie od zera. Powiem Ci szczerze, panie prowadzą bardzo fajny biznes i szykował się naprawdę fajny temat, chociaż trudny, bo panie prowadzą biznes zupełnie w takiej innej działki. I podczas rozmowy, tak naprawdę z projektu za 700 tys., 800 tys., milion złotych, przeszliśmy do projektu za 20 tys., w którym mówimy: dobrze, to na starcie wykorzystajcie istniejące rozwiązania. Powiem bardziej brutalnie, nawet wiesz, nieistniejący kod, tylko rozwiązanie SaaS-owe, które jest na rynku. Ono ma masę ograniczeń, nie realizuje tego tak idealnie, jak tego chcecie, ale jesteście w stanie sprawdzić, czy to rozwiązuje wasz konkretny problem. 

Więc teraz odpowiadając Ci, czy reużywać kod, ja już też muszę przyznać się szczerze, nie programuję od naprawdę wielu lat, w sensie takim, że nie wiem, kiedy ostatnio siedziałem przed kodowaniem, ale widzę, tak jak pracujemy w zespole, że wszystko jest konsekwencją czegoś i jeśli umiesz złapać, czy te konsekwencje, czyli, nie wiem, no nieidealny kod, niedoskonały, nie takie funkcjonalności, nie takie rozwiązania, potrafią Ci pomóc, to to jest okej. 

Prawda jest taka, że dzisiaj, w tym, jak szybko zmienia się technologia, w większości przypadków liczy się nie idealne rozwiązanie, tylko szybkie rozwiązanie, w sensie rozwiązanie, które powstaje szybko. Biznes, który wymyślisz dzisiaj, do którego tworzysz system, za trzy miesiące może okazać się zupełnie nieadekwatny do rzeczywistości. Więc, jeśli tworzysz rozwiązanie osiem miesięcy, to niestety może być tak, że… No chyba, że pracujesz nad rozwiązaniem, które jest, wiesz, które jest gdzieś tam z dziedziny takiej bardzo dużej, poważnej inżynierii, ale to takich projektów jest już coraz mniej. 

 

Właśnie, tak jak powiedziałeś, większość algorytmów, większość podejść i mnóstwo w informatyce zostało już wymyślone i to samo tyczy się architektury. Nie jedna książka została na ten temat napisana i to już dziesięciolecia temu. Co myślisz o tzw. nowoczesnej architekturze? Czyli takiej luźnej, niekoniecznie sformalizowanej, takiej, która gdzieś nie opiera się na jakichś mocnych pryncypiach? Czy to jest jakieś sensowne podejście, czy to może jest po prostu ładne słowo na opisanie bałaganu?

 

Mam takie wręcz schizofreniczne podejście, bo mam dwa podejścia. Z jednej strony jest Bartosz, który jest szefem firmy, który patrzy biznesowo, wynikowo itd. Z drugiej jest jednak gość, który wywodzi się z IT i wie, jakie są konsekwencje takiego podejścia. 

Więc teraz tak, do tego trzeba też spojrzeć przez kontekst, tzn. te wszystkie szybkie architektury, wręcz te architektury, które w tej chwili powstają na rozwiązaniach takich tych low-code’owych czy praktycznie zupełnie zero-code’owych, one są fajne na pewnym etapie. I wiesz, nie ma nic fajniejszego, niż po prostu zrobić, nie wiem, proof of concept czy zrobić pierwszą wersję software’ów, nie patrząc troszeczkę na architekturę, bo takie podejście ma sens. 

Towarzyszymy jednej firmie, która wprowadzała produkt na nowy rynek, i tam liczyła się szybkość, żeby zderzyć się z tym rynkiem. I wtedy rzeczywiście, czy to jest Ruby on Rails, który jest też stary, ale znów wraca do łask, czy to są narzędzia low-code’owe, czy to są te workflowy, takie wyklikiwane, które zresztą też kiedyś Oracle, IBM już miały w swojej ofercie dwadzieścia parę lat temu, jakby w tego typu, na tym etapie absolutnie zachęcam do niepatrzenia na jakość kodu, na jakość architektury.

Ale jeśli produkt to rusza, no to my np. w swoim portfolio mamy projekty, które utrzymujemy 10 lat. To jest 10 lat utrzymywania, naprawiania błędów, rozwijania tych systemów, i tutaj, nie patrząc na czyste podejście architektoniczne, po prostu z takiej perspektywy czasu to to jest proszenie się o problemy.

I znów teraz to ten techniczny Bartosz tłumaczy, przekłada to na argumenty biznesowemu Bartoszowi, bo to jest też koszt związany z tym, że później każdy błąd kosztuje dużo więcej pieniędzy, dużo więcej kosztują zmiany, więc odpowiadając na Twoje pytanie, nowe podejścia, nowe architektury, te w tej chwili idące już w generowaniu kodu praktycznie z AI, one są super, tylko za chwilę będziemy mieli taką sytuację, że tego kodu powstanie bardzo dużo, a te systemy będą miały jakąś karencję 5-, 10-letnią, jeśli zadziałają. Bo jeśli nie zadziałają, jeśli nie wygenerują żadnego biznesu, to tam, wiesz, „RM -FR/” i już kodu nie ma, systemu nie ma. 

Ale myśląc długofalowo trzeba jednak tą architekturę, te pryncypia takie architektoniczne, które są wypracowane już od dawna, brać mocno pod uwagę. 

 

Właśnie to jest perspektywa, którą mam wrażenie, niezbyt często bierzemy obecnie pod uwagę, mówiąc o tym, że da się wiele rzeczy wygenerować, że AI mnóstwo rzeczy za nas stworzy. Stworzenie to jest jedno, natomiast utrzymanie później takiego projektu, które zazwyczaj trwa dużo dłużej niż stworzenie jego pierwotnej wersji, to jest inna kwestia. I tutaj niestety ta jakość początkowa bardzo nas może ugryźć w pewną część ciała w momencie, kiedy będziemy musieli nieraz przez dziesięciolecia, tak jak zaznaczyłeś, ten projekt utrzymywać. 

Co byś doradził takiemu liderowi technicznemu albo managerowi zarządzającemu zespołem, jak wychwycić taki moment, jak zauważyć taki moment, kiedy zaczynamy w zespole właśnie tworzyć koło na nowo? Kiedy zaczynamy niepotrzebnie komplikować rzeczy, dokładać niepotrzebne warstwy? Czy są jakieś przesłanki, jakieś sygnały, które nam mogą się zaświecić i powiedzieć, że hej, może zatrzymajmy się, przeanalizujmy, co robimy? 

 

Kurczę, to jest bardzo trudne, bo przy zarządzaniu zespołem to też bardzo często jest też zarządzanie talentami, to jest jeszcze druga strona tego Twojego pytania, czasami managerowie godzą się na to, żeby pewne rzeczy napisać od nowa trochę w sposób celowy, to jest też biznesowa czasami decyzja, na zasadzie takiej, że masz talent, który po prostu, wiesz, że jeśli nie dasz mu przestrzeni troszeczkę na tę kreatywność, to on najzwyczajniej w świecie odejdzie. 

Wydaje mi się, że rozwiązań, nie ma rozwiązań krótkoterminowych, to znaczy, wydaje mi się, że to jest tak, że takie właściwie budowanie pewnego rodzaju etosu pracy, w którym gdzieś ta efektywność, tylko nie rozumiana jako efektywność poprzez pracowanie 9 godzin w 8 godzin, bo to jest też nasze takie polskie zrozumienie efektywności, modele pracy, gdzie po prostu pracujesz bardzo ciężko 8 godzin, ale modele pracy, w których stawiasz na efektywność, stawiasz na rezultaty, a nie na pracowanie, wydaje mi się, że to jest, to jest droga. 

Tylko że mówię: tutaj ja szczerze mówiąc, nie znalazłem dróg na skróty, takich, wiesz, takich triggerów, które pozwalają Ci powiedzieć, no nie, chłopie, coś tu idzie nie tak. Bo tak jak mówisz, to tak się dziej, i niestety, co gorsza, czasami obserwujemy to i w momencie, kiedy już to tak trwa głęboko, że już trudno się z tego wycofać. 

My teraz zrobiliśmy taki eksperyment, naszym liderom technologicznym, jakby zrzuciliśmy na nich troszeczkę ten element finansowy, w którym pokazaliśmy im, jak performance zespołów technicznych jest widziany przez pryzmat liczb finansowych. Czyli jak po prostu nasi ludzie działają profitowo. 

I to jest taki eksperyment, gdzie mówimy naszym liderom: słuchajcie, stańcie się trochę takimi małymi przedsiębiorcami, tzn. popatrzcie sobie, co wam się bardziej opłaca, co wam się mniej opłaca. I taki wskaźnik powoduje, że oni zaczynają dostrzegać ich konsekwencje na zasadzie takiej, że mając jakieś budżety swoje, zaczynają widzieć, że jeśli optymalizują tę pracę pod kątem efektywności, to z tego mają przestrzeń na nowe rzeczy. I to oczywiście nie chodzi o to, żeby zabić kreatywność, tylko zabić ją w miejscach, gdzie ona jest bezsensowna. 

Czyli jeśli mamy inicjatywy, które są kreatywne i gdzie rzeczywiście warto użyć tam kreatywności, np. żeby zrobić nową automatyzację, czy rzeczywiście nawet, żeby spróbować czegoś nowego, nowej technologii, po to, żeby ją spróbować, to idealny sposób na to, to jest wykroić sobie z budżetu przestrzeń na to, czyli robić rzeczy dla klientów w sposób efektywny, dając sobie przestrzeń na rzeczy kreatywne. 

I teraz nasi liderzy, widząc te zależności, już zaczynają sobie kombinować, oni wiedzą, że np. jeśli zaoszczędzą troszeczkę czasu swoich ludzi, to nie jest taki czas, że im ten czas ktoś zabierze i ukradnie, tylko np. mogą wykorzystać ten czas na szkolenia, mogą ten czas wykorzystać na eksplorowanie nowych tematów. Czyli jakbym miał skonkludować sposób, to jest jednak mimo wszystko to, co wiesz, to, co gdzieś tam przemawia w całej mojej wypowiedzi, no spojrzenie, nauczenie liderów technologicznych tego spojrzenia biznesowego i zobaczenie, jak to działa, jak te suwaczki działają. 

I to jest taki eksperyment, gdzie mówimy naszym liderom: słuchajcie, stańcie się trochę takimi małymi przedsiębiorcami, tzn. popatrzcie sobie, co wam się bardziej opłaca, co wam się mniej opłaca. I taki wskaźnik powoduje, że oni zaczynają dostrzegać ich konsekwencje na zasadzie takiej, że mając jakieś budżety swoje, zaczynają widzieć, że jeśli optymalizują tę pracę pod kątem efektywności, to z tego mają przestrzeń na nowe rzeczy. I to oczywiście nie chodzi o to, żeby zabić kreatywność, tylko zabić ją w miejscach, gdzie ona jest bezsensowna.

 

No ciekawa perspektywa na pewno otwierająca oczy. Wiesz, zastanawiam się, dlaczego minimalizm w IT jest tak trudny do osiągnięcia. Mówimy dzisiaj o takiej prostocie w projektach technologicznych, o nieodkrywaniu koła na nowo. Często, albo powiedziałbym, że zawsze mamy dobre chęci na początku. Chcemy przecież wykonać ten projekt w ten sposób, że w końcu będzie dobrze, tak? A najczęściej kończy się tak jak zawsze, te projekty nam puchną, są trudne w utrzymaniu, więc zastanawiam się, gdzie ta trudność osiągnięcia tego minimalizmu?

 

Tu mam już takie przemyślenie, ostatnio nad ranem mnie naszło. I łatwiej nam będzie rozmawiać, bo Ty mówisz, że zaczynałeś swoją karierę w latach dwutysięcznych, więc prawdopodobnie swoją wiedzę na temat IT czerpałeś z książek, prawda? Ja miałem wspomnianą książkę do Perla, miałem Receptury Perla, to były dwie książki, dwie biblie w 2000 roku, które były po prostu zawsze na biurku u każdego z naszych programistów.

I  dzisiaj mamy taką sytuację, że informacje na temat tego, jak programować, jakiej architektury użyć, jakich narzędzi użyć, jest tak dużo, że zaryzykuję stwierdzenie, że tych informacji jest nadmiar. To jest takie informacyjne przeładowanie, które skutkuje tym, że my się trochę chyba w tej informacji gubimy, i trudno jest nam myśleć o takiej czystej architekturze, jeśli dociera do nas tyle sygnałów.

W czasach takich, jak my zaczynaliśmy, ja wiem, że to jest trochę gadanie takiego czterdziestoparoletniego pana, który programował wiele lat temu, o, za moich czasów, ale prawda jest taka, że czasy się drastycznie zmieniły, ilość informacji jest dużo większa. To jest w ogóle też śmieszne, że mam teorię, że Chat GPT w kontekście ostatnich 20 lat nic nie zmienił praktycznie, bo kiedyś mieliśmy mało informacji i korzystaliśmy z małej ilości informacji, dziś mamy dużo informacji i Chat GPT nam syntetyzuje tę wiedzę.

 

Tak, musi skracać wszystko.

 

Więc nic się nie zmieniło, 20 lat, a nic się nie zmieniło. Ale ten nadmiar informacji, kiedy zaczynasz, kiedy jeszcze nie jesteś doświadczony, kiedy nie wiesz, jakie informacje są prawdziwe, które są niesprawdzone, no my jak zaczynaliśmy naszą karierę, wiesz, studia, książki, droga była prosta. Dziś informacji jest strasznie dużo. I teraz największym problemem jest chyba przeciążenie.

Taki mój sposób, który ja mam, to po prostu, kiedy muszę usiąść i pomyśleć, zastanowić się nad czymś i zsyntetyzować coś do prostego rozwiązania, jest po prostu odcięcie się troszeczkę w pewnym momencie od tych źródeł informacji, tak, żeby usiąść przy kartce. I wydaje mi się, że w programowaniu też to tak działa, nie w sensie w programowaniu w technologii, w architekturze.

 

No tak, informacji jest więcej, wiedzy jest więcej, ale z drugiej strony mamy też narzędzia i rozwiązania, które powinny nam pomóc nawigować w tym gąszczu. Myślę tutaj o open source, które już teraz jest fundamentem i podstawą prawie wszystkich rozwiązań na całym świecie. Stack Overflow, AI. Więc teraz pojawia się pytanie, czy dzięki tym narzędziom my tworzymy szybciej, lepiej rozwiązania, czy też może nie za dużo się tutaj zmieniło, tak jak powiedziałeś?

 

To jest dobre pytanie. To jest troszeczkę tak, że nasza rozmowa ciągle jest jednak osadzona w kontekście nas mających swoje lata, którzy np. patrzą na młode pokolenia Gen Z i mówią: Boże, jak można tak pracować? I teraz, wiesz, efekt tak naprawdę chyba nie jest do oceny dzisiaj. Bo tak naprawdę to, w jaki sposób wylewarowało nas w tej chwili, jak wylewarował nas AI, jak za chwilę będzie nas lewarował AI, no to są takie zmiany, które już widać na zasadzie efektywności, takiej nawet pracy czysto biurowej.

I to będzie szło dalej. Wydaje mi się, że taka ocena tego będzie możliwa za jakieś 10 lat, kiedy ci goście, którzy w tej chwili są, powiedzmy, pewnie dużo bieglejsi w tych nowoczesnych technologiach niż my, oni z nich korzystają, my troszeczkę czasami zaczynamy łapać. Bo jak ja mam na przykład 46 lat, a przychodzą do nas chłopaki po studiach, to jest już pokolenie, to już są różnice pokoleniowe, więc ja czasami troszeczkę nie rozumiem tego, co oni mówią, ale to tak jak nasi ojcowie nas nie rozumieli, więc czy to nam przyspieszy? No na pewno. Historia pokazuje, że kolejne pokolenia są dużo efektywniejsze niż poprzednie, więc na pewno nas przyspieszy.

Czy nie dojdziemy do takiego momentu, kiedy ten nadmiar informacji po prostu przestanie nas rozwijać, to pewnie musimy się spotkać za 20 lat i ocenić to z perspektywy, wtedy już jako historycy, a nie informatycy.

 

Właśnie, ja mam takie przemyślenie w tym temacie, że co prawda tworzymy te rozwiązania szybciej, sprawniej, efektywniej, ale też zapotrzebowanie się zmienia. To też wygląda inaczej niż na przykład te 15 czy 20 lat temu, tzw. time to market, szybkość tworzenia, szybkość wychodzenia z tym na rynek jest zdecydowanie inna, więc myślę sobie, że to są narzędzia na miarę czasów, na miarę tego, jakie jest zapotrzebowanie, jaka jest potrzeba, ale pewnie, gdyby spojrzeć, tak spróbować, starać się stwierdzić, czy my drastycznie szybciej teraz tworzymy te rozwiązania, niż to było wcześniej, to tutaj mam mieszane uczucia, tak jak powiedziałaś, być może jeszcze za mało wody w Wiśle upłynęło, żeby to ocenić, zobaczyć.

 

Tutaj jest jeszcze jeden aspekt, to jest to, co wspomniałeś, czyli złożoność rozwiązań. My np. pracujemy dużo z administracją publiczną i mój ulubiony przykład to jest w ogóle komunikacja z administracją publiczną.

Jak szedłem po swój pierwszy dowód, no to droga do dojścia do dowodu osobistego była jedna, po prostu trzeba pojechać do urzędu, złożyć dokument, okienko itd. Dzisiaj nawet zwykły urząd potrafi mieć tyle kanałów komunikacji, zwłaszcza duże miasta, gdzie liczba platform, która wspiera petentów, czy ilość kanałów komunikacji, które muszą zostać obsłużone, jest już tak duża, że ta cała komunikacja staje się problematyczna.

To samo, jak spojrzysz na bank, to samo, jak spojrzysz na firmę ubezpieczeniową. Więc rzeczywiście całościowo to, że jest więcej rozwiązań, wymaga większej liczby rozwiązań, wymaga większej liczby specjalistów do tego, żeby te rozwiązania obsługiwać i szybkość po prostu powoduje, że to ma szansę się rozwijać, że to może z perspektywy historii wygląda, że to wcale nie idzie wolniej, ale no, szerzej.

 

Rozumiem, jasne. Do tej pory mówiliśmy o takich, mam wrażenie, powodach wewnętrznych, dla których wymyślamy to koło na nowo, wykorzystujemy albo nie wykorzystujemy istniejące rozwiązania, tak? 

Mówiliśmy tutaj o tym, że istnieje może to ego, że jest potrzeba kreatywności, potrzeba wyżycia się w jakiś sposób taki kreatywny. Natomiast, gdyby tak spojrzeć na tą perspektywę zewnętrzną, czyli, czy według Ciebie managerowie i tzw. szeroki biznes też tutaj nie gra jakiejś roli? 

Czy to, że IT tworzy chaos w jakimś stopniu albo że ponownie wymyśla te rozwiązania, które już istnieją, nie jest często powodowane, nie jest często właśnie niejako stymulowane przez tą stronę biznesową i IT tylko gdzieś tam, no musi się w tym wszystkim odnaleźć, musi w jakiś sposób znaleźć swoją drogę?

 

Nie wciągnę się w dyskusję na temat, kto jest ofiarą, kto jest katem. Wydaje mi się, że są zarówno przypadki, kiedy biznes jest chaotyczny, nie daje wymagań, i jest taki biznes, który daje bardzo precyzyjne wymagania, a IT potrafi to zamieszać, a wydaje mi się, że średnia jest taka, że obie te strony powodują chaos, więc moim zdaniem ta wina, której próbujemy poszukać, zaryzykowałbym, że jest równomiernie rozłożona.

Ten pośpiech to też jest kwestia tych czasów. Pośpiech, musimy szybko dowieść, to jest  taka ulubiona potrzeba zrobienia czegoś, muszę dowieść to i po prostu nieważne, co się stanie, muszę to dowieść, i tak wszyscy wpadają czasami w taką pętlę na poziomie biznesu, nie pozwalając sobie tym samym na zrozumienie troszeczkę barier, które leżą po stronie technologicznej. I po stronie technologicznej nie pozwalają sobie na zrozumienie, a rozwiązania w sumie są dosyć proste i wynikające z takiego trochę psychologicznego aspektu życia.

Nie wciągnę się w dyskusję na temat, kto jest ofiarą, kto jest katem. Wydaje mi się, że są zarówno przypadki, kiedy biznes jest chaotyczny, nie daje wymagań, i jest taki biznes, który daje bardzo precyzyjne wymagania, a IT potrafi to zamieszać, a wydaje mi się, że średnia jest taka, że obie te strony powodują chaos, więc moim zdaniem ta wina, której próbujemy poszukać, zaryzykowałbym, że jest równomiernie rozłożona.

 

Rozumiem, bardzo dyplomatyczna odpowiedź.

 

Nie, nie dyplomatyczna, tak jest, po prostu tak jest.

 

Jasne, jasne, rozumiem. Zastanawiam się, czy da się stworzyć jakiś taki proces, który by nas trochę ochronił przed właśnie takim nadmiarem tego różnego typu rzeczy, które wprowadzamy do projektu, nadmiarem kodu, funkcji, integracji, czy, no nie wiem, da się w jakiś sposób rozmawiać z PM-em, z klientem, żeby nie komplikować sobie życia, czy w jakiś sposób jesteśmy w stanie podejść do tego procesu wytwórczego, aby starać się przynajmniej jakąś tę prostotę zapewnić w projekcie IT?

 

To jest troszeczkę tak, ja uwielbiam brutalne porównania, i widzę, że bardzo często w ogóle informatycy, w sensie architekci i programiści są zrównywani przez swój, nie wiem, ekscentryczny charakter, czasami do artystów. A prawda jest taka, że większość z nas to inżynierowie. W sensie inżynierowie, czyli ludzie, którzy używają narzędzi do wytworzenia czegoś.

I tutaj, wiesz, i tutaj warto sobie spojrzeć na takie analogie do warsztatu samochodowego, gdzie wchodzisz do warsztatu samochodowego i w jednym warsztacie jest bajzel, są porozrzucane narzędzia, jest pięć samochodów rozgrzebanych, żaden nieskończony, a wchodzisz czasami do takiego warsztatu, gdzie nie ma procesu.

Wiesz, mój ulubiony proces to są autoryzowane serwisy, gdzie masz tych doradców klienta, gdzie masz asystentkę, gdzie masz szefa serwisu itd., i czasami wchodzisz do takiego garażowego gdzieś warsztatu, w którym panuje porządek, gdzie facet podchodzi do sprawy bardzo rzetelnie, przychodzisz, coś ci stuka, on zagląda, słucha itd. Oczywiście ty mówisz, bo Ty z YouTuba już wiesz, co nie działa, próbujesz mu powiedzieć, co ma naprawić, a on mówi: proszę pana, bardzo dziękuję za pana sugestie, proszę mi zostawić auto, za cztery dni będzie.

Panie, ja potrzebuję dzisiaj, jutro itd. Rozumiem, to proszę znaleźć inny warsztat. I teraz tak,  są to dwa aspekty. Pierwszy to jest ten warsztat pracy zorientowany na prostocie, na porządku pracy, na takim kulcie związanym właśnie z tą taką inżynierią porządną, a druga sprawa też troszeczkę taka asertywność, to znaczy powiedzenie: no sorry, to ja jestem tutaj inżynierem, inżynierem, nie artystą, to ja muszę poświęcić na to ileś tam czasu, i to jest trudne, ale wydaje mi się, że jeśli dowieziesz kilka takich dowodów na to, że warto było poczekać, bo rozwiązanie, które jest dostarczone, jest działające, jest sprawne, nie jest jakoś bardzo tam przeciągnięte w czasie, to wtedy ludzie zaczynają Ci ufać.

Ale do tego są potrzebne te dwie rzeczy, czyli warsztat. Nie wiem, czy tutaj, mnie się nigdy nie udało znaleźć takiego systemowego rozwiązania, bardziej rozwiązanie bazujące na ludziach, którzy cenią sobie tę prostotę rozwiązania i potrafią ją wprowadzić w życie, zwłaszcza w przypadku, kiedy mamy agresywny biznes, który mówi: już, teraz, szybko. A on mówi: no nie, to muszę chwilkę potrwać, ale gwarantuję Ci, że to będzie dobrze zrobione.

Tutaj mój ulubiony przykład ostatnio, to właśnie, żeby tę analogię jeszcze podeprzeć przykładem ostatnio, zawieszenie mi pukało, wyobraź sobie, że w autoryzowanym serwisie byłem sześć razy i za czterema razami wymieniano coś w samochodzie. Dopiero za piątym razem ktoś osłuchał moje auto i za szóstym razem wymienił, co było wadliwe, więc to dzieje się dokładnie też w firmach, nie?

Przychodzi PM, muszę mieć tu szybko, szybko, od razu itd. i ktoś, kto ulega presji, mówi: dobra, zrobię Ci na szybko, to się wywala albo jest skomplikowane. Teraz nie ulegając tej presji, trzeba pamiętać, że to rozwiązanie trzeba dowieźć. Warsztat, jak najbardziej warto.

Mam nadzieję, że moja analogia do mechaników nikogo nie zabolała, ale ja uważam, że nie oszukujmy się, jesteśmy inżynierami, bliżej nam do mechaników niż do Picassa.

 

Zdecydowanie. W związku z tym pojawia się pytanie, jak przekonywać zespół, że mniej kodu to więcej wartości, że czasem ten nienapisany kod jest lepszy, ponieważ nie wymaga utrzymania i nam oszczędzi problemów w przyszłości. Czy masz może jakieś doświadczenia z projektów, gdzie właśnie prostota wygrała ze złożonością?

 

Chyba to jest tak jak zarządzanie każdą zmianą. Najfajniej jest znaleźć kogoś, kto pokazuje przykłady. To też jest dosyć ciekawe, bo my pracujemy bardzo często w branży introwertyków, którzy często nie chwalą się swoimi rozwiązaniami, wręcz ci, którzy głośno mówią o swoich sukcesach, w wielu przypadkach w backgroundzie gdzieś tam to, co się dzieje, to co się dzieje, wygląda inaczej.

I z tej perspektywy właśnie chyba takie szukanie, jeśli mówimy organizacyjnie, to szukanie dobrych przykładów, pokazywanie tych, którzy tam siedzą sobie w swoim temacie, ale robią fajną robotę, i pokazują, że prosto można zrobić lepiej, na przykładach to najlepiej jest zrobić.

 

No tak, bo można wiele mówić na jakiś temat, można przedstawiać wiele pozytywów, które będą z tej zmiany wynikały, ale jeśli ktoś nie poczuje tego, można powiedzieć, gdzieś namacalnie na własnej skórze, no to tylko będzie to traktował jako teorię i jednym uchem wpadnie, a drugim, a drugim wypadnie.

Właśnie, myślę sobie, że pewnie nie unikniemy tego, żeby jeszcze wiele razy powtarzać ten błąd z odkrywaniem koła na nowo i niepotrzebnym komplikowaniem sobie projektów, ale przynajmniej warto popatrzeć, jak możemy do tego tematu podejść, jakie potencjalne, nieraz drobne kroczki możemy zrobić, aby w tym naszym następnym projekcie zmniejszyć trochę ten poziom skomplikowania, co oczywiście przysłuży się nie tylko nam, ale i całemu zespołowi.

Bartku, bardzo Ci dziękuję za rozmowę i za podzielenie się swoimi doświadczeniami w tym temacie.

 

Dzięki, Krzysztof.

 

Powiedz jeszcze, proszę, na koniec, gdzie Cię możemy znaleźć w internecie, gdzie możemy słuchaczy odesłać.

 

Zapraszam do mojego LinkedIna. Teraz, o właśnie, może to będzie taki commitment publiczny, który będę teraz musiał spełnić. Właśnie zamierzam też odpalić swojego YouTube’a. Wychodzę z założenia, że te nasze doświadczenia, które mamy, należy się nimi dzielić i to pewnie jest powód. Ci, którzy pracowali ze mną jak i programiści pewnie teraz patrzą na mnie i mówią: o, to pewnie właśnie dlatego, że tamten kod czasami nie działał tak, jak powinien. Więc LinkedIn i YouTube, pewnie niedługo będę wrzucał jakieś pierwsze filmy.

 

Super, to trzymam wobec tego kciuki za rozwój kanału. Linki oczywiście się znajdą w otwarcie do odcinka. Jeszcze raz Ci bardzo dziękuję.

Do usłyszenia. Cześć!

 

Dzięki!

 

I to na tyle z tego, co przygotowałem dla Ciebie na dzisiaj. Więcej wartościowych treści znajdziesz we wcześniejszych odcinkach. Masz pytania? Napisz do mnie na krzysztof@porozmawiajmyoit.pl lub przez social media. Ja się nazywam Krzysztof Kempiński, a to był odcinek podcastu Porozmawiajmy o IT o tym, dlaczego w IT tworzymy koło na nowo, czyli o sztuce prostoty w projektach technologicznych.

Do usłyszenia w następnym odcinku.

Cześć!