Lepiej pracuje się w 100% zdalnym zespole? Devdebata

Jak wygląda praca zdalnego programisty? To tytuł ostatniego artykułu o pracy zdalnej w naszym serwisie, który wzbudził spore zainteresowanie. SoftwareMill postanowił przepytać współpracowników jak radzą sobie z problemami i wyzwaniami pracy zdalnej, a my postanowiliśmy zapytać o to seniorów pracujących w różnych firmach. Czy ich zdaniem lepiej pracować w firmie 100% zdalnej, czy takiej, w której ten podział zbliżony jest do 50% pracowników w biurze i 50% pracujących w biurach domowych? Tego dowiecie się z poniższej devdebaty.

Zostań najlepszym opiekunem Uszatego! 🐶

Aplikuj

Odpowiedzi na nasze pytania udzielili:

Krzysztof Władyka. ClojureScript Developer. Programuje 100% zdalnie na kontraktach w Clojure / ClojureScript od 2015 roku. Wcześniej pracował w systemie mieszanym jako CTO w firmie, którą stworzył z kolegą. Ma też doświadczenie DevOps. To co robił pozwoliło mu zrozumieć jak budować systemy, a jak ich nie budować. Nie tylko z punktu widzenia programisty, ale przede wszystkim z punktu widzenia biznesu.

Piotr Rasała. Remote Frontend Engineer w enxoo – industry cloud. Programuje zawodowo ponad 6 lat, od zawsze w modelu b2b. Zainteresowany programowaniem od czasów gimnazjum. Na początku kariery związany z PHP + JS. Później przeszedł  transformację w typowego fronta. W ostatnich latach w portfolio ma zarówno projekty dla branży medycznej, jak i telco oraz produkcyjnej. Pracował jako specjalista AngularJS później Angular. 

Bogusław Łyczba. iOS Developer. Nowatorski programista doświadczony we współpracy w ramach różnych metod organizacyjnych, koncentrujący się na podejściu „remote-first”. Wiele wysiłku wkłada w rozwój umiejętności we Swifcie. Aktywnie śledzi najnowocześniejsze rozwiązania pojawiające się w społeczności. Bada perspektywy blockchain w połączeniu z uczeniem maszynowym. Pasjonat zdolności samoorganizacyjnych platform open source.

Jacek Wysocki. Software Solution Architect / Perfromance Engineer / Software Engineer w Kinguin. Lubi gdy aplikacje działają szybko i sprawnie. Fan optymalizacji kodu i procesów, lubiący uczyć się nowych rzeczy. Zainteresowany technologiami: Go, Kubernetes, Operators, GKE, Cloud oraz Serverless. Obecnie do rozwiązywania codziennych problemów używa Go i Javy. Współpracuje z Coders Lab. Tata kochanej trójki dzieciaczków.

Tomasz Guziałek. Backend Engineer w Trustpilot. Inżynierkę obronił na Politechnice Poznańskiej, na magisterkę wyjechał na Uniwersytet Kopenhaski. Po studiach żył i pracował w Kopenhadze, m.in. dla swojego obecnego pracodawcy – trustpilot.com. Postanowił wrócić do kraju i od tego czasu (ponad 2 lata) pracuje zdalnie. Na co dzień pracuje nad systemami wykrywania fałszywych recenzji na platformie i nad techniczną stroną 'compliance’.

Paweł Barszcz. Senior Full Stack Developer w zoovu. Specjalizuje się w czytelnych i możliwie odpornych na refaktoryzację testach automatycznych. Pracuje zdalnie od dwóch lat. Ostatnio zaangażowany w projekty oparte na TypeScript/React/Node, zaś dawniej jego codziennością były Java/Kotlin/Spring. Nie potrafi oddychać bez stałego dostępu do task managera (aktualnie Things 3). Prywatnie ojciec dwóch rezolutnych poszukiwaczy przygód.

