Praca zdalna – tylko dla garstki wybrańców?

Rozmawiałem jakiś czas temu o pracy zdalnej z dwójką moich kolegów. Nasze opinie na ten temat plasują się na przeciwległych krańcach spektrum: ja jestem wielkim zwolennikiem pracy zdalnej, podczas gdy moi koledzy mocno wierzą w kolokowane zespoły.

Padło wiele typowych argumentów za i przeciwko pracy zdalnej. Ponieważ większość z nich została omówiona w doskonałej książce 37 Signals, “Remote”, wsparłem na niej mocno swoją argumentację. Jeden z moich kolegów stwierdził jednak, że doświadczenia 37 Signals nie są dobrym przykładem, ponieważ ich sytuacja jest wyjątkowa. Jako twórcy Ruby on Rails, są oni firmą “sławną”, mogą więc łatwo przyciągnąć developerów specjalnego rodzaju – bardziej zmotywowanych i zaangażowanych niż pracownicy typowej firmy, pracujący wyłącznie dla wynagrodzenia. Dowodem na to jest fakt, że większość dużych firm nie pozwala na pracę zdalną.

Pogląd ten skrywa 3 założenia:

• przy pracy zdalnej można polegać tylko na szczególnie zaangażowanych developerach
• tylko nieliczne firmy, takie jak 37 Signals, są w stanie zatrudnić takich developerów
• powinniśmy się wzorować na dużych korporacjach podczas wdrażania nowych metodyk

Czy te założenia są prawdziwe?

Czy siedzenie w biurze zwiększa motywację?

Pracownicy zdalni nie muszą być bardziej zaangażowani niż pracownicy biurowi. Tak na prawdę, wszyscy pracownicy umysłowi muszą być równie mocno zaangażowani, by wykonywać dobrą robotę, niezależnie z jakiego miejsca pracują – ze swojego domu czy z biura.

Myślenie, że w biurze jest trudniej odbębnić marnej jakości robotę czy się obijać, jest typowym złudzeniem kontroli. Dla niektórych może to być brutalna prawda, jednak spójrzmy jej w oczy: nie masz pojęcia co Twoi siedzący w biurze pracownicy robią, dokładnie w takim samym stopniu jak w przypadku pracujących z domu. Jedynym sposobem jest ocena wyników ich pracy a nie ilości godzin spędzonych za biurkiem.

To wręcz działa na korzyść pracowników zdalnych. Ponieważ są oni świadomi, że jedynym sposobem ewaluacji ich pracy jest ocena wyników, będą się skupiać na osiąganiu świetnych wyników, podczas gdy wielu pracowników biurowych skupia się wyłącznie na tym, by wyglądać na zapracowanych (a i tak często tylko wtedy, gdy ktoś patrzy).

Do tego dochodzi inny, znacznie ważniejszy problem niż kontrola – zaufanie. Zaufanie jest samospełniającą się przepowiednią. Jeśli będziesz traktować ludzi jak oszustów, zaczną oszukiwać. Jeśli pokażesz ludziom, że im ufasz (pozwalając im pracować kiedy i gdzie chcą), spełnią pokładane w nich zaufanie z nawiązką.

(By dowiedzieć się, jakie są 4 typy developerów i jak ich prowadzić, przeczytaj ten post)

Czy też możesz być taką firmą jak 37 Signals?

Zwróć uwagą na istotny fakt: produktem 37 Signals NIE jest Ruby on Rails! Ich produktem jest narzędzie do zarządzania projektami. Dość nudna rzecz. (Sorry chłopaki z 37 Signals! Bez urazy!).

Ruby on Rails jest produktem ubocznym. Podobnie jak ich sławne ksiązki i blog Signal v. Noise. Co więcej, nie byli zbyt wielką firmą, gdy stworzyli wszystkie te produkty uboczne (jestem zbyt leniwy, żeby poszukać dokładnych liczb, ale obstawiałbym, że nie większą niż 20 osób).

Dlaczego więc Ty nie możesz? Dlaczego Twoja firma, zatrudniająca ponad 100 developerów, nie może też stworzyć Ruby on Rails?

To kwestia nastawienia, kultury firmy a nie zasobów. Większości firm nie brakuje możliwości, by zbudować nowe Ruby on Rails, ale chęci.

Oczywiście stworzenie hitu na światową skalę, takiego jak Ruby on Rails, jest trudne. 37 Signals miało po drodze sporo szczęścia. Nie musisz jednak zbudować aż takiego hitu by przyciągnąć zmotywowanych developerów. Po prostu pozwól im stworzyć jakieś wewnętrzne frameworki. Albo zostać regularnymi kontrybutorami Ruby on Rails czy jakichś innych projektach Open Source. Dla wielu osób nawet możliwość by po prostu popracować z jakimś popularnym, nowoczesnym frameworkiem, zamiast z przestarzałym kodem “legacy”, może być wystarczająca. I nie musisz nawet przyciągać developerów – Twoi obecni developerzy staną się wystarczająco zmotywowani, jeśli stworzysz im dostatecznie angażujące otoczenie.

(Więcej na temat tego, jak motywować developerów, możesz przeczytać klikając tutaj)

Czy duże korporacje rzeczywiście są wzorem?

Adopcja pracy zdalnej przez naszą branżę jest uderzająco podobna do adopcji metodyk Agile.

Z początku, idea żeby wydawać na produkcję co 2 tygodnie, pisać testy najpierw, integrować kod w trybie ciągłym, komunikować się z biznesem bez formalnej dokumentacji wymagań czy programować w parach wydawała się taka obca, tak trudna, że wierzyliśmy, iż tylko najlepsze, wyjątkowe zespoły są w stanie tak pracować. Potem okazało się, że zespół nie musi być nadzwyczajny by to robić – jednak wciąż myśleliśmy, że jest to możliwe wyłącznie dla bardzo małych zespołów. Następnie duże korporacje próbowały wdrożyć Agile z wątpliwym powodzeniem. Potem nastąpiła krótkotrwała faza oporu – korporacje twierdziły, że Agile jest przereklamowane, pojawił się nawet przez chwilę dość silny ruch anty-Agile. W końcu, Agile zostało zaakceptowane jako standardowy sposób pracy, niezależnie od rozmiaru projektu i poziomu doświadczenia developerów.

(By dowiedzieć się, jak skalujemy Agile w eSKY, zobacz naszą prezentację oraz artykuł porównujący nasze podejście z opracowaną przez Scrum.org metodyką Nexus)

Praca zdalna jest w tej chwili na znacznie wcześniejszym stadium niż Agile. Duże korporacje są nadal w trybie “to jest tylko dla małych zespołów” albo w trybie oporu. Nie popełnij jednak pomyłki, wierząc że ich opinia na ten temat jest ostateczna. Duże firmy zazwyczaj są bardzo ospałe jeśli chodzi o wprowadzanie nowinek – i w tym właśnie obszarze możesz szukać swojej konkurencyjnej przewagi. Nie wpadnij w pułapkę, odrzucając użyteczną praktykę tylko dlatego, że bezmyślnie naśladujesz “dużych graczy”.

Co ty o tym sądzisz?

Moim zdaniem, praca zdalna nie jest opcją zarezerwowaną wyłącznie dla małych, “wyjątkowych” firm. Nie jest ona w ogóle opcją – jest ona nieunikniona. Bardzo mnie ciekawi Twoja opinia na ten temat. Podziel się proszę swoim zdaniem i doświadczeniami w komentarzach poniżej!