6 принципов PMBOK 8: краткий обзор для руководителя ИТ-проекта
«Принципов стало меньше — значит, стало проще?»
Если вы открываете восьмую версию PMBOK и видите шесть принципов вместо двенадцати, не пугайтесь — это не упрощение, а укрупнение и усиление. Авторы стандарта убрали дублирования и объединили близкие идеи, ни один из старых принципов не потерян. Просто теперь их легче запомнить и проще применять, и главное — эти 6 принципов PMBOK 8 работают и в водопаде, и в Agile, и в гибридных проектах.
В этой статье мы разберём все шесть принципов PMBOK 8 с примерами из ИТ, расскажем, чем отличаются принципы PMBOK 8 от PMBOK 7, и покажем, как применить их в своём проекте уже завтра.
Почему принципы важнее процессов
Процессы отвечают на вопрос «что делать», а принципы — «как думать». Процессы полезны, когда ситуация стандартная: есть чёткая инструкция — выполняй. Но как только появляется неопределённость (а в ИТ она почти всегда есть), жёсткая инструкция перестаёт работать. Здесь нужен принцип — общий ориентир, который помогает принять решение, даже если никто не написал, как правильно.
В PMBOK 7 было 12 принципов, в PMBOK 8 их стало шесть, но ни один не потерян — например, «будьте хорошим руководителем», «создавайте атмосферу сотрудничества» и «эффективно взаимодействуйте со стейкхолдерами» вошли в более ёмкий принцип «ответственное лидерство». Если вы знали седьмую версию, вы уже понимаете 80% философии восьмой, осталось привыкнуть к новой группировке.
Шесть принципов PMBOK 8 с примерами из ИТ
1. Целостный подход. Проект не существует в вакууме, нельзя изменить один элемент, не оценив влияние на остальные. ИТ-пример: команда ускорила разработку, отказавшись от интеграционных тестов, скорость выросла, но после релиза сломались смежные сервисы, и исправление заняло втрое больше времени. Что делать: перед любым изменением нарисуйте карту влияния — кого затронет решение, какие элементы проекта изменятся, есть ли скрытые обратные связи.
2. Фокус на ценности. Успех измеряется не закрытыми задачами, а реальной пользой для бизнеса и пользователей. ИТ-пример: команда два месяца проектировала идеальную микросервисную архитектуру, а заказчику нужен был простой прототип через две недели, чтобы показать инвесторам. Что делать: на каждом планировании спринта задавайте команде вопрос «какую бизнес-проблему решает эта задача?», и если ответа нет — возможно, задачу можно отложить.
3. Встраивание качества. Качество не проверяют в конце, его создают на каждом этапе, и исправление дефекта на ревью кода стоит в десятки раз дешевле, чем на продакшене. ИТ-пример: команда, которая ждёт тестировщика в конце спринта, обречена на переделки, а та, которая проверяет качество на каждом коммите, выпускает релизы без авралов. Что делать: внедрите правило — ни один пул-реквест не попадает в основную ветку без автотестов или обоснования, почему они не нужны. Подробнее об этом — в статье Управление качеством в ИТ-проекте.
4. Ответственное лидерство. Руководитель не ищет виноватых, а создаёт психологическую безопасность. Когда люди боятся ошибок, они скрывают проблемы до последнего. ИТ-пример: после сбоя на продакшене руководитель не спрашивает «кто не досмотрел?», а проводит разбор инцидента без обвинений, и команда вместе ищет корневую причину — не в человеке, а в процессе. Что делать: публично признавайте свои ошибки, расскажите команде «я ошибся в оценке этого спринта, давайте разберёмся» — это даёт разрешение остальным делать то же самое.
5. Устойчивое развитие (ESG). Проект учитывает экологические, социальные и управленческие последствия. ИТ-пример: при выборе хостинг-провайдера сравниваете не только цену, но и энергоэффективность (PUE), а устаревшее оборудование передаёте на утилизацию, а не на свалку. Что делать: добавьте простые ESG-критерии в требования к подрядчикам, например, «провайдер должен предоставить данные об энергопотреблении».
6. Культура полномочий. Команда сама принимает решения в своей зоне ответственности, руководитель задаёт «что» и «зачем», но не «как». ИТ-пример: разработчики сами выбирают стек технологий, аналитики сами приоритезируют бэклог, команда сама распределяет задачи внутри спринта. Что делать: начните с малого — на ближайшем стендапе делегируйте команде одно решение, которое обычно принимаете вы, и не вмешивайтесь, даже если их порядок отличается от вашего. Подробнее о делегировании — в статье 7 уровней автономии по Апелло.
Как применить принципы PMBOK 8 в своём проекте
Не нужно внедрять все шесть сразу.
- Выберите один принцип, который нарушается чаще всего — релизы с багами? Начните с «встраивания качества». Команда боится говорить о проблемах? Начните с «ответственного лидерства».
- Обсудите принцип с командой, не объявляйте «теперь мы работаем по принципу целостного подхода», а просто спросите «где в последнее время мы действовали несогласованно?».
- Внесите одно изменение в процесс — для «встраивания качества» добавьте в Definition of Done пункт «код прошёл ревью коллеги».
- Закрепите ритуалом — на стендапе выделите 30 секунд на вопрос «что сегодня мешает нам создавать качество с первого раза?».
- Через месяц добавьте следующий принцип.
Часто спрашивают про принципы PMBOK 8
Какие 6 принципов PMBOK 8? Целостный подход, фокус на ценности, встраивание качества, ответственное лидерство, устойчивое развитие, культура полномочий.
Чем отличаются принципы PMBOK 8 от PMBOK 7? Количеством и степенью обобщения — старые 12 принципов никуда не делись, они вошли в новые шесть, смысл остался прежним, запоминать стало проще.
Принципы PMBOK 8 и Agile — совместимы? Да, и это не компромисс, а усиление: «фокус на ценности» — основа владения продуктом, «культура полномочий» — про самоорганизующиеся команды, «встраивание качества» — про Definition of Done и автотесты.
Нужно ли знать все шесть принципов наизусть? Нет, начните с одного-двух, которые решают ваши текущие боли, остальные подтянутся позже.
Можно ли применять принципы PMBOK 8 в Scrum? Да, принципы не привязаны к методологии — в Scrum они выглядят как естественная часть процесса: ценность продукта, ретроспективы, самоорганизация команды.
6 принципов PMBOK 8 — это ваш фильтр для принятия решений. Начните с одного, который решит вашу текущую боль, и вы увидите, как меняется качество управления проектом.
На воркшопах мы не просто читаем про принципы, а применяем их к вашим реальным проектам — с конфликтами и нестандартными ситуациями. Присоединиться →