Strona główna > O firmie, publikacje naszych specjalistów > Jak motywować informatyków. Część 2
Jak motywować informatyków. Część 2
Marek Wierzbicki
Artykuł oryginalnie opublikowany w Computerworld, 38/872/2009 [ISSN: 0867-2334], jako podsumowanie dyskusji po wcześniejszym artykule na ten temat: Jak motywować informatyków.
Z przyjemnością przeczytałem tekst Andrzeja Raniszewskiego, będący odpowiedzią na nasz artykuł (mój i Helmuta Gläsera). Z przyjemnością, bo autor poruszył w nim wiele bardzo ważnych spraw, które dzieją się dookoła nas. Zwłaszcza dziś, w okresie w którym nie wiadomo czy kryzys już sobie poszedł, czy dopiero przyjdzie. Jednak w tej beczce miodu znalazła się łyżka dziegciu. Jestem pewien, że Andrzej protestuje przeciwko proponowanej przez nas metodzie motywacji, mimo że sam aktywnie stosuje ją w swojej firmie.
Zacznijmy sprawę od informatyków. Od zamkniętego niegdyś klanu ludzi, grupy szamanów, którzy potrafili zmusić komputer do pracy metodami iście szamańskimi. Któż nie słyszał w czasach pierwszych komputerów opowieści, że będzie on poprawnie pracował tylko wtedy, gdy użytkownik będzie do niego przyjaźnie nastawiony i będzie rozumiał wszystkie jego potrzeby. Sam często opowiadałem takie bajki, wymuszając na ludziach między innymi to, że w przypadku awarii nie próbowali sami jej naprawiać (co często przynosiło więcej szkody niż pożytku), tylko wzywali informatyków.
Tamte piękne dawne czasy, poza sferą mistycyzmu w ramach informatyzacji, miały to do siebie, że jak słuszne zauważa Andrzej Raniszewski informatyka wspierała niewielki fragment biznesu. Pierwsze aplikacje wspierające bardzo ostrożnie zarządzanie przedsiębiorstwami, w większości przypadków omijały procesy krytyczne w firmach. Do końca lat dziewięćdziesiątych często się jeszcze zdarzało, że księgowość była ciągle prowadzona podwójnie czyli i w komputerze i metodą tradycyjną. Problem roku 2000 pięknie przedłużył u nas wiarę w to, że komputery i wróżki mają ze sobą wiele wspólnego. Wirusy komputerowe pojawiające się w tamtym okresie dodatkowo przekonywały ludzi, że komputery żyją jednak swoim własnym, prawdziwym życiem, które tylko informatycy potrafią okiełznać. Od tego okresu nie minęło wcale tak dużo czasu, jak to się Andrzejowi wydaje. To tylko 10 lat. Wiara w gusła jest dalej silna w narodzie. Któż z nas nie zawaha się by pójść dalej, gdy drogę przebiegnie mu czarny kot?
Jednak prawdą jest to, że świat poszedł do przodu. Dziś każdy Polak (wliczając noworodki) ma ponad jeden telefon komórkowy (jakby nie patrzeć to w końcu komputer), a większość studentów pojawia się na zajęciach z własnymi laptopami, żeby tam notować uwagi z wykładów lub sprawdzać na bieżąco, ile z tego wykładu jest dostępne on-line w internecie. Taka powszechność nie byłaby możliwa przy założeniu, że informatyka to wiedza szamańska dostępna nielicznym. I zgadzam się w tym punkcie z autorem polemiki. Informatyka nie jest już wiedzą tajemną, a informatycy nie są niezastąpionymi szamanami, którzy całą wiedzę gromadzą tylko we własnych głowach. Choć często jeszcze bardzo by chcieli.
Na przeszkodzie takiemu pojmowaniu informatyki staje biznes. Zarząd nie chce mieć u siebie stada szamanów, którzy wykonają pracę tylko wtedy, gdy będzie dla nich interesująca. Jak słusznie zauważa Andrzej informatycy często nie tylko nie integrują się z pracownikami innych działów, ale i nie utożsamiają się z problemami firmy. Często jeszcze słyszy się wśród informatyków tezę, że przestój w sprzedaży czy pracy magazynu to nie jest ich problem. Ich problem to deadlock na bazie danych czy backup blokujący dodawanie nowych rekordów. Informatycy tak postrzegający świat muszą się zmienić i to bardzo szybko. Bo jeśli się nie zmienią, to ich miejsce zajmie outsourcing usług informatycznych z wszechobecnym SLA (z angielskiego Service Level Agreement), czyli współczynnikiem definiującym jak szybko dana awaria zostanie usunięta dla tego kontraktu.
Twórczo czy wymiernie?
Jednak od tego miejsca spojrzenie autora polemiki i moje znacząco się rozchodzą. Andrzej błędnie zakłada, że skoro firma zlecająca usługę outsourcingową innej firmie i rozlicza się z tego na podstawie realizacji mniej lub bardziej skomplikowanych współczynników, to realizację tych współczynników trzeba przenosić na informatyków realizujących to zadanie. Błąd ten rozwinę dalej, gdyż niepostrzeżenie dotarliśmy do zawoalowanego pytania, którego Andrzej otwarcie nie postawił, ale przewinęło się również w komentarzach do elektronicznej wersji naszego artykułu: Jak motywować pozornie nietwórczych pracowników help-desku? To pytanie było bardzo silne między innymi dlatego, że jako przykład motywacji informatyków w poprzednim artykule wybieraliśmy bardziej twórcze stanowiska z obszaru informatyki. Po tekście słyszeliśmy więc często tezy: Projektanta czy programistę może da się tak motywować, ale jak motywować serwisanta?
Zanim opowiem jak to ma być z motywacją dam przykład, dlaczego motywowanie wskaźnikami pracowników help-desku jest błędem. Opisywaną sytuację zaobserwowałem w działach obsługi klienta dwóch firm informatycznych będących spółkami giełdowymi. Przez litość przemilczę ich nazwy, ale skoro takie rzeczy zdarzają się dużym, to mogą się trafić wszędzie. Otóż sytuacja była taka: niemal w każdym programie zdarzają się błędy. Niektóre pojawiają się sporadycznie, inne z mniejszą lub większą regularnością. Przypadek, który mam na myśli dotyczy błędu, który pojawiał się stosunkowo często. Na tyle często, że pracownicy help-desku wypracowali sobie metodę szybkiego naprawiania tego błędu. Mniej lub bardziej skomplikowany skrypt usuwał błąd w kilka minut. Do napisania skryptu automatycznie usuwającego błąd potrzebna była analiza, co jest jego przyczyną, oraz w jakiej sytuacji występuje. Pracownik help-desku przeprowadził taką analizę i wykrył warunki powodujące powstanie błędu. I przełożył efekt swojego myślenia na skrypt usuwający błąd.
Jaki ma to związek z destrukcyjnym działaniem wskaźnikowych motywatorów tego pracownika? Już wyjaśniam. Otóż pracownik ten premiowany był za szybkość rozwiązywania zgłaszanych mu problemów. Od czasu gdy stworzył skrypt naprawiający problem, jego premia znacząco wzrosła. Błąd, którego naprawa mogłaby zająć kilka godzin zajmowała mu kilka minut. Dzięki temu średnia szybkość reakcji tego pracownika na pojawiające się incydenty wzrosła, a z nią urosła premia. Nie na rękę było mu więc informowanie działu produkcji, jakie są przyczyny błędu. Na rękę mu było to, że ten błąd istnieje i z wersji na wersję nie jest usuwany.
Tu dygresja, która odsuwa nas na chwilę od kwestii motywowania, a przesuwa w kierunku wspomnianego wcześniej SLA. Otóż autor polemiki błędnie założył, że SLA, czyli ścisłe wskaźnikowe ramy zachowania firmy zlecającej obsługę informatyczną, powinny przełożyć się na wskaźnikowe systemy motywacyjne informatyków zleceniobiorcy. Otóż jest to błędnie założenie. Podpisanie umowy SLA powinno skutkować wdrożeniem standardów ITIL. ITIL (Information Technology Infrastructure Library) jest to zbiór zaleceń i najlepszych praktyk, który mówi jak efektywnie i skutecznie oferować usługi informatyczne. Tu można poszaleć ze wskaźnikami i sformalizowanymi metodami, ale tylko wtedy, gdy dotyczą procesów, a nie ludzi. Korzystając z tej metodologii można zapewnić łatwiejsze wykrywanie błędów w działaniu oprogramowania. Ale nie w działaniu ludzi.
ITIL nie jest bowiem remedium na wszelkie problemy, które pojawiają się przy motywowaniu pracowników. Opisany wcześniej przykład chorego podejścia do często pojawiających się błędów miał bowiem drugie dno. Otóż w obu firmach, w których zaobserwowałem motywacyjny wpływ szybkości realizacji zleceń na podbijanie wskaźnika szybkości (zamiast podnoszenia się jakości oprogramowania) stosowano metodologię ITIL. A pracownicy, którzy o tym wiedzieli, celowo fałszowali wpisy do systemu help-deskowego, by zależność którą sami wykryli, jak najdłużej nie została zauważona przez nikogo innego. Fałszerstwa bazowały na wpisywaniu różnych objawów, bądź różnych metod naprawy błędów. Dzięki temu idea przechodzenia od incydentów do problemów (znana w ITIL) nie mogła funkcjonować poprawnie.
Tu przestrzegam miłośników wskaźnikowego podejścia do motywacji przed tezą, że wskaźnik motywujący był źle zdefiniowany i gdyby był dobrze zdefiniowany to pracownicy nie mogliby go oszukiwać. Należy podkreślić to, co jest głównym zarzutem w stosunku do wskaźnikowych systemów motywacyjnych. W systemach tych pracownik motywowany jest nie do najlepszej pracy, ale do osiągania jak najlepszej wartości wskaźnika motywującego. I bez względu jak skomplikowany będzie wskaźnik motywacyjny czynnik ludzki, tak lubiane przez HR określenie, znajdzie sposób na to by osiągać jak największą wartość tego wskaźnika, zamiast jak najlepiej pracować. W skrajnym przypadku może się okazać, że proces udowadniania, że się dobrze pracuje zajmuje pracownikom znacznie więcej czasu, niż sama praca.
Razem z ludźmi
Jak więc motywować pracowników help-desku? Na wszelki wypadek przypominam, że mówimy o stwarzaniu warunków do automotywacji, a nie zmuszaniu kogoś kijem bądź marchewką do lepszej pracy. Jak więc postępować z ludźmi w tak nudnym środowisku, jak linia wsparcia serwisowego? Najważniejsze to nie przekonywać ich, że środowisko jest nudne. W każdym, pozornie najnudniejszym miejscu pracy istnieją wyzwania, które warto podejmować. Bazując na wcześniej opisanym przykładzie możemy powiedzieć, że pracownik, który znalazł przyczynę często pojawiającego się błędu miał automotywację do pracy. Jedynie wskaźnikowe rozliczanie go z pracy zabiło w nim chęć pracy dla dobra firmy, na rzecz realizacji własnego wskaźnika motywującego.
Wystarczyłoby tylko przekonać opisywanego pracownika, że nie jest małoznaczącym trybikiem, ale od niego w jakiejś mierze zależy jakość tworzonego oprogramowania i znaczenie marki firmy. Jednak żeby to uzyskać trzeba wznieść się ponad poziom uznawania osoby odbierającej telefony i reagującej na awarie za zasób ludzki usuwający błędy informatyczne. Trzeba zobaczyć w nim człowieka. A dalsza droga zależy od konkretnej sytuacji i stanowiska. W opisywanym przykładzie nasz pracownik mógłby w przyszłości nadzorować działanie systemu znajdowania regularności w pojawiających się błędach czy analizować zjawiska przyczynowo skutkowe doszukując się w prawdziwych przyczyn powstawania błędów. Ciekawa ścieżka awansu będzie wyzwaniem dla każdego.
I tu należy wrócić niemal do początku artykułu, czyli do miejsca, w którym wypominałem informatykom (zwłaszcza niektórym), że chcieliby być szamanami czy jednostkami wybitnymi, których nie da się okiełznać. Takich osób nie da się skanalizować do pracy przy taśmie produkcyjnej. Ich trzeba porwać umiejętnym działaniem i rozbudzić w nich chęć do pracy tak, jakby mieli pracować dla siebie. Zamiast konstruować skomplikowane wskaźniki motywacyjne trzeba uczyć się jak z nimi rozmawiać. Jak umiejętnie nimi zarządzać. Zarządzanie to umiejętność, której naprawdę można się nauczyć. To nie jest łut szczęścia czy trafi się na informatyka chętnego do pracy. To ciężka praca zarządzającego. To on powinien uczyć się jak zarządzać ludźmi poprzez sterowanie ich energią do pracy, a nie ślepą chęcią otrzymania kilku złotych premii więcej.
Nie zgadzam się z tezą, że pasjonaci informatyki szkodzą całej rzeszy informatyków pracujących zgodnie z wytycznymi korporacyjnych procesów. To oni (ci pasjonaci) są najwartościowszymi pracownikami. To oni potrafią pociągnąć do dalszej pracy innych. Trzeba tylko wiedzieć jak im pokazać, że nie tylko problemy wymyślone w obrębie ich wąskiej specjalizacji są ciekawe. Trzeba pokazać jak prawdziwy proces biznesowy przekłada się na ich dziedzinę. Informatyk, który zobaczy kilkaset osób czekających bez pracy na zrolowanie transakcji bazodanowej nigdy nie będzie już myślał o tej transakcji bezosobowo. Pracownik help-desku, który osobiście pozna swoich zleceniodawców (nie zarządy, ale ludzi przy biurkach, którzy zgłaszają mu błędy) nigdy nie pomyśli o błędzie zgłaszanym przez znaną osobę jak o problemie teoretycznym. Rozwiązując błąd będzie wiedział kto i na jakim stanowisku z utęsknieniem czeka na jego rozwiązanie. Będzie mógł sobie wyobrazić oczekiwanie tych ludzi.
I żeby dosadniej wyrazić to, że system motywacyjny bazujący na wskaźnikach i związanych z nimi pieniądzach jest złym rozwiązaniem dam Andrzejowi Raniszewskiemu kontrprzykład. Twierdzi On, że żaden odpowiedzialny szef nie będzie chciał mieć pracownika, którego nie da się w prosty sposób skusić pieniędzmi. Andrzeju! Czy naprawdę chciałbyś mieć pracownika, który odejdzie z Twojej firmy tylko dlatego, że konkurencja zapłaci mu złotówkę więcej za każde obsłużone zlecenie? Może dziś nie zapłaci. Ale jutro, gdy kryzys się skończy, taka konkurencja się pojawi. Naprawdę lubisz stawać przed faktem, że pracownik przynosi Ci swoje wypowiedzenie wtedy, gdy budżet kontraktu już jest napięty i nie masz skąd wykrzesać pieniędzy na podwyżkę?