10 минут
Заморозка IT‑проекта: почему «экономия сейчас» часто оборачивается ростом затрат
Заморозка IT‑инициативы — одно из самых частых управленческих решений, когда бизнесу нужно сократить расходы. На уровне отчета о прибылях и убытках это выглядит логично: остановили разработку — сократили бюджет. Но на практике такая пауза редко означает реальную экономию. Чаще это всего лишь перенос затрат во времени с их последующим увеличением. В этой статье разберем три управленческих риска, которые превращают «экономию» в убытки.
Когда проект надолго ставят на паузу, он нередко теряет управленческий контур. Формально у него могут оставаться владелец, бюджет и план, но на практике решения начинают приниматься медленнее, приоритеты — размываться, а ответственность — распределяться неясно. Документы устаревают, дорожная карта перестает отражать реальность, а после возврата к работе команда часто вынуждена заново выстраивать логику управления, хотя внешне проект выглядит просто «замороженным». Ответственность размывается, а документы и приоритеты постепенно перестают соответствовать реальному положению дел.
Иными словами, при заморозке проекта всегда остается три главных риска, которые всегда нужно учитывать: рост будущих затрат, потеря управляемости, деградация процессов и команды. Разберем их все по-порядку.
Иллюзия экономии
Иногда в компании «заморозка» — это не полное отключение проекта, а переход в режим минимальной активности. В нем сохраняются:
-
инфраструктурные расходы (облачные сервисы, лицензии, хостинг);
-
обязательства по контрактам с подрядчиками и вендорами;
-
базовая поддержка работоспособности системы.
Согласно практике финансового управления облачной инфраструктурой (подход FinOps), даже неиспользуемые ресурсы продолжают генерировать расходы, если их вовремя не отключить или не оптимизировать. В крупных проектах такие издержки могут составлять ощутимую долю бюджета. Большая ошибка считать эти расходы несущественными и не включать их в финансовую модель паузы.
Риск 1: «отложенный платеж»
Именно в момент возвращения проекта в активную фазу компания может столкнуться с ростом затрат. Потому что за время паузы а) устаревают версии библиотек и фреймворков; б) меняются внешние API и интеграции; в) накапливается технический долг. При этом обновление зависимостей и восстановление стабильности системы после длительного перерыва может «съедать» значительную долю времени от общего цикла разработки.
Риск 2: потеря контекста
Даже при наличии документации часть знаний остается неформализованной. Многое остается на уровне устных договоренностей, личного опыта и неписаных правил. При смене команды это приводит к дополнительным затратам на повторное погружение и повышенному риску ошибок.
В результате возобновление проекта часто требует отдельного бюджета, который не учитывался при его заморозке.
Риск 3: удорожание ресурсов и среды
Дополнительный и важный критерий. Почти всегда заморозка означает, что проект возвращается в изменившуюся среду.
Почему так происходит. Во-первых ИТ-рынок и рынок специалистов всегда подвержен колебаниям: в разные периоды наблюдается рост ставок и дефицит определенных компетенций. Это подтверждается регулярными обзорами зарплат и рынка труда в IT.
Кроме того:
-
меняются условия работы с подрядчиками;
-
обновляются лицензионные модели вендоров;
-
часть технологий устаревает или выходит из активной поддержки.
Это увеличивает стоимость входа в проект после паузы и может требовать дополнительных инвестиций ещё до начала основной разработки.
Косвенные потери: неочевидная часть экономики
Финансовый эффект заморозки не ограничивается прямыми затратами.
Один из ключевых факторов — упущенная выгода. Задержка релиза означает перенос или потерю потенциальной выручки. В продуктовых компаниях это напрямую связано с Time to market — метрикой, которая существенно влияет на конкурентоспособность.
Также при заморозке проекты возможны сдвиги контрактных сроков и связанные с ними штрафы. Не исключено ухудшение позиций относительно конкурентов. Может случиться снижение эффективности уже вложенных инвестиций.
Эти потери сложнее формализовать, но игнорировать их при принятии решения — это большая управленческая ошибка.
Когда заморозка действительно оправдана
Несмотря на риски, заморозка может иногда быть и рациональным решением. Чаще всего это происходит в 3 ситуациях:
-
проект потерял бизнес‑приоритет или перестал соответствовать стратегии;
-
компания сталкивается с ограничениями ликвидности;
-
уровень неопределенности настолько высок, что продолжение разработки неэффективно.
Разница между управляемой и проблемной заморозкой — в наличии расчетов. Бизнес должен понимать:
-
какие расходы сохраняются в период паузы;
-
сколько будет стоить возврат;
-
как изменится экономика проекта после возобновления.
Без этого заморозка превращается из инструмента оптимизации в источник дополнительных затрат.
Какие данные нужно проверить
Практика показывает, что основная ошибка — принимать решение о паузе без достаточного финансового анализа и детализации.
Минимальный набор данных, которые нужно проверить:
-
структура текущих затрат и их обязательная часть;
-
оценка ежемесячного бюджета поддержания;
-
предварительная стоимость «разморозки»;
-
зависимость от ключевых специалистов и подрядчиков;
-
сценарная оценку потерь от сдвига сроков.
Только при наличии этих данных заморозка становится управляемым решением, а не отложенным финансовым риском.
Заключение
Заморозка становится управляемым решением только тогда, когда она точно просчитана, а не просто объявлена. Без оценки сохраняющихся затрат, стоимости возврата, кадровых рисков и сценарных потерь от переноса сроков проект на паузе превращается в лотерею. При правильном подходе заморозка может быть оправданной реакцией на смену приоритетов. При неправильном — прямой дорогой к росту совокупной стоимости и потере конкурентных позиций. Решение должно базироваться не на отчете P&L (profit and loss — отчет о прибылях и убытках) за текущий месяц, а на полной экономической модели всего жизненного цикла проекта.