PMBOK: от 49 процессов и 10 областей знаний к 12 принципам и 8 доменам

PMBOK (Project Management Body of Knowledge) — попытка собрать и описать все известные человечеству знания в области управления проектами. У этого замысла две стороны. С одной, документ приближается к энциклопедии и гарантирует сохранность важных практических знаний: если что-то в управлении проектами существует, оно там упомянуто. С другой — именно эта полнота размывает документ и мешает использовать его как руководство к действию. PMBOK, впрочем, никогда и не позиционировался как практическое руководство.

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

PMBOK — наиболее полное изложение знаний, признаваемых сообществом менеджеров проектов. Он задаёт рамки для более практических и узконаправленных методологий, но сам методологией, пригодной к непосредственному применению, не является. Он — основа для создания практических методологий.

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

1. Кто издаёт и как он менялся

Project Management Institute — американская профессиональная ассоциация, основанная в 1969 году. Первую версию свода она выпустила в 1987-м как «PMBOK White Paper», первое полноценное издание — в 1996-м. Дальше — примерно раз в четыре года.

Три вещи из этой хронологии важны практически.

Числа «44 процесса и 9 областей знаний» относятся к 3-му изданию (2004) — именно они кочуют по русскоязычным конспектам и учебным курсам до сих пор. В 5-м издании появилась десятая область (управление заинтересованными сторонами), в 6-м процессов стало 49. Встретив в чужом тексте «9 областей», вы теперь знаете его возраст.

6-е издание — последнее процессное и до сих пор самое полезное как справочник. Именно его матрицу разбирают на курсах, по ней устроено большинство корпоративных методологий, и именно из неё берут техники.

7-е издание — не обновление, а смена жанра. Процессы заменены принципами, области знаний — доменами исполнения, а весь процессный аппарат переехал в онлайн-библиотеку PMIstandards+. Причина разворота разбирается в разделе 8, но её стоит назвать сразу: предписывающий документ на несколько сотен страниц плохо переносится между контекстами, а попытка описать все случаи даёт объём, который никто не читает целиком.

2. Основная концепция: матрица процессов

Классическая модель PMBOK устроена как двумерная таблица. Каждый процесс управления проектами одновременно принадлежит одной из пяти групп процессов и ровно одной из областей знаний. В 3-м издании это давало 44 процесса на девяти областях, в 6-м — 49 процессов на десяти.

Пять групп процессов:

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

Главное недоразумение вокруг матрицы: группы процессов — это не фазы проекта. Инициация не «происходит вначале», а завершение не «происходит в конце». В любой фазе проекта работают процессы всех пяти групп одновременно: фаза инициируется, планируется, исполняется, контролируется и закрывается. Именно из-за чтения групп процессов как фаз PMBOK получил репутацию «водопадного стандарта», хотя ничего водопадного в нём нет.

3. ITTO: входы, инструменты и методы, выходы

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

Входы. Либо артефакты, полученные при выполнении другого процесса, либо знания из внешней по отношению к проекту среды. Два входа встречаются почти у всех процессов и заслуживают перевода с канцелярского: факторы среды предприятия (enterprise environmental factors) — то, что вы не контролируете: законы, отраслевые стандарты, рыночные условия, корпоративная культура, существующие информационные системы; активы организационных процессов (organizational process assets) — то, что накоплено внутри: шаблоны, регламенты, архив прошлых проектов, база уроков. Второе — прямое обоснование того, зачем вести архив «оценка — факт»: без него оценка по аналогии не работает.

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

Инструменты и методы. Наиболее ценная часть, в которой собраны все известные авторам практики, относящиеся к данному процессу. Стремление включить именно все практики иногда приводит к утверждениям, забавным по своей банальности; впрочем, банальность здесь субъективна — то, что очевидно человеку с одним опытом, оказывается новостью для человека с другим. Эту часть имеет смысл читать для расширения личного арсенала методик. Но поскольку описывается множество практик, в том числе взаимоисключающих, невозможно начать пользоваться этими указаниями напрямую, не спроецировав их предварительно на конкретный проект с использованием собственного опыта.

