Łukasz Kałużny: Skończyły się czasy romantycznego IT, romantyzowania IT, to jest taka sama praca jak każda inna, że jest ona 9-17 i ludzie chcą wrócić do swojego życia.

Szymon Warda: Trzeba zwalniać i trzeba nauczyć się zwalniać, sorry.

Łukasz Kałużny: Jesteście bardzo niereprezentatywną próbką osób pracujących obecnie w IT. Ale trzeba się z tym pogodzić, że zespół dowozi wolniej niż Ty, zrobi to gorzej niż Ty.

Szymon Warda: To nie jest droga, to jest ciągły proces. To nie jest tak, że przejdziesz to raz i już jestem po drugiej stronie tego mostu.

Łukasz Kałużny: Nie.

Szymon Warda: Nie. Lider to jest osoba, która umie dobrać rozwiązanie do tego, co można realnie wykonać i co zespół realnie dostarczy.

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

Szymon Warda: I Szymon Warda. Wszystkie linki do tego odcinka lewo, prawo, góra, dół, Patoarchitekci.io, ogarniecie, dokładnie.

Łukasz Kałużny: Dobrze.

Szymon Warda: Łukasz.

Łukasz Kałużny: Bardzo szybko segment wstępowy, czyli zerknijcie na szkolenia, które nadchodzą. To jest taka pierwsza rzecz. Druga rzecz, konferencja z okazji 200 odcinka, gdzie między innymi nagramy to na żywo - 16 czerwca i już niedługo wrzucimy tematy naszych sesji. To jest rzecz, z którą jeszcze z Szymonem walczymy, o czym opowiedzieć. Chyba, że macie jakieś swoje życzenia, to zrobimy fan serwis i wrzućcie na Discorda.

Szymon Warda: I standardowy segment właściwie - like & subscribe, że tak powiem. Czyli polubcie, wyślijcie. Najlepsza forma jest wyślijcie odcinek, który Wam się podoba, komuś innemu, niech posłucha, może skrytykuje, to wyślijcie krytykę, może być. Dobrze Łukaszu, dziś odcinek, za który nas chyba nikt nie polubi i wyleje się kubeł szlamu, ale trzeba.

Łukasz Kałużny: Dobra, na Discordzie, pozdrawiamy Kubę, bo to od niego pytanie: jak sobie radzić z możliwościami zespołów: miliony pomysłów, ambitne plany i rzeczywistość, że brakuje nam skillsetu albo ludzi do roboty? Temat do ugryzienia zarówno od strony technicznej, projektowanie i planowanie z uwzględnieniem dostępnych zasobów jak i emocjonalnej: czemu to trwa tydzień, jak to bym zrobił w kilka godzin? Klasyczne problemy. I dzisiaj struktura, sobie przejdziemy, mamy bardzo różne notatki, więc przejdziemy naszymi złotymi myślami, będziemy sobie odbijać. I ja chyba zacznę od największego problemu, miałem go u siebie też przez długi czas. Ty chyba też na to… Inaczej…

Szymon Warda: Każdy to ma.

Łukasz Kałużny: Każdy w pewnym momencie choruje. I pierwsza taka myśl, czemu to trwa tydzień, jak ja bym to zrobił w kilka godzin? Tutaj powiem jedna rzecz, to jest zacznij od siebie. W ogóle czemu jest, bo to jest teraz takie pytanie: what the fuck, że Ty jesteś w stanie na przykład, tak jak Kuba wrzucił, i znam te rzeczy, że ja zrobię to w kilka godzin, ktoś o wiele szybciej. I to jest takie, że zamiast tej frustracji trzeba wreszcie podejść i emocji trzeba troszeczkę zrobić sobie w zespole, jeżeli mówimy o kontekście zespołu, projektu, taką rzetelną analizę, rozmowę ze sobą, jak i z zespołem, co tak naprawdę to powoduje i jak? Po pierwsze, pytanie jest takie, w szczególności jeżeli faktycznie odstajesz i zrobisz to szybciej, co właśnie to powoduje? Czyli jak mogę pomóc, żeby inni byli w stanie to zrobić tak samo szybko? I to jest taka pierwsza rzecz, która jest istotna. A drugie, co powoduje też, że inni zrobią to wolniej? Czy to jest właśnie brak kontekstu, toolingu, wiedzy, strach przed zmianą? I teraz tak, jak popatrzymy, to nie powinno być pytanie z tego retorycznego narzekania. Można faktycznie zamienić to na takie pytanie diagnostyczne i zobaczyć, jeżeli uczciwie do tego podejdziemy, co w ogóle to powoduje?

