Metody kontroli
Wraz ze wzrostem liczebności zespołów informatycznych branża informatyczna nadal forsuje metody kontroli za pomocą zegarka ze stoperem, kabla w biurze, a także całego wachlarza metod bezpośredniego nadzoru lub odgórnego nakazu. Tymczasem wiele firm informatycznych postawiło na indywidualizm, samodzielność i odpowiedzialność – wszędzie tam gdzie jeszcze wyjątkowy talent i indywidualna kreatywność – nadal dominują nad brutalną siłą wielkości zespołu.
Tam gdzie dominuje liczebność wymuszona złożonością pracowników, indolencją kierownictwa lub najczęściej – zwykłą chciwością pracodawców wyrabiających marzę na handlu każdym kolejnym pracownikiem – tam firmy informatyczne nadal prześcigają się w absurdach. Najprostszym i jednocześnie chyba najbardziej tępym sposobem hamowania zespołu jest metoda budżetów czasowych, czyli efektywnie wyznaczania ograniczeń czasowych w dostarczaniu ostatecznych rozwiązań określonych problemów.
Co istotne, warto podkreślić iż krytykując tą metodę rozumiem że samo budżetowanie czasu znane jest wielu metodologiom projektowym: od całej gamy metodologii waterfall – po całą gamę metodologii agile. Rzadko które jednak implementację tego sposobu spodziewają się dostarczania jakkolwiek ostatecznych lub jakkolwiek doskonałych rozwiązań zamkniętych w sztywnym budżecie czasowym poświęconym na ich pierwszą implementację. Branża zmieniła się dramatycznie w ciągu ostatnich dwóch dekad, ale nadal znajduję współczesne przypadki stosowania klasycznych metod.
Jedna z firm, w której pracowałem stosowała metodę budżetową czasu dla projektu, inna z kolei metodę budżetową dla konkretnej funkcjonalności. Kompletnym wyjątkiem, jednak nadal praktyką co najmniej jednej znanej mi firmy było budżetowanie czasu na poziomie zadania – z każdorazowym akceptowaniem przedłużenia czasu realizacji o każdą kolejną godzinę,o którą programista musiał każdorazowo wnioskować u kierownika…
Żadna metoda kontroli, absolutnie nigdy nie zwiększyła produktywności (wydajności, marżowosci) żadnego zespołu, ale co najciekawsze i osobiście dla mnie wręcz szokująco ciekawe – nigdy nie miała takiego celu. Jedynym celem było tworzenie dyscypliny, nawet kosztem wydajności programistów. To szokujące, bo to jakby zrozumieć iż budowanie efektywnej organizacji nie ma niczego wspólnego z procesem, ale zespołem – tylko stosując wnioski odwrotne do oczywistych.
Stosując wnioski odwrotne do oczywistych to tak, jakby powiedzieć że efektywności nie buduje się procesem, tylko indywidualnym talentem i współpracą zespołu, ale oprzeć to na dyscyplinowaniu kreatywnych pracowników i zatrzymywaniu czasu współpracy nad projektem. Tak nieracjonalne postępowanie ma jednak bardzo proste podstawy: poczucie kontroli kierownictwa w części przedsiębiorstw jest znacznie ważniejsze niż zarabianie pieniędzy.
Powtórzę: dla przeciętnej firmy nie ma znaczenia czy zarobiła milion, czy straciła milion – o ile tylko są w stanie ten milion pożyczyć, pozyskać z giełdy, albo skompensować z innym projektem, o ile kierownictwo miało poczucie pełnej kontroli nad procesem, który doprowadzi do takiego lub przeciwnego rezultatu. Dla przedsiębiorcy to szczerze szokujące, ale jestem przekonany że w przygniatającej większości przypadków – całkowicie akuratne.
Analogiczny szok przeżyłem widząc jak wiele firm zupełnie nie jest zainteresowanych wydajnością swoich pracowników, terminami realizacji projektów, co obserwowaniem ich pracy na miejscu w biurze – mówiąc wprost że są w stanie poświęcić każdy terminarz i każdy projekt, jeśli miałoby to narazić możliwość osobistej kontroli pracownika w miejscu pracy. Nie chodzi o to żeby dostarczać szybko i z łatwością, ale obserwować ten proces – niezależnie od tego czy obserwacja dotyczy zwinnego programowania, czy wykuwania rozwiązania w agonii.
Na szczęście pojawia się zmiana, ponieważ rynek wkracza w końcu w każdy obszar nieefektywności i nawet jeśli nie potrafi od razu zweryfikować nieefektywnych metod zarządzania brakiem dochodu, tam absurdalne metody kierowania weryfikowane są przez rynek pracy – obecnie zwanym “rynkiem pracownika”. Obecnie firmy informatyczne nie muszą walczyć o środki, bo środków jest nadmiar, ale zmagają się w walce o pracowników zadając sobie pytania “co zrobić aby sprostać oczekiwaniom pracowników”, a czasami wręcz korygując anachroniczne metody zarządzania, które absolutnie nie są w stanie sprostać oczekiwaniom specjalistów IT. Dzieje się to zaskakująco powoli, ale następuje.
Niestety dotychczasowe metody kontroli będą sprawdzały się tak długo, jak długo pracownicy będą pozytywnie reagować na wysokie wynagrodzenia oferowane przez pracodawców, którzy aktywnie biorą udział w wyścigu wynagrodzeń, głównie ponieważ po prostu mogą.
Wyścig wynagrodzeń trwa, albowiem nadal wynagrodzenie stymuluje przepływy pracowników między firmami. Jednak ten wyścig wynagrodzeń zostanie w pewnym momencie gwałtownie wyhamowany, nawet jeśli nie potrafię sobie wyobrazić dlaczego miałby być znacząco wyeliminowany. Wyhamowanie nastąpi w momencie gdy koszty wynagrodzeń programistów w naszym kraju zrównają się ze średnią krajów, które najczęściej zlecają realizację projektów w Polsce – ze względu na niższe koszty ich realizacji właśnie.
Jeżeli wierzyć ankietom, już dzisiaj wynagrodzenie samo w sobie nie jest wystarczającym czynnikiem decydującym o wyborze pracodawcy, co potwierdzają deklaracje uczestników ankiety popularnego serwisu monitorującego rynek pracy programistów i specjalistów branży informatycznej. Według deklaracji uczestników ankiety są nimi niemal na równi – udział w ciekawym projekcie, możliwość rozwoju w ciekawych technologiach oraz warunki pracy (zdalnej). Jeżeli moje przewidywania są prawidłowe, te ostatnie czynniki będą jedynie rosły na znaczeniu, poza możliwością pracy zdalnej która stanie się oczywistością i zostanie usunięta z tego rodzaju ankiet w ogóle.