Porozmawiajmy o IT

Koszt błędu w IT. Gość: Łukasz Drynkowski - POIT 293

• Krzysztof Kempiński • Season 1 • Episode 293

Share episode

Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.

0:00 | 32:39

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:


Linki:


Wsparcie:


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

https://porozmawiajmyoit.pl/293

Speaker 1

To jest 293 . Odcinek

Wpadki w IT

Speaker 1

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

Rodzaje błędów

Speaker 2

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

Konsekwencje błędów

Speaker 1

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

Zarządzanie błędami

Speaker 1

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

Błędy menedżerskie

Speaker 2

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

Uczenie się na błędach

Speaker 1

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 ,

Podsumowanie odcinka

Speaker 1

ż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 .

Head Shot

Krzysztof Kempiński

Host