Jak pracować zdalnie i nadal być najlepszym

Pasek narzędziowy pracownika zdalnego

Rozpoczęcie nowego zdalnego lub praca z domowego występu, czy to projekt kontraktowy, czy praca na pełny etat, może być trochę onieśmielająca, jeśli jesteś przyzwyczajony do chodzenia do biura dzień po dniu.

Ale ten styl zatrudnienia zyskuje na popularności, a niektóre bardzo znane firmy udzielają mu poparcia.

Od lat z powodzeniem pracuję zdalnie przy użyciu tych narzędzi przy projektach o różnej skali i czasie trwania. W tym poście mam nadzieję wymienić niektóre z najlepszych praktyk, które wybrałem do pracy w różnych sytuacjach. Znajdujący się tutaj przewodnik dotyczący pracy zdalnej i pracy w domu obejmuje szczegółowe zalecenia dotyczące oprogramowania i sprzętu oraz wskazówki dotyczące dotrzymywania terminów zespołu.

Konfiguracja zdalna lub domowego biura

Nie mogę wystarczająco podkreślić, jak ważna jest odpowiednia konfiguracja biura. Dzięki temu będziesz bardziej produktywny i będziesz wyglądać bardziej profesjonalnie. Na przykład zestaw słuchawkowy ma kluczowe znaczenie dla unikania echa podczas połączeń online; drobiazgi takie jak ta przydają się podczas pracy jako pilot.

Oto kilka narzędzi do pracy zdalnej, które uważam za niezbędne w moim własnym biurze domowym:

• Zestaw słuchawkowy . Bardzo lubię w szczególności przewodowe zestawy słuchawkowe, ponieważ nie wyczerpują się one w krytycznych momentach. Będziesz go często nosić, więc upewnij się, że masz coś wygodnego. Mam dwa zestawy słuchawkowe iMicro: jeden do biurka, a drugi do torby na laptopa. Jako zestaw słuchawkowy do torby na laptopa ma dwie świetne zalety: ponieważ jest zasilany przez USB, nie muszę się martwić o utrzymanie baterii naładowanych, a jego wymiana jest bardzo tania, jeśli ulegnie uszkodzeniu w mojej torbie. Właściwie uważam, że ten konkretny zestaw słuchawkowy jest trochę niewygodny w przypadku długich połączeń konferencyjnych; jeśli robisz ich dużo, polecam Corsair Vengeance 2000: wygodny, bezprzewodowy zestaw słuchawkowy z baterią, który pozwala pracować przez cały dzień. (Przy okazji: żaden z tych linków nie jest odsyłaczami).
• Ciche miejsce do myślenia , z drzwiami, które się zamykają – zwłaszcza jeśli mieszkasz z innymi ludźmi, a zwłaszcza jeśli masz rodzinę.
• Stabilne połączenie internetowe lub dobre połączenie zapasowe. Na przykład mam DSL i mam konfigurację tetheringu w moim telefonie, jeśli DSL zgaśnie. Jeśli ciągle masz problemy ze Skype lub przerywasz połączenia, w oczach innych osób, które mogą próbować zarządzać kilkoma zdalnymi pracownikami, stajesz się zarówno mniej niezawodny, jak i mniej profesjonalny.
• Skype . Jest to dobre w przypadku połączeń konferencyjnych ad hoc, wiadomości błyskawicznych z klientami, a nawet tworzenia pokojów rozmów o niskiej ceremonii.
• SkypeOut , który umożliwia odbieranie i wykonywanie połączeń z telefonu do kontaktów Skype. To jest niesamowite, szczególnie w sytuacjach, gdy jesteś z dala od komputera i (błędnie obliczyłeś czas, klient ma awarię itp.).
• Czajnik elektryczny . Czasami chcę gorącej kawy, ale nie chcę zakłócać mojego przepływu, aby ją zdobyć.
• Galonowy dzbanek wody . Do czajnika lub do picia. Na długie sesje kodowania lub długie rozmowy konferencyjne.

Niektóre z nich wydają się oczywiste, ale zdziwiłbyś się liczbą pilotów, które nie trafiają tutaj we wszystkie znaki. Jako deweloperzy potrzebujemy spokojnego miejsca do niezakłóconego myślenia. A jako pracownicy zdalni potrzebujemy spokojnego miejsca do prowadzenia rozmów konferencyjnych, spotkań, sesji programowania w parach itp., w sposób nieprzerwany. Sama praca na kanapie prawdopodobnie nie jest dobrym rozwiązaniem do pracy zdalnej na dłuższą metę.

Narzędzia programowe

