Systemy IT się psują. Co z tego wynika i czego nas to uczy. Gość: Adam Korga - POIT 313

Witam w trzysta trzynastym podcastu „Porozmawiajmy o IT”. Tematem dzisiejszej rozmowy jest to, że systemy IT się psują i czego możemy jako branża się z tego nauczyć.

Dziś moimi gościem jest Adam Korga – autor satyrycznego IT Dictionary. Od niemal dwóch dekad przechodzi przez kolejne szczeble technicznej drabiny: od programisty, przez architekta, po Engineering Managera. Po zebraniu i opisaniu branżowych absurdów, tym razem bierze na warsztat znacznie poważniejszy temat: błędy i katastrofy w IT. Analizuje momenty, w których systemy zawodzą, i sprawdza, czego jako branża możemy się z nich nauczyć, by zamiast szukać winnych, budować realną odporność systemów i zespołów.

W tym odcinku o błędach w IT rozmawiamy w następujących kontekstach:

• nauka z awarii jako bardziej wiarygodne źródło wiedzy niż success stories
• ograniczenia „success stories” i ich niska replikowalność w realnych projektach
• świadomość zawodności systemów w IT i dojrzałość organizacji w uczeniu się na błędach
• błąd przeżywalności (survivorship bias) i jego wpływ na decyzje technologiczne
• znaczenie kultury blameless post-mortem dla budowania odporności organizacji
• dlaczego szukanie winnego blokuje realne uczenie się na błędach
• root cause analysis jako analiza systemowa, wykraczająca poza samą technologię
• technika 5-Why jako narzędzie docierania do źródeł problemów organizacyjnych
• trudność projektowania prostych rozwiązań i rola zrozumienia problemu
• iluzja wiedzy i problem z prostym tłumaczeniem złożonych zagadnień
• automatyzacja jako wzmacniacz ludzkich błędów i skrótów myślowych
• wpływ AI na naturę błędów w IT oraz nowe wyzwania w ich analizie

Subskrypcja podcastu:

• zasubskrybuj w Apple Podcasts, Spreaker, Sticher, Spotify, przez RSS, lub Twoją ulubioną aplikację do podcastów na smartphonie (wyszukaj frazę „Porozmawiajmy o IT”)
• poproszę Cię też o polubienie fanpage na Facebooku

Linki:

• Profil Adama na LinkedIn – https://www.linkedin.com/company/adam-korga/
• Strona domowa – https://adamkorga.com/
• Wcześniejszy odcinek z Adamem o humorze w IT – https://porozmawiajmyoit.pl/poit-299-humor-w-it/

Jeśli masz jakieś pytania lub komentarze, pisz do mnie śmiało na krzysztof@porozmawiajmyoit.pl

https://porozmawiajmyoit.pl/313

Transcript

SPEAKER_00 0:00

To jest 313 odcinek Rozmawiajm IT. Dzisiaj rozmawiamy o tym, że systemy IT się psują i o tym,

Wprowadzenie do błędów w IT

SPEAKER_00 0:06

czego nas toczy. Dotatkiem o linki i transkrypcjami znajdziesz na porozmawiajmy IT.plammanne na 313. Jeśli myślisz o zmianie pracy, albo po prostu masz dość kliknienia dalej na ogłoszenia bez fidełek, to zajrzyj na stolety Jobs. Tam wszystko jest na tacy wynagrodzenia technologie projekty bez zgadywania. Nazywam się Krzysztof Kępiński i tworzą ten podcast napisałem też książkę Markowist IT. Jeśli lubisz ten podcast, udostępnij ten odcinek dalej, albo zostaw od cenny w swojej japcie. To jest dla mnie nieoceniona pomoc. A teraz odpalamy. Cześć mój dzisiejszy gość to autor satyrcznego IT Dictionary. Od niemal dwóch dekad przechodzi przez kolejne szczeble techniczne i drabiny od programisty, przez architekta po engineering managera. Po zebraniu opisaniu branżowych absturdów tym razem bierze na warsztat znacznie poważniejszy temat błędy katastrofy w IT. Analizuje momenty, w których systemy zawodzą i sprawdza, czego jako branża możemy się z tego nauczyć, by zamiast szukać winnych, budować realną odporność systemów i zespołów. Moim waszym gościem po raz drugi jest Adam Kolega. Cześć Adam, bardzo miło mi gościcie w podcaście.

SPEAKER_01 1:17

Cześć, miło być znowu i mam nadzieję, że coś ciekawego z tego wyjdzie.

SPEAKER_00 1:22

Ostatnio rozmawialiśmy pół roku temu o nieco lżejszym temacie, bo to był humor w IT, było troszkę żartów, troszkę śmiechu, ale też poważnej treści jak najbardziej, ponieważ z naszej rozmowy wysło, że ten humor ma jednak jakieś określone

Czas na poważniejsze tematy

SPEAKER_00 1:39

znaczenie do tej rozmowy. Oczywiście również zapraszamy będzie ona dodatkę do tego odcinka podlinkowana. A dzisiaj rozmawiamy o temacie już poważniejszym. Mówimy, będziemy mówić o tym, że system IT się psują i czy my jako branża coś z tego wyciągamy, czy się uczymy, czy coś nam w ogóle ta wiedza daje. Więc potrzebny temat jakby nie było, ale rozpoczniemy sobie standardowo, może dla tych, którzy tej naszej pierwszej rozmowy nie słyszeli, czyli od tego, czy słuchasz podcastów, może jakieś ciekawe audycje zasugerujesz.

SPEAKER_01 2:16

Tak jak ostatnio powiedziałem, nie słucham tak dużo podcastów, po części brak czasu, po części jak jakoś wolę, jestem zdrokowcą, więc jeśli chodzi o ciekawe informacje, to więcej zapamiętuję czytając. Czasami dla rozryzki coś o grach, tu mogę polecić formogatka z jakiegoś powodu. I czasami też w ramach powiedzmy researchu, trochę anglojęzycznych, typu 1X deweloper, DWL printer. Nie mam pojęcia, skąd się to wiem. Znaczy wiem, skąd się to wziął, nie wiem, jak to pomagać. I parę innych. Ale generalnie tak jak mówię, jestem czrokowcem, więc nie jest to moja główna metoda spędzenia czasu.

SPEAKER_00 2:59

Tak, wiesz, jak sobie tak obserwujemy tą blogosferę i szeroko zmiane social media, no to pewnie każdy, kto to robi, to zauważy, że raczej mówi się o sukcesach, o tym, co się udało, o tym, jak bardzo to się przełożyło na jakieś realne rzeczy. Zapominamy trochę o tym, że mimo wszystko to nie jest komplet tego naszego życia, że wpadki, różne błędy, coś, co się nie udało, zdarza się pewnie zdecydowanie częściej. I tak samo też jest z tą naszą branżą. Lubimy mówić o sukcesach, lubimy mówić o tym, jak bardzo wpływamy na życie ludzi, ale rzadko kiedy wspominamy o tym, co tam się nie udało.

