Od biurokracji do technokracji. IT bierze odpowiedzialność biznesową za produkt

Przez wiele lat kariera w IT kojarzyła się raczej na poruszaniu się w dość wąskiej i specyficznej grupie zawodowej, przez postronnych zwanej „kosmitami”. Wielu z nas, którzy wyrośli w takim przekonaniu, dziś ma już na karku dobre „naście” lat doświadczenia w branży, i zastanawia się co dalej? Pogłębiać wiedzę ekspercką i ustatkować się na wygodnej niszy? Zainwestować zarobione pieniądze w hodowlę jedwabnika i przeprowadzić się w Bieszczady? W tym artykule chciałbym zaproponować inną drogę, czerpiącą w pełni z ery technokracji. Droga ta pozwoli nam wziąć odpowiedzialność nie tylko za „bugi” na produkcji, ale za cały wizerunek naszej firmy, wartość produktu i atrakcyjność usług, które stworzymy. Dla zachęty dodam, że oferta ta jest jak najbardziej aktualna także dla tych, którzy wspomnianego doświadczania mają dużo mniej lub prawie wcale.

Piotr Guziorski. Product Manager w Robert Bosch Sp. z o.o. Ukończył Politechnikę Śląską na kierunku Automatyka i Robotyka, Przetwarzanie informacji w procesach biotechnologicznych oraz Inżynierię oprogramowania na Politechnice Warszawskiej. Na co dzień zaangażowany w duży produkt integrujący dane z rozproszonych systemów. Specjalista od usług sieciowych i technologii danych, orędownik User Experience. Jest bywalcem hackathonów, konferencji oraz meetupów (jako uczestnik i prelegent).

„Oprogramowanie zjada świat”

Wielkie koncerny wielobranżowe, które budowały swoją potęgę w oparciu o kolejne zdobycze rewolucji przemysłowej, dziś borykają się z nietypowym wyzwaniem. Poruszając się w świecie fizycznych produktów, wymagających rozbudowanych warstw logistycznych, materiałów, linii produkcyjnych, fabryk i potężnych hal montażowych, nie są w stanie szybko reagować na nową formę konkurencji wirtualnej/cyfrowej.

„Oprogramowanie zjada świat (a usługi zjadają oprogramowanie)”: tak w 2001 roku Marc Andreessen na łamach “Wall Street Journal” opisywał nowo powstające koncerny technologiczne w starciu z klasycznymi korporacjami wielobranżowymi. Najciekawsze w tym wszystkim jest to, że przeciwnik wyrastał na podwórkach wielu korporacji jako struktura wspierania klasycznego manufacturingu. IT było wsparciem dla jeszcze lepszej, szybszej i zwinnej produkcji oraz dla bardziej inteligentnych produktów wyposażonych w coraz więcej elektroniki. Tak właśnie Toyota rozwinęła swoje heurystyki produkcyjne (JobShop), a Siemens protokoły komunikacyjne między sterownikami (Modbus). Podobne przykłady można by przytoczyć dla większości gigantów np. z sektora motoryzacyjnego.

Szybko okazało się też, że warianty wytwarzanych produktów coraz bardziej różnicuje nie mechaniczny „design”, ale układy elektroniczne, a w konsekwencji oprogramowanie. Łatwiej i taniej wyprodukować jest jeden fizyczny wariant silnika, a jego osiągami manipulować za pomocą układów cyfrowych, niż co generacje zmieniać konstrukcje fizyczną. Tak oto z początku działy IT pochłaniały coraz to więcej aspektów wytwarzania i przejmowała coraz to więcej odpowiedzialności biznesowej. W tym samym czasie na rynku zaczęły pojawiać się pierwsze firmy technologiczne bazujące na popularyzacji tzw. „personal computing”: Microsoft, Apple, Oracle, SAP (lata 70te, 80te). Zwłaszcza ten ostatni stał się niezastąpionym graczem dla wielu korporacji motoryzacyjnych i nie tylko. Pojawienie się tych firm z kolej przyczyniło się do następnej fali, związanej z budowaniem wirtualnych usług w oparciu o globalną sieć: Google, Amazon, PayPal. I znów dzięki tym graczom, możliwe było stworzenie takich platform jak Facebook czy Tweeter, których domeną stało się zmniejszanie świata przez web 2.0 i social media.

