Rozwiązujemy nieznany problem

Częstym, niezwykle demotywującym zachowaniem jest rozwiązywanie problemów przez przełożonych. Modne od jakiegoś czasu sesje "rozwiązywania problemów" (problem-solving) w swojej idei bardzo słuszne, są nieprawdopodobnie niszczone, w efekcie mając dokładnie odwrotny skutek od zamierzonego. Wyobraźmy sobie sponsora projektu, uczestniczącego w sporadycznych komitetach sterujących, który rozpoczyna spotkanie: "No to, jaki wy tam macie problem?" albo, co gorsza, dla menedżera "zaangażowanego", który na siłę próbuje rozwiązać problem, który nie został w najmniejszym stopniu zdefiniowany. Spotkania "rozwiązywania problemów" są ryzykowne, ale w przypadku powodzenia mają bardzo pozytywny wpływ na zespół i są dobrą techniką angażowania ludzi w realizację projektu. Skuteczną techniką jest organizowanie takich spotkań jako wyniku planowych (cyklicznych) spotkań poświęconych zarządzaniu ryzykiem, na których identyfikuje się konkretne zagrożenia oraz metody zarządzania nimi (uruchomienie takiej sesji, jak i jej wyniki, winny być załącznikami w oficjalnym rejestrze ryzyka projektowego).

Konflikt musi być

Konflikt w projekcie jest naturalny i pożądany, ścieranie się różnych zdań i postaw jest z reguły twórcze i korzystne dla przedsięwzięcia. Kłopot zaczyna się wtedy, gdy konflikty przeradzają się w personalne. Można powiedzieć, że świadczy to o nieprofesjonalnej postawie i z pewnością jest w tym wiele racji. Oczywiście umiejętność rozdzielenia spięć w pracy od szacunku osobistego dla drugiej osoby jest kluczową cechą dobrego menedżera, jeżeli zaczynamy kogoś nie lubić i zwalczać jedynie z tego powodu, należy się dobrze nad sobą zastanowić (dobrze, jeśli przynajmniej mamy tego świadomość).

Niezależnie od profesjonalizmu, istnieje inny kłopot dotyczący konfliktów. Każdy z nas ma swoją tolerancję i w momencie gdy mamy do czynienia z kondensacją problemów, konflikty stają się destrukcyjne. Taki przypadek jest zazwyczaj oznaką chaotycznego zarządzania, przeładowania zadaniami czy braku zarządzania ryzykiem. Tak więc silniejsze tarcia w zespole powinny być podstawą do przeglądu np. harmonogramu prac (a nie tylko próby załagodzenia sytuacji) - leczmy przyczyny, nie objawy.

Słyszałem, że będzie zmiana...

Plotka jest jedną z przypadłości ludzkich, jaka jest w stanie zająć ciężko pracujący zespół i skutecznie zredukować jego wydajność niemal do zera. Każdy członek zespołu powinien być szczególnie wyczulony na pojawienie się tego typu zjawiska (dotyczy to wszystkich bez wyjątku!). Plotkę należy bez chwili zastanowienia konfrontować i wyjaśniać publicznie (nie ma znaczenia, do kogo dotarła, z jednej strony nigdy nie mamy pewności, a z drugiej jest to przykład działania na przyszłość). Nie należy nigdy podawać źródła, skąd o plotce się dowiedzieliśmy (przecież ktoś miał dobre intencje i chciał nam coś powiedzieć w zaufaniu). Piszmy po prostu list do właściwego menedżera z kopią do wszystkich o treści np.: "Pojawiła się plotka, informuję całe (...), proszę o potwierdzenie lub zdementowanie. Na przyszłość wszystkich proszę o przestrzeganie przyjętej w projekcie formy komunikacji, jaką jest cotygodniowe spotkanie zespołu oraz o precyzyjne przekazywanie informacji, tak aby unikać domysłów i spekulacji".

Mój przełożony to...

