Home office - czyli jak wydajnie pracować z domu

Jednym z takich przypadków jest globalny problem związany z pandemią COVID-19. Przeniesienie działu, czy nawet całej firmy na zdalną pracę, implikuje konieczność wielu zmian. Jak sobie z tym radzić? Przygotowaliśmy dla Was 23 dobre praktyki programistów pracujących zdalnie!

1. Wdrożenie on-site

Pierwszy tydzień (lub - jeśli jest taka potrzeba - dłuższy czas) programista powinien pracować w biurze, najlepiej z zespołem, który będzie realizował swój pierwszy projekt. Zapewni to możliwość wzajemnego poznania się i lepszego wdrożenia w procesy firmy.

2. Wsparcie organizacyjne

Osoba pracująca zdalnie powinna mieć swojego opiekuna (np. PM), do którego będzie mogła się zwrócić z pytaniami czy problemami. Dobrze, żeby to była jedna osoba dedykowana dla danego programisty, co uprości zamieszanie, zwłaszcza w początkowym okresie współpracy.
Taka osoba  powinna też zadbać o prawidłowe wdrożenie nowego programisty, o przypisanie projektu, prawidłowo zdefiniowanych zadań itd.

3. Wsparcie techniczne

Podobnie jak w przypadku spraw organizacyjnych potrzebna jest osoba techniczna, czyli inny programista, który będzie w stanie pomóc w kwestiach stricte developerskich, instalacji środowiska itd. W wariancie idealnym powinien być to techlead projektu, w którym nowy programista będzie brał udział.

4. Komunikacja bieżąca

W przypadku pracy zdalnej kluczowa jest obustronna dostępność dla zdalnej komunikacji - hangouts, slack itp. (uwaga: należy podać JEDEN kanał, który wybrany jest jako oficjalny, nadmiar możliwości potrafi wygenerować chaos). Takiego kontaktu może potrzebować zarówno zdalny programista, jak i inne osoby z zespołu projektowego. Ważne jest, żeby ustalić w jakim maksymalnie czasie (np. 1 godzina) powinna się pojawić odpowiedź na komunikatorze, żeby ktoś nie czekał z pracą tylko dlatego, że druga strona nie odpowiada.

5. Komunikacja pilna

W szczególnych przypadkach (np. jeśli ktoś nie odpowiada na kanale ustalonym do komunikacji bieżącej), potrzebny jest kanał awaryjny do szybkiego kontaktu. Oczywiście najłatwiej jest skorzystać z telefonu. Obie strony muszą więc znać numer na wypadek takiej sytuacji. Jest to odpowiednikiem podejścia do czyjegoś biurka, jeśli musimy zadać komuś szybkie pytanie.

6. Code review

Zwłaszcza w początkowym okresie współpracy rekomendowane jest codzienne, dokładne code review - tak, żeby zdalny programista nauczył się zasad i sposobu pracy w naszej organizacji, zgodnych z naszymi standardami.

7. Task review

Podobnie jak w przypadku weryfikacji samego kodu, niezbędna jest cykliczna weryfikacja właściwego zrozumienia przez programistę otrzymanego przez niego zadania.
Jest to kluczowy element, ponieważ nierzadko zdarza się, że programista, który otrzymał nieprecyzyjnie albo niejednoznacznie opisane zadanie, zinterpretuje jego treść inaczej niż chciałby zleceniodawca. Ważne jest, żeby omówić treść zadania z programistą, a w trakcie realizacji również konsultować przebieg prac. W przeciwnym razie, na koniec dnia możemy otrzymać kawał dobrze zrobionej, nikomu niepotrzebnej roboty, która nie spełni wymagań biznesowych.

Jeszcze raz podkreślę - osoba pracująca zdalnie nie może być pozostawiona sama sobie z zadaniem. To rzadko kończy się dobrze. Niekoniecznie ze względu na złą wolę, bardziej ze względu na zwykłe nieporozumienia. Widziałem takie przypadki nawet, jeśli zdalny programista był seniorem z dobrą reputacją.

