×

Кар’єра в IT: чим займається Project Manager, плюси та мінуси професії

Project Manager (PM) — це спеціаліст, що займається управлінням проєктами. Його завдання — побудувати ефективний процес роботи й дбати про те, щоб проєкт був успішним. Зазвичай проєктний менеджер відповідає за «трикутник проєкту» — час виконання, бюджет і скоуп (обсяг роботи). Та в різних компаніях і в різних проєктах обов’язки Project Manager можуть суттєво відрізнятися.

За даними дослідження DOU, медіанна заробітна плата проєктних менеджерів в ІТ у грудні 2020 року становила $1700. Як правило, РМ заробляє менше, ніж розробник (медіана $2500), проте трохи більше, ніж QA-спеціаліст ($1500). Посада проєктного менеджера доволі популярна на ринку, на DOU наразі відкрито 430 вакансій, більша частина з них у Києві.

Ми розпитали людей, які мають великий досвід роботи проєктними менеджерами в ІТ, про те, чим займається спеціаліст на цій позиції, які знання йому потрібні, про переваги і недоліки професії та про те, як стати РМ’ом. Стаття буде цікавою новачкам у проєктному менеджменті та читачам, які хочуть скласти уявлення про цю посаду.

Наші співрозмовники — проєктні менеджери Анна Шабан, Людмила Криштоп, Олександр Крючков, Ольга Чмир, Юра Кука, Лія Литвиненко, Олег Кубай.

У статті розглянемо такі питання:

— Хто такий проєктний менеджер в ІТ-компанії, чим він займається
— Етапи роботи над проєктом в аутсорс-компанії
— Особливості роботи з проєктом в продуктовій компанії та в аутстафі
— Робочий день проєктного менеджера
— Плюси та мінуси в роботі проєктного менеджера
— Про найскладніші та найцікавіші проєкти
— Знання та навички, необхідні для роботи проєктному менеджеру
— Чи треба проєктному менеджеру в ІТ мати технічний досвід
— Як стати проєктним менеджером
— Література

🔎 Хто такий проєктний менеджер в ІТ-компанії, чим він займається

Проєктний менеджер — це людина, що веде проєкт від початку й до його завершення: спілкується з командою розробників, із замовником, з керівництвом компанії та створює всі умови для того, щоб проєкт був успішним.

Людмила Криштоп:

«Getting things done» (робити так, щоб справи були виконані) — як на мене, це найяскравіший та найстисліший опис обов’язків РМ’а. Перелік завдань дуже великий, та проєктний менеджер може сам визначати, що робити, що делегувати, чого навчити команду, а що вивчити додатково самому.

Юра Кука:

Мені подобається пояснювати, хто такий проєктний менеджер через одну реальну історію.

Це було в 60-ті роки, у період великих космічних перегонів між США і СРСР. У той час Місяць був центром політичних амбіцій, і перед ракетно-космічними конструкторами СРСР стояло складне завдання — здійснити першу м’яку посадку на місячну поверхню. По суті, це був проєкт: він мав певні бізнес-цілі, дедлайни, бюджет.

Та проблема полягала в тому, що вчені ще не знали, яка поверхня Місяця. Одні астрономи вважали, що поверхня тверда, інші — що вона засипана великим шаром пилу. Через цю невизначеність інженери не могли правильно спроєктувати шасі й зробити всі розрахунки для м’якої посадки. Дослідники сперечалися, час затягувався, але остаточного рішення не було.

Керівник космічної програми (по суті, керівник проєкту) Сергій Корольов на одній із зустрічей ухвалив директивне рішення — розвивати проєкт далі, дотримуючись гіпотези, що поверхня Місяця тверда. Звісно, у нього відразу запитали: «А що буде, якщо це не так? Хто відповідатиме за наслідки?». Він взяв відповідальність на себе, навіть написав розписку: «Поверхня Місяця — тверда. С. Корольов». Поставив дату і підпис. Після цього процес продовжився. Рішення Корольова було правильне: в 1966 році автоматична міжпланетна станція здійснила м’яку посадку на Місяць і надіслала фотографії на Землю. Проєкт відбувся, і він був успішним.

Для мене мораль цієї історії в тому, що проєктний менеджер — це людина, яка ухвалює рішення і несе за них відповідальність. Усе решта — Jira, управління ризиками, складання графіків, чартів тощо — другорядне.

