Cały przebieg tego wątku jest bardzo przykry. Nikt nie jest doskonały i wszyscy popełniamy błędy. Nie inaczej było w tym przypadku.
Na pewno niejeden z nas pamięta, jak poczuł się urażony lub zrobiło mu się przykro, gdy jego kod został skrytykowany. Przyjmowanie krytyki jest bardzo trudne, zwłaszcza że, nie ma co ukrywać, podchodzimy emocjonalnie do tego co robimy (kod to coś nad czym ciężko pracowaliśmy, niekiedy po godzinach i jeszcze spędziliśmy trochę czasu, aby to dopieścić). Mimo to, uwielbiamy oceniać innych i wytykać im błędy - nasze ego szybuje coraz wyżej z każdym znalezionym uchybieniem. Ta sprzeczność powoduje konflikty i właśnie w tym miejscu potrzebny jest dobry lider. Dobry, czyli nie tylko taki, który zna doskonale zagadnienia techniczne, ale też taki, który jest w stanie sprawić, aby review nie skupiało się wyłącznie na negatywach i żeby uwagi były przekazywane w odpowiedni sposób. Jeśli wszyscy reviewerzy zaczynają agresywną krytykę, to osobie reviuowanej automatycznie załącza się odruch obronny. Tak pewnie było i w tym przypadku. To lider decyduje o tym jak te spotkania wyglądają. Nawet jeśli było wiele błędów, to można dać na koniec feedback, że mimo tego, że trochę rzeczy jest do poprawy, to całość była bardzo fajna albo że zastosowanie czegoś było pomysłowe. Jeśli się tego nie zrobi, to wówczas ten ktoś wraca do biurka przybity i pełen negatywnych emocji. Taki jeden komentarz na koniec może całkowicie zmienić odbiór całego review.
A teraz przeanalizujmy co się stało. 5 osób rzuciło się na jedną. Pokłócili się o definy (czy uwagi były słuszne czy nie - nie oceniam, nie zawsze opinia większości jest słuszna). Wszyscy zdenerwowani. Przykro mi, że to powiem, ale to Twoja porażka (ale i cenna nauka na przyszłość!). Pozwoliłeś, by błahostka doprowadziła do konfliktu w zespole. Powinieneś być pierwszym, który załagodzi sytuację. Pozwoliłeś, by problem był eskalowany powyżej. Czy project managera albo właściciela firmy obchodzą takie szczegóły jak używanie magic numberów? Nazywania swojego podopiecznego "głąbem" nawet nie skomentuję. Zwalnianie się z tego powodu też będzie porażką i będzie dowodem tego, że jednak pozycja lidera została Ci przyznana niesłusznie. Przekonywanie kogoś na siłę do swoich racji też uważam bez sensu. U niego teraz działa mechanizm obronny.
Co oprócz powyższych rad można zrobić, aby ustrzec się takich sytuacji w przyszłości?
-
Napisać wspólnie coding standard - Wasz własny, którego będziecie się trzymać. Wtedy jeśli argumenty rzeczowe nie działają i ktoś jest mocno oporny, to można mu powiedzieć, że Wasz coding standard tak przewiduje.
-
Podsumowując spotkanie powiedzieć, że oczekujesz, że wspólnie ustalone zmiany zostaną zastosowane. Jeśli jest opór, to mówisz wprost, że nie zezwalasz na wrzucanie tych zmian, ponieważ review jest odrzucone. Jednak to ostateczność i jeśli zadbasz o odpowiednią atmosferę, to nie powinieneś mieć tego problemu.
Co proponuję Tobie zrobić w sytuacji, w której się znalazłeś?
-
Porozmawiać 1:1 z tym developerem, że być może obaj popełniliście błędy (jeśli oczywiście po tym, co napisałem też tak czujesz) i warto zacząć od nowa. Jak atmosfera się rozluźni zaproponuj jakieś spotkanie 1:1 lub z całym zespołem o tych magic numberach, jednak uprzedź resztę zespołu, jaki charakter ma mieć to spotkanie.
-
Porozmawiać 1:1 z managerem / właścicielem, który podważył twoją decyzję, aby tego więcej nie robił. Tylko uprzedzam, że powinno to być zrobione na spokojnie, żeby nie było kolejnego konfliktu.
-
Na pewno nie próbować się mścić. Co było, minęło i trzeba żyć dalej. Najlepiej w dobrej atmosferze. Sukcesy Twoich podopiecznych to Twoje sukcesy.