Що повинен вміти PM і як розвиватися на рівнях junior, middle, senior

Мене звати Дмитро Растатурин, я працюю в компанії Daxx NL і відповідаю за операційний менеджмент в Pindrop NL (компанія-клієнт). Наші end-customers — це Європа, основний ринок — Нідерланди, а також Франція, Бенілюкс і UK.

Ця стаття в першу чергу написана для початківців фахівців/менеджерів середнього рівня. Хоча я припускаю, що і більш досвідчені колеги зможуть знайти щось цікаве та корисне для себе. Стаття допоможе вам зрозуміти, які аспекти спеціальності необхідно вивчати, з чого починати і що робити для подальшого зростання в управлінні проектами (і/або суміжній позиції в ІТ-сфері).

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

Компоненти ролі PM

Сфера менеджменту в ІТ охоплює досить багато суміжних областей, тому необхідно враховувати, що в різних компаніях набір обов'язків може (а, вірніше, буде завжди) відрізнятися. У цій статті я пишу про них з точки зору project management (концентрація на проекті), а також delivery/operations management ми управляємо якоюсь кількістю проектів, розподіленими командами, тобто концентрація на процесах).

Можна виділити такі головні компоненти ролі PM-а:

Основи архітектури. Управління релізами.
Планування.
Комунікація.
People Management.
Володіння інструментами.
Управління вимогами та документація.
Управління бюджетом.

Не варто розглядати ці компоненти як незалежні, оскільки вони тісно пов'язані між собою. Я також буду додавати книги/ресурси для читання (ті, які мають максимально практичну цінність) і практичні кейси.

Давайте розглянемо цю модель у звичній структурі, оскільки для початку потрібно зрозуміти, як працюють компоненти системи, і тільки потім рухатися на наступний рівень (step by step): Junior, Middle, Senior.

Навмисно даю інформацію саме в такому вигляді, оскільки знаю з власного досвіду, наскільки важко іноді зрозуміти, куди рухатися, що читати і як керувати залежностями в процесі навчання :)

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

Основи архітектури. Управління релізами

Junior

Необхідно розуміння наступних основ:

Клієнт/серверна частина (Backend, Frontend).
API .
HTTP запити .
ООП .
Release management — процес, відповідальний за впровадження та контроль якості (частини) (коду) продукту, розгорнутого в ІТ-середовищі. У тому числі в рамках управління релізами розробляються політики впровадження нових версій програмного і апаратного забезпечення. Реліз — це здоров'я проекту. Іноді потрібно робити релізи частіше, іноді ні. Далі я розповім про те, як керувати крос-проектними релізами для проектів середнього рівня.

Middle

Керування версіями .
Gitflow :
- Також одна з кращих Git-моделей .
Розуміння, як створюється збірка продукту (білд), доставка (deployment) в потрібне середовище (environment(s): development, staging, production).
Що таке Continuous Integration (CI), тобто безперервна інтеграція коду (дуже часті оновлення системи (коду вашого проекту), але невеликими частинами, і подальша автоматизація цього процесу).

Senior

Імплементація практик Continuous Delivery .
Business Intelligence (BI): імплементація та автоматична звітність.
Моніторинг процесів в реальному часі:
- конфігурація автоматичних нотифікацій аналітики за обраним метрик;
- для початку підійде eazyBI .

Що прочитати: «Continuous Delivery: Reliable Software Releases Build through, Test, and Deployment Automation» by Jez Humble, David Farley (мінімум на рівні Middle).

Кейс

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

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

У нашій компанії ми застосовуємо крос-проектний Скрам. Чому я кажу «крос-проектний»? Ми використовуємо Atlassian Portfolio для управління великою кількістю проектів, і концепція CPR (cross-project releases) прекрасно інтегрується в наш процес.

Далі розповім трохи більше про управління ітераціями в плануванні проекту.

Планування

Junior

Що таке Waterfall .
Що таке Agile (в першу чергу ми хочемо розуміти, що являє собою Scrum/Kanban).
Що таке Lean .
Типи контрактів . Відмінності Fixed Price від Time & Material.
Управління бюджетом проекту.

Middle

