Oni czegoś nie rozumieją, czyli 5 praktycznych porad, jak powinna wyglądać komunikacja w zespole

Powodzenie projektu, które w pewnym sensie możemy zdefiniować jako zadowolenie klienta, ma bardzo wiele zmiennych. Odpowiednie techniczne umiejętności programistów, to oczywiście jedna z istotniejszych. Natomiast coraz częściej utwierdzam się w przekonaniu, że efektywna komunikacja okazuje się być niejednokrotnie ważniejsza.

Jako programiści najwięcej czasu poświęcamy na pisanie kodu (obóz “Najwięcej czasu poświęcamy na czytanie kodu” właśnie został zaintrygowany). Spokojnie! Również uważam, że więcej tego kodu czytamy niż piszemy — robimy też wiele innych rzeczy, jak chociażby projektowanie i rozwiązywanie problemów. W każdym razie, po jakimś czasie kodowania, powstaje aplikacja. Piszemy kod, czytamy kod – wszędzie kod. Można więc pomyśleć, że wszystko opiera się na nim i że to on jest w naszym zawodzie najważniejszy. Generalnie jest to prawda – żeby w ogóle zacząć, musimy go rozumieć i potrafić go pisać, więc od tego się wszystko zaczyna. Zapisujemy się na studia informatycznie, szukamy jakiegoś kursu, bootcampu czy jeszcze innego sposobu nauki i po jakimś czasie ten nasz kod staje się coraz lepszy. Kodujemy w każdej wolnej chwili.

Jak już się nauczymy i realizujemy kolejne projekty, to po czasie okazuje się, że jednak wiemy mało i wszystko paradoksalnie wydaje się o wiele bardziej skomplikowane, niż na początku. Uczymy się dalej, realizujemy trudniejsze projekty. Niektóre kończą się powodzeniem, inne niestety nie mają już tyle szczęścia. W końcu zdajemy sobie sprawę, że kod nie jest jedynym czynnikiem zadowolenia klientów. Jest on pewnym środkiem do celu, narzędziem w naszej pracy, ale tylko jednym z wielu.

Po pewnym czasie codziennego programowania i rozwiązywania problemów, w końcu większość programistów osiąga podobną wiedzę i umiejętności. Jednym zajmuje to nieco więcej czasu, innym mniej. Pasjonaci oczywiście pójdą dalej, jednakże Codziennemu Programiście to wystarczy. I nie ma w tym nic złego, będzie on w stanie zrealizować zdecydowaną większości projektów.

Wtedy do gry wchodzi komunikacja! Oczywiście weszła już o wiele wcześniej, w sumie to była z nami od samego początku, ale teraz dopiero zdajemy sobie sprawę z tego, jak bardzo jest ona istotna. Dlaczego akurat teraz? Bo wcześniej byliśmy pochłonięci doskonaleniem swojego warsztatu programistycznego tylko od strony technicznej. Tylko to się dla nas liczyło. Teraz robimy już rzeczy coraz częściej powtarzalne i mamy miejsce na rozmyślania. Rozmyślania chociażby o tym, dlaczego ten projekt się nie udał, skoro mieliśmy odpowiednie umiejętności programistyczne, aby go zrealizować?

Jak ważna jest komunikacja — czy raczej jej brak — dowiadujemy się najczęściej, gdy mamy do czynienia z krótkimi projektami, 2-6 miesięcznymi, co znaczy, że często zmieniają się nam klienci, a nawet zespół. Jak na profesjonalnych rzemieślników przystało, zależy nam na każdym projekcie, na każdym kliencie. Każdy jest inny, każdego trzeba się nauczyć, w każdym nowym musimy wypracować sobie efektywną komunikację czy to z nowym zespołem, czy z nowym klientem, czy przeciwstawiając się nowym problemom.

