PRINCE2: семь принципов, семь тем, семь процессов и управление по отклонениям

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

PRINCE2 (PRojects IN Controlled Environments) — главный стандарт проектного менеджмента Великобритании, применяемый также в США, Канаде, Австралии и континентальной Европе, а местами де-факто обязательный для господрядов. Его выбирают за адаптируемость под масштаб, усиленный контроль без микроменеджмента и чёткое распределение обязанностей. Стандарт родился в государственном секторе, но получил огранку благодаря бизнесу: при подготовке около 150 частных компаний и практикующих менеджеров давали обратную связь, которая превращалась в правки.

1. Откуда он взялся

Правами владеет PeopleCert, купившая в 2021 году AXELOS (совместное предприятие правительства Великобритании и Capita). Официальный сайт — prince2.com, сертификация двухуровневая: Foundation (терминология) и Practitioner (применение к сценарию).

Про версии. В PRINCE2 7 семь «тем» называются практиками, а интегрированных элементов стало пять (принципы, люди, практики, процессы, контекст). Ниже — классическая терминология изданий 2009/2017: она распространена шире, а механика между версиями идентична.

2. Три интереса: почему проектом не может управлять один человек

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

Ошибка, которую PRINCE2 закрывает конструктивно: организация обычно назначает одного представителя проекта с правом решать за всех троих, и дальше предсказуемо — заказчик режет нужное пользователю, пользователь заказывает невыполнимое, поставщик оптимизирует удобное себе. PRINCE2 требует, чтобы все три интереса были представлены персонально в управляющем органе — Project Board (Проектном комитете):

• Executive (Заказчик) — бизнес-интерес, владеет Business Case, единолично отвечает за проект, имеет решающий голос. Роль не может быть коллективной.
• Senior User (Старший пользователь) — требования со стороны использования, приёмка и ответственность за реализацию выгод после закрытия проекта.
• Senior Supplier (Старший поставщик) — выполнимость, качество с технической стороны, наличие ресурсов.

Ниже комитета — Project Manager, которому делегируют полномочия и ресурсы. Его вопросы: «получил ли я нужные ресурсы и информацию? доволен ли комитет работой на этой стадии? не выхожу ли я за пределы разрешённого?» Его работа официально начинается не с идеи, а с утверждения PID (Project Initiation Documentation) — «внутреннего контракта» проекта.

Дальше метод раскладывается на «три семёрки» — 7 принципов (раздел 4), 7 тем (раздел 5) и 7 процессов (раздел 6), — которые вместе обслуживают контроль над шестью аспектами исполнения.

3. Шесть аспектов исполнения

«Три семёрки» существуют не сами по себе — они обслуживают контроль над шестью аспектами: время, стоимость, качество, содержание, выгоды, риск. Классический тройственный ограничитель PRINCE2 считает недостаточным и добавляет три измерения, которые ломаются чаще всего.

Классическая иллюстрация стандарта — стройка: завод ради роста выпуска (выгода), в сезон (время) и в смету (деньги), с конкретными материалами и подрядчиками (содержание) нужного качества и с подготовкой к рискам. В ИТ ровно то же: портал самообслуживания снимает 200 часов поддержки в месяц до окончания контракта с колл-центром, в рамках годового бюджета, закрывая конкретный набор операций с долей успешных самостоятельных сценариев выше 85% — при непроверенном допущении о нагрузке на биллинг. Шесть аспектов перечисляют не ради отчёта: по каждому назначается допуск, ради чего и стоит читать раздел 7.

4. Семь принципов

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

1. Постоянное экономическое обоснование. Ответ на вопрос «зачем» пересматривается на каждой стадии, а не один раз на старте. Business Case — живой документ; если обоснование перестало сходиться, проект закрывается досрочно, и это предусмотренный стандартом исход, а не провал. Пример: строим интеграцию с монополистом ради выхода на рынок, через два месяца конкурент открывает API, а монополист объявляет о закрытии. Правильное действие — не «доделать, раз начали», а закрыть; арифметика такого решения — в запуске и закрытии проекта.

