Что делает менеджер проектов

Работая с аутсорс IT проектами вы часто сталкиваетесь с тем, что у вас в команде есть выделенный менеджер проектов. В зависимости от уровня компетентности исполнителя на роли менеджера проектов — у вас может сложиться разное мнение о нужности и полезности такой отдельной позиции. Более того, в продуктовых компаниях часто нет проектного менеджера, есть только инженерный тех лид и продуктовый менеджер!

Так зачем и когда нужен проектный менеджер в команде и какую пользу он приносит проекту?

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

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

Вы решаете не брать прораба, потому что прораб не нужен и стоит дополнительных денег. 

Представим, что происходит дальше.

Вы захотите узнать, сколько будет стоить построить ваш уникальный дом и как долго его будут строить? Возможно захотите узнать, успеют ли эти работники накрыть крышу до зимы? У кого будете спрашивать эти и другие вопросы?

Прошло два месяца, вы приезжаете на стройку и видите что пока есть только котлован и всё. У кого будете спрашивать какого чёрта и что происходит?
Потом вам выставляют счет за этот котлован как будто вы пол дома уже построили, у кого будете просить обьяснить почему?

Теперь представим что мы — каменщик в этой группе строителей, что строит этот дом. Нам принесли какой то листок и чертеж дома, с виду вроде дом как дом, но потом мы читаем и видим что там стены под углом и внутри все может двигаться. Приходит заказчик и спрашивает как мы будем это строить, какими этапами и сколько по времени. А ещё надо котлован выкопать и непонятно, то ли лопатами копать, то ли можно убедить заказчика заплатить за экскаватор. Что делать будем?

Теперь, пока эта история все еще в вашей голове, давайте перейдем к определению кто же такой ПМ по PMBoK:

“Project manager — the person assigned by the performing organization to lead the project team that is responsible for achieving the project objectives. Project managers perform a variety of functions, such as facilitating the project team work to achieve the outcomes and managing the processes to deliver intended outcomes.”

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

Конкретные действия и круг обязанностей ПМ на проекте могут меняться в зависимости от домена, команды, клиента, выбранной методологии. Так же задачи ПМа будут разными на разной стадии проекта и, что очень важно, на разной стадии построения самой команды (согласно теории групповой динамики и модели Такмана).

У каждого проекта по разработке ПО есть свой жизненный цикл (SDLC), он обычно состоит из таких стадий

1. Инициация (Анализ требований)
2. Планирование
3. Проектирование и дизайн
4. Исполнение (разработка)
5. Тестирование
6. Развертывание
7. Поддержка или закрытие

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

За что отвечает менеджер проектов?

Если очень сильно упростить, то наличие проектного менеджера в проекте повышает статистические шансы на то, что проект будет успешным. Чем более компетентен менеджер — тем больше он повышает эти шансы. Соответственно, некомпетентный менеджер может прогноз даже ухудшить. Это вероятности и риски проекта, которые бизнес старается минимизировать. Теперь давайте разберем как именно это работает.

Начнем с того, что определим, где менеджеры вообще нужны, менеджеры IT проектов, в частности.

Проект — это комплекс взаимосвязанных мероприятий, направленный на создание уникального продукта или услуги в условиях временных и ресурсных ограничений. То есть проект имеет так называемое «тройственное ограничение» или «проектный треугольник»: сроки, бюджет и содержание/объем работ.
Именно за соблюдение этих ограничений и несет ответственность менеджер проекта в первую очередь. Учитывая уникальный характер результата, проект проходит с большей или меньшей долей неопределенности, которую обычно описывают в рисках проекта. Иногда говорят что для управления проектом — достаточно управлять его рисками. Для этой цели служат различные методологии управления проектами.

Проектный менеджмент, работает там, где есть высокая неопределенность, динамичная внешняя среда, жесткие ограничения.

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

Структура компаний с точки зрения проектной деятельности:

1. Функциональная: менеджер не распоряжается ресурсами, не ставит им задачи самостоятельно. Бюджет контролируется менеджером, но он им не управляет. Позиция менеджера в таких случаях временная, на время проекта. На эту позицию может быть назначен как кто-то изнутри компании, чаще только на часть своего основного рабочего времени, так и могут привлекаться люди на время проекта извне компании.
2. Матричная: большая самостоятельность в ресурсах и задачах, но необходимость согласовывать большинство решений остается, включая возможность распоряжаться бюджетом. Позиция менеджера в таких случаях может быть как временная, на время проекта, так и постоянная, в зависимости от величины компании и её проектов. В зависимости от этого матричные компании можно подразделить на слабые, сбалансированные и сильные.
3. Проектная: менеджер является самым главным на проекте и может самостоятельно принимать все необходимые решения в рамках своего проекта. Менеджер в такой компании только на полной занятости, является штатной единицей и занимается исключительно проектным управлением.