Komunikacja niestety również podlega Prawom Murphy’ego. Trzeba być bardzo ostrożnym. Przez jej nieefektywność lub też jej zupełny brak, dochodzi do poważnych problemów: dział marketingowy rozpoczął akcję promującą produkt o tydzień za wcześnie, klient myślał, że dana funkcjonalność jest już gotowa od dwóch tygodni (a nie jej prototyp), pole w odpowiedzi na zapytanie serwerowe zostało dodane nie do tego zapytania, powstają też nieustające kłótnie między programistami odnośnie kodu.

Można by tak wymieniać w nieskończoność — wszyscy tam byliśmy. Jak się przed tym chronić? Pozwólcie, że podzielę się z wami moimi spostrzeżeniami na temat najczęstszych problemów w komunikacji oraz radami, jak sobie z nimi radzić. Jest ich tylko 5. Zaczynamy!

Niepełność komunikatów

Jesteśmy wszyscy osadzeni w swoich subiektywnych kontekstach. Odbieramy te same informacje, ale interpretujemy je zazwyczaj w zupełnie inny sposób — przez ich niepełność. Gdy dostajemy za mało informacji, to naturalnym jest, że samodzielnie uzupełniamy braki, często w sposób nieświadomy.

Ja: “Byłem w tym miejscu, o którym rozmawialiśmy ostatnio. To, gdzie kelnerzy byli nadzwyczaj mili. Świetne jest. Może spotkamy się tam dzisiaj o 18:00?”
X: “Jasne, do zobaczenia!”

Jak myślicie, uda nam się spotkać? Prawdopodobnie tak. A nawet gdyby nie, to nic takiego się nie stanie. Wystarczy jeden telefon i wszystko będzie wyjaśnione. Szczęśliwe zakończenie.

Czy w projekcie możemy sobie pozwolić na takie pomyłki?

Ja: “W tym zapytaniu, o którym rozmawialiśmy ostatnio, potrzebuję jeszcze pola <first_name> zalogowanego użytkownika”
X: ”Jesteś pewien? Trochę się trzeba narobić, żeby to osiągnąć.”
Ja: “Tak, tak. Bardzo ułatwi nam to pracę.”

(Następnego dnia)
Ja: “To pole jest dodane nie w tym zapytaniu, o którym mówiłem. Chodziło mi o (…)”
X: “Ach, myślałem, że chodzi o inne. To już powinno tam być. Poczekaj. (…)”

Zdarza się? Jasne. Czyja wina? Nasza. Przekazaliśmy niepełną informację i straciliśmy przez nią jeden dzień. Czy to dużo? To zależy — dla projektu trwającego 2 lata pewnie nie, dla dwumiesięcznego MVP już tak.

Niepełność komunikatu polega tutaj na tym, że informację, o jakie dokładnie zapytanie nam chodzi, osoba z projektu odpowiedzialna za backend musiała wywnioskować sama, gdyż my tego nie określiliśmy precyzyjnie. Pełny komunikat wyglądałby tak:

Ja: “W odpowiedzi na zapytanie GET https://nasza.aplikacja/api/user potrzebuję jeszcze pola <first_name> zalogowanego użytkownika. Tutaj masz zapytanie, które wysyłam wraz z nr id użytkownika: (…)”
X: “To pole powinno tam być. Sprawdziłem tego użytkownika i ma stare dane. Prawdopodobnie jest to testowy użytkownik. Stwórz nowego i wszystko powinno działać.”

Teraz już nie ma miejsca na własne interpretacje. Jeżeli nie wiemy, co jest istotne dla osoby, z którą pracujemy, to zapytajmy ją o wszystkie dane, które powinniśmy jej podawać, aby nie było nigdy miejsca na niedomówienia.

Kiedy pracujemy w tym samym biurze co zespół lub siedzimy w tym samym pokoju, często rozmawiamy twarzą w twarz i niepełne informacje nie wydają nam się aż tak uciążliwe, bo staramy się je zazwyczaj dopełnić. Czyli po prostu zadajemy pytania, żeby mieć pewność, o co dokładnie chodzi naszemu rozmówcy. Tylko wtedy nasza komunikacja jest taka jakby… od tyłu.

