Ile zarabiają programiści i od czego faktycznie zależą ich zarobki?
30 Lis


W wielu z nas (mówię tu głównie o osobach z branży), sama rozmowa na temat programistów lub ich zarobków budzi powszechne wzburzenie. Dlaczego tak się dzieje i dlaczego ten zawód jest tak wysoko wynagradzany? Powodów jest co najmniej kilka. W niniejszym artykule postaram się przybliżyć najistotniejsze czynniki wpływające na wysokość zarobków programistów.

1. Mało kto potrafi to robić – analityczny i matematyczny umysł

Generalnie wszystkiego można się nauczyć, ale nie każdy jest w stanie być dobrym matematykiem czy informatykiem. Wielu odpada. Gdy rozpoczynałem studia na Wojskowej Akademii Technicznej, rektor uczelni na inauguracji zapytał jak wiele osób zamierza skończyć kryptologię. Rękę podniosło około 50 osób. Dodał wówczas zdanie: „Gratuluję odwagi.”. Myślę, że te słowa idealnie oddają rzeczywistość. Wiele się jednak zmieniło – nauka języka C kiedyś, a nauka języka np. Swift teraz to dwa odmienne byty. Mimo wszystko nie każdy jest w stanie poradzić sobie z natłokiem informacji na forach internetowych, językiem angielskim czy tutorialami na YouTube. Do tego potrzebna jest zdolność analitycznego, programistycznego myślenia. Kiedy posiądziemy już taką umiejętność – możemy spróbować swoich sił w programowaniu.

2. Umiejętność pracy z ludźmi i komunikatywność

Dobry programista Java’y, posługujący się biegle językiem angielskim oraz świetny w komunikacji (mało takich ideałów chodzi po świecie), jest w stanie zarabiać nawet powyżej 20.000 zł netto/msc i to bez najmniejszych problemów. Musi jednak wykazywać się rozumieniem potrzeb biznesowych klienta, musi wiedzieć jak prowadzić skype call’e z zespołem, w jaki sposób rozmawiać z klientem docelowym i jak chronić interesy przedsiębiorstwa, dla którego pracuje. Tylko dzięki temu ma szansę zostać docenionym i podnosić swoje oczekiwania finansowe. Niestety wielu programistów, bardzo dobrze przygotowanych merytorycznie, odpada już na samej rozmowie rekrutacyjnej gdyż pracodawca oczekuje czegoś więcej – mimo, że są świetnymi inżynierami to niewiele więcej wnoszą do ich interesu. Jeżeli dochodzi do wymiany zdań między programistą, a klientem przychodzi moment rozczarowania. Oczywiście typowy programista nie zawsze jest w kontakcie z klientem – często jego zadanie przejmuje lider zespołu i to ten powinien wykazywać się wysokimi umiejętnościami interpersonalnymi, niemniej jednak sama rozmowa w zespole jest równie istotna. Nie występują wówczas niepotrzebne spięcia między współpracownikami, marnowanie czasu na dodatkowe SCRUM’y lub co najgorsze – pomyłki skutkujące przepisywaniem danego fragmentu kodu na nowo.

3. Doświadczenie

Sama wiedza oraz komunikatywność to jednak za mało. Do zarabiania wysokich kwot tj. 15.000 zł – 25.000 zł netto miesięcznie, niezbędne jest doświadczenie. Nie mówię tu o doświadczeniu uzyskanym w pracy dla samego siebie lecz doświadczeniu komercyjnym. Przyda się także sprawna umiejętność pokazania swoich zalet na podstawie ciekawego CV oraz portfolio projektów. Osoby z mniejszym doświadczeniem zarabiają w tej branży mniejsze pieniądze – ich zarobki (zależnie od technologii) sięgają od 30 do 70 zł za godzinę pracy przy czym ich doświadczeni koledzy mogą liczyć na kwoty powyżej i dużo powyżej 100 zł netto za godzinę. Od czegoś jednak trzeba zacząć, więc jeśli jesteś Juniorem lub Middle’em – wybieraj ambitne firmy oraz ambitne projekty. Tylko po wejściu na głębokie wody masz szansę na rozwój.

4. Dokładność i szybkość

