Znasz to uczucie, gdy ka\u017cdego ranka otwierasz Slacka i widzisz 10 wiadomo\u015bci o awariach, hotfixach i \u201etymczasowych rozwi\u0105zaniach\u201d? Zesp\u00f3\u0142 IT pracuje po godzinach, a lista zada\u0144 backlogu tylko ro\u015bnie. Brzmi znajomo? Witaj w trybie gaszenia po\u017car\u00f3w \u2013 najbardziej wyniszczaj\u0105cym stanie, w jaki mo\u017ce popa\u015b\u0107 ka\u017cda firma technologiczna.<\/p>\n
Gaszenie po\u017car\u00f3w to sytuacja, w kt\u00f3rej zesp\u00f3\u0142 IT sp\u0119dza wi\u0119kszo\u015b\u0107 czasu na reagowaniu na kryzysy, zamiast pracowa\u0107 nad rozwojem produktu, optymalizacj\u0105 czy innowacjami. To pu\u0142apka, z kt\u00f3rej trudno si\u0119 wydosta\u0107, zw\u0142aszcza gdy firma ro\u015bnie. Ale zanim rzucisz has\u0142o \u201emusimy przepisa\u0107 wszystko od nowa\u201d, sp\u00f3jrzmy na pi\u0119\u0107 konkretnych objaw\u00f3w tego stanu. Poznasz je po tym, jak Twoi programi\u015bci reaguj\u0105 na zwyk\u0142e pytanie: \u201eCzy mo\u017cemy zrobi\u0107 now\u0105 funkcj\u0119?\u201d.<\/p>\n
Je\u015bli co\u015b tak prostego jak dodanie nowego pola w formularzu rejestracji zajmuje dwa tygodnie, to nie jest kwestia \u201eskomplikowanego systemu\u201d \u2013 to objaw d\u0142ugu technicznego. D\u0142ug techniczny narasta, gdy zesp\u00f3\u0142 ci\u0105gle wybiera szybkie rozwi\u0105zania zamiast solidnych architektur. Z czasem kod staje si\u0119 pl\u0105tanin\u0105 zale\u017cno\u015bci, gdzie ka\u017cda zmiana poci\u0105ga za sob\u0105 pi\u0119\u0107 innych, a ka\u017cda poprawka generuje dwa nowe bugi.<\/p>\n
Pami\u0119tam klienta z bran\u017cy fintech, kt\u00f3ry mia\u0142 aplikacj\u0119 do zarz\u0105dzania bud\u017cetem domowym. Ich developerzy sp\u0119dzali 80% czasu na naprawianiu starych b\u0142\u0119d\u00f3w, a tylko 20% na nowych funkcjach. Gdy zapyta\u0142em, dlaczego nie refaktoruj\u0105, odpowiedzieli: \u201eNie mamy czasu, bo ci\u0105gle co\u015b si\u0119 psuje\u201d. To b\u0142\u0119dne ko\u0142o \u2013 im wi\u0119cej gasisz, tym wi\u0119cej po\u017car\u00f3w wybucha.<\/p>\n
Zajrzyj do swojego trackera zada\u0144. Ile z nich ma etykiet\u0119 \u201erefaktoring\u201d, \u201etechniczne\u201d, \u201esp\u0142ata d\u0142ugu\u201d? Je\u015bli stanowi\u0105 one ponad 30% backlogu, masz problem. To nie oznacza, \u017ce s\u0105 niepotrzebne \u2013 wr\u0119cz przeciwnie. Jednak w trybie gaszenia po\u017car\u00f3w s\u0105 one odk\u0142adane na p\u00f3\u017aniej, bo \u201ebiznes wymaga nowych funkcji\u201d. Tymczasem im d\u0142u\u017cej odk\u0142adasz refaktoring, tym wi\u0119ksze ryzyko, \u017ce w ko\u0144cu system padnie.<\/p>\n
Przyk\u0142ad z \u017cycia: sklep e-commerce, kt\u00f3ry dzia\u0142a\u0142 na zmodyfikowanej wersji WooCommerce. Zesp\u00f3\u0142 przez dwa lata dorzuca\u0142 wtyczki i \u0142atki, zamiast zrobi\u0107 porz\u0105dn\u0105 architektur\u0119. W ko\u0144cu nowa funkcja \u2013 dynamiczne ceny \u2013 wymaga\u0142a przepisania po\u0142owy systemu. Koszt: 3 miesi\u0105ce pracy i utrata kilku kluczowych klient\u00f3w, kt\u00f3rzy nie mogli czeka\u0107.<\/p>\n
Je\u015bli monitorowanie alert\u00f3w to codzienno\u015b\u0107, a tw\u00f3j zesp\u00f3\u0142 przywyk\u0142 do pracy w weekendy, to alarm \u2013 dos\u0142ownie i w przeno\u015bni. Statystyki m\u00f3wi\u0105, \u017ce \u015bredni czas naprawy (MTTR) w firmach z chronicznym d\u0142ugiem technicznym jest 2-3 razy d\u0142u\u017cszy ni\u017c w dobrze zarz\u0105dzanych zespo\u0142ach.<\/p>\n
Cz\u0119ste awarie obni\u017caj\u0105 zaufanie klient\u00f3w. W przypadku SaaS, ka\u017cda minuta przestoju to utrata pieni\u0119dzy i reputacji. A gdy zesp\u00f3\u0142 przyzwyczaja si\u0119 do awarii, przestaje traktowa\u0107 je powa\u017cnie \u2013 powstaje kultura akceptacji b\u0142\u0119d\u00f3w, kt\u00f3ra jest zab\u00f3jcza dla jako\u015bci.<\/p>\n
Wypalenie w IT to plaga. Wed\u0142ug bada\u0144 Stack Overflow, a\u017c 30% developer\u00f3w czuje si\u0119 wypalonych, a g\u0142\u00f3wnym powodem jest z\u0142a jako\u015b\u0107 kodu i ci\u0105g\u0142e naciski na szybkie dostarczanie. Gdy Tw\u00f3j zesp\u00f3\u0142 narzeka, \u017ce \u201ekod jest do bani\u201d, ale nie ma czasu go poprawi\u0107, to znak, \u017ce potrzebuje zmiany priorytet\u00f3w.<\/p>\n
W jednej z firm, w kt\u00f3rej doradza\u0142em, zesp\u00f3\u0142 mia\u0142 cotygodniowe spotkania, ale nie rozmawiali o nowych funkcjach, tylko o tym, kt\u00f3ry fragment kodu zn\u00f3w si\u0119 rozsypa\u0142. Atmosfera by\u0142a fatalna, rotacja personelu wysoka. Firma straci\u0142a dw\u00f3ch kluczowych developers\u00f3w w ci\u0105gu roku. Koszt rekrutacji i onboardingu nowych os\u00f3b przewy\u017cszy\u0142 koszt refaktoringu, kt\u00f3ry zalecali.<\/p>\n
Onboarding w trybie gaszenia po\u017car\u00f3w to koszmar. Nowa osoba dostaje dost\u0119p do repozytorium, patrzy na kod i nie wie, od czego zacz\u0105\u0107. Brak dokumentacji, skomplikowane zale\u017cno\u015bci, brak test\u00f3w \u2013 ka\u017cda pr\u00f3ba zmiany ko\u0144czy si\u0119 b\u0142\u0119dem. \u015aredni czas do pierwszej produktywnej zmiany to w takich zespo\u0142ach 3-6 miesi\u0119cy.<\/p>\n
Tymczasem w dobrze zarz\u0105dzanym projekcie nowy developer mo\u017ce wdro\u017cy\u0107 pierwsz\u0105 poprawk\u0119 w ci\u0105gu pierwszego tygodnia. Bo kod jest czytelny, s\u0105 testy, a architektura jest logiczna. To nie kwestia geniuszu \u2013 to kwestia kultury technicznej.<\/p>\n
Po pierwsze: przesta\u0144 udawa\u0107, \u017ce to normalne. Przyznanie si\u0119 do problemu to pierwszy krok. Po drugie: wygospodaruj czas na refaktoring \u2013 nawet 20% czasu sprintu na sp\u0142at\u0119 d\u0142ugu technicznego. Po trzecie: wprowad\u017a monitoring i automatyczne testy, kt\u00f3re z\u0142api\u0105 b\u0142\u0119dy, zanim trafi\u0105 na produkcj\u0119.<\/p>\n
W JurskiTech.pl cz\u0119sto spotykamy si\u0119 z firmami, kt\u00f3re s\u0105 w takiej pu\u0142apce. Nasze podej\u015bcie polega na stopniowym zmniejszaniu d\u0142ugu technicznego bez zatrzymywania rozwoju. Cz\u0119sto wystarczy kilka tygodni pracy nad kluczowymi fragmentami systemu, by odetchn\u0105\u0107. Potem mo\u017cna my\u015ble\u0107 o nowych funkcjach i innowacjach.<\/p>\n
Pami\u0119taj: gaszenie po\u017car\u00f3w nie jest oznak\u0105 zaanga\u017cowania \u2013 to oznaka z\u0142ego zarz\u0105dzania. Tw\u00f3j zesp\u00f3\u0142 zas\u0142uguje na to, by pracowa\u0107 nad czym\u015b, co buduje warto\u015b\u0107, a nie tylko \u0142ata dziury. A Tw\u00f3j biznes zas\u0142uguje na stabilno\u015b\u0107 i przewidywalno\u015b\u0107.<\/p>\n
Je\u015bli rozpoznajesz kt\u00f3ry\u015b z tych objaw\u00f3w u siebie, nie czekaj, a\u017c wybuchnie kolejny po\u017car. Czas na audyt techniczny i zmian\u0119 priorytet\u00f3w. Bo najdro\u017csze rozwi\u0105zanie to to, kt\u00f3re odk\u0142adasz na p\u00f3\u017aniej.<\/p>\n","protected":false},"excerpt":{"rendered":"
Wprowadzenie Znasz to uczucie, gdy ka\u017cdego ranka otwierasz Slacka i widzisz 10 wiadomo\u015bci o awariach, hotfixach i \u201etymczasowych rozwi\u0105zaniach\u201d? Zesp\u00f3\u0142 IT pracuje po godzinach, a lista zada\u0144 backlogu tylko ro\u015bnie. Brzmi znajomo? Witaj w trybie gaszenia po\u017car\u00f3w \u2013 najbardziej wyniszczaj\u0105cym stanie, w jaki mo\u017ce popa\u015b\u0107 ka\u017cda firma technologiczna. Gaszenie po\u017car\u00f3w to sytuacja, w kt\u00f3rej zesp\u00f3\u0142<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[7],"tags":[795,431,63,396],"class_list":["post-2140","post","type-post","status-publish","format-standard","hentry","category-warto-wiedziec","tag-gaszenie-pozarow","tag-optymalizacja-wydajnosci","tag-zarzadzanie-it","tag-zespol-it"],"_links":{"self":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/2140","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/comments?post=2140"}],"version-history":[{"count":0,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/2140\/revisions"}],"wp:attachment":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/media?parent=2140"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/categories?post=2140"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/tags?post=2140"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}