Zarządzanie zespołem – wywiad z Project Managerem

Michale, od wielu lat zarządzasz zespołami z branży IT. To trudna branża, dla wielu ludzi zupełnie abstrakcyjna. Jak to jest, że niektórzy są zarówno świetnymi specjalistami i jednocześnie menedżerami?

Zarządzając różnymi zespołami zgromadziłem własne doświadczenie jako „lessons learned”.

Zacznijmy od hydraulika. Przypadkiem trafiłem na rewelacyjnego fachowca, wszystko zostało zrobione w terminie, bez zbędnego brudu, na czas i co dziwne w kwocie, na którą się umówiliśmy. Pod koniec pracy jak już się hydraulik pakował pytam: czemu pan nie rozszerzy działalności? Czemu pracuje pan sam, brakuje takich firm na rynku.

Usłyszałem w odpowiedzi, że ten etap ma już za sobą, miał kilkunastoosobową firmę, realizował równolegle dwa / trzy zlecenia. Czara goryczy się przelała, kiedy robił zlecenie dla bogatych ludzi, duży dom, w salonie specjalne płytki… Pyta się pracownika, czy zrobił próbę ciśnieniową, odpowiedź pada, że tak, no to się spakowali, i pojechali.

Za dwa tygodnie byli z powrotem, bo się okazało, że cieknie i trzeba było skuwać kafelki na własny koszt. Nie wytrzymał ludzi zwolnił, woli sam odpowiadać przed klientem.

Osoby, które są kierownikami, bądź właścicielami małej firmy znają takie sytuacje z autopsji. Szlag człowieka trafia, tyra na reputacje firmy, ciężko pracuje i zostaje wystawiony do wiatru przez własnego „lojalnego” pracownika.

To jaka jest w zasadzie różnica pomiędzy menadżerem, a kierownikiem projektu?

Rola menadżera liniowego i kierownika projektu często się przenika, szczególnie w małej firmie. O kierowaniu napisano już bardzo dużo, są osobne specjalizacje na wielu uczelniach wyższych, można więc powiedzieć, że wiedza leży na ziemi (tak w Internecie jak i w klasycznym wydaniu np., Kierowanie Stonera), wystarczy się schylić by ją podnieść. Jednak moje doświadczenie wskazuje na to, że jest to raczej sztuka niż ścisła dziedzina, gdzie 2+2 zawsze jest równe 4.

Czemu tak jest pomoże zrozumieć jedna z definicji kierowania wg Stonera: kierowanie polega na pracy w ramach i za pośrednictwem stosunków między ludźmi.

A ludzie są różni, mają lepszy / gorszy dzień, są / nie są zmotywowani, mają odpowiednią wiedzę / kompetencje, etc. W podobnych sytuacjach zachowują się bardzo różnie.

Albert Eistein powiedział: „Szaleństwem jest robić wciąż to samo i oczekiwać różnych rezultatów” małe dziecko nie zna tego cytatu, i dobrze, bo nigdy by się nie nauczyło chodzić, wstaje przewraca się, i tak w kółko …

Z historii o hydrauliku można wyciągnąć wniosek zgodnie z teorią X i Y McGregora. W tym przypadku pracownik reprezentuje typowego X czyli nie lubi pracować. Tu rozwiązania innego typu niż stałe sprawdzanie i monitorowanie postępów nie znam. I wniosek hydraulika z początku jest słuszny, skoro wszystko i tak trzeba zrobić samemu to czemu mam jeszcze komuś za to dodatkowo płacić? Albo systematycznie rozbudowywać system kontroli i monitoringu pracy. Jako kolejny truizm podam zasadę, pokażcie mi system, a powiem wam jak się człowiek zacznie w tym systemie zachowywać; co dziwne kreatywność ludzi w dążeniu do obchodzenia takiego systemu jest praktycznie nieograniczona …

Kierownik projektu też pracuje z ludźmi, jeżeli jest to wydzielona funkcja musi zdobyć „zasoby” od kierownika liniowego, a następnie zmotywować ludzi w trakcie trwania projektu do realizacji poszczególnych zadań. W takim przypadku nie decyduje on o np. urlopach czy podwyżkach, więc zakres możliwości ma uboższy. Również tu można zdobyć dużo wiedzy czy na studiach, czy w formie elektronicznej. Czy jest narażony na omówioną wcześniej próbę ciśnieniową? W określonych warunkach tak.

Kierownicy muszą mierzyć się nie tylko z powierzonym zadaniem, ale przede wszystkim z całą dynamiką zespołu ludzi. Jakie są twoje doświadczenia w prowadzeniu teamu do celu?

Kierowałem różnymi zespołami, dopiero takimi które się formują, przejmowałem zespół kierownika, który był bardzo zżyty z zespołem, zwalniałem pracowników, ponieważ nie grali zespołowo.

Do każdego z tych zespołów trzeba było podejść inaczej, ludzie oczekiwali i cenili inne działania, co innego ich motywowało. Jedno co łączyło te sytuacje to konieczność ciągłej dobrej komunikacji, rozmowy z ludźmi. Przy okazji dając feedback motywuje się pracowników. Odkryłem też, że w zarządzaniu bardzo ważne jest etyczne postępowanie z ludźmi: manipulacja ma bardzo krótkie nogi.

Niestety techniki manipulacji są bardzo popularne na studiach i kursach menadżerskich. Pomijając kwestie etyczne i skuteczność, czy da się to zrobić inaczej?

