Nasza strona używa cookies. Dowiedz się więcej o celu ich używania i zmianie ustawień w przeglądarce. Korzystając ze strony, wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki. Rozumiem

Organizacja tygodnia pracy zdalnej

Rafał Kotusiewicz Co-Owner / nexonIT
Sprawdź, jak skutecznie zorganizować tydzień pracy zdalnej i których narzędzi używać.
Organizacja tygodnia pracy zdalnej

W pierwszej części skupiłem się na cyklu dziennym, dziś zajmę się cyklem tygodniowym i podsumujemy teksty kilkoma uwagami.

Cykl tygodniowy, który opiszę, dotyczy głównie zespołów utrzymaniowych. W zespołach scrumowych wytwarzających produkt, długość cyklu jest narzucona przez długość iteracji (częściej jest to dwa tygodnie niż tydzień) i schemat został opisany w samym frameworku. Skupię się zatem na zespołach utrzymaniowych z pewnym założeniem, że pracują w stylu kanban.


Spotkanie

Raz w tygodniu konieczne jest strategiczne „spotkanie" całego zespołu. Proponuję, aby był to czwartek lub piątek. Czwartek wydaje się lepszy, ponieważ pozwala podjąć kroki wynikające z ustaleń spotkania jeszcze nazajutrz (w piątek) na świeżo. Jeśli wybierzecie piątek, to jest to naturalne zakończenie tygodnia i pozwala na naturalne domknięcie jakiegoś cyklu, wtedy jednak trzeba pamiętać o solidnym dokumentowaniu spotkania.

Oczywiście do przeprowadzenia spotkania wykorzystujemy kanał głosowy (skype, hangouts) idealnie, gdyby włączone były kamery - miło czasami spotkać się w szerszym gronie, choćby za pośrednictwem kamery. Świetna pora na „naradę” jest tuż przed obiadem. Długość to zwykle około 45 minut (pamiętamy, że dłużej trudno utrzymać skupienie) a koniec powinien przypadać właśnie na porę lunchu/obiadu. Dzięki temu nikt nie będzie miał ochoty przedłużać zebrania w nieskończoność :) Na takim spotkaniu omawia się większe problemy, napotkane w trakcie ostatniego tygodnia, decyduje o  wdrożeniach (jeśli z jakiegoś powodu zespół nie stosuje continuous delivery) i ewentualnie o zainicjowaniu problemów i zmian (po szczegóły odsyłam do ITIL). Staramy się oczywiście znaleźć w tym czasie chwilę na „śmieszki", żarty i skomentowanie wydarzeń spoza kontekstu wspólnej pracy.

Lider nigdy, pod żadnym pozorem, nie może postawić w trudnej sytuacji żadnego z członków zespołu na forum publicznym. Podczas spotkań strategicznych (czy codziennych stand-upów) można (i warto!) udzielać pochwał, trzeba docenić proaktywną postawę i ponadstandardowe zaangażowanie. W żadnym wypadku nie należy zwracać uwagi na nienależyte zaangażowanie któregoś z członków zespołu. Ewentualnie można zwrócić uwagę na słabe zaangażowanie całego zespołu, ale to nie odniesie skutku, bo zwykle przyczyna jest w miejscu niedostępnym dla tak prostych rozwiązań. Publicznie  chwalimy, uwagę zwracamy w rozmowach 1 na 1.


Praca kontra czas wolny

Małe ramy omówiliśmy, spójrzmy teraz na szersze nieco. Poszczególni członkowie mają swoje życie poza pracą. Chętnie też wybierają pracę zdalną, wiedząc, że dzięki temu mogą odebrać dzieci z przedszkola, zrobić sobie przerwą na obiad poza domem itd., niektórzy  chcą pracować od 7 do 15, inni od 9 do 17. Jeszcze inni trochę rankiem a trochę wieczorem. Ma to sens dla każdego z nich i po ustaleniu godzin pracy poszczególnych członków lider powinien je respektować, pozwalając sobie na przerywanie „czasu poza pracą" tylko w wyjątkowych sytuacjach.

Świetnym pomysłem jest zapisanie tych godzin dla każdej z osób w jakimś zespołowym wiki. Oczywiście nie jest to rycie w kamieniu, może więc podlegać zmianom, należy te zmiany wyraźnie komunikować liderowi i pozostałym członkom zespołu. Oczywiście programiści lubią pisać rozszerzenia do slacka i mogą samodzielnie zaimplementować przełączenie komunikator w stan „niedostępny” wraz z informacją, kiedy pojawią się ponownie.