Iwona Kubowicz. Frontend Engineer w AgriCircle AG. Programistka z kilkunastoletnim doświadczeniem. W Warszawie pracowała w jednej z największych na świecie agencji interaktywnych, w Krakowie — dla kilku polskich i zagranicznych firm. Obecnie pracuje jako niezależny specjalista. Przywiązuje dużą wagę do jakości tworzonego kodu i uwielbia wykorzystywać najnowsze technologie. Autorka bloga programistka.com.

1. Jak wygląda Twój przeciętny dzień pracy?

Odpowiada Krzysztof Władyka, ClojureScript Developer:

Nie mam przeciętnych dni, są różne okresy. Przez kilka miesięcy regularnie zaczynam dzień od ćwiczenia kalisteniki albo jogi. W inne miesiące jestem bardziej wyczerpany i mi się nie chce. Czasami bardzo pochłania mnie praca, a czasami mam więcej czasu dla siebie. W lato mogę pobiegać w lesie w ramach przerwy. W zimę to większa trudność.

Staram się miksować pracę z ruchem fizycznym i zdrowym jedzeniem w domu. Nie wyznaczam sobie godzin. Jak mam wzrost aktywności to pracuje, jak mam zjazd to robię drzemkę. Nie chodzi o wyrobienie godzin, a o efektywność i wykonanie pracy. Życie w swoim flow jest bardziej efektywne.

Odpowiada Piotr Rasała, Remote Frontend Engineer w enxoo: 

Wydaję mi się, że tak jak dla każdej innej osoby.

• Wstaję ok. 8.
• Odwiedzam łazienkę.
• Ubieram się.
• Idę do biura.

Jedyna różnica jest taka, że biuro mam w innym pokoju i nie muszę nigdzie jechać. Reszta wygląda podobnie jak u stacjonarnych pracowników sprawdzenie maili, jiry, spotkania (online), czasami wypad na lunch, czasem zamówienie czegoś do domowego biura. Po około ośmiu godzinach w zależności od produktywności zamykam dzień pracy i ewentualnie odpowiadam na wiadomości.

Odpowiada Bogusław Łyczba, iOS Developer:

Jestem nocnym markiem, która dba o pięć punktów zainteresowania. Jednym z nich jest dbanie o biznes. Swój dzień pracy zaczynam późno (10-12), od ceremonii parzenia kawy, sprawdzenia poczty e-mail oraz wszelkiego rodzaju sposobów na poprawianie nastroju. Wtedy jestem gotów na zorganizowanie dnia. Uwielbiam czytać, więc jeden lub dwa inspirujące artykuły są idealne dla mojego głodu wiedzy. Następnie rozpoczynam spotkania i współpracę. W moim przypadku produktywność opiera się na samotności, więc staram się uzyskać co najmniej trzy godziny nieprzerwanego skupionego czasu. Na koniec robię niezbędne porządki, przeglądy kodu itp.

Odpowiada Jacek Wysocki, Software Solution Architect w Kinguin:

Zaczynam wcześnie około 6. Planuję co będzie do zrobienia – ostatnio pracuję w Scrumie, ale metodologia nie ma znaczenia jeżeli praca jest zaplanowana to z reguły kończę to, co pozostało z poprzedniego dnia. O 8 zawożę dzieci do przedszkola i jadę do biura, które mam 50 m od mieszkania. Około 9 daily z zespołem, dwa razy w tygodniu planning + raz w tygodniu review + retro. Obok standardowych scrumowych spotkań, dość często mam włączonego Google Meet z zespołem. Jak coś ogarniamy razem to z reguły na żywo, aby w razie czego pomóc sobie nawzajem. Komunikację asynchroniczną załatwia Mail (coraz mniej) oraz Slack. 

Odpowiada Tomasz Guziałek, Backend Engineer w Trustpilot:

Cały mój zespół pracuje w biurze od 9 do 17 i staram się pracować w tych samych godzinach. Codziennie o 9:30 mamy standup, na który łączę się z teamem przez Google Meet. W tym czasie synchronizuję się z zespołem i planuję nadchodzący dzień. Resztę dnia zazwyczaj pracuję samodzielnie w domowym zaciszu, choć – z drugiej strony – w ciągłym kontakcie na Slacku.

