Jak zostać kierownikiem projektu. Zawód kierownik projektu

Jakie umiejętności powinien posiadać kierownik projektu i jak je zdobyć. Czy PM powinien dobrze orientować się w tematyce prowadzonego przez siebie projektu? O tym w kolumnie naszego eksperta Maxima Jakubowicza.

Zacznijmy od tego, dlaczego warto zostać kierownikiem projektu?

1. Rośnie zapotrzebowanie na specjalistów w tej dziedzinie.

Według badań PMI (Project Management Institute) do 2020 roku liczba wakatów w 10 krajach, w których rośnie zapotrzebowanie na kierowników projektów, wzrośnie z 13,4 mln do 41,5 mln stanowisk pracy.

2. Zarobki kierowników projektów są całkiem przyzwoite. Tutaj są na przykład dane z sektora IT.

Źródło: dev.by, dane za czerwiec-wrzesień 2014, w dolarach amerykańskich

3. Praca kierownika projektu to ciągłe wyzwanie i motywacja, która wiąże się również z dużą odpowiedzialnością.

Jakie kompetencje powinien posiadać kierownik projektu?

Moim zdaniem są one następujące:

1. Umiejętność zebrania odpowiednich ludzi i stworzenia z nich zespołu.

To znaczy:

• umiejętność identyfikowania cech psychologicznych ludzi, rozumienia ich mocnych i słabych stron jako jednostek
• umiejętność motywowania członków zespołu
• umiejętności rozwiązywania konfliktów
• umiejętność budowania procesu ciągłego doskonalenia produktywności pracy

2. Umiejętności negocjacyjne.

3. Zdolność do przewodzenia.

4. Umiejętność wyboru bardziej odpowiedniej metodologii zarządzania projektami (lub ich symbiozy) dla konkretnego projektu i dostosowania jej do zespołu i środowiska projektowego.

5. Umiejętności korzystania i wdrażania kilku produktów oprogramowania do zarządzania projektami.

Umiejętność zebrania odpowiednich ludzi i zbudowania z nich zespołu – grupy ludzi, których łączy wspólny cel i odpowiedzialność za jego osiągnięcie – to najtrudniejsza umiejętność, jaką musi nabyć kierownik projektu. A można ją zdobyć jedynie stosując zdobytą wiedzę w praktyce.

Przykładowo, pewnego razu zapoznałem się z techniką pisania MBTI i zacząłem ją stosować w zespole (jest to temat na osobny artykuł). Dziś eksploruję inne podejścia do typowania ludzi, aby przetestować je w praktyce i poprawić swoje kompetencje w tworzeniu i rozwijaniu zespołów.

Drugą ważną umiejętnością jest negocjowanie, a jest ich w projekcie ogromna liczba. Bez opanowania tej umiejętności na wysokim poziomie kierownik projektu będzie miał spore problemy z podejmowaniem decyzji.

Aby rozwijać tę kompetencję, możesz brać udział w różnorodnych szkoleniach komunikacyjnych i stale ćwiczyć zdobytą wiedzę, zamieniając ją w umiejętności.

Trzecią umiejętnością, którą powinien rozwinąć PM, jest umiejętność przewodzenia (lub przywództwa). Moim zdaniem tę umiejętność można „napompować”. O tym, jak zostać liderem, powstają książki i tego uczy się na seminariach i szkoleniach.

Czwartą rzeczą, o którą należy się martwić, jest doświadczenie w stosowaniu kilku metodologii zarządzania projektami, najlepiej przynajmniej jednej ciężkiej i jednej elastycznej. Chodzi o faktyczne stosowanie metodologii w projektach, a nie uczenie się ich z książek. Im więcej metodologii zna RM, tym lepiej dla jego zespołu. Będzie potrafił wybrać bardziej odpowiednią metodologię (lub zintegrować kilka metodologii) dla projektu i dostosować ją do zespołu i środowiska projektowego.

Piątą kwestią jest umiejętność korzystania i wdrażania kilku produktów oprogramowania do zarządzania projektami. Oprogramowanie zwykle automatyzuje jakąś metodologię, co oznacza, że ​​PM musi umieć wybrać oprogramowanie dla wybranej metodologii zarządzania projektami i wdrożyć je dla swojego zespołu. Aby zdobyć takie doświadczenie, trzeba mieć odwagę objąć przywództwo w kwestiach automatyzacji działań projektowych i doprowadzić do realizacji kilka projektów automatyzacji.

Wiele osób, podobnie jak ja kiedyś, jest zainteresowanych pytaniem: „Czy PM powinien rozumieć obszar tematyczny projektu, który prowadzi?”. Większość ludzi odpowie, że tak. Ale nie zgadzam się. Ta wiedza nie zaszkodzi, ale nie jest konieczna. Jeśli kierownik projektu nigdy nie programował, nie oznacza to, że nie może poprowadzić projektu rozwoju oprogramowania do sukcesu. Wystarczy, że znajdzie asystenta (lidera technicznego), który rozumie programowanie i zbuduje z nim pełną zaufania relację, tak aby on zajmował się techniczną częścią projektu, a PM zajmował się zespołem, harmonogramem, budżetem projektu itp.

Jak zatem zostać kierownikiem projektu?

Trzeba zacząć od zarządzania małym projektem (zespół 2-5 osób, czas trwania - od sześciu miesięcy do roku). W tym projekcie trzeba zdebugować procesy zarządzania, wypróbować odpowiednie narzędzia, popracować w zespole i zautomatyzować zarządzanie projektami.

Na zakończenie projektu zdecydowanie powinieneś zorganizować spotkanie podsumowujące projekt i napisać dla siebie dokument „Wyciągnięte wnioski” (czego się nauczyłeś, jakie błędy popełniłeś i co zrobiłbyś inaczej).

Następny projekt może być nieco większy pod względem skali. Wierzę, że po 6-7 udanych (lub „warunkowo udanych”) projektach PM jest już gotowy na milionowy projekt (z budżetem pracy 1 milion dolarów) i może uzyskać certyfikat na poziomie profesjonalisty w zarządzaniu projektami korzystając z jednego z systemów certyfikacji. Tak naprawdę, mając tak bogate doświadczenie i nabywszy opisane powyżej umiejętności, staje się dojrzałym kierownikiem projektu.

