Krzysztof:
To jest 306 odcinek podcastu Porozmawiajmy IT, w którym w cyklu rozmów z Łukaszem Drynkowskim z portalu z ogłoszeniami pracy IT Solid Jobs, który mam przyjemność współtworzyć, dyskutujemy o wpadkach, błędach i fuck-upach w IT.

Krzysztof:
Zapraszamy do słuchania i komentowania. A teraz życzymy Ci już miłego słuchania. Odpalamy! Cześć Łukasz.

Łukasz:
Cześć Krzysztof.

Krzysztof:
Spotykamy się tutaj w ramach serii podcastów Porozmawiajmy o IT o błędach, fuck-upach i różnego typu rzeczach, które nie wyszły w IT. No i nie ma co ukrywać, że najlepiej byłoby uczyć się na błędach popełnianych przez innych. To byłaby idealna sytuacja. Ale życie, wiadomo, pisze inne scenariusze i jednak wychodzi tak, że najlepiej zapamiętujemy te błędy, te wpadki, które popełniliśmy sami. Te lekcje po prostu zostają z nami w pamięci najdłużej, bo gdzieś tam zabolały nas najmocniej. No i co Łukasz? Pewnie najlepiej byłoby dążyć do takiej sytuacji, w której mamy projekt zupełnie bez błędów, firmę, w której żadne wpadki nie występują. To byłaby chyba idealna sytuacja. Co myślisz?

Łukasz:
Tu myślę, że należą się pozdrowienia dla profesora Marciniaka z Politechniki Poznańskiej, który zawsze powtarzał, że oprogramowanie wolne od bugów i błędów to jest twór czysto hipotetyczny. Myślę, że błędy są nieodłączną częścią procesu budowania produktów IT,

Łukasz:
programów. Kto nigdy nie miał żadnego błędu na produkcji, niech pierwszy rzuci kamieniem. Natomiast myślę, że to czym warto się dzisiaj zająć, o czym chcielibyśmy porozmawiać, to jest uczenie się na tych błędach. I myślę, że największym w ogóle fuck-upem, jaki można popełnić, to nie uczyć się po prostu na własnych błędach. Znajdźmy zawsze przyczynę tego, co się stało, tego, co spowodowało jakiś błąd, problemy i postarajmy się to wyeliminować.

Krzysztof:
Błędy to nieunikniona część IT, ale to nie powód, żeby załamywać ręce i rozdzierać szaty jak u Rejtana, tylko jednak wyciągać z tego jakieś wnioski, przechodzić różnego typu retrospektywy, uczyć się na tym, co nie wyszło, aby po prostu unikać tych błędów w przyszłości.

Łukasz:
Tak, jak jest takie polskie powiedzenie, że ten nie popełnia błędów, kto nic nie robi, także zespoły i organizacje, które nie popełniają błędów, to są pewnie takie, które nie dostarczają nic ciekawego, żadnych innowacji, tylko są gdzieś tam w jakimś bezpiecznym swoim sandboxie. No i też pamiętajmy o tym, że tutaj jest też aspekt tego, żeby zarządzać tym wszystkim, zarządzać ryzykiem, zarządzać błędami i też są różne sytuacje, czasami chcemy albo jesteśmy zmuszeni na przykład dopiąć jakiś deadline, no bo prognoza pogody na wczoraj, no to nikomu do niczego się nie przyda, tak i są przypadki, gdzie po prostu ktoś musi powiedzieć dobra, Robimy ten deploy na produkcję albo puszczamy nowy release i tak bywa, że nie jesteśmy jeszcze na 100% pewni, a tak naprawdę na 100% pewni to pewnie nigdy nie możemy być. Natomiast chcielibyśmy zawsze, żeby ten poziom naszej pewności był dostatecznie wysoki przed przedstawieniem naszej pracy szerszej publiczności.

Krzysztof:
Tak, myślę sobie, że tutaj można mówić o dwóch takich poziomach uczenia. Pierwszym jest indywidualne podejście do różnego typu wpadek błędów, które popełniliśmy, niczym szachista, który analizuje swoją partię i stara się dociec, co tam nie wyszło. I to pewnie ubogaca, rozwija daną osobę, która gdzieś tam umaczała swoje paluszki w tym błędzie.