Szymon Warda: To ja mam inne podejście do tego zupełnie, bo prawda jest taka, że im wyżej jesteśmy w strukturze organizacji i od tematu, im dłużej jesteśmy, to też zatracamy ten cały scope co się dzieje, zatracamy realne możliwości oszacowania. Problemy się upraszczają. To doskonale też zdajesz sobie z tego sprawę, że to jest taka, patrzymy naiwnie, że to będzie proste. Tak, tylko musimy pamiętać o tych wszystkich rzeczach, które trzeba dorzucić - dokumentacja, testy i tak dalej. Więc nie mówię, że Twoja wersja jest nieprawdziwa, bo jest jak najbardziej prawdziwa, tylko to jest skala szarości. Z drugiej strony, jest ta sytuacja, że będąc wyżej upraszczamy problemy, zapominamy o tym, co się dzieje i tak dalej, często widzimy funkcjonalność załóżmy jako coś nowego, a nie coś, co się musi integrować z czymś, co już istnieje. Więc to jest też praca nad sobą w kontekście, żeby zrozumieć, że pewne rzeczy trwają dłużej, bo taki jest scope, tak to wygląda i w takim systemie, świecie żyjemy. Więc to jest gdzieś środek, wypośrodkowanie tych dwóch elementów. Dobra, taka w ogóle jest ciekawa analogia, tutaj była. Kiedyś właśnie jak pisano NTFS-a w Microsofcie, to Bill Gates przyszedł i powiedział, że on napisał Fat32 chyba w 8 godzin lecąc samolotem i dostał prostą odpowiedź: no to teraz zrób to ponownie. I to był koniec dyskusji odnośnie czasu. Dwa inne problemy, dwa inne systemy, nie wtrącamy się za bardzo. Dobra, to ja taki prosty temat odnośnie mentoringu, bo to jest taki częsty obszar, bo Ty zacząłeś mówić o tym, że pomóżmy i tak dalej. Wchodzimy w prosty mentoring. Mentoringiem jest bardzo prosta sytuacja. Mentorować można w nieskończoność. Mentoring jest potrzebny, ale też trzeba policzyć kiedy to się opłaca i dla kogo to się bardzo mocno opłaca, w sensie jaki będzie zwrot z tej inwestycji, bo każdego może zamentorować. Trzeba też dobrać odpowiedni sposób mentoringu, mianowicie tego, że podsuwamy kolejne pytania, prowadzimy, a nie mówimy, jak jest. I to jest kolejny etap, który się łączy z tym, to trzeba wiedzieć, kiedy to uciąć i powiedzieć, że sorry, nie, bo niestety nie możemy pomagać w kółko. Jak przy każdej czynności w organizacji musimy policzyć zwrot z tej inwestycji, którą będziemy właśnie wykonywali. Niemiłe, ale prawdziwe.

Łukasz Kałużny: Niemiłe, tak, tak. To dobrze też chyba to spisałaś, co widzę, że ludzie nie wybierają, ten, nie umie versus nie chce versus nie może.

Szymon Warda: Tak, dokładnie. Nie oszukujmy się, to jest punkt, który Ty masz widzę, że w kolejnym punkcie.

Łukasz Kałużny: Tak.

Szymon Warda: Żyjemy w pewnej bańce. Tak to niestety wygląda. Tyle.

Łukasz Kałużny: Ja rzucę takie trzy swoje myśli, które się tutaj łączą o tym wszystkim. Po pierwsze, jeżeli słuchacie tego podcastu, prawdopodobnie albo zadajecie to pytanie na Discordzie, udzielacie się w jakimś community, żyjecie w bańce i jesteście bardzo niereprezentatywną próbką osób pracujących obecnie w IT. To jest taka rzecz, którą trzeba sobie uświadomić. I jak na to popatrzymy, to przypominam statystykę, rozkład normalny, jak wygląda i prawdopodobnie jesteście w tej drugiej połowie po prawej stronie tego rozkładu, jeżeli chodzi o Wasze kompetencje i to, co robicie. I teraz to, co trzeba sobie bardzo mocno uświadomić, ja mówię, że skończyły się czasy romantycznego IT, romantyzowania IT, to jest taka sama praca jak każda inna, że jest ona 9-17 i ludzie chcą wrócić do swojego życia. Ba, nie zapominajmy o tym, że dążymy, większość osób dąży do jak najmniej, jak najbardziej minimalnego nakładu pracy i wydatkowania energii tym co robimy.

Szymon Warda: Raczej punkt może, że to jest praca jak każda, od 9:00 do 17:00 - tak, to jest prawda. I dla samego zdrowia, życia, balansu jakiegokolwiek, które byśmy chcieli, generalnie trzymajmy się tego. To nie znaczy, że nie mamy się edukować i tak dalej, bo to jest jak najbardziej zdrowe i ci, którzy chcą, jak najbardziej i oni będą, a przynajmniej powinni być docenieni w tym temacie. Nie możemy jednak oczekiwać od tego, że wszyscy tak będą wchodzili, wszyscy będą w tym trybie. Ludzie po prostu niektórzy chcą pracować całkowicie normalnie i tyle. To nie jest ich hobby, to nie jest ich styl życia.

