[0:00] To jest 293 odcinek podcastu Porozmawiajmy IT. W duecie z Łukaszem Drynkowskim z portalu pracy IT Solid Jobs, który współtworzę bierzemy na tapet wpadki, fuck-upy i błędy w IT. Będzie trochę serio, trochę na luzie, ale zawsze na temat. Słuchawki na uszy i odpalamy. Cześć Łukasz. Cześć Krzysztof. Rozpoczynamy nową serię podcastów, w której będziemy mówić o różnego typu błędach, wpadkach i fuck-upach w IT. Dzisiejszy odcinek poświęcimy błędom i kosztom, które z tymi błędami są związane. Tak jak wiemy, błędy są immanentną, niezbywalną cechą i właściwością IT.

[0:39] Mówi się o tym, że taki kod, który jest bez błędu, to kod, który nie powstał i coś w tym jest. Ale kod jako taki to nie jest jedyne miejsce, czy nie jedyny rodzaj błędów w IT, o którym możemy mówić. Jest tego niestety znacznie więcej i temat jest szerszy, więc na początku Łukasz zapytałbym Ciebie, żebyś powiedział może trochę o jakich rodzajach, jakich typach błędu IT w ogóle możemy mówić. Zacznę może od tego, że ponieważ planujemy tutaj cały cykl odcinków o błędach, także w dzisiejszym odcinku skupimy się na źródłach i konsekwencjach błędów oraz na ich kosztach. No i tutaj, żebyśmy nie popadli w taki błąd myślowy, że błędy to tylko są błędy, które gdzieś tam w kodzie można znaleźć jakieś bugi, no to będziemy rozmawiać o różnych typach błędów, właśnie o tych błędach technicznych, ale także o błędach procesowych, organizacyjnych.

[1:41] Na przykład błędy komunikacji oraz także o błędach, które wynikają z błędów takich ludzkich, czyli takie błędy, incydentalne, o to jest to, co chciałem powiedzieć, czyli coś, co wynika na przykład ze zmęczenia albo z rutyny. Tak, dokładnie. Błędy, czyli jakieś niezamierzone, niewłaściwe działanie, którego się nie spodziewaliśmy, którego nie przewidzieliśmy, które w jakiś sposób negatywnie wpływa na produkt, na użytkowników, na całą firmę. No i nie tylko te właśnie błędy techniczne wynikające z jakichś przeoczeń, z jakiegoś braku wiedzy, być może kompetencji mogą wystąpić, to mogą być też właśnie różnego typu błędy wynikające z nieco bardziej miękkich tematów, jak na przykład jakieś luki w komunikacji, czy też wynikające zwyczajnie z tego, że jesteśmy ludźmi. Tak jak już na początku wspomniałem, po prostu w IT musimy się pogodzić z tym, że te błędy będą.

[2:41] Co jeszcze pewnie poruszymy dzisiaj w rozmowie, to to, że jesteśmy w stanie sobie w jakiś sposób z tymi błędami radzić, czy w jakiś sposób je być może przewidywać, minimalizować, ale nigdy nie dojdziemy do takiej sytuacji, że je zupełnie wyeliminujemy. Tak, ja jeszcze dodał tutaj, że testerzy zapewne rozróżniają błędy, defekty, usterki, mają na to osobne słowa, tak jak Eskimosi na śnieg, natomiast my tutaj dla jasności jesteśmy tylko szarymi programistami,

[3:17] także będziemy tutaj naszą ignorancją nazywać błędem to wszystko jakby w jednym worku. Dokładnie, no to może rozpocznijmy i powiedzmy skąd się te błędy w ogóle biorą, czy to tylko ten biedny programista jest źródłem, przyczyną i pramatką wszystkich błędów, czy też może z czegoś innego jeszcze może to wynikać?

[3:43] Klasyk mówi, to wszystko wina tych wrednych programistów, natomiast tak naprawdę oczywiście źródła są różne. Ja bym tutaj szukał przede wszystkim, jeśli mówimy o tych konsekwencjach błędów, to musimy patrzeć wstecz, czyli nie ta praca programisty kodzenie, ale gdzieś wcześniej mogły nastąpić jakieś błędy, na przykład błędy w procedurach. Albo też brak tych procedur, albo co najgorsze procedury są i są nawet fajne, tylko po prostu one są martwe, nikt ich nie przestrzega.

