Nastały takie czasy kiedy pewne specjalizacje mogą być wykonywane z dowolnego miejsca na ziemi, w biurze, parku czy na plaży. Nie jest też już niczym nowym, że firmy aktywnie korzystają z możliwości Internetu i szukają pracowników niestacjonarnych, którzy pracują tam gdzie sami chcą. Tak samo jest w branży IT gdzie popularnym sposobem na budowanie zespołu jest poszukiwanie pracowników zdalnych bez ograniczeń terytorialnych.

Nasza firma pracuje częściowo w takim modelu od 2008 roku, kiedy w krótkim czasie była konieczność uruchomienia 2 zespołów programistów a lokalna rekrutacja nie przynosiła oczekiwanych efektów. W tym czasie pozyskaliśmy specjalistów idealnie dopasowanych do potrzeb naszych projektów ale rozsianych w różnych częściach kraju.

W tym artykule podzielę się z Wami moim doświadczeniem z budowania zdalnych zespołów IT.

#1 Rekrutacja

Tak jak i praca, rekrutacja również często odbywa się zdalnie. Testy kompetencyjne – zdalnie, rozmowa kwalifikacyjna – zdalnie. Wszystko jest zdalnie. Wiadome jest, że w takiej formule bardzo trudno jest dokonać trafnego wyboru dlatego też warto zastosować tygodniowy okres próbny. To co należy sprawdzić to przede wszystkim umiejętność kandydata do pracy zdalnej (w brew pozorom jest inna), czyli:

• Samodyscyplina
• Czasy reakcji na zgłoszenia / e-maile
• Komunikację z całym zespołem
• Kontakt z Project Managerem

Developer pracujący zdalnie musi wykazywać się przede wszystkim wysoką samodyscypliną ponieważ nikt nie ma możliwości go w pełni kontrolować (co jest polem czasem do nadużyć). Wymaga się aby osoba pracująca zdalnie aktywnie komunikowała się z zespołem, szybko odpisywała na maile/wiadomości oraz sumiennie wprowadzała dane do systemu zarządzającego czyli na przykład „log worki”.

No i najważniejsze – pracować zdalnie trzeba umieć. Można być świetnym programistą natomiast brak kolegów z zespołu obok siebie i klimatu biurowego może spowodować bardzo niską jakość pracy. Kompetencje to jedno natomiast osobowość w tym wypadku decyduje prawie o wszystkim.

Kwestie warunków pracy w domu w tym artykule pomijam natomiast warto się upewnić czy programista ma swój wydzielony pokój do pracy i przez cały dzień pomiędzy jego nogami nie biegają dzieci.

#2 Zarządzanie

Zarządzanie pracownikami zdalnymi jest w zasadzie troszkę trudniejsze niż stacjonarnymi. Nie mamy możliwości przechodząc obok danego stanowiska zapytać: „jak leci?”, „wszystko w terminie?”, „jakieś problemy?”. Ponadto nie widzimy osób z którymi współpracujemy i tak na prawdę nie wiemy co dana osoba w danej chwili tak naprawdę robi. Kilka zasad, których warto się trzymać:

1. Ustalić godziny pracy. Dobrze jest gdy cały zespół pracuje dokładnie w tym samym czasie gdyż komunikacja przebiega znacznie sprawniej.
2. Komunikacja i dyscyplina. Zewnętrzni developerzy powinni być przez firmę „nauczeni”, że niczego wg. własnej wyobraźni się nie robi. Dużo się rozmawia, potwierdza się odczytane maile a wszelkie toki myślowe istotne dla zadania zapisywane w systemie zadaniowym. (dla przykładu, jeśli jakieś zadanie zostało odrzucone – musi zawierać komentarze uzasadniające). Ponadto jeśli developer musi gdzieś wyjść lub odejść od komputera na dłuższy czas musi poinformować o tym zespół.
3. 15 minutowe „Daily Scrum-Meeting”. Rano, w pierwszej godzinie pracy, np. o 9:00 organizować (regularnie) 15 minutowe rozmowy z całym zespołem dotyczące bieżących prac, planów na dany dzień, prognozowanych sukcesów i zagrożeń.  Każdy z członków zespołu musi zabrać głos.
4. Wszystkie zadania w systemie do zarządzania projektami. My korzystamy z JIRA Atlassian ale może być też inny. Nigdy nic nie może przechodzić „bokiem” przez e-maile czy telefon. Każda wykonywana praca musi mieć swoje odwzorowanie w ticket-cie i Project Manager w każdej chwili musi wiedzieć czym developer się zajmuje.
5. Każde wykonane zadanie powinno zawierać log-worki. Project Manager powinien mieć dostęp do informacji, które zadanie ile zajęło czasu danemu developerowi aby w przypadku zbyt długiego czasu realizacji mógł interweniować.
6. Precyzyjne zarządzanie czasem pracy. W firmie używamy plug-inu do JIRY – TEMPO. Dobre planowanie czasu pracy, oraz ocena dotyczącą już wykonanych zadań dostarczy nam dobrych informacji związanych z efektywnością pracy developerów.
7. Opracować proces pracy. Zanim developer po skończeniu jednego zadania zabierze się za drugi należy się upewnić, że ten zrobiony wykonany jest prawidłowo a nowy jest zrozumiały. Dla wykonanego zadania, w naszej firmie stosujemy przepisanie go na drugiego developera w trybie code-review a później do testowania przez dział Q&A. W przypadku nowego zadania, zanim developer rozpocznie prace rekomendujemy nawet 5 minutowy call z Project Managerem dla upewnienia się, że każdy rozumie tak samo zadanie, które jest do wykonania. Opis słowny ticket’u nie zawsze jest wystarczająco jasny aby jednoznacznie zrozumieć zadanie.
8. Kontrola jakości i niezawodności. Bardzo istotna kwestia, powinniśmy bardzo dokładnie kontrolować jakość produkowanego kodu przez zdalnych programistów aby nie wpaść w błędne koło polegające na zwiększaniu czasu poświęcanego na poprawki i błędy. Jeśli developer 60% czasu wykonuje zadania rozwojowe a przez 40% je poprawia – coś tu nie gra. Informacji o tym dostarczą nam raporty czasu pracy (patrz punkt 5)
9. Własne zaangażowanie programisty. Zdalny programista powinien informować członków zespołu o zadaniu, które w danej chwili wykonuje głównie po to, aby móc ewentualnie wykorzystać fragmenty kodu stworzone przez inną osobę i nie powielać tych samych funkcji, klas czy modeli.

Podsumowanie

Zdalni developerzy to z jednej strony wygoda w kwestii organizacji biura (obniża koszta) i niezależność terytorialna, natomiast z drugiej strony im większy zespół tym znacznie trudniej zarządzać nim zdalnie i koordynować pracę. Budowanie zespołu nawet częściowo zdalnego wymaga od Project Managera dużego doświadczenia w kierowaniu takim typem prac, bardzo dużego zaangażowania oraz podobnie jak sami programiści – dyscypliny.

…z naszego doświadczenia

W naszej historii przez firmę przewinęło się bardzo wielu zdalnych developerów i to bardzo wysokiej klasy, niestety pomimo ich wysokich kompetencji programistycznych nie odnajdywali się w środowisku pracy zdalnej a ich możliwości wykorzystane były co najwyżej w 40-50%. W takich sytuacjach bardzo ważne jest aby to zauważyć jak najszybciej i podjąć dalej idące kroki – niestety zazwyczaj kadrowe.