W świetle starć tych dwóch „pokoleń” korporacji: manufacturingowej vs technologicznej nastąpiła i nadal następuje szeroka i głęboko zakrojona rewolucja dotykająca każdej sfery przedsiębiorstwa. Należy jednak pamiętać, że żadna ze stron tego starcia nie jest w stanie funkcjonować oddzielnie. Technologia powstaje w oparciu o istniejącą infrastrukturę (elektryczną, sieciową, itd.), z kolej fizyczne produkty potrzebują nowoczesnych protokołów komunikacyjnych by być coraz bardziej inteligentne.

W wyniku tych starć powstają fundamenty kolejnej rewolucji przemysłowej 4.0 wraz z jakże już powszechnym trendem Internetu Rzeczy (IoT).

Co z tego przydługiego wstępu wynika dla specjalistów z branż technologicznych? Okazuje się, że transformacja „starych” przedsiębiorstw z biurokracji do technokracji otwiera nowe ścieżki kariery, poszerzając zasięg stanowisk o odpowiedzialność biznesową. Dziś kariera programisty nie musi kończyć się na „Seniorze” przygarbionym przed 17 calowym monitorem CRT, gdzieś w podziemiach korporacyjnej piwnicy. Dziś programista może, a nawet powinien brać branżową odpowiedzialność za biznes oraz dzięki swojej wiedzy umożliwiać tworzenie nowych dziedzin rozwoju firmy.

Oczywiście nie jest to jedyna droga rozwoju w obecnym świecie IT. Można też obrać kierunek specjalizacyjny, których jest wiele: Big Data, IoT, Cyber Security, itd. Można też outsourcingować całe IT i żyć w błogiej ignorancji. W tym artykule jednak chciałbym poświęcić najwięcej uwagi tym stanowiskom, które poszerzają horyzonty i wymagają spojrzenia na biznes z większą odpowiedzialnością i ambicją, tj. Menadżerom Produktów i usług technologicznych (IT Product Manager), właścicielom produktów (Product Owner). Tylko dzięki temu nie narażamy się (my, pracownicy) na hermetyczność i krótkowzroczność, a co za tym idzie: trudniej będzie nas zastąpić. Należy mieć także świadomość, że opisane wyżej role są tylko „etykietami” dla różnych nazw stanowisk, które mniej lub bardziej oscylują wokół produktu. Istnieją też stanowiska bardziej związane z technologią czy architekturą korporacyjną (IT Chief Archtect), która sama w sobie ma być aktywatorem do nowych usług.

Zarządzanie produktem IT: role kontra stanowiska 

Zanim zaczniemy się zastanawiać, jak skutecznie zrzucić szary sweterek i zarządzać produktami jak hotelami w eurobiznesie, wypada wyjaśnić różnicę między rolą produktową a stanowiskiem produktowym. Żeby nie trzeba było wynajmować do tego różdżkarza, poniżej załączam dwukolumnową tabelkę, której celem jest rozróżnienie, co jest czym.

Oczywiście nic nie jest zawsze binarne. Zarówno rola, jak i stanowisko, mogą być mniej lub bardziej „techniczne” lub „biznesowe”. Jeżeli w danym momencie kariery stricte technicznej, mamy okazję współpracować z działami marketingowymi będzie to dla nas świetne doświadczenie w budowaniu przyszłej ścieżki kariery. Analogicznie, kontakt z ekspertami technicznymi, po latach stażu w działach handlowych pozwoli nam tworzyć innowacyjne rozwiązania i imponować klientom wiedzą. Warto szukać jest okazji do wyjścia poza ramy swoich codziennych zadań, szukać „poza działowych” kontaktów i spojrzeć na produkty, usługi w sposób holistyczny. Nie bójmy wychodzić się ze swojej strefy komfortu i wręcz prosić o przydzielenie ról spoza naszego pola ekspertyzy.