Zaufanie

To pewnie najtrudniejsza część, ale jednocześnie najważniejsza. Jak mawiał kpt.  Shakespeare w „Gwiezdnym pyle": Reputacja - trudno zyskać, łatwo stracić.

Myślę, że z wartością słowa jest podobnie - raz utraconą, bardzo trudno jest odbudować. W czym rzecz? Na początek ufamy, że każdy z członków zespołu robi wszystko najlepiej, jak potrafi i stara się rozwiązywać problemy, używając całej swojej dostępnej wiedzy. Jeśli praca jednej osoby wpływa w jakiś sposób na pracę innych, to jest to dodatkowy powód do wytężonej pracy. Oczywiście nie zawsze (a tak naprawdę rzadko) wszystko idzie zgodnie z planem.

Często pierwotne szacunki są nieco zaniżone (szacowanie to znowu oddzielny temat), szczególnie gdy zespół dostaje w utrzymanie produkt, którego nie tworzył a często także od całkiem słabego zespołu produkcyjnego z wieloma zidentyfikowanymi źródłami ryzyka. Bywa, nikt nie mówił, że to łatwa praca. Jednak, gdy pojawiają się problemy, należy o nich informować, a jeśli potrzebna jest pomoc - należy również o nią prosić (do tego właśnie służą wszystkie narzędzia komunikacyjne, których używamy) a w ostateczności należy poprosić lidera o  przydzielenie pomocy lub po prostu zmianę zadania.

Nie przekładamy w nieskończoność ustalonych terminów, dotrzymujemy obietnic. Nic niezwykłego - ot, normalne życie.

Druga strona zaufania to zaufanie od klientów, czy po prostu użytkowników, ale nie będę nic więcej tutaj pisał, bo rządzi się ono tymi samymi zasadami, co zaufanie w zespole.


Moje ulubione narzędzia

Mamy mnóstwo, naprawdę mnóstwo, różnego rodzaju narzędzie wspierających współpracę (nie tylko zdalną) - wymienię choćby Slack (czy jego klon Mattermost), Skype, Hangouts, Discord. Osobiście najbardziej lubię połączenie Slacka (lub Mattermosta) z Hangouts'ami. Do tego integrację z narzędziami Attlasiana (Jira, ServiceDesk, Bamboo), które także należą do moich ulubionych.

Slack

Wygląda to tak, że na Slacku (czy Mattermoście) tworzymy kilka kanałów:

#developement
Może się również nazywać inaczej. To jest kanał, na którym pojawiają się  pytania dotyczące bieżącej pracy developerskiej, programiści pytają, czy ktoś  spotkał się z jakimś konkretnym problem itp... tutaj także informujemy się o nowych wersjach narzędzi, których używamy, a zmiany są istotne na tyle, że wdrożone niezwłocznie mogą podnieść komfort pracy.

#testing
Jeśli w zespole jest oddzielna osoba (osoby), których zadania są  związane przede wszystkim z testowaniem i niekoniecznie są zainteresowane  informacjami z kanału #development, to tworzymy dla niej (lub dla nich) oddzielny kanał, by nie zaśmiecać kanału głównego informacjami związanymi z pracami testerskimi.

#standup
To jest kanał, na którym odbywa się asynchroniczny stand-up (jeśli to jest forma właściwa dla zespołu), nie publikujemy na tym kanale niczego innego i nie wchodzimy w interakcję. Jeśli zachodzi taka konieczność, to robimy kanały adhoc, przeznaczone tylko i wyłącznie do tej konkretnej interakcji.

#event
Tutaj pojawiają się komunikaty z systemów automatyzacji, takie jak:

- powiadomienia z JIRY lub ServiceDesku o nowych ticketach
- powiadomienia z system CI/CD o buildach i wdrożeniach
- powiadomienia z innych systemów (np. o niedostępności serwera DB, WWW czy innego)

Slack integrujemy z Hangouts'ami w taki sposób, aby kliknięcie w ikonkę ze słuchawką  telefoniczną otwierało konferencję dla osób biorących udział w czacie. Im łatwiej się taką rozmowę inicjuje, tym chętniej programiści będą z tej możliwości korzystali. Dzięki temu zawiązuje się nić porozumienia i otwartość na  współpracę.

