Praca ludzie, uczeni

Kim powinien być dobry szef projektu informatycznego? Rzutkim, charyzmatycznym liderem, który umie przekonać innych do swojej wizji, porwać ze sobą? Zamkniętym w sobie, bojowym, zdecydowanym wbrew przeszkodom dążyć do celu, choć trochę oschłym i niezbyt lubianym wodzem? Spokojnym, uporządkowanym administratorem, dobrze koordynującym pracę innych? Dobrym fachowcem, inżynierem, specjalistą kierującym się zasadami, logiką i obliczeniami?

Kim powinien być dobry szef projektu informatycznego? Rzutkim, charyzmatycznym liderem, który umie przekonać innych do swojej wizji, porwać ze sobą? Zamkniętym w sobie, bojowym, zdecydowanym wbrew przeszkodom dążyć do celu, choć trochę oschłym i niezbyt lubianym wodzem? Spokojnym, uporządkowanym administratorem, dobrze koordynującym pracę innych? Dobrym fachowcem, inżynierem, specjalistą kierującym się zasadami, logiką i obliczeniami?

Praca ludzie, uczeni

Wykres 1

Odpowiedź na to pytanie zależeć będzie od wielu czynników. Jeśli wejdziemy w skórę uczestników przedsięwzięcia, to wymarzony szef będzie różny dla różnych osób, gdyż nie każdemu odpowiada ten sam styl zarządzania. Dalej, różni liderzy potrzebni są zależnie od tego, jaki jest projekt - jego cele, etap, ramy czasowe, złożoność i wymagania. W końcu, cechy wymarzonego kierownika zależą także od właściwości produktu, od związanych z jego wykonaniem wyzwań technicznych. Jednym słowem, nie da się nakreślić jedynego, uniwersalnego, pod każdym względem najlepszego obrazu idealnego kierownika, chyba żebyśmy poszukali Światowida - boga o czterech jednoczesnych obliczach, każdym patrzącym w inną stronę.

Podobnie miałyby się sprawy, gdybyśmy postawili pytanie o idealnego programistę. Kreatywny i niezależny, czy lepiej sumienny i starannie przestrzegający zasad? Skupiony na zadaniu i jego technicznych szczegółach, czy raczej otwarty, komunikatywny, samodzielnie zdobywający informacje i skutecznie przekazujący je innym? Dominujący, zdolny narzucić komuś swój punkt widzenia, czy też gracz zespołowy, znajdujący w pracy kolektywnej bezpieczeństwo i gotowość do działań na rzecz wspólnego celu? Bywa i tak, i tak, zależnie od okoliczności i próżno szukać jednoznacznej odpowiedzi, archetypu wzorowego programisty.

Sięgając po kolejne role spotykane w przedsięwzięciach informatycznych: inżyniera wymagań, projektanta systemu, projektanta interakcji oraz interfejsu, administratora projektu, inżyniera testów - trafimy na identyczne trudności. Wymagania co do cech osoby idealnej do każdej z tych ról zależeć będą od wielu czynników. Co więcej, uczestnicy projektu mogą z powodzeniem - zależnie od indywidualnych predyspozycji - swoje role nawzajem wspierać i uzupełniać. Charyzmatyczny, lecz nieco gorzej zorganizowany szef lider sprawdzi się znakomicie, jeśli wspomoże go w działaniu systematyczny, spokojny administrator. Skupionemu na zadaniu, małomównemu programiście przyda się pomoc komunikatywnego inżyniera wymagań i projektanta; tester pedantyczny i normatywny oraz tester skłonny do nietypowych, trochę zwariowanych scenariuszy testowych będą w tandemie o wiele skuteczniejsi niż każdy z osobna.

Mierzenie ludzi

