{"id":14285,"url":"\/distributions\/14285\/click?bit=1&hash=346f3dd5dee2d88930b559bfe049bf63f032c3f6597a81b363a99361cc92d37d","title":"\u0421\u0442\u0438\u043f\u0435\u043d\u0434\u0438\u044f, \u043a\u043e\u0442\u043e\u0440\u0443\u044e \u043c\u043e\u0436\u043d\u043e \u043f\u043e\u0442\u0440\u0430\u0442\u0438\u0442\u044c \u043d\u0430 \u043e\u0431\u0443\u0447\u0435\u043d\u0438\u0435 \u0438\u043b\u0438 \u043f\u0443\u0442\u0435\u0448\u0435\u0441\u0442\u0432\u0438\u044f","buttonText":"","imageUuid":""}

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

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

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

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

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

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

0
14 комментариев
Написать комментарий...
Аккаунт удален

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

Ответить
Развернуть ветку
Сергей Скарбун

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

Ответить
Развернуть ветку
Александра Брызгалова
Автор

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

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/

Ответить
Развернуть ветку
Константин Митин

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

Ответить
Развернуть ветку
Александра Брызгалова
Автор

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

Ответить
Развернуть ветку
Константин Митин

Если это было у Голдрата, то ведь можно сослаться на конкретную книгу Голдрата, где он именно это и писал. Все же кроме бизнес-романа "Критической цепи" у него есть более серьезные книги типа "Цель", "Цель-2", "Цель-3" и другие.
Мы же с вами сейчас не в ситуации слова одного человека против слова другого человека. Просто сошлитесь на конкретное издание и главу из него.

Ответить
Развернуть ветку
Александра Брызгалова
Автор

Я сослалась. Handbook и основы ТОС. В написании обеих книг принимал участие Одед Коуэн, человек который начал работать с Голдраттом ещё до написания книги Цель и основания института ТОС. Человек, у которого я училась несколько лет.

Ответить
Развернуть ветку
Константин Митин

Вы же согласны с тем, что есть большая разница между "Голдратт сказал/Голдратт написал" и "предположительно сказал один из бывших сотрудников Голдратта"?
Возможно, Одед Коуэн где-то и упоминал диагональный буфер, но тогда нужно указать конкретное место, где он это сделал.
P.S.
И согласитесь, есть разница между рассуждениями о системах человека, который имеет научную степень по физике, и просто выпускника университета. Это отсылка к биографии Голдрата и Коуэна.

Ответить
Развернуть ветку
Александра Брызгалова
Автор

Коуэн был не просто его бывшим сотрудником. Книги я вам привела. Главу без проблем нагуглите сами. Мне не кажется, что у вас есть цель разобраться. А с другими целями я вам помогать не готова)

Ответить
Развернуть ветку
Константин Митин

Это так не работает. Вы же заявили, что дескать вы несколько лет учились у самого Одед Коуэна, который внезапно является одним из руководителей TOC Practitioners Alliance.
Нельзя при таком-то учителе так сильно плавать в материале. в чем проблема сослаться на конкретную главу книги-то? Вы не поверите, но серьезные люди в серьезных текстах указывают даже страницы в книгах, на которые они ссылаются. А тут: "Нагуглите сами", "Ищите сами", "Не нашли, так сами виноваты, плохо искали".
Либо подозреваете, что после указания конкретного места книги проблемы будут лишь увеличиваться? Не потому, что я не хочу разобраться, а как раз наоборот?

Ответить
Развернуть ветку
Александра Брызгалова
Автор

handbook - страница 65. Вы перешли границы уважительного общения, прощайте)

Ответить
Развернуть ветку

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

Развернуть ветку

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

Развернуть ветку
Эльмин Алиев

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

Ответить
Развернуть ветку
Александра Брызгалова
Автор

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

Ответить
Развернуть ветку
Максим Макаров

Хорошо

Ответить
Развернуть ветку

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

Развернуть ветку
11 комментариев
Раскрывать всегда