Po drugiej stronie lustra. O percepcji interakcji interdyscyplinarnych w IT.

Jeśli miałbym opisać się jednym zdaniem, to chyba odruchowo powiedziałbym, że jestem programistą. Tak zawsze o sobie myślałem i choć moja ścieżka kariery zaprowadziła mnie do odmiennych krain, to nadal głęboko w sercu tak się czuję. 

Programowanie to nie tylko pisanie kodu – to specyficzny, merytoryczny, logiczny, obiektywny i racjonalny sposób postrzegania rzeczywistości. Z tej właśnie perspektywy starałem się pisać poprzednie artykuły, oczywiście poszerzonej o moje późniejsze postprogramistyczne doświadczenia, ale jednak nadal był to punkt widzenia osoby technicznej. Z tego względu nigdy tak naprawdę, mimo zmieniających się technologii i ewolucji procesów, nie postrzegałem siebie jako laika w kontekście projektów IT, nawet tych budowanych na kompletnie mi obcych stackach technologicznych. Dlatego też nigdy, a przynajmniej nie świadomie, nie stałem po tej drugiej stronie, czyli często nietechnicznej części dostarczanych przez nas rozwiązań czy produktów. Od wielu lat natomiast operuję na granicy styku pomiędzy tymi dwoma warstwami organizacyjnymi i, niestety, muszę stwierdzić, że mimo postępów w obszarach metodologii pracy w sektorze IT, nadal nie udało nam się kompletnie wypełnić przepaści komunikacyjnej pomiędzy nimi.

Do tej pory wielu programistów kategorycznie odżegnuje się od tzw. pracy z ludźmi. Oczywiście chodzi tu o tych „ludzi gorszego sortu”, którzy nie rozumieją naszego żargonu i którym wszystko trzeba tłumaczyć sto razy, a i tak niczego nie zrozumieją. Oni w zamian traktują nas z góry jako „piwniczaków” we flanelowych koszulach, kompletnie oderwanych od rzeczywistości, w której przecież żyje większość ludzi. I tak, mimo upływu lat, przytykamy sobie nawzajem tymi zbędnymi i krzywdzącymi epitetami, co dowodzi tylko tego, jak ważna w IT jest umiejętność przejrzystej komunikacji, do czego obydwie strony podchodzą ze swoimi uprzedzeniami i stereotypami.

Grzechy główne

Tak, jak wyżej zaznaczyłem: obydwie strony aktywnie przyczyniają się do przedłużania tego patologicznego statusu quo ,dlatego też chciałbym na początku rozliczyć je z najbardziej rażących przewinień. Zacznijmy zatem od tej strony bliższej mojemu sercu.

„Elita”

Tak, wielu programistów uważa się za lepszych od osób nietechnicznych. Ja osobiście ograniczyłbym się jedynie do prostszego i bardziej precyzyjnego określenia, że programiści są lepsi w wykonywaniu swojej pracy od osób, które tej pracy nie wykonują. Jest to oczywiście truizm, w końcu właśnie z tego powodu zostaliśmy zatrudnieni do wypełniania takich ról. Spędziliśmy często długie lata, nabywając konkretne umiejętności oraz doświadczenia, przez co, niestety, dużo osób patrzy na projekty IT dość jednostronnie i stara się mierzyć wszystkich jedną miarą. Nie pomaga w tym wspomniane biznesowe traktowanie nas z góry jako „społecznych troglodytów”, co w efekcie końcowym tworzy ognisko zapalne, po którego obydwu stronach stoją ludzie, którzy po prostu się nawzajem nie rozumieją, przez co podchodzą do siebie z dystansem i uprzedzeniami. Innymi słowy: nad zdrowym rozsądkiem wygrywa wydumane ego. 

Poczucie własnej wartości

U podłoża wywyższania się wielu programistów leży świadomość inwestycji czasowych oraz poświęceń życiowych, które doprowadziły ich tu, gdzie są, a która zderza się z często archaiczną hierarchią tradycyjnego modelu zarządzania, czyli warstwą kierowniczą. Dużo ludzi po tamtej stronie sporu czuje się zagrożonych tajemniczymi arkanami sztuki programistycznej lub ogólnie szeroko rozumianej technologii, gdyż sami podążyli często kompletnie odmienną ścieżką kariery, przez co ich kwalifikacje nie przenoszą się zbytnio na tą jakże specjalistyczną domenę. Tutaj uruchamia się pierwotny instynkt strachu przed nieznanym czy niezrozumiałym, co prowadzi do przejawiania mniejszego lub większego kompleksu niższości poprzez epatowanie swoją pozycją w hierarchii. To z kolei dolewa oliwy do ognia i jeszcze bardziej eskaluje konflikt, negatywne odbijając się na współpracy, a często również jakości produktu i procesach wytwarzania oprogramowania.