Zaznaczam, że wszystko co napisałem powyżej jest jedynie moim osobistym spojrzeniem na rolę kierownika projektu przez pryzmat dwudziestu projektów zrealizowanych w tej roli. Jeśli masz inny punkt widzenia, chętnie przeczytam Twoje uwagi.

Maksym Jakubowicz

Ekspert zarządzania projektami, konsultant i trener biznesu grupy konsultingowej Tu i Teraz.

Ponad 10 lat doświadczenia w zarządzaniu projektami.

20 zrealizowanych projektów w roli kierownika projektu i kierownika programu projektu.

Doświadczenie w nauczaniu – 8 lat. Na jego seminariach przeszkolonych zostało około 2000 studentów.

Wykładowca modułu Zarządzanie Projektami w Rosyjskiej Szkole Zarządzania.
Gościnny wykładowca na kursie Project Management w British Higher School of Design.
Prowadzący

Niezależnie od obszaru specjalizacji Twojej organizacji ważne jest zrozumienie tego rozróżnienia.

• Specjaliści wykorzystują swoje umiejętności i doświadczenie do tworzenia specjalistycznych produktów (dostarczanych wyników). Produkty te mogą obejmować wszystko, począwszy od sprzętu komputerowego, oprogramowania, dróg, dokumentów, świadczenia usług, lotnictwa, budynków, stolarki i zasad zarządzania zasobami ludzkimi... Lista nie ma końca.
• Jednocześnie kierownicy projektów oprócz umiejętności rozwiązywania problemów potrzebują ogólnych umiejętności zarządzania. Kierownicy projektów powinni planować pracę i zarządzać nią, a nie ją wykonywać!

1. Bądź liderem i menadżerem

Liderzy przekazują ogólną perspektywę (jakiegoś przyszłego stanu); budują konsensus i wyznaczają kierunek naprzód. Motywują innych. Liderzy dążą do wyników i koncentrują się na wykonaniu pracy zgodnie z ustalonymi wymaganiami. Dobry kierownik projektu będzie stale zmieniał się z lidera na lidera, w zależności od sytuacji.

2. Bądź osobą kształtującą grupę i liderem

Ponieważ projekty są często wielofunkcyjne, angażują w nie ludzi, którzy być może wcześniej ze sobą nie pracowali. Kierownik projektu musi nadawać ton grupie i prowadzić ją przez różne fazy rozwoju, aż członkowie grupy będą pracować jako jeden zespół. Często ludzie w grupie mają swoich bezpośrednich przełożonych, a kierownik projektu nie ma dorozumianej władzy – ale musi motywować tę osobę. Jest to szczególnie prawdziwe w organizacji macierzowej.

3. Rozwiązuj problemy

Jest to umiejętność, której można się nauczyć: wymaga ona jedynie odrobiny pracy detektywistycznej! Najpierw musisz określić możliwe przyczyny, które doprowadziły do ​​pojawienia się problematycznego objawu. Przyczyny mogą mieć wiele źródeł, w tym:

• Problemy interpersonalne
• Źródła wewnętrzne
• Źródeł zewnętrznych
• Źródła techniczne
• Źródła administracyjne
• Komunikacja
• Opinie lub spostrzeżenia

i tak dalej. Następnym krokiem po zidentyfikowaniu głównych przyczyn jest analiza możliwych opcji i alternatyw oraz określenie najlepszego sposobu działania. Dokładnie uzgodnij, co w tym przypadku oznacza „najlepszy”!

4. Bądź negocjatorem i wpływowcem

Negocjacje to współpraca z innymi osobami w celu osiągnięcia wspólnego porozumienia. To nie musi być bezpośrednia, brutalna konfrontacja, o której myślisz! Na przykład konieczność przekonania jednego z członków grupy, aby pracował do późna, aby dotrzymać terminu, a ten chciałby pójść na mecz baseballowy. Aby to zrobić, musisz posiadać pewne umiejętności wywierania wpływu. Wpływ to zdolność do powodowania zdarzeń poprzez przekonanie innej osoby, że Twoja metoda jest najlepszą metodą, nawet jeśli nie jest z niej zadowolona. Wpływanie to umiejętność nakłaniania ludzi do robienia rzeczy, których inaczej by nie zrobili.

5. Bądź świetnym komunikatorem

Bycie komunikatorem oznacza zrozumienie, że jest to ulica dwukierunkowa. Informacje wpływają do projektu i opuszczają projekt. Ogólnie rzecz biorąc, cała komunikacja w Twoim projekcie powinna być jasna i kompleksowa. Jako kierownik projektu musisz radzić sobie z komunikacją pisemną i ustną. Przykładami są dokumenty, spotkania, przeglądy, raporty i oceny. Dobry mnemonik to „kto potrzebuje tych informacji, kto je gromadzi i przekazuje, kiedy i jak często ich potrzebuje oraz w jakiej formie im to przekażę”.

6. Bądź dobrym organizatorem

Zastanówmy się nad aspektami, które będziesz musiał zorganizować: organizacja projektu, w tym cała dokumentacja, umowy, e-maile, notatki, recenzje, spotkania, dokumenty profilowe, wymagania i specyfikacje, raporty, zmiany, problemy, ryzyko itp. Prawie niemożliwe jest utrzymanie porządku bez umiejętności zarządzania czasem, więc dodaj je do swojej listy!

7. Bądź kompetentnym i konsekwentnym planistą

Umiejętności planowania nie można lekceważyć, to samo dotyczy umiejętności szacowania! Istnieją dobrze znane i logiczne etapy tworzenia planów. Jako kierownik projektu z pewnością będziesz mieć plan projektu, ale w zależności od projektu mogą istnieć inne plany. Na przykład plany etapowe, plany wyjątkowe, plany grupowe, plany przeniesienia kontroli, plany realizacji świadczeń itp. Nie martw się, jeśli nie słyszałeś o niektórych z tych planów, ponieważ mogą one nie być konieczne, po prostu uświadom sobie, że planowanie powinno stać się drugą naturą. Należy tutaj zwrócić uwagę na dwa aspekty:

1. Plany są zawsze dokumentami. Nie daj się zwieść myśleniu, że na przykład wykres Gantta to plan – to tylko harmonogram kalendarza.
2. Udane projekty są realizowane przez odnoszące sukcesy zespoły. Podczas tworzenia planu zawsze korzystaj z pomocy grupy, chyba że istnieje ważny powód, aby tego nie robić, np. tajemnice handlowe lub warunki umowy.

8. Twórz budżety i zarządzaj nimi

Podstawą tego wszystkiego jest umiejętność szacowania, zwłaszcza szacowania kosztów. Niemal zawsze kierownik projektu potrzebuje pewnej wiedzy na temat metod i systemów finansowych oraz zasad rachunkowości.

Częścią planu projektu będzie tzw. plan kosztów. Pokaże planowane wydatki w odniesieniu do harmonogramu. Kierownik projektu będzie zaangażowany w zakupy, ustalanie cen, uzgadnianie faktur, kart czasu pracy, wydatków na płace itp. Kierownik projektu musi następnie ustalić, co faktycznie się wydarzyło w porównaniu z tym, co zaplanowano i przewidzieć oczekiwany koszt końcowy. Narzędzia księgowe i do zarządzania projektami zazwyczaj pomagają, ale pamiętaj o zasadzie „śmieci w środku, śmieci na zewnątrz”!

Pokrótce omówiono główne obszary. Jeśli dopiero zaczynasz przygodę z zarządzaniem projektami, nie pozwól, aby cokolwiek tutaj napisane Cię zmyliło. Istnieją powszechnie akceptowane metodologie, narzędzia, wytyczne i procedury, które mogą pomóc w rozwinięciu ważnych umiejętności zarządzania projektami.

Cześć przyjaciele!

Tak się składa, że ​​moi znajomi i znajomi moich znajomych, którym mnie polecono, okresowo kontaktują się ze mną z mniej więcej tym samym pytaniem: „Jak mogę zostać kierownikiem projektu w IT, jeśli wcześniej pracowałem na podobnym stanowisku, ale nie w tym?

Ponieważ w dość krótkim czasie zgromadziło się kilka takich próśb, postanowiłem napisać na ten temat osobny artykuł. No cóż, rozumiesz - jestem leniwy i teraz mogę od razu podać link do tego tekstu, zamiast powtarzać odpowiedzi, które zostały już sformułowane kilka razy. Artykuł nie pretenduje do uniwersalności – to tylko mój pogląd na sytuację. Jednocześnie powiem, że podczas rozmów kwalifikacyjnych, zatrudniania i szkolenia kierowników projektów kumuluje się całkiem sporo ogólnych kryteriów, które odpowiadają na pytanie: „Co właściwie powinien wiedzieć i umieć kierownik projektu IT, aby to zrobić?” pracować z sukcesem w IT.

Nawiasem mówiąc, w artykule nie wspomniano nawet o znajomości języka angielskiego. To po prostu konieczność.

Iść?

Jak zwykle wygląda żądanie:

Aleksiej, dzień dobry! Nazywam się<...>. Polecono mi się z Tobą skontaktować<...>. Potrzebujemy Twojej fachowej porady. Będę wdzięczny za poradę. Znalazłem szkolenie dla kierowników projektów, które czytasz. Chciałbym zapytać, czy powinienem to wziąć. Krótko o mojej sytuacji:<...>Chciałbym spróbować się dalej rozwijać w kierunku projektowym, ale już w obszarze IT. Byłem już na kilku rozmowach kwalifikacyjnych, ale jak dotąd bezskutecznych (pracodawcy często powołują się na brak doświadczenia w IT). W związku z tym wpadłem na pomysł, jak w końcu zmusić pociąg do ruchu. Byłbym bardzo wdzięczny za porady dotyczące kursów. Może warto zainteresować się czymś związanym z kierownikiem projektu, skoro nie ma szans na zatrudnienie na takim stanowisku w branży IT? Byłbym wdzięczny za każdą opinię.

Możliwości aplikacji różnią się jedynie wcześniejszym doświadczeniem zawodowym w niektórych obszarach niezwiązanych z IT.

Co mogę polecić?

Najpierw przestraszę i zagęszczę chmury.

1. Rzeczywiście prawie zawsze odmawiają właśnie dlatego, że niezwykle ważne jest, aby kierownik projektu w IT rozumiał nie tylko zarządzanie projektami jako takie, ale także informatykę. Jest to wymagane do dokładnie dwóch rzeczy: a) znalezienia wspólny język z podwładnymi(testerów, analityków i programistów, którzy wszyscy są specjalistami IT) i w związku z tym zrozumienie istoty dialogów, specyfikacji, problemów itp. oraz b) znalezienie wspólny język z przedstawicielami klientów, które często mają również doświadczenie głównie w IT. Oczywiście są niewielkie szanse na przekonanie przyszłego pracodawcy, że zrozumienie specyfiki branży IT nie jest kluczowe na tym stanowisku. Należy pamiętać, że szanse te są bardzo, bardzo małe. Przecież pracodawca wie najlepiej, czego potrzebuje, a przekonanie go, że jest inaczej, jest dość trudne. Zwłaszcza pracodawcy z branży IT – z pewnością wiedzą, jakiego pracownika potrzebują. Jednocześnie nikt nie zabrania prób przekonywania. Czy to się sprawdzi?

2. W IT zrozumienie etapów rozwoju produktu (SDLC – Software Development Life Cycle) jest bardzo ważne. Praca w organizacjach nie-IT to zrozumienie w pełni Niestety nie do zdobycia. Istnieją problemy specyficzne dla branży IT. A skoro kierownik projektu w IT jest odpowiedzialny za opracowanie produktu/kodu/funkcjonalności w określonym terminie, z określoną jakością i w określonych ramach jakości/funkcjonalności, to musi rozumieć, jak to wszystko osiągnąć środkami, którymi zwykle się zajmuje. ma w sferze IT. Inne branże mogą mieć swoje własne niuanse, które w ten czy inny sposób różnią się od IT.