Jeśli miałbym jednym zdaniem opisać, czy lepiej mieć rolę czy stanowisko, napisałbym tak: „Nie wiesz, czy product management to Twój konik? Przyjmij rolę. Zarządzasz już n-tym projektem IT i chcesz wreszcie pójść o krok dalej? Przyjmij stanowisko”. Ja wiem, każdy może mieć inne okoliczności i możliwości odnośnie wyboru, ale moim zdaniem każda ścieżka rozwoju to krok naprzód.

Dwie drogi do zarządzania produktem 

Z góry przepraszam za podejście binarne. Na pewno jest więcej możliwych ścieżek rozwojowych kończonych się stanowiskiem produktowym. Niemniej jednak chciałbym się skupić na dwóch najbardziej typowych i chyba najbardziej oczywistych. W poprzednich tabelach nakreśliłem już trochę aspekty ról i stanowisk technicznych versus biznesowych. Łatwo więc uzmysłowić sobie, że pochodzenie specjalistów na tych stanowiskach jest właśnie albo z działów sprzedażowych, marketingowych albo z działów technicznych, teleinformatycznych. I jedni i drudzy mają jednakową szansę być świetnymi specjalistami od produktu. Wystarczy tylko przekierować cześć swojej wiedzy na właściwe tory.

Niezależnie od tego, z której „strony” rozwojowej się przychodzi, trzeba dobrze zaprzyjaźnić się z kilkoma metodykami pracy i pojęciami. Wybór metod oparty jest na założeniu, że będziemy pracować z grupami i organizacjami zarówno zwinnymi jak i hierarchicznymi, z biurokratami i technokratami, z analitykami i z marketingowcami, z introwertykami i z protagonistami. Cel jest jeden: zbudować wokół siebie „cross” – funkcyjną sieć adwokatów naszego produktu lub usługi. Kolejna porcja metodyk związana jest oczywiście z potencjalnymi udziałowcami, klientami i końcowymi użytkownikiem. W ramach tych grup naszym zadaniem będzie budowanie wizerunku i odważne przejmowanie odpowiedzialności za biznesowe rezultaty. Musimy umieć przedsiębiorczo spojrzeć na powierzone nam zasoby akcjonariuszy i traktować je równie ostrożnie jak nasz własny domowy budżet czy własne przedsięwzięcie. Taka postawa siłą rzeczy sprawi, że będziemy odbierani jako osoby profesjonalne, odpowiedzialne i autentyczne.

Zarobki: oczekiwania kontra rzeczywistość 

Zarobki jak zwykle zależą od szeregu czynników: począwszy od branży, w której działa korporacja; doświadczenia; stażu pracy; lokalizacji, specyfiku produkty/usługi (zwłaszcza jego krytyczności dla biznesu), a skończywszy na organizacyjnej strukturze i szczeblach kariery. Nie ma prostej formuły mówiącej, ile powinien zarabiać Product Manager czy Product Owner. Owszem, istnieją pewne widełki, są one jednak tylko uśrednieniem wszystkich wyżej wymienionych aspektów. Jeżeli chcemy mieć największy wpływ na wysokość naszych zarobków jako product manager skupmy się na cechach i umiejętnościach najbardziej oczekiwanych przez pracodawców. Może to zabrzmi banalnie, ale w dużym skrócie: jeżeli chcemy, aby nasze produkty były unikalne, potrzebne i pożądane, sami musimy tacy być.

Po pierwsze: cechy pożądane

