Moje błędy podczas zarządzania projektami – właściwe zadania, właściwym osobom

To kolejny wpis z serii #spowiedź, w którym opisuję błędy, które popełniłem podczas nauki zarządzania projektami – wszystko po to żebyście mogli uczyć się na moich błędach (zamiast na swoich). W tym wpisie poruszam kwestię zarządzania zespołem i przydzielania zadań do programistów.

W poprzednim wpisie poruszałem kwestię nadgorliwości, w tym kolei na zarządzanie zespołem. Zarządzanie ludźmi uważam, za trudny temat. Często w zespołach trafiają się specyficzne indywidualności, z którymi musimy sobie poradzić tak, żeby każdy z zespołu był wygranym (tzw win:win). Moim zdaniem, do dobrego zarządzania zespołem jest potrzebna umiejętność, którą ja nazywam „czytaniem ludzi”. Niestety nie da się jej nauczyć z książek – trzeba się z nią urodzić, albo wypracować na „żywym organizmie” jakim jest zespół. Ciekawe jest to, że myślałem, że dość dobrze mam rozwiniętą tą umiejętność – dopóki nie dostałem swojego pierwszego zespołu, którym kierowałem.

Ja osobiście uwielbiam rywalizację i wyzwania – uwielbiam działać w ten sposób, działa to na mnie motywująco i podnosi moją satysfakcję z wykonywanej pracy. Jeśli dostawałem zadanie, które przewyższa moje kompetencje – nie narzekałem na to, tylko starałem się dorównać w górę i wykonać je najlepiej jak potrafię. Problem w tym, że trochę czasu zajęło mi nim zrozumiałem, że nie wszyscy działają w ten sposób. Było to powodem do wielu rozczarowań, zgrzytów, opóźnień i stresu.

Zdarzało się, że przypisywałem developerom zadania, na które nie byli gotowi lub kompetentni. Byłem przekonany, że jeśli dam programiście zadanie, które przewyższa jego kompetencje – będzie on musiał zgłębić wiedzę by je ukończyć, dzięki czemu się rozwinie. Gdyby ktoś mną zarządzał w ten sposób – prawdopodobnie osiągnął by zamierzany efekt. Jednak nie wszyscy działają takimi metodami – jest spore grono ludzi, które nie lubi wyzwań i rywalizacji. Zdecydowanie bardziej wolą rozwiązywać zadania, w których czują się ekspertami, a rozwijają się tylko w tzw piaskownicy – gdzie nie ma lęku ani presji przed zepsuciem projektu lub niewykonaniem zadania. Nie mówię, że to wada – to po prostu cecha, każdy jest indywidualny. Teraz to wiem, wtedy jednak nie potrafiłem na tyle dobrze „czytać ludzi” by poznać jaki ktoś ma charakter i w jaki sposób pracuję. „Męczyłem” programistów zadaniami, w których czują dyskomfort – a ja byłem szczerze zdziwiony, że nie osiągam zamierzonego efektu. Trudno było mi zrozumieć, że są inne sposoby działania, a mój nie jest jedynym słusznym. Ludzie są różni, każdy potrafi być skutecznym jeśli się nim właściwie pokieruje. Doskonale oddaje to poniższy rysunek.

Nawet najlepsza z ryb nie będzie tak dobrą małpą, jak najgorsza z małp. Działa to również w drugą stronę – żadna małpa nie będzie lepszą rybą od żadnej z ryb. Analogicznie jest z zespołem – należy dać właściwe zadania, właściwym osobom. Zamiast rozwijającego się zespołu otrzymałem spadek produktywności, coraz wolniej schodzące zadania z backlogu oraz „gęstą” atmosferę w zespole.

Podsumowanie

Prawdziwą sztuką zarządzania zespołem jest to, żeby dać właściwym osobom właściwe zadania. Nie każdy nadaje się do wszystkiego – nie warto przebijać muru głową. Zdecydowanie lepiej jest dopasować zadania do developerów, niż developerów do zadań 😉 Zdaję sobie sprawę, że nie zawsze mamy ten komfort żeby tak było, ale jeśli mamy to warto z niego skorzystać.