Wartość uczenia się na błędach

SPEAKER_00 3:45

No właśnie, czy według Ciebie mimo wszystko jednak uczenie się na tym, co nie wyszło, na błędach, na fuck-ach, na wpadkach jest wartościowsze niż czytanie sobie o sukcesach?

SPEAKER_01 3:56

Uważam, że jest zdecydowanie bardziej wartościowe, bo sukces ma to do siebie, że jest wypadkowo bardzo wielu czynników, z których nie wszystkie da się zreplikować, i nie wszystkie są nawet wymieniane w Sukcesh. Na pewno w sukcesie nie wiem, Netflixa, Facebooka czy innego Microsoftu nie zobaczymy stwierdzenia, a tak w sumie to mieliśmy szczęście, a nie oszukujmy się, ale to też jest istotny czynnik. Jeśli czytamy, nie wiem, Nike, usłyszymy historię o tym, że tam chyba ośmiu czy dziewięciu gości się spotkało, stwierdziło, że doit i wszystko poszło, ale już nie wspominają o realiach społecznych tego, że w latach 70. w stanie, o ile dobrze pamiętam Hajo albo Kochomo, ale nie cytujcie mnie z tego powodu. Samo to, żeby ktoś miał biznes plan i był, przepraszam, ale jednak biały, oznaczało, że banki otwierały portfele z miejsca. Teraz o tym nie przeczytamy tak łatwo, a to są istotne kryteria. Z tej perspektywy powtórzen sukcesu wcale nie jest takie proste, podczas gdy powtórzen błędu jest nieuniknione, jeżeli nie nauczymy się tego, co poszło nie tak. Co więcej, nawet psychologia sugeruje, że uczenie się na błędach jest jedną z najefektywniejszych metod uczenia się w ogóle. Możemy zrobić setki przykładów, nie wiem, z matematyki czy innej fizyki dobrze, ale analizując własne pomyłki, zapamiętamy dużo więcej. Analizując cudze pomyłki, troszkę mniej, ale jednak wciąż dużo. Bardzo fajnie o tym napisał chociażby Radek Kotarski w jego książce Włamcie do mózgu. Powiedzmy, że nauka na błędach cudzych po prostu jest tańsza, odrobina mniej efektywna, ale wciąż bardzo wartościowa i stąd po części moje skrzywienie w tym kierunku.

SPEAKER_00 5:53

Wszystko łącznie z nauką mówi nam, że faktycznie jest to efektywniejsze, jest to tańsze, że jakoś bardziej mam wrażenie skupiamy się w momencie, kiedy faktycznie analizujemy jakieś błędy, no tym bardziej się dostał nasze błędy, jesteśmy w stanie coś z tego wyciągnąć, niż czy właśnie spróbować powtórzyć, czy iść sukces, bo tak jak powiedziałeś, za nie może stać jeszcze mnóstwo innych czynników, na których, na które zwyczajnie nie mamy wpływu. Szczęście jest pewnie jednym z nich, to, że ktoś się pojawił w odpowiednim momencie, w odpowiednim czasie historycznym i tak dalej, i tak dalej, jest pewnie nie do powtórzenia. Natomiast to wcale nie znaczy, że na tej swojej drodze nie było tam mnóstwo błędów, mnóstwo problemów, mnóstwo porażek, z którymi te osoby musiały sobie poradzić.

Świadomość błędów w branży IT

SPEAKER_00 6:42

To nam mówi nauka, to namówi historia, ale czy wiesz, w tej naszej branży my jesteśmy świadomi tego, że faktycznie tak to działa, że błędy się zdarzają, że bagi w kodzie się zdarzają, że systemy się wysypują, że są zawodne, czy potrafimy się z tego w jakiś sposób czegoś nauczyć?

SPEAKER_01 7:01

I to jest ciekawe pytanie, bo chciałbym powiedzieć, że tak, bo jednak jednym z kluczowych elementów każdej organizacji są postmortem, analizę porażek. Wszyscy są świadomi, że trzeba to monitorować, reagować i tak dalej. Więc tak, w pewnym sensie branża się uczy. Najlepsze firmy na świecie robią to publicznie i to również lubię celebrować, szanuję i celebruję, kiedy widzę chociażby kolejny fuck-up w wykonaniu CloudFlow czy Amazonu, AWS-u jest ich trochę. Za każdym razem publicznie przyznają, co poszło nie tak, i robią publiczną analizę, to tak naprawdę buduję zaufanie, więc ogólnie branża powoli idzie do przodu. To, że czasami to, dlaczego mam pewne obiekcje, to może nie będę zagłębiał się od razu mi pytanie, ale czasami mam wrażenie, że jednak podobnie jak w świecie mody są nawroty pewnych trendów, tak, w IT pewne trendy również wracają i nagle doznajemy jako ogół branży zbiorowej

Powroty trendów w IT

SPEAKER_01 8:14

amnezji. Prostym przykładem obecnym jest chociażby mierzenie efektywności produkcji i oprogramowania. Z jakiegoś powodu zapomnieliśmy ostatnie dwie, dwie i pół dekady mówiące o tym, że linie kodu to nie jest najlepszy wyznacznik i wszyscy celebrują to, jak szybko możemy generować kod. Tak, uczymy się, ale też mamy tendencję do zapamiętania pewnych lekcji.

SPEAKER_00 8:36

Tak, to są pewnie jakieś cykle, jakieś takie faktycznie powtarzalne rzeczy, być może kwestia też pokoleniowa, że musimy się pewnej rzeczy jednak na nowo uczyć, pomimo tego, że pewnie sporo literatury, na ten temat jest, tak, że coś tam nie działa, że mnóstwo prób w tym kierunku poszło nie tak, ale z jakichś tam względów jest to dla nas, nie wiem, atrakcyjne znów i musimy się sami na własnej skórze przekonać o tym, że to nie działa. Wiesz, nawet próbuję to odwołać gdzieś tam do, że tak powiem, naszego pokolenia, które też pewnie mnóstwo błędów powtarzało tych błędów, które, nie wiem, z lat 60. 70. na początku rozwoju informatyki były poczynione, i my robiliśmy to samo, prawda?

SPEAKER_01 9:21

