Как управлять большими проектами

Вы думали, я вам тут жалуюсь про собес? А вот и нет! Сегодня будет жёсткий ликбез. Поговорим о штуке, которая в реальной жизни 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 (а вместе с ним и кремушков с тем самым ароматом-м-м-м-м❤️❤️❤️❤️❤️). Ждете же, правда?