Łukasz Kałużny: I jak popatrzymy, jest w tym jedna rzecz właśnie z tą pracą 9-17, to przez post Piotrka Stappa na LinkedInie trafiłem na, i Piotrek to dobrze podsumował bardzo krótko - tweet Daxa, rada twórcy OpenCode i paru innych wcześniej projektów, że znowu mamy coś w techu, co pozwala nam być super produktywnym, 10 razy productivity zwiększyć. Ale z drugiej strony pozwala zmniejszyć wkład naszej energii o połowę.

Szymon Warda: Wiesz co, miałem o tym rozmowę właśnie wczoraj nawet. To, co dają LLM-y do kodowania jest niewyobrażalnym zyskiem, boosterem dla osób, które wiedzą jak z nich korzystać, które wiedzą, jakie zadawać pytania i tak dalej. Dla seniorów, osób, które już są w pewnym obszarze, że tak powiem, wiedzy. Dla osób, które nie umieją, to nie będzie mnożnik razy 10, to nie będzie mnożnik razy 2, to będzie często potykanie się o własny kawałek, o własne nogi.

Łukasz Kałużny: A to już jest inny element.

Szymon Warda: Tak. Dobra, czyli teraz wystawiasz mnie na ten niemiły temat, mianowicie kiedy zwalniać? No dobra, to teraz…

Łukasz Kałużny: A ponoć ktoś mi zarzucił, że to ja jestem chamem. Odczarujemy to.

Szymon Warda: Dobrze, w takim razie w tym kierunku ta dyskusja idzie. Niech będzie, dobra. Ja powiem coś bardzo niemiłego, ale o czym wszyscy chyba powinni wiedzieć, a przynajmniej ludzie, którzy kierowali zespołem, a na pewno za zespół odpowiadali - trzeba zwalniać i trzeba nauczyć się zwalniać. Sorry, nie raz mówiliśmy o badaniach, o tym co trzyma ludzi w pracy i prawie zawsze to ludzi trzyma w pracy środowisko, w którym są, jak się obracają, trzyma ich zespół i tak dalej. Jeżeli, teraz wracając do mentoringu, jeżeli będziemy mieli w zespole osobę, którą będziemy mentorowali ponad jej możliwości albo ponad jej chęci, to w sumie jest obojętne, bo oceniamy po wynikach jak to wygląda, to nam się nie zepnie. To wprowadza pewną toksyczność. Po prostu tak to wygląda. Moja jeszcze taka jest jedna rzecz, że ja mam takie podejście, że często powiedzenie osobie, że rozstańmy się w tym kontekście, jest ułatwieniem dla obydwu stron. Ja nie raz miałem takie sytuacje, że załóżmy osobom, którym powiedziałem: to nie zadziała po prostu, po jakimś czasie było ok, dzięki, to było, to było dobre, bo tam się nie odnajdywałem. Więcej stresu niż było zysku. Tak że tak. Osoby, które odstają od zespołu, wprowadzają pewną toksyczność, odbijają, jest to po prostu tracenie czasu. Mówiąc kolejne, znowu patrząc na zwrot z inwestycji, też musimy zastanowić się, że za te finanse, które na te osoby wydajemy, co możemy zyskać? Jakie możliwości? Też jest nasz element odpowiedzialności, w zależności oczywiście od stanowiska. I to trzeba o tym myśleć. Żeby nie było, żeby nie być wrednym, wredną cholerą, to jest to, że to nie jest tak, że zwalniamy z dnia na dzień. To jest, jednakże to musi być poparte jakimś planem, musi być poparte jakimiś próbami naprawy, wdrożeniem, sprawdzeniem jak ta osoba się ma, diagnozą, z czego wynika problem. To nie może być widzimisię, tak to nie działa, że tak powiem.

Łukasz Kałużny: Jeszcze jest jeden taki problem. To jest dłuższy temat chyba, który poruszymy, ale też pytanie o tej toksyczności, jak powiedziałeś, i osób za bardzo kompetentnych, które próbują zawłaszczyć decyzyjność i jedyną słuszną drogę. I to jest bardzo ciężka rzecz.

Szymon Warda: Bo mówisz o prawej stronie Gaussa. To jest bardzo ryzykowne.

Łukasz Kałużny: Tak, dokładnie, to jest tak, bardzo ryzykowne, bo bardzo często i to jest taka rzecz, przez którą albo w IT wyrastamy z tego problemu i dojrzewamy, albo w nim zostajemy. Czyli to jest taka rzecz, że ludzie, są osoby, które kochają zostać single point of failure, że uzasadniają całą bytność zespołu od siebie. Ten system to jestem ja, więc ja podejmuję decyzję, to jest moje dziecko. Jest dużo takich rzeczy, które pokazują. I to jest pytanie na przykład, tak jak Kuba zadał właśnie, że zrobiłbym to szybciej, to jest trochę pytanie z czego to, właśnie, z czego to wynika.

