Home

Jedna prosta metoda by programiści chcieli pracować na utrzymaniówce?

Można zauważyć oczywistą tendencję, że programiści źle znoszą pracę w utrzymaniowych projektach z legacy kodem. Z drugiej strony, przy takich projektach też trzeba pracować, a stoją za nimi duże pieniądze.

Sam wciąż (mimo ~4 lat doświadczenia komercyjnego) jestem na etapie, gdzie praca w ciekawych projektach, w nowych technologiach, najlepiej od zera stanowi dla mnie główny bodziec do pracy, ważniejszy niż pieniądze. Przy kilkunastu tysiącach miesięcznie, 1-2 tysiące w te czy wewte nie robi już specjalnej różnicy, a kosztem trochę niższej wypłaty jestem w stanie znaleźć firmy w których będę mógł pracować z zapartym tchem, bez natychmiastowego wypalenia i nerwów.

Wydaje mi się, że to podejście jest znane większości programistom, szczególnie młodszym – i nawet nie mam tu na myśli stażu, ale wiek. Bo za młodu bardziej się chce i jest większa motywacja do rozwoju i nauki (czyli po 8 godzinach pracy kolejne 4 godziny pobocznych projektów czy czytania). Patrząc na starszych wiekiem deweloperów zdecydowanie częściej można zauważyć większą obojętność związaną z projektami, byle nie było nadgodzin, a praca stabilna. Jest to w pełni logiczne, bo priorytety się zmieniają, a Czysty Kod zamienia się na czystą pieluchę dziecka.

W skrócie, różni ludzie mają różne cele i priorytety, ale w tym nic dziwnego. Jednak podstawowe modele popytu i podaży są wszechobecne, więc na pewno można zauważyć następujące tendencje:

  • Im gorszy projekt, tym więcej się płaci za jego utrzymanie. Przeważnie jest to utrzymaniówka starych systemów, projekty w niechcianych technologiach czy „poprawianie po Hindusach”.
  • Im więcej płaci się za projekt, tym bardziej firmie zależy by taki projekt dostać. Projekty utrzymaniowe to przeważnie długi i stabilny dochód.
  • Im gorszy projekt, tym trudniej znaleźć programistę, który będzie chciał go utrzymywać.Ludzie się wypalają, odchodzą z projektów lub firm. Mimo, że różni ludzie mają różne definicje „złych” projektów, pewne cechy pozostaną uniwersalne.

Widać jak czarno na białym, że mamy konflikt interesów. Dlaczego ktoś miałby za te same pieniądze robić super fajny i ładny projekt w nowych technologiach w firmie X lub 30 letni system bankowy w firmie Y? Wiadomo, że firma Y musi więcej zapłacić – to zdaje się mieć miejsce.

A co jeśli weźmiemy pod lupę przeciętną agencję czy software house, które mają różne projekty – od projektów „od zera” po utrzymaniowe? W jaki sposób nakłonić pracownika by chciał w nim pracować, mimo że jego/jej koledzy/koleżanki pracują w fajnych projektach? Jak zgasić poczucie niesprawiedliwości i frustrację?

Moim zdaniem, można spróbować zastosować dwie metody.

1: Poznać pracownika

Zanim zacznie się zastanawiać nad tym jak pracownika motywować, trzeba zastanowić się co go motywuje. Jak wspomniałem, wystarczy często różnica wieku, by całkowicie inne priorytety kierowały ludźmi. Dorzućmy setki unikatowych charakterów i przeróżne środowiska w firmach, a nikt nie będzie w stanie przewidzieć co motywuje poszczególne osoby.

Dlatego uważam, że szalenie ważne są spotkania 1-on-1 i ogólnie regularne rozmowy z pracownikami, które mają na celu poznać jego oczekiwania, plany rozwojowe i motywacje. Tego typu spotkania mogą odbywać się raz na miesiąc czy kwartał, ale zdecydowanie unikałbym dłuższych okresów. Trzy miesiące potrafią być wystarczającym czasem by ktoś trafił do nowego projektu i zdążył odejść przez to z firmy…