Ale tak naprawdę to możemy. To też jest jedna z lekcji, których ja się nauczyłem, że to wszystko jest to, co siedzi w naszej psychologii. Nie musimy patrzeć w historię informatyki, wystarczy popatrzeć na wymianę pokoleniową. Każde kolejne pokolenie ma tendencję do stwierdzenia, że my jesteśmy mądrzejsi niż nasi rodzice. Ja tak twierdziłem o moich rodzicach. To samo słyszę od swoich bratań czy innych członków rodziny, których wiek jeszcze nie kwalifikuje ich do trzymania paracetamolu. Więc. Podobne rzeczy. Niemal ten sam mechanizm widzimy w branży. Nowe pokolenie menedżmentu, jak wspomniałeś, tak są lekcje, ale po co czytać o historii, nie wiem, mainframe, skoro teraz siedzimy na klaudach, podczas mechanizmy, które tam się zadziały, mają jak najbardziej zastosowanie. Nie jest to oczywiste, wymaga wysiłku, więc powtarzamy głos.

SPEAKER_00 10:22

Właśnie na to wszystko nakłada się pewnie taka trochę skręcona perspektywa naszego patrzenia, które to lubi oceniać, lubi to brać pod uwagę projekty, nie wiem, technologie, które gdzieś tam się sprawdziły, które wybiły się, które weszły do takiego mainstreamu. Natomiast zupełnie zapominamy o tym, że pewnie mnóstwo tam było różnych towarzyszących czy konkurujących podejść technologii, które z jakichś tam względów jednak się nie powiodły. O tym raczej nie czytamy, tym się nie

Błąd przeżywalności w sukcesach

SPEAKER_00 10:56

interesujemy. Co byś powiedział właśnie o tego typu pajasie, o tym takim skrzywieniu myślenia?

SPEAKER_01 11:02

Wracają sobie do pytania o tym, dlaczego nauka o czytania o sukcesach niekoniecznie jest fajnie, wystarczająca. W psychologii jest nawet termin na to. Po polsku nazywa się to najczęściej błąd przeżywalności. Chociaż widziałem też inne tłumaczenia, angielski termin survival shryas, który mówi dokładnie to, że uczenie się na sukcesach? Z definicji ogranicza nasz punkt widzenia do tych przypadków, gdzie się udało, podczas gdy dane o tym, jak coś działa, są tam, gdzie coś się nie udało. Klasyczny przykład i w zasadzie original tego terminu to jest historia bombowców w czasie II wojny światowej, gdzie, o ile dobrze pamiętam, Stany Armia Stanów Zjednoczonych analizowała gdzie na kadłubach bombowców wracających z misji były dziury po kulach, uznawali, że to jest, że tam trzeba wzmacniać pancerz i jada i Heja uwzmacniali pancerz. Dopiero statyst, matematyk statystyk, o ile dobrze pamiętam węgierskiego pochodzenia Abraham Wold, stwierdził, że hej, ale te samoloty wróciły, więc te postrzenia wyraźnie nie były krytyczne, trzeba wzmacniać to, gdzie dziur po kulach nie ma. Bo jeżeli tam zostały trafione, no to samolot nie wrócił, czyli danych po prostu nie było. I w efekcie wtedy się nauczono, że należy wzmacniać skrzydła i zbiorniki paliwa, kokwit i tym podobne. Tam nie było dziur, bo jeżeli tam został samolot trafiony, no to kaplica. Kolejny przykład, bardzo podobny już nie Roy Story, to słynny mit Harward Dropaut, że najlepsi na świecie, najbogatsi na świecie nie skończyli studiów odeszli z Harwardu i jako się im się udało. Bardzo często podajemy tu przykład Bila Gate'a. Trochę rzadziej, ale też wymieniamy marka Suckerberga, który też nie skończył Harwardu, że patrzcie, udało się. Ale jak popatrzymy na dane, to każdego roku Harward ma akurat całkiem niski współczynnik od Dropał. Ten 3%, o ile dobrze pamiętam, czyli około 50 osób rocznie, ale nawet licząc te 3% i 50 osób rocznie to w ciągu ostatnich dwóch dekad było tysiąc osób, które odeszły z Harwardu, i oni wszyscy nie są milionerami. Mamy dwa przypadki, którym się udało, a i 1000 osób, które nie wylądowały na czołówkach gazet, nie są miliarderami, nie prowadzą tetów i tak dalej. Więc skupienie się na sukcesie z automatu nam wycina zdecydowaną większość historii, która być może jest bardziej ciekawa, bardziej atrakcyjna i łatwiejsza, tak jak powiedziałem, wcześniej, łatwiejsza do może nie zreplikowania, bo nie chcielibyśmy replikkować porażek, ale przynajmniej uniknięcia.

SPEAKER_00 14:10

No właśnie, bo to jest pewnie też coś takiego, że tym osobom udało się nie dzięki temu, że odeszły z Herwardu, ale być może

Blameless postmortem w analizie

SPEAKER_00 14:19

i pomimo, to też jest pewnie inna perspektywa. Wspomniałeś tutaj o posmortym jako takiej wartościowej praktyce, którą według Ciebie powinna być nawet pewnie częściej gdzieś tam faktycznie używana przez firmy, może być kluczowa, a która po prostu polega na przeanalizowaniu, co tam się pod spodem nie udało i wyciągnięciu z tego jakichś względów, jakichś wniosków, które możemy później zaaplikować naszej organizacji, do naszych procesów po to, żeby ulepszyć, po to, żeby ta sytuacja nie miała miejsca ponownie. Natomiast chciałbym Cię zapytać o to podejście do postmortem, tak? Mianowicie chodzi mi o to, że możemy tutaj łatwo przejść w taki tryb oceniania, łatwo przejść w tryb zrzucania odpowiedzialności na kogoś, co może być mierdzące wręcz dla całego zespołu, a pewnie też i położyć firmę, jeśli jest praktykowane w jakimś tam ekstremum. Jak ty patrzysz na właśnie takie Blameless- podejście do postmortem?

SPEAKER_01 15:29

