Управление производством и проектами

Теория ограничений Голдратта и проектное управление. Что за диагональный буфер?

2023-03-20 17:37 Управление проектами
Диагональный буфер — это часть решения по управлению проектами в Теории ограничений Голдратта (ТОС). Это только часть решения, части проблем. Решения не бывают хорошими или плохими вне контекста. Если вы не читали мою первую заметку, то я рекомендую начать с неё. В ней я описываю проблему, которую решает диагональный буфер, время прочтения — шесть минут. Спойлер — срок задачи в проекте не работает.
Решение ТОС для проектного управления называется «метод Критической цепи». Отличается он от «метода Критического пути» тем, что мы уходим от срока задачи.
Диагональный буфер — это инструмент приоритизации. Если у нас не будет сроков задач, то непонятно как в каждый момент времени ответить на вопросы: мы успеваем, или пора торопиться, или уже пора разговаривать с заказчиком о переносе срока? А если я могу приступить к выполнению нескольких задач из одного, или даже разных проектов, как выбрать, с какой начать?

Пишем подробный план

Мы начинаем с того, что строим обычную диаграмму Ганта. Выписываем задачи и распределяем их в порядке выполнения. Чем подробнее будет ваш план — тем лучше. Что такое подробный план? Если, например, нам нужно написать ТЗ, то нельзя отделаться одной задачей: «Написать ТЗ». И даже если вы добавите «Согласовать ТЗ», — этого тоже будет недостаточно. Подробный: написать ТЗ, показать, доработать, показать, доработать и т. д. Чем лучше такой план? Тем, что задача «Написать ТЗ» будет оценена мной в 2 недели. А набор из 6 мелких задач будет оценён мной в 3.5 дня. Это не значит, что я оставлю себе на это 3.5 дня, но это значит, что дальнейшие мои расчёты будут реалистичнее.

Расставляем исполнителей и трудоёмкости

После того как у нас появился подробный план, мы расставляем исполнителей и трудоёмкости. В решении ТОС подстраховка становится общей, поэтому, когда мы оцениваем трудоёмкость, мы стараемся выкинуть из оценки задачи запасы времени на отвлечения, переключения и всякий случай. Для этого у нас будет общая подстраховка — буфер.
Можно начать с того, что 50% трудоёмкости мы отдаём в буфер. Тогда задача, на которую мы бы раньше заложили в план 10 дней, разделится на задачу трудоёмкостью 5 дней и буфер 5 дней. Можно просто оценить все задачи, а время, которое останется до срока выполнения проекта — заложить в качестве буфера.

Убираем конкуренцию за ресурсы

Следующим шагом — мы убираем конкуренцию за ресурсы. Один и тот же ресурс не может делать одни и те же задачи в одно и то же время. После устранения конкуренции мы выделяем самую длинную цепочку задач — это будет наша критическая цепь. Остальные цепочки мы будем называть питающими.
В примере ниже, после того как мы выстроили Гант проекта и расставили ресурсы (A, B, C и D) и трудоёмкости, у нас создалась конкуренция за ресурс B. Мы устранили её, изменив последовательность выполнения задач. В итоге, у нас получилась критическая цепь длиной в 45 дней и две питающих — длиной в 10 дней каждая.

Добавляем буферы

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

Диагональный буфер

Диагональный буфер — это графическое представление того, сколько работы осталось сделать, и сколько времени и подстраховки у нас на это есть. В начале проекта мы «рисуем» буфер и в дальнейшем постоянно актуализируем, в какой части буфера мы сейчас находимся.

Рисуем буфер

Диагональный буфер — это график, с выделенными цветными зонами. Если у нас в проекте три буфера: буфер проекта и два питающих, то мы строим три буфера. Для каждого отмечаем свою длину цепочки и размер самого буфера.
По оси X мы будем откладывать процент выполнения цепи (критической или питающей), по Y — мы будем откладывать процент проникновения в буфер. В любой момент текущий статус проекта отображается точкой с координатами (текущий процент выполнения проекта; текущий процент проникновения в буфер).
В начале выполнения проекта мы находимся в точке (0;0). Если мы ничего не будем делать, то будем тратить буфер и двигаться вверх по оси OY. Если будем выполнять задачи за время трудоёмкости, то будем двигаться по оси OX.
В зависимости от цвета зоны, в которую попала точка, мы считаем, что всё отлично (зелёная зона), всё нормально (жёлтая зона), либо мы в критической зоне (красная зона). Выше красной зоны начинается чёрная. Чёрная зона соответствует проникновению в буфер больше ста процентов. Это значит, что несмотря на то, что проект ещё не закончен, мы уже опаздываем.
Если мы «съедим» половину буфера в начале проекта, то это довольно плохо, ещё много работы впереди и многое может пойти не так. Если мы в конце проекта использовали всего лишь половину буфера, то это отлично. Мы точно успеем. Чтобы отразить это различие, границы зон проходят под наклоном.
Угол наклона и процент проникновения, с которого начинается и заканчивается зона, можно определить самостоятельно. По умолчанию, можно начать с жёлтой зоны, начинающейся в 5% и заканчивающейся в 45%, красной зоны, начинающейся в 55% и заканчивающейся в 95%. В дальнейшем можно переопределять границы в зависимости от того, в какой момент проекта у вас больше неопределённости.