Krzysztof:
Taką szerszą perspektywą, o której nawet częściej pewnie tutaj dzisiaj będziemy rozmawiać i wspominać jest perspektywa całej organizacji. To jak organizacja może się uczyć z tych błędów, aby ich po prostu nie popełniać. To jest też swego rodzaju, można powiedzieć, element kultury danej organizacji, tego w jaki sposób ona podchodzi do błędów, czy jest tam typowy blame cartel, czyli obarczanie danych osób odpowiedzialnością, w jakiś sposób napiętnowanie, czy też może jest swego rodzaju wręcz przyzwolenie na popełnianie błędów rozumiane nie jako oczywiście umyślne wykonywanie źle swojej pracy, ale takie przyzwolenie na to, że coś może się nie udać bo żyjemy w tak zmiennym otoczeniu jakim jest oprogramowanie, że prędzej czy później jakaś wpadka się wydarzy, to nie jest kwestia czy, ale kiedy no i w takich organizacjach z taką kulturą oczywiście to uczenie jest znacznie lepsze efektywniejsze, jest w ogóle możliwe tak,

Łukasz:
Celem naszym zawsze powinno być dojście do przyczyn problemów, a nie szukanie winnych z zapobieganiem też takim sytuacjom w przyszłości. Natomiast też moim zdaniem nie wolno też popadać w żadną skrajność. Zarówno taki właśnie blame culture, który tutaj szuka przede wszystkim winnych jest zły, ale też sytuacja, w której nikt nie odpowiada za nic i jakby jest kompletne rozbycie odpowiedzialności, to też jest niefajne. Na przykład mogę sobie wyobrazić, że jeśli znajdziemy tutaj jednak tych winnych, niekoniecznie tak szukając specjalnie, ale jeśli wiadomo, że tutaj ktoś zawinił, no to możemy się umówić w zespole na jakieś takie nie…

Łukasz:
Nierażące kary typu, że tutaj ktoś będzie musiał w tym tygodniu czyścić ekspres, do kały, ale coś, co i tak trzeba zrobić. Czy też właśnie ten nieszczęsny deploy na produkcję, ktoś dopilnuje czasami. Różne są procesy. Wiadomo, że w większości one są zautomatyzowane, ale warto zawsze w ramach takiego deploya mieć też jakiś proces, który sprawdza jakieś rzeczy. Także tutaj jeśli są tego typu czynności no to może jednak osoba, która gdzieś tam ostatnio zawiniła mogłaby, a też niekoniecznie ostatnio, bo żeby też nie było potem programiści to lubią optymalizować. Żeby nie było tak, że tutaj każdy będzie zawsze trzymał swoje zmiany na początek sprintu, żeby jego było, wcześniej i w bezpiecznym slocie, tak? Także tutaj trzeba uważać.

Krzysztof:
To może pójść bardzo źle, jeśli źle tym zarządzimy. Ale wykonajmy może krok wstecz, bo zanim zaczniemy…

Łukasz:
Jasne, jasne. Tutaj za szybko poszliśmy.

Krzysztof:
Tak, tak, tak. Oczywiście możemy później zastanawiać się, co z takim delikwentem zrobić, ale zanim do tego dojdziemy, no to musimy być pewni, że to ta osoba. Czyli musimy dojść przez swego rodzaju proces dochodzeniowy, co tam poszło Tak,

Łukasz:
Ale jeszcze raz to powtórzmy, że tu jakby nie chodzi o znalezienie winnego. Tu chodzi o to, żebyśmy wiedzieli dlaczego ten błąd powstał, znaleźli jakiś ciąg przyczynowo-skutkowy, znaleźli może potencjalne, może to było więcej miejsc, gdzie można było temu zapobiec i zbudować po prostu jakieś bezpieczniki na przyszłość, które pozwolą na to, żeby już tego typu błąd nie wystąpił. Także pamiętam takie sytuacje że udało nam się znaleźć przyczyny błędów zaplanować jakieś action itemy w, w dzirze, no i co? No i błąd powrócił, bo jakby brakowało tutaj wykonania tych, czynności, no to to jest też taki fuck up, fuck upie. No tak, no tak. Już coś by można było naprawić, natomiast tak. Natomiast ten sam problem powrócił. Też pamiętam sytuację typu znaleźliśmy, naprawiliśmy błąd, nie zapisaliśmy, jaka była przyczyna. Za jakiś czas nie mówiąc też o tym, żeby właśnie się zabezpieczyć przed tym problemem. Natomiast za jakiś czas problem powrócił i co? Pamiętaliśmy, że był taki problem, ale nikt nie pamiętał jakie było rozwiązanie i było trzeba

Łukasz:
od nowa dochodzić, szukać jakie było rozwiązanie danego problemu.

