Team Work

Praca w rozproszonym zespole może być wygodna i przyjemna jak praca zespołu w jednym biurze. Zobacz jak to robimy w Droptica.

17.07.2018

Praca zdalna to codzienność w Droptica. Już od pierwszego dnia działalności mieliśmy dwa biura: we Wrocławiu i Gdańsku. Obecnie mamy trzecie biuro w Rzeszowie. W każdej z tych lokalizacji, codziennie pracują ze sobą programiści, testerzy, graficy i inni specjaliści. Ponadto nasi klienci w 90% pochodzą z zagranicy - jak w większości firm typu software house. Przez kilka lat takiej działalności wypracowaliśmy metody efektywnej i wydajnej współpracy w rozproszonym zespole. Model takiej pracy stale ulepszamy, testujemy nowe narzędzia i sposoby pracy. W tym wpisie dowiesz się, jak to działa w Droptica.

System wspomagający zarządzanie projektami

Od początku powstania Droptica korzystaliśmy z systemu Redmine. Redmine miał kilka dodatków, m.in. z moduł Backlogs wspierający pracę w Scrum. Obecnie używamy Jira, która jeszcze lepiej pomaga w Scrumie. Jeden i drugi system pomaga nam zapanować nad tym, co się dzieje w projektach. Każdy z projektów dzielimy na sprinty, a w ramach sprintów realizujemy zadania. Wszystkie informacje o realizacji zadań zapisujemy w Jira. Tutaj też ma dostęp klient. Dla klienta jest wszystko przejrzyste. Według nas, taki system to konieczność. Bez niego trudno zapanować nad tym, co się dzieje w projekcie, szczególnie jeśli projekty trwają wiele miesięcy. Komunikacja mailowa się do tego kompletnie nie nadaje.

Dwie prędkości komunikacji

Systemy wspomagające zarządzanie projektami są bardzo przydatne, ale niewystarczające do sprawnej realizacji projektu. Ludzie w zespole muszą mieć możliwość wygodnej i szybkiej komunikacji. Jeśli zespół pracuje w jednym biurze, to wystarczy zapytać. W przypadku rozproszonego zespołu sytuacja się komplikuje. Napisanie maila lub dodanie pytania w Jira w celu zadania krótkiego pytania zajmuje wbrew pozorom dużo czasu. Najczęściej wykonujemy następujące kroki:

  • wchodzimy na Jira,
  • znajdujemy projekt,
  • znajdujemy odpowiednie zadanie,
  • dodajemy komentarz,
  • sprawdzamy za jakiś czas czy jest już odpowiedź.

Często ten proces zajmuje więcej czasu niż samo zadanie pytania i odpowiedź, która czasami po prostu brzmi “tak” lub “nie”.  

W Droptica problem ten rozwiązujemy przez komunikację w systemie Slack. Dzięki tej aplikacji rozproszony zespół pracuje, jakby był w jednym biurze. Komunikujemy się szybko i sprawnie. Wykluczamy czasochłonne maile, telefony czy rozmowy wideo. Zmniejsza się też ilość komentarzy w zadaniach w Jira, które często utrudniają analizę prac nad danym zadaniem. 

Slack w Droptica

Dla każdego projektu tworzymy kilka kanałów komunikacji. Kanały robimy, żeby wyeliminować jak najwięcej powiadomień i komunikacji w mailach oraz aby wiadomości były podzielone tematycznie.

Najczęściej podział na kanały wygląda następująco:

  • projectname_chat - kanał do wewnętrznej komunikacji w Droptica na temat danego projektu. Tutaj przypisujemy cały zespół developerski oraz osoby wspomagające projekt (jak devops, testerzy, itp.)
  • projectname_client - kanał dostępny dla klienta oraz zespołu developerskiego. Tutaj jest miejsce na komunikację z klientem, szybkie pytania odnośnie do zadań, ustalanie terminów spotkań, rozmów, itp.
  • kanały z powiadomieniami z systemów używanych w projekcie, np. powiadomienia z Jira, Jenkins, Github, Bitbucket, etc. Najczęściej każdy system ma swój kanał. Zainteresowane osoby mogą dołączyć tylko do ważnych dla nich kanałów i wyeliminować nieistotne dla siebie powiadomienia (np. grafik nie potrzebuje powiadomień z Github).

Przed Slackiem korzystaliśmy z czatów grupowych w Skype, później pojawił się HipChat. Z tych systemów najlepiej sprawdza nam się Slack i aktualnie nie planujemy zmieniać go na inny. Istotne jest też to, że klienci często używają Slacka. Dlatego też łatwo im dołączyć do naszych kanałów jako kolejna organizacja.

