Bullshit jobs w pracach deweloperskich

Czas uderzyć się w pierś i wskazać stanowiska z jakimi spotykają się programiści i jakie nie mają tak naprawdę sensu. Czym jest bullshit job? To stanowisko sztucznie powołane, które w zasadzie niczego nie wnosi do procesu produkcyjnego. Wymienię tutaj dwa przypadki, choć jest ich oczywiście znacznie więcej, ale nie chcę wychodzić poza prace deweloperskie.

Mariusz Walczak. Tech lead w Softfin. Absolwent Warszawskiej Wyższej Szkoły Informatycznej. Pasjonat inżynierii oprogramowania, swoje aplikacje tworzy w PHP i językach opartych na ES6/7. Prywatnie miłośnik futrzanych czworonogów, oraz winiarstwa i nalewkarstwa. Wszystkie jego teksty znajdziecie pod tym adresem.

Triber, to zawód, czy fanaberia?

Mamy nowy zawód. Nazywa się triber i już zachodnie korporacje zachwycają się nim. Chwalą się, że jest potrzebne, pomaga zaoszczędzić czas i pieniądze. Kim jest triber? To osoba, która tworzy zespół i kieruje jego zadaniami. Hmm, czy team leader i kierownik zespołu deweloperskiego nie mają tychże zadań? To przecież część ich pracy, natomiast w korporacjach panuje zabawna zasada, że awansuje się dopóki człowiek sobie z czymś nie radzi. Przekonałem się o tym, gdy w pewnym momencie zostałem mianowany na team leadera i poległem, awansowałem, bo miałem największy staż, ale zero, powtarzam zero pojęcia o przewodzeniu zespołem. Musiałem dużo pracować, aby stać się porządnym leaderem, przetestować wiele schematów rozwiązywania problemów.

Zobacz też

Praca w IT Refresh. Jak dbasz o to, by być nadal cenionym engineerem?

Zasada Petera

Zdałem sobie sprawę, że w korporacjach awansuje się z dwóch powodów: bo ktoś jest zbyt dobry na swoim stanowisku albo… nie chce być awansowany. Tych drugich trzeba doceniać, głaskać i mówić im prawdę, bo przecież bez nich firma upadnie. Ten efekt ma już od dawna nazwę zasady Petera, a brzmi ona tak: „W organizacji hierarchicznej każdy awansuje aż do osiągnięcia własnego progu niekompetencji.”

Także osoby, które powinny być kierownikami działu technologii, lub obejmować ładnie brzmiące stanowisko: CTO, często nie mają pojęcia o tym co robią, nie wiedzą jak zarządzać ludźmi, nie potrafią ogarnąć prawidłowo projektów i dopiero tego wszystkiego uczą się. Część zadań zrzucają na liderów zespołów technologicznych i tutaj znów dzieje się magia, bo w większość z nich też tego nie potrafi. W mojej karierze, trafiło się trzech liderów co potrafiło rzeczywiście zarządzać zespołem, ale w większości trafiali się tacy, przez których ludzie wręcz uciekali z pracy, bo nie szło wytrzymać. Jeden z nich nawet groził mi odejściem, co wywołało u mnie tylko ironiczny uśmiech.

Mamy więc osoby, które są na stanowisku, jakoś sobie radzą, choć nie do końca, ale to jakoś sprawia, że zarząd nie widzi powodu do zwolnienia takiej osoby, lub zrzucenia go oczko niżej w hierarchii, czyli tam, gdzie czuje się jak ryba w wodzie.

Dochodzi z czasem do momentu, że kierownikami stają się osoby, które nie powinny nimi być, bo Ci co mieli kompetencje odeszli, gdyż nie mogli znieść swoich niekompetentnych kolegów. Wtedy zarząd wpada na pomysł: zatrudnijmy kogoś, kto to potrafi. Tak rodzi się triber, czyli osoba, która zarządza składem osobowym i dodatkowo zadaniami jakie musi zespół wykonać, czyli wykonuje pracę jaka należy do lidera zespołu, a tak naprawdę do kierownika działu.

Przykładowa sytuacja: mamy kierownika projektu Tomka, człowieka, który ogarnia zespół i projekt, zleca mi kierunek wykonywania działań, a ja dalej kieruje pracami. Natomiast to on mówi mi o kolejności głównych kamieni milowych i on kontaktuje się z ludźmi z zespołu w sprawach dotyczących urlopów i całej reszty. Ja tylko kieruje zespołem pod względem technicznym i tylko pod względem technicznym prowadzę projekt. On robi całą resztę.