Определяем текущее положение

По оси ОX мы отмечаем процесс завершения цепи. Важный момент: мы оцениваем не количество выполненной работы, а количество оставшейся работы. Мы спрашиваем «Сколько осталось?», а не «Сколько уже было выполнено?». Чтобы определить координату X, мы отнимаем от длины цепи «осталось» и делим на длину цепи.
По оси ОY отмечаем процент проникновения в буфер. Для этого мы складываем «Сколько осталось» и «Сколько времени уже прошло», отнимаем от этого длину цепи и получаем проникновение в буфер.
Для примера посмотрим, как будет выглядеть расчёт для проекта длиной в 60 дней. Длина цепи составляет 45 дней, в буфер мы заложили 15 дней. Уже прошло 20 дней проекта, а работы осталось на 30 дней.
Теперь отметим текущее состояние проекта на дигональном буфере. Мы попадём в жёлтую зону.
В каждый момент времени для каждой задачи каждого проекта мы можем определить её приоритет и принять решение о том, какую задачу нужно делать вперёд и нужны ли какие-то корректирующие или спасательные действия. Жёлтые нужно делать вперёд зелёных, а красные нужно начинать спасать или, как минимум, держать руку на пульсе.
Причём мы можем понять это ещё на первоначальных этапах проекта, а не в тот момент, когда уже опоздали.

Динамика выполнения проекта

В процессе выполнения проекта мы можем отмечать текущее соотношение «Осталось работы» и «Съедено буфера». В дальнейшем эту информацию можно использовать для понимания слабых зон как планирования, так и исполнения проектов.
  • В точке А мы сделали часть работы и «съели» часть буфера;
  • В точке B мы сделали часть работы ровно за трудоёмкость;
  • В точке C мы оказались в красной зоне и поняли, что нужно «спасать» проект;
  • В точке D мы выполнили работу даже быстрее, чем планировали, и вернули немного времени в буфер;
  • В точке E мы поняли, что поторопились, и теперь нам нужно сделать больше, чем мы планировали.

Решение TOC для управления проектами

Диагональный буфер — это всего лишь инструмент. Само решение для управление проектами включает в себя больше изменений, чем просто отказаться от сроков задач и начать рисовать буферы. Самое первое обязательное изменение (инъекция):
Выполнение обязательств по срокам проектов — первичный показатель управления проектной средой
Это значит, что мы берём в качестве базового принципа принятия решений — срок проекта превыше всего (в рамках разумного и трудового кодекса).
Казалось бы, это и так самом собой разумеется. Но нет!) Во многих компаниях срыв срока воспринимается как неминуемое зло. И клиентами, и сотрудниками. Без этого изменения нет большого смысла играться с буфером.
Если вам интересно больше узнать про решение ТОС для проектной среды, вы можете почитать книгу «Основы ТОС» Оуэн, Федурко, «TOC Handbook» и «Критическая цепь» Голдратта. Первые две книги — учебники, последняя — бизнес-роман.

Полезные материалы

01/ Теория ограничений и проектное управление. Что не так со сроком задачи? [почитать]
02/ Почему мы продолжаем срывать сроки проектов [посмотреть]
03/ Что такое эффективность? [почитать] [посмотреть]
04/ У вас нет выбора. Либо вы управляете ограничением, либо оно управляет вами [почитать]
05/ Теория ограничений — это серебряная пуля? [почитать]
06/ Если это решение, то в чем проблема? Шесть слоев сопротивления изменениям [почитать]
07/ Почему ваши очевидно эффективные идеи отвергаются (вероятно, дело в вас) [почитать] [посмотреть]
Мой телеграм-канал, где я оповещаю о новых заметках и делюсь короткими инсайтами и мыслями, которые не попадают сюда. Ещё там можно обсуждать идеи и смотреть на ТОС с разных сторон вместе с другими