[4:23] Albo nawet ktoś przestrzega, ale tutaj jestem tym szefem, adminem kimś, no to aż spieszy mi się, no to zrobię właśnie coś i wiem nawet, że powinno się coś zrobić w jakiś konkretny sposób, ale tutaj kliknę, zaznaczę jakiegoś checkboxa override i idzie merge, prosto na mastera.

[4:47] No i z tego powodu myślę, powstaje wiele błędów, że po prostu ignorujemy te istniejące procedury, istniejące dobre praktyki.

[4:58] Też może to być tak, że to jest jakiś pośpiech, w dobrej wierze to możemy robić. Chcemy po prostu, żeby klient dostał szybko jakieś rozwiązanie albo błąd wynika z tego, że naprawiamy właśnie jakiś błąd, a przy okazji wprowadzamy inny. To jeśli ten system ma słabą spójność, to może z tego wynikać problem, że w jednym miejscu coś zmieniliśmy, a psujemy coś innego. Czyli tak, pośpiech, jakieś założenia, wręcz wymagania były błędne. Często, to się często zdarzało, że w tych wymaganiach znajduje się błąd i tutaj zachęcam do naszego poprzedniego odcinka, czyli wiedza domenowa, to może chronić nas przed tymi błędami, jeśli po prostu my też potrafimy zauważyć w tych wymaganiach jako programiści, potrafimy zauważyć ten błąd i skonsultować coś z autorem wymagań. No i myślę, że jeszcze idąc jeszcze dalej i na taki najszerszy w ogóle widok, no to błąd, który polega na tym, że w ogóle robimy nie to, co trzeba. Tworzymy nie ten system, którego ktoś oczekuje, czy jakby tworzymy system, który nie rozwiązuje pewnych problemów biznesowych. Tak jak rozjeżdżamy się z tą realizacją. Tak, rozjeżdżamy się zupełnie z realizacją. Przyszły jakieś pieniądze z KPO do nas.

[6:25] I robimy po prostu sztukę, a nie zastanawiamy się, czy to rzeczywiście pomaga tym użytkownikom. … W rozwiązaniu rzeczywistych, ludzkich problemów, czy też codziennych problemów, tylko po prostu robimy system, który jest niewygodny w użyciu, który wprowadza więcej problemów. Też pamiętam z moich doświadczeń z pracy z użytkownikami systemu, kiedy informatyzowaliśmy służbę zdrowia, to słyszeliśmy często takie hasła od lekarzy, że panie, ale to ja będę miał więcej roboty, bo będę musiał tutaj dodatkowo wprowadzać. Tak.

[7:08] Wprowadzać, będę musiał zrobić moją robotę, którą normalnie robiłem, napisać coś na kartce, a potem jeszcze przepisać to do systemu. I tak, no to jakby są takie problemy u podstaw, bym powiedział. No tak. No właśnie, czyli z tego, co powiedziałeś, jeśli chodzi o to, skąd się te błędy biorą, to z jednej strony mamy pewien być może brak kompetencji, jakieś przeoczenia ze strony osób, które wytwarzają tą technologię, ale te osoby nie żyją jakoś w oderwaniu od całego ekosystemu, czyli to wejście, jeśli jest złe, czyli wymagania albo też presja czasu jest zbyt duża, no to to nam może generować błędy. niewłaściwy dobór technologii również. Tak, wydaje mi się, że tutaj taki problem podstawowy i wydaje mi się, że też o tym mówiliśmy w jednym z poprzednich odcinków, jeszcze tam z dwa sezony temu, że wymagania nie podlegają w większości firm też nazwijmy to testowaniu, czyli nikt nie sprawdza poprawności wymagań, Tylko od razu od analityka wymagania trafiają do programisty, który realizuje te punkty.