Szymon Warda: Wiesz co, single point of failure często mogą być większym ryzykiem, jeżeli nie są zarządzani odpowiednio, niż osoby, które nie wyrabiają, są gorsze. Prawa strona może być większym zagrożeniem niż lewa strona rozkładu Gaussa. I teraz czemu? Prawa strona, pojawienie się tych single point of failure, super developerów i tak dalej, bardzo rozleniwia, bo możemy na nich polegać i tak dalej, i tak dalej. Ci ludzie się często mogą szybko wypalać, po prostu, bo się męczą, że oni cały czas ciągną, reszta nie wyrabia. To jest bardzo ryzykowne, trzeba tym zarządzić. Jak oni znikną, to wiadomo gdzie jesteśmy. Narzucają często, bo oni chcą, bo oni mają możliwości, ale nie rozumieją często, że zespół nie ma tych możliwości, albo zespół nawet nie chce, albo nawet nie ma potrzeby użycia tych nowych technologii i tak dalej i reszcie przez to reszta się nie wyrabia. I nagle mamy zamiast Gaussa ładnego, to nagle mamy taką górkę po lewej, dołek w środku i lekką górkę po prawej przez to, że przesunęliśmy to wszystko. Więc to single point of failures są w wersji niezarządzonej, a często są niezarządzeni, bo po prostu to nas rozleniwia, ktoś coś ogarnia.

Łukasz Kałużny: To się opłaca.

Szymon Warda: Krótkofalowo się opłaca.

Łukasz Kałużny: Tak i polecam tutaj wrócić do książki, która jest wyświechtana, ale może czytaliście, może nie do projektu Feniks, bo tam jest jedna z dobrych instrukcji obsługi tego przypadku.

Szymon Warda: Wiesz co, to jest taka, że łatwo mieć instrukcję…

Łukasz Kałużny: Raczej inaczej…

Szymon Warda: Bardzo ciężko jest to wdrożyć w życie, bo to rozleniwia. I ciężko jest ogarnąć gwiazdę.

Łukasz Kałużny: I tam jest pokazany ten problem właśnie. Dlatego mówię, że to jest, pokazuje i problemy się pokazują jak bardzo zwalniają pewne rzeczy jak odcinasz, zaczynasz usuwać wiedzę plemienną.

Szymon Warda: Tak. Żeby nie było to gołosłowne, że spofy są takimi, że super, że są problematyczni i tak dalej. To nie jest to, że ich wyrzucamy. To jest kwestia kilku rzeczy, takie rzeczy, które można zrobić. To jest po pierwsze, to jest mentoring. Będą ludzie, którym będzie się chciało, więc będą świetni do mentoringu. To będą rzeczy odnośnie wymyślenia, jak dać, żeby dać im, kwestia dać odpowiedni problem, że jak na przykład mamy problem taki typu na przykład nie wyrabiamy się z tym, albo na przykład to nas kosztuje dużo, to jest kwestia, to są ludzie, którzy lubią bardzo rozwiązywać zagadki, problemy. Więc to jest kwestia oddania im odpowiedniej zagadki, odpowiedniego problemu, który finalnie przyspieszy cały zespół, zmniejszy nasz koszt i pociągnie wszystkich pozostałych i tak dalej. To mogą być jakieś szkolenia, to mogą być pokazywania, to mogą być masę, masę rzeczy. To jest kwestia, zarządzanie takimi świetnymi developerami to jest duża odpowiedzialność właśnie lidera i na nim polega to, żeby to działało dobrze.

Łukasz Kałużny: Wiesz co, to tak, ja bym to tak rzucił właśnie, że te osoby z prawej strony zawsze będą krzyczeć najgłośniej.

Szymon Warda: Tak, ale tym trzeba po prostu zarządzić odpowiednio.

Łukasz Kałużny: Tak. I druga sprawa jak właśnie popatrzymy sobie, to co rzuciłeś na temat wykorzystania tej wiedzy, to jedno, to jest trochę przejść do części, które zaraz pewnie tam widziałem w moich notatkach w architekturze, to jest pierwsza rzecz - planowanie zespołowe. I teraz jest taka rzecz, której część osób by mnie powiesiła za to, że w ogóle użyję tego stwierdzenia. Część osób uważa to za świetny czas na nicnierobienie, czyli sławetne planowanie w postaci Scrum pokera. I większość uważa to za stratę czasu, bo większość jak widziałem jak jest to robione, jest to stratą czasu, bo cała wartość, która się kryje i tutaj w kontekście też tego problemu, to są outlinery.

