Jeśli usłyszysz kiedyś pytanie na rozmowie rekrutacyjnej „jak wyobrażasz sobie typowy dzień pracy w naszym Software house” – to będzie podchwytliwe pytanie.

Kiedy zapytamy pracowników Software House o to, jak wygląda ich typowy dzień pracy, najczęściej usłyszymy, że na to pytanie nie ma jednoznacznej odpowiedzi. Wszystko co dotyczy rytmu pracy zależy od zarówno roli jaką ma dana osoba (PM, Programista, Projektant, Tester, HR, Sales, Administracja – jest tego jeszcze więcej…) ale także od momentu cyklu, w którym znajduje się dana osoba/zespół. A także… od charakteru projektów, nad którymi pracujemy, oraz od wybranej metodyki.

Typowy sprint?

Jednak, jeśli spojrzymy na pracę w Software House z szerszej perspektywy, możemy mówić raczej o typowym lub przeciętnym tygodniu / sprincie pracy. Rytm pracy jest bardzo dynamiczny, a tydzień lub sprint jest bardziej użyteczną miarą niż 8 godzinny dzień.

W Software House zazwyczaj pracuje się w iteracjach, czy to w sprintach, czy też w modelu kamieni milowych. Pracownicy skupiają się na konkretnym wycinku pracy, żeby zrealizować małe, ale kompletnie skończone projekty.

Praca nad dużym projektem, takim jak tworzenie nowego systemu dla dużej organizacji lub rozbudowa już istniejącego, może trwać od kilku miesięcy do nawet kilku lat. W takich przypadkach zespoły pracują nad różnymi modułami systemu, a cały projekt jest dzielony na mniejsze iteracje, które są stopniowo testowane i wdrażane. Tu już potrzebna jest bardziej zaawansowana metodyka, takie jak Scrum czy Agile, która pozwala na skuteczną organizację pracy w większych zespołach.

Jednakże, to określenie dotyczy bardziej tej części wytwórczej, czyli projektowej, która zajmuje się dostarczaniem projektów. Prezesi, sprzedawcy czy osoby z obszaru marketingu mają bardziej podobne dni pracy, gdzie nie dzielą swojej pracy w cyklach tygodniowych, a raczej operują datami i celami, które muszą zostać osiągnięte w miesiącu.

Sprint dla Project Managera/Product Ownera/Analityka często najbardziej pracowity jest w jego środku. Z mojego doświadczenia wynika, że w środku sprintu najwięcej czasu i energii te osoby muszą poświęcić na przygotowanie backlogu pod kolejny sprint. Żeby na następnym planowaniu zlecić zespołowi dobrze przygotowane i przeanalizowane zadania.

Z kolei programiści mają często największe tempo pod koniec sprintu… żeby dogonić cel jakim jest realizacja zleconego zakresu. Niestety w praktyce rzadko bywa tak żeby cały sprint szedł równomiernie i z reguły na koniec, kiedy czujemy że zostały już ostatnie dni a górka rzeczy do zrobienia nadal jest duża praca nabiera tempa. Zaznaczam, że nie zawsze – ale często 🙂

Projektanci UI z kolei miewają intensywne początki sprintów, bo muszą zaprojektować interfejs, który następnie w połowie sprintu musi przejść przez fazę poprawek i akceptacji, tak żeby dojechał w finalnej formie na koniec sprintu i tym samym był gotowy jako załącznik dla zadań dla deweloperów na początku kolejnego. To oczywiście spore uproszczenie, ale w wielu cyklach ten schemat się u mnie powtarzał.

A to tylko wierzchołek góry lodowej patrząc na ilość i zróżnicowanie osób w SH – nie wspominamy tu w ogóle o zupełnie osobnych cyklach sprzedaży, HR, administracji etc.

Spotkania, spotkania, spotkania…

Można by pokusić się o stwierdzenie, że typowy dzień pracy jest po prostu dla programistów pełen pracy, a dla wszystkich innych pełen spotkań. To niestety zbyt duże uproszczenie.

Raz, że bywają nawet całe tygodnie poświęcone na warsztaty (czyli dość wyjątkowy rodzaj spotkań), gdzie zdalnie lub na miejscu, po kilka godzin dziennie możemy siedzieć na jednym spotkaniu i wspólnie przechodzić przez proces definiowania/odkrywania wymagań, rysowanie procesów etc. A żeby takie kilkudniowe warsztaty zaplanować też trzeba wielu dni wcześniej na przygotowania.

Dwa, że są dziesiątki innych rodzai spotkań, które z kolei mają różne cele. Może to być spotkanie z klientem biznesowym, w którym omawiamy wymagania biznesowe, cele projektu czy terminy. Możemy też mieć spotkania z klientem technicznym, na których omawiamy techniczne aspekty projektu, takie jak architektura, infrastruktura czy integracje.

Oprócz tego istotne są także spotkania zespołu projektowego, takie jak sprint review, sprint planning czy daily standup, które już wcześniej wspomniałem. Ważne jest, aby te spotkania były prowadzone sprawnie i efektywnie, a każdy uczestnik miał szansę wnieść swoje spostrzeżenia i pomysły.

Nie można też zapominać o spotkaniach z zewnętrznymi dostawcami lub kontrahentami, które mogą mieć wpływ na przebieg projektu. Mogą to być spotkania z firmą dostarczającą jakąś usługę czy produkującą sprzęt, którego używamy w projekcie, albo z podwykonawcami, którzy pracują z nami nad jakimś modułem czy elementem projektu.

Więcej o różnych obowiązkach, zajęciach i strukturze pracy w Software House znajdziesz w naszym odcinku (linki na górze tego artykułu).