[8:22] Kropki, kolejne odhacza checkboxy. Natomiast wydaje mi się, że wymagania także powinny być walidowane, weryfikowane i sprawdzane, czy rzeczywiście to jest to. Czasami, to też ja często powtarzam, nie każdy problem też musi być rozwiązany wewnątrz systemu. Możliwe, że część po prostu problemów trzeba rozwiązać poza systemem poprzez wysłanie jakiegoś maila albo zainstalowanie komunikatora na komputerach użytkowników. Może niekoniecznie każdy system musi mieć wbudowany czat. Tak, to jest właśnie to, co powiedziałem na początku, że najlepszy kod to jest kod, który nie powstał i też wrócę do któregoś tam odcinka, w którym rozmawialiśmy o tym, że programista to tak naprawdę powinien być szerzej inżynier, który sugeruje rozwiązania i być może w niektórych przypadkach rozwiązaniem jest nienapisanie kodu albo użycie już czegoś, co istnieje niż tam rzeźbienie od nowa. Tak, najlepsze dni wiadomo, to są takie, kiedy bilans napisanego kodu jest ujemny.

[9:26] Tak, to są najlepsze. Wyruszyliśmy kilkaset tysięcy linii kodu i zastąpiliśmy kilkoma, no to… To się powinien należeć medan, takiemu programiście. Zgadza się, to jest sukces. Dobrze, czyli wiemy skąd te błędy się biorą. Okazuje się, że z różnych rzeczy,

[9:45] nie tylko technicznych. To teraz może przyjrzyjmy się konsekwencjom, na co te błędy mogą wpływać i czy to są znowu tylko problemy techniczne, czy też konsekwencje techniczne, czy też może idziemy tutaj dalej. To, co widać na pewno, to są konsekwencje finansowe.

[10:04] To jest to, co tutaj najbardziej boli dysydentów, czyli to jeśli taka wpadka ma konsekwencje związane z tym, że musimy pokryć jakieś koszty. Po pierwsze musimy pokryć oczywiście te koszty naprawy, ale możliwe, że też jakieś umowy SLA zostały niedopełnione, czyli też koszty tutaj prawne. Możliwe, że to był błąd, który spowodował jakiś wyciek danych czy udostępnienie danych nie tej osobie, która powinna mieć dostęp. No i tutaj wchodzi RODO, no i też koszty takie czasowe, żeby obsłużyć w ogóle ten błąd, żeby zgłosić, zrobić samodonos. Oczywiście koszty mogą tutaj się też pojawić jakieś prawne, właśnie, że musimy wynająć czy zapłacić tak prawnikowi za to, żeby obsłużył tą sytuację. Koszty wizerunkowe tracimy tutaj, jeśli klienci tutaj widzą, że coś u nas nie działa.

[11:07] Był jakiś downtime albo Niebezpiecznik o nas napisał, no to oczywiście możemy tego nie zauważyć na przykład od razu, ale możemy zauważyć w dłuższym okresie czasu przez to, że po prostu nie będzie napływu nowych klientów albo będzie utrata tych istniejących. Także myślę, że wachlarz kosztów jest szeroki. Na wiele rzeczy to wpływa. Dokładnie, jeszcze może do tych finansowych bym dodał, że często to jest też taki koszt utraconych potencjalnych zysków, prawda? Jeśli coś nie działa albo coś się źle nalicza, no to wtedy potencjalnie tracimy, a sama obsługa błędów w postaci, no nie wiem, chociażby załatania tego w kodzie, ale też no przetestowania, też jakiegoś kosztu ze strony supportu i tak dalej też na to wszystko się składa, więc samo naprawienie błędów, te błędu też kosztuje, no to wszystko się dokłada gdzieś do tej kubki właśnie finansowych konsekwencji. No i oczywiście tutaj dochodzą też błędy związane z bezpieczeństwem i z tym, że osoba nieuprawniona mogłaby mieć dostęp albo miała dostęp do danych, no to to otwiera cały wszechświat problemów i konsekwencji.