🧩 Етапи роботи над проєктом в аутсорс-компанії

Життєвий цикл «класичного» проєкту складається з етапу ініціації (initiation), планування (planning), виконання (execution), закриття і передачі його замовнику (closure). Іноді РМ залучений в роботу ще на етапі ініціації (до того, як компанія підпише контракт з клієнтом), в інших випадках починає працювати вже під час планування.

Проєкти в ІТ-компаніях бувають різними, і тривалість їх виконання теж різна. Іноді клієнт звертається за розробкою фічі, невеликого застосунку або вебсторінки компанії. Такий проєкт може тривати кілька тижнів чи кілька місяців, готовий продукт компанія передає клієнту і далі ним не займається. Є ті, які розробляють кілька років. А бувають практично «нескінченні» проєкти, робота з якими триває багато років: ІТ-продукт увесь час змінюється, вдосконалюється, вимагає нових функцій.

Лія Литвиненко:

Перший етап роботи — це попередній аналіз вимог клієнта. Клієнти приходять різні, і проєкти, які ми отримуємо, бувають на різних етапах: хтось приходить уже з готовою специфікацією, а хтось лише з ідеєю.

На цьому етапі ми аналізуємо та описуємо обсяг робіт, оцінюємо терміни виконання, вартість роботи, трудовитрати та можливі ризики.

Далі йде детальний збір усіх вимог і планування проєкту. Та зазвичай неможливо зробити один план, який був би непорушним від початку до кінця. Навіть на етапі планування дизайну архітектури виникають зміни. Під час розробки функціоналу з’являються додаткові умови, потреба у певних деталях. Через це доводиться часто коригувати план уже в процесі.

Анна Шабан:

На початку роботи з проєктом моє основне завдання полягає в тому, щоб усі попередньо зібрані вимоги клієнта були узгоджені. У нас є документація, ми з клієнтом проходимось по ній, підтверджуємо всі деталі.

Після цього я йду до команди. З нею ми аналізуємо, розкладаємо вимоги клієнта на менші шматочки та оцінюємо, скільки часу треба для того, щоб втілити ці вимоги в життя. Оцінку команди я маю затвердити із замовником. Якщо ж він не згоден — щось переробляємо, шукаємо компроміс.

Далі переходимо до розробки. На цьому етапі трохи інша взаємодія. У нас є таймлайн — певний календарний план (узгоджений з клієнтом і командою), за яким ми рухаємося, щоб виконати всі вимоги до проєкту. Якщо працюємо за методологією Agile (наприклад, за скрамом), то кожен спринт (кожен тиждень чи кожні два тижні) показуємо певний результат клієнту та отримуємо відгук: це те, що він хотів, чи ні. Так працюємо упродовж проєкту. Звісно, бувають зміни й багато іншого. Але загалом це має такий вигляд: видаємо результати, отримуємо відгук, вносимо зміни (якщо необхідно) та працюємо далі. За такої послідовної взаємодії в кінці проєкту ймовірність несподіванок для клієнта і для нас набагато менша.

Після завершення основної розробки йде етап фінального тестування (звісно, проміжне тестування є у кожному спринті). Якщо вже є реальні користувачі продукту (наприклад, ми розробляли його другу версію), є з ким поспілкуватися, то збираємо відгук від них. Опрацьовуємо його, інколи робимо зміни, і випускаємо проєкт у життя.

Лія Литвиненко:

Буває, що розробка завершилася, проєкт уже в релізі, але ми переводимо його на сапорт і продовжуємо з ним працювати. Сапорт — це підтримка продукту: його обслуговування, оновлення, створення додаткового функціонала.

Оскільки я працюю в аутсорс-компанії, то паралельно із закінченням попереднього проєкту шукаю новий (веду перемовини щодо нових проєктів, аналізую вимоги). Адже команду треба забезпечити роботою далі.

✔️ Особливості роботи з проєктом в продуктовій компанії та в аутстафі

Юра Кука:

Загалом обов’язки проєктного менеджера в аутсорс-компанії і в продуктовій компанії однакові. Ти — відповідальна особа перед бізнесом, у тебе є команда, з якою ви маєте зробити проєкт вчасно, з певним бюджетом і на вказаний скоуп (тобто не змінюючи якість).