2. Учиться на опыте. Опыт ищут в начале (что известно о похожих проектах), записывают по ходу и передают дальше. Инструмент — Lessons Log, заводимый в первые дни, а не в последние. Пример: запись «нагрузочный тест биллинга сделали на седьмом месяце, переписывали три недели» полезна ровно одним способом — нагрузочный тест ставится в план первой стадии. Урок, не превращённый в пункт плана или шаблона, не переживает проект.

3. Определённые роли и ответственность. У каждого решения однозначный владелец. PRINCE2 разделяет роли и людей: один человек может исполнять несколько ролей, но роль не может быть размазана по группе. Пример: «архитектуру утверждает архитектурный комитет» — надёжный способ обеспечить, что не утвердит никто; нужно имя, а комитет оставить консультантом.

4. Управление по стадиям. Проект делится на управляющие стадии; детально планируется текущая, следующая — укрупнённо, и на границе комитет решает «продолжаем / меняем / закрываем». Пример: та же логика, что в траншевом финансировании — весь бюджет не выдаётся под план, написанный при максимальном незнании; границы стадий ставят там, где снимается неопределённость, а не по календарю.

5. Управление по отклонениям. Каждый уровень получает допуски, внутри которых действует сам, без согласований и еженедельных «планёрок»; наверх идут только прогнозируемые выходы за допуск. Пример: менеджеру разрешено отклонение по сроку стадии на ±10 рабочих дней и по бюджету на ±5%; пока он внутри — комитет его не трогает и получает регулярный Highlight Report. Подробности — раздел 7.

6. Фокус на продуктах. Проект определяется через результаты, а не действия: сначала «что должно быть получено и по каким критериям принято», потом «какие работы к этому ведут». Пример: «настроить CI» — действие без критериев приёмки, его можно делать бесконечно. «Пайплайн, собирающий и прогоняющий тесты на каждый push, зелёный на main, прогон под 12 минут» — продукт: понятно, что сдаём и когда закончили.

7. Адаптация под среду проекта. Метод обязан быть подогнан под масштаб, сложность, важность и риск: не адаптировать PRINCE2 — тоже нарушение PRINCE2. Пример: в проекте на три месяца и четырёх человек Checkpoint Report — статус в канале раз в неделю, End Stage Report — получасовая встреча с решением, Risk Register — вкладка в таблице. Команда, заполняющая вместо этого 26 управляющих продуктов, нарушает стандарт по седьмому принципу.

5. Семь тем: непрерывные аспекты управления

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

Три вещи, теряющиеся при беглом чтении. Business Case — не про деньги на старте, а про пересмотр: он обновляется на границе каждой стадии и проверяется по факту после закрытия; кто пишет обоснование один раз ради визы, использует шаблон, но не тему. Тема «Качество» — единственное место, где PRINCE2 говорит о содержании продукта, и делает это через проверяемые критерии приёмки в Product Description: прямой предок Definition of Done и acceptance criteria (см. приёмку). Тема «Изменения» шире, чем change control: она покрывает запрос на изменение, off-specification (дефект, который либо чинят, либо принимают формальной уступкой) и проблему — путать их дорого.

6. Семь процессов и их вложенность

Что читается на схеме. DP идёт поверх остальных процессов непрерывно — это единственный процесс, исполняемый Project Board; всё прочее делают менеджер и команды, поэтому все процессы «замыкаются» на DP. MP — граница ответственности: внутри команда работает как ей удобно (Scrum, Kanban, водопад), от неё требуют лишь принять Work Package с критериями приёмки, слать Checkpoint Report’ы и сдать продукт, прошедший проверку качества. SB выполняется до конца стадии, а не после — материалы для решения комитет должен получить раньше, чем стадия закончится. Предпроектная стадия отделена от инициации: SU — дешёвая фильтрация за несколько дней, IP — полноценная работа с бюджетом и отдельной авторизацией.