Szymon Warda: Tak, mianowicie, że ktoś mówi 2, a ktoś ktoś mówi 15.

Łukasz Kałużny: Tak. I to są outlinery. I jest zawsze ten, zawsze jest pytanie: czemu ktoś tak bardzo to skraca? A czemu ktoś tak bardzo to wydłuża? I odrzućmy teraz przypadki patologiczne, które są, po prostu wykorzystujemy to jako narzędzie, żeby się nie przepracowywać, bo takie rzeczy też się zdarzają.

Szymon Warda: Jak ładnie to ująłeś.

Łukasz Kałużny: Są zespoły, które wykorzystują to dosłownie… Inaczej, to nie są miejskie legendy. Prawdopodobnie słuchacze mieli okazję widzieć, słyszeć od znajomych, że są zespoły, które to jawnie wykorzystywały, żeby wydłużyć. Ale to nie jest ten moment. I teraz trzeba popatrzeć sobie i w tym miejscu na te outlinery trzeba sobie popatrzeć na wiele elementów. Zacznijmy od personalnych. Czy to jest właśnie doświadczenie? Jak bardzo te doświadczenie czyjeś skraca to? Czy to jest wiedza plemienna i na przykład te osoby nie posiadają, które powiedziały, że tyle to zajmie, nie posiadają tej wiedzy plemiennej? Z drugiej strony to jest też taka rzecz, że brak świadomości do końca własnego poziomu versus reszta zespołu, że nadal podświadomie to jest czemu tak długo, czemu tak długo, nie patrząc tak naprawdę na kontekst, że to ja za szybko dowożę, bo też tak może być.

Szymon Warda: Albo zakres tego, co dowożę, jest bardziej obcięty, tak nazwijmy to delikatnie.

Łukasz Kałużny: Też może to być w tym. I kolejna rzecz w całości i to jest rzecz techniczna, która jest bardzo problematyczna, ale bardzo często developer experience w projektach promuje w tym, bardzo często jest odkładany na półkę i nie robiony i promuje na przykład osoby, które długo siedzą w danym projekcie, zagadnieniu. Ułatwia to, ułatwia życie. I ten próg wejścia w niektórych rzeczach jest, potrafi być bardzo, bardzo, ten próg potem w jakimś temacie potrafi być bardzo wysoki, bo ktoś ma, na przykład sobie siedzi cicho i nie podzielił się swoimi skryptami, toolingiem i innymi rzeczami. Widziałeś to też przecież niejednokrotnie, rzeczy wyciągane zza pazuchy, że a bo ja robię szybciej, bo ja sobie tak tutaj ułatwiłem życie.

Szymon Warda: Bywa. Ja jeszcze jedna rzecz odnośnie całego pokera, bo to jest temat trudny, szczególnie przy systemach, które są na przykład utrzymywane albo właśnie o tym, co Ty mówiłeś, że są osoby z dużą wiedzą plemienną, dużą wiedzą domenową, którą często w ogóle nie da rady w żaden sposób rozproszyć. I pytanie teraz właśnie co zrobić? Czy faktycznie zrobić tak jak Scrum mówi, że dowolny task bierze dowolna osoba i w tym momencie narażamy się na rozrzut między dzień-8 dni. I to czasami bywa lekką ręką jeszcze z mentoringiem.

Łukasz Kałużny: Mówić o gwiazdkach, punktach.

Szymon Warda: Rozmiary koszulek Łukasz, to są rozmiary koszulek, tego w ogóle nie ogarniałem nigdy. Czy to jednak jakoś balansować? I tu szczerze mówiąc, nie ma dobrego rozwiązania tak naprawdę. Bo ta szczytna idea, że wszyscy losują sobie co kto chce bierze, przy większych systemach to będzie bardziej złożone, a przy większej logice, bardziej złożonej się po prostu nie sprawdza do końca. To jest kwestia bardziej balansowania między kilkoma osobami, a nie między dowolną osobą z dowolnego zespołu niemalże, bo tak to nie zadziała. Wiesz co, jeszcze jak mówimy o całości, to ja bym zahaczył jeszcze o jedną rzecz, bo ona fajnie zahacza o temat właśnie osób po prawej stronie i planowania. To jest complexity budget, czyli nasz budżet na złożoność tego systemu. To jest super ważne, bo często wprowadzamy sobie rzeczy, które nam zjadają ten budżet, wprowadzamy sobie rozwiązania. I to jest zawsze dyskusja o tym, czy my tego potrzebujemy, czy my chcemy się bawić i czy ważne jeszcze, chyba najważniejsze z tego wszystkiego, czy mamy na to czas? Często właśnie osoby po prawej stronie będą właśnie; okej, spróbujmy tego, spróbujmy tego, spróbujmy tego, spróbujmy tego. Super, część z tych rozwiązań jak najbardziej ma sens. Część jest po prostu zabawkami, która obniży możliwość i to całe velocity, wydajność tego zespołu i to się po prostu na koniec nie zepnie. Jak chcemy w projekt wdrażać od razu Kubernetesa, Secure RSA, event sourcing, przepraszam Cię Oskar, to w tym momencie to się po prostu nie zepnie.