Процес роботи над проєктом у продуктовій компанії можна розділити на два великі етапи: діскавері та делівері. Діскавері — це етап, на якому представники компанії, бізнесу (продакт-менеджери) придумують конкретну ідею. Вони знаходять проблему потенційних користувачів і шукають, як її розв’язати — за допомогою фічі, нової програми, додаткових інструкцій тощо. На етапі діскавері відбувається багато процесів і врешті-решт з’являється концепція: що ми будемо робити. Концепцію проєкту передають в інжиніринг — команді розробників і мені. І ми запускаємо делівері.

Продакт-менеджер призначає мітинг для команди розробників і презентує ідею. Нам показують концепцію проєкту, пояснюють основні бізнес-вимоги. Ми ставимо питання, щось уточнюємо. Якщо бізнес-команда вирішувала, що потрібно зробити, то ми вже ухвалюємо рішення, як це будемо робити. Вибираємо технічний стек, проєктуємо, створюємо дизайн архітектури, затверджуємо нюанси. Після цього ділимо проєкт на окремі завдання та плануємо роботу. Кожне завдання оцінюємо в годинах роботи чи в Story Point. У результаті маємо скласти «дорожню карту», наш календар роботи. Наприклад, ми плануємо розробити фічу з 1 березня до 16 червня. І маємо розписати всі завдання на цей період, враховуючи можливі відпустки та свята.

Свої розрахунки ми показуємо бізнес-команді. Зазвичай бізнес хоче закінчити проєкт набагато раніше, зробити все швидше, тому далі відбувається «етап торгів». Тут я виконую роль дипломата між розробкою і бізнесом. Я розумію потреби бізнесу і розумію інженерів — вони хочуть зробити якісний продукт, однак не овертаймити. На етапі «торгів» ми думаємо, де можна «стиснутися» — оптимізувати, трохи спростити архітектуру. Бізнес зі свого боку думає, яку частину функціоналу можна відрізати і випустити в наступній ітерації.

Головне — запустити проєкт, а далі вся робота рухається за скрамом. Щотижня ми демонструємо результати. Тепер це відбувається в Zoom: під’єднується команда розробників і бізнес-команда. Ми отримуємо зворотний зв’язок. Можливо, після демонстрації результату якесь завдання втратить свою актуальність, але з’явиться нове. Після кожної зустрічі я складаю документальний письмовий звіт — що було зроблено за тиждень, що залишилося.

Анна Шабан:

Окрім аутсорсу, я працюю і з аутстаф-проєктами. Загалом у цій моделі проєктний менеджер буває рідко. В аутстафінгу команда прямо працює з клієнтом. Там я виступаю в ролі супервайзера: приходжу до команди та з’ясовую, як іде робота, чи усе добре, чи, може, щось треба вдосконалити. Наприклад, може виникнути потреба додати ще людей у команду, тоді я цим займаюсь.

Час від часу проводжу мітинги сам на сам з кожною людиною з команди, а також раз на два тижні обов’язково спілкуюся з клієнтом. Це потрібно для того, щоб переконатися, що в команді усі працюють злагоджено й у замовника немає скарг чи побажань. Якщо усе добре, я зосереджуюся на проєкті мінімально. Клієнт спілкується з командою прямо, спеціалісти задоволені, клієнт задоволений — все чудово. Я долучаюся тоді, коли щось не так, і допомагаю розв’язати проблему.

📅 Робочий день проєктного менеджера

Більшу частину робочого часу проєктний менеджер витрачає на комунікацію. Це:

  • мітинги з розробниками, коли РМ збирає всю команду і коротко з’ясовує поточний стан справ у кожної людини та плани на день (чи на певний період);
  • мітинги з ключовими людьми в команді — архітекторами, бізнес-аналітиками;
  • «one-on-one» — індивідуальні зустрічі з членами команди (їх проводять щомісяця або що два тижні з кожним);
  • зустрічі з клієнтами;
  • зустрічі з керівництвом компанії;
  • різноманітні ad-hoc-зустрічі та листування з усіма учасниками проєкту.

Певний час займає робота з інструментами для проєктного менеджменту: наприклад, з системою JIRA, різноманітними метриками, поставленими на проєкті. Після усіх мітингів, перевірки пошти, РМ має зафіксувати домовленості, створити нові завдання у таск-трекері та переконатися, що усе йде за планом.

