Як проєктному менеджеру швидко влитися на різних стадіях проєкту

Роль проєктного менеджера (PM) має попит не лише в IT-індустрії, але і далеко за її межами. Хоча саме в сегменті розробки вона розкривається найяскравіше, оскільки допомагає оптимізувати робочий процес та підвищити його загальну ефективність.

За даними аналітиків Datanyze, у світі налічується понад 168 тисяч компаній, що надають послуги проєктного менеджменту. Ба більше, нещодавній аналіз групи Mordor Intelligence показав, що капіталізація ПЗ для тих же цілей досягла $5.91 млрд у 2023-му.

За прогнозами цього ж джерела, вартість ринку збільшуватиметься зі значенням CAGR 10.67% до 2028-го, допоки не сягне позначки у $9.81 млрд. Непоганий показник, не вважаєте?

Взагалі ж ця статистика свідчить про головне: популярність PMs доволі швидко зростає, як і їх рівень залученості до різноманітних проєктів, і не лише в рамках IT-сфери. Проте сьогодні ми розглянемо роль PM саме в контексті IT та розробки в цілому. Сфокусуємось на тому, як фахівцю інтегруватись в проєкт на різних його стадіях.

Наші експерти підготували для вас змістовний матеріал, де розкрили такі питання:

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

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

Коротко про головне: життєві цикли продукту та проєкту

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

Ініціація. Цей етап ще умовно називають концептуальним, тобто період, коли ідея майбутнього рішення тільки-но зароджується. На ній зазвичай формується концепція, обговорюються різні варіанти та припущення щодо розвитку проєкту.
Планування. Стадія, коли проєкт від ідеї переходить до певної концепції, що лягає в основу майбутнього продукту. Зазвичай вже на цьому етапі формується бюджет і бізнес-план, проводяться дослідження, розрахунки ризиків тощо.
Запуск. Безпосередній початок роботи над технічною реалізацією IT-рішення, маркетинговою кампанією та плануванням подальших кроків. Загалом цей етап є циклічним, тобто періодично повторюється для актуалізації вектора розробки.
Закриття. Фінальний етап реалізації проєкту, але не його кінець в широкому сенсі. Зазвичай на цій стадії реалізується MVP, який і стає базою для масштабування ідеї та IT-рішення, трансформуючись в наступний проєкт.

Загалом увесь життєвий цикл проєкту є циклічним. Тобто при зміні стадії реалізації попередній етап перезапускається, але вже в оновленому вигляді. Як і з життєвим циклом продукту, для якого реліз MVP є початком, а не завершальним чи проміжним етапом.

Продуктовий життєвий цикл дещо відрізняється від проєктного і має п’ять основних фаз:

Дослідження та аналіз індустрії, її потреб. Рання стадія, на якій вивчається потенціал ідеї, її життєздатність, дохідність. Визначається ROI, аудиторія, болі, потреби та тенденції сегмента – як глобального, так і локального.
Презентація на ринку. Маркетингова кампанія, макети, розробка, тобто все те, що забезпечить продукту адекватну життєздатність, а в ідеалі й високу дохідність. Зазвичай цей етап закінчується з релізом MVP, який далі розширюється через впровадження трендів.
Зростання. Досить великий етап, за час якого популярність продукту зростає до піка та ведеться активна розробка. Зазвичай його називають фазою масштабування, хоча на практиці це робота над помилками та оптимізація IT-рішення, збір відгуків.
Модернізація. Фактично, це переломний момент життєвого циклу продукту, коли він утримується на плаву лише коштом активної підтримки та нововведень. Триває до тих пір, поки інвестиції в розвиток доцільні та приносять (очікуваний) прибуток.
Виведення з ринку. З часом популярність продукту згасає, його цінність зменшується чи втрачається актуальність. Цей період використовують, щоб плавно вивести IT-рішення з обігу та запустити нове, іноді як альтернативу попередньому.

Чи є між цими життєвими циклами різниця? Так, вона очевидна: проєкт може трансформуватись і мігрувати між продуктами (хоч і досить рідко), а от продукти мають скінченний термін експлуатації.

Пряме порівняння між видами життєвих циклів

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

Умовно, коли ми розробляємо якусь хмарну програму, той же онлайн-банкінг, то зазвичай розбиваємо його функціонал на дорожню карту. Спочатку вводимо MVP з базовими функціями, як-от прив’язка карт, переказ коштів, кредитування. А вже далі інтегруємо якісь платіжні можливості: сплата комунальних послуг, покупка квитків в ПЗ тощо.

Для кожної частини цієї розробки ми запускаємо новий проєкт, який включає всі наведені етапи. З наступною фазою аналогічно – новий проєкт, новий функціонал. І так протягом всього життєвого циклу продукту.

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