Przyjmijmy na chwilę w uproszczeniu - choć poprzednio pokazaliśmy, że trudno uzyskać taką jednoznaczność - że wiemy dokładnie, jakiego człowieka poszukujemy do danej zawodowej roli. W jaki sposób zmierzyć człowieka, by móc odpowiedzieć na pytanie, jaki jest? Mierzeniem ludzi zajmuje się psychologia. Problem w tym, że odpowiedzi przez nią udzielane rzadko kiedy są precyzyjne i jednoznaczne, a ponadto dotyczą sfer, które bezpośredniego, łatwego do zinterpretowania znaczenia dla sytuacji w pracy nie mają. Nikt nie byłby specjalnie rozradowany, gdyby w celu wyboru osoby do pokierowania zespołem firma poddawała kandydatów głębinowym badaniom osobowości, wyciągając na powierzchnię traumatyczne przeżycia z dzieciństwa!

Dlatego potrzebna jest miara specjalnie dostosowana do potrzeb zawodowych. Faktem jest, że tak zwane miękkie czynniki odgrywają w powodzeniu przedsięwzięć informatycznych szczególną rolę, większą niż jesteśmy skłonni przyznać! Jak pisze w swojej książce "Inteligencja emocjonalna w praktyce" Daniel Goleman, porównując udane i nieudane kariery zawodowe, odkryjemy, że czynnikiem różnicującym jest przede wszystkim szeroko rozumiana inteligencja emocjonalna ludzi, a nie ich techniczne umiejętności.

W procesie rekrutacji, czy dobierając zadania do osób już zatrudnionych, zwykle jednak nie szukamy tytanów, twórców "Microsoftów" przyszłości, tylko po prostu osób sprawnych, pasujących do zadania. Jak je znaleźć? Intuicja bywa w tych sprawach niezwykle zawodna - poprzedzający zatrudnienie powszechnie stosowany wywiad, będący jakoby znakomitym pomiarem tajemniczej międzyludzkiej chemii, w rzeczywistości pozwala dobrać osoby postrzegane jako sympatyczne, niezagrażające - ale nie te, które najlepiej pasują do roli. Kto zresztą miałby taki wywiad przeprowadzać? Dział personalny ma tylko mgliste pojęcie o tym, jakie cechy predysponują najlepiej do określonej roli w technicznym dziale lub projekcie. Zanim przejdziemy do omówienia metody, która pozwala skutecznie radzić sobie z tymi trudnościami, przyjrzyjmy się jeszcze, gdzie w przedsięwzięciach informatycznych miękkie, psychologiczne i społeczne czynniki ogrywają rolę szczególną.

Macierz psychologiczno-informatyczna

Inżynieria wymagań - Pewnie, że psychologia i socjologia mają w tej dziedzinie duże znaczenie! Niejednoznaczne wymagania (język naturalny), kłopoty z odmiennymi filtrami poznawczymi, które przy pozyskiwaniu wymagań stosują zleceniodawcy i wykonawcy, nawiązanie relacji i komunikacja między stronami kontraktu. Można się nieźle i złośliwie ubawić, słuchając wywodów informatyków, szkolących np. z UML, na temat ezoterycznych zagadnień strefy intymnej, prywatnej, społecznej, publicznej w komunikacji międzyludzkiej…

Praca ludzie, uczeni

Wykres 2

Projektowanie, kodowanie - O psychologii programowania napisano sporo. Kreatywność, umiejętność rozwiązywania pro-blemów - ten aspekt się narzuca. Mamy też do czynienia z próbami instrumentalnego traktowania psychologii, kiedy wątpliwą tezę o jakoby bardziej obiektowym niż strukturalnym sposobie ludzkiego poznania (cokolwiek to miałoby znaczyć) używa się dla wsparcia teorii o wyższości UML nad JSP, a języka Java - nad językiem C.

Testy, zapewnienie jakości - Psychologia testowania to temat obowiązkowy na każdym szkoleniu z podstaw testowania. Mamy tutaj i dyplomatyczne formułowanie wiadomości o znajdowanych defektach, i asertywne unikanie roli kozła ofiarnego czy "odkurzacza", jak tę rolę określa w swoim znanym tekście "Tester is not a vacuum cleaner" znany guru Hans Schaefer. Dynamika grupowa, znaczenie celu dla wyników pracy - przykładów jest wiele.

Zarządzanie przedsięwzięciami - Tutaj łatwiej niż gdzie indziej o psychologię, ale i o podejrzane psychologizowanie. Temat dobrze, choć często pobieżnie, znany każdemu, więc chwilowo pominę go.

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

TOP 200