Uczenie się na błędach. Gość: Łukasz Drynkowski - POIT 306

Witam w trzysta szóstym odcinku podcastu „Porozmawiajmy o IT”. Tematem dzisiejszej rozmowy w serii podcastów o wpadkach w IT jest uczenie się na błędach.

Dziś moim gościem jest Łukasz Drynkowski, z którym mam przyjemność współtworzyć portal z ofertami pracy dla branży IT o nazwie SOLID.Jobs.

Główne myśli o uczeniu się na błędach z tego odcinka to:

• błędy są naturalną i nieodłączną częścią budowania produktów IT
• najszybciej uczymy się na błędach innych, ale najtrwalej zapamiętujemy własne wpadki
• największym fuckupem jest nieusunięcie przyczyn poprzedniego fuckupu
• organizacje, które nie popełniają błędów, zazwyczaj nie dostarczają niczego nowego
• blame culture skutecznie blokuje wyciąganie realnych lekcji z niepowodzeń
• postmortem to proces analizy incydentu, a nie polowanie na winnych
• celem postmortem jest zrozumienie przyczyn i zapobieganie podobnym sytuacjom w przyszłości
• postmortem robimy wtedy, gdy problem jest już rozwiązany, a emocje opadły
• efektem postmortem powinny być konkretne wnioski, zmiany procesowe i zadania techniczne
• action items muszą mieć właścicieli, inaczej pozostaną tylko dobrymi intencjami
• wartościowe postmortem jest blameless, oparte na faktach i rekonstrukcji timeline’u
• dane mają znaczenie – logi, alerty, metryki i obserwowalność pomagają oddzielić fakty od opinii
• postmortem to proces, a nie jednorazowe spotkanie – follow-up jest kluczowy
• ucząc się na błędach, nie zapominajmy o tym, co działa dobrze i co warto świadomie chronić

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 SOLID.Jobs na LinkedIn – https://www.linkedin.com/showcase/solid.jobs/
• SOLID.Jobs – https://solid.jobs/

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

https://porozmawiajmyoit.pl/306

Transcript

Wprowadzenie do błędów w IT

SPEAKER_00 0:00

To jest 306 odcinek podcastu Prostmafia MIT, w którym w cyklu rozmów zastrzeczem trękowskim z portalu z ogłoszczeniami pracy IT Stolic Jobs, który mam przyjemność współporzyć, dyskutujemy o wpadkach, błędach i fuckach w IT. Zapraszamy do słuchania i komentowania. A teraz życzymy Ci już miłego słuchania. Odpalamy. Doszkoło, niezbogo. Spotykamy się tutaj w ramach serii podcastów, porozmawiają o IT o błędach, fuck upach i różnego typu rzeczach, które nie wyszły w IT. No 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?

Uczenie się na błędach

SPEAKER_01 1:06

To myślę, że należą się pozdrowienia dla profesora Marcaka 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 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ć, no to nie uczyć się po prostu na własnych błędach. Zdźmy zawsze przyczyn tego, co się stało, tego, co spowodowało jakiś błąd, problemy, no i postarajmy się to wyeliminować.

SPEAKER_00 2:00

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

SPEAKER_01 2:19

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? S przypadki, gdzie po prostu ktoś musi powiedzieć, dobra, robimy ten deploy na produkcję, alopuszczamy nowy release, i tak bywa, że nie jesteśmy jeszcze na 100% pewni, a tak naprawdę na 100% pewnie 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.

Kultura organizacyjna i błędy

SPEAKER_00 3:33

Tak, na 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, tak, 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, ale taką szczerszą 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ć, no to jest też swego rodzaju, można powiedzieć, element kultury danej organizacji, tego, w jaki sposób ona podchodzi do błędów, tak, czy jest tam typowy Blame Carchel, 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. W takich organizacjach z taką kulturą oczywiście to uczenie jest znacznie lepsze, efektywniejsze, jest w ogóle możliwe.

SPEAKER_01 4:58