Krzysztof:
Tak, gdybyście nie zauważyli, to zaczęliśmy z Łukaszem omawiać post-mortem, czyli taki proces analizy incydentu po jego wystąpieniu. To co, może powiedzmy właśnie jak do tego podejść z głową i co byśmy chcieli po przeprowadzaniu takiego postmortem osiągnąć no to tak,

Łukasz:
Takie postmortem to po pierwsze to jest coś co robimy już po wystąpieniu problemu i po jego rozwiązaniu czyli nie jest to część, samego rozwiązania backfixa, też jakby chodzi o to żeby, też nie dokładać dodatkowych narzutów, kiedy czas na przykład jest ważny, żeby szybko coś rozwiązać, tylko też ze spokojną głową, jak już wszystko mamy rozwiązane, no to wtedy siadamy, Znajdujemy czas, zbieramy osoby, które są tutaj zainteresowane, niekoniecznie zawsze to musi być cały zespół, różnie to bywa. No i staramy się po prostu stworzyć analizę tego incydentu, stworzyć jakieś action itemy, które pozwolą nam zapobiec tego typu problemom w przyszłości. Próbujemy znaleźć swego rodzaju bezpieczniki, które tutaj byśmy mogli, zainstalować staramy się zrozumieć gdzie ten błąd wystąpił błędy mogły też mieć różne przyczyny jeden błąd mógł mieć kilka różnych przyczyn które się gdzieś tam ze sobą zderzyły.

Łukasz:
Jedna rzecz zamieniła to może jeszcze jakoś by uszło, a tutaj akurat był taki problem, który był złożony. No i w efekcie końcowym moim zdaniem powinien powstać jakiś dokument. Ja zawsze jestem fanem OneNote’ów i tego typu narzędzi, które po prostu pozwalają na to, żeby ten dokument żył i pozwalał też na zbiorową edycję i zbiorową ownership tego. Stworzymy jakieś action itemy i w kolejnych iteracjach pilnujemy, co się stało. Także jeśli chodzi o taki proces agile’owy, to też dobrym momentem na przeprowadzenie

Łukasz:
takiego post-mortem to jest sprint retrospective. To jako takie miejsce, które po prostu zajmuje się nie tyle samym produkcem, co procesem.

Krzysztof:
No właśnie, bo te action items, o których powiedziałeś, czyli jakieś czynności do wykonania, które mają powiedzmy w przyszłości w jakiś sposób zapobiec wystąpieniu podobnych problemów albo też naprawić sytuację, to niekoniecznie muszą być tylko zadania techniczne, typu poprawić na przykład coś w robieniu kopii zapasowych albo tego typu, ale to mogą być też zmiany w procesach albo w naszym podejściu do sposobu pracy, czyli takie właśnie procesowo-kulturowe, związane z kulturą pracy, zmiany. I często się okazuje, że to właśnie swego rodzaju problemy w komunikacji, jakieś niedogadanie, niezrozumienie, operowanie innym językiem jest efektem, czy też przyczyną właściwie problemu, a nie błąd w kodzie.

Łukasz:
Tak, to bardzo ciekawe, co powiedziałeś o tym różnym języku. To ja też zauważyłem kilka razy błędy tego typu, że właśnie klient, formułował, używał innego języka niż gdzieś tam my mieliśmy w kodzie, czy my w zespole się porozumiewaliśmy i po prostu na tą samą rzecz mówiliśmy, używaliśmy innych rzeczowników lub też w drugą stronę. To były dwie różne rzeczy, a dla nas jakby i dla klienta to było to samo słowo. Tutaj na przykład rozwiązaniem byłoby stworzenie jakichś słowników, pewnych konwencji też w kodzie. To ja mogę przykład na przykład dla SolidJobs podać, gdzie mamy coś takiego jak offer.

Łukasz:
I teraz to gdzieś tam w domenie finansowej to może oznaczać jakąś ofertę dla klienta na pakiet ogłoszeń, a oczywiście tutaj w domenie tego samego ogłoszenia to ofer jako job ofer sama ta oferta pracy ogłoszenia.

Łukasz:
Po polsku nawet oferta pracy ogłoszenia już mamy dwa różne rzeczowniki, no i to może już powodować problem. Tutaj idąc teraz dalej, co możemy zrobić, co możemy zmienić. Na przykład możemy spróbować przypisać do pewnych obszarów odpowiedzialności i pewne osoby lub pewne zespoły, które będą teraz gdzieś na pewnym poziomie za coś odpowiadały. Na przykład, znowu się powtarzam, pamiętam w jednej z poprzednich firm to mniej więcej wyglądało tak, że ja jako główny deweloper odpowiedzialny za napisanie modułu na przykład recept.