[12:20] O których myślę, że opowiemy w jakimś odcinku. Kolejnym odcinku, żebyśmy tutaj byli bardziej sfokusowani na przedstawienie tych efektów i przyczyn, a nie wchodzili w takie szczegóły. Tak jest. Zazwyczaj jest tak, że im dużej ten błąd nam w systemie siedzi, tym większy koszt może generować, ale też trzeba jasno sobie powiedzieć, że nie wszystkie błędy warto albo ma sens naprawiać, bo to jest kwestia jakiejś tam świadomej decyzji i I ten tak zwany dług techniczny, często jesteśmy świadomi, że jakieś tam problemy występują, błędy występują, ale na przykład ich wpływ na nasz biznes jest na tyle mały, że powiedzmy wręcz nie opłaca się tego naprawiać, albo wiemy, że za chwilę dana funkcjonalność zostanie przepisana, zmieniona.

[13:11] Usunięta, jeśli powstaje tylko na chwilę pod jakąś akcję marketingową, też nie ma wówczas sensu wszystkiego łatać. Więc myślę, że tak jak tutaj zasugerowałeś, pewnie poruszymy ten temat w którymś z kolejnych odcinków. Tak, to cały temat zarządzania błędem i tego, czy właśnie decyzji, czy naprawić, kiedy naprawić, to są też bardzo ciekawe tematy. Stay tuned. Idealnie by było, gdybyśmy zawsze mieli nie tylko świadomość,

[13:39] ale też możliwość naprawy tych błędów, które są związane z naszym kodem, z naszym systemem. No ale często polegamy na zewnętrznych bibliotekach, na jakimś zewnętrznym API, na dostawcach różnych rozwiązań. No i wtedy musimy w jakiś sposób mitygować te błędy, które nie powstały z naszej winy albo nie występują u nas i nie jesteśmy zawsze w stanie tego naprawić. Więc takie zarządzanie tymi błędami również ze strony zewnętrznych providerów musi nastąpić. Przypomniał mi się też pewien klasyk, który mówił, żeby nie korzystać z zewnętrznych bibliotek, bo tam są błędy, lepiej wszystko samemu pisać.

[14:20] Tak jest, to jest idealne rozwiązanie wtedy. Na pewno porodzimy sobie ze wszystkim i będziemy w stanie to udawać. Oczywiście mam nadzieję, że wszyscy słuchacze tutaj wyczuli ironię. Tam była gwiazdka. I nie wyłączyli odbiorników. Okej, to tutaj też ciekawy właśnie wątek, jeśli już mówimy o, bo mówisz o poleganiu na zewnętrznym API, ale też może być tak, że ktoś polega na naszym API. I też ile razy się spotkałem z tym, że np. Ktoś korzystając z jakiejś biblioteki czy z jakiegoś API polegał na jakimś błędzie.

[14:56] Który przez lata tam był i teraz przez to, że my naprawimy ten błąd, to możemy komuś zepsuć funkcjonowanie jakiegoś klocka, który polegał na nas. Taki efekt domina tutaj możemy też osiągnąć. Często też jest tak, ja często tak mam, że naprawiam jeden błąd i po naprawieniu błędu ujawnia się jakiś inny błąd, bo właśnie był ukryty pod spodem, albo właśnie coś zależało od tego błędu, albo nie zależało, ale po prostu naprawiając jeden błąd, czy to dopiero zaczniemy widzieć w logach jakieś inne problemy, które były pod spodem, czy też po prostu naprawiając jedną rzecz odsłaniamy ten inny problem.

[15:42] Tak, usuwamy kamienia, tam pod nim mnóstwo robali, to się zdarza. Ta jedna domena tych błędów technicznych albo powstałych z powodów technicznych to jest jedna rzecz i pewnie jeszcze nieraz do tego tematu wrócimy, ale myślę, że jeśli mówimy szerzej o błędach w firmach IT, to też trzeba wspomnieć o kulturze organizacyjnej, która znacząco może wpłynąć na to, jak sobie radzimy z tymi błędami, czy sobie radzimy, czy tych błędów powstaje więcej z racji na to, że są jakieś wypatrzenia w tej kulturze. No i tutaj myślę, że naprawdę warto zaznaczyć, że takie szukanie winnych, czyli blame culture, obwinianie kogoś za to, że ten błąd powstał, pokazywanie go na świeczniku to jest chyba najgorsze z możliwych podejść. Tak, to do niczego nie prowadzi. Dokładnie, wręcz pogłębia problem i trzeba tutaj też powiedzieć, że wtedy, jeśli będziemy w ten sposób postępować, to ludzie będą chować, będą ukrywać różnego typu błędy, których są świadomi i niech będą chcieli tego ujawnić, żeby właśnie nie wystawić się na tego typu szykanowanie, więc trzeba być też tego świadomym.