Odpowiada Paweł Barszcz, Senior Full Stack Developer w zoovu:

Dawniej moje dni różniły się od siebie, teraz logistyka życia rodzinnego narzuciła schemat. 7:45 wyjście z domu, młodszy syn do żłobka. 8:30 w coworku i tam praca do 16:30. Następnie po starszego syna do przedszkola i w końcu do domu. Zaś sam dzień pracy? Nic szczególnego: daily, videocalle w razie potrzeby, implementacja tasków. W międzyczasie lunch niedaleko biura.

Odpowiada Iwona Kubowicz, Frontend Engineer w AgriCircle AG:

Najlepiej pracuje mi się rano, bo mam wtedy najwięcej energii i nawet skomplikowane problemy udaje się dużo szybciej rozwiązać niż później. Dlatego też wstaję nie później niż o 6 lub 6.30. Pracuję z domu, więc “w pracy” jestem już jakieś pół godziny do godziny później. Zanim reszta zespołu zacznie swój dzień, ja zwykle mam już zrobioną część pracy zaplanowaną na dany dzień. Później standup lub grooming albo planning i przerwa na drugie śniadanie. 

W kolejnych godzinach praca nad zadaniami i komunikacja z resztą zespołu – zależnie od dnia jest jej więcej lub mniej. W międzyczasie przerwa na spacer, by zrobić zakupy i obiad. Staram się pilnować, by zakończyć pracę po mniej więcej 8h. Dawniej zdarzało mi się przesiadywać dużo dłużej, ponieważ nie musiałam się spieszyć, gdyż korki mi niestraszne. 

2. Jak planujesz zadania i dbasz o swoją produktywność?

Odpowiada Krzysztof Władyka, ClojureScript Developer:

Próbowałem wielu technik. Ostatecznie doszedłem do wniosku, że samo zarządzanie zadaniami też pochłania dużo energii i wymaga podejmowania decyzji. Najgorsze jest zapisywanie tasków, którymi nie zajmiesz się teraz, a później. Zbierają się i przyciągają Twoją uwagę, a gdyby były wystarczająco ważne to zająłbyś się nimi teraz. Pamiętaj: jak coś robisz, to w tym czasie nie robisz nic innego. 

Nasz umysł upraszcza. Co będzie bardziej efektywne? Wysłanie 100 000 listów przygotowując je jeden po drugim czy najpierw zaadresowanie 100 000 kopert, później włożenie do nich listów, które musisz też napisać, później zakleić i nakleić znaczki? Zaczynasz i kończysz każdy list czy przechodzisz kolejne etapy dla wszystkich listów równolegle? Założę się, że nawet nie pomyślałeś o ilości pracy związanej z przekładaniem tych listów z miejsca na miejsce, przygotowaniu na to pomieszczenia, kartonów, transportem takiej ilości na pocztę itd. Widzisz analogię do wszystkich wspaniałych metod zarządzania Twoim czasem? Przez nie masz tylko mniej czasu i energii na efektywną pracę, ponieważ zajmujesz się układaniem zadań.

Oczywiście żadna skrajność nie jest dobra. Mam takie momenty, że potrzebuję zapisać na kartce cele miesięcznie lub tygodniowe, żeby poukładać wszystko w głowie, ale to bardziej dotyczy moich celów osobistych, niż pracy zdalnej. Natomiast w pracy wszystkie firmy stosują sprinty i wiadomo co jest ważne dla klienta na najbliższe dwa tygodnie.

Produktywność? Jak robisz coś co Cię interesuje, nie bolą Cię plecy i nie rozpraszają prywatne sprawy, to wszystko czego potrzebujesz. Nie, żeby zawsze mi się to udawało.

Odpowiada Piotr Rasała, Remote Frontend Engineer w enxoo: 

