Przykład z projektu

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 funkcjach.”

Co naprawdę powiedział kierownik testów?

Na poziomie rzeczowym1 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ę. 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, zakodowane, i któryś z nich kierownik projektu mógł naprawdę 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 zaatakowany2.

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, z zaskoczenia, zamiast żeby wykorzystać w tym celu standardowy mechanizm raportowania, i dlaczego zabrakło w niej wielu istotnych szczegółów, na przykład odnośnie 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.”

Co wynika z 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 human relations, 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; jak nieporozumienia nawarstwiały się i jaki mogły być ich konsekwencje dla jakości i terminowości produktu? Schulz von Thun pisze:

„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, ale obszarów, gdzie międzyludzka komunikacja może okazać się języczkiem u wagi, decydującym o sukcesie bądź niepowodzeniu projektu, jest znacznie więcej. Kluczem do sukcesu projektu jest inżynieria wymagań, która, gdy zawodzi, jest wedle wielu oszacowań przyczyną nawet 50% błędów3! W szkoleniach dotyczących 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. Bezsprzecznie, 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 psychologicznych4 widać, ż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 projektów informatycznych nie kończą się – jest wręcz przeciwnie.

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 spodziewa się przede wszystkim dyspozycyjności oraz starannej realizacji szczegółowych instrukcji. Jednak jest to bardzo krótkowzroczne podejście. Pracownik kreatywny będzie sprawdzał się lepiej nawet przy wykonywaniu zadań rutynowych i monotonnych. Zapewne taki pracownik wkrótce 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, mających wiele możliwych rozwiązań, a do takich przecież zalicza się zdecydowana większość projektów informatycznych.

Co ważne, kreatywności można znacznym stopniu nauczyć się poprzez odpowiedni trening.

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, negocjacji oraz analizie wymagań. Ponadto wiele negocjowania 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 i tak dalej.

Nieumiejętne negocjacje mogą zaprzepaścić korzyści, wynikające w wysokiego poziomu technologicznego przedsiębiorstwa. Profesjonalne negocjowanie także – jak kreatywność – pozwala się w znacznym stopniu wyćwiczyć.

W skutecznych negocjacjach konieczna jest asertywność. Moda na asertywność rośnie, coraz więcej osób, nie tylko oddelegowanych przez firmy, uczestniczy w treningach asertywności.

Co to jest asertywność? To umiejętność spokojnego i przyjaznego, ale zdecydowanego wyrażania swojego zdania i swoich preferencji bez popadania w agresję, bez doznawania negatywnych emocji (gniewu, smutku, poczucia upokorzenia) i bez zamiaru ukarania osoby mającej zdanie odmienne.

Niewiele osób umie być asertywnymi. Wielu ludzi ma znaczne trudności z mówieniem „nie” i bierze na siebie zbyt wiele obowiązków lub ustępuje pod niewielką nawet presją. W takim człowieku może przez dłuższy czas narastać poczucie krzywdy, które nieoczekiwanie dla wszystkich może w końcu wyzwolić się w formie wybuchu gniewu i agresji. Inni mylą asertywność z arogancją, bezwzględnością oraz ignorowaniem potrzeb współpracowników. Ani jedna, ani druga postawa nie jest skuteczna – przeciwnie. Znamy z praktyki projektów informatycznych setki sytuacji, w których brak asertywności w negocjacjach doprowadził albo do zaakceptowania przesadnych żądań klienta (zjawisko niekontrolowanego wzrostu wymagań, scope creep), albo do ostrych, wywodzących się z poczucia krzywdy konfliktów na osi przełożeni – podwładni, programiści – testerzy, dział biznesowy – dział informatyki i tak dalej. Dominuje dziś w młodych, prężnych działach polskiej gospodarki opinia, że ostrość, konflikty i arogancja są niezbędną częścią nowoczesnego biznesu, konieczną ceną za sukces. To mylna, kosztowna i niebezpieczna opinia. Trening asertywności – nauka, jak zdecydowanie, otwarcie ale nieantagonistycznie prezentować swoje zdanie – ma wszelkie dane, by zaowocować sprawniejszymi projektami, skuteczniejszą komunikacją i większą satysfakcją z pracy uczestników przedsięwzięć.

