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