Tak, celem naszym zawsze powinno być dojście do przyczyn, problemów, a nie szukanie winnych, zapobieganie też takim sytuacjom w przyszłości. Natomiast też moim zdaniem nie wolno też popadać żadną skrajność, zarówno taki właśnie Bleme Culture, które tutaj szuka przede wszystkim winnych, jest zły, ale też sytuacja, w którym 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, tak, ale jeśli wiadomo, że tutaj ktoś zawinił, no to możemy się umówić w zespole na jakieś takie nierażące kary, typu, że tutaj ktoś będzie musiał w tym tygodniu wyczyścić ES, tak? Dokładnie, ale coś, co i tak trzeba zrobić, tak? Czy też właśnie ten nieszczęsny deploy na produkcję ktoś dopilnuje tak czasami? Różne są procesy, tak. Wiadomo, że w większości one są zautomatyzowane, ale warto zawsze w ramach takiego diploya 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 zamieniła, mogłaby, a też niekoniecznie ostatnio, bo żeby też nie było potem, programiści 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 sllocie, tak? Także tutaj trzeba uważać.

SPEAKER_00 6:50

To może pójść bardzo źle, jeśli źle tym zarządzimy. Ale wykonajmy może krok wstecz, bo zanim zaczęło.

SPEAKER_01 6:56

Jasne, jasne, tutaj za szybko poszliśmy.

SPEAKER_00 6:59

Tak, 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.

Proces post-mortem

SPEAKER_01 7:15

Tak, ale jeszcze raz to powtórzmy, że tu jakby nie chodzi o znalezienie winnego, tak? 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 dzirze, błąd powrócił, bo jakby brakowało tutaj wykonania tych czynności. No to jest też taki fuck up fuck up. Już coś by można było naprawić. Natomiast 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 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 powiedział, nie pamiętał, jakie było rozwiązanie, i było trzeba od nowa dochodzić, szukać, jakie było rozwiązanie danego problemu.

SPEAKER_00 8:41

Tak, gdybyście nie zaużyli, to zaczęliśmy z Łukaszem omawiać postmortem, czyli taki proces analizy incydentu po jego wystąpieniu. To co? Modzmy właśnie, jak do tego podejść z głową i co byśmy chcieli po przeprowadzeni takiego postmortem osiągnąć.

Action items i ich znaczenie

SPEAKER_01 9:00

No to tak, takie postmortem, to po pierwsze to jest coś, co robimy już po wystąpieniu problemu i po jego rozwiązaniu, czyli jakby nie jest to część samego rozwiązania tego, 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, 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źć właśnie swego rodzaju bezpieczniki, które tutaj byśmy mogli, że tak to powiem, zainstalować. Staramy się zrozumieć, gdzie ten błąd jakby wystąpił. Błędy mogły też mieć różne przyczyny. Jeden mógł mieć kilka różnych przyczyn, które się gdzieś tam ze sobą zderzyły, jakby jedna rzecz zamieniła, to może jeszcze jakoś by uszło, tak? 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 OneNotów i innego typu, i tego typu narzędzi, które po prostu pozwalają na to, żeby ten dokument żył i pozwalał też na zbiorową jakby edycję i zbiorow Ownershi tego. Stworzymy jakieś action itemy, no i w kolejnych iteracjach tutaj pilnujemy, co się stało. Także jeśli chodzi o taki proces agile, to też dobrym momentem na przeprowadzenie takiego Mortem, myślę, to jest Sprint Retrospektive, to jako takie miejsce, które po prostu zajmuje się nie tyle samym produkcją, co procesem.

SPEAKER_00 11:16

No właśnie, bo te action items, o których powiedziałeś, czy 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ć sytuacje, to niekoniecznie muszą być tylko zadania techniczne, tak, typu, no nie wiem, 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.

SPEAKER_01 12:04