Ja jestem wielkim zwolennikiem Blameless. Z jednej strony jest taka powiedzmy żartobliwa anegdota, że jeżeli ktoś wywalił produkcyjną bazę danych przez głupą komendę, to możesz być w 100% pewny, że drugi raz tego nie zrobi, więc karanie nie ma wielkiego sensu. Ale nie chodzi o anegdotę, chodzi o psychologiczny aspekt tego, co się dzieje, kiedy zaczynamy obwiniać. Kiedy obwiniamy, kiedy wiemy, że kiedy boimy się odpowiedzialności za popełnienie wpadki, a jesteśmy tylko ludźmi, to nie znaczy, że przestaniemy popełniać błędy, po prostu zaczniemy je lepiej ukrywać, i tak ten błąd się wydarzy, i tak trzeba będzie coś naprawić. Tyle tylko, że zostanie wykryty być może na znacznie późniejszym etapie, a szukanie przyczyny potrwa więcej i będzie kosztować więcej. Ale jest jeszcze jeden aspekt. Tak, mamy tendencję do znalezienia winnego ukarania i stwierdzenia, że wszystko w porządku, ale jeżeli przyjmiemy założenie, moim zdaniem, bardzo słuszne, że wszyscy pracujemy do wspólnej bramki, są czasami złe intencje, ale to jest ekstremum, o którym systemowo. Tak, trzeba się zabezpieczyć, ale nie uznałbym tego za większość. Jeżeli wszyscy chcemy pchnąć organizację, projekt do przodu, wszyscy chcą robić jak najlepiej, być może się nie rozumieją, być może trochę inaczej interpretują, ale jednak, to pytanie nie brzmi, dlaczego ten gość jest winny, wywalenia produkcyjnej bazy danych, literówki skasowania backupu, czy czegokolwiek tego typu. Ważniejsze jest pytanie, dlaczego system zaprojektowany do bycia używanym przez ludzi, którzy z definicji są omyli, pozwolił na taki błąd. Czyli jeżeli tylko przesuniemy z szukania winnego na szukanie przyczyny, możemy się na to zabezpieczyć. Jasne, możemy powiedzieć, że nie wiem, Krzysiek czy Tomek, czy inny Adam skasował bazę danych, nie ukrywajmy tego. To jeszcze nie jest obwinianie, to jest stwierdzenie faktu, ale zamiast skupiać się, jak należy Adama ukarać za to, że skasował bazę danych, i tak zdarzyło mi się w karierze. Lepiej zapytać: co w systemie pozwoliło jednemu człowiekowi na doprowadzenie do takiej katastrofy przez głupiał literówkę czy pomijanie? Czy tak jak w moim przypadku, co opisuję w książce, nie będę się tego stydził. Pomylenie terminalu, gdzie polecić, gdzie odpalona, została komenda drop database.

SPEAKER_00 18:17

Zdarza się nawet najlepszym. Wiesz, myślę sobie, że to też nie można popadać w żadną skrajność. Oczywiście karanie to nie ma żadnego sensu, bo tak jak powiedziałeś, jeśli coś faktycznie poszło źle, to ta osoba pewnie czuje się wewnątrz już na tyle samoukarana, że nie powtórzy tego podobnie, tak jak wskazałeś. Z drugiej strony, udawanie, że nic się nie stało, tak, że faktycznie pomijanie niejako tego aspektu, że ktoś to fizycznie gdzieś tam klepnął Enter w tym terminalu też jest złe. Myślę, że tak zdrowy balans jest potrzebny.

SPEAKER_01 18:52

Tak, tylko że znowu, dlatego powiedziałem, nie ukrywajmy, że hej, Boł czy Adam usunął bazę. To jest fakt, który należy przeanalizować, ale to nie jest przyczyna.

Poszukiwanie przyczyn błędów

SPEAKER_01 19:04

System po prostu generalnie musimy przyjąć do wiadomości, i być może to jest dla kogoś zaskakujące, nie sądzę, że ludzie są omylni, że pracujemy pod presją czasu, że czasami jesteśmy zmęczeni, myślimy o kłótni z partnerem życiowym poprzedniego wieczoru, czy o tym, że nie wiem, w popołudniu będzie fajna misja w Baldus Gate. Nieważne. To jest, to każdy człowiek to ma i to musimy przyjąć za pewnik. Czasami to jest też kwestia po prostu braku wiedzy. Tylko że jeżeli zatrzymamy się na tym etapie, to tak naprawdę nie naprawimy problemu. Pytanie, drążenie głębiej do znalezienia, co mogło być zaprojektowane w procesie, w systemie cokolwiek lepiej, tak żeby następnym razem, jak ktoś po prostu dotszedł do pracy, nie pijąc porannej kawy, żeby nie popełnił tego samego błędu drugi raz. Prosty przykład, to akurat jest dosyć świeże opisuje w drugim tomie. Kilka lat temu trafiła się sytuacja, kiedy ktoś przez pomyłkę wywołał na hawajach alarm. Zamiast próbnego alarmu kliknął link, kliknął przycisk wywołania bombowego alarmu i przez 40 minut całe kawaje chowały się w schronach przeciwkuatomowych. I tak, to był błąd. Ale kiedy przeanalizowano, co się wydarzyło, okazało się, że interfejs to był prosty HTML z linkami jeden pod drugim. Linki w żaden sposób nie zhierarchizowane, w żaden sposób nie różniające się od siebie. Co więcej, komunikat potwierdzenia, czy chcesz wywołać ten komunikat, brzmiał czy na pewno chcesz wywołać ten komunikat, bez nawet potwierdzenia, co kliknąłeś. Więc i miałeś jeden pod drugim: wywołaj trudny alarm, wywołaj prawdziwy alarm i człowiekowi się kliknęło źle. Brzmi absurdalnie, ale naprawdę się wydarzyło.

SPEAKER_00 21:03

No tak, trudno tutaj pewnie obwiniać tego biednego człowieka, bo o pomyłkę niezwykle łatwo. Zacząłeś mówić o tym szukaniu przyczyny źródłowej, tak? Kutko z analiz, która jest niezwykle istotna. To jest, nie wiem, czy się ze mną zgodzisz według mnie taki trochę brakujący element w tej analizie, którą właśnie widzimy ze strony jakichś tam startupów, dużych, BigTeków, i tak dalej, kiedy podają nam, że tak się złego wydarzyło. Tam często są, nie wiem, takie techniczne aspekty tylko danego problemu. Brakuje takiego zajścia głębi, albo wyjścia poza technologię. Czym według Ciebie charakteryzuje się taki dobry, właśnie root cause analysis?

SPEAKER_01 21:45