Łukasz Kałużny: Inaczej, tak, mówisz o bingo CV-kowym.

Szymon Warda: Tak, według mnie to jest coś, co generalnie, na co nie patrzy się w kontekście podejmowania decyzji często. To jest takie: miejmy, bo to ma sens. Ok, może ma sens, ale nie mamy na to czasu.

Łukasz Kałużny: Znaczy inaczej, teraz w zależności, bo nie było czy był to kontekst projektu, istniejącego projektu. Ale jak popatrzymy, istotną rzeczą, projektujemy rozwiązanie poniżej średniej naszego zespołu.

Szymon Warda: Albo w okolice średniej zespołu.

Łukasz Kałużny: Albo w okolicy średniej kompetencji naszego zespołu. I trzeba się z tym pogodzić.

Szymon Warda: Tak i też planujemy więcej średniej i też w ramach, podkreślę ponownie to, czasu, żeby się wyrobić. Każda nowa rzecz to jest jakieś ryzyko, które może nas kopnąć, jak nie teraz, to za jakiś czas i tak dalej.

Łukasz Kałużny: I kompetencje, dostępne kompetencje, to jest w ogóle rzecz, która chyba najbardziej jest… Mam wrażenie, że przy architekturze dostępne kompetencje jest największym ograniczeniem, które jest nie brane często pod uwagę.

Szymon Warda: Łukasz, ale to jest prosta opcja. Ktoś mówi załóżmy: o, to użyjmy Secure RSA. A ktoś mówi: nie znam. To tamta osoba mówi: to ja Ci wyślę reprezentację, to zobaczysz. Śmiejesz się, bo wiesz, że tak to wygląda.

Łukasz Kałużny: Ja wiem, 2014/15, wiem, o czym mówisz.

Szymon Warda: Tak że tak to naprawdę jest, nie patrzenie też na całość. I to jest w pewnym momencie też powinność lidera, nie patrzenie na całościowy koszt złożoności, którą wdrażamy. Użyjmy Kafkę, potem musimy ją utrzymać, monitorować i tak dalej, i tak dalej. Więc to jest okrutne. Dobra, idziemy kolejna rzecz, jak już ciągniemy, to jest patrzenie na systemy naiwnie bym powiedział. Mamy prawo Conwaya, mamy rzeczy, decyzje odnośnie budowania kontra kupowania kontra brania czegoś z gotowego, albo wybór serwisów zarządzanych, wybór własnych i tak dalej. To są decyzje gdzie zespół daje wkład, lider albo ktoś wyżej podejmuje te decyzje jak to wygląda. Bo to są często decyzje quasi polityczne w kontekście tego, co organizacja wybiera i jak chce być zarządzana, w kontekście kto będzie to utrzymywał, jakie jest wsparcie z organizacji, jak jest biznes podzielony i tak dalej, i tak dalej. Często wpychamy się w rzeczy, które są głupie, można śmiało powiedzieć, w jakieś utrzymanie albo: bo Kafka jest prosta w utrzymaniu. I jak chodzi na Twoim local hoście, to może tak, ale jak odpala, chodzi w Scali, po dwóch latach, kiedy już tam trochę danych jest, to już nie jest taka prosta. To wszystko kosztuje. Jakieś tam koszty, kamyczki się zbierają do aż dużo większego kamienia, że tak powiem. To jest super ważne, przeoczane i często przez, często też promowane przez tych ludzi właśnie po prawej stronie. Oni są świetni, tylko kwestia doboru i większej widoczności jak podejmujemy te decyzje. Zamilkłeś.

Łukasz Kałużny: Wiesz co, nie… Inaczej, słuchaj, to jest ten smutny moment, kiedy muszę się z Tobą w niektórych miejscach zgodzić w tym i poklepać po pleckach. Ale tak, chyba tak, dwie rzeczy… Raczej inaczej, im dalej w las, tym prawo Conwaya jest najbardziej problematyczną rzeczą. Jak sobie zobaczymy, jakie są tam psychologiczne, socjologiczne, jak się układamy w struktury w organizacjach, co czym rządzi, to ta cała nielogiczność, którą byśmy chcieli rozumieć, czyli chcielibyśmy, żeby organizacja była logiczna, zapomnijmy, że takie coś jest w ogóle możliwe. Ja bym teraz taką rzeczą, że trzeba się, na pytanie takie Kuby, trzeba zrobić jedną rzecz - pogodzić się z pewnymi rzeczami. W sensie inaczej, teraz to jest ważna rzecz, okej, możemy dążyć do przodu, robić to lepiej, ale trzeba się z tym pogodzić, że zespół dowozi wolniej niż Ty, zrobi to gorzej niż Ty…