Istnieje wiele dobrych narzędzi programowych, które uzupełniają typowe środowisko programistyczne i pomagają przezwyciężyć wyzwania związane z pracą zdalną. Oto kilka, które naprawdę lubię:

• AwayFind , który jest dobry w przypadku pilnych wiadomości e-mail, w szczególności wiadomości w ostatniej chwili od uczestników spotkania, ponieważ przekazuje ich wiadomości SMS-em.
• Time Zone Converter , do pracy z klientami i współpracownikami na całym świecie. Lubię Time And Date's World Time Clock, Every Time Zone, World Time Buddy lub The Time Now dla bardziej przystępnej wersji dla osób niedowidzących.
• Pokoje czatu/IRC dla wszystkich członków zespołu. Może to być oficjalny (np. pokój przy ognisku) lub po prostu pokój rozmów Skype (w stylu Keep It Simple, Silly).
• Narzędzie do śledzenia błędów – zasługuje na osobną sekcję, więc zobacz poniżej.

Kilka lat temu byłem w sporym zespole Railsowym. Kilku członków zespołu pracowało zdalnie przynajmniej przez część czasu, a kultura zespołu polegała na tym, że dużo pracy wykonywano wieczorami. Zaproponowałem utworzenie pokoju rozmów przez oficjalnego lidera zespołu w tym czasie, wskazując na Campfire lub inną płatną usługę czatu. Minęło kilka tygodni bez żadnych działań i postanowiłem skonfigurować czat na Skype tylko z programistami, aby przetestować moją teorię, że pokój rozmów będzie atutem dla zespołu. Ten eksperyment okazał się bardzo udany – tak udany, że po prostu używaliśmy czatu Skype zamiast innego rozwiązania. Ten pokój rozmów Skype był nadal używany, kiedy prawie rok później opuściłem projekt. Czasami proste może być najlepszą opcją.

Później, w krytycznym terminie dla tego samego projektu, zorganizowaliśmy czat na Skype, który obejmował programistów, analityków biznesowych, kierowników projektów i klienta, aby ogólna grupa mogła szybko odpowiedzieć na pytania. Chociaż nie jest tak aktywny jak czat tylko dla programistów, nadal działał naprawdę dobrze. Czaty Skype mogą być moderowane i kontrolowane za pomocą niektórych poleceń czatu grupowego, ustawiając role na czacie i ustawiając uprawnienia dostępu, co pozwala naprawdę dostosować czat do swojego przypadku użycia. Nawet konfiguracja o takiej prostocie może poprawić zdalną produktywność.

Najlepsze praktyki pracy zdalnej: śledzenie błędów

Lubię wiedzieć trzy rzeczy z narzędzia do śledzenia błędów, którego używam:

• Nad czym teraz pracuję?
• Co mam na talerzu w następnej wersji tego oprogramowania?
• Jakie są rezultaty całego zespołu w tej wersji oprogramowania?

Każdy z nich ma swój cel.

Po pierwsze, „Nad czym teraz pracuję?”: Kiedy pracujesz w tradycyjnym biurze, masz w tle gadaninę – daje to ogólne pojęcie o tym, co robią wszyscy inni. Wyraźny znacznik w systemie śledzenia błędów mówiący: „Tak, teraz aktywnie nad tym pracuję”, może wprowadzić podobny wzorzec i odczucie do pracy zdalnej.

Po drugie, „Co jest na moim talerzu w następnym wydaniu?” oznacza „Za jakie błędy jestem odpowiedzialny” lub „Jakie błędy mam do czynienia”. Z pewnością w każdym zespole jest coś w kółko, ale dobrze jest też wiedzieć, kogo zapytać, jeśli chcesz złapać błąd lub potrzebujesz pomocy w sfinalizowaniu błędów przed wydaniem.

Możliwe jest również, że Twój zespół w ogóle nie działa w ten sposób: na przykład przepływ pracy może polegać na tym, że każdy programista ma przypisany tylko jeden błąd na początek i wybiera nieprzypisany stos, gdy jego jeden błąd zostanie wykonany. To również może być produktywne.

„Następne wydanie oprogramowania” nie musi być niczym dużym – byłem w zespołach, w których „następne wydanie” oznaczało „za 3 dni zamierzamy wydać nową wersję alfa dla klienta ”. Ale nadal dobrze jest, aby wszyscy wiedzieli, co wydarzy się w tym nowym wydaniu. Zwłaszcza jeśli odbierzesz nieprzypisane bilety, gdy Twój obecny bilet jest kompletny.

