Завершение проекта позже обозначенного срока — это стандартное ожидание во многих отраслях. По данным Project Management Institute, только 47% проектов заканчиваются вовремя и в рамках бюджета. При этом большинство компаний реагируют на задержки одним способом — добавлением ресурсов: нанимают больше людей, вводят сверхурочные, покупают дополнительное оборудование. В результате, как правило, происходит рост затрат без пропорционального ускорения. Почему так происходит, объясняет Теория ограничений.
Важно понимать контекст: большинство организаций не осознают, что их проблема является системной, а не исполнительской. Когда проект опаздывает, первая реакция состоит в поиске виновного: кто не сдал вовремя, кто недооценил задачу, кто плохо коммуницировал. Теория ограничений предлагает принципиально другую оптику: задержка является симптомом системной дисфункции, а не результатом чьей-то некомпетентности, и найти и устранить ограничение системы важнее, чем найти виновного.
Что ТОС говорит о проектах
В классическом применении ТОС к производственным системам ограничение — это одна операция, которая определяет пропускную способность всей цепочки. В проектном управлении логика та же, но ограничение найти труднее: оно не стоит неподвижно на одном месте, а перемещается от задачи к задаче по мере выполнения работ.
Элияху Голдратт разработал для проектов отдельный метод — Критическую цепь (Critical Chain). Он отличается от классического критического пути (CPM) в двух ключевых аспектах. Во-первых, он учитывает конкуренцию за ресурсы между задачами, а не только зависимости между работами. А во-вторых, управляет буферами времени принципиально иначе: вместо того чтобы закладывать резерв для выполнения каждой задачи, консолидирует его в несколько управляемых буферов.
Разница между критическим путем и критической цепью важна на практике. CPM отвечает на вопрос: «Какая последовательность задач самая длинная?». Critical Chain отвечает на другой вопрос: «Какая последовательность задач самая длинная с учетом того, что одни и те же люди нужны в разных местах одновременно?». Это более реалистичная модель реального проекта.
Почему традиционные буферы не работают
Когда менеджер проекта запрашивает время на задачу, он, как правило, добавляет к реалистичной оценке 50–100% на случай непредвиденных обстоятельств. С точки зрения исполнителя это, безусловно, является рациональным поведением, поскольку в случае, если задача займет больше времени, чем запланировано, именно он будет нести ответственность за задержку.
Но у этой практики есть три системных последствия. Во-первых, закон Паркинсона: работа занимает все отведенное время. Т.е. если на задачу дано две недели, она займет ровно столько времени, даже если реально его нужно гораздо меньше. Это не лень и не злой умысел: человек использует дополнительное время на доработку, перепроверку, улучшение. Проблема в том, что эта доработка редко влияет на итоговый результат.
Второе — синдром студента: исполнитель откладывает начало работы до последнего момента, потому что еще есть время в запасе. К дедлайну он оказывается в ситуации, когда буфер уже потрачен на прокрастинацию, а не на реальную работу. Третье — проблема слияния: даже если задача завершена досрочно, ранний финиш редко передается следующей задаче, а вот позднее завершение передается всегда. Буферы тают, а общий срок проекта при этом не сокращается.
Это не теоретическая конструкция, ведь любой менеджер проектов, поработавший несколько лет, может вспомнить десятки случаев, когда задача была готова раньше срока, но никто не заметил, потому что следующий исполнитель еще не освободился. Или, к примеру, задача опоздала на день, и это опоздание прошло по всей цепочке до финального дедлайна. Асимметрия передачи задержек — один из главных механизмов, по которым опаздывают проекты.
Критическая цепь: как работает метод
В методе Критической цепи исполнители дают более жесткие и ограниченные сроки, примерно 50% от привычного. Затем высвобожденные резервы собираются в три типа буферов: проектный буфер (защищает дату завершения всего проекта), питающие буферы (защищают критическую цепь от задержек в параллельных ветках) и ресурсный буфер (предупреждение ресурсу, что он скоро понадобится).
Управление ведется по потреблению буфера, а не по прогрессу задач. Если проект прошел 40% работ, а буфер потреблен на 20%, то все в порядке. Но если он потреблен на 60%, то нужно вмешательство. Этот подход снимает с руководителя задачу отслеживать каждую задачу вручную, поскольку детальный контроль заменяет светофор из трех зон.
Зеленая зона, когда буфер потреблен менее чем на треть, проект идет хорошо, и вмешательство не нужно. Желтая зона — буфер потреблен на треть-две трети, ситуация требует внимания и планирования контрмер. Красная зона — буфер потреблен более чем на две трети, и необходимо немедленное вмешательство руководителя. Главное достоинство этой системы в ее простоте: менеджер видит состояние всего портфеля проектов на одном экране.
Для исполнителя правило одно: работать над задачей с максимальной скоростью, как только она доступна, и немедленно передавать результат следующему. Не ждать своего срока выполнения задачи по графику, а передавать ее дальше, как только она готова. Это единственное поведенческое изменение, но оно требует перестройки культуры: люди привыкли работать по плановым датам, а не по реальной готовности.
Кейс: производственная компания, 9 параллельных проектов
В 2024 году мы работали с производственным предприятием, которое вело разработку новых продуктов: девять проектов одновременно, команда из 23 специалистов. Средняя задержка по завершенным проектам составляла 4,2 месяца при плановом сроке 8–10 месяцев. Основная жалоба была в том, что работники перегружены, но проекты все равно опаздывают.
Диагностика показала классическую картину многозадачности. Каждый специалист работал над 3–5 проектами одновременно, и переключение между ними занимало, по нашим замерам, 15–20% рабочего времени. Но главная проблема была не в переключении, а в расстановке приоритетов: без четкого порядка приоритетов каждый сотрудник делал то, что казалось важным ему, а не то, что было важно для системы в целом. В результате все проекты двигались со скоростью черепахи, а не один — быстро, другой — медленно.
Первым шагом стало сокращение числа активных проектов, которые выполняются одновременно, с девяти до пяти. Это решение вызвало сопротивление у руководства, им казалось, что они теряют время на четыре проекта. Однако, на практике произошло обратное: потоковая скорость оставшихся пяти проектов выросла настолько, что все пять были завершены раньше, чем ранее завершались девять. Через шесть месяцев в работе уже было снова девять проектов, но теперь они шли через систему последовательно, а не параллельно.
Вторым шагом стало внедрение принципа «передавай, как только готово». Для этого потребовалось изменить систему оценки работы: раньше исполнителей оценивали по соблюдению индивидуальных дедлайнов, а теперь по скорости передачи работы следующему звену. Первые два месяца были сложными? Поскольку люди не доверяли новой системе, но к четвертому месяцу средний цикл проекта сократился с 9,5 до 6,8 месяцев. Затраты за тот же период выросли менее чем на 3%, фактически в рамках инфляции, и никаких дополнительных ресурсов не добавлялось.
Ограничения метода
Критическая цепь работает хорошо там, где проекты относительно предсказуемы по структуре работ, а ресурсы определены. В исследовательских проектах с высокой неопределенностью (когда неизвестно что делать и сколько это времени займет) метод применять сложнее. Он предполагает, что можно отделить реалистичные оценки от тех, которые делаются с запасом, а при высокой неопределенности эта граница размыта. В таких случаях лучше работает итеративный подход (Agile или его гибриды) в комбинации с ТОС на уровне портфеля.
Второе ограничение — культурное. Метод требует, чтобы люди отказались от защитных буферов в индивидуальных задачах. Для этого нужно доверие к системе, ведь сотрудник должен верить, что проектный буфер его защитит и что его не накажут, если оценка будет занижена по времени, и он не сможет ее выполнить. Без этого доверия метод разваливается в первые недели: люди формально дают короткие оценки, но неформально все равно планируют по-старому.
Ломать это недоверие нужно конкретными действиями руководителя. Первое важное решение — не наказывать за «красную зону», если она возникла по объективным причинам. Система буферов работает именно потому, что красная зона — это нормальная ситуация, требующая внимания, а не чрезвычайное происшествие, требующее виноватого.
Когда применять
Опыт показывает, что ТОС-подход к проектам наиболее ценно в трех ситуациях:
- когда проектов много, и они конкурируют за одни ресурсы;
- когда задержки носят системный характер, а не являются исключением;
- когда добавление ресурсов не решало проблему раньше.
Первый из этих признаков (конкуренция за ресурсы) является самым простым для диагностики. Если один и тот же специалист числится в трех проектах и его загруженность составляет 120%, система управления проектами не справляется не потому что люди плохо работают, а потому что система создает эту перегрузку. Критическая цепь в такой ситуации не просто оптимизирует расписание, она делает видимой реальную загрузку ресурсов и заставляет принять решение о приоритетах.
В конечном счете, ТОС — это не набор инструментов, а способ думать о системе. Главный вопрос, который он ставит перед руководителем: «Что мешает этой системе работать быстрее прямо сейчас?» Ответ на этот вопрос и есть ограничение. Найти его, усилить, подчинить остальное, а затем повторить. Эта логика применима к проектам так же, как к производству, логистике или продажам.