Łukasz:
No to potem stawałem się takim nieformalnym light-ownerem tego feature’a i teraz jak w przyszłości ktoś wprowadzał pewne zmiany akurat w tym danym obszarze, w tym danym module, no to zawsze gdzieś tam w tym pull requescie się wypowiadałem. Nie było to gdzieś twardo sprecyzowane. Oczywiście jest to możliwe za pomocą narzędzi typu Azure DevOps czy Bitbucket, żeby przypisać do, jeśli plik ma coś tam w nazwie, no to zawsze przypisuj daną osobę, że musi zaakceptować pull request. Natomiast to moim zdaniem, oczywiście to zależy od zespołu, od projektu, to już jest za dużo. Ja mówię o takim lekkim procesie, że po prostu jeśli jest tutaj…

Łukasz:
Coś związanego z danym obszarem, no to wiemy, że gdzieś jest osoba, która fajnie jakby się wypowiedziała, bo ona wie trochę więcej na ten temat. Ale też nie tylko możemy przypisywać odpowiedzialność, możemy też w ramach takiego postmortem tą odpowiedzialność przesuwać, dzielić. Może ktoś ma właśnie za duży obszar, może jakby te znowu będą odnosiły do tej samej domeny, czyli do tych recept. Może tutaj baza leków a samo wystawianie recept a na przykład drukowanie recept to już są trzy różne obszary, które można podzielić pomiędzy trzy różne osoby, a tutaj jedna osoba się jakby tym opiekowała i nie miała na przykład czasu, żeby to wszystko ogarnąć, że się tak wyrażę, no różne można mieć tutaj.

Łukasz:
Podejścia oczywiście można jako typowe action itemy, no to jest dodanie konkretnych logów, dodanie jakiejś także w chmurze, monitoringu w pewnych sytuacjach na przykład zautomatyzowanie jakichś maili, które tam ta nasza chmura wyśle hej, tutaj się kończy miejsce gdzieś albo przekroczyłeś, jakiś tam wskaźnik i automatycznie zespół dostaje jakieś maile albo może maile są często ignorowane, może właśnie to był problem maile były, i trzeba wymyślić, jak bardziej dobitnie tutaj problem pokazać. Także pamiętam właśnie taką sytuację. Załóżmy, że troszkę ten problem był inny, ale załóżmy, że miejsce w bazie danych się skończyło, wielkość bazy danych tak w morze. No i raz był taki problem, no to co? Dodaliśmy właśnie maile, które się wysyłały do nas hejtu ostatnie 10%. No ale co się stało? Stało się to, że oczywiście nikt tych maili potem nie czytał. Jak wpadają te automatyczne maile i jest dużo, no to nikt nie czytał, także przy kolejnym wystąpieniu tego problemu było trzeba wymyślić coś lepszego niż wysyłanie tych maili. No i powstał jakiś.

Łukasz:
Mikroserwis, który ustawiał po prostu na panelu admina czerwony komunikat, że widzieliśmy, że coś tam się zaczyna, że ta sytuacja już jest blisko.

Krzysztof:
To pokazuje, jak te bugi są zrażliwe, w sensie robisz jakiś action item, żeby przeciwdziałać problemowi, a w realizacji tego action itema okazuje się, że występuje kolejny błąd, kolejny fuck up.

Łukasz:
Tak, no niech pierwsze rzuci kamieniem ten, kto po pierwsze nigdy żadnego buga nie miał, a po drugie nigdy nie zdarzyło że ten sam bug gdzieś wrócił.

Krzysztof:
No i tak, nie raz, nie dwa.

Krzysztof:
Myślę sobie, że na postmortem, czy w ogóle jakieś uczenie, powiedzmy, z błędów, wyciąganie wniosków, należy spojrzeć nieco szerzej, bo często jak myślimy postmortem w grupach deweloperskich, to okej, jakiś techniczny problem się wydarzył i teraz pomyślmy, jak to ogarnąć, żeby w przyszłości ta sytuacja nie wystąpiła. Natomiast oprócz błędów technicznych, myślę, że tutaj jest to dosyć oczywiste, możemy rozpatrywać błędy procesowe. Na przykład jakieś problemy w komunikacji, o których tu mówiliśmy. Nie dogadaliśmy się, nie mieliśmy wspólnego języka. Coś tutaj w całym tym procesie nam nie wyszło. Spróbujmy ten proces poprawić.

