Wielu founder\u00f3w i CTO z kt\u00f3rymi rozmawiam, twierdzi, \u017ce ich zesp\u00f3\u0142 IT jest \u201ew porz\u0105dku\u201d. Projekty si\u0119 realizuj\u0105, b\u0142\u0119dy s\u0105 \u0142atane, a klienci nie narzekaj\u0105. Dopiero gdy przyjrzymy si\u0119 bli\u017cej, wychodz\u0105 na jaw problemy, kt\u00f3re kosztuj\u0105 firm\u0119 du\u017co wi\u0119cej ni\u017c tylko op\u00f3\u017anienia. Kryzys kompetencji nie objawia si\u0119 spektakularnymi awariami \u2013 raczej cichym marnowaniem czasu, pieni\u0119dzy i potencja\u0142u.<\/p>\n
Oto pi\u0119\u0107 sygna\u0142\u00f3w, kt\u00f3re powinny zapali\u0107 czerwon\u0105 lampk\u0119. Ka\u017cdy z nich widzia\u0142em na w\u0142asne oczy w firmach r\u00f3\u017cnej wielko\u015bci.<\/p>\n
Zesp\u00f3\u0142 pracuje w trybie awaryjnym: \u0142atki, hotfixy, nadgodziny. Poprawki bezpiecze\u0144stwa wdra\u017cane s\u0105 po fakcie, a nowe funkcjonalno\u015bci wdra\u017ca si\u0119 \u201ebyle dzia\u0142a\u0142o\u201d. To klasyczny objaw braku g\u0142\u0119bokiego zrozumienia architektury i technologii.<\/p>\n
Przyk\u0142ad z \u017cycia: Firma e-commerce z 50-osobowym dzia\u0142em IT przez dwa lata walczy\u0142a z b\u0142\u0119dem w systemie zam\u00f3wie\u0144. Zamiast przepisa\u0107 krytyczn\u0105 cz\u0119\u015b\u0107 kodu, doklejano kolejne warstwy zabezpiecze\u0144 i komentarzy. W efekcie system sta\u0142 si\u0119 monolitem, w kt\u00f3rym ka\u017cda zmiana grozi\u0142a wybuchem. Dopiero audyt zewn\u0119trzny ujawni\u0142, \u017ce problem le\u017ca\u0142 w nieoptymalnym algorytmie walidacji \u2013 do naprawy wystarczy\u0142 jeden dzie\u0144 pracy senior developera.<\/p>\n
Rozwi\u0105zanie: Regularnie organizuj tzw. \u201esprinty techniczne\u201d \u2013 czas przeznaczony wy\u0142\u0105cznie na refaktoryzacj\u0119 i sp\u0142at\u0119 d\u0142ugu technicznego. Bez tego zesp\u00f3\u0142 nigdy nie wyjdzie z trybu gaszenia po\u017car\u00f3w.<\/p>\n
Ka\u017cda propozycja zmiany stacku, frameworka czy narz\u0119dzia spotyka si\u0119 z oporem: \u201ePo co zmienia\u0107, skoro dzia\u0142a?\u201d, \u201eTo zbyt ryzykowne\u201d, \u201eNie mamy czasu na nauk\u0119\u201d. To cz\u0119sto maskuje brak kompetencji \u2013 zesp\u00f3\u0142 boi si\u0119, \u017ce nie poradzi sobie z nowym rozwi\u0105zaniem.<\/p>\n
Widzia\u0142em to w firmie, kt\u00f3ra przez 5 lat u\u017cywa\u0142a przestarza\u0142ej wersji Reacta, bo \u201enikt nie chcia\u0142 si\u0119 uczy\u0107 nowego API\u201d. Gdy w ko\u0144cu zdecydowano si\u0119 na aktualizacj\u0119, okaza\u0142o si\u0119, \u017ce po\u0142owa kodu by\u0142a napisana w spos\u00f3b, kt\u00f3ry uniemo\u017cliwia\u0142 p\u0142ynne przej\u015bcie. Koszt modernizacji by\u0142 trzykrotnie wy\u017cszy ni\u017c gdyby robiono to stopniowo.<\/p>\n
Rozwi\u0105zanie: Wprowad\u017a polityk\u0119 \u201e20% czasu na eksperymenty\u201d \u2013 jeden dzie\u0144 w tygodniu, kiedy zesp\u00f3\u0142 mo\u017ce uczy\u0107 si\u0119 nowych technologii, prototypowa\u0107 i dzieli\u0107 si\u0119 wiedz\u0105. Op\u00f3r maleje, gdy nowe narz\u0119dzia nie s\u0105 narzucane odg\u00f3rnie, ale wychodz\u0105 od zespo\u0142u.<\/p>\n
Code review trwa tygodniami, a po wdro\u017ceniu cz\u0119sto trzeba cofa\u0107 zmiany z powodu b\u0142\u0119d\u00f3w. To znak, \u017ce programi\u015bci nie rozumiej\u0105 architektury ani standard\u00f3w kodu. Zamiast recenzji merytorycznej mamy wymian\u0119 \u201edzia\u0142a u mnie\u201d \u2013 \u201eale u mnie nie\u201d.<\/p>\n
Zdarzy\u0142a mi si\u0119 sytuacja, w kt\u00f3rej developer z 3-letnim sta\u017cem doda\u0142 funkcj\u0119, kt\u00f3ra powodowa\u0142a wyciek pami\u0119ci w ca\u0142ej aplikacji. Code review przeoczy\u0142o to, bo nikt nie mia\u0142 pe\u0142nego obrazu systemu. Revert zaj\u0105\u0142 dwa dni, a przywr\u00f3cenie sp\u00f3jno\u015bci danych \u2013 kolejne trzy.<\/p>\n
Rozwi\u0105zanie: Wprowad\u017a obowi\u0105zkowe testy jednostkowe i integracyjne przed ka\u017cdym merge\u2019em. Automatyzacja przechwytuje b\u0142\u0119dy, kt\u00f3rych ludzie nie s\u0105 w stanie wy\u0142apa\u0107. Dodatkowo rotuj recenzent\u00f3w, aby nikt nie monopolizowa\u0142 wiedzy.<\/p>\n
Zesp\u00f3\u0142 nie dokumentuje architektury, decyzji technicznych ani proces\u00f3w. Nowi pracownicy musz\u0105 uczy\u0107 si\u0119 na zasadzie \u201epytaj Krzysia, on wie najwi\u0119cej\u201d. Problem narasta, gdy Krzy\u015b odchodzi \u2013 firma traci ca\u0142\u0105 wiedz\u0119.<\/p>\n
W jednej z firm, w kt\u00f3rej pracowa\u0142em, kluczowy backend zosta\u0142 napisany przez sta\u017cyst\u0119, kt\u00f3ry po roku wyjecha\u0142 za granic\u0119. Nikt nie wiedzia\u0142, jak dzia\u0142aj\u0105 niekt\u00f3re endpointy. Dokumentacja ogranicza\u0142a si\u0119 do komentarza \u201eto dzia\u0142a, nie ruszaj\u201d. Gdy pojawi\u0142 si\u0119 b\u0142\u0105d krytyczny, trzeba by\u0142o zatrudni\u0107 konsultanta z zewn\u0105trz, kt\u00f3ry odtworzy\u0142 logik\u0119 \u2013 koszt 30 000 z\u0142.<\/p>\n
Rozwi\u0105zanie: Wdr\u00f3\u017c zasad\u0119 \u201edokumentacja jest cz\u0119\u015bci\u0105 definicji uko\u0144czenia zadania\u201d. Ka\u017cda funkcjonalno\u015b\u0107 musi mie\u0107 minimum: opis celu, diagram sekwencji, list\u0119 zale\u017cno\u015bci i instrukcj\u0119 uruchomienia. U\u017cywaj narz\u0119dzi jak ADR (Architecture Decision Records) \u2013 kr\u00f3tkie notatki z ka\u017cdej wa\u017cnej decyzji.<\/p>\n
Zesp\u00f3\u0142 cz\u0119sto si\u0119 zmienia, a rekrutacje trwaj\u0105 miesi\u0105cami. Kandydaci odpadaj\u0105 na testach lub po kilku miesi\u0105cach odchodz\u0105, bo \u201enie ma si\u0119 od kogo uczy\u0107\u201d. To objaw toksycznej kultury lub stagnacji technologicznej.<\/p>\n
Przyk\u0142ad z ostatniego roku: Firma SaaS z 30-osobowym dzia\u0142em IT przez p\u00f3\u0142 roku nie mog\u0142a znale\u017a\u0107 senior developera. Rekruterzy dostawali CV, ale kandydaci rezygnowali po rozmowie technicznej, bo pytania dotyczy\u0142y framework\u00f3w z 2010 roku. Ci, kt\u00f3rzy zostali, odchodzili w ci\u0105gu roku, bo nie by\u0142o przestrzeni na rozw\u00f3j.<\/p>\n
Rozwi\u0105zanie: Stw\u00f3rz \u015bcie\u017ck\u0119 rozwoju technicznego \u2013 nie tylko awans na managera. Seniorzy powinni mie\u0107 czas na prowadzenie warsztat\u00f3w, pisanie bibliotek wewn\u0119trznych i udzia\u0142 w konferencjach. Poka\u017c, \u017ce firma inwestuje w kompetencje, a nie tylko w realizacj\u0119 zada\u0144.<\/p>\n
Kryzys kompetencji nie musi by\u0107 wyrokiem. Wi\u0119kszo\u015b\u0107 problem\u00f3w wynika z braku systematyczno\u015bci i narz\u0119dzi, a nie z\u0142o\u015bliwo\u015bci zespo\u0142u. Wprowadzenie prostych proces\u00f3w \u2013 jak czas na refaktoryzacj\u0119, dokumentacja, automatyzacja test\u00f3w \u2013 mo\u017ce diametralnie zmieni\u0107 efektywno\u015b\u0107.<\/p>\n
Je\u015bli widzisz u siebie kt\u00f3ry\u015b z tych sygna\u0142\u00f3w, nie czekaj, a\u017c stanie si\u0119 krytyczny. Cz\u0119sto wystarczy audyt zewn\u0119trzny, aby zidentyfikowa\u0107 najwi\u0119ksze w\u0105skie gard\u0142a i zaproponowa\u0107 konkretne rozwi\u0105zania. JurskiTech od lat pomaga firmom w takich transformacjach \u2013 od optymalizacji kodu po zmian\u0119 kultury pracy.<\/p>\n
Pami\u0119taj: kompetentny zesp\u00f3\u0142 to nie tylko ni\u017csze koszty, ale te\u017c szybsze wdro\u017cenia i wy\u017csza jako\u015b\u0107. A w dzisiejszych czasach to mo\u017ce by\u0107 Twoja najwi\u0119ksza przewaga konkurencyjna.<\/p>\n","protected":false},"excerpt":{"rendered":"
5 sygna\u0142\u00f3w, \u017ce Tw\u00f3j zesp\u00f3\u0142 IT ma kryzys kompetencji (i jak go rozwi\u0105za\u0107) Wielu founder\u00f3w i CTO z kt\u00f3rymi rozmawiam, twierdzi, \u017ce ich zesp\u00f3\u0142 IT jest \u201ew porz\u0105dku\u201d. Projekty si\u0119 realizuj\u0105, b\u0142\u0119dy s\u0105 \u0142atane, a klienci nie narzekaj\u0105. Dopiero gdy przyjrzymy si\u0119 bli\u017cej, wychodz\u0105 na jaw problemy, kt\u00f3re kosztuj\u0105 firm\u0119 du\u017co wi\u0119cej ni\u017c tylko op\u00f3\u017anienia.<\/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":[140,297,405,65,658],"class_list":["post-1918","post","type-post","status-publish","format-standard","hentry","category-warto-wiedziec","tag-analityka","tag-automatyzacja-rozwoju-oprogramowania","tag-efektywnosc-zespolow","tag-kompetencje","tag-kryzys"],"_links":{"self":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/1918","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=1918"}],"version-history":[{"count":0,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/1918\/revisions"}],"wp:attachment":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/media?parent=1918"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/categories?post=1918"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/tags?post=1918"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}