Inne narzędzia wspomagające pracę zdalną

Daily Scrum

Nie ma Scrum bez Daily Scrum. W rozproszonym zespole koniecznością jest raz dziennie przeprowadzić rozmowę wideo. Na tych rozmowach czasem obecny bywa też klient, który jest kilkaset czy nawet kilka tysięcy kilometrów od naszych biur. Do tych spotkań używamy kilku narzędzi, zależnie od preferencji zespołu czy klienta. Najczęściej jest to Google Hangouts Meet, ale czasem Zoom.us oraz Skype For Business.

Scrum Retrospective

Do tego używamy prostego arkusza w Google Docs. Mamy arkusz z kolumnami:

  • drop - co należy możliwie ograniczyć lub usunąć
  • keep - co jest dobre i należy kontynuować
  • improve - co musimy ulepszyć
  • add - co musimy dodać, aby lepiej realizować prace nad projektem.

W arkuszu jest historia wszystkich retrospektyw, łatwa do przeglądania i łatwa do edycji. Dokument jest dostępny dla wszystkich osób w zespole, niezależnie od lokalizacji. Sprawdza się to bardzo dobrze.

Code review

Sprawdzanie kodu wykonujemy w Github lub Bitbucket, zależnie od projektu. W tych systemach można łatwo przeglądać kod i dodawać komentarze do wybranych linii skryptu. Nie ma potrzeby, aby jedna osoba przychodziła do biurka drugiej osoby przejrzeć jakość kodu.

Mamy też kilka narzędzi wewnętrznych i skryptów do automatyzacji testów wspomagających Drupal development.

Dobre praktyki pracy zdalnej

Według mnie, przy pracy zdalnej nie można opierać się tylko na komunikacji mailowej lub przez Jira. Do lepszego porozumiewania się konieczne są rozmowy wideo czy telefoniczne. To znacznie usprawnia komunikację w zespole developerskim oraz między klientem a zespołem. Stosowanie Scrum niejako "z automatu” to na nas wymusza. Codziennie odbywa się Daily Scrum w postaci rozmowy wideo. Często też mamy rozmowy wideo z klientem, np. podczas Sprint Review albo w czasie Backlog Refinement. Raz na jakiś czas spotykamy się też z klientem osobiście w naszym biurze lub w biurze klienta.

Ważne też jest, żeby proces komunikacji zbudować tak, aby nie przeszkadzać innym w pracy. Slack jest bardzo przydatnym narzędziem, ale może też doprowadzić do zbyt dużej ilości niepotrzebnych wiadomości, które mogą rozpraszać i przerywać pracę. Zespół powinien mieć tego świadomość i używać Slacka tylko, gdy jest to konieczne oraz wysyłać wiadomości wyłącznie do osób, które muszą je dostać. Nie angażujemy osób, które nie są potrzebne do danej dyskusji.

Czy praca zdalna jest lepsza od pracy w jednym biurze?

Praca całego zespołu w jednym biurze na pewno w znacznym stopniu ułatwia komunikację. Jednak ma też swoje wady, np. dużo łatwiej komuś przeszkadzać w pracy przez niepotrzebne dyskusje. 

W Droptica łączymy pracę zdalną z pracą w biurze. Możemy korzystać z zalet jednego i drugiego modelu. W razie potrzeby budujemy zespoły pracujące tylko z jednego biura.
Więcej niż jedna lokalizacja daje nam przewagę konkurencyjną, ponieważ mamy dostęp do większej ilości specjalistów, nie tylko z jednego miasta, ale z trzech oraz z ich okolic. Dzięki temu możemy zaoferować klientom więcej dobrych programistów.

Wiele biur w Droptica, to też konieczność nauczenia się pracy zdalnej przez każdą osobę w naszym zespole. Dlatego każdy z naszych specjalistów wie jak pracować ze zdalnym klientem.

Podsumowanie

W Droptica wypracowaliśmy system pracy zdalnej, który bardzo dobrze się sprawdza. Uważam, że taki model nie jest w żadnym wypadku gorszy od pracy w jednym biurze. Wręcz przeciwnie, ma wiele dodatkowych korzyści. Jeśli szukasz zespołu ekspertów od Drupala, PHP, Symfony lub ReactJS to chętnie pomożemy. Przy okazji pokażemy, że komunikacja ze zdalnym zespołem może być bardzo dobra :)

Porozmawiajmy o Twoich projektach

Napisz do nas!