Planowanie zadań to głównie kwestia scruma. Wyznaczam sobie cel na dany sprint i staram się go dowieźć. Produktywność to natomiast osobny temat. Zdecydowanie miewam gorsze i lepsze dni. Czasami prokrastynacja jest ogromna i wtedy staram się wspierać kogoś, aby pozostać produktywnym w ramach zespołu. Innym rozwiązaniem jest spożycie dużej ilości kawy i włączenie szybkiej muzyki, aby zmotywować się do działania. Wiadomo, kusi nas wiele pokus lub potrzeb, aby podczas godzin roboczych zrobić coś poza pracą i czasem robię coś poza pracą. I jeśli nie koliduje to z celem całego zespołu, wtedy po prostu staram się te godziny jak najszybciej odpracować.

Odpowiada Bogusław Łyczba, iOS Developer:

Uznaję trzy obszary planowania: osiągnięcie misji i długoterminową strategię, priorytety i taktykę oraz działania operacyjne. Jestem bardzo kreatywną osobą, więc zachowuję pewien chaos w codziennej rutynie. Utrzymuję podekscytowanie na wysokim poziomie. Kiedy czuję się zmęczony lub przerażony nudną pracą, szybko przerywam, aby przerwać cykl nudy. Kilka razy dziennie idę na spacer, aby porozmawiać z moim nieświadomym umysłem i zachować poczucie wrażliwości, gdy sprawy stają się zbyt trudne. Używam swojej wyobraźni do tworzenia analogii i kotwic, które motywują mnie do działania. Zawsze szukam postępu, więc produktywność bez tego aspektu jest bezużyteczna z mojego punktu widzenia.

Odpowiada Jacek Wysocki, Software Solution Architect w Kinguin:

Zadania mamy zdefiniowane i raczej każdy z członków zespołu wie o co chodzi – oczywiście układam sobie “plan ataku” na takie zadanko. Co do produktywności to nie używam żadnych wyrafinowanych tooli, a raczej prostej listy TODO (Org-mode). Jeżeli zadanie jest dość skomplikowane i wymaga poukładania na cały tydzień (sprint) lub dłużej – tutaj też zadania z reguły są porozbijane na jak najbardziej atomowe. 

Gdy potrzebuję większego skupienia to zawsze programuję / projektuję z muzyką w słuchawkach. Staram się nie przeglądać Fejsa / Insta czy innych social media. Gdy mózg chce odpocząć od problemu raczej idę się przejść na świeże powietrze z psem, którego zawsze zabieram do biura.  

Odpowiada Tomasz Guziałek, Backend Engineer w Trustpilot:

W poniedziałkowe poranki z całym zespołem mamy grooming. Wtedy planujemy nad czym będziemy pracować w danym tygodniu. Wszystkie taski i ich aktualny status są w Trello. Nie mam specjalnych sposobów na utrzymywanie produktywności – zdaje się, że praca zdalna po prostu mi leży i nie odczuwam jakoś mocno jej negatywnych skutków.

Odpowiada Paweł Barszcz, Senior Full Stack Developer w zoovu:

Moje planowanie pracy nie różni się niczym od planowania jej w biurze. Są priorytetowe zadania do wykonania, funkcjonalności do “dowiezienia” i nimi się zajmuję. Natomiast w ramach dbania o produktywność pilnuję, aby mieć dłuższe bloki czasu pracy. Bardzo “poszatkowany” dzień mi nie służy. Lunch umieszczam możliwie w środku dnia, aby przed i po nim mieć szansę na odcięcie się od czatu, maila, Jiry i skupienie na zadaniu.

Odpowiada Iwona Kubowicz, Frontend Engineer w AgriCircle AG:

Poza systemem używanym w zespole zawsze mam też swoją kartkę z planem na dany dzień, na której później notuję jeszcze dodatkowe rzeczy, wynikające z danego dnia. Typowe zadania to: porozmawiać z kimś, sprawdzić status jakiejś rzeczy, wyjaśnić co jest do zrobienia w zadaniu itp. 

W kwestii produktywności – staram się pracować w interwałach stosując Pomodoro, aby zwiększyć czas bez rozproszeń. Dodatkowo pomagają mi słuchawki z aktywnym wygłuszeniem. Dzięki nim, żadne hałasy z zewnątrz nie są w stanie mi przeszkodzić i wybić z jakiegoś toku myślenia czy pracy nad problemem. Najlepiej pracuje mi się rano, więc na ten czas zostawiam najbardziej skomplikowane lub trudne rzeczy.