Kompromis?

Co zrobić zatem w sytuacji, w której obydwie strony nie kwapią się do budowy mostu porozumienia w celu zapewnienia lepszej współpracy pomiędzy nimi? Mahatma Gandhi  kiedyś powiedział, że oko za oko czyni cały świat ślepym. Jednak mimo ogromu czasu, który mieliśmy na przyswojenie tej mądrości życiowej, nadal pozostajemy głusi na jego przesłanie. Wzajemne antagonizowanie się nigdy nie rozwiąże problemów leżących u podnóży tej sytuacji. Aby można było mówić o jakimkolwiek planie naprawczym, obie strony muszą przeprowadzić rachunek sumienia i przyznać się przed samymi sobą do swoich uprzedzeń, po czym z otwartymi umysłami postarać się zrozumieć drugą stronę. Prawda bowiem, jak często bywa, leży gdzieś pośrodku.

Złoty środek

Jaka zatem brzmi ta prawda? Otóż bardzo zdroworozsądkowo. W zdrowej organizacji, reprezentującej pozytywną kulturę pracy, każdy ma swoją rolę do wypełnienia, która jest nieodzowną częścią składową procesu dostarczania produktów cyfrowych. Dlaczego takie uściślenie? Ponieważ nie chciałbym się skupiać na patologiach organizacyjno-metodologiczno-transformacyjnych, o których wspomniałem już wielokrotnie we wcześniejszej twórczości na łamach tego magazynu. Jeżeli odrobinę utopijnie założymy, że każdy element hierarchii, w której się znajdujemy, jest produktywnym członkiem zespołu, to w interesie wszystkich jego współpracowników powinna być wzajemna optymalizacja wydajności. Jeżeli (znów ponownie trochę optymistycznie) przyjmiemy, że każdy pracownik w organizacji jest w stu procentach kompetentny do wypełniania swoich obowiązków, to zobaczymy, że aby całość była większa od sumy jej indywidualnych części, należy zwrócić szczególną uwagę na to, jak układamy te „ludzkie puzzle”, bowiem to właśnie odpowiednie ich połączenie gwarantuje najlepszą wydajność oraz najzdrowszą kulturę pracy. Jak zatem tego dokonać?

Śmierć polityce

W mojej opinii u podnóży omawianego problemu leży obustronny strach, który w świetle powyższego akapitu może wywodzić się z braku zaufania. Kierownik nie wierzy, że nienadzorowany w tradycyjny sposób patrzenia przez ramię programista (czy cały zespół) wykona w swoja pracę w sposób sumienny, a ten z kolei nie wierzy w dobre intencje swoich przełożonych, ponieważ nie dostrzega ogromu nietechnicznych procesów mających wpływ na pracę firmy. Ponownie świadomie pominę patologiczne przykłady sytuacji, w których uprzedzenia byłyby jak najbardziej uzasadnione. Zamiast tego, zakładając szczere intencje obydwu stron, przyjrzyjmy się krytycznemu punktowi styku komunikacyjnego – zderzeniu dwóch na pozór kompletnie odmiennych światów i temu, jak je ze sobą pogodzić.

Ewolucja

