Skip to content

Nawyki Profesjonalnych Programistów Java cz. 2

W pierwszym odcinku poruszyłem temat odpowiedzialności, przyglądając się jemu z trzech różnych stron – link do wpisu znajdziesz tutaj. Był to pierwszy odcinek nawyków przyspieszających karierę programisty, które omawiam na łamach tego bloga. W drugim odcinku chciałbym przybliżyć aspekty komunikacyjne i nie chodzi mi wcale o:

  • definicję REST’a, (o niej można było usłyszeć na Javafakturze s02e03, gdzie miałem przyjemność występować)
  • czy tłumaczenie jak to jest „Emacsem przez sendmail

Mam tutaj na myśli zwykłą międzyludzką komunikację. To bardzo istotny aspekt twojej codziennej pracy. Wpływa bezpośrednio na tempo rozwoju twojej kariery. Zapraszam cie do lektury (dla zabieganych na końcu artykułu przygotowałem podsumowanie)

Początkowo miał to być jeden wpis z listą wszystkich punktów. Z racji na dużą ilość treści jaką chciałem w nim zawrzeć, zdecydowałem się na architekturę mikro wpisową.

O wszystkich nawykach przeczytasz tutaj:
1. Bądź odpowiedzialny
2. Komunikuj się efektywnie

Komunikuj się efektywnie

Nie ważne czy komunikacja dotyczy informacji o postępach prac dla naszych przełożonych, czy skrótu prezentowanego podczas standup’u dla innych członków zespołu i jaką formę przyjmie. Cel sprawnej komunikacji często sprowadza się do uniknięcia sytuacji w której:

  • tylko TY coś WIESZ,
  • tylko TY czegoś NIE WIESZ.

Nie bądź niezastąpiony

Dystrybucja wiedzy w zespole ma nawet swoją metrykę, która nosi nazwę bus factor. Chodzi w niej o to ile osób musi rozjechać autobus, aby dana wiedza wyparowała całkowicie z zespołu. Przykładowo, bus factor równy 1 jest czymś czego chcielibyśmy za wszelką cenę uniknąć. Oznacza to, że mamy w zespole osobę niezastąpioną.

Niezastąpioną? – to chyba dobrze, nie?

No, nie do końca. Z perspektywy zespołu jest to jedna z jego dysfunkcji. Przy zmianie pracy, czy choroby tej niezastąpionej osoby, w projekcie powstanie luka, trudna do zastąpienia. Sama osoba zaś, może w dłuższej perspektywie mieć problem z awansem, bo nie będzie miała następcy dla swoich poprzednich obowiązków.

Metryka ta, z reguły dotyczy szerszego zakresu wiedzy. Uważam, że można ją jednak podciągnąć również pod codzienną komunikację, w końcu to na jej fundamentach powstaje wiedza zespołowa. Jeżeli ludzie nie komunikują się ze sobą, jest ogromna szansa, że autobus zabójca byłby bardzo efektywny. Eliminując kilka jednostek, rozłożyłby na łopatki cały dział lub nawet firmę.

Była firma.. nie ma firmy.

Proaktywnie wymieniaj wiedzę

z przełożonymi

Z perspektywy managera/team leadera/product ownera (niepotrzebne skreślić), wiedza nad czym pracują aktualnie jego ludzie, z jakimi problemami się mierzą jest niezwykle istotna. Temu gronu osób w szczególności zależy aby ich część organizacji mogła sprawnie funkcjonować, czyli:

  • generować zyski dla firmy,
  • dbać o to aby pracownicy czerpali satysfakcje z tego co robią.

Do spełnienia obydwóch tych punktów,kluczowa jest dobra komunikacja. Nie zrozum mnie źle, nie chodzi mi wcale o kontrolę absolutną i mikrozarządzanie, a o zdrowy przepływ i wymianę istotnych informacji.

Wykaż się inicjatywą i sam zadbaj o regularne przekazywanie kluczowych informacji. Nie czekaj, aż ktoś inny będzie je od Ciebie wyciągał. Dzięki temu, współpraca z Tobą będzie układać się o wiele lepiej. Tylko pomyśl, jesteś jedyną osobą na temat, której nikt nie ma wątpliwości czym się zajmuje. Ludzie wiedzą, nad czym aktualnie pracujesz i masz potwierdzenie, że jest to słuszne. Uwierz że, to wyróżni Cię spośród innych osób i przypnie łatkę bardziej kompetentnego. Co z tego, że ktoś jest bardziej wydajny, pisze lepszy kod jeżeli komunikacja jest na niezadowalającym poziomie. Dobra komunikacja pełni rolę nośnika, bez którego cała reszta może nie mieć aż tak wielkiego znaczenia.

