Twarzą w twarz

Menedżerom i kierownikom projektów IT z całą pewnością pomogłaby znajomość ''czynników miękkich'', tak często warunkujących sprawną pracę całego zespołu i ostateczny sukces.

Menedżerom i kierownikom projektów IT z całą pewnością pomogłaby znajomość 'czynników miękkich', tak często warunkujących sprawną pracę całego zespołu i ostateczny sukces.

W pewnym projekcie informatycznym zdarzyła się następująca historia: kierownik testów, spotykając na korytarzu kierownika projektu, powiedział: "Wczoraj w oprogramowaniu znaleźliśmy dwadzieścia błędów. Moim zdaniem system nie nadaje się do tego, żeby wdrożenie zacząć w najbliższy poniedziałek. Musimy te błędy najpierw usunąć i upewnić się, czy nie ma równie licznych błędów w jego innych modułach". Co naprawdę powiedział kierownik testów?

Na poziomie rzeczowym wypowiedź była dokładnie taka, jak napisaliśmy powyżej. W zasadzie nie ma z tym kłopotów, choć zagadnienia lakoniczności lub rozwlekłości wypowiedzi, użytego języka (fachowy żargon, język oficjalny lub nieoficjalny) czy sposobu przekazu także mogą odgrywać znaczącą rolę w jego zrozumieniu. Natomiast na poziomie relacyjnym - w tym przypadku ukrytym za fasadą rzeczowości - komunikat brzmiał: "Nie będziesz tak jak dotąd górował nad nami, obcinając nam budżet i traktując jak złośliwe dzieci. Zobacz, do czego doprowadziła twoja arogancka dominacja!". Na poziomie ujawniania siebie kierownik testów powiedział: "Jestem zły i zmęczony takim trybem pracy i niedocenianiem wysiłków naszego zespołu. Nie podoba mi się to!". Wreszcie na poziomie apelowym jego komunikat głosił: "Znowu, jak w poprzednim projekcie, grozi nam awantura z niezadowolonym klientem. Musimy coś na to zaradzić!".

Czy to właśnie usłyszał kierownik projektu? Nie bądźmy tego pewni, przecież trzy poziomy komunikatu były starannie ukryte i zakodowane - któryś z nich kierownik projektu mógł przeoczyć. Znamy podobne sytuacje z życia codziennego, domowego i wiemy, jak łatwo o nieporozumienia. Mąż mówi do prowadzącej samochód żony: "Patrz, zielone światło!", na co żona zirytowana woła: "Kto właściwie prowadzi, ty czy ja?", czym mąż jest zaskoczony i czuje się niesprawiedliwie zaatakowany.

Spróbujmy rozważyć, co mógł usłyszeć kierownik projektu. Na poziomie rzeczowym kierownik projektu zdziwił się, czemu informacja została rzucona w przelocie, niejako z zaskoczenia, skoro można było wykorzystać w tym celu standardowy mechanizm raportowania. Dlaczego zabrakło w niej wielu istotnych szczegółów, na przykład odnośnie do wagi znalezionych błędów, czy na ile są one trudne do usunięcia. Natomiast ucho relacyjne kierownika usłyszało: "Jesteś kiepskim kierownikiem, to ja powinienem być kierownikiem, a nie ty!". Ucho nastawione na komunikat ujawniania siebie usłyszało: "Byłem w firmie dłużej od ciebie, ale ty zostałeś kierownikiem, jestem zły i będę ci przeszkadzać na każdym kroku". Wreszcie odebrany przez kierownika projektu apel brzmiał: "Chcę, żebyś przyznał, że projekt jest do niczego i tylko zespół testowy uratował firmę przed skandalem".

Skutki nieporozumień

Przeczytawszy powyższą historię, ktoś mógłby pomyśleć - "Cóż, nieporozumienia i konflikty między ludźmi zdarzają się, ale to sprawa dla działu HR, nie dla informatyków ani kierowników projektów. Zresztą mają one drugoplanowe znaczenie. Nie mamy czasu bawić się w psychologów, czekają nas trudne wyzwania techniczne". Jest to często spotykane nieporozumienie. Po pierwsze, koszt takich nieporozumień może w rzeczywistości być ogromny. Wyobraźmy sobie, co na taką wypowiedź kierownika testów mógł odpowiedzieć szef projektu? Nietrudno zgadnąć, jakie konsekwencje dla jakości i terminowości produktu miałoby nawarstwianie się takich nieporozumień?

Schulz von Thun w swojej książce "Sztuka rozmawiania" napisał: "W tym stadium prawie nikt nie może powiedzieć nic rzeczowego, żeby nie otrzymać twarzy zarozumiałego znawcy, złośliwca, atakującego czy kogoś, kto stara się wyrównać dawne porachunki. Niektóre grona czy zespoły znajdują się w stanie chronicznego powikłania, gdzie każda rzeczowa dyskusja jest jednocześnie przeniknięta (przy okazji wzmacnianymi) problemami w relacjach międzyosobowych".

