junior project manager middle project manager pm project manager senior project manager менеджер проектов проектный менеджер развитие менеджера проектов junior project manager

Развитие менеджера проектов: от падавана до мастера-джедая

Mykola Sarry

• 7 min read

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

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

В статье вы найдете книги, ресурсы для чтения и практические кейсы.

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

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

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

Не стоит рассматривать эти компоненты как независимые, поскольку они тесно связаны между собой.

Рассмотрим эту модель в немного непривычной структуре, разберемся как работают компоненты системы, и шаг за шагом продем путь менеджера проектов: падаван (junior), рыцарь-джедажй (middle) и мастер-джедай (senior).

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

Junior

Необходимо понимание следующих основ:

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

Middle

  • Управление версиями.
    • Здесь необходимо уточнить, что нам необходимо понимание, как работает процесс Git, что такое коммиты, как происходит релиз технически, но менеджер не будет заниматься реализацией проекта (проверять pull requests, осуществлять релиз технически) — это роль команды. От менеджера в данном случае требуется координация процесса, но не его реализация.
  • Gitflow:
  • Понимание, как создается сборка продукта (билд), доставка (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).

Кейс

Своевременные релизы — здоровье проекта. В целом существует мнение, что чем чаще происходят релизы — тем лучше. Соглашусь с этим лишь отчасти: релизить нужно часто, но насколько часто релизить в лайв — это вопрос, который очень зависит от бизнеса компании.

В целом итеративная разработка иногда оказывается единственно правильным решением успешно «доставить» проект клиенту, а также может существенно уменьшить уровень стресса в вашей команде.

Я использую гибрид Scrum, Kanban и XP с большим уклоном в сторону Scrumban для управления всеми проектами с котороми приходится работать.

Теперь поговорим об управлении итерациями и планировании проекта.

Планирование

Junior

  • Что такое Waterfall.
  • Что такое Agile (в первую очередь мы хотим понимать, что представляет собой Scrum / Kanban).
  • Что такое Lean.
  • Типы контрактов. Отличия Fixed Price от Time & Material.
  • Управление бюджетом проекта.

Middle

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

Senior

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

Что прочитать:

Кейс

В общей модели можно одновременно работать на трех уровнях:

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

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

А. Product Owner знал, когда он получит определенный функционал на staging environment (то есть среда, идентичная по конфигурации лайв серверу) без необходимости идти в календарь релизов.

Б. Через полгода мы можем легко сказать, в каком релизе мы закончили такую-то фичу.

Например, сейчас мы заканчиваем Sprint-3-18.6.2, то есть PО знает, что требуемый функционал он увидит на демо в конце второй недели июня. Это также позволяет более удобно планировать задачи для следующих итераций.

Как управлять версионностью?
Поскольку релиз итерации — это не всегда релиз в лайв, для релизов клиенту (staging) / в лайв, мы используем следующее управление версиями: в Git и в релиз-тикете.

Как мы это делаем если, например, необходим хотфикс до окончания итерации?
Создается тикет с кастомным issueType = Release, где указывается (Git) версия, и далее тикет планируется как часть итерации. Рекомендую внимательно прочитать, что такое управление версиями, поскольку зависимостей очень много в любом процессе, и правильная версионность позволяет грамотно ими управлять.

Как мы планируем ресурсы, которые могут быть разделены между несколькими небольшими проектами? 
Мы используем термин Capacity каждого FTE, то есть каждый член команды имеет определенное количество часов в спринте, которые мы можем использовать. В Capacity автоматически включены риски, и также часть времени мы резервируем на случай непредвиденных рисков. То есть при правильной конфигурации менеджер может управлять ресурсами и строить планирование быстро и эффективно. Но ему нужно помнить о том, что релиз должен быть выполнен (а их может быть несколько, если мы говорим об управлении портфолио проектов) и скоуп не может быть перегружен.

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/Youtrack (user level), Confluence, Google Docs, Email / Slack.

Middle

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

Senior

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

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

Документация очень важна, как и то, как она структурирована. Мы используем иерархию, которая идентична для всех проектов (пример ниже), поэтому важно создать структуру, которая может быть скопирована из проекта в проект. Это также поможет легко найти нужный файл новому члену команды, или стейкхолдеру проекта. Мы начали с того, что создали темплейты для ведения документации.

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