Szymon Warda: Czekaj, to jest ważne, zespół dowozi wolniej niż Tobie się wydaje, że dowiezie.

Łukasz Kałużny: Tak.

Szymon Warda: Tak, ale Ty masz 8 godzin w pracy, załóżmy nawet 12. Nie dowieziesz wszystkiego. To jest bardzo ważne.

Łukasz Kałużny: Tak, w tym, ale i w ogóle jak sobie popatrzymy teraz na całość, to jest cena, którą płacisz za te pogodzenie się. To daje Ci w pewnym momencie skalowalność. To jest taka rzecz, że jedną z tych elementów, wyrzucenie tego perfekcjonizmu, bo to prawdopodobnie było też u Kuby, zaczyna Ci powodować to, że możesz się skalować i przez to potem powoduje Ci, będzie jak będzie, ale braki właśnie single point of failure, możliwość wzięcia spokojnego urlopu.

Szymon Warda: Znaczy ja tu zacytuję takiego jednego ziomka. Może go znacie? Good enough - wystarczy. Łukasz, o Tobie mowa. To jest prawdziwe bardzo, tak, tak, tak, to jest absolutnie prawdziwe. Nie musi być perfekcja. To good enough jest złotym środkiem w kontekście tego, że działa, jest dobrze, nie musi być wypucowane. I to jest też dobre wejście do architektury rewolucyjnej, że nie będziemy mieli smutku, żeby to wyrzucić, jak nie będzie potrzebne. I to zarabia, w sensie jak najszybciej dostarczamy wartość i jest okej.

Łukasz Kałużny: Tak, tylko słuchaj, droga od “zrobiłbym to lepiej” albo “jeszcze muszę nad tym popracować” do good enough to jest bardzo długa droga, wiesz o tym Szymon. Mentalnie jest to…

Szymon Warda: Jest bardzo długa. Znaczy to nie jest droga, to jest ciągły proces. To nie jest tak, że przejdziesz to raz i już jestem po drugiej stronie tego mostu.

Łukasz Kałużny: Nie, nie. Potem wracasz i słuchajcie, zupełnie z doświadczenia, wracasz do punktu zero, że chcesz coś znowu zrobić - dobra, trzeba się z tym pogodzić, lecimy dalej.

Szymon Warda: Dla mnie jest jeszcze jeden punkt odnośnie good enough, bo to jest jeszcze odnośnie delegowania, bo to jest pogodzenie się, że ktoś robi inaczej niż Tobie się uważa, niż Ty uważasz, że powinno być zrobione.

Łukasz Kałużny: Ja wiem, ale to jest…

Szymon Warda: To jest trudne, ale trzeba powiedzieć, bo to jest taka opcja, to jest jedna z rzeczy, którą wydaje mi się, że złapałem dość szybko generalnie z zespołami, to jest to, żeby powiedzieć ok, jak narzucisz decyzję komuś, to on będzie to wykonywał jak żołnierze: ktoś mi powiedział, żeby tak zrobić, to to zrobię. Myślenie jest wyłączone. Jak pozwolisz człowiekowi, że taki typowo ownership tej decyzji, że on będzie to dowoził i tak dalej, to on będzie myślał jak to zrobić, na zmiany w ekosystemie wokół tej decyzji będzie reagował lepiej i będzie próbował zrobić, żeby to zadziałało. Oczywiście do pewnych limitów, (…) inteligentny. Ale lepiej jest dać komuś ownership, niż narzucić może lepszą decyzję, bo ona nie zadziała.

Łukasz Kałużny: Tak i to jest w ogóle… Inaczej, to jest rzecz, z którą ja na przykład zacząłem się godzić dopiero jak otworzyliśmy firmę, tak realnie, że… Inaczej, rozumiałem te mechanizmy, tłumaczyłem je ludziom, ale jest problem największy zastosować te same mechanizmy u siebie.

Szymon Warda: Jest to trudne, ale trzeba wiedzieć po prostu co.

Łukasz Kałużny: Kiedy to jest Twój temat, tak, Twój temat. Trzeba być świadomym, że jako konsultantowi o wiele prościej na przykład ze względu i to jest taka ciekawa rzecz, którą teraz sobie uświadomiłem, w tym momencie, jak to nagrywamy, że w tej roli konsultanckiej, doradczej, jako że Tobie nie zależy, to jest bardzo ważne, czujesz ten ownership chwilowy, ale Tobie nie zależy, łatwiej Ci z boku powiedzieć, że uprośćcie, to będzie w tym. Jest to gorzej niż robisz coś dla siebie.

