- Dlaczego projekty utrzymaniowe są mało atrakcyjne dla developerów
- Jak motywować pracowników w projektach utrzymaniowych
- Daj dodatkową szansę rozwoju
- Szkolenia
- Udział w dodatkowym projekcie
- Ustal jasny horyzont czasowy przydzielenia do takiego projektu
- Pokaż wartość tego co robi zespół
- Daj dodatkową szansę rozwoju
Czytając oferty pracy dla programistów można odnieść wrażenie, że projekty IT realizowane przez software house to głównie projekty 'green field’ tworzone z wykorzystaniem najnowszych technologii, praca w młodym i prężnym zespole z wykorzystaniem nowoczesnych metodyk zwinnych itd. Rzeczywistość niestety nie zawsze wygląda tak różowo – niejednokrotnie szukani są również programiści, którzy będą utrzymywać (oraz w jakimś stopniu rozwijać) aplikacje typu legacy. I trudno się temu dziwić – takie systemy działają w wielu organizacjach (dużych i małych), nie ma potrzeby, albo budżetu żeby wymienić je na napisane od nowa aplikacje, ale istnieje ciągła potrzeba wykonywania niewielkich modyfikacji i usuwania znalezionych błędów. Praca jak praca – ktoś musi ją wykonać … tyle że mało kto chce.
Dlaczego projekty utrzymaniowe są mało atrakcyjne dla developerów
Stare przekleństwo programistów brzmi „obyś poprawiał czyjś kod” – a projekty utrzymaniowe systemów legacy to głównie poprawianie (czasami rozwijanie) aplikacji napisanych dawno i nie zawsze dobrze. Dodatkowo zwykle nie ma w takich projektach miejsce na wykorzystanie nowoczesnych frameworków (np. React czy Vue dla JavaScript), zdarza się, że nie można podbić wersji języka programowania na aktualną – osoby zaangażowane w takie projekty często zatem skarżą się na brak możliwości rozwoju, nudną, powtarzalną pracę, brak ciekawych wyzwań, czy konieczność pracy z zaniedbanym kodem i długiem technicznym.
Nie dziwi, że znaczna część programistów unika takich projektów jak ognia, czasami wprost 'grożąc’ odejściem z pracy jeśli do takiego projektu zostali by przydzieleni, albo nie zostaną z niego szybko wyrotowani. Sytuacja na rynku pracy sprzyja takiemu podejściu, bo zarówno software house jak i firmy samodzielnie rozwijające swoje oprogramowanie cierpią od kilku lat na niewystarczającą ilość rąk do pracy (być może aktualna sytuacja światowa nieco to zmieni).
Z drugiej strony systemy typu legacy były i będą obecne w wielu firmach – niejednokrotnie są to tzw core’owe aplikacje bez których organizacja nie jest w stanie realizować swoich procesów biznesowych lub back-office’owych. Ich utrzymanie i rozwój jest zatem kluczowy dla przedsiębiorstwa – a koszt tego typu działań jest mniejszy niż wytworzenie takiego systemu od nowa. Nawet jeśli decyzja o zastąpieniu danego systemu nowoczesnym rozwiązaniem została podjęta to i tak musi on być utrzymywany do czasu pełnego wdrożenia nowego narzędzia. Tak więc ręce do pracy w obszarze utrzymania tych systemów zawsze będą potrzebne
Jak motywować pracowników w projektach utrzymaniowych
Już od jakiegoś czasu wiele organizacji zauważyło, że system popularnych benefitów (typu karta multisport, owocowe środy itp) przestał spełaniać funkcję motywującą – szczególnie, że podczas pandemii i coraz powszechniejszej pracy zdalnej wiele z tych dodatków przestało mieć sens. Do pewnego stopnia motywatorem mogą być wyższe zarobki, ale trzeba mieć świadomość, że jest to również narzędzie które działa krótkoterminowo, w szczególności że ogólnie zarobki w branży IT w ostatnim czasie znacząco wzrosły (badania mówią o wzroście nawet na poziomie 20%). Z drugiej strony budżety na utrzymanie i rozwój systemów legacy też nie są z gumy, a zarobki developerów często stanowi znaczącą część wydatków na utrzymanie (dodatkow dochodzą jeszcze różnego rodzaju licencje, maintenance sprzętu lub usługi chmurowe).
Co zatem można zrobić aby pozyskać i utrzymać (przynajmniej przez jakiś czas) pracowników w takich projektach?
Daj dodatkową szansę rozwoju
To co bardzo często zniechęca developerów do pracy w projektach utrzymaniowych jest obawa (czasami całkiem uzasadniona) przed brakiem możliwości rozwojowych. Zaadresuj tą obawę poprzez zapewnienie pracownikom możliwości rozwoju poza projektem. Pomysłów na taki rozwój może być kilka:
Szkolenia
Szkolenia lub konferencje to jedna z form rozwoju kompetencji i nowych umiejętności. Część szkoleń może zakończyć się także zdaniem oficjalnego certyfikatu, co może być dla uczestnika dodatkowym atutem (i tutaj drobna dygresja – certyfikaty są zwykle wystawiane na osobę zdającą a nie na firmę kierującą na szkolenie – w związku z tym niektóre firmy nie widzą korzyści w inwestowaniu w certyfikaty, które uzyskuja ich pracownicy, obawiając się, że może to się przyczynić do odejścia specjalistów do konkurencyjnych firm).
Osoby pracujące w projektach typu maintenance często mają doczynienia z tzw. legacy code (przestarzały kod) – utrzymanie i rozwój takiego systemu może być frustrującym zadaniem – być może warto zainteresować się szkoleniem Legacy Fighter (https://legacyfighter.pl/) przygotowanym przez takie osobistości polskiej dev-sceny jak Maciej Aniserowicz, Kuba Pilimon i Mariusz Gil.
Udział w dodatkowym projekcie
Część organizacji oprócz komercyjnych projektów prowadzi również różnego rodzaju inicjatywy wewnętrzne, lub angażuje się w ciekawe przedsięwzięcia non-profit. Niejednokrotnie w takich projektach zespół może wybrać narzędzia i rozwiązania, które chce zastosować – mogą to być też technologiczne nowinki, z którymi firma chce się przy okazji takiego projektu zapoznać, ocenić przydatność itd.
Zaangażowanie osób pracujących na codzień w projekcie typu maintenance&support w tego typu przedsięwzięcie może stanowić pewnego rodzaju przeciwwagę do niezbyt pasjonujących wyzwań codziennej pracy. Należy jednak wyraźnie określić podział czasu (np. w układzie miesięcznym) poświęcanym na oba projekty – z jednej strony chcemy zapewnić odpowiednią jakość obsługi oraz gwarantowane czasy reakcji w projekcie podstawowym, z drugiej strony praca nad 'side-project’ nie powinna wymagać dodatkowych nadgodzin od pracownika.
Ustal jasny horyzont czasowy przydzielenia do takiego projektu
Wiele osób, przed którymi stoi perspektywa dołączenia do projektu utrzymaniowego, obawia się perspektywy pozostania w nim na długie lata. To prawda, że z punktu widzenia organizacji (zarówno po stronie dostawcy jak i klienta) im dłużej dany developer pracuje w projekcie – tym lepiej. Ma możliwość dobrze go poznać – i to nie tylko od strony technicznej (znajomość kodu, rozwiązań architektonicznych itd), ale też od strony domeny biznesowej – procesy biznesowe, nomenklatura użytkowników itd. Być może znajdą się osoby, które będą się czuły komfortowo w takim dobrze rozpoznanym środowisku i nie będzie im zależało na szybkiej zmianie projektu. Jednak większość programistów chce się rozwijać, poznawać nowe technologie, frameworki i rozwiązania – a tego w projekcie utrzymaniowym zwykle nie uświadczą.
Dlatego mimo niewątpliwych korzyści dla organizacji z długoterminowego przypisania procownika do takiego projektu, warto zagwarantować, że taka alokacja jest ograniczona czasowo. Ponieważ będzie się to wiązało z regularną rotacją pracowników w takim projekcie należy zadbać o dobrą dokumentację i proces onboardingowy, który pozwoli sprawnie wdrożyć nową osobę na miejsce rotowanego pracownika. Pomocne będą wszelkiego rodzaju check-listy, słowniki terminów, prezentacje itd. które pozwolą zapoznać się zarówno z obszarem technicznym jak i biznesowym projektu utrzymaniowego.
Pokaż wartość tego co robi zespół
Nic tak nie demotywuje do realizowanej pracy jak poczucie braku celu i sensu tego co się robi. A przecież projekty utrzymaniowe przynoszą realną wartość użytkownikom końcowym wspieranego systemu. Od tego czy incydenty zgłoszone przez użytkowników zostaną sprawnie rozwiązane zależą być może procesy biznesowe realizowane przez organizację. Jakość obsługi IT wymiernie wpływa też na komfort pracy osób wykorzystujących danych system. Taką wartość należy jednak przedstawić członkom zespołu. Czasami bardzo pomocne może się okazać spotkanie z przedstawicielami użytkowników, którzy z perspektywy 'odbiorców’ usługi opowiedzą, jak wprowadzane zmiany, lub rozwiązane incydenty przyczyniły się do poprawy realizowanych przez nich zadań. Niejednokrotnie zwykłe ’dziękuję za Waszą pracę’ może dużo zdziałać.
Ale przecież to wszystko kosztuje …
Kierownictwo firmy może nie patrzeć przychylnym okiem na niektóre z powyżej prezentowanych porad, ponieważ generują one dodatkowe koszty – szkolenia, poświęcanie czasu developra na 'side-project’, oraz rotacja pracownika pociągają za sobą realne obciążenia finansowe. Warto jednak zastanowić się ile kosztuje firmę rekrutacja nowego pracownika, albo jakim wyzwaniem dla organizacji jest nieplanowana zmiana pracownika w projekcie. Przy obecnym niedoborze programistów na rynku i trudnościach w pozyskaniu odpowiednich talentów do organizacji z pewnością warto zrobić wiele, aby pracownik nie 'rzucił papierem’ po kilku tygodniach/miesiącach pracy w projekcie utrzymaniowym.
Podsumowując
Projekty utrzymaniowe (maintenance and support) pewnie nigdy nie będą wymarzonym miejscem dla większości programistów, chociaż mogą znaleźć się jednostki, którym takie środowisko będzie pasowało. Jeśli jednak odpowiednio zaplanujemy przydział developerów do takiego projektu i przedstawimy im zalety pracy w tym projekcie, być może uda się uniknąć sytuacji gdy ludzie wypalają się i odchodzą z firmy.