Проєктний менеджер займається веденням усієї документації проєкту: виставляє інвойси клієнту, задокументовує процеси. Часто РМ опікується процесами, пов’язаними з піпл-менеджментом: затверджує документи для збільшення зарплати співробітникам; перевіряє, чи всі прозвітували про роботу, щоб нарахувати платню; заповнює документи для відпусток.

Крім того, РМ може бути залучений в інші активності компанії — брати участь в інтерв’ю, коли набирають фахівців у команду; відвідувати фідбек-сесії чи appraisals 360 учасників своєї команди; долучатися до аудитів інших проєктів компанії; готувати нові пропозиції для свого клієнта (чи для інших клієнтів компанії).

Іноді проєктний менеджер веде кілька проєктів, тоді кількість мітингів і документації збільшується. Звісно, в різних компаніях завдання, які виконує РМ, можуть суттєво відрізнятися.

Анна Шабан:

Свій план на день я готую ввечері та коригую його зранку. Мої клієнти в Штатах, вночі від них надходять листи, тож зранку можуть з’явитися нові невідкладні справи.

Конкретний розклад дня залежить від кількості проєктів та їх фаз, але щодня у мене є обов’язкові короткі daily standup зустрічі з командами та 1–2 дзвінки з клієнтами.

Ольга Чмир:

Зазвичай мій робочий день починається із перевірки пошти та корпоративного слаку. Далі маю 0,5 години на планування дня.

В першій половині дня відбуваються щоденні та щотижневі мітинги (команда сама вирішує кількість сінків — коротких зустрічей, які їй потрібні). Після обіду — спілкування з керівництвом, перегляд і зміни робочих планів, звітування, робота з документами та багато іншого. З 5 до 7 вечора — дзвінки із продакт-командами зі Штатів.

💬 Плюси та мінуси в роботі PM’а

Проєктний менеджер — позиція, на якій є багато спілкування з людьми. Це може бути і перевагою, і недоліком. Перевагою — завдяки знайомству з цікавими людьми, з різноманітними культурами. Недоліком — коли доводиться працювати із «складними» клієнтами чи співробітниками, таке теж часто буває.

Як перевагу у своїй роботі проєктні менеджери називають відчуття масштабності завдань, коли ти можеш формувати команду з різних людей, організовувати процес розробки, приносити користь клієнту (чи суспільству загалом у соціально важливих проєктах). Як мінус — велику відповідальність. Якщо на проєкті стаються невдачі, навіть не пов’язані з роботою РМ’а, за роботу команди перед керівництвом все одно відповідає цей фахівець.

Людмила Криштоп:

Проєктний менеджер не відразу бачить реальний результат своєї роботи, а людині це потрібно з погляду психології. Розробник, тестувальник, дизайнер та інші професіонали можуть подивитись на плоди своєї праці, а от РМ’у складніше розгледіти їх в короткостроковій перспективі. Це може викликати демотивацію. Та треба витримати, пройти шлях до кінця, щоб побачити результат і відчути задоволення від нього.

Анна Шабан:

З того, що буває складним — це навантаження. Зазвичай я веду два-три проєкти — і етапи роботи у них не збігаються. Коли на одному проєкті все спокійно й ми просто ведемо розробку, то на другому може бути більш активна фаза, коли треба готувати демонстрацію для клієнта, презентації потенційним користувачам. Та іноді активні фази на проєктах відбуваються одночасно, тоді буває складно: треба робити багато речей і все мусить бути вчасно.

З плюсів — мені подобається бачити, як перетворюється команда з «щойно зібраних у групу людей» на ефективну та самоорганізовану. Отримувати відгук від колег та клієнтів про свою роботу, мати змогу постійно вдосконалюватись, поглинати нові знання.

Юра Кука:

Для мене робота РМ — це можливість не сидіти на місці. Мені потрібен постійний екшн, зміни. Як казав хтось із гонщиків: «Якщо ти їдеш на швидкісному треку і в тебе усе під контролем, ти їдеш надто повільно». Я люблю ці постійні «небезпечні ситуації» і залученість у них.

Лія Литвиненко:

Іноді проєктному менеджеру треба ухвалювати складні рішення і доносити їх людям, згладжувати гострі кути, вирішувати конфліктні моменти.

РМ спілкується з розробниками, з клієнтом, з керівництвом своєї компанії, треба балансувати, знаходити такі рішення, щоб усі були задоволені. На жаль, так не завжди виходить, іноді треба домовлятися й жертвувати чиїмись інтересами.

Це складна частина роботи, хоча й по-своєму цікава.