Łukasz:
Może to jest nawet taka wielka rzecz, że na przykład brakuje jakiejś roli w zespole, jakiejś w ogóle osoby. Może rozwiązanie mięz, nie wiem, zatrudnimy testera.

Krzysztof:
Tak, tak, tak, to wcale nie musi być jakaś dziwna konkluzja. Mamy jeszcze błędy takie decyzyjne czy organizacyjne, bardziej wynikające z podejmowania decyzji przez management albo z kultury pracy, którą mamy, bo zawsze się tak robiło, więc dlatego tak zrobiliśmy, nie zastanawiając się nad tym, albo byliśmy zbyt optymistyczni, że przecież to, co tutaj może się złego wydarzyć, potestujemy na produkcji i tak dalej, i tak dalej. Więc to wszystko może być przedmiotem postmortem.

Łukasz:
Tak, jak w tym żarcie z brytwanką. Babcia ucinała, matka ucinała, a ty dlaczego ucinasz? No w sumie nie wiem, zapytamy się mamy. No w sumie nie wiem, zapytajmy się babci, no bo brytwanka była za krótka.

Krzysztof:
No właśnie, właśnie. Chcecie dłuższą wersję, to chat GPT na pewno podpowie. Dobrze, Łukasz, to ja bym może…

Łukasz:
To jest jeszcze ciekawe, jak już jesteśmy przy tych sztucznych inteligencjach. Może właśnie rozwiązaniem jest to, że na przykład trzeba podpiąć gdzieś proces kod review, jeszcze dodatkowego reviewera, na przykład takiego zautomatyzowanego jakiegoś chata czy cloda. Może tutaj dwa słowa jeszcze powiem właśnie o clodzie, z którego ostatnio dość dużo korzystam też fajnie jest dodać sobie takie skille typu security review no i można odpalić przy każdym po prostu pull requestie no to odpalamy tego skilla security review albo tam performance review no i dodajemy to do naszego procesu oczywiście nie trzeba tego brać zawsze na pałę co tam wypluje ale warto to przeczytać, zrozumieć, zastanowić się czy, czy czasem nie ma racji.

Krzysztof:
Tak, tak. Tutaj mam wrażenie, że się mocno skupiliśmy na action items i to jest oczywiście ważne, no bo za pomocą nich będziemy starali się uniknąć tego samego problemu w przyszłości, ale pewnie warto tak podsumować, że postmortem, żeby być wartościowym, to powinien być przede wszystkim blameless, czyli nikogo personalnie nie obarczać tym problemem, ale jednocześnie, tak jak tutaj powiedziałeś, to też nie może być zupełnego rozmycia i takiego bez wskazania tak naprawdę przyczyny. W procesie budowania tego dokumentu, o którym wspomnieliśmy, który może być, albo być może nawet powinien być efektem postmortem, chcemy zbierać fakty, a nie opinie, czyli taki powiedzmy timeline tego, co się wydarzyło, kto co zrobił, jakie były kolejne kroki. Chcemy przeprowadzić swego rodzaju wręcz dochodzenie po to, żeby zobaczyć, czy nie mogliśmy na przykład zareagować wcześniej, czy nie mogliśmy wyłapać jakiegoś problemu wcześniej, co zawiodło tak naprawdę. No i tutaj warto wspierać się różnego typu logami, metrykami, alertami, które wystąpiły. Być może, tak jak tutaj powiedziałeś, coś z nimi było nie tak. Być może były nam za często wysyłane, być może nie było jakiejś osoby odpowiedzialnej za przeglądanie tych rzeczy. Chcemy jak gdyby znowu zbadać, co nam się nie udało, co zawiodło po to, żeby to poprawić.

Łukasz:
Tutaj może jeszcze taki krótki wtręt polecajkowy. Dawno nie polecaliśmy żadnej książki. Już wydaje mi się, że książkę Pan raczy żartować, Panie Feynman, już tutaj polecaliśmy, natomiast w tym kontekście szykania błędów uczenia się na błędzie to ciekawa jest też książka A co Ciebie obchodzi, co myślą inni. Także Feynmana i to jeśli pamiętam to tam właśnie jest historia katastrofy promu Challengera i właśnie poszukiwania jakie błędy zostały popełnione, i na ilu różnych właśnie poziomach. Także tak, w temacie.