Ja: “Potrzebuję dodatkowego pola <first_name>”
X: “Po co? I gdzie?”
Ja: “Dla zalogowanego użytkownika. Teraz nie możemy zrobić (…) i bardzo by to dodatkowe pole pomogło.”
X: “Ale gdzie chcesz to pole?”
Ja: “No w tym zapytaniu, o którym ostatnio gadaliśmy.”
X: “W tym: (…)?”
Ja: “Nie. W tym: (…).”
X: “No dobra. Albo czekaj. Podaj mi id użytkownika, to pole powinno tam być.”

Ile razy zdarzyło wam się przeprowadzić taką rozmowę? Często, prawda? Wydaje się niewinna, ale niestety potrafi być bardzo niebezpieczna. Jest w niej dość sporo miejsca na pomyłki i niedopowiedzenia. Tylko dzięki osobie X do tego nie doszło.

Czy możemy sobie pozwolić na takie rozmowy, gdy pracujemy z naszym zespołem zupełnie asynchronicznie? Gdy pracujemy z Polski, a druga osoba ze Stanów Zjednoczonych, z różnicą czasową dziewięciu godzin? Jeżeli nie będziemy precyzyjni pisząc do tej osoby, będziemy tracić bardzo duże ilości czasu na rzeczy z pozoru proste.

Rada: Nasze komunikaty muszą być pełne i nie powinny zostawiać miejsca na interpretacje.

Oferty pracy z

Nie widzę Cię i nie słyszę

Podczas rozmowy twarzą w twarz słyszymy i widzimy drugą osobę. Oprócz samych słów, odbieramy mnóstwo innych sygnałów z mowy ciała, mimiki twarzy, tonu głosu. To wszystko zostaje nam odebrane przez komunikator. Jest tylko tekst.

Dlatego, w mojej ocenie, tak bardzo popularne są emoji czy gify. Jesteśmy w stanie dzięki nim wyobrazić sobie drugą osobę, jej stan emocjonalny i dopasować odpowiedni ton głosu. Skoro więc mamy emoji, używajmy ich. Truizm, powiecie, i tak to robimy. Doprawdy? Na pewno w luźnych rozmowach, ale czy również gdy rozmawiamy o kodzie? Czy również gdy rozmawiamy o architekturze? O problemach? Gdy mamy inne zdanie na temat danego rozwiązania? To są tematy trudne do rozmowy gdy jesteśmy twarzą w twarz, więc będą jeszcze trudniejsze, gdy widzimy tylko tekst.

Ekscytujemy się, lekko wzburzamy i wtedy sami dokładamy naszemu rozmówcy ton głosu i wyraz twarzy. Sam tekst, żadnego emoji, dużo kropek — na pewno jest zirytowany — myślimy, i też się irytujemy.

X: “Nie możesz tego tak zrobić. To o krok od kodu spaghetti. Jutro o tym porozmawiamy.”

Czy jutro dostanę reprymendę? Czy osoba X już jest tak bardzo zdenerwowana moim kodem, że ma już tego dość?

X: “Nie możesz tego tak zrobić. To o krok od kodu spaghetti. Jutro o tym porozmawiamy ”

Jednak nie chodziło o reprymendę. Po prostu musi już kończyć pracę na dzisiaj i jutro wrócimy do tego tematu. Jedna dodatkowa minka i dzięki niej pożegnanie jest o wiele bardziej “miękkie”.

Te przykłady wydają się bardzo błahe. Nie zrozumcie mnie źle. Nie chodzi mi o to, żeby wszędzie wstawiać animowane minki czy obrazki, ale o to, żeby zadbać o naszego odbiorcę po drugiej stronie. Łatwo jest coś wpisać w komunikator i wcisnąć enter.

Jak już wspomniałem, rozmowy o kodzie bywają pełne emocji i bardzo łatwo doprowadzić do niepotrzebnego spięcia. Szczególnie łatwo o to podczas Code Review. Komentarze typu:

