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
![Co zrobić, jeśli nie akceptują do IT bez wiedzy technicznej tech skills](data:image/svg+xml,%3Csvg%20xmlns='http://www.w3.org/2000/svg'%20viewBox='0%200%202048%201097'%3E%3C/svg%3E)
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ę![Co zrobić, jeśli nie akceptują do IT bez wiedzy technicznej tech skills: что изучать](data:image/svg+xml,%3Csvg%20xmlns='http://www.w3.org/2000/svg'%20viewBox='0%200%202048%201097'%3E%3C/svg%3E)
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
![Co zrobić, jeśli nie akceptują do IT bez wiedzy technicznej инструменты tech skills](data:image/svg+xml,%3Csvg%20xmlns='http://www.w3.org/2000/svg'%20viewBox='0%200%202048%201097'%3E%3C/svg%3E)
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.
![Co zrobić, jeśli nie akceptują do IT bez wiedzy technicznej TechMind PL](data:image/svg+xml,%3Csvg%20xmlns='http://www.w3.org/2000/svg'%20viewBox='0%200%201259%20410'%3E%3C/svg%3E)
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.