Управління процесом планування.
Вміння взяти на себе роль Скрам-майстра (а часто поєднання цієї та ПМ ролей).
Робота з естімейтами (див. книгу Mike Cohn ), одночасна робота на декількох рівнях планування (high-level, story level, technical level).
Побудова Gantt-графіків для клієнта.
Грамотне планування релізів і планування ітерацій.
Концепції PMBOK , PRINCE2 , їх відмінності від методологій Agile.

Senior

Впровадження різних моделей планування і розуміння, яка підходить даного проекту.
Управління крос-проектними релізами.
Реліз менеджменту в портфоліо проектів.
Продаж спринтів клієнту.

Що прочитати:

«Scrum and XP from the Trenches» by Henrik Kniberg. Обов'язково читати новачкам, є у відкритому доступі і російською . Написана простою мовою і дає розуміння, як працюють гнучкі методології.
«Agile Estimating and Planning» by Mike Cohn.
«The Lean Startup» by Eric Ries.

Кейс

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

High (Epic) level : rough planning (range pessimistic/optimistic + розділення ризиків з клієнтом, де це можливо). Для оцінки ймовірності використовується класична модель PERT . На цьому рівні ми продаємо проект.
Business (story) level : на рівні user story, планування ітерацій з описом/acceptance criteria, але без технічної декомпозиції. Планування фіч по моделі Kano . Це планування ітерацій після того, як проект підтверджений і приоритизирован скоуп проекту.
Technical (sub-task level): технічні завдання для розробника. Планування в рамках однієї ітерації. Завдання на цьому рівні максимально деталізовані.

Ми використовуємо класичні двотижневі спринти і в їх назві дотримуємося формату «Sprint-X-year-month-week», для того, щоб:

А. Product Owner знав, коли він отримає певний функціонал на staging environment (тобто середовище, ідентична по конфігурації лайв сервера без необхідності йти в календар релізів.

Б. Через півроку ми легко можемо сказати, в якому релізі ми закінчили таку фічу.

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

Як ми управляємо версионностью?
Оскільки реліз ітерації — це не завжди реліз в лайв, для релізів клієнту (staging)/в лайв, ми використовуємо таке керування версіями : Git і в реліз-тикеті.

Як ми це робимо в Jira, і якщо, наприклад, необхідний хотфикс до закінчення ітерації?
Створюється тікет з кастомным issueType = `Release`, де вказується (Git) версія, і далі тікет планується як частина ітерації. Рекомендую уважно прочитати, що таке управління версіями, оскільки залежностей дуже багато в будь-якому процесі, і правильна версійність дозволяє грамотно ними управляти.

Як ми плануємо ресурси, які можуть бути розділені між декількома невеликими проектами?
Ми використовуємо термін Capacity кожного FTE , тобто кожен член команди (команди також розділені в Atlassian Portfolio) має певну кількість годин у спринті, які ми можемо використовувати. У Capacity автоматично включені ризики, і також частину часу ми резервуємо на випадок непередбачених ризиків. Тобто при правильній конфігурації менеджер може управляти ресурсами і будувати планування швидко і ефективно (звичайно, повинна працювати двостороння синхронізація з Jira). Але йому потрібно пам'ятати про те, що реліз повинен бути виконаний (а їх може бути кілька, якщо ми говоримо про управління портфоліо проектів) і скоуп не може бути перевантажений.

Capacity враховується при плануванні завантаження релізу, який виділяється червоним кольором, якщо менеджер хоче використовувати більше ресурсів, ніж треба :)

Комунікація

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

Junior

Англійська: upper-intermediate (min B2).
Грамотна комунікація ризиків.
Комунікація в команді, позиція командного лідера.

Middle

Англійська: fluent (C1, C2).
Управління проектом з моменту підписання SOW (до релізу, можливо, виключаючи управління бюджетом).
Управління ризиками проекту і грамотна комунікація ризиків клієнта.

Senior

Англійська: fluent (C1, C2).
Робота зі стейкхолдерами (зацікавленими особами проекту) З-рівня.
Участь у presale.
Delivery management.

Що прочитати: «Домовитися можна про все» Гевіна Кеннеді

Окремо хотів би сказати, що дуже важливо правильно вести переговори з клієнтом, і часто потрібно вміти говорити «ні» з грамотною аргументацією. Інакше ви можете виявитися в ситуації, коли ви будете працювати в умовах божевільних дедлайнів, оскільки раніше не врахували ризики, допустили зміна скоупа та/або вибрали занадто м'яку позицію, і клієнт цим скористався. У підсумку оплатіть овертайми зі свого бюджету, і проект виявиться не тільки збитковим, але і клієнт буде незадоволений.

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