3. Praca zdalna powoduje, że trudniej utrzymać wysoki poziom teamworku. Jak radzisz sobie z tym problemem?

Odpowiada Krzysztof Władyka, ClojureScript Developer:

Wszystko zależy od firmy. Albo potrafi stworzyć zespół, albo dzieli pracowników na zdalnych i pracujących na miejscu czy też swoich i tych z software house. Albo potrafi dokumentować wiedzę, albo nie. Nic z tym nie zrobisz – nie da się istotnie zmienić stanu zastanego z pozycji programisty zdalnego. To jest temat na książkę. Możesz się dzielić przemyśleniami, ludzie będą potakiwać głowami, ale i tak nic się nie zmieni.

Komunikacja w zespole na miejscu i zdalnym jest inna i to co sprawdza się na miejscu nie sprawdzi się zdalnie. Ludzie mają nawet dobre intencje. Wtedy wymyślają zasady, które frustrują jeszcze bardziej, ponieważ wchodzi klęska 21. wieku, czyli: równość, tolerancja i te same zasady dla wszystkich. Pracujemy w innym flow – to się nie sprawdza.

W każdej nowej firmie zaczynam od rozmów z kamerą 1 na 1 z każdą osobą. Pomagają też spotkania zespołu na żywo. Oczywiście rozmowy mają być o Was, a nie o pracy! To podnosi transparentność pomiędzy członkami zespołu. Ludzie muszą się polubić i zaufać sobie.

Odpowiada Piotr Rasała, Remote Frontend Engineer w enxoo: 

Wydaje mi się, że kilka spotkań w roku, aby porozmawiać twarzą w twarz bardzo pomaga. Duży plus to też rozmowy z użyciem kamerki czy to chodzi o daily, czy jakieś konsultacje. Natomiast co można zrobić na co dzień to pair-programming, który poprawia zrozumieć umiejętności współ-programistów i ich sposobu rozwiązywania problemów.

Odpowiada Bogusław Łyczba, iOS Developer:

Prawda jest dokładnie odwrotna. Praca zdalna ma znaczący wpływ na to, co myśleliśmy o pracy zespołowej. Zdalne zespoły są zobowiązane do wskazania kluczowych czynników przepływu pracy. Nie ma miejsca na niedopowiedzenia. Komunikacja musi być wyraźnie ujawniona poprzez codzienne zadania. Dokumentacja musi być kompletna i zaktualizowana o aktualny status projektu. Praca zdalna to świetna okazja do poprawy przejrzystości. A przejrzystość nie polega na mówieniu wszystkiego, co myślimy. Chodzi o jasne zrozumienie tego, co robimy i dlaczego, prawda?

Odpowiada Jacek Wysocki, Software Solution Architect w Kinguin:

Nie zauważyłem tego problemu – raczej pracujemy bardziej wydajnie (mój zespół jest mieszany część osób jest zdalnie, część częściowo zdalnie ⅗, część jeszcze inaczej ⅕ zdalnie). Jak dla mnie przyjazd do biura oznacza z reguły zmniejszoną produktywność – zbyt dużo przerywników. Myślę, że niedojrzałym w tym temacie zespołom może być trudno pracować zdalnie. Należy na pewno wybrać zestaw narzędzi do komunikacji, które będą wspierać pracę zdalną oraz wypracować proces, w którym praca zdalna to coś normalnego. A to wszystko po to, by osoby dołączające nie czuły się jak piąte koło u wozu. W moim zespole jak chcemy popracować i coś ostro pchnąć do przodu to raczej jest parcie na remote niż siedzenie w biurze.

Odpowiada Tomasz Guziałek, Backend Engineer w Trustpilot:

Gdy dołączyłem do zespołu, pracowałem normalnie w biurze przez prawie rok. Pomysł pracy zdalnej zrodził się w trakcie, kiedy planowałem przeprowadzkę. Ten fakt sprawił, że swój zespół znałem dobrze „twarzą w twarz” i nie musiałem poznawać go i budować więzi na odległość. Biuro odwiedzam mniej więcej raz na kwartał, kiedy przyjeżdżam na cały tydzień pracy. Ciekawostką są wspólne wypady na piwo do baru. Kiedy pracuję zdalnie, biorą ze sobą laptopa i wirtualnie siedzę z nimi przy stoliku.

Odpowiada Paweł Barszcz, Senior Full Stack Developer w zoovu:

Najlepiej z pracą zespołową radziłem sobie w zespole całkowicie zdalnym – tam naturalnie nasza komunikacja była “ustawiona” pod remote. Gorzej natomiast idzie mi w firmie, w której większość programistów pracuje w jednym biurze. W takiej konfiguracji dbanie o dobrą komunikację, transparentność i wymianę wiedzy wymaga starania się, dopytywania. Na pewno polecam korzystanie z kamerek na spotkaniach – bez tego, jako pracownik zdalny czuję się jakbym rozmawiał z szeregiem czarnych prostokątów. A tak serio to po prostu trudniej o dobrą komunikację, gdy nie widać rozmówców.

Odpowiada Iwona Kubowicz, Frontend Engineer w AgriCircle AG:

W przypadku pracy zdalnej bardzo pomaga ustalenie dodatkowych regularnych (np. raz w tygodniu) spotkań online z zespołem, żeby sobie po prostu pogadać i lepiej się poznać. Obowiązkowo z włączoną kamerą. Oprócz tego kilka spotkań w roku, gdzie wszyscy mogą zobaczyć się w realu. Do niektórych zadań można przydzielić dwie osoby, tak by wspólnie pracowały nad problemem i zmieniać te pary od zadania do zadania. Taki pair programming pozwoli im się lepiej poznać, uczyć od siebie a także sprawi, że nie będą się czuli osamotnieni w swojej pracy. Ważne też, aby w sytuacji, gdy ktoś szuka pomocy z jakimś problemem albo chociażby wyjaśnienia czegoś, nie zostawiać go zbyt długo bez odpowiedzi, nawet gdy nie mamy czasu. Trzeba potraktować to jak zadanie równie ważne jak inne.

4. W jaki sposób komunikujesz zespołowi swoje potrzeby i problemy?

Odpowiada Krzysztof Władyka, ClojureScript Developer:

Zawsze mówię o wszystkim bezpośrednio prosto w twarz. Chyba że wiem, że to prowadzi donikąd. Tutaj akurat jest tak samo jak wszędzie w życiu. Z tą różnicą, że firmy często mają pomysł na dedykowane osoby do prowadzenia rozmów raz w miesiącu o naszej motywacji i o wszystkim o czym mamy ochotę mówić. Zadają podchwytliwe pytania, oczekują odpowiedzi i takie tam. Pomysł dobry, ale wykonanie jest różne. Najgorsze jest to, że to się zamienia w takie sesje psychologiczne, a wszystko powinno być nastawione na zmiany. Te z kolei się nie wydarzają.

Odpowiada Piotr Rasała, Remote Frontend Engineer w enxoo: 

Komunikacja czy to w formie czatu zbiorowego czy indywidualnego wystarcza mi. Ewentualnie poważniejsze tematy można poruszyć czy to na wideokonferencji lub twarzą w twarz, jeśli naprawdę wymaga tego sytuacja.

Odpowiada Bogusław Łyczba, iOS Developer:

Używam dwóch form wyrażania intencji i potrzeb w zależności od okoliczności. Poszukuję wyraźnych i szczegółowych wiadomości, gdy zostanie ustanowione zaufanie między nimi. Wtedy wszystko działa jak urok. Kiedy jednak pojawia się brak zaufania i niepewność, wybieram bardziej ogólne, dorozumiane podejście. Ukryłem osądy (i niezadowalające) pod moją wyjątkową, nieco dziwną życzliwością. Podejrzani ludzie zamykają się w obronie, gdy są narażeni na jawną prawdę, więc tak musi być. Korekta tego, co poszło nie tak, powinna rozpocząć się od samodzielnego przemyślenia siebie. To proces ciągły w obie strony. Na koniec sprintu warto otwarcie omówić najbardziej problematyczne okoliczności i przygotować punkty akcji. Jednak skuteczność tego spotkania zależy całkowicie od chęci wprowadzenia zmian.