Drodzy programiści (mówię tu o osobach zarabiających blisko 20.000 zł netto miesięcznie lub więcej) to osoby przykładające dużą wagę do szczegółów. Nie są to programiści wyznający zasadę – „jak będzie coś nie tak to kolega z działu QA to wychwyci i najwyżej utworzy ticket w Jira’rze i bug będzie załatany”. Takie osoby często prześlizgują się w korporacjach, ale nie jest to strategia na dłuższą metę, a branża jest na tyle mała, że każdy szanujący się programista będzie bał się o swoją reputację (jeśli faktycznie jest dobry). Dobry (i co za tym idzie, często drogi) programista to osoba, po której testowanie produktu jest czystą przyjemnością ponieważ błędy są sporadyczne, oprogramowanie ma czysty i dobrze zakomentowany kod, wszystko stworzone jest zgodnie z obowiązującymi paradygmatami programowania w danej technologii. Takie osoby mają szansę na polecenie do innych, lepiej płatnych firm, a jeśli są do tego szybkie w swojej pracy mogą liczyć na wysokie premie.

Podsumowanie:

Dobry programista to programista szybki, dokładny, komunikatywny oraz doświadczony przez co skuteczny w działaniu. Tak uzdolniona osoba może liczyć na słone wynagrodzenie (powyżej 100 zł netto za godzinę pracy). Natomiast programista leniwy, wolny, niedokładny i sprawiający problemy przy najprostszych sprawach (robienie na złość pracodawcy, oszukiwanie, celowa niedokładność i brak empatii) to programista słaby, który owszem będzie zarabiał dla większości z nas duże pieniądze, ale są to pieniądze krótkoterminowe, a sam dodatkowo naraża się na utratę reputacji co skutkuje brakiem poleceń lub zleceń w przyszłości.

Zarządzanie projektem IT – komunikacja w zespole
28 Paź


O tym jak ważna jest komunikacja w pracy – nie musimy nikomu mówić. Po prostu jest ważna i tego należy się trzymać. Ten fakt jest oczywisty, ale już mniej oczywista wydaje się „jakość” owej komunikacji, a to od niej w dłuższej perspektywie zależą sukcesy firmy oraz jej efektywność. Komunikacja jest szczególnie istotna w przypadku projektów inżynierskich takich jak np. IT. W grę wchodzą często bardzo duże pieniądze inwestora przeznaczone na dowiezienie projektu w określonym czasie i (jeśli jest to model Fixed Time&Cost) budżecie. Od tego jak projekt będzie prowadzony, na kiedy oddany, z jaką ilością błędów oraz jaką jakością kodu – zależy często forma i jakość komunikacji pomiędzy interesariuszami projektu. W kilku zdaniach postaram się przybliżyć najbardziej „czułe punkty” komunikacji w zespole projektowym tworzącym oprogramowanie dla klienta.

1. Po pierwsze – narzędzia

Istotnym elementem całej komunikacji jest odpowiedni dobór narzędzi projektowych takich jak narzędzia do komunikacji wewnętrznej (np. Slack.com), narzędzia do przechowywania informacji o projekcie, plików graficznych, dokumentacji itd. (np. Basecamp.com), repozytorium z kodem (np. Bitbucket.org) czy wreszcie sam system do zarządzania projektami z tablicą Kanban (np. Jira). Odpowiednie narzędzia to jednak za mało. Muszą być też poprawnie uzupełnione, tak aby żadna osoba zaangażowana w projekt nie musiała męczyć PM’a o tak trywialne sprawy jak: „gdzie mamy pocięte png pod andka?” lub „daj mi dostęp do repo, uprawnienia write bo nie mogę zrobić commita”. Wszystko musi być uporządkowane – dokumentacja, elementy graficzne i inne, muszą znajdować się w odpowiednio opisanych folderach w konkretnym systemie. Repozytorium z kodem musi być stale aktualizowane, na bieżąco powinny być tworzone jego kopie zapasowe, a sama tablica w Jirze musi być aktualna oraz na bieżąco weryfikowana przez Project Managera. Narzędzie do komunikacji wewnętrznej ma służyć do usprawnienia pewnych procesów np. pomysłów na szybsze oprogramowanie danego algorytmu lub w celu zwiększenia postępów w projekcie – nie jest to bynajmniej skupisko internetowych memów.

2. Block’i

Kolejnym elementem wzorowej komunikacji jest eliminacja tzw. „wąskich gardeł” czyli sytuacji, w których nie możemy iść dalej z projektem gdyż coś lub ktoś nas blokuje. Typowym wąskim gardłem jest często sam klient, który opóźnia zespół projektowy np. z powodu niedostarczania konkretnych elementów graficznych do aplikacji (w przypadku gdy design jest w gestii klienta). Tutaj sam project manager musi wykazywać się nie tylko uprzejmością (bo przecież klient nam płaci), ale też stanowczością i zdecydowaniem. Bardzo częstym zjawiskiem są taski oznaczone w systemie do zarządzania projektami, etykietą „Blocked by API”, które są niczym innym jak konkretnymi endpointami w API i często to klient powinien je dostarczyć w określonym czasie. Przecież oprogramowanie trzeba też testować, nie tylko manualnie…