7. Управление по отклонениям и допуски — главное, что стоит украсть

Идея в одном абзаце: вместо согласования каждого действия каждый уровень получает допуск (tolerance) — диапазон, внутри которого решает сам. Наверх сообщают не факт отклонения, а прогноз выхода за допуск; пока прогноз внутри, начальство не вмешивается и получает только регулярные отчёты.

Допуски по качеству и содержанию живут не в отдельном документе, а в Product Descriptions — там, где записаны критерии приёмки. Допуск по выгодам задаётся только на уровне проекта: выгоды невозможно контролировать в границах одной стадии.

Слои допусков

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

Реакция зависит от слоя. Team Manager поднимает Issue менеджеру, тот решает в рамках допуска стадии: перераспределяет работу, снимает часть содержания, тратит запас. Project Manager при прогнозе выхода за допуск стадии пишет Exception Report в Project Board — не просьбу разрешить, а анализ: причина, последствия, варианты, рекомендация. Project Board решает и при необходимости запрашивает Exception Plan — план остатка стадии, заменяющий текущий; если отклонение выходит за допуск проекта, комитет сам эскалирует в корпорацию, которая расширяет допуск, урезает или закрывает проект.

Обратите внимание на шаги 3–6: не каждое отклонение поднимается наверх. Первое отставание съедено допуском стадии — менеджер решил сам и сообщил в обычном отчёте; наверх ушло только то, что он уже не мог покрыть полномочиями. Канал наверх остаётся чистым и потому его слушают.

Наблюдение, делающее механику работающей: допуск бесполезен, если его не пересчитывают в прогноз. «Мы потратили 40% бюджета» — не информация. «При текущем темпе на завершение стадии не хватит 9% бюджета» — информация, требующая действия. Отчётность, показывающая израсходованное вместо прогнозируемого, гарантированно узнаёт о проблеме поздно. Как это связано с типами решений и порогами полномочий в современной практике — в принятии решений в проекте.

8. Организационная структура целиком

Два места, где чаще всего ошибаются. Project Assurance нельзя поручить проектному менеджеру: это независимая функция, проверяющая, не выдаёт ли менеджер желаемое за действительное; менеджер, проверяющий сам себя, — имитация контроля, а в маленьких проектах assurance берёт на себя кто-то из членов комитета лично. Change Authority — не комитет, а бюджет: комитет выделяет фиксированный change budget и делегирует право распоряжаться им внутри порога; без этого любое изменение идёт через Project Board, очередь запросов получает лид-тайм в две недели, и появляется обходной путь «договорились в коридоре». Классическая рамка контроля изменений — в главе про устав и содержание.

9. Продуктовое планирование

PRINCE2 планирует не действия, а продукты, в четыре шага. Project Product Description — описание конечного продукта целиком: назначение, состав, критерии приёмки клиента, метод проверки, допуски по качеству; пишется в SU, утверждается заказчиком. Product Breakdown Structure (PBS) — иерархическая декомпозиция результата на продукты, только существительные: «пайплайн сборки», «схема БД», «руководство администратора», никаких глаголов. Product Descriptions — для каждого продукта нижнего уровня: назначение, состав, источник, навыки, критерии качества, метод и ответственные за проверку. Product Flow Diagram (PFD) — порядок создания и зависимости; только из него выводятся работы, длительности и график.

Смысл порядка: сначала договориться, что именно будет сдано и как это проверят, и лишь потом обсуждать, как делать. Планирование от действий («сначала анализ, потом разработка, потом тестирование») даёт план без проверяемого результата в любой точке; планирование от продуктов — список вещей, каждую из которых можно предъявить и принять.

PBS против WBS. Разница не терминологическая: PBS декомпозирует результат (что получится), WBS — работу (что делается). Формально PMI тоже требует deliverable-ориентированной WBS, но на практике она сползает в перечень активностей с глаголами, а PBS этого не допускает конструктивно. Правило 100%, work package, правило 8/80 и словарь WBS — в главе про устав, содержание и WBS.