Może zacznę od obrony tych startupów czy firm, które skupiają się na technologii. Zwróćmy uwagę, że błędy w procesach to nie jest coś, co powinno być publiczne. Ja jestem wspieran. 100% przekonanie, że przynajmniej te najlepsze firmy w branży nie mają oddzielne raporty publiczne. Być może mają też oddzielne takie pół publiczne dla swoich głównych klientów. I to, co wewnętrznie, gdzie można powiedzieć, że Hej Bob kliknął zły przycisk, i jak temu zapobiec, to już się przykłada na konkretny backlock, plany biznesowe i tak dalej. To nie będzie publiczne, więc nie przeskakiwałbym do wniosku tylko dlatego, że w tych publicznych raportach tego nie ma, a te firmy tego nie robią. Ale wracając do Twojego pytania, brutko z analiz moim zdaniem powinno się skupić właśnie na znalezieniu przyczyny systemowej. Nie technicznym aspekcie, hej, zapomnieliśmy o testach, tylko właśnie drążyć dalej. Dlaczego pozwoliliśmy zapomnieć o tych testach? Co w procesie nie zadziałało? Czyli jedna z powszechnych technik, tak zwanych five WIS, czyli taka dorosła wersja zabawa w dziecko, czyli a dlaczego? Tylko z głową. I tutaj nazwa techniki mówi o 5 waj i widziałem wielokrotnie sytuację, kiedy ktoś się za bardzo zaiksował na liczbie 5 zamiast na tym, jaki jest faktyczny cel procesu, czyli pytamy tak długo, aż znajdziemy faktyczny aktion obuł. Nie jestem pewny, jak będzie po polsku w tym momencie. Powód, co poszło nie tak. Bardzo prosty przykład, który lubię przytaczać, to jest, nie wiem, spóźniłeś się na spotkanie dlaczego? No bo utknąłem w korku. A dlaczego utknąłeś w korku zamiast wyjechać wcześniej? No bo zaspałem, a dlaczego zaspałem? Dlaczego zaspałeś? No, bo wczoraj wieczorem oglądałem serial na Netflixie i poszedłem za późno spać. W tym momencie powód, który pozornie jest, że spóźniłem się, bo utknąłem w korku. Tak, to jest techniczna przyczyna, ale faktyczna źródło problemu, to nie jest kwestia tego, że są korki. No bo tak są korki Chala XXI wiek. Przyczyną jest kiepska dyscyplina i zarządzanie własnym czasem dzień wcześniej. Tak moglibyśmy ciągnąć dalej, że jeżeli doszliśmy do wyników w trzech pytaniach, moglibyśmy dążyć dalej. A dlaczego oglądałeś za długo, bo serial był świetny, a dlaczego był świetny, no bo scenarzysta jest dobry. Tylko że znowu tak możemy drążyć, tylko dojdziemy do tego, że aha, ktoś gdzieś w San Francisco czy innym Los Angeles napisał świetny scenariusz. Co możemy z tym zrobić? No w sumie nic. Więc musimy znaleźć też taki zdrowy rozsąd, pamiętać o zdrowym rozsądku i z jednej strony, drążyć do momentu znalezienia przyczyny, z drugiej strony nie drążyć za długo, żeby przypadkiem nie rozwąć odpowiedzialności do absurdu?

Złożoność systemów IT

SPEAKER_00 24:49

Rozmawiamy dzisiaj o błędach wpadkach, różnych problemach w IT, i tak sobie myślę, że być może jednym z powodów, dlaczego tak się dzieje, jest to, że tworzymy systemy nadmiernie skomplikowane, nadmiernie złożone, które niekoniecznie musiałyby takie być. Ale za tym idzie pytanie, czy aby nie jest tak, że tworzenie tych prostych rozwiązań jest trudne? Dlatego tego nie robimy?

SPEAKER_01 25:15

Oczywiście, że jest trudne. To może brzmieć w pierwszej chwili abstrakcyjnie, ale tak, tworzenie, prostych rozwiązań jest nieporównowalnie trudniejsze niż skomplikowane, dlatego że idę jest wiele poziomów tak naprawdę. Przede wszystkim, żeby zaprojektować prosty system, proste rozwiązanie jakiegoś problemu, musimy ten problem zrozumieć od początku do końca, co wcale nie jest proste we współczesnych realiach. Dużo prościej jest zacząć z PLC, potem MVP, a potem dobudowywać obsługę warunków brzegowych i coś z tego wyjdzie. Ja lubię to porównywać do projektu TatsMal. Wyobraźmy sobie, co by się stało, gdyby usta Lachory, to był projektant Tsmahal, stwierdził, dobra, najpierw postawmy schowek namiotły, a później dobudowujmy w miarę potrzeby. Zamiast cudu świata dostalibyśmy jakieś monstrum z różnych materiałów w różnych stylach itd. i tak dalej. Raczej niekoniecznie to, co byśmy chcieli. Dopiero, kiedy projektant podszedł do problemu kompleksowo, zrozumiał, jaki jest cel i ogólne przewidywany rozmiar, możliwe było zaprojektowanie czegoś tak prosto, jak się dało. To jest jeden z. Drugi jest taki, że też nie oszukujmy się, nie możemy wszystkiego projektować od A do Z. W obecnych czasach zmieniających się dosłownie z godziny na godzinę, nie jest to takie proste, delikatnie mówiąc. Ale też brakuje nam swojej odwagi do usuwania czegoś, co już zrobiliśmy. Czyli łatwiej jest dobudować, trudniej jest zrobić krok wstecz i stwierdzić, OK, tego już nie potrzebujemy. Czyli gdybyśmy to porównali znowu do architektury. Zaczynamy od zbudowania jednopokojowej chałupy, dobudujemy później salon. W miarę jak budżet pozwoli, dobudujemy kuchnię, schołę, sypialni itd. Ale czasami, żeby projekt pozostał spójny, konieczne jest stwierdzenie, aha, dobra, to pomieszczenie już nie pasuje, musimy je wyburzyć i zbudować w jego miejsce coś większego, tak, żeby ominąć pustą przestrzeń, która by powstała. To usunięcie czegoś, co już nie pasuje, jest dużo trudniejsze niż stwierdzenie, aha, ale to działa i kontynuuje. I w efekcie dostajemy coś, co nawet nie ewoluuje, tylko pączkuje w sposób niemal kancerogenny.

SPEAKER_00 28:01

Tak, rośnie przez babelkowanie. No właśnie, przywiązujemy też się do tych naszych rozwiązań, które tworzymy. Zaczyn je traktować bardzo osobiście, dlatego pewnie z trudnością pozwalamy sobie na usuwanie czegoś, no bo to jest jakby jakbyś sobie odcinał część ciała wręcz, niemalże wiem, znam takie osoby, które tak bardzo się utożsamiają z tym swoim kodem, że trudno im przysłowiowo zaorać wcześniejsze rozwiązanie. Tak, tworzenie tych rozwiązań to jest jak gdyby jedno, ale najczęściej my, albo prawie zawsze oprócz samego budowania musimy również technologie wyjaśniać,

Trudności w tłumaczeniu technologii

SPEAKER_00 28:35

tłumaczyć, chociażby użytkownikom końcowym, chociażby jakimś innym osobom, nietechnicznym wewnątrz czy organizacji, które te osoby również są zaangażowane w wytwarzanie na przykład kolejnych feature, i tutaj również pojawia się takie pole trochę do popełniania błędów, do jakichś fuck-upów, do naszej takiej nieumiejętności prostego wytłumaczenia technologii. Jak myślisz, dlaczego tak się dzieje, że jako osoby, które wydawało się, że powinniśmy rozumieć tę technologię dogłębnie, jednak mamy trudność i problem z jej łatwym wytłumaczeniem.

SPEAKER_01 29:13