Ольга Чмир:

Мені подобається розбиратися в складних ситуаціях, розв’язувати різноманітні задачі, спілкуватися з людьми, планувати.

Не подобається писати багато документації. Особливо, якщо її ніхто не читає.

🔔 Про найскладніші та найцікавіші проєкти

Лія Литвиненко:

Іноді у найскладніших клієнтів найцікавіші проєкти. У нас був дуже цікавий проєкт з онлайн-букінгу та довгострокової оренди з клієнтом із Японії.

Цей проєкт був складним через те, що замовник постійно вносив зміни, практично щодня. Окрім того, інтерфейс сервісу був японською мовою, коли ми виправляли помилки у текстах, це було схоже на складну гру із пошуку слів.

Був випадок, коли клієнт надіслав фото (скриншот свого екрану), там ієрогліфами було написано, що треба виправити. Іншого разу надійшов PDF-файл з японським текстом з правками. Тоді я копіювала текст у гугл-перекладач, з усім розбиралася. Витрачала кілька годин на те, щоб зрозуміти, що треба зробити. Далі розказувала це команді, і ми реалізували.

Завдяки згуртованій команді, яку вдалося побудувати, усі проблеми вирішувалися. В цей проєкт треба було вкласти трохи більше часу й сил, постійно підбадьорювати колег, бо в такому режимі, коли йдуть постійні зміни, працювати складно. Розробка тривала рік. Пізніше у нас були й інші проєкти з цим клієнтом, та вони були простішими.

Олег Кубай:

Складні проєкти бувають у великих програмах, де є кілька вендорів (компаній, що розробляють програмне забезпечення). Іноді вони розміщені в різних часових поясах, у різних культурах і конкурують між собою. Наприклад, з проєктом працює кілька команд з Індії, колектив з Білорусі чи Росії, наша команда з України та ще є команди в Британії чи у Штатах.

Ми, як один з вендорів, не ставимо процеси глобально на всій програмі, робимо якусь частину роботи та взаємодіємо з іншими. У таких проєктах буває складно налаштувати злагоджені процеси. Тут важливо, щоб був відкритий клієнт, готовий слухати та розуміти, як краще побудувати управління проєктом. Важливо, щоб усе працювало як єдиний механізм, тоді буде якісна робота і хороший кінцевий результат.

Щодо найцікавішого проєкту, з яким я працював, — це був величезний well-funded стартап, маркетингова платформа, пов’язана з екоактивностями. Цей американський стартап мав амбітну мету — поліпшити ситуацію із сортуванням сміття, змінити поведінку людей у цьому плані. Платформа мотивувала користувачів робити добрі справи для природи й за це отримувати винагороду у вигляді різних бонусів, грошей. Вони активно набирали юзерів, та продукт явно випереджав свій час. Думаю, що їхня модель надто швидко вийшла на ринок і проводила занадто агресивну політику, в результаті вони не стали комерційно успішними. Ця платформа є на ринку, але не має того глобального масштабу, який міг би бути. Та все одно робота з цим продуктом була дуже цікавою, це був гарний досвід.

💡 Знання та навички, необхідні для роботи Project Manager’y

Окрім базових технічних знань, проєктний менеджер має знати теорію управління проєктами та вміти застосовувати її в роботі (як спланувати та виміряти прогрес проєкту, планувати роботу з ризиками, працювати з бюджетом); розуміти життєвий цикл розробки програмного забезпечення та яка методологія найкраще підійде до кожного проєкту (Scrum, Kanban, SAFe та інше); добре володіти англійською мовою (для роботи з іноземними клієнтами і щоб читати профільні статті). І особливо важливі в цій роботі софт скіли: емпатія, комунікабельність, навички самоорганізації, цілеспрямованість, уміння бути стійким до конфліктів і вирішувати їх.

Олександр Крючков:

РМ’у в роботі допомагає уміння думати на декілька кроків уперед, прораховувати всі ризики та їхні наслідки. Важливо вміти слухати та чути, а також аргументовано доносити свою точку зору.

Ще одна важлива риса — стресостійкість, уміння залишатись спокійним навіть під час кризи та конфлікту.

Та особливо важлива повага до людей — насамперед до команди.

Юра Кука:

Якщо говорити про набір навичок, важливих для роботи РМ’а, то передусім це софт скіли: вміння спілкуватися з людьми, презентувати, переконувати, «продавати» свої ідеї, впевненість у тому, що говориш.