W ten sposób w organizacji można sobie wyciągnąć persony pracowników, przykładowo:

  • Junior z parciem na rozwój
  • Regular dev, który chce zmienić technologie
  • Senior, który chce robić więcej biznesu
  • Team leader, który ma dość biznesu i chce więcej programować

Zwróć uwagę, że każdy z tych typów ma zupełnie inne potrzeby i motywacje. Jest spora szansa, że junior ponad wszystko będzie stawiać szalony rozwój. Często spotkasz też ludzi którzy chcą zmienić technologię i jeśli nie dostaną takiej możliwości, to zmienią firmę w tej potrzebie. Są też programiści, którzy dobrze czują się zarządzając oraz tacy, którzy trafili na stanowiska zarządzające (czy liderskie), ale tego nienawidzą.

2: Zmotywować pracownika

Znając już swoich pracowników i to co nimi motywuje, można zastanowić się jak zmotywować ich do pracy. Zakładam, że jeśli odpowiedni pracownik „trafi” w odpowiednie miejsce, to wszystko jest w porządku i każdy jest szczęśliwy. Co jednak, jeśli wśród młodych gniewnych i żądnych rozwoju programistów, trzeba wybrać kogoś do utrzymania bardzo dochodowego projektu gdzie cała aplikacja jest napisana w jednym pliku przez studentów z Indii?

Popyt, podaż i mikroekonomia

Gdy nie ma kto wykonywać danej pracy, stawki rosną. Gdy dana praca nie wymaga wykwalifikowania lub jest przyjemna, to jest dużo potencjalnych chętnych do jej wykonywania. Jednak w obrębie organizacji, gdy już pracownik zostanie do niej wcielony, tego typu model zanika.

Co gdyby projekty w firmie były odkryte, a pracownicy sami zgłaszaliby się do ich robienia? Przeważnie za zamkniętymi drzwiami projekty przydzielane są przez management, a nie ma w tym żadnego benefitu. Pracownicy mogliby zgłaszać swoje zainteresowanie danym projektem (na podstawie zarówno kompetencji, branży czy prywatnych potrzeb), a otwarty system przydzielania pracowników wpływa pozytywnie na transparentność (a ta na zadowolenie w pracy).

Załóżmy że potrzebujemy przydzielić pracownika do projektu gdzie nikt nie chce pracować (i nikt się nie zgłasza w naszym otwartym systemie). Wtedy proponuję motywować, ale także publicznie, na przykład finansowo. Nikt nie chce? No to ekstra 500zł miesięcznie dla chętnego. Dalej nikt? No to 1000zł. Po zakończeniu projektu lub odejściu z niego – premia zostaje wycofana.

Tego typu dodatek, szczególnie jeśli jest publiczny, rozwiązuje poczucie „niesprawiedliwości”, gdzie z ofiary staje się to świadoma decyzja za określone zyski. Nikt nie będzie kwestionować tego typu premii, bo nie będzie chciał w takim projekcie pracować.

Równocześnie, zakładam że tego typu projekty są wysokomarżowe i zdecydowanie jest skąd wziąć pieniądze na te premie.

Ale mogą być problemy.

Z tego typu systemem nigdzie się nie spotkałem, ale możliwe że są na to powody. O ile w małych organizacjach, szczególnie w turkusie (lub okolicach) pracownicy zdają się być uczciwi i utożsamiać się z firmą, tak w dużej korporacji ludzie raczej nie czują potrzeby działać na rzecz firmy swoim kosztem.

Istnieje ryzyko, że pracownicy bedą świadomie odrzucać wszystkie projekty oraz czekać aż pokażą się tam premie, a nawet wstrzymywać decyzję czekając na kolejne, wyższe.

Finalnie możliwe jest, że te premie będą przyznawane każdemu, a tu nie o to chodzi.

Równocześnie istnieje pytanie jaki wpływ na morale będzie miało zabranie tego typu dodatku – ludzie dużo gorzej reagują gdy się im coś zabiera, niż gdyby tego nigdy nie mieli.

To są moje przemyślenia, które na pewno musiałby obalić lub potwierdzić ktoś kto się zajmuje prowadzeniem firmy IT. Ale myślę że w formie eksperymentu warto takie coś wprowadzić, szczególnie w organizacjach turkusowych.