Porozmawiajmy o IT
Porozmawiajmy o IT
Koszt błędu w IT. Gość: Łukasz Drynkowski - POIT 293
Witam w dwieście dziewięćdziesiątym trzecim odcinku podcastu „Porozmawiajmy o IT”. Tematem dzisiejszej rozmowy w serii podcastów o wpadkach IT jest koszt błędu w IT.
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 koszcie błędu w IT z tego odcinka to:
- rodzaje błędów w IT: techniczne, organizacyjne (brak komunikacji), ludzkie (zmęczenie, rutyna)
- skąd się biorą: brak procedur, złe wymagania, pośpiech, złe szacowanie, niewłaściwy dobór technologii, błędne założenia biznesowe
- konsekwencje błędów: finansowe, czasowe, wizerunkowe, utrata klienta
- wpływ kultury organizacyjnej
- jak reagować na pojawiające się błędy
- jak minimalizować ryzyko błędów
- jak uczyć się na cudzych błędach
Subskrypcja podcastu:
- zasubskrybuj w Apple Podcasts, Google 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/
- Failory - https://failory.com
Wsparcie:
- Wesprzyj podcast na platformie Patronite - https://patronite.pl/porozmawiajmyoit/
Jeśli masz jakieś pytania lub komentarze, pisz do mnie śmiało na krzysztof@porozmawiajmyoit.pl
https://porozmawiajmyoit.pl/293
To jest 293. Odcinek podcastu Polosmawiajmy IT. W duecie z Łukaszem Drynkowskim z portalu pracy IT Solid Jobs, który współtworzem, 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. Rozpoczynam, cześć Kuszczu 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łędów IT w ogóle możemy mówić.
Speaker 2: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, na przykład błędy komunikacji, oraz także o błędach które wynikają z błędów takich 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ę.
Speaker 1: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. No, po prostu w IT musimy się pogodzić z tym, że te błędy będą. I to, co jeszcze pewnie poruszymy dzisiaj w rozmowie, to to, że jesteśmy sobie. 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.
Speaker 2:Tak, ja jeszcze dodam tutaj, że testerzy zapewne rozróżniają błędy, defekty, usterki mają na to osobne słowa, tak jak Eskimosi na śmiech. Natomiast my tutaj dla jasności jesteśmy tylko szerymi programistami. Także będziemy tutaj naszą ignorancją nazywać błędem. To wszystko jakby w jednym worku.
Speaker 1:Dokładnie. No, to może rozpocznijmy i powiedzmy, skąd się te błędy w ogóle biorą. Tak 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ć.
Speaker 2: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 też tych konsekwencjach, błędów, no, to musimy jakby 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, albo nawet ktoś przestrzega, ale tutaj jestem 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. No, ale tutaj kliknę, zaznaczę jakiegoś checkboxa override i idzie merge prosto na mastera. No, i z tego powodu myślę powstaje wiele błędów, że po prostu ignorujemy te istniejące procedury, istniejące dobre praktyki.
Speaker 2:Też może to być tak, że to jest jakiś pośpiech, jakieś 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ść, tak to może z tego wynikać problem, że w jednym miejscu coś zmieniliśmy a psujemy coś innego. Czyli tak pośpiech złe, jakieś założenia, wręcz wymagania były błędne. To się często zdarza, ż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.
Speaker 1:Tak rozjeżdżamy się z tą realizacją.
Speaker 2:Tak rozjeżdżamy się zupełnie z realizacją. Przyszły jakieś pieniądze z KPO do nas i robimy po prostu sztukę, a nie zastanawiamy się, czy to rzeczywiście pomaga tym użytkownikom w rozwiązaniu rzeczywistych, rzeczywistych ludzkich problemów czy też codziennych problemów. Tylko po prostu robimy system problemów. Tylko po prostu robimy system który jest niewygodny w użyciu, który jest, który wprowadza więcej problemów. Też pamiętam z moich doświadczeń z pracy z użytkownikami systemu, kiedy informatyzowaliśmy tak 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 klikać tak.
Speaker 1:Tak 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, czy z tego co powiedziałeś, jeśli chodzi o to, skąd się te błędy biorą, no, 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.
Speaker 2:czyli to wejście jeśli jest złe, czyli wymagania albo też presja czasu jest zbyt duża, to to nam może generować błędy, niewłaściwy dobór technologii, również 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, kropki, kolejne, od hacza, 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ęść 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.
Speaker 1: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.
Speaker 2:Tak najlepsze dni wiadomo. To są takie kiedy bilans napisanego kodu jest ujęty. Wyrzuciliśmy kilka kilkaset tysięcy linii kodu i zastąpiliśmy kilkoma To, to, to się powinien należeć, programie, programie.
Speaker 1:Zgadza się, to jest sukces. Dobrze, czyli wiemy, skąd te błędy się biorą. Okazuje się że z różnych rzeczy, 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.
Speaker 2:Czy też konsekwencje finansowe. To jest to, co tutaj najbardziej boli dysydentów, czyli to, jeśli taka wpadka ma konsekwencje związane z tym, że musimy pokryć rzeczywiście te koszty naprawy ale możliwe że też jakieś umowy SLA zostały niedopełnioneDO 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, ż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 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.
Speaker 1: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. Jeśli coś nie działa, albo coś się źle nalicza, to wtedy potencjalnie tr działa, albo coś się źle nalicza, no, to wtedy potencjalnie tracimy. A sama obsługa błędu w postaci, no nie wiem, chociażby załatania tego w kodzie, ale też przetestowania, czy też jakiegoś kosztu ze strony supportu i tak dalej też na to wszystko się składa. Więc samo naprawienie błędów też kosztuje. No, to wszystko się dokłada gdzieś do tej kubki właśnie finansowych konsekwencji.
Speaker 2: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 otwiera cały wszechświat problemów i konsekwencji, o których myślę że opowiemy w jakimś kolejnym odcinku. Żebyśmy tutaj byli bardziej sfokusowani na przedstawienie tych efektów i przyczyn, a nie wchodzili w takie szczegóły.
Speaker 1:Tak jest. Zazwyczaj jest tak, że im dłuż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 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, usunięta prawda. Jeśli powstaje tylko na chwilę pod jakąś na przykład akcją marketingową, też nie ma wów. Więc myślę, że, tak jak tutaj zasugerowałeś, pewnie poruszymy ten temat w którymś z kolejnych odcinków.
Speaker 2: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.
Speaker 1:Idealnie by było gdybyśmy zawsze mieli nie tylko świadomość, ale też możliwość naprawy tych błędów które są związane z naszym kodem, z naszym systemem. 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 tutaj zewnętrznych prowajderów, musi nastąpić.
Speaker 2: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 opisać.
Speaker 1:Tak jest, to jest idealne rozwiązanie. Wtedy na pewno poradzimy sobie ze wszystkim i będziemy w stanie to.
Speaker 2:Oczywiście mam nadzieję, że wszyscy słuchacze tutaj wyczuli ironię i nie wyłączyli odbiorników. Tutaj też ciekawy właśnie wątek. Jeśli już mówimy o bo mówisz o poleganiu na zewnętrznym API. No, ale też może być tak że ktoś polega na naszym API i też ile razy się spotkałem z tym że na przykład ktoś, korzystając z jakiejś, z jakiejś biblioteki czy z jakiegoś API, polegał na jakimś błędzie, który przez lata tam był i teraz, przez to, że my naprawimy ten błąd, to możemy komuś zepsuć funkcjonowanie jakiejś klocka, który polegał na nas.
Speaker 2:Taki efekt domina tutaj. Możemy też osiągnąć Na przykład 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.
Speaker 1:Tak usuwamy kamienia tam pod nim gdzie my stworowali. 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ść.
Speaker 2:Tak to do niczego nie prowadzi.
Speaker 1: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ć, 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, niech będą chcieli tego ujawnić, żeby właśnie nie wystawić się na tego typu gdzieś tam szykanowanie. Więc trzeba być też tego świadomym. Najlepiej, jeśli mamy do tego takie zdrowe podejście, czyli okej, 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 piersi i naprawy Tego typu właśnie kultura organizacyjna, gdzie szukamy winnych a nie szukamy rozwiązań.
Speaker 2:No, to prowadzi do tego że te koszty rosną, po prostu.
Speaker 1:Tak, no, i też takie szukanie winnych skutecznie nam hamuje wszelkiego typu innowacje czy też inwencje. Tak, no, bo jeśli robimy coś niestandardowo, korzystamy z jakichś jeszcze wcześniej nie używanych rozwiązań, to mamy sporą szansę na popełnienie błędów. Jeśli ten błąd będzie gdzieś tam wytykany jako taki, 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.
Speaker 2:I tutaj myślę, że też ciekawy jest wątek, bo wydaje mi się, że kolejnym typem błędu to jest taki, który wynika z jakichś właśnie 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. To też jest jakby taki rodzaj błędu, czyli to, że działam w ten sposób, że po prostu działam wolno.
Speaker 1: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źć.
Speaker 2:To jest właśnie sponsorowany fragment.
Speaker 1: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ć.
Speaker 2: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.
Speaker 1:Właśnie, bo to się wszystko chyba zaczyna od tego ogłoszenia o pracy, 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ń, no to wiesz zajmował. Jeśli tam nie ma widełek wynagrodzeń, no to wiesz. Ciężko tutaj oczekiwać, że dostaniesz z takiego procesu kogoś wartościowego, kogoś sensownego, skoro właściwie nie wiesz kogo szukasz.
Speaker 2:Tak, albo uwielbiam rozmowę rekrutacyjna, pytania o najnowsze feature'y w NET 9, a potem przychodzisz i projekt w NET 4.5, tak.
Speaker 1:No, tak, tak, no, właśnie właśnie. Więc taki rozstrzał, takie przestrzelenie się teorii z rzeczywistością też może mieć miejsce. Warto 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. No, potrafi być naprawdę doskwierający.
Speaker 2: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.
Speaker 1:Tak jest, tam odsyłamy.
Speaker 2:Odsyłamy do internetów.
Speaker 1: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 postępowanie, Ale znacznie lepsze, tak jak tutaj wcześniej powiedziałeś, jest minimalizowanie ryzyka błędu, czyli niedopuszczenie do tego, żeby ten b Przede wszystkim to uczmy się na swoich błędach, albo najlepiej na cudzych błędach.
Speaker 2:Miejmy wujmy też to, żeby wykrywać tego typu błędy. Ja z doświadczenia powiem, że błędy lubią wracać. Lubią wracać. Często jest tak, że coś naprawimy i czy to przez jakiś potem błędny mercz czy też po prostu ktoś popełni ten sam błąd za jakiś czas nie będą świadomi 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ś.
Speaker 1:I ignorujemy.
Speaker 2:I ignorujemy, 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 kod review jakąś automatyzację, która też wstępnie pewne rzeczy nam jakiś linter podpowie, Standardyzujmy, wprowadzajmy Ja jestem fanem różnego rodzaju też checklist także polecam.
Speaker 1:Tak obecnie my 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 linterów po jakieś potencjalne security issues, po analizę statyczną i 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 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.
Speaker 2:Tak, i pamiętajmy, że na bank nie jesteśmy pierwszymi, którzy z danym problemem się spotkali. Także warto sprawdzić, jak inni sobie z tym poradzili. Że warto 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 rozwojem oprogramowania. Przejdźmy może do błędów takich zarządczych, czyli co menadżerzy robią źle.
Speaker 1: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 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. 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.
Speaker 2:Tak, ja tu jeszcze chciałbym tylko dorzucić brak albo błędne zarządzanie. Problemami i błędami. To też jest coś, co często gdzieś tam widzę.
Speaker 1:Wspominaliśmy tutaj o rekrutacji, 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 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ą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.
Speaker 2:No i fajnie, ale wydaje mi się, że jednak najlepiej to się uczyć na cudzych błędach. Łatwo powiedzieć ale pewnie trudniej zrobić. Jak myślisz, jak można się uczyć na cudzych błędach? Gdzie jakby tą wiedzę zdobywać?
Speaker 1:Tak. No, 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ł dłuższy czas o czymś piszą. To tam możemy znaleźć pewnie właśnie informacje. 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 gdzieś tam tematem, można się powymieniać właśnie tego typu informacjami, co nie działa i jak sobie z danym tematem poradzić. I oczywiście tutaj jeszcze może podsunę 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 failorycom.
Speaker 1:Oczywiście to tam w notatkach do odcinka zawrzemy, 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żą bibliotekę historii, które mówią nam o tym, że coś tam poszło nie tak, i 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 właśnie jakie są rodzaje błędów 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.
Speaker 2: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ę zrekrutować osobę do zespołu.
Speaker 2: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. Przede wszystkim 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. Że ten błąd nie powróci albo się nie powtórzy, 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.
Speaker 1: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 pracy.
Speaker 2:Dzięki Krzysztof, dzięki Łukasz Cześć, i do zobaczenia.
