Code Review bez przemocy, czyli 5 sposobów empatycznej komunikacji developera

Komunikacja jest jedną najbardziej pożądanych umiejętności. Skoro tak jest to dlaczego nie uczymy jej się w szkole? Niektórzy uważają, że umiejętności komunikacyjne przychodzą naturalnie a inni po prostu twierdzą, że jest trudna. I z tym ostatnim rzeczywiście się zgadzam. I dodałbym coś jeszcze: Komunikacja jest trudna, ponieważ jest prosta. Zawiłe, prawda? Sam doświadczam znaczenia tych słów niemalże codziennie.

Nie ma nic trudnego w przekazywaniu informacji, treści nie zawsze przekazujemy jednak zgodnie z intencjami. Niekiedy blokadą są własne emocje, coś co potocznie nazywamy dumą lub brak pewności swoich kompetencji, albo technicznego lub domenowego słownictwa. Niemniej istotny jest też aktualny stan samopoczucia. Inaczej wyrażamy pewne opinie i zdania, gdy nie znajdujemy się w tym najlepszym dla nas stanie psychicznym.

W relacji z ludźmi w pracy i nie tylko stosuje praktykę wywodzącą się z metody Porozumienie bez Przemocy (w skrócie PBP, ang. Non-Violent Communication) dr Marshalla B. Rosenberga.

Sama nazwa metody już sugeruje, że w większości naszych wypowiedzi pojawia się ta “przemoc”. Są dwa powody dlaczego jest tu zastosowane to konkretne słowo w polskim tłumaczeniu. Po pierwsze, nie znaleziono lepszego i odpowiedniejszego słowa, które miałoby zbliżony charakter znaczeniowy do oryginału. Po drugie, dotyczy to również przemocy psychologicznej, a więc budowania presji, sytuacji i odczuć stresujących, dewastującej krytyki, a nawet dewastujących pochwał, oraz wyrzutów sumienia u naszego odbiorcy.

Co więc mogę zrobić, aby poprawić jakość mojej komunikacji? Oto 5 zasad z tej metody, którymi sam poświadczam o ich skuteczności w działaniu.

1. Rozróżniaj spostrzeżenia od ocen i opinii

Na pierwszy rzut oka wydaje się to jasne. Przecież głównie to robię jako rozmówca: staram się mówić i pisać o faktach. Czy na pewno? Przyjrzyjmy się jednemu przykładowi.

“W tej metodzie panuje bałagan, jedna zmienna jest użyta kilkakrotnie, przez co traci pierwotne znaczenie. Zastosuj więcej zmiennych.”

Zanim przeanalizujemy to zdanie i pójdziemy dalej, zachęcam Cię do wykonania prostego ćwiczenia. Przeczytaj przykład jeszcze raz i spróbuj zgadnąć, czy i gdzie zawiera on ocenę i opinię, a gdzie spostrzeżenie.

Odpowiedź: Tak, zawiera ocenę i opinię.

W podanym przykładzie największym problemem jest słowo-ocena “bałagan”, które może już sugerować, że dany programista jest w pewnym sensie “bałaganiarzem” kodu. Jedną z zasad pozytywnej komunikacji empatycznej PBP jest unikanie określeń, które zwiększają prawdopodobieństwo zrozumienia ich jako krytyki, dalej zwanych ocenami.

Również zdanie nie jest do końca jasne w punkcie “jedna zmienna” ( aczkolwiek może to wynikać z kontekstu o czym dowiemy się później). Dużo precyzyjniej jest wskazać zmienną nazywając ją tak jak w istocie jest przekazana.

W uproszczeniu jeżeli chcemy pomijać ocenę w naszych wypowiedziach, najlepiej stosować metodę “kamery”. Kamera rejestruje dźwięk i wizję i nic poza tym. Nie widać tego, co dzieje się w naszym rozmówcy, możemy tylko zgadywać.

To zdanie, pozbawiając je niejasności i oceny mogłoby brzmieć tak:

“Zmienna x jest przypisana 4 razy do różnych wartości, przez co trudniej mi się czyta. Czy mógłbyś/mogłabyś wprowadzić więcej zmiennych, abym mógł lepiej zrozumieć twoje intencje?”

Ważne, by podmiotem rozmowy w Code Review zawsze był kod a nie programista, a to co jest naszą osobistą opinią rzeczywiście taką były używając na przykład “w mojej opinii”, “wydaje mi się” lub “z tego co wiem”.

