🔥 PMBOK 8th Edition: 12 принципов стало 6. Что это значит для вас?

13 ноября 2025 года PMI выпустил восьмую редакцию PMBOK Guide — и это не просто косметическое обновление. Если в седьмой редакции (2021) было 12 принципов управления проектами, то теперь их шесть. Звучит проще? Не совсем. Просто изменился фокус.

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

6 принципов вместо 12
Было: бережливость, системное мышление, лидерство, ответственность, уважение, адаптация, результативность, фокус на ценности, признание системы, контекст, взаимодействие, разбиение на элементы.
Стало шесть консолидированных принципов, которые покрывают всё то же, но без дублирования. Это не упрощение — это концентрация. Каждый принцип теперь тяжелее по смыслу.

7 доменов производительности
Вместо 10 областей знаний (как в 6-й редакции) — 7 доменов, которые охватывают весь жизненный цикл проекта. Плюс в каждый домен интегрированы технические способы работы. Agile больше не «приложение» — он встроен в основу.

Три новые техники
Восьмая редакция добавила в глоссарий три инвестиционных инструмента:
• Value Breakdown Structure (VBS) — структура разбивки стоимости по ценности, а не по работам.
• Critical Path Drag — сколько времени элемент критического пути «отбирает» у проекта.
• Critical Path Drag Cost — стоимость этой задержки в деньгах.

Это инструменты для тех, кто считает не только сроки, но и деньги.

Почему это важно
Если вы практик — стоит прочитать, даже если не сдаёте экзамен. Потому что язык управления проектами меняется: от «закрыть задачу» к «создать ценность» и от «уложиться в срок» к «управлять инвестициями».

Вывод, если по-честному
PMBOK 8 — это не просто обновление стандарта. Это смена парадигмы: проект — это не временная задача, а инвестиция, которая должна окупиться. Если вы раньше планировали по принципу «уложимся в срок», теперь вопрос другой: «а какую ценность мы создаём?». Начните с малого: возьмите текущий проект и попробуйте оценить его через VBS — по ценности, а не по трудозатратам. Удивитесь, как изменится взгляд.

#менеджмент #РП #проектная_команда #аналитика #PMBOK #PMP

🛤 Критический путь: самый длинный путь в проекте определяет срок

Знакомая ситуация: команда работает, все заняты, задачи закрываются одна за другой. А срок всё равно срывается.

Причина чаще всего одна — кто-то считал длительность по самым длинным цепочкам зависимостей, а кто-то — по самым коротким. Правда, как обычно, ближе к длинным.

Критический путь — это цепочка задач, которая определяет минимально возможную длительность проекта.

Если хотя бы одна задача на нём задерживается — сдвигается весь срок! Не «может сдвинуться». Сдвигается. Без вариантов.

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

Звучит просто. Но в реальном проекте с сотней задач и десятком зависимостей путь не найти глазом. А ошибки делают по одному и тому же сценарию.

Где кроются ошибки
Считаем срок задач по отдельности. Задача «А» — 3 дня, «Б» — 5 дней. Но «Б» не начнётся, пока не закончится «А». Реальный срок — 8 дней, а не «в среднем 4». Знакомо?

Игнорируем зависимости. Тестирование ждёт разработки, разработка — аналитики, аналитика — согласования с заказчиком. Каждое ожидание — это время. Оно не исчезает, потому что «мы же не сидим сложа руки».

Считаем по «нормальному» сценарию. Нормальный — это когда никто не заболел, ничего не переделали, все отвечали быстро. В реальности на каждый этап добавляется правка и уточнение. В критическом пути 10 задач — значит, 10 точек, где всё может пойти не так.

Как находить критический путь
Метод простой, но требует дисциплины.
Шаг 1. Список задач. Не «примерный», а конкретный: оценка длительности плюс зависимости.
Шаг 2. Определяем зависимости: что должно завершиться до начала каждой задачи.
Шаг 3. Строим сетевую диаграмму: задачи — узлы, зависимости — стрелки. Сразу видно, какие цепочки длиннее.
Шаг 4. Считаем ранние и поздние сроки: от начала — когда задача может стартовать не раньше, от конца — не позже, чтобы не сдвинуть итог.
Шаг 5. Находим резерв — разницу между поздним и ранним стартом. На критическом пути резерва нет. Ни минуты.

Как управлять критическим путём
Найти — полдела. Удержать — вторая половина.
Визуализируйте. Путь должен быть виден всей команде, а не лежать в таблице в папке «проектные документы». Когда цепочка на виду, проще объяснить, почему «ещё недельку» на одной задаче ломает весь план.
Контролируйте входы и выходы. У каждой задачи на критическом пути — чёткий критерий завершения. Не «вроде сделали», а «передано, принято, подписано». Мутные границы — главный источник задержек.
Планируйте ресурсы заранее. Если критический ресурс загружен двумя проектами — конфликт не «если», а «когда».
Пересматривайте регулярно. Путь может смениться: задача на «второстепенном» пути задержалась — и вот она уже на критическом. Считали путь только на старте — управляете прошлым.