Szymon Warda: Zgadza się. Odnośnie tego właśnie delegowania decyzji i mówienia o decyzji - krytyczne: bardziej naciskaj. Jak coś nie ma większego znaczenia odnośnie jak będą ADR-y wyglądały, jak będziemy dokumentację wystawiali i tak dalej, niech ludzie podejmują decyzje. Naprawdę o pewne bitwy nie warto w ogóle do nich podchodzić.

Łukasz Kałużny: Tak, przy czym jest teraz jedna bardzo ważna rzecz, trzeba powiedzieć… Są dwie rzeczy: albo dokonać mentoringu albo coachingu, tudzież mentoringu, albo mikrozarządzania, kiedy idzie to naprawdę w złą stronę, albo zaczyna iść w przerostem. Bo też ludzie niekiedy przy wolnej ręce potrafią skomplikować. To też trzeba mieć tego świadomość.

Szymon Warda: Trzeba pilnować. To jest ta kwestia, tak, zgadza się, to kwestia mentoringu, czy patrzenia, jak to wygląda i tak dalej. I raczej ciągnięcie w kierunku upraszczania, a nie komplikowania, bo zespół sam z siebie będzie chciał często to bardziej skomplikować. A rola lidera jest też taka, że zna trochę szerszy kontekst, zna czas, zna budżety, zna…

Łukasz Kałużny: Politykę.

Szymon Warda: Politykę, ekosystem biznesowy można tak powiedzieć. Zgadza się jak najbardziej.

Łukasz Kałużny: Ja bym tutaj przy tych ADR-ach jeszcze na sekundkę na koniec wrócił, że w zespołach technicznych nie przerośnięte ADR-y, bo to jest to, co na przykład się pojawia na szkoleniach, na tym moim szkoleniu Architektura 101, że ludzie zaczęli implementować ADR-y albo jako bardzo przerośnięty proces, albo próbują robić to do wszystkiego. Trzeba znaleźć sweet spot, co jest ten, co jest zmianą architektoniczną i zrozumieć, że to są tylko rzeczy, które są długofalowe. Ale powiedzmy, że już okroiliśmy te ADR-y z całego, że tak powiem, naleciałości, działają prawidłowo. ADR, jeżeli delegujecie ten task, on będzie świetną rzeczą do mentoringu i zadawania pytań. Pytanie dlaczego? Jak? I to jest takie miejsce, które naturalnie, to jest taki next level po code review, w którym można pomóc rozwijać innych członków zespołu.

Szymon Warda: Tak, choć droga tu może być długa z tego powodu, że niestety ADR-y nie są łatwe i często idziemy tam w dogmatyzm. Ale to już chyba rozmowa na inną okazję, że tak powiem.

Łukasz Kałużny: Trzeba będzie odświeżyć odcinek o ADR-ach w ogóle, teraz tak wpadło mi do głowy i zerknąć, co wtedy mówiliśmy. Słuchaj, jakaś taka myśl Szymon Twoja na koniec?

Szymon Warda: To jest bilansowanie. To jest chyba podsumowanie. Dobre jest to, co mówiliśmy, że to nie jest czarno białe. To nie jest tak, że zespół, że Ty byś zrobił to szybciej, bo tak pewnie też nie jest całkowicie jak Ci się wydaje. A z drugiej strony generalnie też ten obszar, patrzenie jak zrobić, żeby jednak ludzie robili szybciej, to jest cały czas bilansowanie. Skala szarości, jesteśmy gdzieś pomiędzy niej tak naprawdę i o tym trzeba bardzo mocno pamiętać. Z mojej strony taki wniosek.

Łukasz Kałużny: Tak, a ja przy tym rzucę, w zależności w jakiej jesteś roli, czy lidera tego zespołu, czy jesteś tym seniorem w zespole, który zrobiłby to szybciej, to jest moment, żeby zająć się tą pozycją seniorską i zastanowić się, jak swoje kompetencje przełożyć, żeby zespół też tak umiał. I to jest ten moment, kiedy to jest chyba rzecz, która odróżnia regulara od seniora, że dla mnie senior to nie jest osoba, która będzie już klepała kod, ale rozwiązuje problemy i pomaga również z resztą zespołu.

Szymon Warda: A w takim razie definicja, idziemy dalej. Lider to jest osoba, która umie dobrać rozwiązanie do tego, co można realnie wykonać i co zespół realnie dostarczy. Czyli patrzenie co możemy i zarządzanie właśnie tym complexity budget.

Łukasz Kałużny: Dajcie znać jak się podobał odcinek i miłego dnia.

Szymon Warda: Miłego, na razie. Hej.

Łukasz Kałużny: Hej!