3. Wszelkie szkolenia z zarządzania projektami „w ogóle” najprawdopodobniej niewiele pomogą. Potrzebujemy szkoleń z zarządzania projektami w IT. Pozwólcie, że wyjaśnię, dlaczego tak sądzę: szkolenia „w ogóle” nie zapewnią zrozumienia dwóch ważnych rzeczy: „języka technicznego IT” i „zrozumienia etapów rozwoju szczególnie w IT”.

4. Każda firma IT ma już swoich pracowników, którzy chcą zostać menedżerami. A ci pracownicy (programiści, testerzy, analitycy) już rozumieją IT (mówią tym samym technicznym językiem, co otaczający ich ludzie), a także znają SDLC. Co więcej, znają klienta, znają specyfikę firmy i jej wewnętrznej kuchni (nie są to punkty krytyczne, ale w porównaniu z zerową wiedzą zewnętrznego kandydata nawet te punkty mogą przeważać). Okazuje się zatem, że kandydat zewnętrzny NIE z branży IT zmuszony jest konkurować zarówno z kandydatami wewnętrznymi z samej firmy, jak i z innymi kandydatami zewnętrznymi, także z branży IT.

Jakie więc parametry uzyskałeś?

1. Biegła znajomość technicznego języka IT. Zrozumienie na przykład czym jest FTP, podpisanie, sprint, ASAP, regresja, XML, żądanie bazy danych, termin ostateczny, FYI, architektura klient-serwer, czerwona linia, test dymu, FTE, wydanie... Lista jest długa. Bycie super ekspertem w niektórych z wymienionych rzeczy wcale nie jest wymagane. Trzeba zrozumieć istotę tego, co to jest w ogóle, co to za terminy, co oznaczają, co się za nimi kryje, inaczej będziesz jak niewidomy w świecie osób widzących.

2. Znajomość SDLC(Cykl Życia Rozwoju Oprogramowania) – etapy rozwoju oprogramowania. I nie tylko wiedza, ale zrozumienie, dlaczego dokładnie te etapy, dlaczego w takiej kolejności, gdzie i dlaczego można przeskakiwać z jednego etapu na drugi i czy możliwe jest przejście przez te etapy w przeciwnym kierunku, a jeśli tak, to kiedy i na jakich warunkach.

3. Umiejętności metodyczne w zarządzaniu projektami i ludźmi (PM Hard Skills). Obejmuje to wiedzę na temat metodologii, zasad zarządzania i procesów według obszarów. Takie jak Agile, Scrum, Kanban, Waterfall, zarządzanie komunikacją, zarządzanie specyfikacjami i wymaganiami, zarządzanie zmianami, zarządzanie ryzykiem, raportowanie itp. Dobra wiadomość jest taka, że ​​tego wszystkiego można się nauczyć w ten czy inny sposób poprzez odpowiednie szkolenia, seminaria internetowe i różnorodne dostępne materiały online.

4. Umiejętności osobiste w zarządzaniu projektami i ludźmi (PM Soft Skills). Należą do nich: umiejętności zarządzania zespołem i klientami, umiejętność rozwiązywania złożonych zadań, umiejętności prezentacji, umiejętności zarządzania konfliktami, umiejętności komunikacji, umiejętności przekazywania informacji zwrotnych, umiejętność słuchania, słuchania i rozumienia, otwartość na inne punkty widzenia, umiejętność przyznania się do własnych błędów i ich poprawianie, Samokrytyka, Umiejętności przywódcze, Umiejętności coachingowe/mentoringowe, Umiejętność wyjaśniania, Kultura zawodowa (jakość wypowiedzi, e-maili, rozmów telefonicznych), Umiejętność podejmowania decyzji i brania za nie odpowiedzialności, Proaktywność, Umiejętności zarządzania zadaniami, Delegowanie umiejętności, Umiejętności kontroli wykonania, Efektywność osobista, Umiejętności zarządzania czasem. Druga dobra wiadomość jest taka, że ​​tego wszystkiego można się także nauczyć poprzez odpowiednie szkolenie.

Stwórzmy tabelę podsumowującą, w której będzie trzech kandydatów:

1. zewnętrznych bez znajomości branży IT
2. zewnętrzny ze znajomością branży IT
3. wewnętrzny ze znajomością branży IT i specyfiki firmy

W ten sposób staje się oczywiste, gdzie możesz spróbować konkurować.

Uważam, że bez zanurzenia się w środowisku IT nie da się opanować języka IT przynajmniej na poziomie zrozumienia. Nie ma zatem sensu konkurować z punktem pierwszym. Ty (zewnętrzny kandydat spoza branży IT) na pewno przegrasz. Pozostałe trzy obszary są dość podatne na konkurencję. Co więcej, jeśli to drugie (znajomość SDLC) również wymaga zanurzenia się w środowisku do pełnego zrozumienia, to można nauczyć się go przynajmniej z grubsza rozumieć bez pracy w IT. Brak wiedzy SDLC można zrekompensować wiedzą inteligentnego lidera technicznego, architekta, a nawet każdej kompetentnej technicznie osoby z przyszłego zespołu. Aby jednak znaleźć wspólny język z taką osobą i uzyskać jej pomoc, potrzebne są bardzo poważne umiejętności w zakresie PM Soft Skills.

Pozostaje PM Hard Skills i PM Soft Skills – a to są dokładnie te obszary, w których kandydat niebędący informatykiem może znacząco przewyższyć kandydata z branży IT. Dlaczego tak myślę? Wielu menedżerów IT dorastało jako programiści, analitycy i testerzy. Tak, są wśród nich bardzo fajni specjaliści. Wielu z tych kandydatów na stanowiska kierownicze pochodzi z branży IT – w głębi serca pozostają tymi samymi programistami, analitykami i testerami. Oznacza to, że ich umiejętności twarde i miękkie PM mogą być słabiej rozwinięte niż umiejętności kandydata zewnętrznego. Przecież oba te obszary (PM Hard Skills i PM Soft Skills) nie są zależne od specyfiki IT. Można i należy je rozwijać niezależnie od obszaru, w którym aktualnie pracujesz.