Niestety dość łatwo ten punkt zbagatelizować z uwagi na natłok bieżących tematów - każdy ma swoją pracę i przecież nie mamy czasu, żeby jeszcze kogoś “niańczyć”... A potem musimy znaleźć czas, żeby odkręcić fakap, który został przez to wspólnymi siłami wygenerowany.

8. Dokumentacja procesów

Procesy, które dotyczą programistów pracujących zdalnie, powinny być przejrzyście opisane tak, żeby w każdej chwili można było sięgnąć do wiki lub innego miejsca i sprawdzić co i w jaki sposób działa w firmie.

9. Dokumentacja projektu

Projekt, w którym bierze udział zdalny programista, również powinien być jak najlepiej udokumentowany. Programista powinien mieć wgląd nie tylko w wąski zakres swojego zadania, lecz w szerszy kontekst całego projektu. To powinno ułatwić mu podejmowanie właściwych decyzji i też proaktywne proponowanie rozwiązań, które wpisują się w całość tematu.
Oprócz opisu dobrze jest omówić projekt w szerszym gronie tak, żeby wszyscy mieli wspólną wizję celu.

10. Uporządkowanie procesów i dokumentacji

Od braku informacji czasami gorszy jest nadmiar informacji. Jeśli zasypiemy pracownika toną wszystkiego, co niekoniecznie dotyczy jego pracy, albo jest częściowo nieaktualne lub niezrozumiałe, może przysporzyć to też niepotrzebnych problemów. Należy zadbać o to, żeby przekaz był adekwatny (dotyczył tego, co faktycznie będzie pomocne) i klarowny (nie wymagający dodatkowych wyjaśnień słowno-muzycznych :) ). 

Obraz 1. 

Źródło: memy.pl

11. Szybka video-dokumentacja

Czasami stworzenie kompleksowej dokumentacji (procesu, projektu, czegokolwiek) bywa trudniejsze i bardziej czasochłonne niż zrobienie szybkiego szkolenia. W takim przypadku warto takie szkolenie nagrać, żeby z jednej strony uczestnicy mogli do niego w dowolnym momencie wrócić, z drugiej - można potem przekazać taki zapis kolejnym, nowym osobom. To taka dobra droga na skróty.

12. Daily i inne spotkania projektowe

Programista powinien być wdzwaniany na wszystkie spotkania (daily, planningi, review, retrospektywy) - najlepiej z “wizją” tak, by kontakt był jak najbardziej zbliżony do zwykłego spotkania, oczywiście w miarę możliwości. Zdalna osoba musi czuć, że jest częścią zespołu.

13. Spotkania live

Od czasu do czasu warto złamać zdalną rutynę i zaprosić programistę do zespołu albo pojechać do niego, popracować chwilę razem, posłuchać na żywo o problemach i spostrzeżeniach. Czasami też możliwe jest wprowadzenie systemowej opcji pracy on site - np. 1 dzień w biurze raz na dwa tygodnie.

14. Sprzęt do telekonferencji

Sprzęt powinien być sensownej jakości, bo nic tak nie niszczy zdalnej komunikacji, jak głos, który zanika co drugie słowo. ;)
To nie muszą być super drogie zabawki, świetnie sprawdza się np. Jabra PHS002W lub podobne modele.

15. Integracja

Dobrze jest od czasu do czasu zamiast przy łopacie, spotkać się też przy piwie… lub kilku. ;)

16. Zdalne biuro

Jeśli w zespole są dwie lub więcej osób w danej okolicy, warto rozważyć opcję otwarcia zdalnego biura. O ile oczywiście takie osoby są tym zainteresowane. Koszty biura w mniejszych miastach są drastycznie niższe od metropolii. A taki mikrozespół łatwiej się integruje i zarządza. Z czasem też nierzadko tworzy się efekt kuli śnieżnej - takie osoby zapraszają do współpracy znajomych i nagle okazuje się, że mamy całkiem fajny, zdalny zespół, który stał się mikro-filią firmy.

17. Benefity

Benefity, które mają programiści w biurze powinny również trafiać do osób pracujących zdalnie - czyli np. jak zamawiamy pizzę dla wszystkich w biurze, zamówmy ją też dla zdalnych programistów, żeby nie poczuli się pominięci.

