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 может конвертировать в кейс, допродажу или валидацию методологии.

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

Run / Change / Disrupt

Run (поддержание потока)

То, что PM делает каждый день и каждый спринт, чтобы проект шёл:

• Проведение ритуалов скрам-команды (планирование, дейли, ревью, ретроспектива)
• Ведение базы Sprints и Scrum Tasks (контроль полноты Fact Time, Cost Price, Plan Quality)
• Эскалация рисков на CVD
• Регулярная синхронизация с клиентом по приоритетам бэклога
• Коммуникация с FDE и AIA по содержанию задач

Это «база» — без неё роль не выполняется вообще. Здесь PM не должен быть оригинальным, он должен быть дисциплинированным.

Change (улучшение того, как роль работает)

То, что PM делает на горизонте проекта/квартала, чтобы делать роль лучше:

• Разбор по итогам каждого закрытого проекта → выводы → корректировка шаблонов оценки задач, шаблона запуска проекта, чек-листа эскалации
• Передача материала разбора COO для апдейта процессов и методологии компании
• Работа с командой над качеством оценок (Plan Quality) и временной точностью (Time Adherence)
• Совместный с CVD разбор причин отклонений Project Margin и On-Time Delivery в квартальном срезе

Disrupt (переизобретение роли)

То, что меняет саму конфигурацию роли в системе:

• Конфигурации без PM на малых проектах (FDE сам, PM-функция через AI-ассистента или через CVD напрямую)
• AI-усиление функций PM: автоматическое отслеживание рисков из транскриптов встреч, автогенерация шаблонов разбора, AI-оценка качества ритуалов
• Переход от мышления одним проектом к мышлению потоком проектов своей скрам-команды как продуктом

Disrupt — не для каждого PM и не для каждого квартала. Это горизонт, который держит CVD и PO Digital Shift, а PM в него входит избирательно.

Метрики

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

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

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

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

🟢 Full Zone of Genius (зона полной автономии)

Решения, которые PM принимает сам, без согласования с кем-либо. Это область, где PM действует по собственному суждению, и компания уверена, что суждение PM здесь — правильное.

• Структура и тайм-бокс ритуалов своей скрам-команды. Когда дейли, в каком формате, как проводить ретроспективу, как структурировать планирование. PM не согласовывает это с CVD; CVD проверяет результат через Ritual Quality Score, а не процесс.
• Приоритизация бэклога внутри согласованного скоупа проекта. Какую задачу взять первой, какую отложить, как переставить порядок — решает PM в диалоге с клиентом, без эскалации на CVD.
• Делегирование исполнения внутри команды. Кому из FDE/AIA отдать задачу, какую часть работы декомпозировать на исполнителя, как распределить нагрузку в спринте — это PM решает сам.
• Выбор момента эскалации риска на CVD. PM сам определяет, когда сигнал стал риском, требующим внимания CVD. Внешнего триггера для эскалации нет — это его суждение.
• Содержание разбора по итогам проекта. Какие выводы зафиксировать, что считать корневой причиной, какие шаблоны и чек-листы поправить — PM формирует разбор сам. CVD и COO принимают результат, но не диктуют содержание.
• Тактическое управление коммуникацией с клиентом. Тон, частота синхронизаций, формат отчётов о ходе проекта, как именно сформулировать сложную новость — это PM решает в моменте.

Принцип: если решение касается как идёт проект, а не что обещано клиенту — это зелёная песочница PM. Зрелость PM измеряется в том числе тем, насколько широка его зелёная зона: чем зрелее PM, тем больше решений он принимает сам, не апеллируя к CVD.

🟡 Decisions Requiring Collaboration (коллегиальные решения)

Решения, которые PM принимает в коллаборации с другими ролями. Здесь критично понимать с кем и как принимается решение — иначе коллаборация превращается в безответственность «коллективного решения».

• Изменение скоупа проекта → с CVD (несёт P&L портфеля) и клиентом (определяет приоритеты). Как: PM формулирует предложение и аргументацию, CVD согласовывает с клиентом, решение фиксируется письменно.
• Изменение состава команды (замена FDE/AIA на проекте) → с CVD. Как: PM выявляет ресурсный пробел и предлагает альтернативу, кадровое решение принимает CVD как руководитель дивизиона.
• Эскалация дедлайна вверх (объявление клиенту нового срока) → с CVD. Как: PM не выходит к клиенту с новым сроком до согласования с CVD; CVD может скорректировать формулировку или взять коммуникацию на себя.
• Архитектурные решения на проекте → с FDE и AIA. Как: технический выбор за исполнителями, PM не утверждает «как делать», но удерживает рамку «что в срок и в бюджет».
• Изменения в шаблонах процессов или методологии, вытекающие из разбора по итогам проекта → с COO (процессы и регламенты) и PO Digital Shift (методологический стек). Как: PM поставляет материал и формулирует предложение; утверждение изменений за COO и PO Digital Shift в их зонах.

🔴 Decisions That Should Never Be Made (зона запрета)

Решения, которые PM не принимает ни в одиночку, ни в коллаборации. Это либо чужая зона полномочий, либо зона, где у PM нет необходимой компетенции, либо зона, где у роли в принципе нет авторитета.

• Ценообразование и коммерческие условия с клиентом (T&M против фикса, размер аванса, штрафы, скидки). Это зона CVD. PM может зафиксировать факты, влияющие на коммерческое решение (отклонение фактической трудоёмкости от плана, риск дополнительных итераций), но не ведёт коммерческий торг.
• Стратегические отношения с ЛПР клиента. Это зона CVD. PM коммуницирует с клиентом на оперативном уровне (ход проекта, приоритеты, риски), но не выстраивает стратегию аккаунта и не ведёт диалог о расширении сотрудничества.
• Найм, увольнение, изменение зарплат в команде. Это зона CVD (как руководителя дивизиона) и HR Manager. PM может дать обратную связь о работе члена команды, но кадровые решения не принимает.
• Утверждение изменений в методологическом стеке компании. Это зона PO Digital Shift. PM поставляет материал из разборов, но не решает, что войдёт в методологию Digital Shift и в какой форме.
• Утверждение изменений в общих процессах и регламентах компании. Это зона COO. PM может предложить изменение шаблона запуска проекта или формы разбора, но утверждение и внедрение в общую практику — не его.
• Решения по продажам и привлечению новых клиентов. Это зона CSO. PM не участвует в воронке продаж и не делает коммерческих предложений.
• Технический архитектурный выбор внутри задач. Это зона FDE и AIA. PM может оспорить срок или стоимость предложенного решения, но не выбирает технологический стек или паттерн архитектуры.

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

Цикл 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. Внешний цикл задаёт рамки для внутреннего: первоначальный дедлайн и плановая маржа определяют допуски, в которых работают спринты.