Разбор одного процесса целиком: планирование качества

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

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

Инструменты и методы.

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

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

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

4. Десять областей знаний

Десятая область появилась в 5-м издании и до этого была частью коммуникаций; вынесение её отдельно — самое осмысленное изменение за всю историю свода. Причина простая: коммуникация — это канал, а работа со стейкхолдерами — это влияние и интересы, и сведение второго к первому даёт менеджера, который аккуратно рассылает отчёты людям, чьи цели он не выяснял. Техника анализа стейкхолдеров — карта власти и интереса, стратегии вовлечения — разобрана в треке системного анализа.

Почему управление интеграцией стоит над остальными

Хотя все процессы очевидным образом связаны — чётко определено, выходы каких процессов являются входами для каких, — PMBOK несколько раз акцентирует внимание на том, что в реальности процессы не идут последовательно один за другим, а происходят параллельно и являются взаимосвязанными. Более того, свод сознательно отказывается устанавливать эти связи, заявляя, что они слишком сложны, разнообразны и зависимы от конкретного наполнения проекта.

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

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

Характерно, что в методологиях вроде PRINCE2 связи между процессами заданы явно: выход одного процесса прямо назван входом другого, есть точки авторизации и обязательная последовательность. Это и есть разница между сводом знаний и методом: свод перечисляет, метод связывает.

5. Участники проекта

К ключевым участникам любого проекта относятся:

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

6. Три основных документа

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

План управления проектом делится на части по областям знаний — и, как отмечено выше, частей на одну меньше, чем областей. Состав, шаблоны и лёгкая версия для команды из шести человек разобраны в отдельной главе (устав, содержание и WBS), поэтому здесь ограничимся связкой: устав авторизует, содержание ограничивает, план описывает способ. Если какой-то из трёх ответов в проекте отсутствует, он будет дан позже и кем-то другим — обычно в момент конфликта и не в вашу пользу.

7. Честная критика

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

Последняя строка — ключ к правильному обращению. Свод знаний не обязан быть лёгким: он обязан быть полным. Лёгкими бывают методы, собранные из него под конкретный контекст, — и ровно за этим существуют P3.express и подобные.

8. Седьмое издание: разворот к принципам

В 2021 году PMI сделал то, чего от него не ждали: выбросил процессную модель из основного текста. Вместо 49 процессов — 12 принципов, вместо 10 областей знаний — 8 доменов исполнения. Процессы никуда не делись, но переехали в онлайн-библиотеку PMIstandards+, где живут как набор практик с примерами применения.

Что изменилось по существу, а не по оформлению.

Единицей описания стал результат, а не действие. Домен «поставка» не говорит, какие процессы выполнить; он говорит, какой результат должен быть достигнут, и перечисляет соображения. Это перенос той же идеи, что лежит в основе продуктового планирования PRINCE2 и правила «WBS состоит из существительных».

Ценность вытеснила тройственный ограничитель. Проект, сданный в срок и бюджет и не принёсший пользы, в новой рамке не считается успешным. Это признание проблемы, известной по данным: перерасход бюджета в крупных ИТ-проектах составляет десятки процентов, а недобор обещанной ценности — больше половины (McKinsey и Оксфорд).

Адаптация (tailoring) стала обязательной, а не разрешённой. Раньше свод перечислял всё, и организация молча выбирала; теперь выбор объявлен явной работой с ответственным. Это сближает PMBOK с седьмым принципом PRINCE2, где не адаптировать метод — тоже нарушение метода.

Гибкие подходы перестали быть приложением. Домен «подход к разработке и жизненный цикл» ставит выбор между предиктивным, итеративным, инкрементным и адаптивным в центр планирования, а не в примечание (см. подходы и методологии).

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

9. Что брать в IT-проект

PMBOK бесполезен как обязательство и очень полезен как каталог. Разумный отбор для команды, которая не готовится к сертификации, выглядит так.