Tak, to bardzo ciekawe, co powiedziałaś o tym różnym języku. To ja też zauważyłem kilka razy, błędy tego typu, że właśnie klient formuł, używał innego języka niż gdzieś tam my mieliśmy w kodzie, czy my w zespole się porozmawialiś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 Solid Jobs podać, gdzie mamy coś takiego jak ofer, 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, no to ofer jako job offer, sama ta oferta pracy ogłoszenie. 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, no to potem stawałem się takim nieformalnym light ownerem tego featurea, 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 requeste 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ć to, jeśli PLIK ma coś tam w nazwie, 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 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 te znowu się będę odnosił do tego samego 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 opiekowała i nie miała na przykład czasu, żeby to wszystko ogarnąć, że się tak wyraża. Różne można mieć tutaj podejścia, oczywiście, można, jako typowe aktion itemy, to jest dodanie konkretnych logów, dodanie jakichś także w chmurze monitoringu w pewnych sytuacjach, na przykład za automatyzowanie 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ół dostaję 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, troszkę ten problem był inny, ale załóżmy, że miejsce w bazie danych się skończyło, wielkość bazy danych tak w może. No i raz był taki problem, no to co dodaliśmy właśnie maile, które się wysyłały do nas hej, tu 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ż wysłanie tych maili. No i powstał jakiś mikroserwis, który ustawiał po prostu na panelu Admina jakąś czerwony komunikat, że widzieliśmy, że coś tam się zaczyna. że ta sytuacja już jest blisko.

SPEAKER_00 17:15

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.

SPEAKER_01 17:28

Tak, no niech pierwszy rzuci kamieniem ten, kto po pierwsze nigdy żadnego baga nie miał, a po drugie, nigdy nie zdarzyło mu się, że ten sam bug gdzieś wrócił.

Problemy w postmortem

SPEAKER_00 17:39

No i tak, tak, nieraz, nie dwa. Myślę sobie, że na postmortem czy w ogóle jakieś uczenie powiedzmy z błędu wyciągania 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 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, tak, 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ć.

SPEAKER_01 18:21

Może to jest nawet taka wielka, rzecz, że na przykład brakuje jakiejś roli w zespole, jakiejś osoby, może rozwiązaniem jest zatrudnimy te stera.

SPEAKER_00 18:29

Tak, tak, tak. To wcale nie musi być jakaś dziwna konkluzja. Mamy jeszcze błędy takie decyzyjne czy organizacyjne, tak, bardziej wynikające z podejmowania decyzji przez menadżment, 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, itd, i tak dalej. A więc to wszystko może być przedmiotem posmolnym.

SPEAKER_01 19:00

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ót.

SPEAKER_00 19:11

No właśnie, właśnie, chcecie dłuższą wersję, to Chad Gity na pewno podpowie. Dobrze, Łukasz, to ja bym.

SPEAKER_01 19:18

No 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 code review, jeszcze dodatkowego reviewera, na przykład takiego zautomatyzowanego jakiegoś czata, czy Kloda. Może tutaj dwa słowa jeszcze powiem, właśnie o klie, z którego ostatnio dość dużo korzystam. Też fajnie jest dodać sobie takie skile typu security review, no i można odpalić przy każdym po prostu pull requeste, no to odpalamy tego skila 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 czasem nie ma racji.

SPEAKER_00 20:14

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, tak, który może być, albo być może nawet powinien być efektem postmortem, chcemy zbierać fakty, ani opinie, czyli takie 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ć.

SPEAKER_01 21:37

Tutaj może jeszcze taki krótki wtrend polecajkowy dawno nie polecaliśmy żadnej książki. Już wydaje mi się, że książkę. Pan raczy żartować, panie Fejman, już tutaj polecaliśmy, natomiast w tym kontekście szukania błędów uczenia się na błędzie, to ciekawa jest też książka, a co ciebie obchodzi, co myślą inni. Także w Feinmana, i to, jeśli pamiętam, to tam właśnie jest historia katastrofy Promo 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.

SPEAKER_00 22:22

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ś namalnego, to wszyscy znamy dobrze życie, które nie lubi pustki i gwarantujesz, że za chwilę tym wszystkim zapomnimy, bo zajmiemy się innymi ważnymi rzeczami.

Konstrukcja dokumentu postmortem

SPEAKER_01 22:56

Tak, dlatego ciągle powtarzam to nieznośne action items. Nie wiem, czy tu jest jakieś fajne, dobre polskie tłumaczenie. W mojej bańce tutaj zawsze się mówiło action items.

SPEAKER_00 23:08