Кейс

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

Що ми зробили? Ми описали скоуп в рамках нових вимог як Time & Material , декомпозировали на кілька фаз (Epics), починаючи з MVP (minimum viable product), приоритизировали stories разом з продакт-оунером, провели переговори з клієнтом, використовуючи початкові вимоги, побудували планування і провели клієнта через весь процес.

People Management

Junior

Комунікація прогресу замовнику і вимог команді.

Middle

Вміння працювати з конфліктами в команді.
Управління ризиками в команді.
Проведення 1?1 мітингів .

Senior

Імплементація KPI, оцінка performance (інтеграція з BI).
Управління крос-проектними/shared/remote командами.
Проведення інтерв'ю.

Що прочитати: «Чорна книга менеджера» Слави Панкратова (коротка книга, не про методологіях, а про відносини між менеджером і бізнесом).

Інструменти

Junior

Jira (user level), Confluence, Google Docs, Email/Slack.

Middle

Jira advanced level, Confluence, інструменти прототипування (Balsamiq Mockups, Proto.io, Axure, etc, якщо необхідно), MS Project or similar.

Senior

Jira deep configuration, Atlassian Portfolio, BI/process analytics systems (ServiceClarity & others).

Що прочитати: «JIRA Essentials» by Patrick Li, Third Edition.

Управління вимогами та документація

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

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

Документуються не тільки вимоги, але і мітинги за час ітерації:

А також процеси і політики всередині компанії.

Управління бюджетом

Junior

Управління тільки скоупом проекту (управління бюджетом — мінімум, рівень Middle).

Middle

Оцінка проекту і комунікація даних клієнта.
Аналіз трекінгу часу.
Комунікація бюджету/управління бюджетом — залежно від політики компанії.
Репортинг.

Senior

Адміністрування годин.
Моніторинг бюджету BI.
Автоматичні нотифікації про перевищення бюджету (за итерациям/релізів).
Бюджет команди проекту.
Бюджетування на певний період часу наперед.
Гнучке інвойсування T&M годин (конфігурація експорту в залежності від вашого облікового запису).

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

Висновки

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

Як я говорив на початку статті, я навмисне даю інформацію в такому форматі, щоб початківець не опинився посеред океану інформації, не знаючи, за що братися. Градацію «junior — middle — senior» слід сприймати умовно. Аналогічно можна використовувати «A — B — C», тому не варто припускати, що менеджер проектів середнього рівня буде мати саме таким сетом навичок.

В кінці виділимо декілька важливих тез, які визначають кваліфікацію та досвід менеджера:

Ми керуємо процесом, а не процес керує нами. Якщо менеджер is not in charge, ймовірність того, що проект закінчиться успішно, — практично нульова.
Продукт потрібно знати на рівні архітектури, тобто ви повинні розуміти, що ви віддаєте клієнту, як взаємодіють модулі, логіку продукту etc.
Не створюйте зайву роботу, намагайтеся спростити все, що можна спростити:
- Щодо планування завдань і управління бэклогом — ще раз, вивчіть Kano Model of Satisfaction, а також як приоритезировать завдання і враховувати ризики і залежності. До речі, Mike Cohn пише про це дуже добре.
- Завжди враховуйте вплив задачі на логіку продукту.
Не приймайте рішення за розробників. Ніколи не продавайте проект без оцінки команди, якщо завдання виконувати не будете ви самі.
Стаєте на бік замовника при комунікації з ним, і на бік команди при комунікації з командою. Вивчайте бізнес замовника. Вивчайте предметну область продукту.
Плануйте і керуйте плануванням на декількох рівнях.
Завжди вважайте і враховуйте ризики.
Час — гроші. Always be in control of your budget.
Структура і передбачуваність процесів. Процеси повинні бути передбачуваними для команди і замовника. Так, саме так.
Процеси повинні бути гнучкими. Якщо процес розсипається при найменшому відходженні від плану, це не процес.
Ви завжди працюєте з людьми. Без команди ви не зможете зробити нічого, а без клієнта вам буде нічим платити зарплату. Працюйте по обидві сторони барикад :)

Опубліковано: 27/06/18 @ 10:47
Розділ Різне

SEO Блог