Kierowanie cały czas się rozwija pojawiają się nowe pomysły, ktoś kiedyś przy okazji projektu Apollo stwierdził, że wymagane jest szczególne podejście do tego zadania i w ten sposób pojawiła się nowa dziedzina jakim w latach 70 było zarządzanie projektami (niektórzy sięgają aż do projektu Manhattan). Dziedzina ta tak jak i samo kierowanie ewaluowała i się rozwijała w kolejnych latach powstał Agile oraz zanana w świecie IT podejście DevOps’owe (development czyli metodyka zespolenia rozwoju oraz eksploatacji i utrzymania jakości – przyp.red.).

W przypadku bardzo kompetentnych zespołów IT odkryłem, że intrygującym podejściem do kierowania jest bycie swego rodzaju „Scrum Masterem”. Chodzi mi tutaj głównie o usuwanie przeszkód, które uniemożliwiają zespołowi skuteczną pracę. Podejście to znajduje zastosowanie tylko w przypadku dojrzałych i kompetentnych zespołów, gdzie ludzie są nastawieni na cel i zmotywowani by go osiągnąć.

Niestety w bardziej kompetentnych zespołach technicznych daje o sobie znać problem opisany przez Model Tuckmana. Dzieje się tak ponieważ fachowcy zdają sobie sprawę, że wiedza daje im swoistego rodzaju władzę, którą niechętnie się dzielą. To ja wiem co i jak zrobić, to ja mam doświadczenie, a reszta ma mnie słuchać i robić tak jak każę. W przypadku, kiedy parę takich osób po raz pierwszy się spotyka trudno jest im rozpocząć współpracę. Tu trzeba działać intuicyjnie, czasem trzeba pozwolić się konfliktowi rozwijać samoistnie, i liczyć na to, że strony wynegocjują rozwiązanie, lepiej jest jednak narzucić wcześniej jasne zasady i nie doprowadzić do jego powstania (chociaż nie za wszelką cenę i nie zawsze się to udaje).

Jak COVID zmienił twoje spojrzenie na kierowanie ludźmi?

Kierowałem już zespołami które pracują 24/7 przez cały rok. Nie ma w tym przypadku możliwości wdrożenia skutecznej metody weryfikującej co tak naprawdę pracownik robi (pamiętajmy o hydrauliku z początku historii). Wdrożyć systemy śledzące? Kupi sobie drugiego laptopa etc. Dobrze przygotowany zespół, gdzie ludzie czują odpowiedzialność nie będzie miał większego problemu z pracą zdalną (mówię oczywiście o pracy, która jest możliwa do realizacji, trudno sobie wyobrazić podział linii technologicznej pomiędzy mieszkania pracowników). Zresztą sami współpracownicy w zespole zdają sobie sprawę z tego kto i jak pracuje. Pamiętam przypadek, kiedy został wdrożony system motywacyjny oparty o liczbę zrealizowanych zgłoszeń. Jeden z „kolegów” polował na zgłoszenia dot. zmiany hasła. Przez wiele miesięcy był przodownikiem pracy i otrzymywał regularnie premię, co oczywiście było demotywujące dla reszty zespołu.

Mój wniosek jest taki trzeba dbać o zaangażowanie pracowników, powinni czuć się odpowiedzialni za realizację swoich zadań. W pewnym sensie można oprzeć się tutaj na metodzie ADKAR Służy ona co prawda do zarządzania zmianą, jednak czym jest zarządzanie jak nie stałym procesem zmiany?

Masz doświadczony zespół – czy kierownik jest potrzebny?

Pracowałem również z bardzo doświadczonymi ludźmi, którzy „zjedli zęby” na tym co robią. Poza wyzwaniami związanymi z Model Tuckmana, istnieje nieustający problem utrzymania motywacji i zaangażowania. Cały czas musimy też pamiętać o zachodzących zmianach i badać jak ludzie na nie reagują.

Kolejny wniosek: produkcja w toku zabija produktywność, im mniej tematów tym lepiej. Ta konkluzja jest o tyle trudna do zaakceptowania, że przecież mówimy o pracy, intuicyjnie wydaje się, że im więcej zadań wykonujemy tym lepiej i sprawniej działamy. A jednocześnie zdajemy sobie przecież sprawę, że każdy system ma swoje ograniczenia. Idea ta znajduje potwierdzenie np. w takich narzędziach jak tablica kanbanowa, gdzie trzeba z góry określić „Work in progres limits”.  Więcej o tym, że multitasking to zło można znaleźć tutaj albo w rewelacyjnej książce Project Fenix. O tym też już pisał też Goldratt w swoim „Cel i doskonałość w produkcji”.

Ostatni truizm, nie wiedzieć czemu bardzo przez środowisko IT nie lubiany, to fakt, że trzeba planować! Plany są ważne, ponieważ dają nam pogląd na to co chcemy osiągnąć i umożliwiają określenie np. budżetu, planu działania na wypadek awarii. Jest też jednak druga strona medalu w przypadku, kiedy plan przestaje funkcjonować trzeba dynamicznie dostosować się do zaistniałej sytuacji. Do takiego wniosku doszła między innymi Armia USA, która bardzo skutecznie kieruje swoimi „zasobami”.

Rzeczywiście, nie można armii amerykańskiej odmówić skuteczności. Na zakończenie proszę powiedz kilka słów o sobie.

Nazywam się Michał Frąckiewicz od ponad 15 lat pracuję w IT z czego przez większość czasu jako kierownik, bądź jako kierownik projektu.