... i tu w zależności od osoby, jej stanu ducha i elokwencji pojawiają się określenia o bardzo zróżnicowanym zabarwieniu. Idealnym uzupełnieniem powinno być "członek naszego zespołu", jednak w rzeczywistości takie postrzeganie nie jest częste. Problem wielokrotnie ma źródło w niezrozumieniu roli zarządzającego (aczkolwiek wadliwych postaw tych ludzi też niestety nie da się wykluczyć). Z praktyki mogę polecić myślenie: "Dziś on jest szefem, jutro mogę być nim ja". Osobiście miałem to szczęście doświadczyć tego wielokrotnie (w tym również kilkakrotnie z tą samą osobą w różnych konfiguracjach). Polecam tę technikę wszystkim menedżerom ustalającym role w zespole projektowym. Trzeba mieć okazję, żeby nauczyć się zarówno zarządzać, jak i być zarządzanym.

Jeszcze jedna ważna zasada dla szefa zespołu - donosicieli należy grzebać, zanim zdążą przekazać to, z czym przyszli. Osobom, którym wydaje się, że tą drogą osiągną swój cel, z pewnością w dłuższej perspektywie nie wystarczy donoszenie tylko nam. Pamiętajmy, że jest to choroba zakaźna, która bardzo nie tylko nam.

Chciałem przez to powiedzieć, że...

Komunikacja, szczególnie w dużych zespołach, jest podstawą zarządzania. Aby jednak tak się działo, nie wystarczy, aby zarząd projektu informował o stanie projektu i kolejnych zadaniach, a pracownicy składali kolejne raporty. Umiejętność komunikowania się jest kompetencją bardzo często zapominaną. Znane mi są przypadki, gdy bardzo sprawny programista potrafiący realizować w zawrotnym tempie pokaźne funkcjonalności w "swoim języku", męczy się kilka godzin nad kilkunastowersowym mailem (nie jest to przypadłość jedynie programistów! - nawet analitycy mają z tym czasem problem). Do szefa zespołu należy upewnienie się, czy powyższe zagadnienie nie jest problemem i ewentualnie pomoc w nabyciu tej kompetencji. Można to osiągnąć np. poprzez wyznaczanie kolejnych członków zespołu do udokumentowania cyklicznego spotkania. Konieczne jest oczywiście opracowanie najprostszego szablonu zawierającego przykładowo informacje: lista uczestników, stan realizacji zadań uzgodnionych na poprzednim spotkaniu, tematy poruszone na spotkaniu, wnioski, zadania, terminy i odpowiedzialni za realizację postanowień itd.

Komunikacja w projekcie zachodzi oczywiście na wiele sposobów (w tym wspomniane wcześniej plotki), natomiast ze względów praktycznych trzeba w pierwszej kolejności zadbać o formę pisaną. Niechęć do (czy po prostu nieumiejętność) przelewania swoich myśli w formę pisaną skutkuje bardzo często zawieraniem ustaleń ustnych, które są często zapamiętywane odmiennie przez dwie strony, co prowadzi do niemałych konfliktów.

W prawidłowo prowadzonym projekcie wszystkie założenia, ustalenia, decyzje itp. winny zostać udokumentowane. Konieczne jest zatem, aby wszyscy uczestnicy projektu potrafili to sprawnie zrobić.

Opadłem ciężko na fotel. Kolejny projekt zamknięty. Drżącymi jeszcze rękoma nabiłem fajkę i zaciągnąłem się markowym tytoniem. Moje myśli, w brew świadomej chęci, nie chciały odkleić się od wydarzeń ostatnich tygodni. "I tak delikatnie się skończyło" pomyślałem. Na początku przecież poszła fama, że jestem agentem-likwidatorem projektu, a moim jedynym zadaniem jest wskazanie ludzi do odstrzału. No trochę odstrzeliłem, ale wiadomo, siła wyższa, czasem tak trzeba... dobrze, że z IT i finansami udało się mimo to w końcu dogadać. Jak chłopaki z IT poszli na szkolenia, o które zabiegali od roku, od razu robota dała się zrobić, a jak finanse wreszcie pozbyły się tych bzdurnych ręcznych raportów, to też jakoś zaraz czas się znalazł. Od Zarządu jak zwykle dostałem uścisk dłoni odciśnięty w betonie... ale z drugiej strony premia też była słuszna. Niepokoi mnie tylko, jak ostatnio patrzą na mnie chłopaki z IT, podobno mają jakąś potworną wpadkę dla HR... Nazywam się Tomek, Tomek Norman i proszę nie starajcie się tego zapamiętać.