PODOBAŁ CI SIĘ TEN ARTYKUŁ?
Sprawdź inne teksty
Dzisiejszy wpis zaczynam od pytania: Czy jest u was możliwość pracy zdalnej? Pytanie to bardzo często pada z ust kandydatów na rozmowach kwalifikacyjnych, którym zależy na okazyjnej możliwość pracy z domu (np. raz w tygodniu). Jednak pracą zdalną można nazwać nie tylko możliwość okazjonalnej pracy z domu. Jeśli pracujesz w firmie outsourcingowej, taką pracą może być wykonywanie usługi dla klienta położonego w innym miejscu niż Twoje. Jest to komfortowe rozwiązanie, zwłaszcza jeśli klient przyzwyczajony jest już do ludzi na kontrakcie, którzy mają elastyczniejszy czas pracy. Od dwóch lat mam przyjemność pracować w projekcie rozproszonym geograficznie, którego polski oddział znajduje się w Gdańsku, zaś główna siedziba znajduje się w Ameryce. Ja w tym wszystkim - pracuję z Lublina. Jak wygląda praca przez taką barierę komunikacyjną? Postaram się opisać swoje wrażenia i doświadczenia w tym artykule. Przyznam się też do kilku wpadek... :D
W moim przypadku zderzenie z wyzwaniami wymienionymi poniżej było dosyć gwałtowne. Po przejściu do projektu musiałem zasięgać wiedzy od ludzi, którzy znajdowali się w innej lokalizacji. Ja natomiast byłem jedynym członkiem zespołu w lubelskim oddziale swojej firmy. Dodatkowo sam projekt miał duży próg wejścia. Pełne zrozumienie procesów tam zachodzących zajęło mi około 8 miesięcy. Podczas zapoznawania się ze projektem przyglądałem się i uczyłem wszystkich procesów, jakie tam zachodzą. Dzisiaj czuje się gotowy do przygotowania listy wyzwań, na jakie wg. mnie należy zwrócić uwagę, aby lepiej przygotować się do pracy w zespołach rozproszonych geograficznie.
Jest to związane przede wszystkim z powierzeniem obowiązków, sprzętu a nie rzadko również tajemnic osobie znajdującej się poza organizację. W pracy zdalnej na dużych odległościach nie ma możliwości omówienia spraw z członkami zespołu w cztery oczy. Są setki bądź tysiące kilometrów od Ciebie. I bardzo często w innej strefie czasowej. Taka praca wymaga dobrej organizacji czasu oraz dużych umiejętności interpersonalnych. Z każdego zagadnienia trzeba wyciągnąć jak najwięcej informacji, ponieważ następna możliwość pojawi się dopiero na koniec następnego dnia waszej pracy. Może się to okazać kluczowe, jeśli np. w dniu jutrzejszym macie ważne wydanie wersji, a Ty potrzebujesz więcej wskazówek na temat testowanej funkcjonalności. Nie bój się pytać i nie martw się - z czasem zaczniesz zdobywać coraz więcej wiedzy dziedzinowej i pewne rzeczy staną się dla Ciebie oczywiste. Wtedy na pewno spotkasz się z zasłużonym uznaniem ze strony klienta :)
Mając doświadczenie jedynie z pracy w projektach takiej samej strefy czasowej, będzie to wymagać od Ciebie chwili wprawy. Na początek staraj się wykonać swoją pracę przed początkiem dnia pracy Twojego zespołu z innej strefy czasowej. Twoje zgłoszenia będą wtedy obsłużone kiedy Ciebie nie będzie już w pracy. Jeżeli natomiast nie uda Ci się do tego czasu zdobyć informacji na temat zagadnienia nad którym pracujesz, istnieje ryzyko przedłużenia się jego wykonania aż o dwa dni robocze! (pełen dzień amerykański -> Twój pełen dzień -> odpowiedź w dzień amerykański). A ramy czasowe są prawdopodobnie mocno zdefiniowane wewnątrz waszej iteracji. Istnieją oczywiście sytuacje na które nie mamy wpływu. Jedną z takich sytuacji mogą być wydłużające się wydania, które nakładają się na inne zaplanowane aktywności tego dnia, w wyniku czego te ostatnie mogą zostać anulowane. Nie ma wtedy możliwości zasięgnięcia rady od członków zespołu, ponieważ wszyscy są skupieni na dostarczeniu wydania.
Z osobistych rekordów, do tej pory maksymalny czas jaki spędziłem na wydaniu to 6 godzin na zaplanowane 30 minut. Tamtego dnia spotkanie zaczęło się o 13.00 naszego czasu, czyli o 6.00 rano czasu klienta i trwało do 19.00 naszego czasu/12.00 czasu klienta. Dla nich więc był to normalny dzień pracy, a dla mnie dosyć długi dzień roboczy - trwał 11 godzin!.
Jedna z cenniejszych porad w dzisiejszym zestawieniu, która wiąże się z organizacją czasu pracy. Właśnie za kilka minut wychodzisz z biura, kiedy członek zespołu ma do Ciebie ostatnie pytanie. Przede wszystkim pamiętaj, aby nie zostawić go z niczym. Dobrą praktyką jest wskazanie osób i miejsc, u których może poszukać odpowiedzi. Z drugiej strony jednak nie daj się wplątać w wir, który nie pozwoli Ci wyjść z pracy. Z pewnością dobrym rozwiązaniem korzystnym dla obydwu stron będzie zmiana i dostosowanie Twoich godzin pracy tak, aby strefy czasowe się na siebie nałożyły. Miałem o tym okazję przekonać się na sobie:
Zbliża się godzina 16:55. Na pięć minut przed wyjściem tester prosi mnie o utworzenie w aplikacji struktury przez API na nowym środowisku. Z racji tego, że na obecnych środowiskach testowych jest to działanie rutynowe nie waham się ani chwili i od ręki wykonuję potrzebne zapytanie. Kilka sekund później zdaje sobie sprawę, co się właśnie wydarzyło. Środowisko na którym wykonałem zapytanie było na chmurze, mogło się to więc wiązać z utworzeniem mnóstwa dodatkowych bytów na płatnych serwerach. Proces odwracania tej operacji trwał do 21.00 godziny naszego czasu. Kluczowe, (choć niekomfortowe) w takich sytuacjach jest szybkie przyznanie się do błędu osobom odpowiedzialnym za zarządzanie procesami w waszym projekcie, aby natychmiast można było podjąć działania naprawcze. Zatajenie błędu mogłoby skończyć się naprawdę dużymi kosztami dla Ciebie i firmy.
Opierając się na powyższym, wykorzystuj wszelkie możliwe metody kontaktu używając komunikatorów, e-maili, wideokonferencji, aby jak najwcześniej zdobyć wszelkie potrzebne informacje. Zawsze pamiętaj o tym, że masz również kamerę i mikrofon. W skrajnych przypadkach kiedy nie możesz połączyć się do aplikacje z wideokonferencją, spróbuj "wdzwonić się" z telefonu komórkowego. Jeśli w Twojej firmie wszyscy włączają kamery na spotkaniach, dobrą praktyką będzie również się pokazać. Jeśli obecnie nie udzielasz się w dyskusji, wycisz mikrofon. Mi osobiście zdarzyło się tego nie zrobić na czas, przez co podczas ważnego spotkania w eter powiedziałem "ale cebula!". Na planowaniu składającym się z kilku zespołów. Na szczęście zespół z Polski szybko mnie ostrzegł i wyłączyłem mikrofon. Myślałem, że spłonę ze wstydu! :D
Skup się nad nieustannym doskonaleniem języka, w którym pracujecie. Przygotuj odpowiednie techniczne słownictwo, aby zawsze być gotowym na opisanie napotkanych problemów. Przyda Ci się to np. w obliczu niespodziewanych wydarzeń. W moim przypadku sprawdziło się to podczas nagłej sytuacji, w której zostałem z godziny na godzinę poproszony o poprowadzenie demonstracji funkcjonalności, którą obecnie przygotowywaliśmy i testowaliśmy. Mając mało czasu, musiałem na szybko zorganizować odpowiednią konfigurację oraz przygotować się do rzeczowego przedstawienia funkcjonalności. Gdybym wtedy nie miał przećwiczonych zwrotów, mógłbym nie wybrnąć z sytuacji, która wydarzyła się podczas demonstracji:
Niemalże klasycznie, podczas oficjalnej prezentacji przed grupą interesariuszy (ponad 50 osób) aplikacja wyrzuciła mi błąd. Nie mogłem przerwać prezentacji, a więc musiałem zgrabnie wyjść z sytuacji, nie oczerniając przy tym całej pracy zespołu. Opowiedziałem o różnicach między środowiskami i po chwili wszystko działało sprawnie. Po czasie okazało się, że w tym momencie aplikacja podgrywała sobie najnowszą wersję zmian :)
Jest to powiązanie z pokonywaniem bariery językowej. Poznawaj i zapamiętuj zwroty, idiomy, aby przygotować się na ograniczenie wpadek do minimum. W ramach zderzenia z inną kulturą miej na uwadze, że pewne zwroty jakie przychodzą Ci do głowy mogą być inaczej zrozumiane/odczytane. Ostrożnie podchodź również do żartów. Zależnie od kultury pewne dowcipy, czy fajne teksty mogą po prostu nie być na miejscu. Lepiej trzymać się sprawdzonych, a nawet powtarzalnych i wyuczonych schematów z książki do angiielskiego.
Ostatnio omawialiśmy nawet ten temat z naszą nauczycielką od języka angielskiego. Zauważyła ona, że pracując z osobami z innej narodowości, jako Polacy często próbujemy podchwycić używane przez nich zwroty i dodać je do naszej mowy. Jest to dość ryzykowne, ponieważ takie zwroty mogą mieć zbyt wąsko ustalone znaczenie, a co za tym idzie zostać źle przez nas użyte.
Najprostszy przykład, z którym ja się spotkałem: Kiedy ktoś kichnie, mówimy "na zdrowie". Pamiętam, jak na początku przygody pracy z przedstawicielami z Ameryki odpowiadałem pozdrowienie "Cheers" (w jak najszczerszych intencjach) i...nagle zapadała martwa cisza. Wygląda na to, że nikt nie rozumiał dlaczego mówię o radowaniu się w brytyjskim znaczeniu. Dopiero po czasie zorientowałem się, że tam użwa się innych zwrotów jak "Bless you", czy ku memu absolutnemu zaskoczeniu: "Gesundheit!" (niem. "Zdrowie!").
Sprawdź, czy aplikacje których potrzebujesz działają, a niepotrzebne są wyłączone. Jest to krótka i najlepsza porada. Kiedyś podczas prowadzenia bardzo ważnej rozmowy zdalnej mój laptop postanowił odmówić posłuszeństwa i zgasł. Ciężko było się wytłumaczyć dlaczego nagle zerwałem się ze spotkania, ponieważ po drugiej stronie nic nie wskazywało na to, że padła moja maszyna. Aby uniknąć niedopowiedzeń, polecam dodatkowe zabezpieczenie się poprzez zainstalowanie komunikatora używanego w waszej firmie jak Slack, czy Microsoft Teams na telefonie. Dzięki temu zawsze będziecie w stanie szybko ostrzec członków wideokonferencji/spotkania co się wydarzyło i poinformować, że pracujecie nad naprawą sytuacji. Tak też było w moim przypadku i cała sytuacja została uratowana!
Tutaj nie ma za bardzo rady ponad działania prewencyjne. Praca na odległość prawie zawsze związana jest ze skonfigurowaniem łącza VPN, dzięki któremu dostaniesz się do domeny klienta. Zależnie od jego polityki , możesz również w różnym stopniu mieć odcięty dostęp do internetu. Tak utrzymywane połączenie wpływa to na jakość transferów, co wiąże się z ryzykiem, że połączenie może się zerwać się w najmniej dogodnym dla Ciebie momencie. Zastosuj poradę z zasobami komputera: przed ważnym spotkaniem zawsze upewnij się, że wszystkie aplikacje w tle jakich potrzebujesz działają, a wszystkie niepotrzebne są wyłączone. Te ostatnie przede wszystkim mogą niepotrzebnie zapychać łącze i pamięć, narażając Cię na niestabilność.
Zaplanuj swoją pracę nie tylko pod względem polskich świąt ustawowych, ale i świąt w kraju, dla którego pracujesz. Jeśli o tym zapomnisz, może się okazać, że odłożysz ważną sprawę na dzień w którym nie będzie nikogo w biurze po stronie klienta. Zakładając, że sprawa dotyczyłaby kluczowej funkcjonalności - kłopoty gotowe!. Na spotkaniach nie zapomnij poinformować zespołu z innej strefy czasowej, że zbliża się data święta ustawowego/zaplanowanego wolnego w Twoim kraju, aby każdy miał czas odpowiednio skorygować możliwości przerobowe zespołu. Ta zasada sprawdza się również ze zgłaszaniem L4, czy UŻ. Dodatkowo, jeśli podczas planowania na przyszłe iteracje widzisz, że ktoś przez przypadek zapomniał poruszyć ten wątek - nie bój się zwrócić na to uwagi. Zespół uniknie w ten sposób natłoku pracy, a Ty wykażesz się czujnym okiem testerskim!.
Wydaje mi się, że taki zbiór może wam pomóc w szybszej adaptacji w projekcie z zespołami rozproszonymi geograficznie. Jeśli przychodzi wam coś jeszcze do głowy, śmiało napiszcie w sekcji komentarzy! Jestem ciekaw, jakie są wasze historie i doświadczenia. Czy pracujecie dla zespołów znajdujących się w innych szerokościach geograficznych? Dajcie znać!
REMIGIUSZ BEDNARCZYK
Znajdź mnie na mediach społecznościowych