Historycznie w wielu projektach IT, zwłaszcza tych z poprzedniej dekady, element tradycyjnie zarządzający organizacją był równocześnie tym decyzyjnym w kwestiach produktowych, co – na szczęście – od jakiegoś już się zmienia i można zaobserwować gwałtowny rozwój powiązany ze wzrostem nowej medialnej świadomości rynkowej w postaci uformowania się specjalizacji produktowych oraz UX-owych. Tak, dokładnie tych, na których skupia się ten właśnie magazyn. Dzięki temu nastąpiło wydzielenie odpowiedzialności za niejako miękkie oraz skoncentrowane za użytkowniku aspekty dostarczanych projektów i przypisanie ich dedykowanym ekspertom, co – w porównaniu do archaicznego modelu, w którym często pojedynczy UI designer projektował interfejs użytkownika pod dyktando swojego nieobeznanego w tej kwestii szefa – jest ogromnym krokiem naprzód. Merytoryczne oraz bazujące na danych z analiz rynkowych podejście zdecydowanie ułatwiło komunikację w obydwu kierunkach: biznes wreszcie w sposób zrozumiały dla siebie mógł obserwować rozwój dostarczanego produktu, a warstwie technicznej zdecydowanie łatwiej było porozumieć się z zespołem produktowym w oparciu o obiektywne fakty zamiast subiektywną opinię. W idealnym świecie to byłby koniec tego artykułu. Problem rozwiązany poprzez powstanie śródorganizacyjnej warstwy produktowej, pełniącej rolę mostu komunikacyjnego pomiędzy zwaśnionymi stronami. Niestety, w świecie rzeczywistym często doprowadziłoby to także do rozproszenia niektórych elementów konfliktowych na trzy zamiast dwie warstwy organizacyjne oraz dodatkowo skomplikowałoby niektóre aspekty komunikacyjne.

A miało być tak pięknie

Ponieważ powyżej opisana nowo powstała specjalizacja produktowa bardzo szybko się rozwinęła, doprowadziło to do powielenia schematu behawioralnego modelu komunikacyjnego poprzedzającego jej genezę, czyli w skrócie: pojawiła się kolejna niszowa domena wiedzy (mniej „piwniczna”, przez co jednak bardziej zrozumiała dla osoby niewtajemniczonej) do przyswojenia przez tradycyjną warstwę kierowniczą. Skutek? Tak, ponownie pojawił się strach spowodowany brakiem zrozumienia oraz zaufania. Zatem co dalej? Otóż na pomoc przychodzi jedno z moich ulubionych powiedzeń branżowych.

Nie po to zatrudnia się ekspertów, żeby im mówić, jak mają pracować

Z lekkim przerażeniem przewertowałem w mojej pamięci sytuacje, w których musiałem się nim posłużyć na przestrzeni ostatnich kilku lat, aby spróbować pohamować zapędy osób na kierowniczych stanowiskach wewnątrz mojej własnej organizacji, ale to już temat na oddzielny artykuł. Chciałbym jednak zaznaczyć: wielokrotnie już wspomniany strach jest wiecznie żywy i jeszcze długo będziemy z nim walczyć, a najlepiej to robić, używając pozytywnego feedbacku zwrotnego zamiast walki na noże. Jak zatem, o ile to w ogóle możliwe, raz na zawsze rozprawić się z tym brakiem zaufania?

Ewolucja struktur organizacyjnych

O ile zawsze, w każdej firmie, nawet tej z sektora IT, będą się pojawiać te stricte tradycyjne elementy zarządzania, o tyle czas uświadomić ogół społeczeństwa tej branży, zwłaszcza na poziomie dyrektorskim, że nie zawsze jest on najlepszym wyborem. Pomimo postępów w optymalizacji procesów projektowych na przestrzeni ostatnich dwóch dekad, na wyższych poziomach w hierarchii organizacyjnej nadal niesprawiedliwie gloryfikowane są niektóre kwalifikacje zawodowe, które merytorycznie kompletnie nie są związane ze specyfiką technologii. Najbardziej ewidentnym i wzbudzającym we mnie grozę tego przykładem są sytuację, w których w procesie rekrutacyjnym na pozycję – dajmy na to – Scrum Mastera widzę profil oldschoolowego IT Project Managera z MBA. Absolutnie niezrozumiałym jest dla mnie fakt, że w erze ekstremalnych specjalizacji nadal pochwalany jest stereotyp tradycyjnej ścieżki kariery kierownika sprzed rewolucji cyfrowej schyłku zeszłego wieku. Czas odesłać ten przestarzały konwenans do lamusa – tak, jak stało się to z innymi archaizmami w stylu tatuaż to kryminał, a założenie garnituru to automatyczne plus dziesięć punktów na rozmowie kwalifikacyjnej. Tak, jak wspomniałem w artykułach o rekrutacji oraz budowaniu kultury pracy w IT: osoby prowadzące rekrutacje często przy wyborze kandydatów wybierają ludzi podobnych do siebie i mniej lub bardziej świadomie powielają swoje uprzedzenia. No bo kogo ma zatrudnić charyzmatyczny mistrz excelowych tabelek, często sam będący na wysokim szczeblu w hierarchii firmy, jeśli nie rozumie niszowej specyfiki podległego stanowiska? Tutaj pozwolę sobie przytoczyć przykład kierownika działu, pod którym kiedyś miałem „przyjemność” pracować, a który został zatrudniony w czasach pierwszej fali transformacji agile’owych wyłącznie dzięki temu, że oczarował osobę kompletnie nietechniczną podstawowym żargonem metodologicznym, którego – jak sam później się okazało – nie rozumiał. Konsekwencji takiej polityki zatrudnieniowej chyba nie trzeba nikomu wyjaśniać. 