Na dole wpisu zamieściłem kilka zaleceń dotyczących konkretnych programów do śledzenia błędów.

Najlepsze praktyki pracy zdalnej: komunikacja w zespole

Dla niektórych komunikacja w zespole jest najbardziej przerażającą częścią pracy zdalnej lub w domu. Ale będzie to problemem tylko wtedy, gdy na to pozwolisz .

W biurze, kiedy przechodzisz obok wszystkich w drodze do swojego miejsca, jest trochę przekomarzania się, ludzie mówią „Cześć”. Twoi współpracownicy wiedzą, że jesteś w pracy, ponieważ widzą Cię tam, przy biurku, pracującego.

Pracownicy zdalni muszą być nieco bardziej jednoznaczni — nikt nie wie, że pracujesz, chyba że im powiesz . Ale jeśli ustalisz właściwe praktyki komunikacyjne, Twoi koledzy będą dostępni za naciśnięciem przycisku, a nie na spacer po biurze, w dół windy itp.

Te wskazówki dotyczą bardziej zdalnie zarządzanego pracownika w ramach większego zespołu, ale mogą być przydatne, jeśli jesteś jedynym programistą.

Wyczuwalna obecność: nie idź niewidzialny

Kilka z tych pomysłów znalazłem w 48. odcinku podcastu Wide Teams.

Na początku dnia wejdź na IRC (lub jakiekolwiek inne narzędzie używane przez Twój zespół) i powiedz „Cześć” , porozmawiaj o tym, jak mijają dni ludzi itp., itd. Nawet jeśli oznacza to wejście na IRC i wypytywanie o dzieci, weekendy, drużyny sportowe lub weekendowe hakowanie. Kiedy ludzie wiedzą, że obecnie ciężko pracujesz w domu, nie stajesz się niewidzialny. Zbuduj relację i daj ludziom znać, że tam jesteś .

Rozmawiaj z ludźmi na czacie i upewnij się, że pozostajesz w kontakcie z kolegami. Inaczej jest, gdy wpadasz na ludzi w kawiarni itp. Musisz wyraźnie skontaktować się i pozostać w kontakcie, aby kiedy zatwierdzisz kod lub będziesz potrzebować pomocy, ludzie będą gotowi.

Wiadomości „Dzień rozpoczęcia”, „Pora lunchu” i „Wróć”

Oprócz wyczuwania swojej obecności, powinieneś także informować swoich zdalnych kolegów z drużyny, kiedy nie pracujesz. Tak jak w tradycyjnym biurze, nie chcesz zniknąć na resztę dnia i zostawić współpracowników w zawieszeniu.

Jeśli pracujesz w zespole z kilkoma innymi programistami lub zarządzasz pracownikami zdalnymi, warto zameldować się na początku dnia pracy. Proste „Dzień dobry wszystkim”, aby poinformować ludzi, że jesteś przy biurku gotowy do rozpoczęcia pracy nad projektem, a nie w domu lub w łóżku.

Wysyłanie wiadomości „Wróć za 1 godzinę” na lunch lub przerwy w pracy w ciągu dnia też jest miłe. Praca zdalna jest świetna do wielu rzeczy, ale jednym z niepokojących scenariuszy jest to, że zadajesz koledze pytanie i nie otrzymujesz odpowiedzi. Czy nie odpowiadają, ponieważ są nieobecni przez 30 minut? A może dlatego, że są głęboko w strefie i nie słuchają rozmowy? Może na spotkaniu? Komunikaty „Wróć do…” mogą złagodzić te obawy i usprawnić przepływ pracy.

Kiedy skończysz na popołudnie, daj innym znać, kiedy wrócisz. Może jest to „Do zobaczenia rano” lub „Wróć później wieczorem, aby zrobić [x]”. Ale podobnie jak komunikaty „W ciągu 1 godziny”, wyznaczają pewne oczekiwania, do których Twój zespół może się dostosować.

Istnieje ciekawy startup o nazwie Sqwiggle, który może rozwiązać niektóre z tych problemów (choć sam jeszcze tego nie próbowałem). Oprócz robienia Ci zdjęcia co kilka sekund, umożliwia również członkom zespołu kliknięcie Twojego zdjęcia, aby rozpocząć czat wideo/audio, a także udostępnia komponent czatu tekstowego. Ideą obrazu jest sprawdzenie, na pierwszy rzut oka, czy jesteś przy komputerze, czy nie. (Nie ma nic gorszego niż próba rozmowy z kimś przez Internet i brak szybkiej odpowiedzi. Czy jest to coś innego? Głęboko w strefie? Nie widzisz powiadomienia o czacie? W tej chwili w łazience?). Słyszałem o Sqwiggle w odcinku 83 podcastu Wide Teams.