Przykładem negatywnym będzie Adrian, który nie potrafił zarządzać ludźmi, sprawił że 80% z nich uciekło, lub zostało zwolnionych. Traktował osoby jako zasób, czyli na zasadzie: projekt wymaga takiego, a nie innego zasobu, no to ciach, numery 1, 14, 16 zrobicie to. Programista numer 28 nauczysz się sharepointa. Nie chcesz? To nie jesteś mi potrzebny. Adrian to typowy karierowicz, który chce się wykazać słupkami, nie ma pojęcia jak zachęcać ludzi do pracy, jak z nimi współpracować, programistów traktuje jako niewyczerpany zbiór zasobów projektowych.

Tutaj ludzie nie chcą pracować, więc idziemy po outsource, czyli koszty powstawania projektu rosną. Wtedy do akcji wkracza triber, dzięki niemu ludzie wracają, robi się ludzka atmosfera, rezygnujemy z zewnętrznych zasobów, koszty projektowe spadają i bum, mamy oszczędność. Choć tak naprawdę, zwalniając lub degradując Adriana i zatrudniając na jego miejsce takiego Tomka, nie tworzylibyśmy następnego wakatu, oraz może Tomkowi udałoby się wytłumaczyć, gdzie zarząd popełnia błędy projektowe. Czemu projekty są trudne do wdrożenia, oraz wiele innych rzeczy, jakich nie zrobi na pewno Adrian, bo nie ma o nich pojęcia.

Oferty pracy z

Scrum master to zestaw umiejętności, nie zawód

Kolejnym bullshit jobem jest scrum master. Umówmy się, jeżeli mamy lidera zespołu, lub kierownika działu, to oni powinni we dwójkę mieć opanowanego scruma, oraz metodologię jakie są wykorzystywane w firmie. W praktyce kierownikowi nie chce się, a lider, woli trzaskać zadania niż się bawić w spotkania. Dlatego pojawia się scrum master, który wymaga tego wszystkiego. Rozwiązanie jest proste: procedury prowadzenia projektu, które muszą być spełniane, a jeżeli ktoś z zarządu zrobi sobie kontrolę i zobaczy, że ktoś coś olewa, to powinien wziąć na rozmowę zarówno lidera, jak i kierownika, i wytrzaskać ich po twarzy.

Zauważyłem, że nawet nie do końca dobre procedury narzucone od góry są lepsze niż ich brak, bo podążamy według jakiegoś planu, schematu, który wszyscy rozumieją. Nie ma sensu powoływać czystego scrum mastera, bo to nic innego jak pusty wakat, bo zarówno lider zna na pewno scruma, jak i kierownik działu. Wystarczy tylko na nich wymusić stosowanie scruma, czy innej metodologii.

Mały vs Korpo

Reasumując wielkie firmy toczy powolny rak. Co ciekawe żadna z nich tego nie widzi, prawda jest taka, że żadna firma tego nie zobaczy. Z resztą przyjrzyjmy się strukturom w IT wśród małych firm i wielkich korporacji. Mała firma ma jakiegoś lidera, który ma około trzech programistów w zespole. Szef przychodzi, mówi co trzeba zrobić, lider to rozprowadza po pracownikach i wszyscy sobie pracują w zespole, po cichutku.

W korporacji, szef zazwyczaj nie wie nic o projektach, od tego ma Cxx (zbyt dużo tych CTO, COO, C-Cholera-Wie-Co ), każdy z nich ma pod sobą kilku kierowników odpowiednich działów, każdy kierownik ma odpowiednią ilość liderów, każdy z tych wyżej ma jeszcze kogoś do pomocy, więc to już armia ludzi.

Mały przedsiębiorca ma zazwyczaj dobrych ludzi, nad którymi w pełni panuje, wie co się z nimi dzieje, jest na bieżąco ze wszystkim, dodatkowo w jego firmie nie ma jako takiej opcji awansu, bo nie ma niepotrzebnych obowiązków.

Korporacje, toczy problem dokumentacji każdego projektu, jest milion sposobów jak to trzeba raportować i do kogo, także liderzy 50% czasu ogarniają bałagan związany z raportowaniem, aby nikt wyżej się nie przyczepił, że oni nic nie robią. Dodatkowo dochodzi też czas decyzyjny, bo to musi przejść przez kilka poziomów.