Dlatego, że znowu tłumaczenie łatwe jest trudne. Z inny strony, to wymaga pewnej dozy, powiedzmy, empatii, żeby pamiętać, że nie każdy rozmówca wie, to, co my. Ludzie typowo inżynierowie oprogramowania są świetnie, mogłobniej, jeśli chodzi o wzorce projektowe, architektury, być może cloud computing i tak dalej, ale niekoniecznie rozumieją biznesowe realia, i z drugą stronę, ktoś może rozumieć biznesowe realia problemu, ale pogubi się w terminologii. To jest jeden aspekt. Ale drugi, znacznie ciekawszy moim zdaniem, jest to, że używanie, tłumaczenia w sposób skomplikowany, z jednej strony daje nam obronę albo iluzję tego, że brzmiemy mądrzej, więc lepiej tak to powiedzieć. Ale z drugiej tak naprawdę rozmywa odpowiedzialność za komunikat. Bo zwróćmy uwagę, ja bardzo lubię ten przykład. Jeżeli byśmy powiedzieli nim, co to jest Kubernetis, można by powiedzieć, że to jest orkiestrator, który skeduluje pody na w klasze komputerów, bla, bla, bla. Jasne, to wszystko się zgadza i wiem, że to za przymiałem dziwnie dużo łatwiej byłoby mi powiedzieć po angielsku, tylko że zwróćmy uwagę, że tak naprawdę tylko to, że ja to powiem, nie znaczy, że ja wiem, co to jest orkiestrator. Tak naprawdę przekazuję odpowiedzialność za zrozumienie terminologii na odbiorce komunikatu, a nie biorę na siebie odpowiedzialności za wyjaśnienie, co ja mam na myśli. Czyli tak naprawdę do końca nie wiadomo, czy w momencie, kiedy rzuciłem jakieś tego typu zdanie, czy ja rozumiem, o czym mówię, czy tylko się wy nauczyłem formułki z Wikipedii, czy innej dokumentacji. W momencie, kiedy połączymy empatię i wzięcie odpowiedzialności za jasność komunikatu, okazuje się, że nie mamy gdzie się schować i musimy wyjaśnić, co mamy na myśli, tak, żeby rozmówca to zrozumiał. To jest dużo trudniejsze zarówno koncepcyjnie, jak i do pewnego stopnia psychologicznie. Wzięcie większej odpowiedzialności na siebie nie jest proste. Z tego powodu ja na przykład bardzo lubię na rozmowach rekrutacyjnych w platform engineeringu, czy na DevOps, czy coś tego typu, zadać pytanie, wyjaśnij mi, ale tak, jakbym był pięciolatkiem, jaka jest różnica między kontenerem a maszyną wirtualną. I gwarantuję 9 na 10, jak mniej więcej kandydatów, jest w stanie to wyjaśnić w sposób techniczny, używając żargonu, terminologii itd. Ale kiedy narzucę limit, ale wyjaśnij mi to tak, jakbym był pięciolatkiem, nie rozumiem, o czym do mnie mówisz, to nagle to się okazuje dużo trudniejsze, bo nagle zaczynają pojawiać szczeliny w samym zrozumieniu przez osobę, która mi to miała tytłumaczyć.

SPEAKER_00 32:22

No tak, to wcięcie odpowiedzialności na siebie za komunikację to jest myślę tutaj klucz, niepoleganie na tym, że wydaje nam się, że inni też wiedzą, to, co my wiemy. No tak, cała pewnie tutaj teoria komunikacji lepszej komunikacji się kłania. Natomiast chciałbym zapytać się w kontekście automatyzacji, która dosyć mocno nam wkroczyła na scalony w przeróżnych aspektach

Automatyzacja i jej paradoksy

SPEAKER_00 32:50

IT. Czy według Ciebie to jest dobry trend w takim rozumieniu, że potencjalnie pozwoli uniknąć jakichś błędów i problemów, czy też można wręczyć przeciwnie, spowoduje, że zamkniemy się w tych naszych swoich bańkach i nie będziemy w stanie robić więcej niż dana automatyzacja pozwala, niż te założenia, które służyły do jej stworzenia, pozwalają.

SPEAKER_01 33:16

To jest bardzo ciekawe i wielopoziomowe pytanie, ponieważ z jednej strony, czy automatyzacja jest dobra? Tak, oczywiście, że jest dobra, z drugiej czy pozwoli uniknąć błędów? Wielu na pewno tak. Ale nie wszystkich, a wręcz przeciwnie stworzy nowe błędy. Nawet to jest takie coś, co się nazywa paradoks automatyzacji, gdzie tak naprawdę im więcej i im lepszy system zbudujemy do automatyzacji, tym mniej dajemy możliwości użytkownikom tego systemu ćwiczenia w regularnych sytuacjach, więc zabieramy możliwość treningu, a później oczekujemy, że jeżeli ta automatyzacja się wyspie, to natychmiast będą wiedzieć, co robić. No nie, tak to nie działa. Więc z tej perspektywy tworzy się cały nowy obszar problemów i wyzwań, jak temu zaradzić. To jest jedna rzecz. Druga, nawet ciekawsza jest taka. I to jest powiązane z jeszcze jednym paradoksem. Można zauważyć, że lubi patrzeć w historię, żeby tłumaczyć, co się dzieje obecnie. Nazywa się to paradoksem produktywności. Termin ukryć w latach 80. ale znacznie starszych, ale mechanizm jest starszy, że tak naprawdę nowa technologia nie powoduje wzrostu produktywności od razu. W latach 80. to nie pamiętam teraz, kto to stwierdził, ale stwierdziło coś w rodzaju, że komputeryzację widać wszędzie z wyjątkiem wyników produktywności. I faktycznie, jak się popatrzy na statystyki z lat 80. 90. to prawda, ale wynikało z tego, że wprowadzono nową technologię, oczekiwano nowej jakości, ale nie zmieniono procesów, które by wspierały tę technologię. To samo byłofikacją, opóźnienie pomiędzy wynalezieniem silnika elektrycznego albo nawet próbą wprowadzenia go w przemyśle, a faktycznymi korzyściami wyniosło około 20-30 lat na przełomie XVIII i XIX i XX wieku. I wynikało z tego, że po prostu próbowano zastąpić jedną centralną maszynę parową ogromnym silnikiem elektrycznym w halach produkcyjnych i spodziewano się, co potrzebne były dosłownie 2, 2,5 dekady na totalne przeprojektowanie hal produkcyjnych, zastąpienie jednej centralnej, drogiej i nieefektywnej maszyny parowej, znacznie mniejszymi, tańszymi silnikami przy stanowiskach produkcyjnych. To wymagało przeprojektowania całej hali produkcyjnej. Dopiero, kiedy to się wydarzyło, ten bóst produktywności nastąpi. Dokładnie to teraz obserwujemy moim zdaniem z IT, gdzie z jednej strony wprowadzamy automatyzację, procesu wytwarzania kodu, czyli tych link kodu, ale z drugiej strony zakładamy, że wszystko wokół będzie działać tak samo. Podczas, gdy w praktyce tak, wytwarzanie kodu staje się dużo, stało się dużo prostsze, dużo szybsze, ale sam proces projektowania rozwiązania wcale nie zrobił się proporcjonalnie mniejszy. etap weryfikacji, testowania tego rozwiązania nie tylko nie stał się mniejszy, ale stał się dużo trudniejszy, dużo bardziej skomplikowany i dużo istotniejszy niż był jeszcze, nie wiem, 5 lat temu. Czyli tak, wprowadzenie automatyzacji spowoduje wzrost produktywności, ale zanim to naprawdę nastąpi w sposób mierzalny, musimy zmienić całe linię, całą fabrykę, całą linię produkcyjną procesu wytwarzania oprogramowania i zrozumieć, że to, co było naszą operacją dominującą, jeśli mówimy takim żargonem IT, czyli wytwarzanie kodu, przestało być operacją dominującą. Nową jest być może weryfikacja, walidacja rozwiązania i przez ten pryzmat powinniśmy oceniać. To wywraca do góry nogami wszystkie procesy, jakie istnieją organizacja być może, ale musi nastąpić, zanim ta produkcyjność wzrośni.