18. Feedback

Osoba pracująca zdalnie, osadzona jest w  pewnym sensie “w próżni”, dlatego ważne jest, żeby otrzymywała informacje zwrotne na temat swojej pracy - zarówno miękkie (jakość komunikacji, chęci, podejście do pracy), jak i twarde (jakość kodu, zgodność realizacji z oczekiwaniami, liczba błędów).
Podobnie w drugą stronę - warto zawsze posłuchać takich osób, ponieważ pracując niejako “z zewnątrz”, często więcej widzą niż osoby siedzące na miejscu i dają cenne uwagi, z których można potem skorzystać i wyciągnąć wnioski. 

19. Powiadomienia o nieobecnościach

W biurze zawsze możemy podejść i sprawdzić czy ktoś jest dziś w pracy, czy nie. W przypadku osoby pracującej zdalnie  konieczne jest systemowe rozwiązanie tego tematu - tzn. takie, żeby każdy członek z zespołu mógł sprawdzić czy dana osoba dziś pracuje, czy może ma urlop lub wyjazd służbowy - np. w kalendarzu, Calamari, czy innym narzędziu HR z którego korzystamy w firmie.

20. Narzędzia

Narzędzi wspierających pracę zdalną jest oczywiście od groma, przykładowe, z których korzystamy:
- Jira + Tempo (zarządzanie zadaniami i rozliczanie ich; podstawa do rozliczeń z klientami)
- Confluence (baza wiedzy, procesów itp.)
- Slack
- Google Chat
- Google Docs
- Google Calendar
- Calamari (nieobecności i urlopy)
- VPN

21. Kryteria dla osoby pracującej w pełni zdalnie

Z naszych doświadczeń wynika, że osoba, która pracuje w pełni zdalnie powinna:

I. Być na poziomie minimum mocnego regulara.
W innym przypadku może być jej ciężko wdrożyć się w projekt, bez bieżącej pomocy kogoś na miejscu. 

II. Umieć pracować samodzielnie.

Zdarzają się przypadki, kiedy mimo, że ktoś jest naprawdę mocny technicznie (na poziomie seniora), to nie potrafi pracować w pełni samodzielnie, oczekując np. że pewne rzeczy (choćby konfiguracja środowiska itp.) zrobić ktoś za nich. Tego typu współpraca też niestety bywa uciążliwa/problematyczna.

22. Nie zawsze się uda…

Trzeba też jasno sobie powiedzieć, że nie każda osoba nadaje się do pracy zdalnej. Bywa, że pomimo prób, efekty są mizerne i widać, że to po prostu nie działa. Tematy nie są realizowane na czas, albo są słabej jakości itd. Jeśli mimo rozmów nie ma poprawy - czasami trzeba po prostu zakończyć taką współpracę i poszukać kogoś innego.

23. Co jeszcze…?

Zdarzają się sytuacje, że osoby pracujące zdalnie nie są w stanie oddzielić czasu pracy od czasu wolnego. Ma to różne konsekwencje - niektórzy podczas pracy oglądają tv czy bawią się z dzieckiem, inni pracują od rana do późnych godzin wieczornych. Do pracy zdalnej potrzeba dużego doświadczenia, świadomości, że jest to czas pracy, osobnego pomieszczenia, gwarantującego możliwość skupienia. Jeden z kandydatów radził sobie z tym problemem tak, że wstawał rano, brał prysznic, ubierał się, zakładał buty! i szedł do drugiego pokoju. Wg mnie warto mocniej analizować kompetencje i predyspozycje ludzi podczas rozmowy kwalifikacyjnej, dopytywać szczegółowo o doświadczenia z pracą zdalną. Warto proponować w takiej sytuacji krótszy okres wypowiedzenia lub okres próbny.

To już wszystkie nasze dobre praktyki, dotyczące skutecznej pracy zdalnej programistów. Ciekawych zgłębienia tematu, zachęcamy do dalszej lektury materiałów, których obecnie w sieci jest coraz więcej.