Что такое буфер проекта и как его использовать менеджеру
Поможем определить, когда закончится проект и достаточно ли ресурсов для завершения в срок
Реализация проекта требует ответа на множество вопросов. Пожалуй, два самых важных — это: «Когда закончится проект?» и «Достаточно ли ресурсов для завершения проекта в срок?» Попробуем ответить на эти вопросы с помощью управления буфером проекта и рассмотрим этот метод на примере.
Что такое буфер проекта
Буфер проекта в качестве метода управления описан в книге Элии Голдратта «Критическая цепь», как инструмент, который позволяет уменьшить перестраховку, заложенную в каждую отдельную задачу и тем самым ускорить выполнение проекта.
Основная причина появления перестраховки — неопределённость. Там где время выполнения задачи нельзя оценить точно, исполнитель хочет подстраховаться, чтобы иметь запас времени в случае возникновения проблем. В разработке программного обеспечения мне приходилось слышать такую рекомендацию: «Возьмите свою первоначальную оценку и умножьте её на Пи». Но, это означает перестраховку в 3 раза, если первоначальная оценка была достаточно точна! Кроме того перестраховка зачастую закладывается в каждую задачу не смотря на то, что проблемы возникнут далеко не каждой из них, а какие-то будут выполнены даже быстрее первоначальной оценки.
Проблема подобных оценок в том, что они превращаются в самореализующиеся предсказания. Вот три механизма разбазаривания подстраховки, о которых пишет Голдратт:
- Студенческий синдром: спешить некуда, поэтому начинаем в последнюю минуту.
- Перепрыгивание от задания к заданию, при котором время выполнения каждой задачи увеличивается.
- Зависимость между элементами, которые вызывают накопление опозданий и потерю выигрышей по времени.
Это очередная иллюстрация закона Паркинсона: “Работа занимает всё отведённое ей время”
Управление с помощью буфера проекта предлагает не использовать перестраховку для каждой задачи, а создать резервный запас времени для всего проекта в целом. Расход буфера позволяет быстро оценить состояние проекта и вовремя принять меры для устранения проблем.
Fever Chart
Управление с помощью критической цепи (Critical Chain Project Management — CCPM), в основе которого лежит теория ограничений Голдратта, предлагает использовать Fever Chart для определения текущего статуса проекта.
По горизонтальной оси отложен процент выполнения проекта, а по вертикальной процент расхода буфера. Черный график показывает как развивался проект с течением времени. Фон разделён на три разноцветные области и нахождение графика в каждой из них даёт определённый сигнал для менеджера проекта.
Зелёная зона – Ожидаемое отклонение (Expected Variation) – “Всё идёт по плану!” Зелёная зона поглощает предсказуемую (свойственную задачам предметной области) неопределённость. Не требуется никаких специальных действий. Если весь график до окончания проекта находится в этой зоне, фактически можно говорить о том, что сложность задач оказалась переоценённой, а размер буфера слишком большим
Жёлтая зона – Нормальное отклонение (Normal Variation) – Всё под контролем, но надо подготовиться к возможным действиям, в случае если график перейдёт в красную зону. Жёлтая зона поглощает неопределённость связанную с оценкой времени на выполнение задач. Необходимо понимать, что вызывает дополнительные затраты времени и подготовиться к устранению причин задержки.
Красная зона – Аномальное отклонение (Abnormal Variation) – В этой зоне необходимо действовать. Реализуйте планы подготовленные в тот момент, когда график расхода буфера находился в жёлтой зоне. Скорее всего график попал в эту зону из-за не предусмотренного при планировании проекта события.
Использование буфера проекта в Канбан
Использование Kanban для управления проектами не предполагает оценку каждой задачи. Да и наличие этой оценки не позволяет оценить время окончания проекта, поскольку задачи могут выполняться параллельно. Потому для оценки времени окончания проекта мы будем использовать простую и доступную метрику – пропускную способность.
Её действительно просто получить, просто взглянув на то, сколько задач дошли до поставки за неделю. Канбан предполагает использовать статистическую информацию для прогнозирования, поэтому лучше всего использовать реальные данные команды, которая работает на проекте. Стоит отметить, что по мере выполнения проекта мы будем корректировать это значение.
Предположим, что пропускная способность нашей команды 10 задач в неделю (возьмём среднее значение за последние 4 недели), а наш новый проект содержит 90 задач. Очевидно, что самый наивный подход говорит о том, что для реализации проекта нам потребуется 90 / 10 = 9 недель.
Есть несколько подходов для выбора размера проектного буфера, но они выходят за рамки данной статьи. В качестве примера возьмём в качестве буфера треть времени, необходимого для реализации проекта – то есть ещё 3 недели.
С практической точки зрения это означает, что мы планируем выполнить проект за 9 недель, если не произойдёт ничего неожиданного, но заказчику мы называем срок в 12 недель.
Пример расчёта
Рассмотрим на примере, как рассчитать размер оставшегося буфера по прошествии первой недели. Наша команда только втягивается в новый для неё проект и поэтому вместо ожидаемых 10 задач (средняя пропускная способность на момент начала проекта), выполняет лишь 7.
Средняя пропускная способность уменьшается до 9.25 задач в неделю. Напомню, что это значение мы подсчитываем на основании данных за последние 4 недели – (10 + 10 + 10 + 7) / 4 = 9.25
Посчитаем сколько времени потребуется на реализацию оставшихся задач. Разделив число оставшихся задач на текущее значение средней пропускной способности – 83 / 9.25 = 8.97. Нам по прежнему нужно 9 недель для завершения проекта! Это влияние медленного старта.
Посчитаем размер оставшегося буфера. 12 недель – продложительность проекта (9 недель согласно пропускной способности + 3 недели буфера).
12 — 1 (1 неделя прошла с начала проекта) — 8.97 (текущее время до завершения проекта) = 2.03
От буфер осталось чуть больше 2 недель, а значение израсходованного буфера в процентах вычисляется, как 2.03 / 3 * 100% = 32.43%
С точки зрения прогресса мы выполнили 7 / 90 * 100% = 7.78% проекта.
Таким образом мы вычислили первую точку (7.78, 32.43) графика, который вы можете увидеть ниже. Точка находится в жёлтой зоне и потому нам стоит предусмотреть действия на случай если пропускная способность команды не изменится.
Посмотрим на все данные расчёта и посмотрим, в результате каких событий мы получили такой график
Постепенно команда вошла в привычную колею, её пропускная способность вернулась к 10 задачам в неделю и график вернулся из красной зоны в жёлтую.
На шестой неделе в проект добавили 10 новых задач, но даже это не стало критичным, расход буфера говорил о том, что проект не выходит за рамки установленных сроков.
Попытка добавить ещё одну порцию задач на восьмой неделе привела к резкому росту рисков, что проект не будет сдан в срок. Судя потому, что на следующей неделе 5 задач были исключены из списка работ, менеджмент отказался от части требований, чтобы не нарушать взятых обязательств.
На последней неделе, отмеченной на графике, у нас выполнено 86.11% проекта и буфер истрачен на 87.39%. Значение средней пропускной способности говорит о том, что для реализации проекта, нам нужно чуть больше полутора недель и скорее всего команда уложится в 12 недель, которые она назвала заказчику в качестве предполагаемого срока завершения проекта.
Интересные статьи
Viacheslav Tsyrulnik
Viacheslav Tsyrulnik
Viacheslav Tsyrulnik
Прогрессивные компании уже управляют своими проектами в Kaiten. Присоединяйтесь к лучшим.