Основные роли менеджера проектов:

• планировщик (planner) — планирует этапы проекта и активности на этих этапах.
• снабженец (provider) — убеждается, что у команды есть все необходимое для работы: инструменты, доступы, общий чат проекта, проект в джире и тд.
• защитник (protector) — защищает команду от негативного внешнего воздействия: например клиента, пишущего напрямую разработчику, или длинных митингов о будущем проекта или подробностях контракта. 

Дополнительные роли:

• администратор (administrator)
• лидер (leader)
• политик (politician)
• переговорщик (negotiator)
• посредник/связующий (liason)

Основная физиологическая функция менеджера — это планирование: сроков, бюджета, ресурсов, своей и чужой работы. 

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

Чаще всего менеджер проектов задает 3 вопроса: Кто? Что? Когда?

На основании ответов создается план и список необходимых действий, а также препятствий, которые необходимо устранить. Вопросы приходится задавать часто и потом ещё чаще, чтобы докопаться до сути. Именно поэтому создается ощущение, что менеджер проектов только и делает, что говорит и не просто говорит, а что-то постоянно спрашивает и задает так много вопросов. Это во многом правда, коммуникация, анализ информации — это есть большая часть работы ПМа.

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

Если попробовать описать пример алгоритма решения проблемы на проекте со стороны менеджера проектов, то упрощенно получится такая последовательность:

1. Сбор информации, анализ и мониторинг
2. Определение сути проблемы
3. Разработка вариантов действий по устранению
4. Выбор одного из вариантов и утверждение плана действий
5. Контроль выполнения плана, корректирующие действия

Само собой что все пункты — это коммуникация с разными членами команды, которые обладают соответствующими техническими компетенциями и необходимой информацией.

Что делает менеджер проектов в типовом аутсорс проекте

В типовом аутсорс проекте менеджер проектов выполняет многие активности, соответствующие ролям, описанным выше:

• Участвует в продаже проекта на этапе пресейла, помогает обозначить риски и следит за тем чтобы в контракте были учтены все важные пункты, которые касаются деливери
• Формирует процесс, по которому будет разрабатываться проект. (Выбирает методологию), распределяет ответственность и полномочия в команде проекта.
• Запрашивает ресурсы, необходимые для выполнения проекта (включая людские, но не только). В проектной структуре также принимает решения о найме/увольнении
• Обсуждает с командой правила, которым будет следовать команда на проекте и следит за их соблюдением.
• Обсуждает с заказчиком и руководством правила, по которым будет происходить коммуникация о ходе проекта и приемка
• Пишет план проекта, следит за его выполнением и обновляет по мере необходимости. План может быть высокоуровневым при долгосрочном планировании и более подробным на короткую перспективу.
• Пишет другую необходимую проектную документацию (зависит от выбранной методологии)
• Собирает информацию о ходе, статусе проекта и актуальных рисках
• Информирует заказчика и руководство о ходе проекта, ближайших планах, изменениях вероятности наступления рисков и появлении новых рисков.
• Работает с людьми в команде, чтобы обеспечить их максимальную эффективность и вовлеченность. Это включает в себя как встречи один на один для сбора обратной связи и важной информации, так и медиация и решение конфликтов между членами команды.
• Работает с заказчиком для сохранения реального проектного ограничения бюджет-сроки-работа. Это включает контроль за внесением изменений и разрастанием объема работ проекта и управление ожиданиями заказчика.
• Участвует в выстраивании долгосрочных отношений с заказчиком, ищет возможности для допродажи услуг и расширения команды/аккаунта (upsell)
• Собирает необходимую информацию для выставления счета (инвоиса) клиенту согласно расписанию в контракте
• Исходя из своего опыта принимает проактивные действия для того, чтобы избежать появления проблем и снижения вероятности наступления рисков на проекте
• Поддерживает контакты вне команды проекта, чтобы по необходимости привлечь дополнительную экспертизу или ресурсы для проекта
• Защищает команду от внешнего негативного воздействия
• Поддерживает позитивный настрой внутри команды, формулирует ценность проекта
• Постоянно ищет пути улучшения процесса

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

Какими компетенциями должен обладать менеджер проектов

Вот высокоуровневый список областей, в которых должен разбираться ПМ:

• Проектные методологии и фреймворки
  • Agile (Scrum, Kanban, etc)
  • Waterfall, Prince2, RUP
• Жизненный цикл проекта (SDLC)
  • Анализ требований
  • Планирование
  • Разработка
  • Тестирование
  • Запуск (релиз)
  • Поддержка системы после запуска/ Гарантийное обслуживание
• Управление объемом работ (Scope management)
  • Планирование объема работ
  • Техники оценки работ
  • Управление рисками
• Технические навыки (минимум теория и терминология)
  • Репозитории кода
  • Базы данных
  • API
  • Мобильная разработка
  • Облачные сервисы
  • Тестирование
  • Управление окружениями и конфигурациями
  • CI/CD практики
  • Интеграции (3rd party services)
• Контракты
  • Типы контрактов
  • Обязательные разделы контрактов
  • Основные риски различных типов контрактов
• Управление разработкой
  • Старт проекта (Kick-off)
  • Настройка процессов (JIRA workflows)
  • Разграничение ролей и зон ответственности в команде (вместе с командой)
  • Общая структура проекта (инструменты, где и какая проектная информация хранится и кому доступна)
  • Управление расписанием проекта (календарные планы)
  • Отчеты и инвоисы
  • Устранение препятствий и блокеров для команды
  • Выбор и отслеживание проектных метрик и KPI
  • Обмен информацией согласно матрице коммуникаций (каналы, частота, содержание)  
• Коммуникация
  • Навыки устной коммуникации
  • Переговорные навыки
  • Сбор обратной связи и ее отдача
  • Выстраивание хороших взаимоотношений и нетворкинг
  • Управление ожиданиями
  • Наличие эмоционального интеллекта
• Знания бизнес областей (доменов)
  • Специфические риски бизнес области
  • Необходимые сертификации
  • Государственные стандарты и регулирование в бизнес области
• Управление ресурсами проекта
  • Найм/увольнение
  • Собеседование
  • Удержание и мотивация
  • Разрешение конфликтов
  • Менторинг/Коучинг
  • Составление планов развития и поддержка
• Управление финансами
  • Планирование бюджета проекта
  • Отслеживание сгорания бюджета и отклонений от плана
  • Управление прибыльностью проекта
  • Управление утилизацией ресурсов проекта
  • Прогнозирование сгорания бюджета до конца проекта
  • Сбор информации, выставление и отслеживание инвойсов

Уровни управления (authority levels)

В зависимости от компетентности менеджера и зрелости команды, ПМ стремится к наиболее высокому уровню управления из этого списка:

1. Приказы. Менеджер сам принимает решения и озвучивает их команде как финальные.
2. Продажа. Менеджер принимает решения но старается “продать” эти решения команде, чтобы команда согласилась с ними (но не обязательно чтобы все согласились)
3. Консультирование. Менеджер приглашает всю команду к обсуждению до принятия решения, но итоговое решение принимает сам менеджер, пусть и, возможно, с учетом мнения команды.
4. Согласие. Менеджер приглашает всю команду к обсуждению. Решение принимается при достижении общего консенсуса, голоса каждого члена команды равны, включая голос менеджера.
5. Рекомендации. Менеджер высказывает свое мнение и аргументирует его команде, но решение принимает команда, без менеждера.
6. Осведомление. Менеджер дает команде принять решение самостоятельно, не высказывая свое мнение и не давая рекомендаций и просит команду, что было бы хорошо, но необязательно, если команда потом аргументирует принятое решение менеджеру.
7. Делегирование. Менеджер никак не вмешивается и не участвует в процессе принятия решения командой

Итог

Нужны ли менеджеры проектов? В продуктовой компании — не особо, в проектной — нужны.

Бизнесу менеджер проектов нужен чтобы:

• Иметь одного ответственного за проект
• Снизить риски
• Иметь возможность быстро получить актуальную информацию по проекту и анализ перспектив

Заказчику менеджер проектов нужен чтобы:

• Иметь одно контактное лицо
• Не работать с командой самому
• Повысить шансы на успешное выполнение проекта за счет контроля его рисков
• Иметь возможность быстро получить актуальную информацию по проекту и план
• Получить экспертизу по организации эффективной работы над проектом

Команде менеджер проектов нужен чтобы:

• Получить максимально комфортную обстановку на проекте и все необходимое для эффективной работы
• Иметь понятный план и объем работы, приоритеты и процесс внесения изменений
• Иметь возможность обратится с проблемой, вопросом и конфликтом для максимально быстрого разрешения