Krzysztof:
Tak jest, podpisuję się pod rekomendacją. Dobrze, ja bym jeszcze się może skupił na tym dokumencie postmortem, bo oczywiście zazwyczaj pod wpływem emocji jakiejś sytuacji, która się wydarzyła nie tak dawno, spotykamy się tak w ramach tego spotkania postmortem, dyskutujemy, rozmawiamy, staramy się znaleźć problemy, ale jeśli efektem tego spotkania nie będzie coś namacalnego, to wszyscy znamy dobrze życie, które nie lubi pustki i gwarantujesz, że za chwilę o tym wszystkim zapomnimy, bo zajmiemy się innymi ważnymi rzeczami.

Łukasz:
Tak, dlatego ciągle powtarzam to nieznośne action items. Nie wiem, czy tu jest jakieś fajne, dobre, polskie tłumaczenie.

Łukasz:
W mojej bańce tutaj zawsze się mówi o action items.

Krzysztof:
To jest na pewno mega ważna rzecz. To jest jakaś konkluzja, ale według mnie taki dobrze skonstruowany dokument postmortem powinien jeszcze zawierać opis tego, co się właściwie wydarzyło, kto został tym dotknięty, w jaki sposób to wykryto, jakie lekcje z tego wyciągnęliśmy i ewentualnie, jeśli jesteśmy w stanie, co było tą źródłową przyczyną. W sensie, jeśli taki dokument właśnie jest skonstruowany w ten sposób, czyli nie tylko konkluzji, nie tylko te możliwe działania później, te action items, ale również jaka była tutaj ścieżka wcześniej, jak ta historia wyglądała wcześniej i jak bardzo nam to gdzieś dotknęło użytkowników i biznes, no to jeśli mamy coś takiego i sytuacja, podobna sytuacja się wydarzy w przyszłości, no to będzie nam znacznie łatwiej nie tylko przeanalizować, ale też rozwiązać problem, więc do takiej nieco rozszerzonej wersji konstruowania dokumentu postmortem bym zachęcał.

Łukasz:
Tak, no i oczywiście jeszcze dodam tutaj kroki, które pozwoliły rozwiązać ten problem. To też jest kluczowe, gdyby jednak się zdarzyło. Że ten problem gdzieś tam wróci, no to żebyśmy byli w stanie w miarę łatwo i szybko powtórzyć te kroki naprawcze. Tutaj wydaje mi się, że jednym z takich głównych problemów to jest też brak takiego follow-upu. Ja tu jeszcze raz się odniosę do tego spotkania typu Sprint Retrospective. Oczywiście to się tak nie musi narzyzywać i też jakby nie musicie też pracować w Scrumie, natomiast fajnie jakby na takim spotkaniu cyklicznym, żeby przejrzeć właśnie te, Poprzednie problemy, to co tam ostatnio, czy przedostatnio, czy jeszcze wcześniej zostało omówione, opisane i zweryfikować po prostu wykonalność, czy tam stopień wykonania tych różnych zadań, które zostały do różnych osób przypisane.

Krzysztof:
No wszystko to wygląda naprawdę obiecująco. Zrobienie takiego postmortem, znalezienie przyczyn, znalezienie kolejnych kroków do wykonania, ale jak wiemy z praktyki występuje też sporo problemów z tym, żeby w jakiś sposób faktycznie czerpać dużo wartości z tego postmortem. Według Ciebie jakie najczęstsze problemy w tym obszarze widzimy?

Łukasz:
Wydaje mi się, że problemem może być to, że te dokumenty, te historie, one są gdzieś ukryte i nie są ogólnie dostępne dla wszystkich pracowników lub też może wiadomo, że tu trzeba zarządzać ryzykiem bezpieczeństwem, więc może niekoniecznie wszystko musi być publiczne czy tam publiczne w ramach firmy, Ale ja jestem zawsze zwolennikiem tego, żeby po pierwsze ten ownership dokumentów był wspólny, żeby te dokumenty żyły, czyli one nie mogą być Wordami, których co do zasady Wordy to są tak jak PDF-y, ich się już nie da edytować. Jak już ktoś zrobi Worda to już jest sztuka i każdy się boi natomiast przy narzędziach typu OneNote, Notion nie wiem Evernote nie wiem co tu jeszcze można wymyślić no to ich zaletą jest to że po prostu każdy może łatwo nawet jedno zdanie dodać, Usunąć jakieś swoje przemyślenie, też mamy tam zazwyczaj historię zmian, więc nie ma obaw, że ktoś coś ważnego usunie.