ServiceDesk i JIRA

ServiceDesk oraz JIRA to oczywiście przemysłowy standard do zarządzania cyklem pracy nad systemami informatycznymi. Możemy z nich korzystać, pracując w stylu Kanban lub Scrum. Wspomagają przepływ informacji pomiędzy  poszczególnymi liniami wsparcia (w systemach utrzymaniowych) oraz doskonale organizują pracę wytwórczą w stylu Scrumowym.

Pozostałe narzędzia

To oczywiście nie są jedyne dostępne narzędzia - warto wspomnieć Youtrack i TeamCity od JetBrains, czy stary dobry Redmine lub nawet Track. Oczywiście można korzystać z Mantisa czy Bugzilli, ale nie należą one do moich faworytów. Wybierzcie coś, co Wam odpowiada i z czym zechcecie pracować.

Oczywiście narzędzia konfigurujemy w sposób dostosowany do naszej pracy tak, aby widoczna dla każdego była tablica scrumowa lub kanbanowa, by każdy z członków zespołu mógł podejrzeć, co się dzieje. Oczywiście poza omawianiem problemów podczas codziennych stand-upów, warto zastosować jakąś wspólną metodę oznaczania zadań, w których potrzebna jest pomoc. Tutaj jest mnóstwo pomysłów.

Kolejne ważne narzędzie to server CI/CD. Może to być hostowany w obrębie firmy Jenkins/Hudson, oczywiście także Bamboo czy TeamCity, lub coś całkiem zewnętrznego jak CircleCI. Istotne jest, żeby system ten zintegrować z komunikatorem (np. Slackiem) w taki sposób, aby wysyłał do odpowiedniego kanału powiadomienia o statusie pracy, którą wykonuje (jeśli coś pójdzie źle).

Odpowiednia konfiguracja narzędzi i nabranie nawyków współpracy sprawia, że każdy z członków zespołu ma dobry obraz tego, co się dzieje, a co za tym idzie, świadomość tego, kto aktualnie potrzebuje pomocy, lub po prostu ma zadania, które potrzebują wsparcia.