SPEAKER_00 37:39

Wiemy już, że nie da się zupełnie wyeliminować wszystkich

Zrozumienie błędów i technologii

SPEAKER_00 37:42

błędów problemów. One są gdzieś tam immanentne, wpisane po prostu w technologie, w systemy, które są, mogą być wadliwe, mogą po prostu mieć jakieś Twoje problemy, co potem przekłada się na pozostałe. No to wcale nie znaczy, że jednak nie powinniśmy dążyć do jakiegoś zminimalizowania bo wykluczenia tych problemów, tych błędów, które po prostu da się w jakiś sposób gdzieś tam usunąć. I czy według Ciebie w ogóle mówić, aby w ogóle myśleć o takim, no nie wiem, minimalizowaniu tych błędów, to trzeba przede wszystkim mieć bardzo dogłębną, wynikliwą wiedzę na temat technikaliów, na przykład danej technologii, aby wiedzieć, gdzie tam potencjalne problemy mogą wystąpić, a być może wiedzę na temat ograniczeń danej technologii, gdzie ona się nie sprawdza, jakie problemy mogą nastąpić na jakichś skrajach działania tej technologii, a wręcz może kompletnie nie w technologii jest problem, a raczej wiedza o tym, jak ludzie działają, jak ludzie się komunikują i gdzie mają te swoje ułemności, jest niezbędna, żeby w ogóle o tym eliminowaniu błędów mówić. To jest według siebie najistotniejsze.

unknown 38:51

Tak.

SPEAKER_01 38:52

I to by było w zasadzie cała odpowiedź, ale głębiej. No nie oszukujmy się. Rozumienie technologii, technikali, ograniczeń technologii jest ważne. To nie ulega wątpliwości. I być może gdybyś mnie spytał jeszcze kilka miesięcy albo rok temu, to może bym nawet był stanie stwierdzić, że to jest najważniejsze. Obecnie jednak skłaniam się ku stwierdzeniu, że może jednak zrozumienie ludzkiej natury jest co najmniej równie ważne, jeśli i nieważniejsze, dlatego że tak jak powiedziałem, technologia się zmienia szybciej niż jesteśmy w stanie nadążyć tak naprawdę, tylko w czasie mojej kariery paradygmat oprogramowania został przywrócony co najmniej trzykrotnie do górami, a błędy i koncepcje pozostają. Tak naprawdę nawet ostatnio napisałem całkiem, głębszą analizę o technocentryzmie, czyli roli AI w prawach autorskich dostępne na moim blogu, ale nie będę się tu reklamował. I co zauważyłem, to to, że praktycznie wszystkie techniki związane z ochroną praw autorskich są naprawdę bardzo stare i sięgają nawet czasów starożytnej Grecji albo i lepiej. Tak, technologia stojąca za tym oczywiście się zmieniła, ekonomia samego procesu jak najbardziej, ale koncepcje są te same. Więc. Jakkolwiek, techniczne rozumienie koncepcji i technologii, ograniczeń tych technologii jest ważne? Tak jeśli chodzi o długofalowe rozumienie natury błędów i tego, jak ich unikać, raczej skłaniałbym się już teraz bardziej ku stwierdzeniu, że to zrozumienie ludzkiej psychiki, naszych własnych ograniczeń jest może nieba ważniejsze, ale co najmniej równie ważne.

SPEAKER_00 40:58

Czy AI tutaj wywraca stolik, a może jeszcze bardziej dokłada się do tego, że powinniśmy lepiej rozumieć człowieka, oczywiście w kontekście tutaj mówimy, błędów fuckupów tych naszych rozwiązań IT, czy nie wiem, dzięki temu, że stosujemy tego typu rozwiązania, to możemy uniknąć więcej potencjalnych błędów, czy też może wręcz przeciwnie, dokładamy sobie kolejnych

AI a ludzkie ograniczenia

SPEAKER_00 41:21

jeszcze na sztalsz?

SPEAKER_01 41:22

Jakkolwiek cenię technologię AI, tak raczej byłbym w stanie skłonny do stwierdzenia, że nie unikniemy błędów. Te modele AI wciąż są tworzone przez ludzi, więc nabierają tych samych problemów i ograniczeń, które mamy. Nawet też dosyć mocno tym w drugim tomie FP Palmana napisze. Więc nie jest tak, że są projektowane przez cocjopatów, którzy nie mają ludzkich ograniczeń. To jest jedna rzecz. Automatyzujemy, czyli jeszcze dokładamy czynnik skali, dokładamy element automatyzacji, paradoksu automatyzacji, o którym wącimy, wspomniałem. I jeszcze na dokładkę dodajemy skalę, z którą ludzie nie są w stanie już sobie poradzić. Więc jakkolwiek wiele błędów, które się trafiały być może zostanie wyeliminowane, te najbardziej krytyczne pozostają, zostaną zautomatyzowane i jeszcze tworzymy nową kategorię. To jest moim zdaniem, ale tak jak mówię, cenię IT, więc AI nie chce tutaj brzmieć jak deetysta i zaorajmy wszystko zaraz będzie skinnet. Po prostu zdawajmy sobie sprawę z tego, jak to działa i jakie są ryzyka, ograniczenia koszta. I znowu historia nam to bardzo fajnie pokazuje, że wynalezienie silnika spalinowego i zastąpienie koni wcale nie wyeliminowało wszystkich problemów. Część tak, część pozostała, ale stworzyła też zupełnie nowe. Co wcale nie oznacza, że technologia wcale nie była na koniec dnia wartościowa dla rozwoju ekonomii, społeczeństw i tak dalej. Podobnie będzie ZJ. Część problemów przestanie istnieć, część pozostanie, bo po prostu to jest w naszej naturze, a nowe już zaczynamy odkrywać powiedzmy.