• Asertywność
• Dalekowzroczność
• Przedsiębiorczość
• Komunikatywność
• Wiedza i doświadczenie biznesowe i/lub techniczne

Po drugie: unikalne umiejętności

• Myślenie analityczne i zorientowane no ciągłe pogłębianie wiedzy. Nie wystarczy już zaproponować rozwiązanie na wszystko. Trzeba umieć zgłębić problem klienta nawet jeśli to oznacza, że nic mu nie sprzedamy. Istotne jest też umiejętne korzystanie ze zdobytego doświadczenia. Często będziemy pracować po presją czasu, warto jest więc stworzyć sobie bibliotekę szablonów problem/rozwiązanie, które w przeszłości zdawały egzamin. Nasze propozycje powinny być zawsze podparte twardymi danymi bądź dobrze udokumentowanymi doświadczeniami.
• Umiejętność komunikacji z różnymi typami osobowości. Klient ma zawsze rację, chyba, że jej nie ma prawda? No właśnie, w naszej karierze przyjdzie nam się zetknąć z każdym możliwym charakterem i musimy umieć błyskawicznie te charaktery rozpoznawać. Musimy też dysponować wachlarzem narzędzi ułatwiającym nam radzenie sobie z klientem trudnym.
• Umiejętność poruszania się na odpowiednim poziomie szczegółowości. Tak jak będziemy mieli do czynienia z różnymi osobowościami, tak i przyjdzie nam się zmierzyć z różnymi poziomami wiedzy. Nie każdy nasz klient zainteresowany będzie głębokimi technikaliami. Musimy wytworzyć w sobie umiejętność komunikowania niezbędnego minimum i wychwytywania tych momentów, kiedy po prostu powiemy “To są już szczegóły techniczne, pozwólmy fachowcom nas wyręczyć”.
• Eklektyczne podejście do stosowanych technologii. Technologia ma służyć produktowi, a nie odwrotnie – chyba, że sama jest produktem. Era monolitycznych narzędzi się skończyła. Nasz produkt czy usługa musi zapewniać interoperacyjność i integralność z innymi produktami i usługami nawet jeśli są one konkurencją. W związku z tym musimy być elastyczni w wyborze technologii. Wyzwaniem jest posiadanie wiedzy na temat tak wielu różnych aspektów technicznych, nie oznacza to jednak, że musimy je znać kompletnie. Reguła Pareto (80/20) dobrze zdaje tutaj egzamin. Na przykład: 80% aplikacji korporacyjnych korzysta z 20% dostawców chmurowych. Reguła jest symetryczna, więc posiadanie wiedzy o najpopularniejszych graczach na rynku “cloud” pozwoli nam skutecznie wspierać 80% aplikacji korporacyjnych.
• Przywiązanie do wysokiej jakości. Dobre wrażenie można zrobić tylko raz. Dlatego nie tylko samo rozwiązanie/produkt musi być najwyższej możliwej jakości, ale także cały proces jego tworzenia, raportowania i komunikacji z kluczowymi interesariuszami. Naszym zadaniem jest budowanie marki i wizerunku, jesteśmy twarzą tego, co sprzedajemy.
• Umiejętne zarządzanie ludźmi i zasobami. To, jak rozporządzamy talentami zespołu produktowego, jest nierozerwalnie związane z jego sukcesem. Musimy umieć zarażać innych entuzjazmem i dzielić się sukcesami produktu ze wszystkimi, którzy przyłożyli do niego rękę. Co najważniejsze, powinniśmy umieć wywierać wpływ na naszych klienta, zespół produktowy czy innych interesariuszy i jeśli trzeba walczyć o niezbędne zasoby, aby zapewnić najwyższą jakość.

Powyższe wskazówki pozwolą Wam podjąć decyzję o tym, jak pokierować dalej swoją karierą. Ekspert technologiczny, Product Manager, a może jednak jedwabniki? Decyzja należy do Was.

Zdjęcie główne artykułu pochodzi z unsplash.com