На связи Наталья Воронько из РТЛабс. Я RTE Аналитической Платформы и ЕЛК, а в прошлом — руководитель проектов и функциональный руководитель. Сегодня хочу поделиться своим взглядом на новую редакцию PMBOK® Guide от Project Management Institute (PMI).
В этой статье будут мои наблюдения как практика, не пренебрегавшего теорией, прошедшего проекты и программы разного масштаба и сложности.
Официального русского перевода PMBOK® Guide 8th edition у меня нет. Я читала английскую версию, поэтому некоторые термины могут отличаться от будущего официального перевода. Для точности буду указывать в скобках оригинальные названия и термины.
Ссылки на информацию о Стандарте и на другие источники института PMI буду прикладывать, но открываются они только с помощью VPN.
PMBOK 8: коротко о главном
PMBOK® Guide давно считается золотым стандартом в управлении проектами.
Восьмая версия вышла 13 ноября 2025 г. После спорной седьмой и на фоне заметных трансформаций последних лет она вызвала живой интерес ещё задолго до публикации. Слухи, утечки, обсуждения в профессиональных сообществах — всё указывало на то, что PMI собирается снова нас удивить. Результат оправдал ожидания: получилось интересно.
PMBOK® Guide 8 стал полнее, практичнее, понятнее и актуальнее. Он органично соединяет три ключевых измерения:
-
принципы — «почему»
-
домены эффективности — «что»
-
области фокусировки — «когда»
Такая структура позволяет гибко адаптировать подход под любой контекст — будь то предиктивный, адаптивный (Agile) или гибридный проект.
Проект — фокус на ценность
Самый фундаментальный сдвиг произошёл в самом определении проекта. Если ранее он формулировался как «временная работа по созданию уникального продукта», то теперь — как «временная инициатива в уникальном контексте, направленная на создание ценности».
Эта формулировка переносит центр тяжести с выполнения задач на доставку ощутимого эффекта. Успех больше не измеряется ни соблюдением тройного ограничения в виде сроков, бюджета и объёма, ни наличием работающего функционала.
Ключевой метрикой становится консенсус бенефициаров: почувствовали ли они, что полученная ценность стоит вложенных усилий и ресурсов (value-driven success).
Экономическая целесообразность проекта упоминалась и в более ранних версиях: Бизнес-кейс был входным документом для Устава Проекта. Но он был, скорее, фундаментом, и в больших проектах до команды доходил в очень размытом виде. Да и не все хотели его понимать. В результате команды фокусировались на реализации (outputs), игнорируя решение задач бизнеса (outcomes). Требовалась тактичность, деликатность и настойчивость для возвращения фокуса на реальную пользу.
Новое определение поддерживает позицию «сделано то, что нужно, а не то, что сказано».
Принципы: короче и по делу
Принципы, введённые в седьмой версии, остались, но их количество сократилось с 12 до 6. Это результат продуманной консолидации: близкие идеи объединены, дублирование устранено. Например, «оптимизируй поток» и «фокусируйся на ценности» теперь работают в единой связке.
Вот какие принципы сейчас сформулировали:
-
ответственное лидерство (be an accountable leader) — лидерство как образ мышления, которым делишься со всей командой.
-
целостное мышление и системный взгляд (adopt a holistic view) — важно ориентироваться на системный подход и понимать, как изменения во внутренней и внешней среде влияют на проект
-
ориентация на ценность (focus on value) — проектные решения должны быть направлены на достижение стратегических целей и результатов, поддерживая идею проекта как инициативы для создания ценности
-
встраивание качества в процессы и результаты (embed quality into processes and deliverables) — интегрирует стандарты непрерывного контроля и проверки качества в каждый этап реализации проекта. Довольно старая тема
-
интеграция устойчивого развития во все области проекта (integrate sustainability within all project areas) — интеграция долгосрочного экологического, социального и экономического воздействия проектной деятельности
-
наделение полномочиями и создание поддерживающей культуры (build an empowered culture) — важно формировать адаптивную, доверительную и гибкую среду, в которой проектная команда может принимать решения
Примечательно, что эти принципы во многом совпадают с принципами SAFe — фреймворка, который мы используем в РТЛабс. Мы в тренде – приятно осознавать.
Для тех, кому интересно понять, как распределились принципы, в самом стандарте есть справочная страница соответствия, показывающая, какие принципы седьмого издания вошли в каждый из шести новых в восьмом издании.
Agile: долгий путь к принятию
В версиях до 5 включительно Agile-методы упоминались в PMBOK® спорадически, как нишевое решение — или не упоминались вообще. Генеральной линией оставался предиктивный подход, более известный как водопад.
Перелом наступил в 2017 году с выпуском шестого издания, сопровождавшегося релизом Agile Practice Guide (APG). Это был эффектный дипломатический ход: основной том сохранял верность предиктивным процессам и областям знаний, но в приложении PMI официально признал: «Да, Scrum и Канбан существуют, и мы даже знаем, как их сопоставить с нашими процессами».
Скорее всего, это был ответ на рыночное давление и запуск сертификации PMI-ACP ещё в 2011 году. Однако некоторые эксперты отмечали, что это было, скорее, «гибридное перемирие», а не полная интеграция.
Седьмая редакция стала настоящим вызовом консерваторам. PMI совершил смелый шаг: отказался от процессов в пользу принципов. Теперь неважно, работаете вы по водопаду или скраму — важны ценность, стейкхолдеры и управление неопределённостью. Этот шаг, возможно, спас стандарт от превращения в музейный экспонат. Именно в седьмой версии адаптивность окончательно легитимизировалась как вариант нормы.
Восьмая версия завершает этот путь: Agile-практики получили повышение из приложения в ядро стандарта:
-
daily scrum упоминается как инструмент управления вовлечением заинтересованных сторон и коммуникацией, даже если у вас не скрам. Более того, в предиктивных проектах он рассматривается как средство быстрой идентификации и устранения препятствий
-
роль владельца продукта (Product Owner) формально закреплена как представителя заказчика — внутреннего или внешнего
-
итеративное планирование признано официально — результаты спринта напрямую влияют на следующий план. Планирование и исполнение становятся постоянным диалогом: план обновляется после каждого спринта на основе реальной скорости команды (Velocity), превращая «Разработку расписания» (Develop Schedule) в живую активность
-
agile release planning теперь официально включено в процесс «Разработка расписания» (Develop Schedule). И даже более: он рассматривается как основной инструмент для создания высокоуровневого графика — обычно на 3–6 месяцев — на основе дорожной карты продукта. У стейкхолдеров поэтому появляется понимание того, что и когда примерно будет доставлено, без детализации планов спринтов
-
вместо жёсткого предписания ролей стандарт продвигает культуру доверия, совместной ответственности и автономии (empowered culture)
PMBOK® Guide 8 — самое Agile-дружелюбное издание, но оно делегирует глубину другим продуктам PMI, например Agile Pracice Guide и Disciplined Agile (DA). Это разумный компромисс для универсального стандарта, но недостаток для ожидающих «всё в одном».
Для глубокого понимания Agile-практик, масштабирования Agile, восьмой версии может быть всё ещё недостаточно. Как отмечают эксперты, полная интеграция, вероятно, придётся на 9 издание — если PMI решит, что зрелость рынка требует большей конкретики.
Гибрид как выбор большинства
Если шестое издание предложило «гибридное перемирие», то восьмое делает следующий шаг — легитимизирует гибрид как основной режим работы.
PMI говорит что по результатам их исследований более 80% проектов сегодня идут по гибридным моделям. И здесь я вспоминаю слова Чака Кобба — эксперта, известного своим прагматичным подходом в управлении проектами: «Гибридный подход — это не попытка совместить несовместимое. Это осознанный выбор лучших практик для решения конкретной бизнес-задачи в конкретном контексте».
Именно это предлагает PMBOK® Guide 8. Он не требует от проектной методологии быть «чистым водопадом» или «чистым аджайлом». Он предлагает гибкий каркас, внутри которого можно комбинировать элементы:
-
на стратегическом уровне — предиктивные практики. Например, формальный устав, бюджетирование, этапы согласования
-
на операционном уровне — адаптивные циклы. Это спринты, ретроспективы, итеративная поставка.
В своей работе я часто смешивала практики из разных подходов, используя предиктивные методы на уровне программы и адаптивную работу на уровне команды. Применяла Метод Освоенного Объёма (Earned Value Analysis) для сведения сторипойнтов, долларов и дней, или рисовала Gantt-диаграммы для визуализации всех зависимостей важной фичи с жёстким дедлайном в масштабируемом Agile-проекте.
Я ориентировалась на рациональность и удобство инструмента. Но называть это гибридом я избегала — опасалась, что меня не поймут или сочтут, будто я плохо понимаю и Agile, и классическое управление. Казалось, что на проекте нужно выбирать «одну веру».
Сегодня такая ситуация стала нормой. PMBOK® Guide 8 легитимизирует этот подход, снимая необходимости смущённо прятать Gantt под Burn-down диаграммой. Гибрид стал осознанным выбором зрелого практика.
Процессы, домены и ITTO – каркас для любого проекта
Архитектура PMBOK® Guide 8 превращает гибрид из идеи в рабочий инструмент. И всё это довольно легко реализуется технически
Области фокусировки (Focus Areas). Знакомые пять групп процессов — инициация, планирование, исполнение, мониторинг и контроль, завершение — вернулись под зонтиком «Области Фокусировки». Теперь они снова часть Руководства как универсальные категории деятельности, включённые во все подходы — и предиктивный, и адаптивный (Agile), и гибридный. Считаю, что это удобно, логично и естественно. Например, в рамках SAFe фреймворка они используются постоянно: мы планируем PI (планирование), контролируем поток работ (мониторинг), передаём функционал в поддержку (завершение).
Семь доменов эффективности (Performance Domains) — Governance, Scope, Schedule, Finance, Stakeholders, Resources, Risks — сформированы из 10 областей знаний шестой версии и 8 доменов седьмой версии. Изменения варьируются от косметических до принципиальных.
40 гибких процессов, выросшие из 49 процессов предыдущих версий, — внутри доменов. Возвращение процессов и ITTO — входы, инструменты, техники и выходы — после абстрактной седьмой версии приветствуется многими. «Делайте гибко» — отличный совет, но плохая инструкция. Без чёткого каркаса там, где нет зрелой культуры, качество управления упадёт.
Проверка на ценность (Check Results) — новинка седьмой версии и приз моих личных симпатий, переехала в восьмую версию. Он включён в каждый домен и задаёт простой, но серьёзный вопрос: «Достигаем ли мы цели?». Это механизм рефлексии и прямая поддержка Agile-цикла inspect and adapt.
Адаптация под контекст (Tailoring) тоже включена в каждый домен. Кроме того, она стала более структурированной и к ней добавили конкретные примеры. Здесь есть подсказки, как сочетать элементы предиктивного подхода — например, для соблюдения нормативных требований — и Agile — для итеративной разработки. Её цель — помочь осознанно настраивать проектный подход под среду, возможности и цели.
Финансы (Finance) вместо Стоимости (Cost). Это переименование отображает новые акценты на реализацию ценности и стратегическое управление инвестициями. Менеджер проекта теперь должен следить за тем, какой возврат на инвестиции (ROI) получает организация. В рамках Finance теперь чаще обсуждается «динамическое бюджетирование». Вместо фиксации затрат на старте теперь поощряется подход, при котором финансирование может перераспределяться между релизами в зависимости от того, какая функциональность приносит больше ценности бизнесу.
Однако не все изменения однозначно удачны.
Так, Качество (Quality) больше не отдельный домен, теперь это часть Объёма (Scope). В крупных системах качество часто является отдельной профессиональной дисциплиной, требующей выделенных команд и независимых проверок. Встраивание его в другой домен размывает зону ответственности и снижает приоритет. Без выделенного домена процессы обеспечения качества теряют структуру, их сложнее находить, планировать и применять системно.
Коммуникация тоже больше не отдельный домен, она стала частью домена Stakeholders. С одной стороны, это понятно и логично, ведь общение существует ради взаимодействия. Но, с другой стороны, очень легко забыть, что команда — тоже стейкхолдер. Её информационные потребности и схема коммуникации требуют анализа и осознанного проектирования. В реальной жизни команда часто воспринимается как данность, и эффективность коммуникации остаётся без внимания. Как результат, команда тонет во встречах, принимает это как досадную, но неизбежную часть производственного процесса и оправдывает невысокую результативность высокой активностью.
Закупки (Procurement) тоже лишились отдельного домена и были вынесены в приложение. Часть активности по управлению контрактами и выбору поставщиков теперь в доменах Управление (Governance) и Финансы. Это может быть разумно, но в секторах с жёстким регулированием — особенно в госИТ — закупки часто определяют реализуемость проекта.
Новые темы: ИИ, PMO, устойчивость
Искусственный интеллект впервые получил отдельное упоминание — стандарт отражает современный контекст. PMI рассматривает ИИ как инструмент:
-
для прогнозирования рисков на основе исторических данных
-
работы с расписанием
-
уточнения оценок производительности
-
автоматизации рутинных задач
Но на мой взгляд, это скорее первый подход, чем полноценная стратегия. Почти отсутствует управление рисками, связанными с предвзятостью алгоритмов. Этика и безопасность применения ИИ не выделена в отдельный принцип. Я вижу в этом прагматизм: институт не хочет, чтобы стандарт устарел через полгода, и не выпускает правила для технологий, которые меняются ежемесячно.
Отсутствие готовых рецептов по внедрению нейросетей в управление проектами может разочаровать. Но стоит помнить: Стандарт описывает возможности, но не подменяет мышление. Там, где заканчиваются алгоритмы, решающую роль играют экспертиза и профессиональное суждение. Решение на проекте принимает человек, ответственность тоже несёт человек.
Project Management Office (PMO) тоже проходит серьёзную трансформацию. От него больше не ждут роли «полиции процессов». Современный PMO — это центр компетенций и стратегический партнёр, который:
-
поддерживает гибридные подходы
-
обеспечивает обучение и фокусирующийся на ценности
-
выстраивает и процессы, и мышление, и культуру
-
гарантирует, что проект в портфеле напрямую работает на достижение долгосрочных целей организации, действуя отчасти как VMO (Value Management Office)
-
берёт на себя внедрение AI-инструментов
-
становится аналитическим хабом
-
помогает выбрать наиболее подходящий подход, сохраняя системную целостность
Устойчивое развитие (sustainability) в фокусе. Это включает социальные, экологические и управленческие аспекты долгосрочной ценности и последствий проекта. Например, баланс между немедленной выгодой и долгосрочной устойчивостью организации, и даже оценка воздействия на климат и ресурсы.
Что упущено: тишина о людях
Несмотря на все сильные стороны,в восьмом издании исчезли конкретные модели управления изменениями, например ADKAR или модель Вирджинии Сатир, которые присутствовали в седьмой версии. Управление изменениями остаётся в доменах Управление (Governance) и Stakeholders, но без практических инструментов.
Я считаю это упущением. Любая трансформация — это, прежде всего, изменение культуры, поведения и привычек людей. В условиях постоянной эволюции платформ и процессов явное внимание к управлению изменениями с деталями и рекомендациями было бы крайне полезным. Этот пробел будет особенно ощутим для организаций, которые планируют трансформацию или находятся в начале её активной фазы.
Заключение: синтез зрелости
PMBOK® Guide 8 — удачный синтез лучших элементов прошлых версий. Детальные процессы шестого издания и гибкие принципы седьмого объединились в практическое руководство для современных реалий. Высокие идеи «доставляй ценность» теперь подкреплены конкретными практиками: «как планировать, когда всё меняется».
Прочитать стандарт, выучить правильную последовательность процессов и их ITTO и подгонять под неё проект недостаточно. Современный руководитель проектов должен владеть широким спектром подходов, понимать их применимость, сочетаемость, влияние на связанные процессы, и уметь выбирать именно то, что добавляет реальную ценность в его контексте.
Иронично, что мы так делали и раньше, но теперь такой подход легализован. Он умеет выстраивать диалог с разными стейкхолдерами, чтобы сформировать консенсус: действительно ли результат стоит усилий. Он становится архитектором подходов, он сочетает стратегическое видение с операционной гибкостью. Именно за это восьмую редакцию называют «стандартом для взрослых» — здесь мало послушно следовать написанному, здесь нужно иметь профессиональное суждение и ответственность.
Таким образом, PMBOK® Guide 8 окончательно закрепляет переход от эпохи предиктивного доминирования к эпохе гибридной зрелости, где методология служит цели. На мой взгляд, получилось достойное сочетание дисциплины, гибкости и здравого смысла.
Автор: nt-voronko