Честно говоря, критический путь — это не методология ради методологии. Это способ сказать заказчику не «постараемся», а «вот конкретная цепочка, которая определяет ваш срок. Ускорим задачу X на 2 дня — проект готов на 2 дня раньше. Задача Y задержится на 3 — сдвинется и срок». Математика, а не обещания.

И ещё он объясняет, почему «просто добавить людей» не всегда помогает. Задаче на критическом пути нужно 10 дней — десять человек за день её не сделают. Закон Брука в действии.

Начните с малого: возьмите текущий проект, выпишите 5-7 ключевых задач и постройте простую цепочку зависимостей. Увидите свой критический путь. Возможно, он вас удивит.

📌 Дайджест «Школы проектного специалиста» за прошлую неделю

За неделю — о том, как управлять результатом, а не видимостью работы: от декомпозиции проекта и границ ответственности до критического взгляда на Agile и метрики гибридных команд.

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

Как NASA управляла проектом «Аполлон» без Jira
Почему история о «400 тысячах человек без Agile и Jira» не доказывает превосходство старых подходов — и чему на самом деле может научить управление программой «Аполлон».

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

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

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

#управлениепроектами #Agile #удаленнаяработа #команда #WBS #проектныйменеджмент

📌 Дайджест «Школы менеджера организации» за неделю

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

🔹7 элементов, которые решают судьбу вашей стратегии (подкаст)
О модели McKinsey 7S и о том, почему стратегия работает только тогда, когда согласованы структура, системы, люди и ценности.
🔹«Ловушка успеха»: как прошлые достижения становятся барьером для развития
Про компании, которые продолжают опираться на старые сильные стороны, хотя рынок уже изменился.
🔹Вам кажется, что у вас есть преимущество? VRIO-анализ честно покажет, где вы себе льстите
О том, как VRIO помогает проверить, есть ли у бизнеса реальное конкурентное преимущество.
🔹Встреча ради встречи: хобби или вредительство?
Разбор бесполезных совещаний и того, как считать их реальную стоимость для компании.
🔹В видео разбираем, как эффективно управлять удалёнными и гибридными командами без избыточного контроля и потери продуктивности.
Короткий материал о том, как выстраивать управление на расстоянии без микроконтроля.
🔹Логика в менеджменте: умозаключения и качество управленческих выводов
Про дедукцию, индукцию, когнитивные искажения и инструменты проверки управленческих гипотез.
🔹Remote-менеджмент: как управлять командой на расстоянии
О том, почему удалёнка ломает привычный контроль по присутствию и требует управления по результату.
🔹«Мы свою часть сделали»: фраза, после которой стоит проверить процессы
Про размытую ответственность и то, как она приводит к сбоям между отделами.

#менеджмент #стратегия #удаленка #управлениекомандой #организация #проектныйменеджмент

Почему «клиент всегда прав» — красивая фраза, которая ломает и команду, и продукт.

Эта фраза звучит как аксиома: красиво, логично, и спорить как-то неловко. Клиент платит — значит, прав. Или нет?

На практике эта фраза превращается в кое-что странное. Сотрудники начинают соглашаться с любым требованием. Даже если требование абсурдное. Даже если оно противоречит здравому смыслу. Даже если оно ломает продукт. Потому что «клиент же прав».

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

Самое обидное, что настоящая забота о клиенте — это как раз не всегда соглашаться. Иногда сказать «нет, это вам навредит» — вот это и есть профессионализм. Потому что «да» на абсурдный запрос сегодня — это разрушенный продукт завтра. И тогда клиент уйдёт не потому что ему отказали, а потому что его желание выполнено, а результат — ноль.

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

Может, формула «клиент всегда прав» устарела. Может, стоит заменить на «клиент всегда важен». Потому что важный клиент — это тот, с кем договариваются. А правый клиент — тот, кому подчиняются. Это разные вещи.

Парк юрского периода — компания, которая выросла на старых процессах и рискует вымереть

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

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

Вот и у компании-динозавра своя «температура». Тот самый уклад, который был идеален вчера. Согласования в три круга, отчётность для отчётности, иерархия ради иерархии. Внутри этой температуры всё растёт и развивается. А снаружи люди уже живут иначе. Молодые не хотят работать в пятиуровневом подчинении. Клиенты не хотят ждать ответа неделю. Рынок не прощает «мы всегда так делали».

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