Друге — англійська мова. Якщо хочеш бути більш цінним фахівцем на ринку, без знання мови не обійтися.

Третє — бажання максимально зануритися в середовище проєктного менеджменту. РМ має читати багато фахової літератури, проходити курси, бувати на конференціях, спілкуватися з іншими людьми з цієї сфери. Менеджмент — це дисципліна, в якій немає правильних відповідей. Мені, як колишньому технарю, спочатку було складно з цим погодитись. Якщо я писав якусь команду в консолі, то знав, що програма виконає певну операцію (чи в крайньому разі не виконає). Та коли робиш щось як менеджер, ніколи не можеш бути до кінця певним у наслідках своїх дій. Робота з людьми завжди непередбачувана. Відповідно важливо мати досвід того, як ти пережив ту чи іншу ситуацію, щоб знати шляхи її вирішення, найкращі практики. Оскільки весь досвід пережити складно (чи й неможливо), корисно знати та розуміти досвід інших людей, твоїх колег. Через читання літератури, відвідування конференцій, спілкування отримувати його дуже круто.

Ще одна важлива навичка — не боятися помилок і відмов. Це те, що трапляється в роботі РМ’а досить часто, на різних етапах. Проєктний менеджер — людина, що пропускає крізь себе багато негативу, треба вміти з цим справлятися.

Уміння працювати з JIRA, будувати красиві діаграми Ганта, чартери я поставив би в кінець списку. По суті, це інструменти, навчитися працювати з ними не дуже складно. Та якщо немає таких базових навичок, як стійкість до турбулентності, змін й інших софт скілів — працювати в менеджменті буде складно.

📓 Чи треба проєктному менеджеру в ІТ мати технічний досвід

Іноді люди починають працювати проєктними менеджерами після того, як певний час попрацювали на якійсь технічній позиції — розробниками чи тестувальниками. Цей досвід допомагає в роботі, але він не обов’язковий. Та все ж без базових знань в ІТ проєктному менеджеру не обійтися.

Олександр Крючков:

Вважаю, що технічний бекграунд (2–3 роки роботи розробником) допомагає розуміти процес створення програмного забезпечення, його життєвий цикл, розуміти проблеми розробників, говорити з ними однією мовою та хоча б приблизно орієнтуватися у рівні складності задач. Команда завжди сприймає менеджера з технічним бекграундом краще, бо йому легше пояснити технічні аспекти проблеми.

Водночас я бачив успішних менеджерів без технічного досвіду. Тож можу сказати, що це великий плюс, але він не є необхідною умовою.

Олег Кубай:

Думаю, що більше технічного досвіду в РМ’а, то краще. Єдине, що РМ’у не варто увесь час занурюватися в технічні деталі та залишатися тільки там, треба бачити ширшу картину.

📌 Як стати проєктним менеджером

Робота РМ’а доволі складна і специфічна, тож перш ніж записуватися на курси й читати купу фахової літератури, проєктні менеджери радять «приміряти» професію на себе і розібратися, чи справді цей напрям тобі цікавий.

Олександр Крючков:

Людині, що хоче розвиватись як РМ, варто було б спочатку попрацювати на координаційній ролі (скажімо, як адміністратор проєкту або скрам-майстер). Подивитися, як робляться проєкти. Після цього (або паралельно) можна вчитись на курсах — тут допоможуть і Agile-курси, і курси з управління проєктами.

Анна Шабан:

Я б порадила спочатку послухати доповіді або вебінари людей, які вже працюють у цій сфері, щоб зрозуміти, чи роль проджект-менеджера — це справді те, що вам підходить.

Далі можна вибрати одну книгу про проєктний менеджмент для початківців і курси. Добре, коли курс буде більш-менш масштабним — хоча б на три місяці. Бувають короткі курси, вони дають інформацію дуже стисло. На мою думку, вони підходять тим, хто має хоча б якийсь досвід. Інформація накладається на досвід і формується структура. Якщо досвіду зовсім немає, краще обрати розширене навчання, щоб було більше деталей.

Іноді в ІТ-компаніях пропонують роботу для проєктних менеджерів на рівень трейні (trainee). Це навіть не джуніор, не початковий рівень, а передпочатковий. Трейні проходять стажування в компанії — навчаються та отримують практичний досвід, після навчання є шанс бути працевлаштованим у тій самій компанії. Думаю, це теж хороша можливість для початківців.

