Aby sprawnie zarządzać projektem IT, sama wiedza menedżerska nie wystarczy. Wymagana jest również znajomość procesu tworzenia oprogramowania.
W praktyce firmy zwykle nie mają czasu na nauczenie kandydata niuansów technicznych. Dlatego szukają osoby, która od razu wyznaczy zespołowi zadania, uzasadni wybór rozwiązania klientowi i skonfiguruje wydanie oprogramowania.
Czy to oznacza, że nie można dostać się do branży IT bez backgroundu technicznego? Wcale nie — uważają nasi eksperci Denis Szamataży i Natalia Biełousowa. Jeśli odpowiednie doświadczenie nie wystarczy, można je zdobyć dość szybko.
Denis jest związany z IT już od 8 lat, 5 z nich przepracował jako manager zespołów zdalnych. Natalia prowadzi projekty z zakresu mobile development. W trakcie swojej pracy obaj eksperci przeprowadzili niejedną rozmowę kwalifikacyjną i opracowali własną listę tego, czego oczekuje się w firmie informatycznej od kandydatów na stanowiska kierownicze.
Zebraliśmy rady Denisa i Natalii w jednym artykule, abyś mógł natychmiast przeanalizować, jakiej wiedzy brakuje i opracować «mapę drogową» rozwoju niezbędnych umiejętności.
Dlaczego osoby z umiejętnościami technicznymi są priorytetem
Wydaje się, że doświadczony manager z dziedziny «nietechnicznej» będzie równie dobry w IT. Jeśli zarządzałeś budową domu, to poradzisz sobie z rozwojem aplikacji mobilnej. Czy rzeczywiście tak jest?
Natalia Biełousowa: Kiedyś szukałam asystenta PM. Jednym z kandydatów był menedżer z branży turystycznej, który był bardzo odpowiedni pod względem soft-skills.
Podczas rozmowy przyłapałam się na myśleniu, że mówimy zupełnie różnymi językami i zdałam sobie sprawę z ilości wiedzy, którą trzeba przekazać, aby kandydat mógł zacząć normalnie pracować jako PM w IT.
Dzięki temu zdałam sobie sprawę, że przygotowanie do pracy specjalisty «nie-informatycznego» będzie zbyt pracochłonne, dlatego skupiłam się na kandydatach, którzy oprócz soft-skills mieli również doświadczenie w IT.
Jakie trudności napotyka PM, przechodząc z obszaru «nie-IT» do obszaru «IT»:
- Brak zrozumienia procesu jako całości. Musimy zacząć od podstaw: czym jest proces rozwoju, jak przebiega, jakie trudności pojawiają się na każdym etapie. PM musi poprowadzić projekt, ale nie jest łatwo zarządzać czymś, czego się nie rozumie.
- Komunikacja z klientem. Menedżer bez znajomości terminologii informatycznej na spotkaniu z klientem może wydawać się klientowi niekompetentny. Kiedy specjaliści techniczni od strony klienta rozmawiają z managerem i orientują się, że nie zna terminologii, nie wie ważnych rzeczy, cała firma wygląda nieprofesjonalnie.
- Autorytet w zespole. Skuteczność PM-a zawsze bezpośrednio zależy od szacunku, jakim darzą go członkowie zespołu.. A jeśli menedżer jest słabo zorientowany w procesie, trudno będzie przezwyciężyć protekcjonalną postawę programistów.
W związku z tym firma musi poświęcić czas na przeszkolenie osoby bez odpowiedniego doświadczenia. Dobrze, gdy kandydat ma wykształcenie techniczne, ale co jeśli nie?
Wszystko w porządku, ponieważ dla PM ważniejsza jest umiejętność szybkiego zrozumienia problemu, a to nie wymaga podstawowej wiedzy, a raczej ogólnego zrozumienia procesu. Zobaczmy więc, jakie tematy warto poruszyć, aby pomyślnie przejść techniczną rozmowę menedżerską.
Czego się uczyć, jeśli chcesz samodzielnie poszerzyć swoją wiedzę
Nie jest wymagane, aby PM szczegółowo rozumiał rozwój, ważne jest, aby specjalista miał ogólne pojęcie o tym, jak powstają produkty programowe.
Cykl życia oprogramowania
W produktach software’owych nie chodzi o to, że programista usiadł, coś napisał — i tyle. Istnieją pewne etapy rozwoju, a Project Manager w IT zna te etapy, rozumie ich specyfikę i wie, jacy ludzie są potrzebni na każdym etapie:
- Formułowanie wymagań programowych. Do obowiązków PM-a należy zapewnienie dobrego planowania funkcjonalności i analizy wymagań.
- Projektowanie rozwiązań. Na tym etapie tworzy się przejrzysty interfejs i wizualna reprezentacja produktu. Budowana jest również architektura rozwiązania.
- Realizacja i testowanie. Musisz zrozumieć, że tworzenie i dalsze testowanie z poprawkami błędów to normalny proces. Często trzeba wyjaśniać klientom, spoza branży IT, w jaki sposób powstają produkty programowe i dlaczego na przykład błędy są normą.
- Uruchomienie (wdrożenie) i to, co dzieje się później.
- Eksploatacja i konserwacja (wsparcie techniczne). Dlaczego nie możemy po prostu porzucić produktu po wdrożeniu, czym jest serwis gwarancyjny, wsparcie techniczne itp.
Modele i metodologie
Wystarczy przeczytać kilka artykułów, aby zrozumieć cały temat. Celem jest stworzenie zestawu pojęć, które powinna posiadać osoba wchodząca do firmy IT.
Musisz znać najpopularniejsze modele: kaskadowy (Waterfall), iteracyjny, przyrostowy. Gdzie jest w tym wszystkim miejsce dla Agile i czym jest Kanban. Aby wybrać odpowiedni model zarządzania produktem, ważne jest zrozumienie zalet i wad każdego podejścia.
Terminologia
Musisz zrozumieć podstawowe rzeczy, aby móc odpowiedzieć na ogólne pytania techniczne:
- Czym jest architektura;
- Co to jest backend i frontend;
- Jak współdziałają platformy;
- Co to są bazy danych, tabele i relacje, klucz podstawowy;
- Co to jest DNS, load balancer, replikacja;
- Klient-serwer: gruby i cienki klient, co to jest;
- Jaka jest różnica między klientem-serwerem w sieci web i mobile;
- Co to jest REST;
- Jaka logika powinna być na frontendzie, a jaka na backendzie;
- Bezpieczeństwo, jak je zapewnić.
Denis Szamataży: Czasami, aby przygotować się do rozmowy kwalifikacyjnej, warto przyjrzeć się listom pytań zadawanych w różnych firmach. Pytania te mogą się jednak bardzo różnić w zależności od branży.
Dlatego jeśli czasu jest mało, lepiej znaleźć znajomego z podobnej firmy, na przykład w przypadku projektu gry, może to być twórca gier. Poproś znajomego, aby zadał ci ogólne pytania techniczne. Zwykle pomaga to zidentyfikować obszary problemowe, w których brakuje wiedzy lub zostały zapomniane, a wtedy staje się jasne, czego się nauczyć.
Dokumentacja techniczna
Menedżer nie pisze bardzo technicznych rzeczy, takich jak styl kodu czy opis architektury. Z pewnością jednak trzeba będzie dowiedzieć się, czym jest zadanie techniczne i jak je określić.
Aby móc wyznaczać zadania dla zespołu, PM musi sam zrozumieć pojęcia:
- Opis interfejsu API: zrozum, gdzie używane są interfejsy API, w którym momencie należy wprowadzić zmiany, a kiedy nie. Dzięki temu aktualizacje różnych części systemu nie spowodują przerwania jego działania. Często w outsourcingu zdarza się, że mobile robi jedna firma, a backend inna i w takiej sytuacji PM musi trochę bardziej uważać na to, co dzieje się «pod maską».
- Opis architektury. W outsourcingu często zdarza się, że klient prosi o opisanie pracy jakiegoś modułu dla klienta zewnętrznego lub o integrację z systemem zewnętrznym. I tu PM musi zrozumieć, co programista miał na myśli w opisie, żeby na rozmowie z klientem lub z jednym z zewnętrznych wykonawców móc odpowiedzieć na pojawiające się pytania.
- Test case, bug report, use case, user story — co to jest i dlaczego jest potrzebne.
Narzędzia projektowe
W tym bloku wiedzy głównym celem jest opanowanie aparatu pojęciowego i zrozumienie pytań, które mogą być zadane podczas rozmowy kwalifikacyjnej:
- Jakie są task trackers i które z nich są lepsze
- Gdzie jest wykorzystywane project planning? Jak zbudować wykres Gantta
- Gdzie przechowywać i zarządzać wymaganiami
Natalia Biełousowa: Praktyczna porada: Wybierz wersję próbną jednego z trackerów zadań, na przykład Jira i spróbuj sprawdzić, czy możesz tworzyć zadania. Zapytany podczas rozmowy kwalifikacyjnej o twoje doświadczenia z task trackers, możesz odpowiedzieć:
— Tak, trochę pracowałem z Jirą — i to będzie dodatkowy plus na twoją korzyść.
Task trackers są podobne, a jeśli ćwiczysz z jednym, ogólnie zrozumiesz, jak działają inne.
Testowanie
Konieczne jest wyrobienie sobie wyobrażenia o rodzajach testów (funkcjonalne, regresyjne, obciążeniowe), w jakiej kolejności są przeprowadzane i kiedy są potrzebne:
- Testowanie wewnętrzne i zewnętrzne.
- Jak odróżnić bug od change request
- Artefakty testerów: test cases, PMI (program i metodyka testów).
- Dotkliwość (Severity) i priorytet (priority) buga/wady.
- Kiedy powinieneś przestać testować?
- Czy można oddać projekt, jeśli występują bugi, w jakiej kolejności i w jakiej ilości?
Kiedy już zdecydujemy CZEGO się uczyć, porozmawiamy o tym GDZIE uzyskać potrzebne informacje. Porozmawiajmy o wiedzy teoretycznej i umiejętnościach praktycznych.
Gdzie szukać odpowiedzi
Plan rozwijania umiejętności technicznych będzie składał się z dwóch części. Z jednej strony potrzebna jest wiedza teoretyczna: jak to wszystko działa, gdzie jest jaka platforma i komponenty. Z drugiej strony będziesz potrzebować praktycznych umiejętności: zrobić kilka rzeczy własnymi rękami i zobaczyć, jak to działa.
Denis Szamataży: Teraz pracuję jako «mobilny» PM, więc projektowałem w ten czy inny sposób mobile design, ciągle czytam o platformach mobilnych i sam potrafię napisać prostą aplikację.
Wiedza teoretyczna
Natalia Biełousowa:
Gdyby przyjaciel przyszedł do mnie i zapytał: «Natasza, chcę iść do IT, co powinienem zrobić?» – poleciłabym kurs podstawowy na Coursera lub podstawowy TechMind albo rozpoczęcie nauki na uczelni wyższej. Wszystko zależy od czasu trwania kursu i celów danej osoby, jak bardzo chce się ona zagłębić w część techniczną.
Denis Szamataży: Podstawowe kursy techniczne mają jedną wadę: często obejmują supertechniczne szczegóły, których PM nie potrzebuje. Zamiast wyjaśniać specyfikę projektu, podpowiedzą, jak podnieść poziom usług, skonfigurować hosting itp. A menedżer, aby zarządzać, musi po prostu ogólnie zrozumieć, jak działa system.
Z drugiej strony są też kursy czysto menedżerskie, gdzie mówią więcej o zasadach zarządzania, ale nie wyjaśniają, jak rozumieć prace rozwojowe. A bez zrozumienia trudno jest zrozumieć proces.
Dobrym źródłem wiedzy jest interakcja ze specjalistą. Komunikacja może być dość nieformalna: po prostu jakiś znajomy, którego można przepytać.
Inną opcją jest znalezienie bardziej doświadczonego PM lub mentora i poproszenie go o przesłanie odpowiednich treści lub pomoc w rozwiązaniu problemu technicznego.
Możesz samodzielnie studiować teorię: czytać newsy, artykuły, śledzić, co się dzieje, subskrybować społeczności IT. To jest bardzo ważne.
Załóżmy, że pracujesz z użytkownikami w zakresie projektów mobilnych i tutaj każda innowacja w systemie operacyjnym od razu staje się bardzo istotna. Codziennie rano można wchodzić do określonych zasobów i śledzić informacje: na przykład wyszedł nowy IOS lub Android alfa, i jaka tam jest funkcjonalność.
Śledząc najnowsze wiadomości, zrozumiesz, co się poprawia, a co pogarsza. To nie jest jakaś specjalna wiedza potrzebna do bezpośrednich obowiązków PM, ale daje dobre myślenie kontekstowe.
Natalia Biełousowa: Jeśli mówimy o tym, skąd czerpię wiedzę techniczną, to otrzymałam podstawową bazę dotyczącą projektowania systemów informatycznych, baz danych, podstaw algorytmizacji wraz z wykształceniem wyższym.
Przeczytałam już wystarczająco dużo książek, a teraz wolę zaczynać od praktyki, od postawionych zadań: kiedy na coś trafię, idę o tym poczytać. Jednak najprawdopodobniej poszukam profesjonalisty — on może pokierować, doradzić czego i gdzie szukać na dany temat.
Wszystko, co jest potrzebne w pracy, w razie potrzeby nabieram punktowo. Na przykład natrafiłam na analitykę produktu i poszłam o tym przeczytać. Nie udało mi się tego rozgryźć — poszłam i zapytałam znajomego specjalisty, co radziłby przeczytać, co naprawdę działa.
Denis Szamataży: Na początku próbowałem znaleźć podstawowe książki, które by mi pomogły, spędziłem dużo czasu, ale w końcu okazało się, że połowa informacji z tych książek od dawna nie jest wykorzystywana.
Książki szybko się dezaktualizują i często są zbędne: kilka rzeczy, które można wyjaśnić na 10 stronach, wyjaśniono na 50 i po prostu marnujesz swój czas. Dlatego teraz czerpię wiedzę techniczną nie z książek, ale z artykułów, prac naukowych, blogów.
Umiejętności praktyczne
Jeśli mówimy o zdobywaniu wiedzy praktycznej, to bez względu na to, ile książek i stron internetowych przestudiujesz, dopóki nie zrobisz czegoś własnymi rękami, nie będziesz w stanie zrozumieć sfery IT. Spróbuj stworzyć coś ręcznie, aby zobaczyć, jak to działa: na przykład witrynę wordpress lub minimalną aplikację, a la «Hello, Word». Kiedy spróbujesz przełożyć teorię na rzeczywistość, wiedza zamieni się w praktyczną umiejętność.
Przy nauce programowania będzie to coś w rodzaju pracy laboratoryjnej. Możesz zrobić takie «laboratoria» samodzielnie lub udać się na kurs, na którym zostaniesz poprowadzony za rękę, poinstruowany, co robić, tam też wszystko sprawdzą i rozwiążą błędy.
Innym sposobem zdobycia praktycznej wiedzy jest wejście do IT ze stanowisk takich jak support lub QA, gdzie próg wejścia jest stosunkowo niski. Zanurzysz się w atmosferę, zrozumiesz, jak powstają produkty programowe, przyjrzysz się procesowi od środka, a następnie zorientujesz się, w jakim kierunku się rozwijać.
Denis Szamataży: Rzeczywiście jest wiele zawodów, z których można wejść do IT, nawet bez doświadczenia. Niektórzy z moich znajomych stali się PM z customer support, ponieważ to stanowisko rozwija dwie ważne umiejętności:
- Zrozumienie produktu, potrzeb i problemów klientów.
- Zrozumienie szczegółów technicznych potrzebnych do sformułowania odpowiedzi.
Na przykład, jeśli produktem jest duży system CRM, ciągle będziesz spotykał się z nowymi częściami tego systemu: usługami, hostingiem, drobiazgami i w końcu to rozgryziesz.
Natalia Biełousowa: Support lub QA to świetne stanowiska, aby dostać się do branży IT i zdobyć doświadczenie techniczne. QA rozwija się bardzo szybko, to dobry sposób, aby się wybić. Nawet student może przyjść do firmy jako praktykant i zacząć zdobywać doświadczenie.
A jeśli szukasz stanowiska menedżerskiego, udaj się do junior PM-ów lub na staż. Będzie to niekorzystne finansowo, ale zdobędziesz doświadczenie. Pomyśl o stanowisku nie w kategoriach bieżących zarobków, ale przyszłego rozwoju i doświadczenia.
Opracowanie planu rozwoju umiejętności technicznych to dopiero początek podróży. Dlatego, gdy roadmap jest gotowy, zacznij działać.
Jeśli twój plan ma punkt: zdobyć umiejętności techniczne w zakresie zarządzania, spróbuj TechMind.
Program jest specjalnie zaprojektowany, aby po każdym wykładzie było jasne, jak działa ta część procesu. Za półtora miesiąca zdobędziesz podstawową wiedzę techniczną i nauczysz się komunikować z programistami w ich języku.