W projektach, w których można wprowadzić najlepsze praktyki

Zdalne koncerty freelancerów są zawsze inne. (To część atrakcyjności!) Czasami jesteś włączany do istniejącego zespołu programistów wyłącznie jako uzupełnienie personelu. Może ten zespół jest razem od jakiegoś czasu iw takim przypadku ma już ustalone praktyki komunikacyjne.

Z drugiej strony, czasami jesteś jedynym programistą w projekcie, pracującym z klientem nietechnicznym. Możesz skonfigurować własne najlepsze praktyki tworzenia oprogramowania i mieć pewną kontrolę nad sposobem uruchamiania operacji. Poniżej przedstawiam kilka najlepszych praktyk z mojej dekady doświadczenia w pracy zdalnej. W większości są one ukierunkowane na harmonogramy półtygodniowe (20 godzin/tydzień) lub całotygodniowe (40 godzin/tydzień).

Spotkania na stojąco

Jest coś do powiedzenia na temat organizowania spotkań na stojąco, aby rozmawiać o stanie projektu. Są one bardzo powszechne w tradycyjnych biurach, ale nie ma powodu, dla którego nie mogą one być produktywne dla zespołu zdalnego: to tylko kolejny sposób na wymuszenie komunikacji między dwiema stronami: klientem i deweloperem.

Tradycyjne spotkanie stand-up pyta, nad czym pracowałeś wczoraj, nad czym będziesz pracować dzisiaj i czy są jakieś przeszkody na Twojej drodze. Ten format może, ale nie musi działać, biorąc pod uwagę wielkość Twojego zespołu: jeśli jest to pojedynczy projekt deweloperski, te pytania nie mają sensu.

To, jak często powinieneś mieć spotkanie standup, zależy od wielkości i kultury zespołu. Oto moje zalecenia:

• 1-3 programistów: 2 spotkania w stylu stand-up w tygodniu
• 4+ programiści: codzienne spotkania standup

W przypadku 1-3 programistów te pytania są w większości oczywiste: wiesz, co robi każdy programista, ponieważ łatwo jest śledzić ich indywidualną pracę, gdy przebijają się przez bilety: wszyscy wiedzą, co robią wszyscy, ponieważ po prostu niewiele osób robi Praca.

W przypadku większych zespołów zdalnych jest więcej elementów w ruchu: chcesz mieć pewność, że nikt nie nadepnie nikomu na wirtualne palce, replikując pracę lub wprowadzając niezgodne zmiany.

Zaawansowane zespoły zdalne mogą mieć inne metody utrzymywania wszystkich interesariuszy na tej samej stronie bez planowania rzeczywistego spotkania podczas pracy w domu. Nadal lubię kontaktować się z kimś przez telefon/Skype/Hangouty i spotykać się w ten sposób.

W przypadku małych zespołów dwa spotkania stand-up w tygodniu sprawdzają się naprawdę dobrze: poprawki kursu są wprowadzane szybko, ale programiści wciąż mają coś istotnego do zaraportowania podczas każdego spotkania.

Zdalne dostarczanie w następnym wydaniu

W zależności od wielkości projektu lubię dostarczać produkty do klienta co tydzień w przypadku małych (1-2 programistów) i co dwa tygodnie w przypadku większych (3+ programistów) projektów. Ten rytm daje programistom wystarczająco dużo czasu na wykonanie sporych kawałków pracy, w tym interfejs (lub ulepszone wrażenia użytkownika), aby klient mógł je zobaczyć.

Dla programistów ważne jest, aby pamiętać, zwłaszcza w przypadku klientów nietechnicznych, że postęp, który można wizualizować za pomocą interfejsu użytkownika, jest często jedyną rzeczą, która ma znaczenie dla klienta. Klienci nietechniczni nie dbają o to, że wypchnąłeś w tym tygodniu 500 linii kodu lub że miałeś trudności z interakcją z jakąś usługą internetową; jedyną miarą, za pomocą której mogą ocenić postęp, jest to, co widzą na ekranie . Nie oznacza to, że wykonanie dobrej pracy na zapleczu jest nieistotne, ale raczej, że musisz sprawić, by cała ta dobra praca była namacalna w oczach klienta.

Dlatego lubię dostawy co tydzień lub co dwa tygodnie. Cokolwiek krótszego często stawia programistę w trudnej sytuacji: może utkną w pracy back-end przez dwa dni i nie mają czasu na dokończenie interfejsu, więc nie mają nic do pokazania klientowi.

