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

Диагональный буфер — это часть решения по управлению проектами в Теории Ограничений Голдратта (ТОС). Это только часть решения, части проблем. Решения не бывают хорошими или плохими вне контекста. Если вы не читали мою первую статью, то я рекомендую начать с неё. В ней я описываю проблему, которую решает диагональный буфер, время прочтения — шесть минут. Спойлер — срок задачи в проекте не работает.

Решение ТОС для проектного управления называется метод Критической цепи. Отличается от метода Критического пути тем, что мы уходим от срока задачи.

Диагональный буфер — это инструмент приоритизации. Если у нас не будет сроков задач, то непонятно как в каждый момент времени ответить на вопросы: мы успеваем, или пора торопиться, или уже пора разговаривать с заказчиком о переносе срока? А если я могу приступить к выполнению нескольких задач из одного, или даже разных проектов, как выбрать, с какой начать?

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

Мы начинаем с того, что строим обычную диаграмму Ганта. Выписываем задачи и распределяем их в порядке выполнения. Чем подробнее будет ваш план, тем лучше. Что такое подробный план? Если, например, нам нужно написать ТЗ, то нельзя отделаться одной задачей: «Написать ТЗ«. И даже если вы добавите «Согласовать ТЗ», этого тоже будет недостаточно. Подробный: написать ТЗ, показать, доработать, показать, доработать и т. д. Чем лучше такой план? Тем что задача «написать ТЗ» будет оценена мной в 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», и «Критическая цепь» Голдратта. Первые две книги - учебники, последняя - бизнес роман.

Заинтересовало — подписывайтесь, в следующих заметках я расскажу особенности применения этого метода в жизни)

P.S. Мой канал в телеграм с уведомлением о новых заметках и короткими заметками, которые я публикую только там (кстати, если вам совсем не терпится, то там можно найти ответ)

P.P.S Мой YouTube канал про Теорию Ограничений и не только. Там есть пару стримов с Максимом Дорофеевым, скоро появятся новые)

P.P.P.S Я люблю сердечки, сердечки — это красиво, и они повышают настроение🥰

4747
14 комментариев

Комментарий недоступен

3

Спасибо! Дано был вопрос о том, как буферами в ТОС управляться.
Книги, на которые Вы ссылаетесь, есть ли ссылки где их можно купить или скачать на русском языке?

1

Основы ТОС раньше распространялись бесплатно. Можно здесь скачать

https://tocpeople.com/wp-content/uploads/2012/10/Osnovy_Teorii_Ogranichenij_Cohen_Fedurko_01-10-2012.pdf?ysclid=lg1433mh42771587922

Многие книги Голдратта доступны в Литрес.

https://www.litres.ru/book/eliyahu-goldratt/kriticheskaya-cep-6377209/

3

Насколько я помню, у Голдрата ничего подобного не было, так как в этом не было никакой нужды. Люди «просто» строили PERT-диаграммы. Если буферы распределялись по задачам, а они всегда были с целью управления рисками, то получался метод критического пути. Если буфер был общий на проект на этап/проект, то получался метод критической цепи. Общий буфер ввели потому, что программисты всегда тратят все отпущенное время, то есть они уничтожают локальные буферы, которых может не хватить в конце.
Более того, подобных упрощений типа «диагонального буфера» никто бы не позволил использовать, потому что есть явления броска критической цепи, когда в начале проекта вы рассчитывали на одну критическую цепь, а в середине проекта у вас образовалась другая критическая цепь. Если у вас не будет PERT-диаграммы, то вы просто пропустите этот момент.
Ну и вряд ли кто-то предложил бы отдать 50% трудоёмкости в буфер. Просто это очень и очень много. Такие объёмные буферы нужны только если проектом вообще не собираются управлять.

1

Вряд ли вас утроит мой ответ, но у Голдратта это было)

2

Спасибо за статью!

1

Спасибо, за спасибо)

1