Warto zarządzać w IT – oto dlaczego

Dawno temu (trochę zbyt dawno, patrząc tak z perspektywy uciekającego życia), idąc na studia Zarządzania na Uniwersytecie Warszawskim nie miałem szczegółowo określonego celu. Jak większość młodych ludzi, kierunek wybrałem bez ścisłego harmonogramu swojego przyszłego rozwoju. Zarządzanie brzmiało ciekawie – dobrze też było wyobrazić sobie siebie jako dumnego menedżera, zarządzającego zapatrzonym w niego zespołem. Mimo solidnego backgroundu komputerowego nie spodziewałbym się jednak wtedy, że będę zarządzał projektami IT. Teraz, gdy już nim jestem wiem jedno – oby tak dalej!

Ludzie mają ambicje zarządzania z różnych powodów. Jedni zafascynowani są siłą i wpływem, jaki się z tym wiąże. Inni lubią po prostu realizować projekty i pilnować, aby wszystko się udało (mi zdecydowanie najbliżej jest do tej grupy). Jeszcze inni natomiast zostają kierownikami, ponieważ mają już solidne doświadczenie zawodowe i są po prostu najlepszymi ludźmi do tej roli. Ja mimo swojego młodego wieku zostałem menedżerem przypadkiem – akurat zwolniło się w Orange miejsce dla Product Ownera jednego z projektów w kluczowym programie.

Od tego czasu nabrałem mnóstwo doświadczenia. I wiem już, że nie chciałbym zajmować się w życiu niczym innym. Dlaczego?

Każdego dnia uczysz się czegoś nowego

I nie mam tu na myśli farmazonów pokroju „zdobywania doświadczenia dzięki pracy u lidera branży” czy „nieskrępowanych możliwości rozwoju zawodowego i osobistego”. Branża IT jest specyficzna – pełna nowych i starych technologii, które przydają się w określonych sytuacjach, a w innych są kompletnie zbędne. Co więcej, technologie te ulegają również pewnego rodzaju modzie, tak jak design (Angulara do front-endu komuś?).

Odkrywanie tajemnic hurtowni danych i rozwiązań obiektowych na wielkich, pełnych terabajtów danych systemach było dla mnie jak przyswajanie nowych teorii naukowych z zakresu fizyki kwantowej. Z początku to wszystko wydawało się nie mieć sensu, być niepotrzebne i nie z tego świata – aż w końcu zacząłem rozumieć, jak akurat takie podejście może przynieść realną korzyść dla biznesu ponad zwykłymi bazami transakcyjnymi.

Zauważenie, że front-end skomplikowanej aplikacji to zwykły HTML + CSS uzupełniony o AngularJS i JavaScript było dla mnie olśnieniem – to przecież nie różni się aż tak bardzo od tworzenia designu na bloga (przynajmniej na Drupalu 6, ugh)! A ja, głupi, byłem przekonany, że siedzi tam jakiś kosmiczny fragment kodu, którego nie pojmę nawet za 2 lata…

Takie odkrywanie meandrów świata tworzenia oprogramowania otwiera umysł. Zacząłem szybko łapać się, że chcę wgryźć się w każdy koncept programistyczny, zrozumieć akurat taką, a nie inną strukturę bazy danych… Zdarzało mi się nawet odpływać, gdy przy analizowaniu nowej funkcjonalności do zrobienia zacząłem rysować na kartce papieru nowe tabele do bazy danych. Zostałem za to słusznie skarcony przez programistów – w końcu to nie moja robota, a oni zrobią to lepiej ode mnie.

Pokora i szacunek do pracy drugiego człowieka

I tu dochodzimy do kolejnego punktu. Zarządzanie w IT pod tym względem ma niewiele wspólnego z klasycznym archetypem kierownika, który myśli, że pozjadał wszystkie rozumy i dyryguje pracownikami jak poddanymi. Tu się tak po prostu nie da. Nie ma takiej możliwości.

Na każdej płaszczyźnie projektu istnieje jasny podział kompetencji i obowiązków (zwłaszcza w metodologiach zwinnych – np. SCRUM). Abstrahując już nawet od metodyki zarządzania projektem, nie wyobrażam sobie, żeby menedżer mówił analitykowi czy developerowi jak ma realizować swoją pracę. Jasne, można wskazać, jak chcielibyśmy rozwiązać problem tak, aby było to zgodne z koncepcją biznesową – ale reszta pozostaje w gestii programisty.