3. Testy i współpraca z działem QA

Odnośnie samych testów i współpracy z testerami można by pisać godzinami. To tutaj dochodzi często do największych opóźnień i najczęściej nie z winy programistów. Brak dobrej komunikacji swoich potrzeb przez testera skutkuje niezrozumieniem tych potrzeb przez programistę co może skutkować (w najlepszym przypadku) niepotrzebnym „dopytywaniem się” co autor miał na myśli lub (co gorsza) niewłaściwą implementacją rozwiązania. Jedynym sposobem na uniknięcie problemów na tym etapie jest skrupulatne i bardzo dokładne opisanie błędów w działaniu danej aplikacji oraz stworzenie odpowiednich ticket’ów w systemie, tak aby programista bez problemu i zadawania zbędnych pytań mógł przystąpić do naprawy bug’ów. Każdy błąd musi mieć swój szczegółowy opis zawierający markę, model telefonu, na którym dokonywano testów manualnych, system i jego wersję oraz inne znaczące elementy ułatwiające programiście diagnozę i naprawę błędu w jak najkrótszym czasie.

4. Świadomość klienta

Kolejnym ważnym elementem jest uświadomienie klienta jak ważny (jeśli mówimy o pracy projektowej na zlecenie klienta) jest on sam w całym procesie tworzenia oprogramowania. Projekty IT są często bardzo skomplikowane oraz ryzykowne – w grę wchodzą zazwyczaj duże budżety, a więc każdy powinien stanąć na wysokości zadania, klient także – mimo, że często jest inwestorem i wykłada pieniądze na stół. Tutaj wysiłek leży po stronie dobrego i stanowczego PM’a, który poprzez skuteczne naciski, uzyska niezbędne informacje od klienta w szybkim czasie, zapewniając tym samym ciągłość pracy swoim inżynierom. Ponadto, musimy zdawać sobie sprawę, że klient nie musi znać się na programowaniu lub zarządzaniu projektem – w tym przypadku to celem biznesu jest odpowiednie wytłumaczenie, że w takiej sytuacji pieczę nad całym projektem klient powinien oddać w ręce doświadczonego zespołu, który poprowadzi projekt (wraz z jego odpowiednim budżetowaniem).

5. Daily stand’upy, weekly demo calls, ustalanie harmonogramu sprint’ów

Zarządzając projektem w oparciu o metodykę Agile/SCRUM i chcąc wyeliminować tym samym sytuacje opóźniające nasz projekt musimy zwrócić szczególną uwagę na strukturę pracy, jej wewnętrzną organizację. I nie mam tu na myśli bynajmniej rozproszenia zespołu czyli pracy zdalnej – ta jest jak najbardziej ok jeśli inne elementy są odpowiednio ustrukturyzowane. Jednym z takich elementów są daily standupy czyli spotkania zespołu organizowane najczęściej rano, po „zalogowaniu” się wszystkich interesariuszy projektu. To moment, w którym podsumowujemy co zostało zrobione wczoraj lub przed weekendem, a jakie zadania czekają na nas dziś. Notatkę ze spotkania, PM powinien umieścić w odpowiednim systemie np. w Basecamp co pozwoli na śledzenie postępów prac przez klienta oraz nada samym spotkaniom pewnego porządku. Weekly demo calls to spotkania, organizowane zazwyczaj w formie wideorozmów z klientem, który na bieżąco, z tygodnia na tydzień, śledzi postęp prac zespołu. Ważnym elementem są także spotkania dot. ustalania harmonogramu sprintów – etapów rozwoju projektów, jego kolejnych kamieni milowych. Do przygotowania takiego harmonogramu potrzebna jest wiedza analityczna oraz doskonała znajomość założeń projektowych.

Powyższe 5 punktów to tylko zalążek tego co spotyka nas w projekcie i wpływa na komunikację, jednak bazując na swoim doświadczeniu przytoczyłem te (w mojej opinii) najważniejsze. Pewnym jest jednak, że wiele problemów projektowych, nie wyrabiania się przez firmy w określonym budżecie (np. niedoskonała komunikacja działu QA z programistami) lub deadline (np. konflikt z klientem, zmiana założeń projektu w trakcie trwania danego sprintu, brak uświadomienia klienta o potencjalnych zagrożeniach) to często powód słabej komunikacji.

Na koniec ostatnia myśl, która przyszła mi do głowy – komunikować się dobrze, nie znaczy często mówić/pisać. Jeśli nikt nie zadaje pytań to znaczy, że każdy wie co ma robić. I to jest chyba najefektywniejsza komunikacja.