• “Po co to tutaj dałaś?”,
• “Dlaczego tak to jest zaimplementowane? Użyj (…)”,
• “Zmień to (…), na to (…)”.

Niby nic w nich złego, pewnie powiedzielibyśmy je na głos. Ale pamiętajmy, że nasz rozmówca teraz nas nie słyszy. Sam dobierze sobie nasz ton głosu, a może być bardzo przywiązany do swojego kodu. Na zimno te wypowiedzi wcale tak dobrze nie brzmią — wyobraźmy sobie nas nieco zmęczonych, może lekko poddenerwowanych jakąś sytuacją. Dołożymy złe intencje. Może spróbujmy w ten sposób:

• “Wydaje mi się, że można to jeszcze napisać w nieco inny sposób: (…). Co o tym myślisz?”,
• “Proponuję zamienić to (…) na to (…). Według mnie jest to nieco czytelniejsze.”.

O wiele lepiej. A gdy uśmiechamy się, pisząc ten komentarz, to czemu by też nie dołożyć jakiegoś emoji?

Rada: Pisz tak, aby druga osoba mogła Cię zobaczyć i usłyszeć. Nie pozostawiaj miejsca na wyobrażenia.

Niech to spotkanie w końcu się skończy

Spotkania są tym czasem podczas wytwarzania oprogramowania, w którym nie powinniśmy robić nic, poza komunikowaniem się. Wiem, wiem, również nie jestem zwolennikiem wielu spotkań. Na co dzień pracuję w Scrumie. Spotkania, które cenię sobie najbardziej to Daily (Standup) oraz Retrospektywa. Z punktu widzenia dobra projektu, te dwa spotkania muszą być “przeżyte”. W pełnym skupieniu.

Pierwsze przeznaczone jest do zsynchronizowania pracy całego zespołu. Dzięki temu dokładnie wiemy, co robią pozostali członkowie i czym zajmą się do kolejnego spotkania. Jesteśmy w stanie pomóc lub doradzić, gdy wspomną o problemach, które próbują rozwiązać bez większego powodzenia. Również nam może zostać udzielona pomoc.

No właśnie, problemy. Istotą tego spotkania jest nie tylko zakomunikowanie, nad czym aktualnie pracujemy, ale przede wszystkim, jakie mamy problemy, czy ukończenie zadania przedłuży się, co nas blokuje, ale przede wszystkim, że potrzebujemy pomocy. Często duma nie pozwala nam prosić o pomoc. My jej nie potrzebujemy. Zrobimy to sami. W końcu odkryjemy, o co chodzi, nauczymy się tej nowej technologii i zadanie będzie skończone, tylko dzięki nam.

Jesteśmy ambitni i nie ma w tym nic złego, ale ta ambicja nie powinna być przeszkodą w zrealizowaniu celu projektu. Nie ma nic złego w proszeniu o pomoc. Programowanie w parach jest jedną z lepszych metod pomagających w rozwoju programistów. Nie powinniśmy od tego uciekać, nie powinniśmy się tego wstydzić.

Mała dygresja. Z tego samego powodu, a więc przez naszą ambicję, bardzo często nie trafiamy z oszacowaniem czasu, potrzebnego na zrealizowanie danej funkcjonalności. Nie chcemy wypaść na słabych, na tych, którzy czegoś nie potrafią, nie zrobią zadania szybko, bo nigdy go nie robili. Chcemy zawsze być postrzegani w oczach innych i oczach klienta, jako Ci, którzy zawsze ze wszystkim dadzą sobie radę i każde zadanie zrobią szybko. Spójrzmy prawdzie w oczy. To iluzja. Musimy komunikować, jeżeli czegoś nie wiemy, jeżeli według nas coś jest trudne i zajmie dużo czasu.

Klient: “Jak dużo czasu zajmie zrobienie tej funkcjonalności?”
Ja: “Nie wiem. Musiałbym najpierw przyjrzeć się temu bliżej i dopiero wtedy będę w stanie realnie to oszacować. W tej chwili byłby to ślepy strzał.”