Берите почти всегда: различение трёх документов (устав, содержание, план); правило 100% и WBS как чек-лист полноты; матрицу ответственности RAM/RACI (глава 10); реестр рисков с владельцем и выбранной реакцией; терминологию резервов — contingency против management reserve (глава 8); процедуру управления изменениями с порогами полномочий; журнал допущений и ограничений.

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

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

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

Про сертификацию PMP

PMP (Project Management Professional) отличается от большинства IT-сертификаций тем, что требует подтверждённого опыта: 36 месяцев руководства проектами при высшем образовании (или 60 без него) плюс 35 часов обучения, и только потом экзамен. Экзамен с 2021 года устроен вокруг трёх доменов — люди, процесс, бизнес-среда — и примерно половина вопросов относится к гибким и гибридным подходам. Практическая ценность разная: в ИТ-продуктовых компаниях сертификат почти не влияет на найм, в консалтинге, интеграции и на тендерах — влияет прямо, потому что число сертифицированных менеджеров бывает условием конкурса.

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

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

Интегратор, работающий по конкурсам. PMBOK используется в качестве источника корпоративной методологии: взяты устав, описание содержания, WBS со словарём, реестр рисков, процедура изменений и отчётность по освоенному объёму — потому что этого требует заказчик. Внутри команды разработка идёт двухнедельными итерациями, и это не противоречие: слой соответствия отделён от слоя исполнения и имеет посчитанную стоимость — около 12% времени менеджера.

Продуктовая компания, 200 человек. Свод знаний живёт как справочник у руководителя направления. Из него взяты ровно четыре вещи: журнал допущений с владельцами, реестр рисков с реакциями, различение двух видов резерва и процедура изменений с порогами. Формально «PMBOK не внедрён», фактически — используется именно так, как задумывался.

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

Мини-итог

• PMBOK — энциклопедия, а не методология. Он задаёт рамки для практических методов, но сам к прямому применению не предназначен; «внедрить PMBOK» невозможно, можно только выбрать из него и собрать свой процесс.
• Классическая модель — матрица: пять групп процессов на десять областей знаний, 49 процессов в 6-м издании (44 и девять областей — это 3-е издание, по которому написано большинство русских конспектов). Группы процессов — не фазы: в каждой фазе работают все пять.
• Каждый процесс описан через входы, инструменты и методы, выходы. Самая ценная часть — инструменты; читать её стоит ради расширения арсенала, а применять — только спроецировав на конкретный проект. Шаблонов документов свод намеренно не даёт.
• Управление интеграцией стоит над остальными областями. PMBOK отказывается фиксировать связи между процессами и отдаёт их интеграции; показательно, что план управления проектом состоит из планов по всем областям, кроме неё — интеграция не поддаётся планированию. В методах вроде PRINCE2 связи, наоборот, заданы явно.
• 7-е издание сменило жанр: 12 принципов и 8 доменов вместо процессов, ценность вместо тройственного ограничителя, обязательная адаптация, гибкие подходы в центре, а не в приложении. Практично читать оба: седьмое — ради рамки, шестое — ради техник.
• Из свода в IT-проект берут немногое: три документа, WBS как чек-лист полноты, RACI, реестр рисков, различение contingency и management reserve, процедуру изменений с порогами и журнал допущений. Фильтр один — какое решение изменится из-за существования артефакта.

Источники

• PMBOK Guide, PMI — основной свод; PMIstandards+ — онлайн-библиотека процессов и практик, куда переехала процессная модель.
• PMI Practice Standard for Work Breakdown Structures — правило 100%, словарь WBS, уровни декомпозиции.
• Agile Practice Guide, PMI и Agile Alliance — приложение 6-го издания о гибких подходах.
• PMP Certification — требования к опыту и структура экзамена.
• PRINCE2 — метод, где связи между процессами заданы явно; полезное сравнение со сводом знаний.
• ISO 21502:2020 — нейтральное руководство, часто используемое как общий знаменатель PMBOK и PRINCE2.
• McKinsey и Оксфордский университет, «Delivering large-scale IT projects on time, on budget, and on value», 2012 — данные о недоборе ценности, стоящие за разворотом 7-го издания.

Что дальше

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

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

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