Do niedawna nikt nie mówił tego na głos, ale teraz stało się to już trudno podważalnym faktem:
Polscy eksperci techniczni przestali być rynkowo atrakcyjni, a stali się drodzy.
Czemu tak się dzieje?
Po pierwsze – gospodarka. Wysokie koszty życia i kredyty hipoteczne (które w przypadku innych krajów nie są tak powszechne, bo wynajem jest bardziej korzystny i popularny, nie ma też tak dużej potrzeby posiadania, jaką mamy my, Polacy). To sprawia, że polscy specjaliści chcą zarabiać więcej i więcej, ale niekoniecznie idzie za tym ciągły przyrost kompetencji.
Ponadto, życiowe priorytety są mocno ulokowane w budowie domu czy rodzinie. Jeszcze kilka lat temu nieustannie słyszałam, że każdy marzy o rozwijającym, interesującym i najlepiej zmieniającym świat projekcie, a dziś najczęściej słyszę: szukam takiej roboty, żeby nie trzeba było tam wiele robić. No i wybaczcie, ale nie ma możliwości, żeby takie osoby ”kompleksowo zadbały o biznes klienta”.
Na początku tego roku firma Remitly udostępniła dane ilustrujące to, jaki zawód cieszy się największą popularnością w danym kraju. W Polsce – jak nie trudno zgadnąć – wymarzonym okazał się być zawód programisty. Tak, na naszym rodzimym rynku to olbrzymi prestiż, który prowadzi niekiedy do rozwojowego zastoju, bo skoro wykonuję najbardziej ceniony zawód w mojej szerokości geograficznej, to dlaczego jeszcze miałbym coś zmieniać, rozwijać się, sięgać po więcej?
Poza uznaniem społecznym wiąże się to też oczywiście z czymś bardziej namacalnym – wysokimi zarobkami. Jeśli osiągnęliśmy już jakiś wysoki poziom wynagrodzenia i prowadzimy życie na zadowalającym poziomie, to rzadko idzie to w parze z dalszym rozwojem, bo wiemy doskonale, że kiedy jest dobrze i cieplutko, to brakuje nam determinacji by coś zmieniać.
I na tym etapie, gdy nie potrzebujemy już zbyt wiele – ani benefitów, ani integracji, ani fajnych ludzi w teamie, ale nie możemy przecież zarabiać mniej, więc szukamy kolejnej pracy, kładąc nacisk tylko na pieniądze, co z kolei nie ukazuje nas jako godnych partnerów do rozmowy w potencjalnym miejscu pracy. Klient doskonale wie, że ktoś, kogo interesuje tylko ile, ale niekoniecznie z kim i jak, nie będzie holistycznie i proaktywnie dbał o jego biznes.
Efekt krótkowzrocznej strategii
To też nasza wina. Kiedy przez ostatnie lata popyt na specjalistów technicznych znacząco przewyższał podaż, zatrudnialiśmy ludzi, którzy pokrywali 1/3 wymagań technicznych, a weryfikacja kompetencji miękkich ograniczała się tylko do sprawdzenia czy ktoś nie przejawia poważnych odchyleń 😉 Liczyło się tylko tu i teraz. Klient potrzebuje pięciu devów Reacta na już, klient jutro ich dostanie. To długotrwałe przyzwolenie na braki podstawowych umiejętności miękkich uformowało pewne zachowania i postawy, które teraz trudno będzie zmienić.
Swoją drogą, jeśli zapewniamy klientom niezbędny team do pracy od ręki, to zwykle dzieje się to kosztem obniżania oczekiwań i zatrudniania specjalistów, którzy nie do końca specjalistami są, a to z kolei buduje również w jego oczach niekorzystny i nie-tak-dobry-jak-kiedyś wizerunek polskich specjalistów.
Poza tym, nie należy zapominać, że to w naszym kraju zawód programisty jest tak prestiżowy i roszczeniowe postawy, które są tutaj tolerowane, nie muszą być tak dobrze (i raczej na pewno nie będą) tolerowane poza granicami naszego kraju. Ponadto, wysokie ego i przekonanie o własnej ekspertyzie nie zawsze czyni nas najlepszymi partnerami do współpracy; zwłaszcza w środowiskach, w których unikanie konfliktów jest wpisane w DNA narodu.
Jakość nie tak istotna, jak nam się wydaje
To bardzo smutne, ale to my w Polsce kładziemy taki nacisk na jakość. I często zapominamy, że inni (inni w kontekście narodowościowym, ale też inni jako pełniący inne role w organizacji) trochę mniej. Stakeholderzy zwykle nie mają technicznego know-how, więc zazwyczaj nie rozumie, co developer robi, a co dopiero czy robi to z należytą jakością.
W rezultacie, bardziej „opłaca się” nawiązać współpracę (przez proxy w postaci software house’u jak i bezpośrednio) ze specjalistami chociażby z Litwy, Łotwy, Estonii czy Gruzji, którzy potencjalną pracę będą traktować jako wielką szansę. Wraz z otrzymaniem szansy, będą się stale rozwijać, dodatkowo robić to wszystko za mniejsze pieniądze i z większym brakiem „problemów”, które często gęsto wynikają z naszej polskiej dbałości o najwyższą jakość, zapominając, że klient potrzebuje czegoś innego; zwykle po prostu – żeby działało i to najlepiej dziś lub jutro, a manager/proxy – żeby nie miał dodatkowych tasków na koniec dnia w postaci rozwiązywania problemów interpersonalnych w teamie.
Przewaga, której rynek już nie kupuje
Nie chcę zabierać znaczka jakości naszemu rodzimemu rynkowi specjalistów, jeśli chodzi o dziedzinową ekspertyzę, wykształcenie, znajomość języków i tak dalej. Ale niestety, dla większości klientów z Europy Zachodniej czy Północnej, zwłaszcza tych, którzy ze względów kulturowych, mocno cenią sobie brak problemów interpersonalnych, ważniejsze będzie samo dowiezienie (mniej ważne jak – zatem jakość schodzi tu na drugi plan) i spokój wynikający z braku konieczności rozwiązywania problemów na koniec dnia.
Często zapominamy, że wszyscy, niezależnie od roli, jesteśmy tylko ludźmi i na koniec dnia chcemy po prostu czuć spokój i zamknąć wszystkie taski na swojej to-do liście. I ten wewnętrzny spokój jest wówczas znacznie ważniejszy niż jakość o którą tak dbamy.
Adnotacja dla tych, którzy mogli poczuć się offended
Drogi_a ekspercie_tko techniczny_a, jeśli to czytasz, to najpewniej należysz do bańki ludzi zaangażowanych i stale rozwijających się, więc po pierwsze – większość powyższego wpisu może nie być o Tobie, a po drugie – cała treść dotyczy bardziej trendów i tendencji rynkowych, a więc niekoniecznie tego na co mamy wpływ.
Cheers!
O.
Coś jest w tym co napisałaś!
Dzięki za lekturę, Mateusz! Co pokrywa się z Twoimi obserwacjami/przemyśleniami? 🙂
Ciężko nie zgodzić się z Twoim artykułem. Pracuję jako programista i od wybuchu pandemii zacząłem obserwować w IT pewne zmiany, a być może tylko tak mi się wydaje i rynek wyglądał tak już wcześniej.
Popyt na projekty w pewnym momencie wzrósł na tyle, że firmy zaczęły zatrudniać na potęgę oferując znacznie wyższe zarobki niż do tej pory. Wystarczyły 2 miesiące, żeby zauważyć ogólny spadek poziomu programistów. Być może to przez rozluźnienie na pracy zdalnej, a może ktoś wziął sobie 3 kontrakty i zakopał się do tego stopnia, że nie potrafi niczego dowieźć. Oczywiście nikt nikomu nie broni wykonywać kilku projektów na raz, ostatecznie po to zakłada się działalność – stolarz też nie kończy na jednym kliencie. Ale właśnie, ta krótkowzroczność – bo przecież klienci i tak walą drzwiami i oknami. Odnoszę delikatne wrażenie, że praca zdalna niektórym odrobinę „zwirtualizowała” myślenie i zapomnieli o budowaniu relacji z klientem. Wszystko jest spoko do momentu kiedy się okazuje, że świat jednak jest mały.
Jakość. To prawda, że polscy programiści kładą na nią duży nacisk, a przynajmniej znakomita większość z którą miałem styczność to robiła. Często jednak jak zastanawiałem się nad tym, jak do tego ma się trójkąt projektu. Na efekt pracy składa się czas, budżet i jakość. Jedno z trzech zawsze musi zostać poświęcone kosztem dwóch pozostałych. Co się dzieje w momencie kiedy ambitny zespół techniczny postanawia wzbić się na wyżyny swoich umiejętności przy tworzeniu MVP albo typowo startup’owego projektu, gdzie czas i budżet grają kluczową rolę? „Nadmierna” jakość powoduje wydłużenie czasu i przepalenie budżetu. Oczywiście, gdy projekt dojrzał, zarabia, a klient tego chce – jakość należy podnosić.
Z jakością idzie oczywiście rozwój, bo można napisać super kod, analizować, pomyśleć, wyciągnąć wnioski, może wdrożyć jakieś nowe rozwiązanie albo architekturę, pójść za trendami. Zawsze uważałem, że jeśli jestem w pracy, pracodawca płaci mi za wykonaną robotę w określonym czasie, to ja mam dostosować wdrażane rozwiązania do czasu, jaki mam na dowiezienie mam, a przecież i tak sam sobie wszystko estymuję. To nie jest koncert życzeń, że ja w pracy mam mieć możliwość ciągłej nauki. Ja przyszedłem do pracy i oczekuje się ode mnie, że będę umiał (przynajmniej częściowo). Jeżeli mam zespół, który wspiera mnie w nauce – to super. Chyba żadna inna branża nie pozwala na rozwój w tak dobrych warunkach. Ale mimo wszystko, powinniśmy się dokształcać (głównie) sami. Co by się stało z lekarzem, który powiedziałby pacjentowi, że musi zaczekać, bo on chce doczytać jak mu pomóc? Za chwilę wiele osób może zarzucić mi herezję. W pewnych sytuacjach nie warto stawiać na nadmierną jakość. Zdarzało mi się spotykać programistów, którzy za jedyną słuszną jakość uważali to co sami robią. Nie przeczę, często pisali bardzo dobrej jakości kod, tylko po co? Wspomniany stolarz nie umacnia biurka na komputer drutem zbrojeniowym. Wspomniany projekt MVP nie musi na etapie walki klienta o finansowanie ładować danych na ekran w 100 milisekund, może być 300 milisekund. Tutaj przydaje się dobry manager albo product owner, który pokieruje zespołem jak należy – dlatego dobrze jest, gdy osoba zarządzająca projektem ma nieco wiedzy technicznej. Cały ten wywód o jakości tyczy się oczywiście jakości kodu, ale podobnie jest z pisaniem testów – dla startup’u czy MVP mogą przepalić budżet i czas.
No i właśnie, klienta czasami nie obchodzi jak coś działa – jeżeli działa tak jak sobie życzył, to musi być ok. Jeżeli coś przerosło jego oczekiwania – szansa na kontynuowanie współpracy rośnie, firma zarobi, powinna to docenić. Tak jak napisałaś należy traktować się po ludzku. Szczere zachowanie się z klasą niejednokrotnie potrafi załagodzić potencjalny konflikt.
Jakość kodu nie ma nic (lub ma niewiele) wspólnego z jego wydajnością. Niezwykle trudne i zbędnie czasochłonne jest zbudowanie MVP „na kolanie” a następnie rozwijanie wg dalszych potrzeb klienta. Jak uzasadnić klientowi, że należy tą samą funkcjonalność przepisać teraz od 0 w podobnym czasie? Przecież „to działa”, „jedziemy dalej”.
Pomimo tego, że korzystamy z wiedzy zdobytej przy tworzeniu MVP, cały kod jest najprawdopodobniej do przepisania.
O wiele lepiej jest kłaść nacisk na jakość kodu od samego początku, w miarę zdobywania wiedzy kod refaktoryzować i w miarę potrzeb optymalizować (wydajność).