[16:58] Najlepiej, jeśli mamy do tego takie zdrowe podejście, czyli ok, jesteśmy świadomi, że taki błąd powstał, czegoś tam się uczymy na podstawie tego błędu, żeby nie powielić w przyszłości, ale jak gdyby bijemy się w pierś i naprawiamy i idziemy dalej. A też pamiętajmy, że im wcześniej wykryjemy ten błąd.

[17:18] No to tym mniejszy będzie koszt jego naprawy. Tego typu właśnie kultura organizacyjna, gdzie szukamy winnych, a nie szukamy rozwiązań, no to prowadzi do tego, że te koszty rosną po prostu. Tak, no i też takie szukanie winnych skutecznie nam hamuje wszelkiego typu innowacje czy też inwencje, no bo jeśli robimy coś niestandardowo, korzystamy z jakichś jeszcze wcześniej nieużywanych rozwiązań, no to mamy sporą szansę na popełnienie błędów. Jeśli ten błąd będzie gdzieś tam wytykany jako taki, no to będziemy unikać oczywiście wchodzenia w jakieś nieoczywiste rozwiązania, bo próbowanie czegoś nowego, żeby się nie narazić na takie sytuacje, więc musimy być świadomi, że strzelamy sobie w kolano, jeśli właśnie taki blame culture u nas uprawiamy. I tutaj myślę, że też ciekawy jest wątek, bo wydaje mi się, że kolejnym typem błędu, który wynika z jakichś organizacyjnych problemów, to jest to, że nie, że coś nie działa albo działa źle, tylko że nasz proces działa wolno. I na przykład nie dostarczamy na czas, albo konkurencja zrobi to szybciej, albo też ta słynna prognoza pogody na wczoraj.

[18:35] To też jest jakby taki rodzaj błędu, czyli to, że działam w ten sposób, że po prostu działam wolno. No tak, to jest z pewnością problem. Innym typem błędów, który ma konsekwencje finansowe, czasowe, a niekiedy wizerunkowe, to jest błąd w nieskutecznej, niewłaściwej rekrutacji i to potrafi naprawdę nas mocno ugryźć. I czy to jest właśnie sponsorowany fragment?

[19:00] Nie jest, ale to jest idealne miejsce, idealny spot, żeby wspomnieć o tym, że mamy skuteczne narzędzie i rozwiązanie, jak sobie właśnie z tym błędem radzić. Także zapraszamy wszystkich na Solid Jobs. Szukajcie i wybierajcie pracowników mądrze. Solid Jobs to nie tylko właśnie job board, ale też staramy się zapewnić wsparcie także w wyborze tego kandydata, dając różnego rodzaju narzędzia wspierające proces rekrutacji. Właśnie, bo to się wszystko chyba zaczyna od tego ogłoszenia o pracę, gdzie jeśli jest tam powiedzmy ściemnianie, jeśli jest nie w pełni opisywanie tego, czym się będziesz zajmował, jeśli tam nie ma widełek wynagrodzeń.

[19:41] No to wiesz, to ciężko tutaj oczekiwać, że dostaniesz z takiego procesu kogoś wartościowego, kogoś sensownego, skoro właściwie nie wiesz, kogo szukasz. Tak, albo uwielbiam rozmowę rekrutacyjną, pytania o najnowsze feature’y w .NET 9. A potem przechodzisz i projekt w dotnecie 4,5. No tak, tak. No właśnie. Więc taki rozstrzał, takie przestrzelenie się teorii z rzeczywistością też może mieć miejsce. Warte korzystać z narzędzi, które nam ten proces ułatwiają i które już na samym jego początku zapewniają jakieś tam dopasowanie wstępne kandydatów właśnie do tego, kogo faktycznie potrzebujemy w firmie. No bo ten błąd w rekrutacji może nas dużo kosztować, wpłynąć nie tylko na finanse, ale i na wydłużenie czasu realizacji projektów, jak i na morale zespołu potrafi być naprawdę doskwierający. Także tu kadry są najważniejsze i dobrzy ludzie naprawdę robią różnicę i to jest tutaj parafraza, ostatnio słyszałem. Kto w ogóle tą teorię wymyślił, może nie będę tutaj tego zdradzał, można sobie poszukać w internecie. Tak jest, tam odsyłamy. Odsyłamy do internetów.