Коли може виникнути потреба у швидкій інтеграції PM у проєкт

Зазвичай IT-компанії 100% часу зайняті роботою: власними, OSS чи комерційними проєктами. Хоча це й не грає як такої ролі в контексті теми, але при працевлаштуванні типовий PM завжди потрапляє на якусь зі стадій проєкту. Найчастіше або на ініціацію, або на запуск.

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

Ініціація і запуск є цікавими для нас етапами, і ось чому:

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

Власне, останнє безпосередньо стосується актуальної теми, тому пропонуємо сфокусуватись саме на цьому.

Три кити швидкої адаптації

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

І для цього є цікава модель трикутника, вершини якого позначають певні рекомендації:

Досвід. Якщо ви вже маєте досвід роботи в активних проєктах, то він допоможе вам швидше адаптуватись в новому оточенні. Навички, розуміння процесів, знання концепцій та методологій – все це стане у пригоді для асиміляції в компанії.
Документація. Вміння читати та розуміти проєктну документацію – один з китів ефективного PM. Тому, потрапивши в команду посеред циклу розробки, першочергово попросіть всю наявну документацію та ознайомтесь з нею. Так ви пришвидшите свою інтеграцію.
Комунікація. Спілкуйтесь. З тімлідами й з командою як по роботі, так і в неформальному оточенні, наприклад, в пабі за келихом пінного, на природі чи в кафетерії за горнятком кави. Налагоджуйте спільну мову з усіма, це стане вам у пригоді для асиміляції.

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

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

Роль PMs в ініціації проєкту. Перша стадія, перші труднощі та нюанси

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

На цій фазі вам потрібно ознайомитись з:

NDA, MSA, DPA, тобто всією документацією, яка дає уявлення про цілі та обсяги проєкту.
Фінальною ітерацією домовленостей, затверджених замовником.
Брифом проєкту: що, навіщо, технічний стек, нюанси, сегмент тощо.
Планом рекрутингу, щоб розуміти наявність та залученість ресурсів.
PnL та аналізом затрат на роботу.
Детальним описом проєкту.

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

Підготовка до запуску (умовно Sprint 0)

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

Вам критично необхідно буде провести ряд операцій:

Зустріч та комунікація з командою продажів. Аналіз, що і навіщо ми реалізуємо замовнику, а також які ресурси доцільно залучати до роботи.
Спілкування з командою проєкту. Визначення пріоритетів, сильних та слабких сторін, навичок, досвіду. Оцінка рівня розуміння цілей та цінностей проєкту. Підготовчі процеси.
Створення проєкту в PMIS. Написання беклогів, формування дорожньої карти, пріоритетів, розставлення задач та критеріїв для приймання результатів тощо.
Реалізація бази знань з проєкту. Підготовка вичерпної документації з опису актуальних процесів розробки, церемоній Scrum.
Підготовка оточення для розробки. Визначення з інструментарієм, SDK, тестовими програмами, системами CI/CD, фреймворками, стандартизація типів документації, мов програмування і т.д.

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

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

Стадія запуску: що тут відбувається та як розібратись з актуальними справами?

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

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

Бізнес-контекст

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

Наявна документація фази Discovery. Цінності, цілі, бачення розробки, пріоритети та очікувані результати.
Готова бізнес-документація. Наявні проєкти, кошториси, результати аналітики й все, що пов’язане з бізнес-аспектом розробки.
MSA/SoW. Контракти, домовленості, інші типи документів, де чітко сформульовані та детально описані особливості співпраці, вимоги клієнта тощо.
Фінансова документація. Бюджети, розрахунки, зіставлення затрат з потенційним профітом, витрати на наймання ресурсів тощо.
Сценарії користувачів. Результати дослідження про те, які потреби чи болі ЦА закриваються внаслідок розробки та релізу конкретного проєкту.
Дорожня карта та таймлайни. Усе, що дає розуміння, коли і як здавати рішення. За порушення строків випуску чи навіть демонстрації проєкту інвесторам накладаються певні штрафи.
Діаграми. Як BA-діаграми, так і суто технічні, що описують принципи роботи певних фрагментів проєкту. Обов’язкове до ознайомлення.
UX-кейси з макетів. Наявні шаблони взаємодії ЦА з ПЗ, їх цінність та ефективність (за потреби не тільки переглянути, а й внести корективи).
Термінологія, яка використовується в проєкті. Специфіка проєкту, ключові терміни, що застосовуються для роботи в поточних процесах.

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

PM контекст

