logo

Komunikacja - druga najważniejsza rzecz w programowaniu

Długość wpisu: 8 min

💡 Ten wpis ma na celu nakreślenie problemu. Jeżeli już wiesz, że komunikacja jest dużym problemem, to możesz chcieć przejść od razu do następnego wpisu, w którym przedstawiam konkretne rozwiązania.

Pamiętam moje pierwsze oświecenie, gdy zaczynałem pracować jako programista. Było jak solidny kopniak w twarz:

👉 W pracy programisty najwięcej jest gadania oraz czytania, a dopiero na trzecim miejscu jest kodzenie.

Niezależnie od tego, czy pracowałem jako frelancer, czy byłem na praktykach w firmie, czy też pracowałem już “normalnie” na etacie, to zawsze najpierw było gadanie.

Trzeba było dogadać się z klientem, ugadać scope zlecenia, poszukać informacji, popytać.

Zorientowałem się, że programowanie to przede wszystkim praca z ludźmi - z innymi i z samym sobą.

Kod jest efektem ubocznym, a najważniejszą rzeczą, poza wszechobecną zmianą, o której pisałem wcześniej, jest komunikacja.

Źródło wszystkich problemów

Wprowadzanie zmian nie byłoby możliwe, gdyby nie komunikacja.

To sprawna i jasna komunikacja powoduje, że projekty są dowożone.

Nieprzerwanie odkąd zacząłem pracować w IT, widzę pewną prawidłowość:

Większość problemów spowodowanych jest słabą komunikacją.

Pokusiłbym się nawet o stwierdzenie, że wszystkie problemy w IT spowodowane są słabą komunikacją.

Leci mi już 8 rok pracy i nie pamiętam, żeby udało mi się zaobserwować, że coś poszło (mocno) nie tak ze względu na brak umiejętności technicznych.

A nawet jeśli coś wyglądało jak problem techniczny, to zawsze dało się prześledzić przebieg wydarzeń i dojść do tego, że tak naprawdę ktoś gdzieś się nie dogadał. Zawsze u źródła problemu znajdywała się komunikacja.

Patrząc na to z bardziej pozytywnej strony, w 100% przypadków, które widziałem, złe decyzje techniczne albo brak umiejętności dało się odratować, gdy komunikacja była w porządku. Wystarczyło to zauważyć, powiedzieć na głos i podjąć decyzję, co z tym zrobić.

Podejrzewam, że gdybym prześledził każdy uwalony projekt, to u podstaw znalazłbym jakiś problem komunikacyjny, który ten upadek zapoczątkował. Po prostu nie zawsze te problemy widać.

Komunikacja jest wszędzie

☝ To stwierdzenie wydaje się być oczywiste, ale nie zawsze jest.

Captain Obvious

Zacznijmy więc od “najważniejszego”.

Kodzik

Piszemy kod po to, żeby się komunikować. Nie jest to wielkie odkrycie. Często jednak zapominamy, że jest to komunikacja w dwie strony.

Komputer uwielbia zera i jedynki, najlepiej jakbyśmy mu wszystko podali w ten sposób. My jednak nie piszemy kodu samymi zerami i jedynkami.

Najpiew uprościliśmy zapis zerojedynkowy do innych np. szesnastkowego.

Potem zaczęliśmy budować języki programowania, które tłumaczą kod do zer i jedynek za nas, mamy Assemblera, C.

A potem szliśmy dalej, do języków programowania wyższego rzędu - powstała Java, C#, JavaScript i inni.

A potem zaczęliśmy budować co raz to bardziej wyrafinowane biblioteki oraz frameworki. I w takim świecie żyjemy dzisiaj.

Wszystko dlatego, że kod to komunikacja w dwie strony - w stronę komputera i w stronę kolegi w zespole.

Budujemy kolejne warstwy abstrakcji, bo każda z nich coś upraszcza i ułatwia komunikację.

Dlatego mamy wzorce projektowe. Łatwiej jest powiedzieć “użyłem wzorca strategii”, niż tłumaczyć jego działanie za każdym razem.

Dlatego piszemy komponenty w React. Łatwiej jest zrozumieć słowa “wyświetl tego jsona w panelu użytkownika”, gdy wiemy, że “panel użytkownika” to UserPanel.js napisany w Reakcie, a nie jakiś randomowo ułożony zestaw tagów htmlowych.

Dlatego mamy testy. Głównym celem testów jednostkowych jest komunikacja i specyfikacja. Testowanie dostajemy gratis.

Tutaj miałem fajny cytat Uncle Bob-a na ten temat, ale gdzieś mi się zwieruszył i nie ma.

Patrząc na testy, Twój kolega musi rozumieć jak działa rzecz, którą testujesz.

Kto myśli o testach w ten sposób? Z mojego doświadczenia wynika, że prawie nikt.