Czy jest coś złego w tej rozmowie? Nie. Zachowaliśmy się profesjonalnie.

Klient: “Jak dużo czasu zajmie zrobienie tej funkcjonalności?”
Ja: “3-4 dni dla jednej osoby.”
Klient: “Tak dużo? Przecież to nie wydaje się skomplikowane. Na pewno nie da się tego zrobić szybciej? W 1 lub 2 dni?”
Ja: “Na pozór to zadanie wydaje się łatwe, ale takie nie jest. Najbardziej problematyczne będzie (…). Musimy tutaj również obsłużyć takie przypadki jak (…). Żeby nie skomplikować kodu, co w krótkiej przyszłości wydłużyłoby tworzenie każdej kolejnej funkcjonalności, musimy to przemyśleć i dobrze zaprojektować. Dlatego 3-4 dni są realne.”

Kolejny raz wykazaliśmy się profesjonalizmem, pomimo tego, że nie potrafilibyśmy zrobić zadania tak szybko, jakby chciał klient.

Klient to jedno, a nasi koledzy po fachu to drugie. Przed nimi również się wstydzimy, z tych samych powodów. Jednakże musimy wykazać się profesjonalizmem i powiedzieć prawdę — mam z czymś problem, zajmie to więcej czasu. Daily są właśnie miejscem na tego typu komunikaty.

Retrospektywy z kolei pozwalają zespołowi na szczerą rozmowę o wszystkich sytuacjach i zachowaniach towarzyszących nam podczas wytwarzania oprogramowania. To tam powinniśmy szczerze ocenić pracę całego zespołu. Wymienić wszystko to, co było dobre, ale również (i przede wszystkimi) to, co poszło nie tak. W sposób szczery i niewymuszony. Oczywiście powinniśmy to robić na bieżąco, ale nie zawsze mamy ku temu okazję.

Jak możecie sobie wyobrazić, skrytykowanie czyjegoś zachowania lub sytuacji, w której uczestniczyły osoby z naszego zespołu, nie przychodzi łatwo.

Ja: “Tamta sytuacja, to był jakiś absurd. Kłóciliście się o jakąś zupełną głupotę, a potem wyżywaliście się na reszcie zespołu. Ogarnijcie się.”

Dobry komunikat? Nie do końca. Przecież w związku z tą sytuacją, obudziły się w nas jakieś emocje, coś poczuliśmy. Smutek? Strach? Zaniepokojenie?

Ja: “Tamta sytuacja bardzo mnie zaniepokoiła. Czułem się przez nią niekomfortowo i nie ukrywam, że byłem przez jakiś czas po niej zestresowany. Bardzo prosiłbym was, żebyście spróbowali następnym razem opanować się i rozwiązać kolejny konflikt w spokoju.”

Skupiliśmy się na nas, na naszych odczuciach i ciężko już z tym komukolwiek polemizować. Zakomunikowaliśmy nasze obawy, nikogo przy tym nie urażając. W ten właśnie sposób retrospektywy przebiegają o wiele efektywniej, więcej w nich szczerości, bo nie boimy się już przekazywać trudnych informacji. Również klientowi.

Rada: Szczerze komunikujmy i nie wstydźmy się niepowodzeń. Mówmy o naszych odczuciach.

Oni niczego nie rozumieją

Są, ale tak jakby ich nie było. Ignorujemy ich, udajemy, że ich nie ma. Kogo? Nie-programistów: testerów, grafików, kierowników projektu, Scrum Masterów, klientów. Nie zwracamy na nich uwagi. Trzeci dzień robimy zadanie, które powinno zająć jeden. Dlaczego?