W zależności od typu projektu oprogramowania, nie wszystkie z tych wersji klienckich zostaną udostępnione publicznie. Na przykład, jeśli pracujesz nad projektem Railsowym, możesz chcieć natychmiast wdrożyć zatwierdzone zmiany; z drugiej strony, z aplikacją mobilną, możesz nazwać wydanie „1.3a10”, ale bieżąca wersja jest tylko częścią większego zestawu funkcji nowej wersji oprogramowania 1.3, która zostanie wdrożona później.

W tym miejscu w grę wchodzą najlepsze praktyki zdalnego śledzenia błędów. Dzięki śledzeniu błędów klient wie:

1. Co znajduje się na talerzu zespołu za ten element dostawy?
2. Jeśli zostało zakończone
3. Jeśli praca została zaakceptowana przez klienta.

Klient wie, czego się spodziewać po tym wydaniu, a programiści wiedzą, jaka praca go czeka.

Jeśli Twój zdalny zespół jest wystarczająco dojrzały, aby korzystać z ciągłego wdrażania i/lub Kanban, to w porządku. Są to jednak obie bardzo zaawansowane techniki, które są bardziej odpowiednie dla organizacji o silnej kulturze programistycznej. Większość organizacji, w których tworzenie oprogramowania na zamówienie jest postrzegane jako konieczne, ale kosztowne, prawdopodobnie nie jest gotowe na żadną z tych technik. Dlaczego tak jest? Dwie rzeczy, które zauważyłem, to to, że klient nie nadąża za liczbą zmian, które programiści chcą, aby przejrzeli , lub priorytety zmieniają się zbyt szybko, aby programiści mogli zrobić cokolwiek .

Zalecenia

Jeśli zdarzy ci się trafić do zespołu, w którym będziesz ustalać najlepsze praktyki, poniżej wymieniłem kilka narzędzi do zarządzania pracą zdalną. Pamiętaj, że to tylko moje zalecenia: z pewnością ten przewodnik nie jest dla wszystkich; a jeśli nie lubisz tych narzędzi, prawdopodobnie istnieje narzędzie, które lepiej odpowiada Twoim potrzebom.

• Planscope.io , w trybie tygodniowym. Jest to narzędzie do śledzenia czasu + śledzenia błędów + narzędzia do szacowania projektów, które wysyła klientom codzienne e-maile podczas pracy nad ich projektem i pozwala im zobaczyć, jak się sprawy mają pod względem postępów i budżetu. Jest to idealne rozwiązanie dla projektów o wielkości 1-4 deweloperów/miesięcy.
• App Trajectory to narzędzie do śledzenia błędów dla małych zespołów, które koncentruje się na szacowaniu i dzieleniu projektu na części (iteracje) od jednego do dwóch tygodni. Trajektoria aplikacji może powiedzieć, ile pracy wykonujesz w iteracji i ile iteracji do zakończenia całej znanej pracy. Jest to idealne rozwiązanie dla projektów o wielkości od 2 do 12 deweloperów/miesięcy.
• Pivotal Tracker to narzędzie do śledzenia błędów dla klientów z naciskiem na metodologie Agile. Jest to świetne, jeśli wykonujesz formalne iteracje Agile lub masz rozmiar projektu mierzony w programistach/latach.
• FlowDock do czatu. Flowdock ma pewne zalety w porównaniu ze zwykłym czatem IRC lub Skype: oprócz integracji z popularnymi usługami, umożliwia także tagowanie rozmów w celu późniejszego szybkiego odniesienia. FlowDock przechowuje również listę działań dotyczących statusu (sprawdzania kodu itp.), które są oddzielone od ogólnych czatów. (Tj. w interfejsie internetowym automatyczne aktualizacje statusu znajdują się po lewej stronie, a czaty po prawej).
• Ponownie, Campfire świetnie nadaje się również do rozmów.

Wniosek

Rozpoczęcie pracy zdalnej lub pracy w domu może być sporym dostosowaniem, zarówno dla Ciebie, jak i dla klienta. Poszło bardzo dobrze i bardzo źle. Ale jeśli wszystko pójdzie dobrze, może to być doskonały sposób dla klientów lub pracodawców na rozwiązanie problemu „załamania talentów” i stworzenie szerszej gamy możliwości dla deweloperów, którzy mieszkają poza głównymi centrami technologicznymi lub hubami „startupowymi”. Dzięki zdalnej współpracy programistów z zastosowaniem odpowiednich najlepszych praktyk można uzyskać cały świat wydajności.