Wybrany przykład dotyczył relacji test-zarządzanie projektem, jednak można wskazać znacznie więcej obszarów, w których międzyludzka komunikacja może okazać się języczkiem u wagi decydującym o sukcesie bądź niepowodzeniu projektu. Kluczem do sukcesu projektu jest inżynieria wymagań, która, gdy zawodzi, jest według wielu oszacowań przyczyną nawet 50% błędów (por. The Standish Group: "Charting the Seas of Information Technology Chaos")! W szkoleniach z inżynierii wymagań wiele miejsca poświęca się zagadnieniom pozyskiwania wymagań, technikom nawiązywania i utrzymywania porozumienia z klientem oraz komunikacji na styku dokument analizy-projektowanie systemu. To uderzające, jak ogromne znaczenie dla powodzenia tych czynności ma sprawna komunikacja.

Po drugie, pozostawianie spraw psychologicznych w gestii działu personalnego jest zasadniczym błędem. Obserwując profile zawodowe uczestników rozmaitych treningów psychologicznych (dane z Ośrodka Doradztwa i Treningów Szkoleniowych HOMO CREATORE), można zauważyć, że najczęściej uczestniczą w nich sprzedawcy, kierownicy zespołów oraz pracownicy działów obsługi klienta, a więc grupy tradycyjnie uznawane przez działy personalne firm za narażone na stres i potrzebujące w swojej pracy umiejętności psychologicznych. Któż odważyłby się zaproponować kierownictwu wydatek na trening tego typu dla programistów, analityków systemów, inżynierów testów czy osób odpowiedzialnych za zapewnienie jakości?

W rzeczywistości, właśnie dla tych grup umiejętności interpersonalne i psychologiczne mają szczególne znaczenie i pozwoliłyby - niekiedy dramatycznie - na podniesienie efektywności i skuteczności procesu produkcji oprogramowania.

Podany na początku artykułu przykład dotyczył zagadnień międzyludzkiej komunikacji. Na nim jednak psychologiczne aspekty w projektach informatycznych nie kończą się - przeciwnie.

Kreatywność

Kreatywność, czyli zdolność wynajdowania oryginalnych, twórczych rozwiązań dla rozmaitych problemów, w oczywisty sposób przydatna jest projektantom systemów informatycznych i programistom. Nie każdy jednak zdaje sobie sprawę z tego, jak wielkie znaczenie ma kreatywność w rozwiązywaniu zagadnień nie tylko konstrukcyjnych, lecz również organizacyjnych, międzyludzkich czy biznesowych, a także w inżynierii wymagań, zapewnieniu jakości i utrzymaniu systemów informatycznych.

Może się wydawać, że kreatywność nie jest potrzebna pracownikom, od których kierownictwo oczekuje przede wszystkim dyspozycyjności oraz starannej realizacji szczegółowych instrukcji. To jest jednak bardzo krótkowzroczne podejście. Pracownik kreatywny będzie sprawdzał się lepiej nawet przy wykonywaniu zadań rutynowych i monotonnych. Taki pracownik zapewne dość szybko znajdzie sposób, jak takie czynności ominąć, zautomatyzować albo przynajmniej wykonywać znacznie szybciej. Nic dziwnego, skoro kreatywność określa się między innymi jako umiejętność zmiany punktu widzenia, zakwestionowania lub restrukturyzacji posiadanej wiedzy.

Kreatywność sprawdza się najlepiej w sytuacjach otwartych, w których istnieje wiele możliwych rozwiązań, a do takich przecież zalicza się zdecydowana większość projektów informatycznych. Co ważne, kreatywności można w znacznym stopniu nauczyć się poprzez odpowiedni trening.

Negocjacje

Sytuacje negocjacji występują w projektach informatycznych nie tylko na spotkaniach zarządów spółek czy podczas rozmów sprzedawców z klientami. Negocjacje toczą się nieustannie: przy składaniu wstępnej oferty, przy rozmowach na temat kontraktu, przy pozyskiwaniu oraz analizie wymagań. Ponadto wiele negocjacji odbywa się wewnątrz projektów: między kierownikiem projektu a grupą sterującą, między kierownikami zespołów a ich podwładnymi, między osobami odpowiedzialnymi za zapewnienie jakości a pozostałymi udziałowcami projektu, między testerami a konstruktorami.

Większość projektowych decyzji poprzedzają jakieś negocjacje. Negocjowanie jest nieodłącznym czynnikiem zarządzania zamianami, zarządzania i analizy ryzyka, śledzenia zgłoszeń niezgodności, określania zakresu funkcjonalnego kolejnych wersji produktu informatycznego itd.

Nieumiejętne negocjacje mogą zaprzepaścić korzyści, które są owocem wysokiego poziomu technologicznego firmy. Profesjonalne negocjowanie także - jak kreatywność - jest umiejętnością, którą w znacznym stopniu można wyćwiczyć.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200