Project Manager (PM) / Руководитель проекта

Зачем эта роль

PM существует, потому что у проекта с клиентом должен быть один человек, который держит обещание целиком. Не «сдал свою часть», а отвечает за ход проекта от запуска до приёмки и разбора. Без PM в команде с FDE и AIA каждый везёт свой кусок производства, но нет роли, которая отвечает за экономику проекта как целого: соблюдение сроков, бюджета, ритуалы, обратная связь с клиентом — всё это превращается в «как-нибудь договоримся».

В системе NOTA это означает простое правило: «исполнители подвели» не существует как объяснение от PM. Это диагноз самому PM.

PM — несущая роль для управляемости портфеля проектов. Чем зрелее PM, тем меньше CVD и CEO нужно вмешиваться в ход проектов; зрелый PM освобождает CVD для стратегической работы с клиентом и даёт компании возможность масштабировать число одновременных проектов без линейного роста управленческой нагрузки на верхний слой.

На малых проектах допустима конфигурация без PM (FDE закрывает сам). PM появляется там, где сложность проекта превышает то, что один FDE удерживает в голове в одиночку.

Продукт должности

Управляемый ход проекта с клиентом — выполнение договорённостей в срок и в бюджет, прозрачный прогресс по согласованным метрикам, отсутствие сюрпризов для клиента и для CVD на стороне процесса. Риски проекта выявляются и эскалируются раньше, чем они становятся блокером, бэклог приоритизирован, ритуалы (планирование, ретроспектива, DoD/DoR) исполняются как живой механизм улучшения, а не как формальность. Каждый проект превращается в разбор по итогам — материал для обучения команды и развития методологии компании.

Главный потребитель и его требования

Главный потребитель: CVD (Customer Value Director, ведущий проект на стороне портфеля своего клиента).

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

Сроки и бюджет соблюдаются или сдвиг известен и согласован за один спринт до факта (не по факту срыва). На уровне портфеля это входит в Portfolio P&L Adherence у CVD — метрика Project Margin от PM прямо суммируется в его метрику.
Прогресс прозрачен через одни и те же артефакты (Sprints, Scrum Tasks, Projects NOTA), которые CVD может открыть в любой момент и понять статус без созвона с PM.
Сюрпризов на стороне процесса нет: эскалация рисков идёт PM → CVD до того, как они становятся видны клиенту. Если CVD узнаёт о проблеме на проекте от ЛПР клиента раньше, чем от PM — это провал PM.
Разборы и ритуалы поставляют материал, который CVD может конвертировать в кейс, допродажу или валидацию методологии.

Вторичный потребитель: клиент — получает предсказуемость результата и ход проекта, в котором не нужно «продавливать» ответы.

Метрики

PM измеряется композитом из 4 метрик, покрывающих все три ноги EEQ (Effectiveness / Efficiency / Quality) и ориентированных на главный вопрос CVD: проект экономически здоров, доставляется в срок, спринты предсказуемы, ритуалы PMO исполняются качественно.

Логика композита: одна метрика — экономическое здоровье проекта (соответствие плановой марже как итог управления ресурсами, рисками, scope'ом). Вторая — выполнение обязательств по срокам перед клиентом (доля вех, выпущенных в срок). Третья — внутренняя предсказуемость (доля задач спринта, завершённых в его рамках, отражающая зрелость планирования и управления командой). Четвёртая — качество исполнения PMO-ритуалов (стендапы, ретроспективы, разборы по итогам — соответствие стандартам COO).

Метрики дополняют друг друга по логике «деньги / срок / предсказуемость / процесс». Если Margin высокая, но Sprint Predictability низкая — выруливаем за счёт переработок и спринт-героики, не системно. Если On-Time Delivery высокий, но Margin низкая — успеваем, но платим избыточным ресурсом. Если Ritual Quality низкая, но остальное в зелёном — PM работает за счёт интуиции и личного контакта с командой, не за счёт системы; при росте проекта или замене людей всё посыплется.

Полный список метрик с определениями и порогами — в свойстве Metrics ниже.

Цикл PDCA

PM управляет двумя вложенными циклами с разной частотой. Внешний цикл — управление проектом целиком; внутренний — управление каждым отдельным спринтом внутри проекта.

Цикл управления спринтом (короткий, недельный)

Plan — спринт-планирование: согласование объёма работ на спринт, простановка оценок задач, контроль качества оценок (Plan Quality), фиксация Definition of Done.
Do — исполнение спринта: проведение дейли, удержание фокуса команды, разбор блокеров в течение 24 часов, синхронизация с клиентом по приоритетам.
Check — фактические показатели спринта на момент закрытия: Sprint Completion %, Time Adherence, Ritual Quality Score; ретроспектива.
Act — корректировка следующего спринта: пересмотр оценок типовых задач, перераспределение нагрузки, подъём системных проблем на ретро, изменение порядка ритуалов при необходимости.

Цикл управления проектом (длинный, по периоду проекта)

Plan — запуск проекта: фиксация скоупа, первоначального дедлайна, плановой маржи, состава команды, реестра рисков, плана коммуникации с клиентом.
Do — ведение проекта: проведение всех спринтов, эскалации на CVD, регулярные синхронизации с клиентом, удержание проекта в согласованных рамках сроков и бюджета.
Check — закрытие проекта: фактические Project Margin и On-Time Delivery, разбор по итогам с командой и клиентом, фиксация корневых причин отклонений.
Act — внесение изменений в шаблоны запуска и оценки задач, передача материала разбора COO и PO Digital Shift, корректировка списка типовых рисков для следующих проектов.

Внутренний цикл (спринт) питает внешний (проект): данные Sprint Predictability накапливаются и формируют опережающий сигнал по Project Margin. Внешний цикл задаёт рамки для внутреннего: первоначальный дедлайн и плановая маржа определяют допуски, в которых работают спринты.