Sprawy inne, ale nie mniej ważne

  1. Cykl pracy nad kodem (także praca utrzymaniowa zwykle wiąże się z kodem) wymaga przeprowadzania jego inspekcji (ang. code review). Dobrym obyczajem jest nieodkładanie CR w nieskończoność i reakcja w najbliższym możliwym terminie (zwykle nazajutrz, na godziny pracy zespołowej).
  2. Czasami zaglądamy także na te kanały w Slacku, które bezpośrednio nas nie interesują.
  3. Dbamy o to, aby słuchawki i mikrofon były zawsze sprawne, jeśli są zasilane bateriami, to należy przechowywać komplet baterii na zmianę. To bardzo irytujące, gdy podczas wspólnej pracy rozładowują się baterie i trzeba przerwać programowanie w parze.
  4. Dbamy o konfigurację komunikatora głosowego - np. hangout często ją gubi (google'u drogi, zrób coś z tym!) i mikrofon przełącza się na mikrofon wbudowany w laptop, przez co dźwięk jest jakby z beczki... bardzo to irytujące
  5. Szanujemy wzajemnie swój rytm pracy. Jeśli kolega z zespołu rankiem chętnie  „pracuje głęboko" to nie prosimy go o programowanie w parach o 9.30. Nie rozpoczynamy także wspólnej pracy 10 minut przed tym, gdy wychodzi do  przedszkola po dzieci, wiedząc, że do wykonania pracy potrzeba nieco więcej czasu.


Dodatkowe metody spajania zespołu

Regularne spotkania zespołu w realnym świecie

Wspólne wyjście na piwo, kręgle, piłkę nożną itd... podobno nic tak nie zacieśnia relacji pomiędzy ludźmi, jak wspólna ciężka praca i radosne, beztroskie imprezowanie. Oczywistym wydaje się, że połączenie jednego z drugim zwielokrotni ten efekt. Dlatego warto takie spotkania organizować dość często (chociaż raz na miesiąc). Niech to będzie czas na wspólne oglądanie meczu, drużynowe pogranie w bilard (da się tak?) czy kręgle. Wypicie paru piwek (albo po prostu kawy czy herbaty), porozmawianie o muzyce, filmach, książkach i życiu. Takie spotkania twarzą w twarz pomagają nam nie zapomnieć, że pracujemy z ludźmi, a nie awatarami w jirze czy na slacku, czy po prostu z głosami po drugiej stronie słuchawek.

Wspólna nauka

W zespołach, z którymi pracowałem/pracuję, lubię organizować wspólną naukę albo w formie prezentacji, albo wspólnego kodowania.

Jeśli jest to prezentacja, to wybieramy wspólnie osobę, która robi research związany z jakimś interesującym narzędziem, które wspomoże naszą pracę (może to być także jakaś biblioteka lub po prostu zestaw technik pracy) i przedstawia go krótko pozostałym członkom zespołu. Istotne jest, aby temat był na tyle nieskomplikowany, by dało się go przedstawić w skończonym czasie (30-40 minut + dodatkowe 20 na ew. pytania lub dyskusję) a osoba przedstawiająca mogła w tydzień lub dwa opanować go na bardzo dobrym poziomie. Może to być nowa biblioteka wspomagająca testowanie, nowy sposób automatyzacji wdrożeń, interesujący nowy (lub stary) edytor tekstowy itd... (lubię opowiadać o Emacsie, którego chętnie używam).

Jeśli uczymy się podczas pracy, to wybieramy jakiś szeroki temat i dzielimy na małe części, np. identyfikowanie fragmentów systemu, które mogłyby być rozwiązane w jakiś elegancki sposób (np. jakimś wzorcem projektowym, specjalną, ale sprawdzoną biblioteką) i wspólnie implementujemy ulepszenie. Oczywiście używamy do tego oddzielnej gałęzi w repozytorium kodu lub środowiska wirtualnego, jeśli zmiana dotyczy wdrażania, jego przyspieszenia lub dodatkowej automatyzacji.

Możemy także zbiorowo ulepszać dokumentację, bawiąc się wspólnie, wyszukując w sieci zabawne obrazki pasujące do ilustrowania konkretnych fragmentów. Wspólna nauka  języków obcych (jeśli pracujemy w środowisku międzynarodowym) to także świetna okazja do przełamania wielu barier.

Taka nauka oczywiście musi być zrobiona w czasie, gdy sprawność intelektualna zespołu jest jeszcze na przyzwoitym poziomie, a jednocześnie nie spodziewamy się żadnego „pożaru”. Piątkowe popołudnia wydają się rozsądnym wyborem.


Podsumowanie

Praca zdalna jest tak samo dobra dla osiągnięcia celu, jak praca „on site". Jedna i druga ma swoje zalety i wady. Obydwie należy odpowiednio zorganizować, aby ludzie przebywający długi czas razem w zamkniętym pomieszczeniu nie zaczęli się na siebie rzucać z ostrymi przedmiotami w rękach (praca „on site") lub nie zapomnieli, kim są, dlaczego ze sobą rozmawiają i jaki jest w ogóle cel ich pracy (praca zdalna). W tym tekście skupiłem się oczywiście na problemie pracy zdalnej i mam nadzieję, że udało mi się przekonać Cię, że nie jest wielkim wyzwaniem zorganizowanie jej w taki sposób, żeby przebiegała płynnie, dając wszystkim satysfakcję, a głównemu zainteresowanemu (szefowi wszystkich szefów) poczucie dobrze wydanych pieniędzy i dumę z jego zespołu.


Książki warte przeczytania

- Cal Newport "Praca głęboka"
- D. Allen "Getting Things Done"
- M. Hammarberg, J. Sunden "Kanban"
- K. Schwaber "Sprawne zarządzanie projektami metodą Scrum"
- G. Kim, K. Behr, G. Spafford "Projekt Feniks. Powieść o IT, modelu DevOps i o tym, jak pomóc firmie w odniesieniu sukcesu"


Na koniec

Jeśli pracujesz w zdalnym zespole i czujesz, że coś nie gra, napisz do mnie (rk@buzzlers.com), a ja spróbuję pomóc.

Zobacz więcej na Bulldogjob

Masz coś do powiedzenia?

Podziel się tym z 80 tysiącami naszych czytelników

Dowiedz się więcej
Rocket dog