Więc kiedy mały przedsiębiorca dowiaduje się o problemie i od razu może go załatać, duży przedsiębiorca straci tydzień pracy. To może przejdźmy jak to się przekłada na system płacowy. Mały przedsiębiorca, zarobi tyle samo co korporacja, z tym że mały przedsiębiorca ma system dwóch marż, pierwsza marża to pensje pracowników, druga marża to jego pensja, pozostałe to koszty infrastruktury oraz koszty utrzymania budynku. Czyli dajmy na to czterej programiści dostali 40 tys. złotych, szef zarobił 20 tys. złotych na miesięcznym projekcie, a koszty utrzymania budynku wyniosły ok. 5 tys. złotych. Czyli jego projekt kosztował z grubsza 65 tys. złotych, plus 18%~19% dochodowego, plus VAT i już.

Korporacja, aby zrobić dokładnie to samo, musi wystawić fakturę na 650 tys. złotych. Tam mamy system wielo-marżowy, pracownicy marża 1, kadra zarządzająca niskiego szczebla – marża 2, kadra zarządzająca wysokiego szczebla – marża 3, prezesostwo, czyli zazwyczaj kilka osób marża 4.

Zobacz też

Juniors Kotlin to kolejny krok dla Java Developera

Kiedyś korporacje były nastawione na robienie wielu projektów jednocześnie. Teraz w wielu firmach mamy do czynienia z 20 programistami, oraz armią ludzi wokół, którzy pozyskują klientów. Czyli mamy 20 osób, które coś produkują, dajmy na z 50 osób, które to starają się sprzedać, oraz wiele osób, które czymś zarządzają, albo zespołem, albo czyimiś zadaniami, albo tablicą scrumową. Robią coś, czym nie powinno się zajmować, bo leży to w kompetencjach innych osób.

Kiedyś pracowałem w cztery osoby nad projektem, który zrobiliśmy w miesiąc, a firma zgarnęła za niego 3 mln złotych, bo ktoś sprzedał taki, a nie inny kosztorys. Firma kupująca była przekonana, że ich projekt będzie robiony przez zastępy programistów, sprawdzany przez dziesiątki testerów. Poza tym byli przekonani, że pół roku to minimum jakie trzeba poświęcić, więc jak usłyszeli miesiąc, to znaczy, że cała firma będzie zaangażowana w ten projekt.
Mały przedsiębiorca nigdy nie przebije się do tego etapu. Będąc małym zrobiłby to za 300 tys. złotych i w nagrodę wysłał zespół developerski na miesięczne wakacje. Niestety zamawiający klient ma większą psychiczną pewność, że duża firma podoła, dlatego nawet nie próbuje korzystać z usług tych mniejszych.

Dodatkowym aspektem jest specjalizacja, powszechna opinia jest taka, że korporacje dają wyższe pensje, przez co mają lepszych specjalistów z IT. Od razu mówię to nie ma znaczenia, w małych firmach jest wielu uzdolnionych programistów, którzy nie chcą korporacyjnego życia, pod krawatem 8h, te wszystkie korpo-dyskusje, roszady i konspiracje. Jeśli chodzi o zarobki, to małe firmy i duże często dają dokładnie te same stawki. W moim przypadku było tak, że dostałem wyższą stawkę u małego przedsiębiorcy niż w korpo.

Podsumowanie

Reasumując, powstaje dużo bullshit jobs w obecnych czasach. Jest to związane z brakiem kompetencji osób będących na wyższych stanowiskach. Ta patologia niszczy w szczególności korporacje. Co więcej niszczy ona i ludzi, którzy widzą, że nie idzie im dobrze i zaczynają przechodzić kryzys wewnętrzny.

Jak możemy sprawić, aby nie było tego problemu? Nie przyjmujmy awansu, na który nie jesteśmy gotowi, a jeżeli czujemy, że nie dajemy sobie rady, to powiedzmy to przełożonemu. Jeżeli nas zwolni z tego powodu, to znajdziemy sobie nową pracę na stanowisku, które sprawia, że czujemy się bezpieczni i wiemy, że robimy to co nam wychodzi najlepiej.

Zdjęcie główne artykułu pochodzi z stocksnap.io.

Oferty pracy z