Jak napominać programistę

Dzisiaj w kościele czytania o napominaniu. Główna interpretacja dotyczy oczywiście kwestii religijnych i etycznych ale problem dotyka całkiem mocno i mojego zawodu.

Jak powiedzieć programiście, że wybrał złe rozwiązanie, zajmuje się nie tym co trzeba, nie przestrzega zasad obowiązujących w projekcie, zapóźnia się z elementem na który wiele osób czeka, pisze niezrozumiałe dokumenty, oddaje nieprzetestowany kod, albo odwala jakąś inną kichę? Upominanie nigdy nie jest łatwe, a w tym zawodzie - gdzie wielu ludzi niepokornych, o silnym ego i dużej ambicji - tym trudniejsze.

Zasada trzech kroków

Biblijny fragment jest całkiem fajną - i szczegółową - wskazówką praktyczną:

Gdy brat twój zgrzeszy, idź i upomnij go w cztery oczy. Jeśli cię usłucha, pozyskasz swego brata. Jeśli zaś nie usłucha, weź z sobą jeszcze jednego albo dwóch, żeby na słowie dwóch albo trzech świadków oparła się cała sprawa. Jeśli i tych nie usłucha, donieś Kościołowi! A jeśli nawet Kościoła nie usłucha, niech ci będzie jak poganin i celnik!

W transkrypcji na sytuacje projektowe:

• najpierw porozmawiaj w cztery oczy, możesz w ten sposób rozwiązać problem, udzielić wsparcia, a nawet zyskać przychylność danej osoby
• jeśli to nie pomoże, włącz w problem kogoś jeszcze - najlepiej kogoś mającego naturalny autorytet w grupie,
• gdy i to nie zadziała - szukaj rozwiązań formalnych (od interwencji u szefa projektu po pisemne uregulowania),
• a jeśli nawet to nie pomoże, unikaj współpracy z daną osobą, staraj się mieć z nią jak najmniej wspólnego (ten poganin i celnik z grubsza to właśnie oznacza, Żyd stawał się nieczysty, jeśli kogoś takiego odwiedził, czy wymienił z nim uścisk - stąd min. Piłat wychodzący na zewnątrz).

Mądrość tych zasad widać zwłaszcza, gdy się zauważy jakie zachowania - często spotykane, nieskuteczne i bardzo psujące atmosferę - wykluczają.

Po pierwsze, nie ma tu obmowy - sytuacji, gdy o tym iż Kazio nigdy nic nie testuje, Paweł od dwóch miesięcy pracuje w tempie wiersza kodu dziennie, a Stefan arogancko ignoruje wszelkie pytania i prośby o pomoc, rozmawia cały zespół z wyjątkiem głównych zainteresowanych. Tego typu ploty są bardzo kuszące - pozwalają poczuć się lepszym od zawalającego robotę współpracownika i zwalić na niego winę za trudności w projekcie (jedno i drugie miłe dla rozbudzonego ego) - ale totalnie niekonstruktywne. Za to bardzo skuteczne w rozbijaniu poczucia solidarności w zespole i psuciu atmosfery.

Po drugie, nie ma tu pyskówki w dużym gronie (albo - przed dużym gronem). Popularna sytuacja - jakiś problem nabrzmiał do poziomu, w którym nie da się już go po cichu tolerować i wybucha na spotkaniu całego zespołu w formie kłótni. Albo ktoś publikuje ostrą krytykę na firmowych forach dyskusyjnych (czy - przy projektach otwartych - w internecie), po czym trwa tasiemcowy flame-war. Częstym wynikiem jest demonstracyjne porzucenie projektu przez którąś ze stron, a gdy to niemożliwe, klincz rozwiązywany siłą i permanentnie zepsuta atmosfera.

Po trzecie, ignorowanie problemu i unikanie stwarzającej go osoby jest ostatecznością, a nie domyślnym rozwiązaniem obieranym przez spokojniejszych lub mniej śmiałych pracowników.

Po czwarte, odwołanie do formalnego autorytetu następuje dość późno i w momencie, gdy problem ma już szanse być stosunkowo dobrze zdefiniowany. Pamiętajmy, że w projektach informatycznych przełożeni często nie mają szans podejmować w pełni kompetentnych decyzji, zwłaszcza technicznych.

Anegdotka - jak najbardziej pozytywna - z Microsoftu (cytuję za Joelem Spolskym):

Dwóch projektantów nie mogło uzgodnić sposobu implementacji jakiegoś komponentu. Decyzja była ściśle techniczna. Udali się do swojego szefa - był to niejaki Mike Maples, zastępca kierownika działu rozwoju aplikacji..

A co ja wiem na ten temat? - krzyknął na nich. Z trzech ludzi w tym pokoju, ja wiem najmniej. Zajmujecie się tą sprawą od wielu godzin, a ja od minuty. Jestem ostatnią osobą do podjęcia tej decyzji. Znajdźcie rozwiązanie!

Zrobili to.

Czy zasada trzech kroków działa? Cóż, nie zawsze. Ale na pewno daje radykalnie większe szanse powodzenia niż odruchowe zachowania, a nawet gdy zostanie wyczerpana bez skutku, jest mniej rujnująca od powyższych scenariuszy. Czy da się ją narzucić? Wątpię. Ale można ją propagować i ... stosować samemu.

Treść

W chrześcijaństwie mówi się, by potępiać uczynki, a nie człowieka. Specjaliści od asertywności uczą o koncentrowaniu się na faktach i nie wchodzeniu w strefę wewnętrzną drugiej osoby. Jedno i drugie prowadzi do tego samego i daje się łatwo objaśnić na przykładzie. Wyobraź sobie swoją reakcję na każdą z poniższych wypowiedzi:

Lewy wariant w większości wypadków prowadzi do kontragresji i kłótni, w pozostałych (istotna przewaga - formalna lub psychologiczna - mówiącego nad odbiorcą) do jakiejś formy wycofania się i strachu (zresztą - bez prób rozwiązania problemu). Prawy jest oczywiście nieprzyjemny, ale daje szansę na konstruktywną rozmowę i nie prowokuje konfliktu.

Kluczową różnicą wcale nie są ewentualne epitety czy ton wypowiedzi. Lewy rozmówca koncentruje się na przypisywaniu słuchaczowi jakichś myśli, planów i emocji - o których zresztą nie ma (bo nie może mieć) pojęcia - czym gwałci jego prywatną strefę mentalną i jednoznacznie ustawia się w pozycji agresora. Prawy rozmówca przedstawia fakty i swoje własne uczucia czy obawy. Nie ma tu niczego, co stanowiłoby atak.

Bardzo szczegółowo tę tematykę omawia się na kursach asertywności czy w poświęconych jej książkach. Trochę bywa w tym wszystkim przesady (jak w każdej dziedzinie, która robi się modna, a na doczepkę daje się sprzedawać biznesowi), ale podstawowy model interakcji międzyludzkich jest bardzo udany i wart poznania. W szczególności, jednodniowy kurs miękkich technik może być dużo lepszą inwestycją dla firmy, niż kolejne szkolenie z Javy czy UML. Z osobami, z którymi tego typu kurs wspólnie przeszedłem, dużo lepiej mi się obecnie współpracuje.

Nawet w pozytywnym wariancie czegoś jeszcze brakuje. Konkretnej informacji, czego oczekuje mówiący. Czegoś, do czego przyjmująca krytykę osoba może się odnieść - akceptując wymaganie albo, gdy to niemożliwe, podejmując negocjacje. Na przykład zdania dostarcz mi ten dokument najpóźniej jutro o 16. Taki zwrot dowodzi, że celem rozmowy jest rozwiązanie problemu, a nie np. udowodnienie słuchającemu niekompetencji.

To już pełna zasada asertywnej krytyki, tzw. FUO (fakty - ustosunkowanie - oczekiwania). Bardzo użyteczny schemat wypowiedzi.

Dorzucę jeszcze, że temat nie dotyczy wyłącznie ustnych dyskusji. Email, a nawet zgłoszenie błędu, także można napisać konstruktywnie i w sposób ukierunkowany na rozwiązanie problemu, albo destrukcyjnie, prowokując konflikt.

Forma

Firma w której pracuję wyrosła na bazie grupy dobrze znających się, częściowo zaprzyjaźnionych, ludzi. Jedną z konsekwencji jest brak formalizmu wypowiedzi. Na zdanie typu Marcin, ty baranie, znowu rozwaliłeś build, chodź zobacz odpowiada się Skretyniałeś? Nie mam teraz czasu na głupoty, zgłoś buga i wszyscy są zadowoleni, traktując to jako swoistą konwencję.

To znaczy, myślałem, że wszyscy. Byłem dość mocno zszokowany dowiedziawszy się, że dla sporej grupy młodszych pracowników (stażem, niekoniecznie wiekiem) ten styl jest ogromnie konfudujący (gdy widzą go w użyciu przez innych) i obraźliwy (gdy zostanie skierowany do nich bezpośrednio). A niektórzy mieli problemy nawet z zwracaniem się do starszych po imieniu.

Czy i kto

Jak już wyżej pisałem, formalne kierownictwo firmy czy projektu ma często - z konieczności - ograniczoną wiedzę. Nie tylko techniczną, także dotyczącą detali funkcjonalności, szczegółowych uzgodnień z klientem, losu wybranych dokumentów. Po prostu, tematów i zagadnień jest zbyt wiele, by jeden człowiek (czy nawet grupa osób) - obarczony na dodatek chmarą obowiązków organizacyjnych, kontraktowych czy politycznych - miał szanse je wszystkie śledzić (nie mówiąc już o kreatywnej analizie). Efekt? Gdy jakiś problem staje się widoczny dla managementu, najczęściej jest już za późno na sensowne rozwiązanie. Owszem, coś co miało trwać trzy miesiące trwa już pięć, końca nie widać a do tego zespół nie może się dogadać. Dobry stan, by skasować projekt.

Dlatego o problemach trzeba rozmawiać na dole. W małych zespołach, między kolegami z pokoju. Zauważać drobne negatywne symptomy i nie bać się o nich mówić. Zgodnie z zasadą trzech kroków, używając FUO, rozważnie dobierając formy. Ale mówić.

Zacząłem od biblijnego cytatu, więc takowym też skończę (zresztą, także dzisiejszym czytaniem, tym razem starotestamentalny Ezechiel):

Jeśli (...) nic nie mówisz, by występnego sprowadzić z jego drogi - to on umrze z powodu swej przewiny, ale odpowiedzialnością za jego śmierć obarczę ciebie.

W mniej groźnej transkrypcji: widzisz, że kolega nie radzi sobie ze swoim zadaniem - i nic nie mówisz? On poniesie konsekwencje, ale za upadek projektu odpowiadasz Ty.

Nie, nie jest łatwo. Nie, nie jestem zadowolony z tego, jak mi samemu to wychodzi (tak jako autorowi krytyki, jak jako ją przyjmującemu). Ale chcę próbować. Bo nie pracuję na sztukę...