Opisane na początku nieporozumienia między kierownikiem testów a kierownikiem projektu odnosiły się do interakcji między dwiema osobami, choć oczywiście podobne do opisanych zjawiska mają miejsce także wówczas, gdy dotyczą wielu osób jednocześnie. Szczególnym przypadkiem są wystąpienia i prezentacje publiczne, w warunkach organizacji i projektów szczególnie często spotykane: uczestniczy się w zebraniach, naradach, przeglądach, prowadzi się warsztaty, szkolenia, seminaria i prezentacje dla klientów. Dla wielu osób konieczność wystąpień publicznych budzi lęk, który wręcz paraliżuje i powoduje, że w takich sytuacjach są – ze stratą dla wszystkich – mniej skuteczni i profesjonalni niż kiedy indziej. Na drugim krańcu skali plasuje się nadmierna swoboda i nieuwzględnianie potrzeb słuchaczy. Prelegent sparaliżowany lękiem mówi cicho i niewyraźnie, unika kontaktu wzrokowego ze słuchaczami, nie podkreśla intonacją i gestykulacją struktury przekazu, lęka się pytań lub odpowiada na nie przesadnie rzeczowo, w stylistyce akademickiej. Takie osoby często usypiają swoich słuchaczy. Natomiast prelegenci zbyt pewni siebie (niekiedy jest to tylko maska, za którą także kryje się stłumiony lek) mówią chaotycznie, zaciemniają przekaz nadmierną ilością anegdot lub żartów nie pasujących treścią do prelekcji, robią też wrażenie aroganckich i manipulacyjnych.

Spójrzmy na strukturę CMMI. Przejście od poziomu pierwszego do drugiego wymaga zaistnienia powtarzalnego procesu, od drugiego do trzeciego – zdefiniowanego procesu, od trzeciego do czwartego – zarządzanego procesu, wreszcie od czwartego do piątego – optymalizującego procesu. Aby proces był powtarzalny trzeba umieć się ze sobą komunikować, aby był zdefiniowany – umieć go przedstawić, aby zarządzać trzeba umieć negocjować, wreszcie aby optymalizować – trzeba wykazać się kreatywnością. Rodzi się poważna pokusa i wyraźna potrzeba, aby CMMI poszerzyć o elementy dojrzałości organizacji na poziomie psychologicznym oraz interpersonalnym. Owszem, jest ten pion w CMMI – na papierze. Czyżby nadszedł czas, aby wypełnić go treścią?

Nie potrzeba wyjaśniać, jakie znaczenie ma umiejętność stworzenia właściwej motywacji oraz kompetencji i doświadczenia w zakresie zarządzania zespołem dla powodzenia projektu informatycznego. Pozostaje kwestia, na ile dostępne w tym zakresie szkolenia są dostosowane do specyfiki potrzeb występujących przy wytwarzaniu oprogramowania. Z jednej strony, niewątpliwie istnieje wiele podobieństw w zarządzaniu zespołami niezależnie od tego, co jest przedmiotem, celem czy zadaniem projektu, a także czynności wykonywanych w sposób ciągły, jak zarządzanie działem firmy. Z drugiej strony, nauczanie zasad zarządzania zespołem w oderwaniu od specyfiki projektu pozostawia najważniejsze zadanie – przełożenie nauczanych ogólnych zasad na konkretne reguły postępowania w rzeczywistości – do wykonania uczestnikom treningu. Z łatwym do przewidzenia skutkiem, zwłaszcza jeśli pozostali uczestnicy treningu reprezentowali specjalności takie jak zarządzanie zespołami budowlanymi, sprzedawcami czy pracownikami call centre. Jednym słowem, wiele korzyści mogłyby przynieść treningi dedykowane dla uczestników projektów informatycznych, przygotowywane i prowadzone jednocześnie przez zawodowego trenera kompetencji psychologicznych i przez osobę z obszernym, praktycznym doświadczeniem informatycznym.