Halo, ale przecież miało być o budowaniu mostów komunikacyjnych, a nie wytykaniu patologii

Zgadza się, dlatego kajam się i błagam czytelnika o wybaczenie, oczywiście tego biznesowego, ponieważ w tym momencie każda osoba techniczna przypomina sobie swoje traumatyczne przeżycia z tej kategorii. Niemniej zdaję sobie sprawę, że sam też, mimo lat współpracy, nadal mam swoje uprzedzenia i, niestety, często zbyt łatwo jest mi sprowadzić niektóre osoby do krzywdzących stereotypów. A przecież wszyscy jesteśmy ludźmi, z tymi samymi potrzebami, które jedynie manifestują się w innych domenach specjalizacyjnych. Dlatego też apeluję do wszystkich stron zaangażowanych w dostarczanie projektów w IT o bardziej otwarte umysły w interakcjach interdyscyplinarnych. Zdajmy sobie wszyscy sprawę, że często posługujemy się innymi żargonami i patrzymy na różne problemy czy wyzwania z bardzo indywidualnych perspektyw, co przecież samo w sobie nie ujmuje wartości stanowisk zajętych przez naszych współpracowników, niezależnie od ich ścieżki kariery czy departamentu, którego są częścią. 

Podsumowanie

W świetle powyżej opisanej problematyki komunikacyjnej pomiędzy różnymi warstwami organizacyjnymi w miejscach, w których pracujemy, chciałbym zwrócić szczególną uwagę na kilka wynikających z tego kwestii. Nawet z najszczerszymi intencjami zrozumienia i współpracy muszę wytknąć „niesektorowość” profili specjalizacyjnych osób na wysokich szczeblach kierowniczych czy dyrektorskich. Pokutują wspomniane już klasyczne ścieżki rozwoju targetowane na te właśnie role, które później,w błędnym kole potrzeby autowalidacji, mielą się w nieskończoność. O ile zdaję sobie sprawę, że na zmiany potrzeba czasu, o tyle chciałbym zdecydowanie zaznaczyć, że w mojej opinii jest to numer jeden, jeśli chodzi o przyczyny wszelkich problemów organizacyjnych w sektorze IT. Schemat ten został przecież boleśnie przerobiony przez chociażby sektor motoryzacyjny, gdy w erze optymalizacji kosztów do zarządzania koncernami zostały zatrudnione osoby bez doświadczenia domenowego, skutkiem czego ucierpiała nie tylko jakość, ale też wartość rynkowa oraz reputacja wspomnianych marek. Dlatego też chciałbym niejako demistyfikować aspołeczną percepcję osób technicznych, przy jednoczesnym uderzeniu się w pierś i przyznaniu do winy posługiwania się stereotypami, i powiedzieć, że będąc jedną nogą po drugiej stronie lustra widzę, jak długą drogę musiałem przebyć, aby samemu zrozumieć naturę biznesowo-technicznych, a teraz już biznesowo-produktowo-technicznych, problemów komunikacyjnych. Tym samym zachęcam Was do wstąpienia na tę samą ścieżkę autorefleksji, niezależnie od tego, po której stronie znajduje się Wasza rola – a tym bardziej, jeżeli – jak ja – stoicie na granicy tych dwóch lub trzech światów, a już najbardziej, jeżeli z dyrektorskiego fotela kształtujecie kulturę swojej organizacji. Nie dajmy się zwieść charyzmatycznym technikom sprzedażowym i skupmy się wszyscy na merytorycznym i wspólnym dostarczaniu jakości.