21 03 2018

Artur Kotow, dyrektor technologiczny w PwC Polska podkreśla, że edukacja na Wydziale Zarządzania Uniwersytetu Łódzkiego dobrze wpisuje się w obecną rolę. Praca na stanowisku dyrektora technicznego to efekt mieszanki zebranych doświadczeń i dobrych zbiegów okoliczności.


Jak wyglądała Twoja edukacja i wczesna kariera? Czym się zajmowałeś i jak przełożyło się to na późniejsze doświadczenia?  

AK: Z biegiem lat dostrzegam, że moja edukacja i obecna rola świetnie do siebie pasują, ale nie było tak od początku. Studiowałem zarządzanie i marketing na Uniwersytecie Łódzkim, a swoją przyszłość wiązałem raczej z agencją kreatywną, niż firmą IT. Dzięki rekomendacji znajomego jeszcze na studiach zacząłem pracę jako tester oprogramowania. Na początku nie miałem na ten temat zielonego pojęcia, szybko jednak okazało się, że moje czysto biznesowe podejście pomaga mi lepiej rozumieć co testuję, niż osobom, które mają wiedzę głównie techniczną. Co więcej, brak tej wiedzy czasami wręcz pomagał wcielić się w rolę końcowego użytkownika systemu. Z czasem zacząłem szukać nowych wyzwań, takich jak automatyzacja testowania, analiza biznesowa, zarządzanie projektami, ale to, co ukierunkowało moją karierę to zarządzanie zespołem - najpierw testowym, a potem wdrożeniowym.


A w chwili obecnej, brak technicznego backgroundu również bywa plusem, czy czasem jednak przeszkadza?

AK: Czasami dobrze byłoby wiedzieć, czy każde „nie da się” lub „ to niemożliwe” jest prawdziwe. (śmiech) Ale najważniejsze to mieć świadomość, gdzie jest osoba mająca tę wiedzę. Brak technicznego backgroundu motywuje mnie do tego, by tworzyć zespół z najlepszych specjalistów, którym mogę ufać bez potrzeby kontroli. Często też moje spojrzenie na problem - odmienne od kolegów - prowadzi do ciekawych i kreatywnych rozwiązań.


Jaki poziom zrozumienia kwestii technicznych jest konieczny by - Twoim zdaniem - pełnić rolę dyrektora technicznego?

AK: Z pewnością zrozumienie technologii pomaga, ale jeszcze ważniejsze są doświadczenia z pracy na projektach. Nie da się zarządzać zespołem technicznym, jeżeli człowiek sam nie zakasał wcześniej rękawów i nie stawił czoła wyzwaniom, jakie stawia rozwój oprogramowania. Często spotykamy się z klientami, którzy są świetnymi menedżerami, ale wcześniej nie brali udziału w żadnym wdrożeniu. W takich sytuacjach najlepiej widać, jaką wagę ma realne doświadczenie vs. umiejętności zarządzania.


Jak wyglądała Twoja ścieżka kariery, gdy już obrałeś menedżerską drogę rozwoju?

AK: Jak wspomniałem, zanim wybrałem ścieżkę ściśle menedżerską, próbowałem różnych rzeczy. Częściej dowiadywałem się czego nie chcę robić, niż świadomie obierałem jeden kierunek. Ciekawość oraz chęć podejmowania nowych wyzwań kierowały mnie w zarządzanie zespołami, co naturalnie przerodziło się w ścieżkę menedżerską. Od momentu, w którym zostałem dyrektorem odpowiedzialnym za dział Quality Assurance skupiłem się wyłącznie na doskonaleniu umiejętności zarządzania zespołem i rozwojem biznesu.

Obecnie mam wypracowane cele, do których dążę i kieruję swoją karierą bardziej świadomie. Jestem jednak osobą, która ceni sobie ,,element przygody’’, dlatego nadal z chęcią podejmuję się nowych wyzwań, wybierając już te, które znajdują się w mojej ścieżce rozwoju.



Na czym polega Twoja obecna rola?

AK: Zarządzam zespołem wdrożeniowym, w którego skład wchodzą analitycy, architekci, konsultanci oraz developerzy. Rola nie jest mocno techniczna - to przede wszystkim umiejętność balansowania między światem technicznym, a biznesowym. Szczególnie w zespole, gdzie większość naszych rozwiązań dotyka obszaru CRM na równi z wiedzą techniczną istotne jest zrozumienie potrzeb klienta i możliwości produktów.



Na jakiej podstawie są podejmowane decyzje stricte techniczne?

AK: W idealnym świecie każda decyzja jest oparta o głęboką analizę i obiektywne techniczne parametry poszczególnych rozwiązań. W świecie prawdziwym trzeba często uwzględniać czas, budżet i przekonania klienta. W naszym zespole zawsze dążymy do idealnego modelu, ale nie zapominamy, że na końcu jest cel dostarczenia rozwiązania, która ma spełniać swoją funkcję i nie zawsze musi być idealne.



Co jest ważne w rozwoju software’u z Twojego punktu widzenia?

AK: Najważniejsze w rozwoju oprogramowania jest dla mnie tworzenie przede wszystkim dla ludzi, a nie tylko dla spełnienia formalnych wymagań. Rynek kształtuje różne potrzeb i czasami jesteśmy zmuszeni robić rzeczy, które mają sens jedynie na papierze. Szacunek do swojej pracy poprzez dostarczanie realnej wartości, a nie tylko pustych „osobogodzin” jest jednak ważny. Chyba nie ma nic bardziej frustrującego niż wykonana praca, która nie jest nikomu potrzebna. Myślę, że podobne zdanie ma każda osoba biorąca udział w rozwoju oprogramowania i chce, by produkt jej pracy był użyteczny.



Co to znaczy, według Ciebie, być dobrym dyrektorem technicznym?

AK: W moim przekonaniu dobry dyrektor techniczny z punktu widzenia pracowników to osoba, która umożliwia i motywuje swój zespół do wykonywania porządnej, wartościowej pracy. Z punktu widzenia firmy to osoba, która potrafi stworzyć i utrzymać zespół, który chce wykonywać porządną i wartościowa pracę. Najważniejsze jest to, by zespół był zespołem, a nie chmurą wolnych elektronów.


Typowy dzień pracy na Twoim stanowisku - możesz go jakoś zdefiniować?

AK: Szczerze mówiąc, będzie trudno. Kiedy mam plan na cały tydzień zazwyczaj okazuje się, że właśnie nadeszła świetna nowa okazja sprzedażowa, wymagająca szybkiego, elastycznego działania. Oprócz porannej kawy wszystko codziennie się zmienia. Nie mogę z tego powodu narzekać.


Wybierz jedną, najważniejszą rzecz, której nauczyłeś się piastując stanowiska dyrektora technicznego.

AK: Na każde pytanie jest jedna słuszna odpowiedź „to zależy”. (śmiech) Tak na poważnie, nauczyłem się mnóstwa rzeczy, ale gdybym miał wybrać jedną - świadomość, że najważniejsze jest to, żeby ludzie wiedzieli nie jak mają coś zrobić, ale po co.


Na koniec - czego możemy Ci życzyć?

AK: Współpracy z otwartymi i zorientowanymi na cel ludźmi. Wtedy nie wszystko jest łatwe, ale prowadzi do realizacji ciekawych i satysfakcjonujących projektów.