Что должен уметь PM и как развиваться на уровнях junior, middle, senior

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

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

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

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

Сфера менеджмента в ИТ охватывает довольно много смежных областей, поэтому необходимо учитывать, что в разных компаниях набор обязанностей может (а, вернее, будет всегда) отличаться. В этой статье я пишу о них с точки зрения project management (концентрация на проекте), а также delivery / operations management (мы управляем каким-то количеством проектов, распределенными командами, то есть концентрация на процессах).

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

1. Основы архитектуры. Управление релизами.
2. Планирование.
3. Коммуникация.
4. People Management.
5. Владение инструментами.
6. Управление требованиями и документация.
7. Управление бюджетом.

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

Давайте рассмотрим эту модель в привычной структуре, поскольку для начала нужно понять, как работают компоненты системы, и только потом двигаться на следующий уровень (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 through Build, 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, то есть PО знает, что требуемый функционал он увидит на демо в конце второй недели июня. Это также позволяет более удобно планировать задачи для следующих итераций.

Как мы управляем версионностью?
Поскольку релиз итерации — это не всегда релиз в лайв, для релизов клиенту (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.
• Структура и предсказуемость процессов. Процессы должны быть предсказуемыми для команды и заказчика. Да, именно так.
• Процессы должны быть гибкими. Если процесс рассыпается при малейшем отхождении от плана, это не процесс.
• Вы всегда работаете с людьми. Без команды вы не сможете сделать ничего, а без клиента вам будет нечем платить зарплату. Работайте по обе стороны баррикад :)