Ja: “Obsługa errorów jest trudniejsza, niż nam się wydawało. Ciągle leci 422 i nie wiedziałem dlaczego — nie było żadnej informacji w dokumentacji API. Poza tym, dołożenie kolejnego zapytania do klasy ApiManager było praktycznie niemożliwe. Musiałem stworzyć osobną klasę, potem okazało się, że jeszcze muszę dziedziczyć po innej, bo taka jest architektura, co jeszcze bardziej skomplikowało kod. Została jeszcze do zrobienia integracja z Firebase.”

Jest to co prawda dość szczegółowy komunikat, ale przeznaczony tylko i wyłącznie dla innego programisty z naszego zespołu. Gdy na spotkaniu są też inne osoby, Scrum Master czy klient, to niczego niestety z niego nie zrozumieją. Na Daily jeszcze byłby do zaakceptowania — przede wszystkim musi się zsynchronizować Development Team. Niestety na spotkaniu z klientem taki komunikat jest nieodpowiedni.

Powinni to rozumieć? Oczywiście, że nie. Mają inne zadania i obowiązki. Nie traktujmy ich z góry. Wytłumaczmy po prostu w czym rzecz w sposób dla nich zrozumiały. To przecież nic wielkiego.

Ja: “Niestety dokumentacja nie była zaktualizowana, co spowodowało, że musieliśmy obsłużyć więcej problematycznych przypadków. Dodatkowo kod był już bardzo przestarzały i musieliśmy go dostosować do nowych funkcjonalności. Do zrobienia pozostała jedynie integracja z serwisem umożliwiającym pokazywanie notyfikacji na ekranie użytkownika.”

Taki komunikat również zaznacza powagę problemów, z którymi musieliśmy się zmierzyć, ale ma tę zaletę, że jest zrozumiały zarówno dla programistów, jak i dla całej reszty zespołu projektowego. Programiści mogą zawsze dopytać o szczegóły po spotkaniu.

Wpadamy w pułapkę wiecznego programistycznego kontekstu, w którym przez większość dnia się znajdujemy. Programujemy i ten język do nas przemawia. Tym językiem porozumiewamy się też z innymi programistami. Mamy z nimi swój slang i swoje skróty myślowe. Gdy musimy zakomunikować coś, co jest bezpośrednio związane z zadaniem, którym się zajmujemy, to w pierwszej chwili chcemy mówić “kodem”, bo tak jest nam łatwiej. Jednakże powinniśmy włożyć nieco wysiłku i zamienić ten komunikat z technicznego, na nietechniczny. Powinniśmy rozejrzeć się po osobach będących na spotkaniu, ustalić wspólny mianownik i w taki sposób budować komunikaty, aby były one dla wszystkich zrozumiałe i na odpowiednim poziomie technicznych szczegółów.

Rada: Nie komplikuj swoich wypowiedzi. Znajdź wspólny mianownik i uogólniaj komunikaty.

Nie wiesz tego?

Jako programiści i osoby techniczne, mamy do czynienia z wieloma osobami, które tej wiedzy nie posiadają. Nasz wizerunek w oczach tych osób niestety nie jest najlepszy. I sami jesteśmy temu winni. Już wyjaśniam.

X: “Nie potrafię zresetować hasła do internetu.”
Ja: “Nie umiesz tego? No dobra, pomogę Ci.”

Niby nic takiego, a jednak daliśmy naszemu rozmówcy do zrozumienia, że trochę wstyd nie wiedzieć tego, o co pyta. Po pierwsze, to nie żaden wstyd czegoś nie wiedzieć, a już na pewno nie spraw jakkolwiek technicznych (choćby w małym stopniu). Po drugie, napiętnowanie drugiej osoby z powodu jej niewiedzy, kompletnie niczego nie zmieniło. I tak zamierzaliśmy jej pomóc. Nawet jeżeli nie było to naszą intencją, postawiliśmy się ponad tą osobą, zawstydziliśmy ją. Nic więc dziwnego, że często jesteśmy postrzegani jako osoby wywyższające się. Wszystko jest przecież łatwe, a nie potrafić tego, to wstyd.

W mojej opinii, z tego właśnie powodu juniorzy, osoby początkujące padają ofiarą nieustannego wstydu na początku swojej kariery.