Oceny najczęściej są skrótami myślowymi, które zawierają w sobie wiele słów z aktualnego kontekstu. Niestety, wiele razy podczas rozmów, nie upewniamy się czy odbiorca posiada dokładnie taki sam kontekst jak my. Przykładowo wielu dorosłych, którzy uważają że ich lub czyjeś dzieci są “grzeczne”, mają najczęściej na myśli że “są spokojne”. Dla mnie grzeczne dzieci, takie nie muszą być, a z tego co wiem, wielu znakomitych pedagogów uważa, że żywo zachowujące się dzieci są stanem o wiele lepszym.

Chciałbym, aby zrozumiano mnie tu jasno: oceny i opinie nie muszą być złe, jednak rozróżnienie ich ze spostrzeżeniem, pozwala uniknąć niechcianej krytyki. Trzeba więc ich używać rozważnie.

Oferty pracy z

2. Używaj konkretnych wiadomości

Kolejna wskazówka, która w teorii wydaje się bardzo prosta. Natomiast, wiele razy spotkałem się z komunikatami, które względem mnie czy może moich współpracowników, zakładały że odbiorca w pełni rozumie, co do niego mówimy. Nie zauważamy przy tym, że stosujemy słowa ogólnego znaczenia a nam samym wydają się precyzyjne, gdyż znamy ich kontekst.

Eric Evans w książce “Domain driver design” pisze o języku zrozumiałym zarówno dla programistów i projektantów, jak i użytkowników oraz ekspertów domenowych (Ubiquitous Language). Powinien być on precyzyjny i niejednoznaczny. W tej praktyce można zauważyć, że bardzo pomocne są tu liczby (w tym czas i jego przedziały) lub skończone zbiory terminów (na przykład konkretna zasada z akronimu SOLID, S – Single responsibility principle).

Zauważmy, że znacznie jaśniej brzmi “Mamy trzy miesiące na dokończenie projektu” niż “Mamy mnóstwo czasu na dokończenie projektu”. W tym pierwszym przypadku nie mamy oceny czy to rzeczywiście “mnóstwo” czasu na dokończenie projektu w aktualnym stanie, ponieważ dla kogoś innego może to oznaczać stan zupełnie odwrotny.

Warto w tym momencie też pamiętać o unikaniu słów uogólniających “zawsze”, “nigdy”, “często”, “rzadko”, “mało”, “dużo” i podobnych. Zgodnie z poprzednią zasadą są to uogólniające oceny, ponieważ wystarczy, że znajdziemy choć jeden kontrprzykład dla zdania z “zawsze” lub “nigdy” i już traci wiarygodność oraz precyzyjność.

W odniesieniu do Code Review w umieszczanych przez nas komentarzach można się posilić o wskazanie konkretnej metody refaktoryzującej, zamieszczenia linka z wyjaśnieniem lub badaniami benchmarkowymi, dlaczego ta metoda nie jest optymalna, wskazanie konkretnego API lub bibliotek do użycia.

3. Mów/pisz o tym co chcesz, a nie o tym czym nie chcesz

“Nie chciałbym tutaj widzieć tyle zamieszania w kodzie. Dla mnie jest to nieczytelny kod”.

Zdania z “nie” na dobre goszczą w naszym codziennym słownictwie i nawet nie jesteśmy tego świadomi. Pozostaje tylko pytanie, co dokładnie ten developer ma zrobić? Jest wiele sposobów i reguł, które można zastosować aby dany kawałek kodu był czystszy, ale może pisząc lub mówiąc taki komentarz.

Gdy ktoś kieruje do mnie pytanie zawierające słowo “nie”, muszę dwa razy się zastanowić a nawet wykonać pewną woltę myślową, by upewnić się o co chodziło mojemu nadawcy.

Na przykład zamiast “Czy nie lepiej zastosować tutaj wzorzec builder?” po prostu stwierdź “Moim zdaniem lepiej tutaj użyć wzorca builder” lub zapytaj “Czy mógłbyś użyć tutaj wzorca builder?” i podaj konkretne powody.

Choć wygląda to jako trochę naciągana zasada, zdania bez “nie” są odbierane jako bardziej pozytywne, są krótsze i oddają w pełni intencje nadawcy. Zastosowanie tej metody ma podobieństwo w jednej z reguł Clean Code – porównanie w warunku jesteśmy w stanie zrozumieć znacznie szybciej, aniżeli jego negację.