W końcu co się dzieje? Jak mogłaby wyglądać nasza tabela podsumowująca, aby kandydat zewnętrzny, który nie pracował wcześniej w IT, miał szansę?

Plan działania, który może (ale nie musi) pomóc. Ale jeśli nic nie zrobisz, nie ma gwarancji, że to pomoże.

1. Porozmawiaj z jednym ze znanych Ci INTELIGENTNYCH ludzi IT (programistami, testerami, analitykami, a jeszcze lepiej, liderami zespołów lub menedżerami) na temat SDLC. Dodatkowo poczytaj o tym w Internecie. Być może warto porozmawiać więcej niż raz, a nawet dwa razy.

2. Spróbuj wybrać rolę asystenta kierownika projektu w IT lub rolę młodszego specjalisty PMO (znajomość procesów zarządczych jest tam ważniejsza niż znajomość etapów i niuansów oraz warunków rozwoju). Gdy już znajdziesz się na którejkolwiek z tych ról, będziesz musiał przestudiować terminologię i specyfikę IT od podszewki, jeśli naprawdę masz silną chęć poruszania się i rozwoju w tym konkretnym obszarze.

3. Wyjaśnij na rozmowie kwalifikacyjnej, że „Twoimi mocnymi stronami są umiejętność rozwiązywania konfliktów, umiejętność pracy w trudnych sytuacjach, sukces w negocjacjach, znajomość języka angielskiego. A Ty uzupełnisz techniczne braki w wiedzy poprzez odpowiednią komunikację i pomoc specjalistów technicznych, którzy będą Twoimi podwładnymi. W końcu praca z ludźmi to Twoja mocna strona.” Mniej więcej tymi słowami. Ważne, żeby to była naprawdę prawda o mocnych stronach, a nie brawura zaliczenia rozmowy kwalifikacyjnej. Uwierz mi, każdy mądry menedżer podczas rozmowy kwalifikacyjnej ustali, czy kłamiesz. I to wszystko się skończy. Ale załóżmy, że dostałeś pracę - wtedy pilnie musisz poszukać sojusznika wśród techników, którzy pomogą w pełni omówić i regularnie wyjaśniać techniczną stronę pracy, zadania i pojawiające się trudności.

Z grubsza rzecz biorąc, ty i techniczny sojusznik będziecie takim połączonym menadżerem z dwiema głowami (być może będziecie potrzebować więcej niż jednego sojusznika). Wielu menedżerów zajmujących się rekrutacją (twój przyszły szef) to rozumie i może nie chcieć tego robić, ponieważ pochłoniesz czas techników, co zmniejszy produktywność całego zespołu. Zatem Twój brak pewnych umiejętności i wiedzy będzie po jednej stronie skali, a po drugiej – Twój przyszły menadżer będzie rozważał możliwy spadek efektywności i produktywności zespołu, do którego planuje Cię zabrać. Im bardziej zależy Ci na wydajności, tym mniejsze jest prawdopodobieństwo, że zostaniesz zatrudniony. Weź to pod uwagę.

Podsumowując. Aby konkurować z facetami, którzy rozumieją IT, a także starają się zostać menadżerami projektów, trzeba ich poważnie przewyższyć w PM Soft Skills.

P.S.: oryginał tego artykułu (i inne ciekawe materiały) można przeczytać na moim blogu:

Cześć przyjaciele!

Tak się składa, że ​​moi znajomi i znajomi moich znajomych, którym mnie polecono, okresowo kontaktują się ze mną z mniej więcej tym samym pytaniem: „Jak mogę zostać kierownikiem projektu w IT, jeśli wcześniej pracowałem na podobnym stanowisku, ale nie w tym?

Ponieważ w dość krótkim czasie zgromadziło się kilka takich próśb, postanowiłem napisać na ten temat osobny artykuł. No cóż, rozumiesz - jestem leniwy i teraz mogę od razu podać link do tego tekstu, zamiast powtarzać odpowiedzi, które zostały już sformułowane kilka razy. Artykuł nie pretenduje do uniwersalności – to tylko mój pogląd na sytuację. Jednocześnie powiem, że podczas rozmów kwalifikacyjnych, zatrudniania i szkolenia kierowników projektów kumuluje się całkiem sporo ogólnych kryteriów, które odpowiadają na pytanie: „Co właściwie powinien wiedzieć i umieć kierownik projektu IT, aby to zrobić?” pracować z sukcesem w IT.

Nawiasem mówiąc, w artykule nie wspomniano nawet o znajomości języka angielskiego. To po prostu konieczność.

Jak zwykle wygląda żądanie:

Aleksiej, dzień dobry! Nazywam się<...>. Polecono mi się z Tobą skontaktować<...>. Potrzebujemy Twojej fachowej porady. Będę wdzięczny za poradę. Znalazłem szkolenie dla kierowników projektów, które czytasz. Chciałbym zapytać, czy powinienem to wziąć. Krótko o mojej sytuacji:<...>Chciałbym spróbować się dalej rozwijać w kierunku projektowym, ale już w obszarze IT. Byłem już na kilku rozmowach kwalifikacyjnych, ale jak dotąd bezskutecznych (pracodawcy często powołują się na brak doświadczenia w IT). W związku z tym wpadłem na pomysł, jak w końcu zmusić pociąg do ruchu. Byłbym bardzo wdzięczny za porady dotyczące kursów. Może warto zainteresować się czymś związanym z kierownikiem projektu, skoro nie ma szans na zatrudnienie na takim stanowisku w branży IT? Byłbym wdzięczny za każdą opinię.

Możliwości aplikacji różnią się jedynie wcześniejszym doświadczeniem zawodowym w niektórych obszarach niezwiązanych z IT.

Co mogę polecić?

Najpierw przestraszę i zagęszczę chmury.

