Kiedy myślimy o zespole programistów, a konkretnie o jego wydajności – przychodzi nam na myśl zapewne jego doświadczenie, motywacja, czy uzdolnienia. Tymczasem sposób w jaki porozumiewają się członkowie zespołu może zaoszczędzić lub roztrwonić znaczące ilości czasu.
Komunikację w zespole można rozróżnić na synchroniczną i asynchroniczną. Pierwsza oznacza, że nadawca i odbiorca wiadomości muszą w tym samym czasie skupić swoją uwagę. Drugi rodzaj pozwala na odpowiedź po pewnym czasie.
Dominujący rodzaj komunikacji w zespole deweloperskim ma fundamentalne znaczenie dla jego wydajności.
Jeśli zespół komunikuje się synchronicznie, to każda rzecz wymagająca wyjaśnienia rozprasza programistów. Oderwanie dewelopera od kodu, choćby na pięć minut, rujnuje jego skupienie i obniża produktywność.
Przykłady komunikacji synchronicznej:
- programista czegoś nie wie i potrzebuje zadać pytanie, wstaje, idzie do biurka kolegi i pyta
- product owner odpowiada na pytania podczas regularnych spotkań, gdzie omawiane są po kolei wątpliwości różnych osób
- tester nie wie jak przetestować zadanie, podchodzi do programisty i pyta
- programista potrzebuje pomocy w debugowaniu, podchodzi do pierwszego z brzegu kolegi i prosi o pomoc
Marnujemy w ten sposób dużo czasu i energii. Z pozoru jest łatwiej – nie musimy czekać na pomoc, możemy omówić coś na żywo, wydawać by się mogło bardziej dogłębnie, a jednak… podczas spotkań głównie czekamy na swoją kolej, w trakcie pracy przy biurku współpracownicy przerywają nam flow.
Komunikacja asynchroniczna dla sporej ilości osób jest nieintuicyjna, ma jednak ma wiele zalet:
- pozwala osiągać długie okresy skupienia
- pozostawia pisemny ślad, do którego można się odwołać, który można przeszukiwać po jakimś czasie
- pozwala udzielać bardziej przemyślanych, szczegółowych odpowiedzi na pytania
O ile dla pracowników “z biznesu” asynchroniczność może wydawać się dziwna, o tyle dla programistów powinna być oczywistością. Każdy przecież wie, że ponowne załadowanie kontekstu zajmuje czas, że czekanie na odpowiedź serwera blokuje wykonanie programu. Mimo to – w realnym życiu często zdarza nam się o tych zasadach zapominać.
Przykłady komunikacji asynchronicznej:
- product owner odpowiada na pytania mailowo, nie natychmiast, ale sprawnie
- tester zamiast pokazywać programistom problemy opisuje je słownie albo nagrywa filmy pokazujące błędy
- programista mający pytanie zadaje je na slacku lub mailowo, a osoby z zespołu w momencie, gdy nie potrzebują skupienia odpowiadają mu
Najbardziej efektywne zespoły, w jakich miałem przyjemność pracować komunikowały się w dużym stopniu asynchronicznie. Analogicznie – najbardziej niewydajne, omawiały godzinami na spotkaniach w dużych grupach kwestie, które mogły zostać omówione w e-mailu.
Warto pochylić się nad sposobem w jaki organizujemy sobie pracę i dostrzec wzorce, a następnie zastanowić się, czy nie sabotujemy własnej produktywności złymi praktykami.