Вы думали, я вам тут жалуюсь про собес? А вот и нет! Сегодня будет жёсткий ликбез. Поговорим о штуке, которая в реальной жизни IT‑проектов спасает нервы, бюджеты и дедлайны.
ТЕОРИЯ ОГРАНИЧЕНИЙ ГОЛДРАТТА. Да‑да, та самая, из которой вырос критический путь и нормальное понимание, как закладывать буфер времени в проект, чтобы он не поехал в тартарары.
Помните Паркинсоновский закон? А я его помню (не факт что соблюдаю, но помню лет так 14 уже). Светлана Николаевна▪️, мой ex-босс, ещё до того, как это стало мейнстримом, любила говорить, когда мы опять не успевали сделать красивый отчет по ROI по всем каналам за квартал и впопыхах между выставками чуть ли не в самолете рисовали слайды:
“Оля, на задачу уходит ровно столько времени, сколько на нее отведено. Дай задачу на неделю – сделают за неделю. Дай на день – сделают за день. Дай на год – будут делать год. И всё равно в последний день.”
И вот в этом и кроется корень проблемы любого проекта. Даже если ты раздашь всем запасы по максимуму, проект всё равно опоздает.👉👉👉 Что такое студенческий синдром: это когда исполнитель не начинает задачу сразу, потому что “времени ещё полно”. А потом в последний момент наступает “припёрло, делаем в аврале”. И если случится малейшая проблема – привет, задержка проекта.
Голдратт сказал: “Не давайте людям лишнего времени. Они всё равно начнут в последний момент.”
▪️▪️▪️Как правильно закладывать буфер времени: классика VS Голдратт Классика (PERT/CPM): Каждая задача имеет “реальную оценку” + “личный запас исполнителя”. Эти запасы сгорают в прокрастинации и багфиксе → итог: проект всё равно опоздал.
Голдратт: ✏️Найди критическую цепочку (учитывая ресурсы). ✏️Сократи оценки задач до 50% (убери индивидуальные запасы). ✏️Разницу собери в проектный буфер в конце цепочки. ✏️Добавь feeding buffers на все точки слияний.
Всё. Теперь у тебя буфер в одном месте, а не размазанный по всему проекту.
▪️Feeding buffers ???!!! Как это и что?)
Представь у тебя в проекте есть некритические задачи, которые вливаются в критическую цепь. Например: разработка фичи идёт на критической цепи, а подготовка документации идёт параллельно, но всё равно нужна перед релизом. Вот чтобы задержка по документации не убила критическую цепь, мы ставим feeding buffer перед точкой слияния.
▪️И тут мы вспомним про ресурсные ограничения...
В реальном проекте цепочки задач ограничены не только зависимостями, но и людьми. Например, у вас один DevOps, который нужен и на настройку окружения, и на CI/CD, и на тестовый стенд. Это значит, что критический путь может быть не самый длинный по задачам, а самый длинный с учётом реальных доступных ресурсов → critical chain. Как отслеживать, сколько буфера уже съедено? Голдратт предложил гениально простой метод – график потребления буфера:
💚Зелёная зона (0–33%) → проект идёт нормально. 💛Жёлтая (34–66%) → внимание, что-то начинает гореть. ❤️Красная (67–100%) → SOS! Проект под угрозой!
Фишка: мы не гоняем людей с вопросом “почему задержка?”, а смотрим на здоровье буфера.
Почему это ппц как важно? Потому что в классике ты видишь проблему, когда она уже случилась. А с буферным управлением видно заранее, что мы уже сожрали половину запаса, а проект готов только на 30%.
И если проект всё-таки уходит в красную зону – ты не разводишь руками, а: 😀Перераспределяешь ресурсы, 😀Убираешь низкоприоритетные задачи, 😀Ставишь фокус на критическую цепочку.
Вывод: не нужно раздавать людям по 2 недели на задачу, чтобы они всё равно сделали в последний день. Лучше собрать все в один буфер и управлять им, чем жить в иллюзии “с запасом”. ❤️- если было полезно 😘 - если испугался за меня в прошлом посте
#управлениепроектами #слезыпроджектменеджера
P.S. И да, я немного не рассчитала в моем личном проекте - и теперь маааааленькие наклеечки на неделю задержали выход новых ароматов скрабов Lumimaniya (а вместе с ним и кремушков с тем самым ароматом-м-м-м-м❤️❤️❤️❤️❤️). Ждете же, правда?