Odpowiada Jacek Wysocki, Software Solution Architect w Kinguin:

Tak naprawdę jestem w stałym kontakcie – bardzo często mam włączonego Meeta, przez około 30%-40% czasu pracy więc po prostu komunikuję się werbalnie. Do tego mamy planning i refinement scrumowy, na których można dostrajać to co jest do zrobienia. 

Odpowiada Tomasz Guziałek, Backend Engineer w Trustpilot:

Slack w większości przypadków załatwia sprawę. Czasami warto połączyć się za pomocą wideokonferencji. W moim odczuciu fizyczna lokalizacja nie jest tutaj znaczącym utrudnieniem, jeśli tylko rozumiesz się ze swoim zespołem i nie masz oporów, żeby otwarcie z nimi rozmawiać.

Odpowiada Paweł Barszcz, Senior Full Stack Developer w zoovu:

Zazwyczaj wystarczy, że napiszę na kanale zespołu na czacie – wtedy ktoś podejmuje temat i, jeśli to przydatne, przechodzimy “na priv”, aby nie zaśmiecać czatu innym. Natomiast takie większe potrzeby są świetnie adresowane przez cykliczne spotkania typu 1-on-1 z managerem – tam jest miejsce na feedback w obie strony.

Odpowiada Iwona Kubowicz, Frontend Engineer w AgriCircle AG:

Zależy od problemu – jeśli jest to coś związane z konkretną osobą czy coś, co mogę rozwiązać po prostu rozmawiając z kimś, to kieruję się do wybranej osoby. Z kolei jeśli to jest coś, co może dotykać również innych albo już się z tym spotkali i mogą mi podsunąć rozwiązanie, to poruszam temat na spotkaniu typu standup czy retrospekcja. To dla mnie dobre miejsca na proponowanie jakiś nowych rozwiązań czy to związanych z organizacją kodu czy pracy.

5. Lepiej pracuje się w 100% zdalnym zespole, niż w takim, w którym 50% pracuje stacjonarnie?

Odpowiada Krzysztof Władyka, ClojureScript Developer:

Lepszy 100% zdalny, ponieważ praca jest lepiej zorganizowana. Jak część osób pracuje na miejscu to omówią coś na obiedzie i postawią Ciebie przed faktem dokonanym, albo w ogóle nie poinformują. Tutaj znowu wracamy do tego o czym pisałem wcześniej, czyli jak w firmie jest zorganizowana praca w zespołach i ilu jest programistów. 6 vs 40 robi różnicę. 

Generalnie fajniej omawia się rzeczy na żywo, a nie zdalnie. Nie męczy to uszu w słuchawkach, pleców i oczu. Po prostu jest przyjemniej porozmawiać o czymś przy okazji obiadu, niż zwołać kolejne spotkanie i gapić się w monitor jak jedna osoba coś mówi, bo dwie naraz nie mogą. Czasami spotkania trwają 6 godzin pod rząd. Łatwo zrozumieć skąd biorą się problemy w komunikacji.

Odpowiada Piotr Rasała, Remote Frontend Engineer w enxoo:

Niestety nie jestem w stanie udzielić jednoznacznej odpowiedzi. Pracuję w zespołach mieszanych, składających się z osób w biurze oraz w domu, ok. trzech lat. Zespoły składały się z osób z różnych oddziałów (zdarzyło się również, że i firm), co wymuszało pewien rodzaj komunikacji.

Wydaje mi się, że zespół w 100% zdalny z odpowiednimi narzędziami zawsze będzie lepszym rozwiązaniem. Lecz zakładam tutaj zespół składający się z minimum regularów. Osobom z mniejszym stażem raczej odradzałbym taką formę pracy.

