Co zrobić, jeśli nie akceptują do IT bez wiedzy technicznej

18 maja 2022

  • Autor: Denis Shamatazhy

  • Złożoność: normalna

  • Czas: 8 min

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

tech skills

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ętech skills: что изучать

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

инструменты tech skills

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.

TechMind PL

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.

Denis Shamatazhy

Project/Product manager z ponad 5-letnim doświadczeniem w branży IT. Specjalizuje się na zarządzaniu w firmach spożywczych, budowaniu zespołów programistycznych, optymalizacji procesów i skalowaniu. Przyszedł w świat zarządzania z programowania na platformach mobilnych. Jest adeptem i zwolennikiem XP oraz Scruma.