[21:04] To się musiało tak skończyć. Dobrze, powiedzieliśmy już o tym, że prawidłowe, zdrowe reagowanie na błędy to jest swego rodzaju postmortem, to jest nauka na bazie tego, co poszło nie tak, jak to możemy naprawić w przyszłości, jakieś tam dostosowanie naszych procesów, jakaś retrospektywa na ten temat. Złe podejście, złe reagowanie to jest szukanie winnego albo wręcz zamiatanie pod dywan i udawanie, że tych błędów nie ma, to jest oczywiście bardzo krótkowzroczne podjęcie. Postępowanie. Ale znacznie lepsze, tak jak tutaj wcześniej powiedziałeś, jest minimalizowanie ryzyka błędu, czyli niedopuszczenie do tego, żeby ten błąd powstał i co tutaj moglibyśmy wymienić, jakiego typu narzędzia ku temu stosować? Przede wszystkim, no to uczmy się na swoich błędach, albo najlepiej na cozych błędach. Miejmy w procesie właśnie to, co powiedziałeś, post mortem, czyli jakieś spotkanie, z którego powinna jakaś notatka powstać, z którego może powinni Musieliśmy wprowadzić jakieś zmiany w naszych procesach. Też jeśli to są błędy w kodzie, no to od razu zautomatyzujmy też to, żeby wykrywać tego typu błędy. Ja z doświadczenia powiem, że błędy lubią wracać.

[22:16] Lubią wracać. Często jest tak, że coś naprawimy i czy to przez jakiś potem błędny merch, czy też po prostu ktoś popełni ten sam błąd za jakiś czas, nie będąc świadomy tego, że to zostało jakoś tam rozwiązane. Także automatyzujmy, monitorujmy problemy. Jeśli mieliśmy na przykład jakieś problemy z bazą danych na przykład, no to możemy zautomatyzować to, żeby dostawać wcześniej już alerty, jeśli coś się dzieje, jakieś thresholdy pozakładać i dostać po prostu jakiś mail. Natomiast tu też trzeba uważać, bo może być taki problem, że dostajemy potem tysiące tych maili i nie zauważymy czegoś. Ignorujemy, tak. Ignorujemy, tak, jeśli za dużo. Także też musimy dobrze wybrać te metryki, które mierzymy i które na bieżąco sprawdzamy. Co tu jeszcze możemy zrobić? No oczywiście wszystko, co można, automatyzujmy, czyli CI, CD, czyli też wprowadzajmy na przykład w proces code review jakąś automatyzację.

[23:25] Która też wstępnie pewne rzeczy nam, jakiś linter podpowie. Standaryzujmy, wprowadzajmy. ja jestem fanem różnego rodzaju też checklist, także polecam. Tak, no obecnie mamy naprawdę mnóstwo narzędzi do praktycznie każdej technologii, które da się wpiąć właśnie w nasz pipeline CICD, które będą w stanie wiele rzeczy zweryfikować od prostych winterów po jakieś potencjalne security issues, po analizę statyczną i mnóstwo, mnóstwo tego typu rzeczy, które są w stanie nam wyłapać problemy. Trzeba pamiętać, że te narzędzia często są rozszerzalne, czyli jeśli często gdzieś tam spotkamy się z jakimś typem.

[24:09] Problemów specyficznym dla naszej aplikacji, to możemy napisać coś, co będzie nam to już automatycznie weryfikowało i to naprawdę potrafi już na tym pierwszym etapie wyeliminować sporo problemów. Tak i pamiętajmy, że na bank nie jesteśmy pierwszymi, którzy z danym problemem się spotkali, także warto to sprawdzić, jak inni sobie z tym poradzili. Mówiliśmy tutaj, Krzysztofie, dużo o błędach właśnie związanych z samym tym

