Niniejszym wpisem rozpoczynam nowy cykl postów w których chcę przybliżyć Ci jak naprawdę wygląda praca w sektorze IT. Przyjrzymy się jak wygląda rzeczywistość pracy w różnych rolach. Zacznę od bardzo popularnego stanowiska – programisty. Przyjmę też kilka założeń, które realnie wpływają na to jak taki dzień pracy może wyglądać.

Założenia:

• Programista: Backend developer na poziomie Junior lub Mid 
• Język: Java + frameworki towarzyszące
• Firma:  Software house, 50-100 osób
• Zespół: do 10 osób
• Projekt: 6-12 msc, etap implementacji (przed chaosem testów odbiorczych i wdrożenia)
• Model pracy: Praca hybrydowa, 2-3 dni w biurze, reszta zdalnie
• Etat: Pełen etat, godziny standardowe
• Inne: Zwinne metodyki wytwarzania oprogramowanie, klient z sektora publicznego

Dlaczego tyle założeń?

No i jak to wygląda?

09:00 – Dlaczego 09:00?  To i tak późno dla projektów, które są realizowane dla sektora publicznego. Czasem zespoły startują o 07:00 czy 08:00. To ważne by wiedzieć, że w zależności od klienta te 'elastyczne godziny pracy’ potrafią być nieco bardziej rygorystyczne a umowy z klientami dokładnie określają godziny pracy zespołów wytwórczych. Oczywiście może być tak, że bardzo samodzielne osoby mogą pracować w innych godzinach ale z perspektywy zespołu możecie mi wierzyć,  jest to niewygodne i często powoduje zastoje w pracach. 

Rozpoczęcie dnia pracy, najlepiej spotkaniem zespołu typu daily (piszę „typu daily”, gdyż nie chcę opisywać sposobu pracy w konkretnej metodyce a tylko zaznaczyć konkretne wydarzenia z danego dnia). Jeśli w biurze – to spotkanie w salce konferencyjnej lub największym pokoju programistów. Jeśli online to wszyscy widzimy się na zoomie/teamsach, gdzie każdy prześciga się w ustawieniu najbardziej abstrakcyjnego tła za sobą. Spotkania są różne – jeśli prowadzone zgodnie z pewną popularną metodyką projektową  – trwają 15 minut i każdy z członków zespołu wymienia swoje zadania na dany dzień. Jeśli służą omówieniu zadań, wyzwań (czyt. problemów) oraz priorytetów  – potrafią trwać nieco dłużej. Dobrze jest, jeśli w oprogramowaniu pomocniczym typu asana, gitlab czy trello są opisane zadania, przydzielone osoby, określone terminy i priorytety.

Co dalej?

Właściwie potem to już lista zadań nie zależy od godziny 🙂

Przeplatają się ze sobą godziny pisania kodu, commitowania zmian, naprawiania napisanego kodu. Raz, drugi, trzeci. W międzyczasie pojawiają się spotkania ad-hoc czy to na żywo czy online, żeby omówić pojawiające sie znienacka problemy, przepraszam, wyzwania. Między pisaniem kodu a kolejnymi kubkami kawy pojawiają się też kolejne, z setek każdego dnia, wiadomości na slacku oraz uwielbiane przez wszystkie maile. Pół biedy jeśli firmowe, gorzej jak od klienta. I nie należy zapominać o systemie zgłoszeń jira, redmine czy innym w którym pojawiają się nagle, palące zgłoszenia z błędami, które trzeba naprawić ASAP.

I nagle jest 17:00. I jako, że w założeniach mamy etap implementacji projektu to jeszcze wszyscy mają czas. Dla siebie, dla zadań. Można zamknąć komputer. Gdyby w założeniach był etap wdrożenia, testów odbiorczych.. to dzień mógłby się skończyć nieco później, a zacząć nieco wcześniej.

To jak Ci się rzeczywistość pracy programisty w firmie IT podoba?