W bogatym folklorze informatyki znajduje się nieskończona wręcz liczba żartów, anegdot i dobrych rad dotyczących chronicznego w tej branży stresu, pośpiechu, wypalenia, problemów emocjonalnych. Na przykład szkolenia dla testerów obfitują w pół-profesjonalne porady, jak rozmawiać z programistami, by ich nie antagonizować. Znaczna część wiedzy z inżynierii wymagań dotyczy tego, jak rozmawiać klientem, aby uzyskać od niego rzeczywisty i w miarę kompletny obraz jego wymagań. Wdrożenia, serwis i utrzymanie systemów szczególnie narażone są na problemy spowodowane niekontrolowanym ujawnianiem emocji, stresem i przeciążeniem zadaniami. Na pewno informatycy – programiści, analitycy, projektanci i testerzy - zasługują na trening radzenia sobie ze stresem i negatywnymi emocjami co najmniej tak samo, jak pracownicy działów sprzedaży i call centers. Praca informatyków jest równie narażająca na złe emocje, przy czym otwartość problemów powoduje, że opanowanie i spokój są szczególnie niezbędne, aby radzić sobie z technicznymi wyzwaniami.

W świecie akademickim wiedza na temat podejmowania decyzji jest obfita. Obszerne i liczne badania poświęcono psychologicznym mechanizmom podejmowania decyzji. Nagroda Nobla z ekonomii w 2002 roku, przyznana Danielowi Kahnemanowi i Vernonowi Smith’owi za prace w zakresie podstaw ekonomii eksperymentalnej, była w znacznym stopniu nagrodą Nobla z eksperymentalnej psychologii decyzji, gdzie decyzje dotyczyły kwestii ekonomicznych5. Jej tematyka była kontynuacją przełomowych, liczących ponad 30 lat prac Tverskiego i Kahnemana poświęconych psychologicznym mechanizmom decyzji6.

Z drugiej strony, podejmowanie decyzji jest domeną statystyki, nauki nazywanej niekiedy nauką o podejmowaniu decyzji w sytuacji niepewności7.

Mimo tego, decyzje – nawet warte dziesiątki milionów złotych - nadal podejmowane są często po amatorsku, bez odpowiedniego przygotowania, analizy i narzędzi. Szkodzi tutaj mit silnego menedżera, co kierując się intuicją, w mgnieniu oka podejmuje ryzykowne decyzje, po czym – między zawałem a krótkotrwałym załamaniem nerwowym – zbiera zasłużone laury i krociowe zyski. Nie negujemy znaczenia intuicji – tak zwane racjonalne decyzje wymagają precyzyjnych danych, którymi zwykle albo nie dysponujemy, albo ich uzyskanie byłoby zbyt kosztowne. Tylko że intuicję trzeba umieć zastosować. W swojej znakomitej książce8 Richard Wiseman pisze, czym różnią się osoby postrzegane przez innych (i przez samych siebie) jako „szczęściarze” od osób postrzeganych jako „pechowcy”. Jedną z czterech podstawowych różnic jest właśnie umiejętność pójścia za głosem intuicji wtedy, kiedy brak innych przesłanek do podejmowania decyzji.

Intuicją przyjdzie nam posługiwać się wielokrotnie, bowiem nawet w najprecyzyjniejszym procesie zwykle zabraknie jakichś danych, które trzeba uzupełnić wyczuciem czy instynktem. Niemniej zastosowanie intuicji narażone jest na wiele pułapek. W sprawach wielowymiarowych, dynamicznych – a do takich zalicza się przecież większość decyzji podejmowanych w projektach informatycznych – zagrażają nam liczne psychologiczne mechanizmy, które – choć sprawdzały się znakomicie tysiące lat temu przy uciekaniu przed lawami i przy polowaniu na mamuty – dziś dramatycznie zawodzą9. Takie mechanizmy to np. przecenianie prawdopodobieństwa zdarzeń korzystnych a niedocenianie niekorzystnych, wyciąganie wniosków o zależności przyczynowej na podstawie obserwowanej korelacji oraz o korelacji na podstawie jednorazowego zdarzenia – i wiele innych.

Anna Mikołajewska,  Bogdan Bereza, www.bbjtest.pl, info@bbjtest.pl