[24:37] rozwojem oprogramowania. Przejdźmy może do błędów takich zarządczych, czyli co menadżerzy robią źle.

[24:45] Właśnie to nie jest może pierwsza rzecz, która przychodzi nam do głowy, kiedy myślimy o błędach w IT, ale dopiero co skończyliśmy serię podcastów dla właśnie liderów i menadżerów w IT i wiemy, że to jest bardzo istotny klocek i element każdego zespołu i powiedzmy osoba, która ma wpływ na wiele różnych rzeczy. Czy jeśli taki menadżer źle się komunikuje albo wręcz właśnie się nie komunikuje, jeśli ten przekaz tej osoby jest niejasny do zespołu, brak ściśle wyznaczonych priorytetów, jeśli jest tam mikromanagement albo wręcz za dużo zadań delegowanych na członków zespołu, no to budujemy sobie jako menadżer takie środowisko właśnie do powstawania błędów. Więc trzeba tutaj być świadomym, że to nie tylko literówki w kodzie i jakieś tam niedopatrzenia w pętli budowanej przez programistę są źródłem błędów, ale wszystko zaczyna się znacznie wcześniej od wymagań, od ustalania priorytetów, od tego jaki jest rodzaj komunikacji menadżera z zespołem. Już na tym styku mogą powstawać jakieś niedomówienia, niedopatrzenia, co później przełoży się na niedziałające funkcjonalności i potencjalne koszty różnego typu dla całej firmy. Tak, ja tu jeszcze chciałbym tylko dorzucić brak albo błędne zarządzanie problemami i błędami.

[26:11] To też jest coś, co często gdzieś tam widzę. Wspominaliśmy tutaj o rekrutacji.

[26:17] Gdybyśmy się chcieli przestawić na drugą stronę tego stolika rekrutacyjnego i postawić w butach osoby kandydującej, to myślę, że bardzo doceniane jest, a przynajmniej ja tak zawsze do tego podchodziłem rekrutując osoby, jeśli mówimy na tej rozmowie kwalifikacyjnej, jakiego typu błędy gdzieś tam popełniliśmy i czego się z tego nauczyliśmy, to jest jak gdyby jeszcze ważniejsze, wtedy pokazujemy, że jesteśmy osobą, która uczy się na własnych błędach, która potrafi coś z tego wyciągnąć i która też jest świadoma tego, że błędy po prostu się zdarzają, natomiast istotne jest, żeby właśnie coś z tego wyciągać. Nie unikajmy mówienia o błędach, problemach, jakichś swoich wpadkach z przeszłości. To myślę, że nawet buduje taki… Cieplejszy wizerunek człowieka, który jest bardziej ludzki, a nie robotyczny. No i fajnie, ale wydaje mi się, że jednak najlepiej to się uczyć na cudzych błędach. Łatwo powiedzieć.

[27:18] Ale pewnie trudniej zrobić. Jak myślisz, jak można się uczyć na cudzych błędach? Gdzie jakby tą wiedzę zdobywać? Tak, takim najbardziej oczywistym miejscem jest po prostu czytanie albo oglądanie o tym, jak inni gdzieś tam się tą informacją dzielą. To jeszcze w Polsce nie jest takie bardzo popularne, żeby dzielić się różnego typu wpadkami i błędami. Myślę, że na zachodzie jest to znacznie popularniejsze, ale jak możemy sobie tutaj gdzieś wyszukać różnego typu blogi osób, które już dłuższy czas o czymś piszą, to tam możemy znaleźć pewnie właśnie informacje, co poszło nie tak, jakiego typu wnioski ta osoba wyciągnęła. To jest właśnie dobry sposób uczenia się na podstawie czyichś błędów, ale też z mojego doświadczenia konferencje są do tego dosyć dobrym miejscem. Nie tylko udział w prelekcjach, które gdzieś tam właśnie mówią o naukach wyciągniętych z błędów, ale w kuluarach, bardzo często rozmawiając z innymi osobami, które zajmują się podobnym tematem.

[28:23] Można się powymieniać właśnie tego typu informacjami, co nie działa i jak sobie z danym tematem poradzić.