1. Rzeczywiście prawie zawsze odmawiają właśnie dlatego, że niezwykle ważne jest, aby kierownik projektu w IT rozumiał nie tylko zarządzanie projektami jako takie, ale także informatykę. Jest to wymagane do dokładnie dwóch rzeczy: a) znalezienia wspólny język z podwładnymi(testerów, analityków i programistów, którzy wszyscy są specjalistami IT) i w związku z tym zrozumienie istoty dialogów, specyfikacji, problemów itp. oraz b) znalezienie wspólny język z przedstawicielami klientów, które często mają również doświadczenie głównie w IT. Oczywiście są niewielkie szanse na przekonanie przyszłego pracodawcy, że zrozumienie specyfiki branży IT nie jest kluczowe na tym stanowisku. Należy pamiętać, że szanse te są bardzo, bardzo małe. Jednak pracodawca wie lepiej, czego potrzebuje, a przekonanie go do czegoś innego jest dość trudne. Zwłaszcza pracodawcy z branży IT – z pewnością wiedzą, jakiego pracownika potrzebują. Jednocześnie nikt nie zabrania prób przekonywania. Czy to się sprawdzi?

2. W IT zrozumienie etapów rozwoju produktu (SDLC – Software Development Life Cycle) jest bardzo ważne. Praca w organizacjach nie-IT to zrozumienie w pełni Niestety nie do zdobycia. Istnieją problemy specyficzne dla branży IT. A skoro kierownik projektu w IT jest odpowiedzialny za opracowanie produktu/kodu/funkcjonalności w określonym terminie, z określoną jakością i w określonych ramach jakości/funkcjonalności, to musi rozumieć, jak to wszystko osiągnąć środkami, którymi zwykle się zajmuje. ma w sferze IT. Inne branże mogą mieć swoje własne niuanse, które w ten czy inny sposób różnią się od IT.

3. Wszelkie szkolenia z zarządzania projektami „w ogóle” najprawdopodobniej niewiele pomogą. Potrzebujemy szkoleń z zarządzania projektami w IT. Pozwólcie, że wyjaśnię, dlaczego tak sądzę: szkolenia „w ogóle” nie zapewnią zrozumienia dwóch ważnych rzeczy: „języka technicznego IT” i „zrozumienia etapów rozwoju szczególnie w IT”.

4. Każda firma IT ma już swoich pracowników, którzy chcą zostać menedżerami. A ci pracownicy (programiści, testerzy, analitycy) już rozumieją IT (mówią tym samym technicznym językiem, co otaczający ich ludzie), a także znają SDLC. Co więcej, znają klienta, znają specyfikę firmy i jej wewnętrznej kuchni (nie są to punkty krytyczne, ale w porównaniu z zerową wiedzą zewnętrznego kandydata nawet te punkty mogą przeważać). Okazuje się zatem, że kandydat zewnętrzny NIE z branży IT zmuszony jest konkurować zarówno z kandydatami wewnętrznymi z samej firmy, jak i z innymi kandydatami zewnętrznymi, także z branży IT.

Jakie więc parametry uzyskałeś?

1. Biegła znajomość technicznego języka IT. Zrozumienie na przykład czym jest FTP, podpisanie, sprint, ASAP, regresja, XML, żądanie bazy danych, termin ostateczny, FYI, architektura klient-serwer, czerwona linia, test dymu, FTE, wydanie... Lista jest długa. Bycie super ekspertem w niektórych z wymienionych rzeczy wcale nie jest wymagane. Trzeba zrozumieć istotę tego, co to jest w ogóle, co to za terminy, co oznaczają, co się za nimi kryje, inaczej będziesz jak niewidomy w świecie osób widzących.

2. Znajomość SDLC(Cykl Życia Rozwoju Oprogramowania) – etapy rozwoju oprogramowania. I nie tylko wiedza, ale zrozumienie, dlaczego dokładnie te etapy, dlaczego w takiej kolejności, gdzie i dlaczego można przeskakiwać z jednego etapu na drugi i czy możliwe jest przejście przez te etapy w przeciwnym kierunku, a jeśli tak, to kiedy i na jakich warunkach.

3. Umiejętności metodyczne w zarządzaniu projektami i ludźmi (PM Hard Skills). Obejmuje to wiedzę na temat metodologii, zasad zarządzania i procesów według obszarów. Takie jak Agile, Scrum, Kanban, Waterfall, zarządzanie komunikacją, zarządzanie specyfikacjami i wymaganiami, zarządzanie zmianami, zarządzanie ryzykiem, raportowanie itp. Dobra wiadomość jest taka, że ​​tego wszystkiego można się nauczyć w ten czy inny sposób poprzez odpowiednie szkolenia, seminaria internetowe i liczne materiały dostępne w Internecie.

4. Umiejętności osobiste w zarządzaniu projektami i ludźmi (PM Soft Skills). Należą do nich: umiejętności zarządzania zespołem i klientami, umiejętność rozwiązywania złożonych zadań, umiejętności prezentacji, umiejętności zarządzania konfliktami, umiejętności komunikacji, umiejętności przekazywania informacji zwrotnych, umiejętność słuchania, słuchania i rozumienia, otwartość na inne punkty widzenia, umiejętność przyznania się do własnych błędów i ich poprawianie, Samokrytyka, Umiejętności przywódcze, Umiejętności coachingowe/mentoringowe, Umiejętność wyjaśniania, Kultura zawodowa (jakość wypowiedzi, e-maili, rozmów telefonicznych), Umiejętność podejmowania decyzji i brania za nie odpowiedzialności, Proaktywność, Umiejętności zarządzania zadaniami, Delegowanie umiejętności, Umiejętności kontroli wykonania, Efektywność osobista, Umiejętności zarządzania czasem. Druga dobra wiadomość jest taka, że ​​tego wszystkiego można się także nauczyć poprzez odpowiednie szkolenie.

Stwórzmy tabelę podsumowującą, w której będzie trzech kandydatów:

• zewnętrznych bez znajomości branży IT
• zewnętrzny ze znajomością branży IT
• wewnętrzny ze znajomością branży IT i specyfiki firmy