Łukasz:
To się musi łatwo dać wyszukać, musi być jakaś możliwość wyszukiwania. To może troszkę też zbocze z tematu, ale też fajnym pomysłem jest stworzenie też takiego publicznego rejestru ryzyk, czyli poskując się z takim cytatem z pewnej znanej serii filmów. I have a bad feeling about it. Czyli jak ktoś sobie tak pomyśli, no to fajnie, żeby mógł zgłosić gdzieś swoją obiekcję, najlepiej właśnie w cudzysłowie na piśmie, czyli w jakimś systemie. To może być po prostu jakiś ticket na dżirze, a może być też w tym samym narzędziu, o którym przed chwilą rozmawialiśmy. No i fajnie, żeby właśnie można było swoje, jakieś niepokoje, obiekcje zgłosić i je na bieżąco omawiać z osobą, która odpowiada za projekt produkt ownerem, czy też project managerem.

Krzysztof:
Dla mnie takie główne problemy związane z tym uczeniem się na błędach w IT to jest przede wszystkim niewdrażanie tego, co sobie określiliśmy w postmortem, czyli mamy świetne pomysły, niby wiemy, co nie działa, ale tak naprawdę to nic tam później nie zmieniamy, czyli Ten czas kompletnie do kosza. To podejście takie jednak związane z obarczaniem winą kogoś. Jakaś ściana wstydu, wręcz wytykanie palcami osób, które coś źle zrobiły, to nam kompletnie działa odwrotnie niż powinno. Ale też z drugiej strony tak zwane hero culture, czyli podejście, w której mamy osoby, które być może są ekspertami w danym obszarze. Szybko potrafią zafiksować bak i teoretycznie z punktu widzenia biznesu są takimi bohaterami, które ratują nam biznes, ratują produkt, szybko coś naprawiają, ale to jest takie przyklejanie tylko plasterka, jak wiemy. To nie jest fiksowanie tego, co naprawdę było przyczyną, nie naprawianie tych przyczyn źródłowych, ale właśnie łatanie, takie pobieżne załatwianie sprawy i to też na dłuższą metę się nie sprawdza. Jeśli chodzi o narzędzia, no bo tak mówimy tutaj trochę być może teoretycznie o pewnych rzeczach, ale warto korzystać z twardych danych, które mamy w procesie analizy tego, co poszło nie tak.

Krzysztof:
Monitoringi, alerty, analiza logów, szeroko rozumiane observability, korzystanie z gotowych templateów pod mostmortem, niewymyślanie tego na nowo, określone punkty, mamy template, bierzemy sobie taką templatkę i według tego postępujemy. Stosowanie tych narzędzi po prostu dużo nam tutaj ułatwia w całym tym procesie. Mówmy się, robienie postmortem to nie jest pewnie najlepsza część dnia programistów, jeśli jest taka konieczność, więc trzeba sobie tutaj to upraszczać i mieć po prostu na to też procedurę, żeby wiedzieć, jak to zrobić dobrze.

Łukasz:
Tak, ja jestem zawsze fanem wszelkiego rodzaju checklist i tego, żeby można było na takim… Półautomacie tego typu spotkania, brakuje mi słowa, że zaznaczamy po prostu czy doszliśmy do przyczyny, czy doszliśmy do tej root cause, czyli tej właściwej przyczyny. To jest też może ważne spostrzeżenie, żeby też niekoniecznie osiąść na laurach i jeszcze się zastanówmy, może znaleźliśmy jakąś techniczną właśnie przyczynę, ale może ta przyczyna jest gdzieś tam głębiej i ona tkwi właśnie w naszej kulturze organizacyjnej, że tak brzydko się wyrażę. I może gdybyśmy po prostu jakoś trochę inaczej działali jako firma, jako organizacja no to te błędy po prostu by nie powstały właśnie tak jak wcześniej rozmawialiśmy o tym języku i o tym, że klient może używać zupełnie innych sformułowań niż my w ramach systemu i tego typu, rzeczy powodują potem, jakieś nieporozumienia, które w efekcie powodują błędy w systemie.