Добре, коли РМ-початківець поруч має ментора. У великих компаніях, коли беруть на роботу джуніор проджект-менеджера з досвідом роботи до року, то зазвичай призначають йому наставника — колегу з більшим досвідом. Він координує роботу, підтримує у складних питаннях та ситуаціях і «втягує» молодшого колегу в потік роботи менеджера.

📚 Література

Основна книга проєктного менеджера — PMBOK. Це книга-довідник про управління проєктами, але вона написана досить «сухо» і складно. Тому менеджерам-початківцям зазвичай радять читати простішу літературу. Окрім того, є багато популярних та цікаво написаних книг для розвитку м’яких навичок проєктних менеджерів.

Список книг, які порадили наші співрозмовники:

А ще Ольга Чмир радить читати художню літературу. Вона допомагає відновити сили після роботи й збільшує словниковий запас. Уміння формулювати думки, підбирати потрібні слова дуже важливе для менеджера.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось22
До обраногоВ обраному26
LinkedIn

Схожі статті




8 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Дякую за статтю.Єдине, що я не зрозумів.
У PM відповідальності більше, роботи більше (буває кілька проектів і замовників), а зарплати менше, ніж у девелопера.

Ну дивіться. Я в самій індустрії десь 12.5 років (до того в мене був «начальник КТВ»), перші 2.5 роки у Вінниці. Там проджект-менеджерами були — вчорашній лід 28 років і взагалі двоє на той час зубрів індустрії, чоловік і жінка 37 і 35 років відповідно. Всім було очевидно, що це наступний крок у кар‘єрі. Те ж саме було у Львові — перші п‘ять років усім було за 30, всі були досвідчені.
В 2016 було оголошено, що тепер кожен проєктик буде мати свого координатора і я вперше зустрівся з молодшою за мене ПМ-кою — за сумісництвом, людиною, яка в IT більше нічим не займалася і єдиною адекватною керівницею з цього різновиду «проджект-координаторів».
На той момент виявилося, що роботи багато, а топових пм-в (вони ж «справжні», «сіньйор» або «engineering manager-и») мало, тому до звиклого раніше кар‘єрного шляху — «з лідів у менеджери» додався новий — в секретарі проєктів без досвіду, але з софт-скіллами.
І саме такі люди обвалили медіану.

Був випадок, коли клієнт надіслав фото (скриншот свого екрану), там ієрогліфами було написано, що треба виправити. Іншого разу надійшов PDF-файл з японським текстом з правками. Тоді я копіювала текст у гугл-перекладач, з усім розбиралася. Витрачала кілька годин на те, щоб зрозуміти, що треба зробити. Далі розказувала це команді, і ми реалізували.

А ви не пробували порозумітися з замовником і попросити перейти на англійську мову?

Наброшу: без знаний матстата PM разве что может двигать тикеты в джире и в дверь туалета стучать с криком «когда задача будет сделана».

На самом деле все крайне просто — задача проджекта закрывать все вопросы касающиеся бизнеса, что бы они не становились проблемами для ИТ, дизайна, аналитиков, прочих.

Графички отчетики и прочее это про про проджекта. этим может заниматься кто угодно. это просто отчет по работе. Он может быть а может и не быть. Мне больше нра отчеты в виде демо где есть вся команда. это и клиенту понятнее и нету сухости и уныния.

Очень неправильно думать что проджект это руководитель проекта и такой подход всегда будет приводить к проблемам. Так как для руководство нужно хорошее понимание самого проекта. И если это ИТ то по сути нада быть немного ИТшником.. чего в большинстве случаев нет.
А посему по нормальному проджект идет на уровне лидов, просто отвечает за еще одну грань проекта, за которую не отвечают другие. И его сила в правильном взаимодействии и снятии левого гемора с остальных, и помощь им что бы все не пошло коту под хвост.

правильно всё это совмещать и плюс есть конкретные «не точности понимания» что есть собственно «проект» потому именно отсюда рождаются «уточнения»

Графички отчетики и прочее это про про проджекта. этим может заниматься кто угодно. это просто отчет по работе. Он может быть а может и не быть.

+ Pmbook к литературе.
Но для её понимания нужен управленческий опыт.
С нуля не уверен, что нужно изучать 🔬 эту методичку.

Підписатись на коментарі