Umiejętność/zdolność	Kandydat zewnętrzny bez Znajomość branży IT	Kandydat zewnętrzny z znajomość branży IT	Wnętrze
1. Znajomość języka informatycznego	—	+	+
2. Znajomość SDLC	—	+/-	+
3. PM Umiejętności twarde	+	+	+
4. PM Kompetencje miękkie	+	+	+

W ten sposób staje się oczywiste, gdzie możesz spróbować konkurować.

Uważam, że bez zanurzenia się w środowisku IT nie da się opanować języka IT przynajmniej na poziomie zrozumienia. Nie ma zatem sensu konkurować z punktem pierwszym. Ty (zewnętrzny kandydat spoza branży IT) na pewno przegrasz. Pozostałe trzy obszary są dość podatne na konkurencję. Co więcej, jeśli to drugie (znajomość SDLC) również wymaga zanurzenia się w środowisku do pełnego zrozumienia, to można nauczyć się go przynajmniej z grubsza rozumieć bez pracy w IT. Brak wiedzy SDLC można zrekompensować wiedzą inteligentnego lidera technicznego, architekta, a nawet każdej kompetentnej technicznie osoby z przyszłego zespołu. Aby jednak znaleźć wspólny język z taką osobą i uzyskać jej pomoc, potrzebne są bardzo poważne umiejętności w zakresie PM Soft Skills.

Pozostaje PM Hard Skills i PM Soft Skills – a to są dokładnie te obszary, w których kandydat niebędący informatykiem może znacząco przewyższyć kandydata z branży IT. Dlaczego tak myślę? Wielu menedżerów IT dorastało jako programiści, analitycy i testerzy. Tak, są wśród nich bardzo fajni specjaliści. Wielu z tych kandydatów na stanowiska kierownicze pochodzi z branży IT – w głębi serca pozostają tymi samymi programistami, analitykami i testerami. Oznacza to, że ich umiejętności twarde i miękkie PM mogą być słabiej rozwinięte niż umiejętności kandydata zewnętrznego. Przecież oba te obszary (PM Hard Skills i PM Soft Skills) nie są zależne od specyfiki IT. Można i należy je rozwijać niezależnie od obszaru, w którym aktualnie pracujesz.

W końcu co się dzieje? Jak mogłaby wyglądać nasza tabela podsumowująca, aby kandydat zewnętrzny, który nie pracował wcześniej w IT, miał szansę?

Umiejętność/zdolność	Kandydat zewnętrzny bez Znajomość branży IT	Kandydat zewnętrzny z znajomość branży IT	Wnętrze kandydat ze znajomością branży IT i specyfiki firmy
1. Znajomość języka informatycznego	—	+	+
2. Znajomość SDLC	—	+/-	+
3. Umiejętności twarde PM	+++	+	+
4. Umiejętności miękkie PM	+++	+	+

Plan działania, który może (ale nie musi) pomóc. Ale jeśli w ogóle nic nie zrobisz, nie ma gwarancji, że to pomoże.

1. Porozmawiaj z jednym ze znanych Ci INTELIGENTNYCH osób IT (programistami, testerami, analitykami, a jeszcze lepiej, liderami zespołów lub menedżerami) na temat SDLC. Dodatkowo poczytaj o tym w Internecie. Być może warto porozmawiać więcej niż raz, a nawet dwa razy.
2. Spróbuj wybrać rolę asystenta kierownika projektu w IT lub rolę młodszego specjalisty PMO (znajomość procesów zarządczych jest tam ważniejsza niż znajomość etapów i niuansów oraz warunków rozwoju). Gdy już znajdziesz się na którejkolwiek z tych ról, będziesz musiał przestudiować terminologię i specyfikę IT od podszewki, jeśli naprawdę masz silną chęć poruszania się i rozwoju w tym konkretnym obszarze.
3. Podczas rozmowy kwalifikacyjnej wyjaśnij, że „Twoimi mocnymi stronami są umiejętność rozwiązywania konfliktów, umiejętność pracy w trudnych sytuacjach, sukces w negocjacjach, znajomość języka angielskiego. A Ty uzupełnisz techniczne braki w wiedzy poprzez odpowiednią komunikację i pomoc specjalistów technicznych, którzy będą Twoimi podwładnymi. W końcu praca z ludźmi to Twoja mocna strona.” Mniej więcej tymi słowami. Ważne, żeby to była naprawdę prawda o mocnych stronach, a nie brawura zaliczenia rozmowy kwalifikacyjnej. Uwierz mi, każdy mądry menedżer podczas rozmowy kwalifikacyjnej ustali, czy kłamiesz. I to wszystko się skończy. Ale załóżmy, że dostałeś pracę - wtedy pilnie musisz poszukać sojusznika wśród techników, którzy pomogą w pełni omówić i regularnie wyjaśniać techniczną stronę pracy, zadania i pojawiające się trudności. Z grubsza rzecz biorąc, ty i techniczny sojusznik będziecie takim połączonym menadżerem z dwiema głowami (być może będziecie potrzebować więcej niż jednego sojusznika). Wielu menedżerów zajmujących się rekrutacją (twój przyszły szef) to rozumie i może nie chcieć tego robić, ponieważ pochłoniesz czas techników, co zmniejszy produktywność całego zespołu. Zatem Twój brak pewnych umiejętności i wiedzy będzie po jednej stronie skali, a po drugiej – Twój przyszły menadżer będzie rozważał możliwy spadek efektywności i produktywności zespołu, do którego planuje Cię zabrać. Im bardziej zależy Ci na wydajności, tym mniejsze jest prawdopodobieństwo, że zostaniesz zatrudniony. Weź to pod uwagę.

Podsumowując. Aby konkurować z facetami, którzy rozumieją IT, a także starają się zostać menadżerami projektów, trzeba ich poważnie przewyższyć w PM Soft Skills.

P.S. Rozsądnie zauważono, że IT nie ogranicza się do rozwoju. Prawda. W takim przypadku drugi punkt (znajomość SDLC) będzie mniej istotny lub całkowicie zastąpiony czymś specyficznym dla Twojego obszaru.