Якщо з бізнес-контекстом загалом проблем не виникає, оскільки за це відповідають саме BA та топменеджмент проєкту, то з контекстом PM можуть бути певні труднощі. Особливо, якщо попередній фахівець виконував свої обов’язки дещо неякісно.

Але в будь-якому випадку варто звернути увагу на такі нюанси:

Project Charter. Що робиться в проєкті (потрібно зазвичай на випадок його передачі іншим фахівцям).
Процес онбордингу в проєкт. Як та чому наймаються фахівці для роботи над цим проєктом.
Перелік стейкхолдерів. Хто та чому відповідає за проєкт, які має інтереси та бачення продукту.
Графік комунікацій. Коли та з яких причин проводяться зустрічі з командою, інвесторами, стейкхолдерами тощо.
Прогрес у трекінгових системах. Який актуальний стан розробки, задачі, баги і т.д.
Наповненість бази знань з проєкту. Чи вся наявна інформація включена в актуальну документацію.
SDLC процеси. Які актуальні, минулі та майбутні процеси супроводжують проєкт до його завершення.
Звітність з проєкту. Яка документація є по виконаних роботах, готових фрагментах, виправлених багах тощо.
Композиція команди. Як та чому була сформована команда, які фахівці в неї включені й т.д.
Баги та проблеми проєкту. Які складнощі виникали чи виникають з розробкою, організаційні проблеми й не лише.
Дорожня карта. Які є етапи розробки, коли має відбутись випуск повноцінного рішення, який порядок розробки функцій тощо.
Беклог. Чи є графіки, описи, звітність та інше, пов’язане як з технічною, так і з бізнес-стороною проєкту.
Релізний план. З якою періодичністю та в якому масштабі мають відбуватись випуски ітерацій, оновлень продукту.
План управління ресурсами. Як та коли залучаються чи вивільняються люди, бюджет, за яких умов та в яких цілях.

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

Контекст інжинірингу

Як часто жартують фахівці індустрії, для PM недостатньо єдиної спеціалізації, він має знати все, але поверхнево. Насправді це не зовсім жарт, оскільки дійсно фахівець цього профілю повинен вміти організувати роботу і проконтролювати її, поспілкуватись зі стейкхолдерами, провести BA та роз’яснити тімліду розробників складні моменти.

У зв’язку з останнім вам доведеться (навіть при потраплянні в новий проєкт) розбиратись з технічними особливостями.

Звернути увагу слід на наступне:

Технології. Технічний стек, застосовані фреймворки, додаткові інструменти тощо.
Дизайн рішення. Компоненти, модулі, їх взаємодія та загальна концепція роботи.
Сервісна документація. Опис процесів та технічних рішень, що застосовуються в розробці.
Архітектурна документація. Бачення продукту, його модулі, специфіка, структура тощо.
Перелік сторонніх програмних (юридичних) залежностей. Вимоги та дозволи на залучення додаткових технічних ресурсів.
Стандарти кодування. Шаблони, норми та стандарти, якими керуються розробники при створенні продукту.
GitLab, SonarQube. Доступ до спеціальних ресурсів, якими користуються розробники.
Процес розгортання. Те, як відбуваються операції з реалізації рішення, його збірки тощо.
Нефункціональні вимоги. Вимоги до того, як саме має працювати програма, яка її продуктивність очікується.
Система моніторингу розробки. Доступ до стокових метрик та інструментів, якими користується команда для відстежування продуктивності та прогресу.

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

Quality контекст

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

Тож потрібно сфокусуватись також на:

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

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

Контекст команди

Досить цікавий, але водночас і складний елемент адаптації. Комунікація. І якщо команда розробки мінімальна, тобто нараховує до 10 фахівців, то проблем, як правило, не виникає. Але якщо проєкт великий і включає кілька команд по 10-12 експертів, то ситуація стає масштабнішою.

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

Головне – зрозуміти концепцію і знайти спільну мову з командами (або хоча б з тімлідами).

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

Будьте готові до того, що команду може почати штормити чи проявлятимуться певні симптоми дисфункції. У цьому випадку ви як PM маєте ефективно працювати над розв’язанням проблеми та покращенням атмосфери в колективі. Більше про типову проблематику команд та методи її нівелювання можна дізнатись з нашого матеріалу.

Підсумуємо

Обов’язки PMа, на якому б етапі проєкту він не вливався в компанію, залишаються незмінними. Тобто це все той же проєктний менеджмент, метрики, оцінки продуктивності, стану та процесу розробки, тісна робота зі специфікаціями та командами.

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

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

Якщо ж ви хочете отримувати додаткові знання про роль PM, зрозуміти певні методики роботи чи просто покращити свій скіл, щоб бути готовими до будь-яких ситуацій долучайтеся до курсу Project Risk Management Online.