X: “Nie potrafię zrobić tej animacji. Pomożesz mi?”
Ja: “Nie potrafisz tego? Musisz tylko zmienić to (…) i to (…). Przecież to łatwe.”

Nie da się uczyć w takiej atmosferze. W atmosferze ciągłego wytykania błędów, nawet nieświadomie. W końcu taka osoba przestanie przychodzić po pomoc, a do tego nie powinniśmy dopuścić. Powinniśmy się wykazywać dojrzałością i zrozumieniem. Wskazać drogę. Przyjście po pomoc wiele kosztuje.

X: “Nie potrafię zrobić tej animacji. Pomożesz mi?”
Ja: “Jasne. Rzućmy okiem. Dobra, chyba wiem, o co może chodzić. Widzisz ten fragment? Żeby zaczął działać poprawnie, to musimy jeszcze zmienić to (…) i to (…). Teraz powinno być wszystko w porządku. Też bardzo często popełniałem ten błąd.”

Taki komunikat jest o wiele bardziej ludzki. Osoba potraktowana w ten sposób, przyjdzie do nas znowu i ponownie będziemy mieli okazję przekazać jej wiedzę, a ona dzięki nam będzie się szybciej rozwijać. Swoim przykładem pokażemy jej, jak powinna traktować innych młodych programistów w przyszłości.

Nie chodzi oczywiście tylko o młodszych programistów, czy osoby nietechniczne, ale o każdą osobę, która czegoś nie wie. Takie sytuacje się zdarzają, nic w tym nadzwyczajnego. W projektach z osobami o różnych doświadczeniach, jest to wręcz naturalne. Jeżeli programiście proszącemu o pomoc, będzie wytykana jego niewiedza, to z czasem przestanie o nią prosić. To skutkować może w nierzetelnych dziennych synchronizacjach, Retrospektywach, czy nawet szacowaniach czasu na wykonanie zadań. Nie dopuśćmy do tego.

Rada: Nie oceniaj i nie dziw się zadanemu pytaniu. Po prostu zrozum problem i pomóż.

Podsumowanie

Kod otacza nas z każdej strony. Uwielbiamy programować, tworzyć kolejne bloki systemu, łączyć i podziwiać jego działanie. Jednakże, aby ten system powstał, potrzeba czegoś więcej, niż tylko umiejętność pisania kodu.

Programowanie to praca zespołowa. Nawet gdy jesteśmy zdani sami na siebie, to zawsze jest jeszcze klient czy użytkownik końcowy, z którym współpracujemy. Aby ta współpraca przebiegała pomyślnie, musimy nauczyć się ze sobą komunikować w sposób efektywny.

Dbajmy o to, aby nasze komunikaty nie pozostawiały miejsca na różne interpretacje, aby były pełne. Zatroszczmy się o osobę, z którą nie możemy porozmawiać twarzą w twarz. Pomóżmy jej nas usłyszeć i zobaczyć nasze emocje. Zwracajmy uwagę na zdania, które konstruujemy. Zmiękczajmy je, na ile jesteśmy w stanie. Synchronizujmy w sposób szczery nasze postępy, a na spotkaniach dotyczących zespołu, mówmy otwarcie o tym, co czujemy. Znajdujmy wspólny mianownik dla naszych komunikatów i nie mówmy “kodem” do innych. Niewiedza w naszym zawodzie jest czymś zupełnie naturalnym — nie dziwmy się na zadane pytanie i dajmy z siebie 100% podczas odpowiedzi.

Wszystkie te zmiany w naszej komunikacji przybliżą nas do sprawnego wymieniania się informacjami między nami a naszym zespołem. Już po krótkim czasie praktykowania wymienionych rad, wejdziemy na zupełnie inny poziom w relacjach z programistami oraz innymi osobami z naszego projektu. Możecie mi zaufać 🙂

---

Zdjęcie główne artykułu pochodzi z pexels.com.