10. Обязательные управляющие продукты

PRINCE2 определяет 26 управляющих продуктов в трёх группах: baselines (утверждаются, меняются через контроль изменений), records (журналы, ведутся непрерывно) и reports (снимок состояния). Вот те, без которых метода не остаётся.

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

11. PRINCE2 Agile: как каркас уживается со Scrum

PRINCE2 Agile (2015) отвечает на вопрос «мы работаем по Scrum, зачем нам стадии и комитет». Ответ структурный: agile живёт внутри процессов CS и MP (уровень поставки), а PRINCE2 остаётся на уровне DP и SB (уровень руководства). Work Package превращается в набор элементов бэклога, Checkpoint Report — в результат дейли или обзор доски, приёмка продукта — в Sprint Review. Комитет продолжает решать на границах стадий, но обсуждает не «сколько задач закрыто», а «сходится ли ещё Business Case».

Главная механика — инверсия фиксации. Классический проект фиксирует содержание и позволяет плыть сроку и бюджету; PRINCE2 Agile переворачивает: время и стоимость фиксированы жёстко, гибкими остаются содержание и качество — точнее, набор критериев качества, которые обязательно будут выполнены. Инструмент приоритизации — MoSCoW.

Эту раскладку изображают гексагоном, где у каждой из шести вершин показано, фиксирована она или гибка. Второй инструмент — Agilometer: шесть шкал оценки того, насколько среда пригодна для гибкого подхода (гибкость требований, сотрудничество с заказчиком, лёгкость коммуникации, возможность работать итеративно и поставлять инкрементами, благоприятность условий, готовность организации принять agile). Низкие оценки — сигнал не «внедрять agile сильнее», а адаптировать подход и чинить среду. Практическая сторона Scrum — в треке Scrum Master, сравнение подходов — в подходах и методологиях.

12. PRINCE2 против PMBOK

Практический вывод: они не конкуренты, а дополнения. На сайтах почти всех методологий (RUP, PRINCE2, MSF) обязательно есть статья «наша методология и PMBOK» с одним и тем же выводом — противоречий нет. Реалистичная сборка: governance из PRINCE2, техники из PMBOK, поставка из Agile. PRINCE2 к этому и располагает: он проектировался совместимым с MSP (программы), MoP (портфели) и ITIL (ИТ-услуги) — это одно семейство, и оно позволяет связать проект, программу и эксплуатацию единым языком.

13. Против: честная критика

Бюрократия. 26 управляющих продуктов, три уровня планов, формальные точки авторизации: при буквальном применении на маленьком проекте документооборот съедает больше времени, чем работа. Формально лечится принципом адаптации, но организации боятся «неправильного PRINCE2» и заполняют всё. Практический порог: если управляющих документов больше, чем людей в команде, метод применён неверно.

Плохо ложится на изменчивые требования. Метод предполагает, что содержание определяемо заранее и меняется через контроль изменений. Там, где требования меняются еженедельно, аппарат Exception Report’ов и Change Authority становится тормозом: пока запрос проходит регистрацию и оценку, он устаревает. PRINCE2 Agile лечит симптом на уровне поставки, не меняя природы каркаса. Побочно страдают новички: пока команда осваивает словарь аббревиатур, скорость падает.

Мягкий менеджмент почти не покрыт. Управление конфликтами, мотивация, развитие людей, коммуникация с руководством вне метода: PRINCE2 уделяет отчётам больше внимания, чем лидерству, и команда, управляемая строго по методу, может быть демотивирована при безупречной документации. В PRINCE2 7 это признано и добавлен элемент «люди», но в объёме, не заменяющем отдельного изучения — см. трек инженерного лидерства.