Адаптация — штука медленная. Вот в чём проблема. Менять процесс — это месяцы. Привыкать к новой скорости — полгода. А климат меняется быстрее. И компания, которая всегда гордилась стабильностью, вдруг обнаруживает, что стабильность эта — как у музея. Надёжная, красивая и мёртвая.

Язык ускоряется: почему мы тараторим быстрее бабушек

Ученые из Института русского языка сказали, что мы теперь говорим быстрее, чем наши бабушки с дедушками. И знаете, в чем причина? Гласные стали короче. То есть не то чтобы мы специально торопимся, просто сам язык так устроен – система гласных упрощается, а согласных становится больше. Звучит как какая-то математика, но если вдуматься, все логично.

В древнерусском языке гласных было куча. Потом они постепенно исчезали, и вот сейчас их осталось мало. Дальше сокращать уже некуда, поэтому начали меняться сами звуки – они стали короче. Отсюда и скорость речи. Часто слышишь от старого поколения: «Куда ты тараторишь, ничего не понятно!» А нам кажется, что говорим нормально. Оказывается, это не характер, а фонетика. Ну, отчасти.

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

Но есть в этом что-то грустное. Бабушкино «слишком быстро» – это ведь не просто слова. Это целый разрыв между поколениями. Мы торопимся, глотаем звуки, а они помнят другую музыку речи. И эту музыку уже не вернуть, как ни старайся. Язык не спрашивает разрешения, он просто меняется. А мы просто говорим. Быстрее, чем раньше. И даже не замечаем.

Экспертное мышление — это не талант, а набор рабочих привычек

В McKinsey и других консалтинговых компаниях людей учат не просто «много анализировать», а быстро превращать сложность в понятное решение.
Структурировать проблему. Начинать с вывода. Отвечать за результат. Искать главное по принципу 80/20. Постоянно задавать себе вопрос «И что из этого следует?». И проверять гипотезы вместо того, чтобы собирать данные «на всякий случай».

Собрал в инфографике 6 привычек экспертного мышления в подходе McKinsey.

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

Памятка менеджеру: как гарантированно завалить простой проект

Сохрани себе. Особенно если хочешь однажды посмотреть на команду и спросить:
«А почему мы опять не успели?»

1. Объяви дедлайн
Поставь дату в таск-трекере. Лучше красным.
Неважно, верит ли в неё команда. Неважно, обсуждали ли вы ресурсы, зависимости и реальные ограничения. Главное — чтобы дата была. Дата создаёт ощущение контроля.
Если задача просрочена, просто перекрась её в более тревожный оттенок. В какой-то момент красный цвет перестанут замечать, но это уже не твоя проблема.
2. Соглашайся на все «маленькие дополнения»
«Давайте просто добавим ещё одну фичу».
Соглашайся. Ты же не хочешь выглядеть человеком, который мешает бизнесу.
Потом выяснится, что кнопке нужен новый сценарий, сценарию — отдельная логика, логике — ещё три согласования, а всё вместе необходимо срочно протестировать до пятницы.
Но не переживай. Формально это всё ещё одна маленькая доработка.
3. Не сообщай о проблемах слишком рано
Разработчик заметил, что решение разваливается? Отлично.
Пусть сначала попробует разобраться сам. Потом обсудит с коллегой. Потом вы подождёте ещё пару дней — вдруг действительно само рассосётся.
Заказчику сообщи, когда проблема станет достаточно крупной, чтобы её уже нельзя было скрыть за словами «есть небольшой нюанс».
Именно так формируется доверие.
4. Разработай идеальную методологию
Проведи несколько встреч.
Создай красивую презентацию. Добавь матрицу ответственности, дорожную карту, цветные статусы и, если останутся силы, отдельный слайд про прозрачность.
Не проверяй, пользуется ли этим кто-нибудь в реальной работе.
Живой процесс, который команда действительно соблюдает, — это слишком просто. Настоящий менеджмент должен быть сложным, желательно настолько, чтобы его нельзя было применить без специального совещания.
5. После провала напиши разбор
Подробно.
С причинами, выводами, ответственными и мерами по улучшению. Отдельно укажи, что в следующий раз необходимо «усилить коммуникацию».
Положи документ в папку с названием вроде Postmortem_Final_v7.
Перед следующим проектом не открывай.
Если кто-нибудь спросит, учли ли вы прошлый опыт, уверенно ответь:
«Да, конечно. Мы провели работу над ошибками».
Это универсальная фраза. Она звучит убедительно и не требует доказательств.
Главное правило
Не пытайся сделать проект предсказуемым.
Предсказуемость лишает менеджера возможности героически спасать ситуацию в последний момент. А без этого зачем вообще нужны дедлайны, статусы и экстренные созвоны?

P.S. Если ваша команда узнаёт себя в этой памятке — не спешите проводить ретроспективу. Сначала убедитесь, что кто-то потом действительно её прочитает.