Co więcej, nie da się po prostu znać wszystkich systemów. I co najważniejsze – nie trzeba. Menedżer pracujący przy projekcie opartym o SAP Hybris powinien faktycznie mieć pewną ekspercką wiedzę na temat funkcjonowania systemu – ale nikt nie będzie oczekiwał od niego znajomości konkretnych powiązań między modułami. O takie rzeczy dba analityk SAP, który wyłoży koncepcję rozwiązania sprawy, którą następnie wcieli w życie programista.

I to jest wspaniałe w zarządzaniu projektami IT – ta wzajemna sieć powiązań i poleganie na sobie. Tu nie da się być despotycznym władcą (jak np. w sklepie odzieżowym czy restauracji). Żeby projekt się udał, wymagana jest współpraca, szacunek i zaufanie.

Nigdy nie widziałem siebie jako despotycznego, polegającego tylko na sobie lidera, który zamiast współpracować ze swoim zespołem traktuje go jak niepotrzebny element układanki. Dlatego też jestem szczęśliwy, że wylądowałem właśnie w branży IT. Ale nie tylko.

Dynamika rynku i mnogość koncepcji

To chyba najfajniejsza z cech. Tu zawsze się coś zmienia. Nigdy nie da się przewidzieć wszystkich ryzyk i problemów (a jeśli ktoś mówi, że się da – zapraszam do zarządzania startupem), każdy dzień przynosi coś nowego. Od prostych, małych zmian w koncepcji rozwiązania (bo okazuje się po analizie, że coś można zrobić łatwiej lub upiec dwie pieczenie na jednym ogniu), przez lekkie zmiany harmonogramu (zwłaszcza w startupach – kiedy okazuje się, że klienci jednak chcą najpierw tej, a nie planowanej wcześniej funkcji), poważne przetasowania w projekcie (np. nagła zmiana priorytetów przez zarząd w dużej korporacji), aż po pełne pivoty (bo jednak badania pokazują co innego, i zamiast B2C będziemy robić system B2B).

Mało? A nuż zaraz po skończeniu Front-Endu zmieni się wersja AngularJS z 1 na 2, oczywiście bez wstecznej kompatybilności. Niby to nie problem, wszystko nadal działa, ale zostajemy z formalnie nierozwijanym już rozwiązaniem (a to czasem gorsze, niż być bez rozwiązania – zwłaszcza gdy producent zawiesił też wsparcie techniczne i nagle odkryta zostaje poważna luka). Ale to i tak jeszcze nic.

A co w przypadku, gdy poszedł update do najnowszej wersji oprogramowania serwerowego, a system sypie błędami? A software, który działa w jednej placówce klienta, a w drugiej, o takich samych parametrach, jednak odmawia posłuszeństwa? I moje ulubione – a co, gdy w kodzie programu jest jakiś dziwny, niezrozumiały fragment opatrzony KOMENTARZEM Z CAPS LOCKIEM, który po drobnej nawet modyfikacji kompletnie wykrzacza aplikację?

Jedną z moich ulubionych rzeczy w IT jest właśnie zmienność i ogromne pole do zastanowienia. Czy to eksperymenty myślowe, przygotowywanie koncepcji, analizy systemowe; czy też tworzenie makiet i zastanawianie się, co będzie najbardziej pożyteczne z punktu widzenia użytkownika końcowego… czy wreszcie niezwykłe sesje rozważań z programistami nad ewentualnym nowym rozwiązaniem do wdrożenia. Tu mózg przez cały czas ma zajęcie. I nie jest ono bynajmniej jałowym gdybaniem. To praktyczna lekcja z eleganckiego (lub nie – ale o tym kiedy indziej) rozwiązywania realnych problemów.

Ciąg dalszy wpisu z pewnością nastąpi – na razie wystarczy tyle (zresztą, nie chciałbym pisać artykułów, od których potencjalny czytelnik odbije się, bo zauważy ścianę tekstu). Stay tuned!

Zapisz się do newslettera!

Dołącz do osób, które regularnie otrzymują ostre i kontrowersyjne treści, które z racji charakteru bloga nie nadają się do publikacji.
Tomek Opublikowane przez:

Jestem Scrum Masterem w branży e-commerce i zarządzam projektami IT dla klientów. Spełniam się też jako handlowiec i front-end developer. Zbieram zegarki, jaram się technologią i nauką (fizyka, astronomia, biologia). Potrafię uwarzyć własne piwo, zrobić sesję zdjęciową i tworzyć muzykę. Prowadziłem kiedyś bloga lifestylowego. Potem przestałem, żeby zacząć zarabiać pieniądze. Spełniłem swój cel i wracam do pisania.