To jest na pewno mega ważna rzecz, to jest jakaś konkluzja, tak? Ale według mnie taki dobrze skonstruowany dokument pod smortem 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, ewentualnie jeśli jesteśmy w stanie co było tźdłową przyczyną. W sensie, jeśli taki dokument właśnie jest skonstruowany w ten sposób, czy nie tylko konkluzje, 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ł.

SPEAKER_01 24:06

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 i retrospektive, oczywiście to się tak nie musi narzązy i też nie musicie też pracować w kramie. 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 gdzieś tam zostało omówione, opisane, no i zweryfikować po prostu wykonalność, czy tam stopień wykonania tych różnych zadań, które zostały do różnych osób przypisane.

SPEAKER_00 25:11

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 siebie jakie najczęstsze problemy w tym obszarze widzimy.

SPEAKER_01 25:35

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 to 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 Wardy to są takie PDF-y, ich się już nie da edytować. Jak już ktoś zrobi Warda, 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 jakby nie ma obaw, że ktoś coś ważnego usunie. Mamy. To się musi łatwo dać wyszukać. Musi być jakaś możliwość wyszukiwania. To może troszkę też zboczy schematu, ale też fajnym pomysłem jest stworzenie coś 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 geżerze, 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 na bieżąco omawiać z osobą, która odpowiada za projekt ownerem czy też Proct Manadżerem.

SPEAKER_00 27:54

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 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 dokosza. No, to podejście takie jednak związane z obarczaniem winom kogoś, tak? Jakaś ściana wstydu, wręcz wytykanie palcami osób, które coś źle zrobiły, no to nam kompletnie działa odwrotnie niż powinno. No ale też z drugiej strony tak zwane hero culture, czyli podejście, w której mamy osoby, które być może na przykład są ekspertami w danym obszarze, tak, szybko potrafią zafiksować buck. 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, tak to nie jest fiksowanie tego, co naprawdę było przyczyną naprawianie tych przyczyn źródłowych, ale właśnie łatanie, takie pobieżne załatwianie sprawy, to też na dłuższą metę się nie sprawdza. Jeśli chodzi o narzędzia, bo tak mówimy tutaj trochę być może teoretycznie o pewnych rzeczach, ale warto korzystać z twartych danych, które mamy w procesie analizy tego, co poszło nie tak. Monitoring, alerty, analiza logów, szeroko rozumiane obserwability, korzystanie z gotowych template'ów podem postmortem, 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.

SPEAKER_01 29:54

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. Przeprowadzisz, tak. Prprowadzić tak. Zaznaczamy po prostu, czy doszliśmy do przyczyny, czy doszliśmy do tej Rootkoast, 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ża. 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.

SPEAKER_00 31:16

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ąć, tak. Poklepmy się trochę po pleckach, powiedzmy, że okej, ale udało nam się to naprawić, doszliśmy do tego super z nas, Team, mamy taką naukę z tego, to jest też potrzebne, żebyśmy po prostu nie patrzeli, 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ę.

SPEAKER_01 31:59

Tak, natomiast ja nie widzę nic złego w tym, że jeśli jednak znajdziemy winnego, żeby następnego czemloga musiał napisać tak. To się nie wyklucza. Tak. To jeśli są rzeczy, które i taktoś musi zrobić, no to czemu nie ktoś, kto na to zasłużył?

Podsumowanie i wnioski

SPEAKER_00 32:18

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

SPEAKER_01 32:30

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, żebyśmy mogli zainstalować pewnego rodzaju bezpieczniki, które nas po prostu przed tym problemem będą chronić. W żadnym razie naszym celem 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. 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ść zlotu, 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ś tam odpowiedzialność przesunąć. Ja właśnie lubię takie podejście, gdzie za pewne obszary systemów ktoś tam w zespole czuje jakieś mniej większą odpowiedzialność. 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 trzecie tutaj trzeci wniosek to follow up, czyli nie tylko tutaj odbędzijmy 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ę.

SPEAKER_00 34:35

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ący 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ć.

SPEAKER_01 35:17

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 jest dla Was odpowiedniejszy, bobyście mieliśmy bardziej żyli szczegóły albo mniej. Staramy się tutaj tak wypośrodkować myślę, ale dajcie znać, jak nam się po prostu nas spyka.

SPEAKER_00 35:43

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