Tak samo jak nikt nie myśli o kodzie jako o sposobie komunikacji. Co drugi junior developer zastanawia się jak “zoptymalizować” pętle, które napisał, podczas gdy ficzer, który ma dowieźć, jeszcze nie działa, a sam kod jest takim pasztetem, że nawet sam autor za dwa dni nie będzie rozumiał co robi.

Jednak wiele osób wybiera optymalizowanie kodu dla maszyny, a dopiero potem dla kolegi. Podczas gdy maszyna zrozumie każdy rzyg, a Twój kolega już nie.

Większość osób olewa też pisanie przejrzystych README oraz aktualizowanie dokumentacji i opisywanie ważnych procesów takich jak np. deploy. 🤷‍♂️

Zespół

Mimo stereotypów programiści to bardzo fajni ludzie, ale są też wśród nas naprawdę nieźle wykręcone typy.

Dwight Schrute

Z każdym trzeba się jakoś dogadać. Z tymi pierwszymi jest łatwiej, a z tymi drugimi “to zależy”.

Zgodnie z zasadą, że mądrzejszy musi być mądrzejszy, musisz wziąć na klatę komunikację z dziwnymi ludźmi i pokierować ją w taki sposób, żeby to jakoś działało.

Jest wiele świetnych narzędzi poprawiających komunikację. Są one tak potężne, że nawet osobę o przeciętnej inteligencji jesteś w stanie nakierować na sensowne myśli i przekształcić w kogoś sensownego.

Samo budowanie zespołu również polega na odpowiednio zbudowanej komunikacji. Widziałem już, jak wszyscy w zespole kłócili się miesiącami, tylko dlatego, że nie rozumieli się nawzajem.

Każdy gadał, zamiast słuchać. Wystarczyło zrobić jednodniowy warsztat, żeby uświadomić, albo po prostu przypomnieć, że wszyscy gramy do tej samej bramki.

Potem okazywało się, że w sumie to każdy ma tę samą rzecz na myśli, ale komunikuje ją w inny sposób. A przez to, że nikt nie potrafi słuchać, robiły się niepotrzebne dramy.

Pomimo tego, nigdy nie spotkałem programisty, który wkłada tyle samo energii w szlifowanie umiejętności komunikacji, co w umiejętności techniczne. Po stronie klienta też nie jest jakoś specjalnie lepiej.

Nawet osoby z wieloletnim stażem bywają mocno niedorozwinięte pod kątem komunikacji. Często nie mają za grosz umiejętności budowania zespołu, w oparciu o szczerą i jasną komunikację.

Klient

O ile w zespole jesteśmy sobie jeszcze jakoś w stanie poradzić, najwyżej będziemy na siebie warczeć i szczekać miesiącami, to gorzej jest w komunikacji z klientem.

Gdy jesteś jeszcze młody i niewinny, to ktoś komunikuje się z klientem za Ciebie i nie musisz się jakoś szczególnie martwić.

W końcu jednak będziesz musiał. Stanie się to np. wtedy, gdy mama-lider pójdzie na urlop albo gdy zostaniesz sam w pracy przed świętami Bożego Narodzenia, bo reszta zespołu zupełnie przypadkiem weźmie urlop.

Wtedy to do Ciebie będzie należało dogadanie się z klientem i przekształcenie jego płaczów w działający kod.

Albo dogadanie się jak dostać się na serwery produkcyjne, żeby zdeployować fixa. Bo jak już wspomniałem README/dokumentacji nikt nie aktualizuje, więc nie będziesz miał pojęcia jak dostać się na serwery. 🤷‍♂️

W takich sytuacjach będzie też brakować Ci czasu. Trzeba będzie lepić pierogi i stroić choinkę. Jak powiesz klientowi, że część pracy będzie musiała być zrobiona po świętach? W jaki sposób to zakomunikujesz, żeby się nie wkurzył?

Jak poradzisz sobie z tym, że część klientów świadomie ignoruje to, co mówisz?

Narzędzia

Jest jeszcze cała masa narzędzi, których używamy w codziennej pracy i które również służą do komunikacji. Wymieniałem je już przy okazji rzeczy, które pomagają wprowadzać zmianę.

Jira, opisy tasków, powiadomienia o failujących buildach na Slacku, CI, wyniki testów, screenshoty, demo dla klienta, retro, code review, i cała masa innych.

Te narzędzia pomagają nam się komunikować, uświadamiają sytuację w projekcie i tym samym umożliwiają wprowadzanie zmian.

Nikt nie potrafi się komunikować

Każdy w zespole, niezależnie od tego, czy jest programistą, czy nie, powinien umieć rozmawiać z ludźmi w efektywny sposób, dostosowując poziom abstrakcji do odbiorcy.