Odpowiada Bogusław Łyczba, iOS Developer:

Odpowiedź jest oczywista! Podejście oparte na pierwszym zdaniu się opłaca. Rówieśnicy mogą siedzieć obok siebie i nadal pracować w 100% zdalnie. Współpracownicy mogą przebywać w całkowicie różnych strefach czasowych i nadal dostarczać ogromną wartość dla firmy. Żyjemy w erze informacji. Komunikacja jest trwała i szybka. Oznacza to, że współpraca jest niezależna od tradycyjnych ograniczeń przestrzennych i czasowych. Istnieje wiele samouczków i pomocy dla początkujących dostępnych online. Myślę, że dzisiaj najtrudniejszą częścią jest wybór spośród dostępnych źródeł wiedzy. Możemy korzystać z wielu narzędzi i inspirować się innymi zdalnymi zespołami zlokalizowanymi na całym świecie. Jedynym ograniczeniem są nasze przekonania i zdolność do adaptacji nowych technologii do naszych miejsc pracy.

Odpowiada Jacek Wysocki, Software Solution Architect w Kinguin:

Nie generalizowałbym tutaj – wszystko zależy od zespołu i od narzędzi. Jeżeli proces jest dobrze spięty – środowisko umożliwia dostanie się do firmy i jej zasobów z biura – to nie ma znaczenia czy jesteś w siedzibie firmy, na leżaku w ogrodzie, czy nad jeziorem. Jak masz internet to możesz pracować równie wydajnie z każdego miejsca. Tutaj raczej bardziej istotny jest zgrany zespół, w którym dobrze się pracuje. Do biura jadę, że z chłopakami zjeść obiad i pogadać o pierdołach – a nie żeby podbijać świat programowania.

Odpowiada Tomasz Guziałek, Backend Engineer w Trustpilot:

Ciężko mi definitywnie stwierdzić, bo zdalnie pracowałem tylko w obecnym zespole, a w nim wszyscy oprócz mnie pracują z biura i tylko czasami decydują się na home office. Mimo że jestem zadowolony z obecnej konfiguracji, podejrzewam, że przewaga osób pracujących zdalnie w naturalny sposób wymusiłaby podejście remote-first i jeszcze bardziej ułatwiła komunikację.

Odpowiada Paweł Barszcz, Senior Full Stack Developer w zoovu:

Stanowczo polecam pracę w zespole całkowicie zdalnym! Taka konfiguracja powoduje, że naturalnie tworzące się procesy i styl pracy uwzględniają potrzeby pracy zdalnej. W przypadku zespołu mieszanego miałem sytuację, że było mi po prostu smutno, gdy widziałem, że osoby pracujące w biurze mają znacznie lepiej rozwinięte relacje ze sobą, czułem wyraźnie tę “asymetrię”.

Odpowiada Iwona Kubowicz, Frontend Engineer w AgriCircle AG:

Z moich doświadczeń wynika, że lepiej się pracuje w 100% zdalnym zespole. Jednak z tych samych doświadczeń mogę powiedzieć również, że odpowiedni nacisk na dobrą komunikację w zespole 50% stacjonarnym mógłby diametralnie zmienić sytuację. Osoby pracujące stacjonarnie muszą pamiętać o tym, że poza biurem jest jakaś grupa osób, której w żadnym wypadku nie wolno pomijać przy dyskusjach czy podejmowaniu decyzji. Dlatego też wszelkie rozmowy na tematy związane z projektem i pracą powinny toczyć się na jakimś ogólnodostępnym kanale typu Slack lub podczas wideokonferencji. 

Zdjęcie główne artykułu pochodzi z unsplash.com.

Zespół redakcyjny

RocketSpace.pl

RocketSpace.pl to magazyn portalu pracy przyszłości – RocketJobs.pl. Misją RocketSpace.pl jest zwiększanie świadomości społecznej w kwestiach związanych z rynkiem pracy. Jesteśmy tam, gdzie każdy pracownik white collar. Śledzimy na bieżąco najnowsze trendy na rynku pracy.