[28:32] I oczywiście tutaj jeszcze może podsumę takie dwa miejsca. Udział w różnego typu spotkaniach typu Fuck Up Nights w niektórych miastach polskich właśnie tego typu spotkania się odbywają. Tam raczej powiedziałbym, że takie biznesowe fuck upy są omawiane, ale myślę, że to też może być istotne. No i ostatnim źródłem, który znalazłem dosyć ciekawym miejscem jest taka strona failory.com, oczywiście to tam w notatkach do odcinka zawrzemy.

[29:06] Gdzie możemy znaleźć historię różnego typu startupów, różnego typu projektów technologicznych, które gdzieś tam się nie udały, nie powiodły, coś tam się wysypało, więc mamy tutaj bardzo duży. Dużą bibliotekę historii, które mówią nam o tym, że coś tam poszło nie tak i

[29:25] to jest pewnie doskonałe źródło, żeby czegoś się nauczyć i nie powtarzać tego błędu na sobie. Powiedzieliśmy dzisiaj o tym, jakie są rodzaje błędu w IT i trochę jak sobie z tym tematem radzić, jak również jakiego typu konsekwencje mogą z tego tytułu wynikać. Będziemy tego typu różne tutaj wątki, tematy jeszcze pewnie rozszerzać w kolejnych odcinkach tej serii o IT Fuckups. A teraz Łukasz poprosił mnie, żebyś może w kilku żołnierskich słowach podsumował ten nasz dzisiejszy odcinek. Także tradycyjnie postaram się tutaj podsumować to, o czym mówiliśmy. To po pierwsze, pamiętajcie, że błędy to nie tylko bugi w kodzie. Błędy mają różne źródła, w tym źródła organizacyjne i ludzkie. To jest pewnie pierwszy taki punkt. Drugi mój punkt, no to pamiętajcie, że najgorszy błąd, jaki można popełnić, to błąd w czasie rekrutacji. Jest to naprawdę ciężkie do odkręcenia i zajmuje dużo czasu, dużo pieniędzy. Jeśli jesteście menadżerem, no to to jest najważniejsza rzecz, którą możecie zrobić dobrze.

[30:31] Zrekrutować osobę do zespołu. Pamiętajcie o tym, że konsekwencje błędów są różne nie tylko finansowe albo mogą być finansowe, ale gdzieś tam w czasie odwleczone. Też zabezpieczcie się nie tylko przed tymi skutkami finansowymi, ale też postarajcie się przeciwdziałać innym rodzajom konsekwencji. No przede wszystkim no to uczcie się na tych błędach i reagujcie, twórzcie różnego typu automatyzacje, które zabezpieczy Was przed tym, że ten błąd nie powróci albo się nie powtórzy.

[31:11] No bo zazwyczaj wcześniej czy później ten problem wróci no i bądźcie na to gotowi albo właśnie przeciwdziałajcie, żeby to się nie stało. Tak, z tej naszej dzisiejszej rozmowy jednoznacznie wynika, że błędy w IT to nie jest tylko temat dla programistów, ale i dla menadżerów, i dla właściwie całej organizacji, całej firmy. Jest to temat, który może szeroko dotykać całą firmę, więc tym bardziej zapraszamy na kolejne odcinki właśnie tej serii podcastów o roboczej nazwie IT Fuckups. Myślę, że będziemy tutaj poszczególne te tematy i wątki, które gdzieś zaznaczyliśmy rozbijać jeszcze na czynniki pierwsze. Już teraz zapraszamy do słuchania. No i na koniec standardowo też przypominamy, że na Solid Jobs znajdziecie oferty pracy już nie tylko z branży IT, ale i z wielu innych, gdyż Solid Jobs otworzyło się na inne branże. Ale nie zmienia się to, że są to zawsze wartościowe oferty pracy z widełkami wynagrodzeń, więc warto tam szukać rozwoju swojej kariery. Jeśli natomiast potrzebujecie nowe osoby do Waszych organizacji, no to również wiecie gdzie uderzyć, bo na Solid Jobs w kilku prostych krokach możecie wystawić ogłoszenie o pracę. Dzięki Krzysztof, do zobaczenia.