Polub i udostępnij są mile widziane i dają plusa Twojej karmie.

Dziękuję i życzę powodzenia!

Przeczytaj kontynuację tego artykułu „” i!

Kierownik projektu (menedżer projektu lub kierownik projektu) to specjalista odpowiedzialny za pomyślną realizację projektu:

• w terminie określonym przez Klienta;
• o wymaganej jakości;
• ze stałym budżetem i ograniczonymi zasobami ludzkimi;
• na niezbędne wymagania klienta.

W rezultacie głównym efektem pracy tego menadżera jest zadowolenie klienta.

Stanowisko kierownika projektu nakłada na specjalistę dużą odpowiedzialność, ponieważ... To on zarządza wszystkimi procesami projektu i od niego zależy końcowy efekt pracy. Ścieżka kariery kierownika projektu zawsze prowadzi do najwyższego kierownictwa i w stronę projektów o większym budżecie.

Miejsca pracy

Zawód kierownika projektu jest bardzo poszukiwany w wielu branżach:

• technologie informacyjne (programowanie, automatyzacja, tworzenie stron internetowych);
• budowa;
• finanse;
• ubezpieczenie
• farmaceutyki;
• organizacja wydarzeń;
• sport.

Koncepcja Project Managera narodziła się w obszarze technologii informatycznych, dlatego właśnie tam jest największe zapotrzebowanie na menadżerów. Jednocześnie w każdym dużym przedsiębiorstwie zawód kierownika projektu jest niezbędny i ekonomicznie uzasadniony.

Historia zawodu

Przywódcy, dowódcy i przywódcy pojawili się wiele tysięcy lat temu. Niektórzy zarządzali państwem, niektórzy zarządzali armią lub statkiem, niektórzy zarządzali budową. We współczesnym języku każde z ich zadań było projektem, a oni byli jego liderem.

Historia zawodu kierownika projektu wiąże się z pojawieniem się terminu „projekt” w dobie szybkiego rozwoju gospodarczego w XX wieku.

Projekt to zadanie, które ma początek i koniec, jasno określony termin, ograniczenia zasobów, kryteria jakości i pomyślnego zakończenia. Najpierw stanowiska Project Managera pojawiały się w firmach IT, następnie w budownictwie i produkcji, a później w innych branżach.

Obowiązki Kierownika Projektu

Obowiązki kierownika projektu w dużej mierze zależą od obszaru działalności firmy, ale mają wspólny zestaw zadań:

• zarządzanie projektami (kontrola jakości, terminy, budżety i ryzyka);
• komunikacja z klientem (koordynacja planów, terminów, wymagań, budżetów);
• zarządzanie zespołem projektowym;
• prowadzenie dokumentacji projektowej i technicznej:
  • plany kalendarzowe;
  • Specyfikacja techniczna;
  • wymagania funkcjonalne;
  • raporty finansowe;
  • i tak dalej.
• udział w procesie sprzedaży i zawieraniu umów (w tym udział w przetargach);
• postprojektowe zarządzanie klientami i dodatkową sprzedażą.

Czasami do funkcji kierownika projektu zaliczają się zadania kierownika sprzedaży: aktywne poszukiwanie klientów, przygotowywanie ofert handlowych, negocjacje, zawieranie umów itp.

Wymagania stawiane kierownikowi projektu

Wymagania stawiane kierownikom projektów zależą od obszaru działalności firmy. Na budowie potrzebne jest jedno, w IT drugie, w bankowości trzecie. Średni zestaw wymagań to:

• Wykształcenie wyższe (najlepiej w branży, w której pracuje firma);
• Doświadczenie zawodowe co najmniej 1 rok (poważne stanowiska wymagają więcej niż 3 lat);
• Dobra znajomość dziedziny działalności i rynku;
• Umiejętność sporządzania dokumentacji (technicznej i projektowej);
• Doświadczenie przywódcze (w ramach zespołów projektowych);
• Doskonałe umiejętności komunikacyjne.

Czasami wśród wymagań stawianych kierownikom projektów można znaleźć:

• znajomość MS Project;
• angielski w mowie i piśmie;
• zrozumienie zasad zarządzania projektami (np. PMI)
• Gotowość do podróży.

Przykładowe CV Menedżera Projektu

Jak zostać kierownikiem projektu

Wymagana wiedza, umiejętności i zdolności kierownika projektu w istotny sposób zależą od profilu firmy.

Weźmy jako przykład budownictwo. Aby zostać kierownikiem projektu w budownictwie należy posiadać wyższe wykształcenie techniczne oraz doświadczenie w pracy w firmach budowlanych (zwykle powyżej trzech lat i najlepiej na stanowiskach kierowniczych).

Trzeba także umieć kierować zespołem składającym się z więcej niż trzech osób, negocjować na wysokim poziomie i potrafić bronić swojego punktu widzenia, posiadać umiejętność zarządzania czasem i mieć stabilną psychikę.

Wynagrodzenie kierownika projektu

Wynagrodzenie kierownika projektu może wahać się od 20 do 150 tysięcy rubli miesięcznie. Jednocześnie system płatności zawsze zawiera wiele bonusów, premii, procentów od sprzedaży lub ukończonych etapów. Zatem ostateczny dochód może być znacząco wyższy od podanego wynagrodzenia. Średnia pensja kierownika projektu wynosi około 50 tysięcy rubli miesięcznie + premie zależne od wyników pracy.

Gdzie się przeszkolić

Oprócz studiów wyższych na rynku dostępnych jest szereg szkoleń krótkoterminowych, trwających zwykle od tygodnia do roku.

Międzyregionalna Akademia Budownictwa i Zespołu Przemysłowego i jej kursy w kierunku „”.

Instytut Kształcenia Zawodowego „IPO” zaprasza na kursy zdalne na kierunku „” (istnieją opcje 256, 512 i 1024 godzin akademickich) w celu uzyskania dyplomu lub świadectwa państwowego. Przeszkoliliśmy ponad 8 000 absolwentów z niemal 200 miast. Możesz przejść szkolenie zewnętrzne i otrzymać nieoprocentowane raty.