Сучасній компанії, особливо, якщо вона пов’язана з IT, потрібен проєктний менеджер (Project Manager, PM). Це фахівець, який виконує свої обов’язки, комунікує з командою тощо. Проте далеко не всі розуміють, що саме включене в перелік зон відповідальності цієї посади.
Відповідно, від компанії до компанії вимоги до кандидата на зазначену роль можуть значно відрізнятись. Це створює певний дискомфорт для тих, хто шукає роботу саме в цій галузі.
Фахівці E5 підготували матеріал, де чітко описали, що має робити проєктний менеджер, а що не входить в його перелік обов’язків. Зрозуміло, що є інші нюанси, які залежать напряму від організації-працедавця, проте загалом норми та стандарти для всіх єдині.
Далі розкриємо такі питання:
- Важливість проєктного менеджера для компанії.
- Роль PM у типових процесах бізнесу.
- Вплив на якість продуктів.
- Обов’язки та ситуативні ролі на посаді.
- Методики та рекомендації, що допомагають розвиватись фахівцю.
Короткий огляд професії
Просто поглянувши на назву посади, ми розуміємо, що ключова задача фахівця полягає у керуванні проєктами. Проте чи значить це, що він їх сам створює, сам затверджує та ще й, можливо, реалізує? Звісно ж, ні.
Проєктний менеджер – це експерт з сильно вираженими лідерськими якостями, комунікативними навичками та глибокими профільними знаннями. Серед його обов’язків:
- Планування проєктів.
- Визначення цілей проєкту.
- Комунікація з інвесторами (або клієнтами).
- Контроль прогресу та роботи в цілому.
- Бюджетування проєкту.
- Управління обсягом та розкладом робіт.
- Керування ризиками.
- Декомпозиція задач.
- Робота з командою.
Це якщо розглядати професію в широкому сенсі. Фактично ж, перелік може дещо видозмінюватись, залежно від актуальних потреб проєкту чи методологій. Також він базується й на стандартах, а саме – міжнародному PMBOK.
Project Management Baggy Of Knowledge
Якщо узагальнити, то PMBOK – стандарт індустрії PM, що транслює актуальні вектори розвитку професії. Займається його модернізацією група PMI, що спеціалізується саме на цьому типі діяльності.
До речі, E5 є сертифікованим провайдером від PMI, оскільки використовує в роботі та навчанні саме ті методики, що розробляються групою PMI.
Чому ми згадуємо про PMBOK у контексті матеріалу? Тому, що це важливий стандарт для професії PM. Приймаєте ви його чи ні – справа другорядна, головне, ознайомитись з ним для професійних цілей, в тому числі для підвищення кваліфікації.
Актуальна (сьома ітерація) гайду дещо трансформувалась, якщо порівнювати з попередніми. Зараз акцент зміщений в сторону Agile, а сам матеріал легкий для сприйняття навіть початківцям. Ключові об’єкти в PMBOK – принципи, які поєднуються з процесами чи інструментами.
Кейси використання стандартів PMBOK в реальності
Щоб краще розкрити суть матеріалу, фахівці E5 підготували для вас перелік з 12 ключових положень про те, що означає бути Project Manager на практиці. Далі ви дізнаєтесь про ролі, які виконує PM та їх суть в розрізі проєктів.
Стюарт
Фактично PM є інтегратором в організації. Фахівець має охопити відразу три сторони проєкту: команду, компанію та замовника, щоб синхронізувати кооперацію та налагодити робочі процеси. Стратегії, візії, місії, прямі комунікації, пошук компромісів… Усе це слід врахувати до запуску проєкту.
Крім того, експерт має донести команді суть задачі, корпоративну політику та інформацію щодо потреб проєкту, клієнта, ЦА тощо. Це необхідно, щоб команда інтегрувалася, адаптувалася та виконала покладені на неї задачі максимально ефективно.
Team Environment
PM має створити профільне робоче оточення для реалізації проєкту. Це означає, що він повинен підібрати фахівців певного рівня, досвіду та навичок. Важливо, щоб команда складалась за принципом «пазла», тобто навіть за наявності прогалин у скілах вона функціонувала як єдиний організм та компенсувала певні недоліки окремих учасників.
Зрозуміло, що у проєктах на 100 осіб проводити співбесіди з кожним кандидатом доволі проблематично. Проте можна сфокусуватись на ключових ролях, наприклад, BA чи Team Lead, а далі делегувати їм цю задачу.
Ще один цікавий нюанс: важливо створити таке оточення, щоб його правила були зрозумілі колективу, а також прийняті переважною більшістю учасників проєкту. І для цього варто їх пропрацювати разом з командою. Наприклад:
- виділити цінності проєкту та колаборації;
- встановити цілі проєкту;
- вирішити алгоритми погодження змін тощо;
- виявити потенційні конфлікти та способи їх нівелювання;
- запропонувати моделі поведінки.
Фактично ж, цей перелік може бути майже нескінченним, а його положення залежать від колективного характеру команди.
Додаткові нюанси організації оточення
Також варто створити командний SDLC гайдлайн, де буде прописано:
- обов’язки PO, PM, команди розробки;
- структурована послідовність процесів;
- алгоритми взаємодії між учасниками проєкту.
Такий підхід дозволяє вибудувати архітектуру роботи. Згідно з нею всі, хто залучений до проєкту, отримають своє коло обов’язків, за які нестимуть відповідальність. Це ж саме стосується й документування процесів, що є дуже важливим компонентом розробки.
Окрім цього, знадобиться Raci Matrix, де будуть прописані сфери відповідальності всіх лідерських ролей проєкту. А також план комунікацій, де вказана частота, методи мітингів, цілі та ключові питання.
Навряд чи варто нагадувати, що в роль PM автоматично включається робота з командою. Тобто персональні комунікації, мітинги, перевірка здоров’я та продуктивності колективу, тімбілдинг, масові святкування тощо.
Кооперація зі стейкхолдерами
Стейкхолдером вважається особа, яка зацікавлена в певному проєкті (або ж, навпаки, проєкт/продукт залежний від неї). І саме на PM покладений обов’язок постійно комунікувати з цим контингентом.
Щоб ефективно налагодити процес взаємодії зі стейкхолдером, фахівцю необхідні комунікативні навички. Але далеко не на базовому рівні, а, так би мовити, на наближеному до максимально можливого.
Усе тому, що PM має вміти:
- доносити актуальний стан речей;
- відповідати за прийняті рішення (чи узгоджувати ідеї);
- розв’язувати ризикові чи конфліктні ситуації;
- коригувати задачі, цілі чи бачення проєкту;
- знаходити підхід до кожної сторони, що має вплив на продукт.
Для останнього і взагалі створюється матриця стейкхолдерів, де вказуються відомості про кожного, їх відношення до проєкту тощо. Також тут прописується стратегія, яку PM застосовує до конкретної особи під час комунікаційних сеансів.
Фокусування на цінності
Будь-який проєкт чи продукт має певні переваги та цінність як для ЦА, так і для стейкхолдерів, команди розробки. Роль PM полягає в тому, щоб використати цю цінність для форсування роботи над IT-рішенням різними способами. Наприклад:
- мотивувати команду;
- залучити додаткове фінансування;
- просунути якусь ідею чи концепцію;
- переформатувати певний компонент;
- переглянути цілі чи методи реалізації проєкту.
Власне, для цього застосовують метод «Business Model Canvas», де описані:
- перспективи проєкту;
- цілі, переваги, ризики;
- розрахунки потенційної дохідності та інвестицій в розробку;
- аналіз сегмента та стану ринку в певному регіоні;
- методи монетизації тощо.
Це важливий інструмент не лише для PM, але й для BA, PO, інвесторів, стейкхолдерів та команди. Саме тут формується винятковість та цінність продукту, яку PM має донести зацікавленим особам.
Після того, як PM обговорив та пропрацював бачення цінності продукту, створюється карта переваг. Вже її роль полягає в тому, щоб описати ключові вигоди для компанії:
- Вихід на новий ринок.
- Збільшення аудиторії.
- Розширення клієнтської та партнерської бази.
- Дохідність від прямої чи непрямої монетизації.
- Потенціал масштабування компанії тощо.
Отриманий перелік має бути тим фактором, що мотивує не лише інвесторів, від яких планується залучити фінансування, але і компанію. Тобто стимулом можуть послужити як підвищення рівня заробітної плати, так і зростання рейтингу організації, що автоматично апгрейдить престижність роботи в ній.
Готовність до адаптацій
Система розробки, як і цінності проєкту чи його склад, може змінюватись. Це нормальна практика, особливо, якщо використовується методологія Agile. Важливо, щоб зміни не застали PM зненацька та не створили дискомфорту всьому оточенню.
Власне, готовність до подібного розвитку подій і є однією з рис ролі PM. Але не тільки. Фахівець має постійно аналізувати все, що відбувається, враховувати минулий досвід та навіть планувати перспективи.
Це необхідно, щоб отримати чітке розуміння, чому проєкт має саме такий вигляд в цей проміжок часу, та його потенціал розвитку. І не лише, оскільки за результатами аналізу можна сфокусуватись на покращенні певних процесів чи системи в цілому. І це дасть свої плоди.
Під «покращеннями» маються на увазі глобальні зміни, наприклад:
- перегляд системи QA та її оптимізація за необхідності;
- переоцінка Requirements та їх адаптація;
- аналіз процесу розробки та впровадження нових концепцій.
Але це далеко не все, оскільки ситуації бувають різними, що надає простір для маневрів. Навіть PMI з цього питання надає велику кількість рекомендацій, що є доволі ситуативними та не завжди доцільні для використання. Проте це не стосується інструментарію.
CLD (Casual Loop Diagrams)
Існує такий фреймворк, як Less, що описує принципи та методи систематичного мислення. Його суть полягає в розбитті проблеми на невеликі фрагменти, вибудовуванні зв’язків між ними та пошуці оптимального рішення.
Тут використовуються різні практичні та ментальні прийоми, що допомагають сформувати нові точки погляду на ситуацію. В результаті брейншторму та колективного пошуку рішень команда має локалізувати проблему та запропонувати варіант її усунення, наприклад:
- додати більше розробників певного профілю;
- збільшити кількість QA фахівців;
- розбити задачі на менші фрагменти;
- призначити ліда, який буде допомагати команді;
- прибрати певну умову з принципу розробки тощо.
У підсумку – PM має отримати рішення, яке буде позитивно сприйняте командою та покращить ефективність роботи колективу.
Лідерство
Кожен PM – лідер, оскільки він працює з командою, стейкхолдерами й т.д. одночасно. Такий фахівець має вести за собою колектив, нести відповідальність за рішення (а також приймати їх) та демонструвати приклад – мотивації, зацікавленості в результатах проєкту, професійного розвитку тощо.
Є дві моделі PM: централізована та децентралізована. У першій роль лідера дістається лише менеджеру, який веде за собою всю команду. У другій цю роль належить тимліду, висококваліфікованому фахівцю тощо. Тобто в цьому випадку лідерами є всі, хто має до цього здібності.
І це топова практика, без перебільшення. Хоча роль центрального лідера відіграє все ж PM. Проте саме розподілена модель допомагає ефективніше організувати робочі процеси та покращити загальну продуктивність команди в проєкті.
Розуміння проєкту та обов’язків
Відносно часто PM може виходити за рамки своїх повноважень та виконувати нетипову для посади роботу. Це стається насамперед через те, що фахівець не до кінця розуміє цілі проєкту, його компоненти, цінності чи навіть команду.
Щоб адаптуватись до проєкту, PM має переглянути його контекст та визначити пріоритети. Тобто зрозуміти клієнта, продукт, цінність, концепцію, а також оптимізувати згідно з цим алгоритми та методології.
Фахівці E5 рекомендують застосовувати такий інструмент, як PMI Radar. Так, він не закриє всі потреби планування проєкту, проте допоможе підібрати методологію розробки, умовно – Waterfall, Kanban, Agile і т.п.
Важливе зауваження: початковий сетинг розробки не є фінальним: між спринтами чи певними етапами PM має переглядати загальну концепцію та модернізувати її. Лише так вдасться побудувати дійсно ефективну, продуктивну та результативну розробку проєкту.
QA інтеграція у всі процеси
Цей аспект слід сприймати ширше, аніж типові операції з тестування чи його автоматизації, підтримки тощо. Це глобальне питання, яке стосується всього проєкту. Наприклад, організації процесів чи сценаріїв, налагодження алгоритмів взаємодії між всіма учасниками проєкту і т.д.
Загалом питання якості проєкту базується на двох стовпах:
- Процесах. Їх налагодженні, оптимізації, модернізації, адаптації, структуруванні, використанні певних методологій тощо.
- Метриках. Впровадженні контрольних перевірок продуктивності та ефективності, їх аналізі, оптимізації, покращенні в короткостроковій перспективі.
Завдяки останньому PM постійно моніторить стан розробки, її «здоров’я» та приймає виважені рішення щодо вдосконалення певних аспектів проєкту.
Аналіз складності
Цей процес має проводити PM на постійній основі, щоб адаптувати команду та успішно реалізувати проєкт у встановлені строки. Для цього використовуються абсолютно різні методики.
Як характеризує їх PMI, це може бути розділення проєкту на невеликі фрагменти, асиміляція продукту, балансування, рефреймінг. Проте найпростішим рішенням вважається прототипування продукту. Наприклад, через Figma.
Цей прототип PM узгоджує з клієнтом (замовником), а вже потім вносить зміни до проєкту, якщо це не суперечить домовленостям.
Робота з ризиками
PM працюють з ризиками. Це аксіома, що стала стандартом індустрії (навіть за версією PMI). Ці ризики можуть стосуватися як менеджменту команди, так і безпосередньо проєкту – змін концепції, нових рішень чи навіть хвилювань на цільовому ринку.
Хоч безпосередньо в обов’язки PM це не включено, а роботою займається RM, проте важливо створювати між цими ролями колаборацію, щоб уникати критичних проблем для проєкту.
Рекомендується обробляти ризики для великих циклів, наприклад, на майбутній квартал. При цьому командами обговорюються ці ризики та стратегії для їх нівелювання.
Адаптивність та стійкість
PM має стійко реагувати на будь-які виклики та адаптувати себе й команду до будь-яких змін. Для цього використовується PDCA цикл, який на різних рівнях встановлює стратегії реакцій та алгоритмів. Наприклад:
- Кожен цикл має закінчуватись ретроспективою.
- Кожна каденція має закінчуватись ретроспективою.
- Кожен пресейл має закінчуватись ретроспективою.
- Кожен проєкт (особливо неуспішний) має закінчуватись ретроспективою.
Це дозволить проаналізувати діяльність команди та менеджменту, виявити слабкі місця, локалізувати їх та працювати далі над усуненням проблем.
Менеджмент змін
Це обов’язковий компонент типового PM процесу. Для керування змінами застосовуються різноманітні інструменти, наприклад, модель Коттера. Це дозволяє створити зміст змін та обґрунтувати їх. Відповідно, PM може знайти підтримку для реалізації концепцій, створити візію вектора розвитку проєкту тощо.
Окрім зазначеного, мають бути мітинги зі стейкхолдерами, командами, на яких долаються бар’єри для втілення змін.
Також важливо продемонструвати короткострокові переваги, щоб вмотивувати команду втілити ті чи інші ідеї в життя. Ба більше, потрібно підтримувати проєкт на постійній основі, тобто періодично звітувати про результати, демонструвати перемоги.
Для роботи зі стейкхолдерами можна навіть використати метод гейміфікації, взявши умовну модель Юргена Аппело «Менеджмент 3.0». Тут є маса різних шаблонів, а також цікавий концепт «керування змінами».
Резюмуємо
Проєктний менеджер – відповідальна роль, що поєднує в собі лідера, BA, RM, PM і не тільки. На плечі фахівця лягають понад 12 обов’язків, кожен з яких є якщо не критичним для проєкту, то важливим. Ефективний менеджмент – це комплекс процесів, які мають ледь не вирішальне значення для життєздатності майбутнього проєкту.
Якщо ви хочете якомога краще опанувати роль PM в короткій перспективі, втілити свої амбіції й побудувати успішну кар’єру – запрошуємо вас на курс Project Management: Deep Dive Online.