SPEAKER_00 43:28

Dokładnie i pewnie wiele z nich będzie z nami jeszcze szło, niezależnie od tego, jak bardzo te technologie będą się zmieniać, rozwijać, czy przechodzić w coś zupełnie innego, o czym nawet ciężko teraz pomyśleć, bo chociażby dlatego, że są tworzone przez ludzi, i tak jak powiedziałeś, nie komentują tę naszą naturę. Zdecydowałeś się napisać o tym serie książek? Może krótko opowiedz proszę, o czym jest ta seria? Dlaczego w ogóle taka decyzja, żeby ten temat poruszyć?

SPEAKER_01 43:56

Bez zagłębienia się w zbyt wiele detali, żeby Nie znadziej tutaj słuchaczy, ale na początkowo nawet nie myślałem o pisaniu książki, chciałem zrobić cały krótki przegląd ciekawych historii jako promocję mojej poprzedniej książki. Tyle tylko jako powiedzmy tak wykorzystać tendencję albo do tego, że wszyscy lubimy Szaden, mamy tendencję do Szaden Freund'a i do tego, że to jest chwytliwe i tak dalej. Tylko, że bardzo szybko zrozumiałem, że temat jest zbyt głęboki i zbyt bogaty żeby nie zagłębić się jeszcze bardziej. I uznają, że to zasługuje na książkę. Tylko, że jak zrozumiałem, że tego będzie więcej niż kilkadziesiąt stron. Początkowo myślałem, że wyjdzie może z 400-500 stron książka. To zrozumiem, że sam przegląd historii haha, patrzcie, zepsuło się, nie uzasadnia z jednej strony mojego czasu, a z drugiej, może nawet co ważniejsze, czytelnika czasu, żeby poświęcić czas, energię i pieniądze na przeczytanie 500 katastrof, więc zacząłem szukać, skąd to się bierze, analizować i chciałem to zrobić bardziej przystępnym dla jak najszerszego krona odbiorców. W związku z czym, zamiast tłumaczyć, popatrzcie, nie wiem, cały szwedzki internet zniknął z internetu na dwa dni, tak stało się. Musiałem wyjaśnić, dlaczego, a żeby to wyjaśnić, musiałem wyjaśnić, po pierwsze, co to jest DNS i co to jest DNSC. I znowu mógłbym tutaj sypnąć z dokumentacją, ale jeżeli to ma być krótkie wprowadzenie do technologii, no to albo bym zrobił to zbyt nudne i wciąż na tyle powierzchne, że specjalista i tak by stwierdził, że przyczyta RFC i będzie wiedział więcej. Albo zrobię to na tyle pełne żargonu i technikaliów, że ktoś, kto nie ma o tym pojęcia, i tak nie będzie miał o tym pojęcia, bo albo nie zrozumiał, albo uzna, że to nudne. Więc musiałem znaleźć zupełnie inne podejście, jak to zrobić ciekawe, więc jest całkiem sporo właśnie takich wyjaśnień tak, żeby. I to nawet sprawdziłem na czternastoletnim siostrzeńcu, że tak przeczytał i zrozumiał. Więc z drugiej strony, sprawdziłem na wykładowcy jednej z uczelni publicznych, technicznych w Polsce i też przeczytał. Oczywiście, celem tutaj nie było, żeby zrozumiał, to by było trochę obraźliwe. Celem było, żeby uznał, że to jest wystarczająco dokładne i odzwierciedlało realia, i tak ten cel się udało osiągnąć. Dopiero mając taką bazę, byłem w stanie opisać parę historii, które reprezentują, które jeszcze lepiej obrazują, jak dany aspekt technologii działa. Tylko że w miarę jak zacząłem się zastanawiać, co jeszcze wypadałoby wyjaśnić, no to z 400 stron zrobiło się sporo więcej. No, i tak jak wspomniałeś, wychodzi z tego cyklu, planowany cykl czterech tomów. Więcej nie będzie na razie, bo wystarczy tego skołbym crepu, ale każdy z nich będzie miał około 40-500 stron, więc jest dużo materiału, dużo ciekawego materiału.

Wprowadzenie do książki Adama Korgi

SPEAKER_01 47:17

Mam nadzieję, że ciekawego nie tylko nam. Pierwsze opinie sugerują, że chyba się udało.

SPEAKER_00 47:24

Superusz oczywiście gratuluję i na tyle na ile ci znam, to jestem przekonany, że to nie jest Twoje ostatnie słowo. Za dzisiejszą rozmowę bardzo Ci dziękuję. Powiedz jeszcze proszę, gdzie cię możemy znaleźć w internecie, gdzie możemy też książki, które już się okazały i które jeszcze dopełnią ten cykl znaleźć.

SPEAKER_01 47:42

Więc najprostszym miejscem, że tak powiem, pierwszym kontaktu jest moja strona internetowa wwwadam.com. Tam są informacje i o książkach, i moje inne przemyślenia. Powiedzmy, jeżeli można to tak nazwać, przemyślenia i rozkminy. W postaci bloga, możliwości zapisu do newslettera, linku do LinkedIn, gdzie piszę jeszcze więcej, dzieleję jeszcze więcej wody. I tam też są linki to, gdzie można kupić, no ale najprostsza odpowiedź na ten moment to jest Amazon, to jest SelfPop, więc na razie jest to jest główny kanał. Jest dostępny w księgarni, w pewnych księgarniach internetowych, ale nie jestem, nie mam na to wielkiego wpływu, więc Amazon to jest najlepsza ścieżka, że tak powiem, w tym momencie.

Zakończenie i podsumowanie rozmowy

SPEAKER_00 48:32

Świetnie, oczywiście wszystkie linki w dodatko tego odcinka się znajdą. Ja tobie jeszcze raz dziękuję za tą rozmowę. Do usłyszenia.

SPEAKER_01 48:39

Dzięki wielkie.

SPEAKER_00 48:41

To już wszystko na dzisiaj. Jeśli chcesz więcej takich rozmów, archiwum czekam. Tam też dzieją się ciekawe rzeczy. Masz pytania, przemyślenia? Możesz się ze mną skontaktować na social mediach lub mailowo na Krzysztof Map. Rozmawiajmy itklub.pl. Nazywam się Krzysztof Kępiński, a to był odcinek porozmawiajmy IT o tym, że system IT się ptują i czego nas to uczyni. Do usłyszenia w kolejnym odcinku. Cześć.