Ktoś kiedyś powiedział, że możesz mieć najlepsze pomysły na świecie, ale jeśli nie potrafisz zakomunikować ich światu, to i tak jesteś w dupie (tłumaczenie własne).

Z mojego doświadczenia wynika, że prawie nikt nie potrafi się komunikować.

Oto krótka, niekompletna, poglądowa lista błędów, którą napisałem w 30 sekund na kolanie, bo naprawdę nie trzeba się wysilać, żeby te wszystkie braki zauważyć:

  • zadajemy słabe pytania
  • udzielamy słabych odpowiedzi
  • spotkania są nieefektywne, bo dryfujemy w rozmowach na nieważne tematy
  • rozwalamy spotkania i rozmowy gadając o rzeczach, które nie mają znaczenia z punktu widzenia spotkania
  • komunikaty są nieprecyzyjne
  • używamy skrótów myślowych
  • nie dostosowujemy języka do rozmówcy
  • porozumiewamy się na złym poziomie abstrakcji, mówimy technicznie do klienta, który nie jest techniczny
  • nie umiemy rozmawiać językiem biznesowym
  • nie rozumiemy terminów biznesowych
  • nie stosujemy słowników i nazywamy tę samą rzecz na 5 różnych sposobów
  • komunikujemy się za pomocą buzzwordów i słów, które nam się podobają, a nie takich, które zrozumie nasz rozmówca
  • nie dostosowujemy komunikatu pod rozmówcę
  • gdy czegoś nie rozumiemy to nie dopytujemy
  • zapominamy, że zdania mogą mieć różne znaczenia
  • nasze spotkania nie mają celu
  • nasze zadania nie mają celu
  • zadajemy pytania w ciemno, sami nie wiemy po co pytamy
  • zadajemy pytania sugerując rozwiązanie, zamiast w ogóle zapytać czy to rozwiązanie ma sens
  • nie podajemy kontekstu podczas rozmowy
  • mówimy, a dopiero potem myślimy
  • nasze słownictwo z klientem jest na poziomie “kali jeść, kali pić”, bo nasz angielski jest tak bardzo słaby
  • wmawiamy sobie, że coś rozumiemy, gdy nie rozumiemy
  • wstydzimy się zapytać
  • pozwalamy, żeby nasze uprzedzenia kierowały rozmową
  • nie mamy pojęcia, że kierują nami błędy poznawcze
  • używamy nieprecyzyjnych stwierdzeń typu “ulepszymy security” zamiast “zapobiegniemy 90% ataków hakerów w 2 tygodnie”
  • (…)

Mógłbym tak ciągnąć jeszcze bardzo długo.

Przejdźmy lepiej do konkretów, czyli do tego, dlaczego to wszystko, co napisałem w akapitach wyżej, jest dla Ciebie bardzo dobrą informacją. 😺

Low-hanging fruits

Z powyższych akapitów wynikają dwie rzeczy:

  1. Komunikacja jest wszędzie i ogarnięcie jak robić to dobrze pomoże Ci w wielu sytuacjach - z klientem, z zespołem, z kodem i nawet z przełożonymi.
  2. Dobrze ogarnięty skill komunikacji (na każdym poziomie) to mega rzadkość.

To oznacza, że poprawianie swoich umiejętności komunikacji, to jeden z najlepszych kroków, które możesz zrobić, żeby wybić się przed szereg. Nie jest on jakoś specjalnie trudny, bo jak to powiedział pewien mądry człowiek:

Wielcy są tylko wielcy, bo my klęczymy. ~Max Stirner

Wystarczy wstać z kolan i nauczyć się porozumiewać z innymi. Za pomocą kodu, za pomocą testów, za pomocą dokumentów oraz słów odpowiednio dostosowanych do rozmówcy.

Gdy już to ogarniesz, to będziesz się wkurzać, jak słabo wychodzi komunikacja innym osobom. Ale wtedy, będziesz mógł wziąć sprawy w swoje ręce. Będziesz miał bardzo duży wpływ na wiele spraw.

Ten post miał za zadanie nakreślić Ci problem. Istnieje mnóstwo gotowych narzędzi i mam swoje ulubione, chciałbym jednak opisać je w kolejnych postach.

Jeśli chcesz od razu przejść do działania, to polecam Ci zacząć patrzeć na kod i testy jako narzędzia do komunikacji. Powinno to trochę zmienić jak kodzisz.

Zerknij też na tę listę braków powyżej i zastanów się, o których rzeczach na tej liście wiesz najmniej. I zacznij googlać.

Jak nic nie znajdziesz, to napisz do mnie maila i powiem Ci gdzie szukać.

🖖

💡 Kontynuację tego wpisu znajdziesz tutaj:

Narzędzia poprawiające komunikację, które pożyczyłem od Keanu Reevesa i Hannibala Lectera

Podziel się:

Instagram, Twitter, YouTube, Facebook, LinkedIn