Англоязычная привязка. Корпус материалов, экзамены и сообщество — на английском, качественных русских переводов мало, терминология в них расходится; за пределами Великобритании и Северной Европы плотность PRINCE2-практиков заметно ниже, чем PMP.

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

14. Типичные ошибки

15. Как это выглядит в проде

Госконтракт на 18 месяцев, подрядчик и заказчик — разные организации. PRINCE2 применён почти дословно, потому что этого требуют тендерные условия. Работает то, ради чего он создан: Senior Supplier со стороны подрядчика и Senior User со стороны заказчика ловят конфликт «удобно/выполнимо» на границах стадий, а не в акте приёмки; Product Descriptions с критериями приёмки экономят месяцы спора о том, что считается сданным. Цена — около 15% времени менеджера на документы.

Внутренняя продуктовая команда, 7 человек, ничего не внедряли. Украдены две вещи. Допуски: тимлид двигает срок задачи на неделю сам, выше недели — разговор с владельцем продукта, выше месяца — с директором. И правило «наверх идёт прогноз, а не факт»: эскалация — сообщение в канале по шаблону «причина / влияние / варианты / рекомендация». Статусные встречи сократились вдвое, плохие новости стали приходить за три недели до срыва, а не в день срыва.

Программа из пяти проектов в банке. PRINCE2 на уровне проектов, MSP на уровне программы; полезнее всего оказались явные слои допусков — у программы по бюджету 8%, у каждого проекта 3%, сумма меньше целого, поэтому у программного офиса есть нераспределённый резерв. Три проекта из пяти за год ни разу не выходили за допуск и не отвлекали руководство.

Мини-итог

• PRINCE2 отвечает не на «как делать проект», а на «кто и на каком основании принимает решения». Он задаёт governance и молчит про техники — поэтому легко совмещается с PMBOK и Agile.
• Три интереса — бизнес, пользователь, поставщик — представлены персонально в Project Board; Executive всегда один человек, потому что решение закрыть проект коллективным не бывает.
• Три семёрки обслуживают шесть аспектов (время, стоимость, качество, содержание, выгоды, риск), и по каждому назначается допуск — это делает контроль конкретным.
• Управление по отклонениям — главное, что стоит взять. Допуски по слоям, наверх идёт прогноз, а не факт; Exception Report — анализ с вариантами, а не просьба; канал наверх остаётся чистым и потому работает.
• Планирование от продуктов, а не от действий: сначала «что сдаём и как принимаем» (Product Description, PBS, PFD), потом «какие работы к этому ведут». Принципы не адаптируются, всё остальное обязано: проект на четырёх человек с 26 управляющими продуктами нарушает PRINCE2 сильнее, чем проект вообще без документов.
• Честные слабости: бюрократичность, плохая переносимость на изменчивые требования, молчание про людей и лидерство, англоязычная привязка и высокий порог входа по терминологии.

Источники

• PRINCE2 — официальный сайт метода — структура, издания, экзамены.
• AXELOS / PeopleCert: PRINCE2 ProPath — сертификация Foundation и Practitioner.
• PRINCE2 Agile — Agilometer, гексагон, фиксация времени и стоимости.
• MSP, MoP, ITIL — соседи по семейству: программы, портфели, ИТ-услуги.
• ISO 21502:2020 — нейтральное руководство, полезное как «общий знаменатель» PRINCE2 и PMBOK.
• PMBOK Guide — свод знаний PMI для сравнения.
• PRINCE2. Британский принц проектного менеджмента — популярное русскоязычное введение.

Что дальше

PMBOK и PRINCE2 — два самых известных ответа на вопрос «как устроено управление проектами», но далеко не единственные. Рядом живут ISO с нейтральным словарём, IPMA со стандартом на компетенции человека, открытые методы на десять страниц, российские ГОСТы, без которых не берут госконтракт, и модели зрелости, измеряющие не проект, а организацию.

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

Читайте: Ландшафт стандартов: ISO 21500/21502, IPMA ICB, P3.express, ГОСТ и модели зрелости