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

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

Если коротко, ключевые принципы книги такие:

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

Кто реально использовал CCPM

Подход применяли не только в теории:

1) Maasstad Hospital (Роттердам) — сократили средний lead time почти вдвое и увеличили количество завершённых проектов без роста штата.

2) В индустриальных обзорах упоминаются внедрения и использование принципов CCPM в Boeing, Seagate, Tata, NASA, а также кейсы из госсектора (Япония, штат Bihar в Индии).

Но даже без ссылок на чужие успехи — ниже чистая практика, как внедрять это у себя)

✈️ Шаг 0. Выберите пилот

Берите один поток (команда / продуктовый трек / релиз), где есть повторяемость и боль со сроками. Цель пилота — предсказуемость, а не «ускориться любой ценой».

✋Шаг 1. Остановите многозадачность

- WIP-лимит на «В работе» (и отдельно на review/QA, если там пробка), - правило команды: не начинаем новое, пока не протолкнули текущее, - правило для бизнеса: срочное входит только через замену (swap).

Мини-метрика: сколько задач висит без движения больше 3–4 дней.

👯‍♂️Шаг 2. Уберите личные буферы и соберите общий

Оцениваем задачи реалистично, без запаса запас переносим в общий буфер релиза / спринта.

В Scrum это может быть capacity-буфер: 10–20% спринта не планировать под фичи.

🤺Шаг 3. Найдите ограничение и защитите его

Это может быть: - ключевой backend / ML / DevOps, - согласование с безопасностью или архитектором, - дизайн или аналитика как входной шлюз.

Действия: - фиксируем узкое место, - даём ему приоритет и входной лимит, - убираем параллельные «срочники».

🛃 Шаг 4. Контролируйте буфер, а не дедлайны задач

Важно не «кто опоздал», а как мы проедаем общий буфер. Что делаем: - простой буфер-трекер (хоть в Google Sheet), - раз в 2–3 дня: сколько осталось до цели и сколько буфера осталось, - буфер желтеет → меняем план, а не ищем виноватых.

💁‍♂️Шаг 5. Говорите «сколько осталось», а не «% готовности»

Проценты почти всегда врут. На дейли: - не «сделал 80%», - а «осталось 2 дня, блокер — такой-то».

👍Шаг 6. Введите правила для срочных изменений

- окно валидации, - мини-фильтр: ценность / риск / кого выбиваем, - срочное = замена, а не добавка сверху.

Шаг 7. Короткий ритуал управления потоком

15 минут раз в неделю: - где узкое место сейчас, - что в красной зоне по буферу, - какие 1–2 решения возвращают поток.

😵Частые ошибки

- вводят буферы, но не убирают многозадачность; - продолжают мерить успех «все заняты»; - пытаются внедрить сразу на весь портфель.

Для меня «Критическая цепь» — не про методологию, а про спокойную управляемость: меньше героизма, больше системного фокуса и предсказуемого результата :)

p.s. Еще не знаю, в каком формате лучше всего писать посты в Сетке (это мой первый пост), так что если вам понравилось мое саммари и мои мысли, то, пожалуйста, оставьте комментарий, буду рада любой ОС)