Krzysztof:
Ja bym też zachęcał do tego, żeby nie być tak bardzo pesymistycznym. Mimo wszystko w tych naszych spotkaniach pod smortem. No oczywiście coś się wydarzyło, być może są jakieś straty, oby nie w ludziach. Musimy dojść do tego, co tam się złego wydarzyło, ale spróbujmy mimo wszystko taką jakąś tam dozę optymizmu tutaj wstrzyknąć. Poklepmy się trochę po pleckach, powiedzmy, że że okej, ale udało nam się to naprawić, doszliśmy do tego super z nas team, mamy taką naukę z tego. To jest dość potrzebne, żebyśmy po prostu nie patrzyli jako programiści na te spotkania, jako pójście na ścięcie, tylko żebyśmy w tym właśnie widzieli szansę na naukę.

Łukasz:
Tak, natomiast ja nie widzę nic złego w tym, że jeśli jednak znajdziemy winnego, żeby następnego change loga musiał napisać.

Krzysztof:
To się nie wyklucza.

Łukasz:
A jeśli są rzeczy, które i tak ktoś musi zrobić, no to czemu nie ktoś, kto na to zasłużył?

Krzysztof:
Dokładnie, uzbierał sobie te tokeny w padek. Dobrze Łukasz, myślę, że powiedzieliśmy już całkiem sporo o różnych rzeczach związanych z uczeniem na błędach. Spróbujemy to jakoś podsumować?

Łukasz:
Tak, jasne. Podsumujmy. To, żeby się trzymać tutaj naszego złotego podziału na trzy takie główne punkty. Po pierwsze, pamiętajmy, co jest celem tego postmortem, czyli celem jest znalezienie przyczyn problemów i zapobieganie im w przyszłości. Celem naszym jest to, żeby rozwiązać ten problem raz na zawsze.

Łukasz:
Żebyśmy mogli zainstalować pewnego rodzaju bezpieczniki, które nas po prostu przed tym problemem będą chronić. W żadnym razie naszym celem nie jest szukanie winnych. Po drugie, pamiętajmy, że problemy mogły nie tylko wynikać z jakichś technicznych niedoskonałości, z tego, że ktoś po prostu czegoś nie wiedział, zrobił coś źle. Te problemy mogą też wynikać z różnego rodzaju organizacyjnych problemów i też po znalezieniu tych przyczyn technicznych jeszcze zróbmy taki krok w tył, spójrzmy na całość z lotu ptaka i zastanówmy się, czy właśnie gdzieś tam systemowo nie możemy czegoś rozwiązać, na przykład przypisać jakiejś odpowiedzialności albo czy też gdzieś tą odpowiedzialność przesunąć.

Łukasz:
Ja właśnie lubię takie podejście, gdzie za pewne obszary systemów ktoś tam w zespole czuje jakąś mniejszą lub większą odpowiedzialność i jestem takim ekspertem, do którego zawsze można podejść w razie czego i przedyskutować pewne rzeczy, także to też tworzy myślę w zespole taką większą odpowiedzialność też. Co też jest samo w sobie wartością dodaną. No i trzeci tutaj, trzeci wnosek to follow-up, czyli nie tylko tutaj odbemnijmy to spotkanie, stwórzmy jakiś dokument, ale też zadbajmy o to, żeby te zadania były wypełnione, żebyśmy rzeczywiście coś zrobili, co nas skieruje w dobrą stronę.

Krzysztof:
Tak i stosując te wszystkie rady z pewnością będziecie się w stanie wiele nauczyć na własnych i cudzych błędach pracując w IT, Ale to wcale nie znaczy, że my zamykamy tą serię podcastów o wpadkach w IT, bo jeszcze przynajmniej kilka odcinków przed nami, na które już oczywiście teraz zapraszamy, jak i do innych serii podcastów, które razem z Łukaszem nagraliśmy. No i zapraszamy też niezmiennie na Solid Jobs, gdzie znajdziecie wiele ofert z IT i nie tylko, zawsze z widełkami wynagrodzeń. Jeśli do Waszego zespołu natomiast poszukujecie osób, to również zapraszamy właśnie w to miejsce, aby tam swoje ogłoszenie o pracę wystawić.

Łukasz:
Dzięki bardzo Krzysztof, a do naszych słuchaczy, jeśli macie jakieś uwagi, dajcie nam znać w komentarzach, czy na przykład poziom tutaj szczegółowości jest dla Was odpowiedniej, czy woli byście, żebyśmy bardziej stwierdzili szczegóły albo mniej. Staramy się tutaj tak wypośrodkować myślę, ale dajcie znać jak nam się po prostu nas słucha.

Krzysztof:
Dokładnie. Do tego zachęcamy, jak i również do oceniania podcastu. Dzięki Łukasz za dzisiaj. Do zobaczenia.

Łukasz:
Dzięki, cześć.