Co mają robić firmy IT?

Zarządy firm informatycznych powinny też sobie zdawać sprawę, jak na metody pracy rzutuje sposób wyznaczania celów finansowych. Czasami sobie żartuję, że jedną z kluczowych informacji jakie powinien podawać dostawca IT przy startowaniu do przetargu jest sposób definiowania celów dla managerów u tego dostawcy. Jeżeli np. realizowanie celów finansowych sprawdza się raz na dwa miesiące i plany strategiczne zakładają stały wzrost dochodów, to możemy być pewni, że inwestycje dostawcy w efektywność pracy będą znikome. Bo po co? Manager jest rozliczony co dwa miesiące z tego, czy generuje coraz wyższy dochód, a usprawnienia pracy to inwestycje, a inwestycje to koszty, a koszty to niższe dochody. Ta inwestycja może się zwrócić za pół roku, a może za rok. A może wcale. Więc po co ryzykować? Lepiej zmusić ludzi do pracy w nadgodzinach. A zresztą czy za rok ja tu jeszcze będę managerem? Liczą się najbliższe dwa miesiące. A po mnie, to choćby potop.

Stawiając wysokie wymagania krótkoterminowe, co do dochodowości, wytwarzamy bodźce, które prowadzą do zepchnięcia tematyki usprawnienia metod pracy na drugi tor. W sytuacji, jeżeli klient jest mocno uzależniony od dostawcy, nieefektywne metody pracy zabezpieczają dostawcy dużo pracy i duże przychody. I taka sytuacja może trwać przez wiele lat ku chwale kolejnych managerów dostawcy. Do momentu, aż znajdzie się ktoś, kto nie tylko zada pytanie "dlaczego robimy to samo, co inny płacą za to 3 razy więcej", ale będzie miał odwagę i charyzmę, żeby to zmienić. Ale na szczęście odwaga i charyzma to w naszej branży rzadkość. Nieefektywni dostawcy IT mogą spać spokojnie.

Bardzo łatwo byłoby winić managerów za to, że podpisują nierealne kontrakty. Ale brak kontraktów oznacza koniec firmy. Podawanie prawdziwych kosztów i terminów w sytuacji, kiedy inni je zaniżają, jest ryzykowne. Managerowie i handlowcy są wdzięcznym celem ataków i krytyki za nierealne zobowiązania. Ale nie zapominajmy, że często pracują oni w dużym stresie. Nie można więc mieć żalu do managerów, że godzą się na nierealne terminy i oszukują klienta. Problem polega na tym, że managerowie także często oszukują też swój zespół, wytwarzając atmosferę fałszywego poczucia, że to wszystko jednak da się zrobić. Ewidentnie są też oszukiwani ludzie z innych projektów.

Sprawa oszukiwania też nie jest taka prosta. Jednym z kluczowych zadań dużych firm sektora IT jest motywowanie pracowników. Odnoszę wrażenie, że firmy te doszły do wniosku, że przy dużej liczbie pracowników nie da się tego zrobić skutecznie bez prania mózgów. Oczywiście można na to spojrzeć tak - Ci ludzie z projektu X, który jest porażką, naprawdę dają z siebie wszystko. Po co ich jeszcze dodatkowo dołować i poniżać przy innych i mówić jak to dali ciała. Nie - pokażmy im, że doceniamy ich wysiłek, to złagodzi ich frustrację tą całą sytuacją. A dla innych taka informacja, że radzimy sobie w trudnych sytuacjach podziała motywująco.

To wszystko niby racja, ale warto sobie uświadomić pewne efekty uboczne. Ci ludzie rozmawiają z kolegami z innych projektów. Często szczerze mówią jak jest naprawdę. I wtedy tworzy się niebezpieczny dysonans - z jednej strony wierchuszka mówi, że jest super, a ludzie z pola walki mówią coś zupełnie innego. To wywiera na pracownikach bardzo złe wrażenie i kolosalnie nadszarpuje wiarygodność kierownictwa.

Lessons learned to ulubione powiedzenie w naszej branży. Ale trudno o uczenie się na cudzych błędach, skoro oficjalnie nikt tych błędów nie popełnia i każdy wszystkie śmieci zamiata szybko pod dywan, aby inni nie widzieli. Taka otwarta analiza błędów swoich bądź rozmówców to nie to samo, co jakiś dokument lesson learned znaleziony w Internecie, opisujący jakiś nieznany projekt, tworzony przez nieznanych nam ludzi. Może kierownictwo powinno w takiej sytuacji brać winę na siebie i w ten sposób zachęcać ludzi do otwartego rozmawiania o błędach.

Jeżeli bym więc miał sugerować tutaj jakieś remedium, to może powinno się wytworzyć atmosferę zachęcającą do uczciwych rozmów. Ludziom, którzy na takim nieudanym projekcie pracują, należy oddać hołd, tak jak się oddaje hołd żołnierzom, którzy biją się dzielnie w przegranej bitwie. Ale trzeba też w sposób otwarty porozmawiać o tym, jakie błędy zostały popełnione.

Piotr Kałuski jest konsultantem w firmie CGI i jako test manager pracuje przy wdrożeniu systemu CRM w firmie ubezpieczeniowej.