Zobacz też

PM Krytykuj prywatnie, chwal publicznie. O radykalnej szczerości

4. Bądź tu i teraz

To mocno uproszczone stwierdzenie ma na celu wskazać, że nie powinniśmy skupiać się tylko i wyłącznie na widoczne lub słyszanej treści, ale także na intencjach. Język używany w PBP jest językiem dynamicznym, zmieniającym się od sytuacji.

Ale jak to? Przecież wcześniej wspominałem o tym, aby stosować zasadę kamery, a reszta to zgadywanie?

I właśnie o to chodzi, próbuj zgadywać jawnie i to w taki sposób, żeby pokazać że szczerze chcesz zrozumieć tego, który kieruje do Ciebie komunikat. Zgadywanie – nazywane w metodzie parafrazą ma jeden wielki plus – jest pokazaniem naszemu odbiorcy, że rzeczywiście go słuchamy.

Jedna z parafraz mogłaby wtedy brzmieć tak:

“Jeżeli dobrze Cię zrozumiałem, to chcesz zastosować wzorzec Visitor aby móc przechodzić po strukturze drzewa naszej konfiguracji?”

Mógłbym to nazwać metodą fail-fast komunikacji. Lepiej się pomylić szybko, aby nadawca doprecyzował komunikat, gdy widzi jakieś niejasności w naszej interpretacji.

Jeżeli rozmawiasz z kimś bezpośrednio widzisz również jego gesty, reakcje, słyszysz ton głosu, a możliwe że nawet znasz nieco temperament i osobowość rozmówcy. To wszystko ma wpływ na komunikat, który odbieramy i może znacznie go zmieniać. Również nasza kondycja ma wpływ na to jak słuchamy. W złym samopoczuciu możemy słyszeć więcej krytyki i żądań. W takim wypadku polecam szczerze przedstawić swoje emocje w zdaniach typu:

“Przepraszam, ale wstałem dziś bardzo wcześnie z powodu dzieci, ciężko mi się Ciebie słucha, chociaż rzeczywiście chciałbym zrozumieć, z czym do mnie przychodzisz. Może spróbujmy jeszcze raz za godzinę na porannej kawie?”

W wiadomościach commit git do Code Review niekiedy dopisuje przy zmianach, które opisuje, pole REASON, aby tam je wyjaśnić i uzasadnić. Pozwala to na określenie obecnego kontekstu danej zmiany, która może się przedawnić w przyszłości, jednak zwraca uwagę na kryteria podanej decyzji. To pozwala łatwiej podejmować decyzje i osądzać kolejne zmiany w przyszłości, jednocześnie dokumentując kod w systemie kontroli wersji.

5. Sprawdzaj jak zostałeś zrozumiany

Trochę odwrotność poprzedniej zasady – jesteś nadawcą i sprawdzasz czy Twój komunikat został otrzymany tak jak zamierzałeś. Są momenty, gdy zakładamy, że wszystko powinno być oczywiste i zrozumiałe. Nie spostrzegamy jednak, że są sytuacje, kiedy jesteśmy interpretowani zupełnie inaczej niż zamierzaliśmy. Powodem są tu nieświadome aspekty komunikatu, tak wspomniałem wcześniej, mogące mieć odzwierciedlenie w naszym samopoczuciu, kondycji fizycznej, czy obecnie towarzyszących emocji.

Nie chcemy, aby w naszej przekazywanej informacji pojawiały się zakłócenia w interpretacji, trafiając do odbiorcy w taki sposób, by ujednolicić kontekst wypowiedzi. Spróbuj więc po przekazaniu istotnych informacji oznajmić i zapytać:

“Bardzo zależy mi na dokładnym i spójnym zrozumieniu tego rozwiązania w naszym projekcie. Czy mógłbyś mi opowiedzieć swoimi słowami, jak mnie zrozumiałeś, abym miał pewność, że przekazałem wszystko w sposób jasny i klarowny”?

Prolog

Wszystkie powyższe zasady są na tyle ogólne, że można je stosować w każdej możliwej rozmowie. Warto wiedzieć, że aby te zasady były skuteczne i żywe, trzeba wprowadzić je w codzienny nawyk.

Sam autor tej metody wszakże wiele razy mówił: “Jedynym sposobem, by nauczyć się PBP, jest ćwiczenie, ćwiczenie i jeszcze raz ćwiczenie”.

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