z kolegami z zespołu

Inną przesłankę ku temu, aby zadbać o sprawne przekazywanie istotnych informacji stanowią wszelkie wypadki losowe. Jak sama nazwa wskazuje, są losowe. Załóżmy, że pracujesz nad jakąś funkcjonalnością i nagle dopada Cię choroba. Jeżeli niedopuszczalny jest przestój zadania nad, którym pracowałeś i musi ono zostać zrealizowane zanim wrócisz do pracy, to pojawia się problem. Niezwykle frustrująca okaże się archeologia, którą muszą wykonać osoby mające kontynuować prace rozpoczęte przez Ciebie. Inaczej sprawa ma się w sytuacji, gdy na bieżąco dbałeś o status i dyskusje z kimś innym z zespołu. Kontynuacja pracy przez osobę znającą kontekst jest o wiele łatwiejsza.

Ok, to jak może wyglądać mały krok w celu usprawnienia komunikacji? Na początku mojej drogi zawodowej usłyszałem, pewną radę od mojego dawnego mentora (pozdrawiam Michał):

Tuż przed wyjściem z pracy, poświęć chwilę na streszczenie tego czym się dziś zajmowałeś. Powiedz, jaki jest twój plan i co będziesz kontynuował w dniu jutrzejszym.

Z doświadczenia wiem, że nie kosztuje to wiele, a znacząco usprawnia komunikację. Pozwala uniknąć przykrych niespodzianek, pokroju dlaczego te prace idą tak wolno. Dziś rozszerzyłbym tę poradę i zaaplikował za każdym razem ilekroć wyda nam się sensowna. Przykłady:

  • pracujesz zdalnie i chcesz przekazać zespołowi czym dziś się będesz zajmował,
  • przygotowałeś pull requesta, ale chciałbyś przekazać pełniejszy kontekst tych zmian i co będzie przydatne dla osób robiących review kodu,
  • szybki status podczas standup’u,
  • zbliża się twój urlop i chciałbyś przed swoim zniknięciem przekazać wszelkie informacje, na temat tego co w ostatnim czasie robiłeś.

Zajmujesz się zadaniem X, co chciałbym wiedzieć na ten temat, gdyby to ktoś inny zajmował się zadaniem X.

Takie odwrócenie kontekstu mocno ułatwia przekaz tego, co ważne. Forma werbalna, to oczywiście, nie jedyna opcja jaką dysponujemy. W dobie slack’a, równie dobrym pomysłem może być podzielenie się statusem w postaci zgrabnej wiadomości. Zaletą komunikatorów jest ich asynchroniczna forma komunikacji, dzięki czemu taki status może zostać skonsumowany później. Wtedy nawet osoby pracujące w „egzotycznych” godzinach, mogą nadrobić wszystko, to co istotne wydarzyło się od rana. Skoro już przytoczyłem ten podział, to zapraszam do szybkiego porównania.

Dobieraj właściwy sposób komunikacji

Skoro już wiesz, że warto się komunikować przeanalizujmy jak to robić. Wszystkie formy komunikacji możemy podzielić na dwie grupy:

  • komunikacja synchroniczna to taka, która wymaga aby zarówno odbiorca jak i nadawca komunikowali się ze sobą, w tym samym czasie. Przykłady:
    • rozmowa
    • standupy
    • code review by shoulder
    • pair programming
  • komunikacja asynchroniczna, czyli taka, która nie wymaga obecności w tym samym czasie nadawcy i odbiorcy. Przykłady:
    • komunikatory np. slack
    • email
    • poczta głosowa
    • standardowe code review
Slack – król komunikacji asynchronicznej

Czy można stwierdzić, że jeden z rodzajów jest lepszy od drugego? Absolutnie nie. Obydwie formy mają swoje plusy i minusy i warto je znać, aby wybierać mądrze.

Wybieraj komunikację synchroniczną gdy:

  • zależy Ci na natychmiastowej odpowiedzi,
  • istotnym elementem komunikacji są emocje,
  • dyskusja dotyczy złożonego zagadnienia,
  • zależy nam na szybkim rozwiązaniu sprawy, której komunikacja ma dotyczyć,
  • sprawa zahacza o korporacyjną politykę.

Wybieraj komunikację asynchroniczną gdy:

  • chcesz być niezależny czasowo (działa gdziekolwiek, kiedykolwiek 24/7/365)
  • istotnym aspektem jest zachowanie konwersacji i łatwe jej odtworzenie przez nas lub przez inne osoby,
  • komunikacja może poczekać i nie chcemy przerywać pracy innych osób,
  • elementem komunikacji, są dokumenty lub pliki, które chcielibyśmy w niej zawrzeć.

Zadbaj aby informacje zwrotne były szybkie

Na sam koniec, jeszcze jeden aspekt wynikający bezpośrednio z komunikacji.

Bez sprawnej komunikacji wydłużamy pętlę informacji zwrotnej.

Czym jest pętla zwrotna w kontekście komunikacji? Na potrzeby tego wpisu przygotowałem, krótką historię, która pozwoli Ci to lepiej zobrazować.

Poznaj Chwałka i Skryjkę. Nasi świeżo upieczeni przedsiębiorcy wpadli na „genialny” pomysł otworzenia startup’u. Zrobili to niezależnie, każdy zakładając swoją firmę. Łączyło ich to, że realizowali swój pomysł w tej samej domenie i obaj rozwijali swój biznes w garażu.

Podstawą sukcesu jest garaż.

Różniła ich natomiast cała reszta, przede wszystkim podejście do komunikacji z innymi:

  • Skryjek preferował podejście aby za wszelką cenę ukryć przed konkurencją wszystkie informacje dotyczące jego pomysłu,. Ukrywał postęp prac oraz jakie były jego metody realizacji. Kto z nas nie słyszał, że 50% to pomysł? Skryjek słyszał! Zamknął się na rok w garażu i pracował całe dnie i noce nad swoim projektem.
  • Chwałek podszedł do tematu zupełnie odwrotnie. Od momentu, w którym wpadł na pomysł, dzielił się nim ze znajomymi, rodziną, a nawet konkurencją. Już na samym starcie, dopytywał o opinie. Dzielił się też pomysłami, w jaki sposób chce osiągnąć pewne cele i jakich narzędzi chce do tego celu użyć.

Minął rok i nasi bohaterowie spotkali się podczas konkursu startup’ów, razem ze swoimi projektami. Nie dało się ukryć, że rozwiązanie Chwałka wyglądało imponująco, jednocześnie było tanie i przyciągało tłumy. Skryjek nie mógł cieszyć się taką popularnością. Jego stoisko świeciło pustkami. Co więcej samo rozwiązanie nie wyróżniało się na tle kilku podobnych tematycznie startup’ów. Podczas przerwy obiadowej, nasi bohaterowie mieli okazję porozmawiać, ze sobą. Z ich dyskusji wynikało jednoznacznie, że różnice w procesie twórczym dało się podsumować jedną metryką długością trwania pętli zwrotnej.

Im któtsza pętla tym szybciej jesteś w stanie wyciągać wnioski na podstawie swoich działań
  • Chwałek – dzięki częstej komunikacji, podglądaniu konkurencji, dyskutowaniu z innymi, był w stanie skorygować swój początkowy pomysł. Dzięki, krótkiej pętli zwrotnej mógł na bieżąco wprowadzać poprawki i usprawnienia do swojego pomysłu.
  • Skryjek – tak bardzo dbał o prywatność i skrywanie swojego pomysłu, w efekcie czego jego pętla zwrotna była bardzo długa i jedyna weryfikacja nastąpiła podczas konkursu startup’ów.

Mimo, że historia ta na pierwszy rzut dotyczy aspektów biznesowych, lekcje z niej płynącą jak najbardziej możesz zaaplikować do realiów programistycznych. Wystarczy pomyśleć, że Skryjek i Chwałek to dwójka programistów, implementująca podobny kawałek rozwiązania. Komunikacja również w takiej wersji historii będzie wpływać na podobne efekty.

Więcej w książce „Metoda Lean startup” Erica Ries’a

Podsumowanie

Kilka rad które powinieneś wyciągnąć z tego wpisu to:

  • unikaj bus factor 1 – nieważne, czy wiedzę posiadasz Ty lub ktoś inny zespołu. W obu przypadkach to dysfunkcja, która rozwala produktywność zespołu na dłuższą metę,
  • komunikuj innym co robisz, nawet gdy o to nie proszą, dbając w ten sposób o dobry przepływ i wymianę wiedzy,
  • używaj odpowiedniego typu komunikacji, w zależności od kontekstu i celu jaki chcesz osiągnąć,
  • bądź Chwałkiem, nie Skryjkiem. Konsultuj swoje pomysły, rozmawiaj często z innymi. Skorzystasz na tym zarówno Ty jak i inni.