Бюджет цифрового продукта на 2027 год: пять контуров, которые нельзя прятать в одной смете

Финансовый директор открывает смету на запуск личного кабинета и видит одну понятную строку: разработка. Через десять минут появляются вопросы, которые эта строка не покрывает: кто проверит обмен с ERP, кто отвечает за резервные копии, что делать с ростом облачных счетов и где в плане изменения после первого релиза.

Привет, я Антон Фокин — CEO Qtim

Годовой бюджет цифрового продукта начинается там, где заканчивается оценка первого релиза. Его задача — связать решения о функциональности, интеграциях, инфраструктуре и развитии с деньгами, владельцами и моментами пересмотра. В нашей команде мы начинаем такой разговор с границ продукта и зависимостей, а не с единой итоговой суммы.

В этом разборе — рабочая карта из пяти контуров. Она не выдаёт универсальную сумму и не заменяет оценку. Зато помогает подготовить бюджет, который можно защищать перед бизнесом без произвольного процента «на всякий случай».

Оценка первой версии показывает, сколько усилий нужно, чтобы вывести конкретный набор сценариев в production. Годовой бюджет отвечает шире: какие решения придётся поддерживать, менять и контролировать после этого момента.

Эти документы часто смешивают, потому что оба заканчиваются итоговой суммой. Но управленческие объекты разные. В смете запуска важны объём функций и последовательность работ. В годовом бюджете появляются зависимости: внешний API, рост данных, мониторинг, обновления библиотек, требования к безопасности, новый канал продаж или изменения в правилах партнёра.

Удобная проверка проста: у каждой статьи расходов должен быть результат и владелец решения. Формулировка «резерв на поддержку» не отвечает ни на один из этих вопросов. Формулировка «ежемесячное наблюдение за интеграцией с системой X, устранение инцидентов и пересмотр лимитов» уже позволяет обсуждать объём и риск.

Чтобы бюджет не стал списком ролей и часов, разложите его по контурам работ. В каждом контуре фиксируются результат, исходные данные, зависимость, диапазон и дата следующего решения.

Таблица полезна тем, что показывает пустоты. Если в ней есть разработка интерфейсов, но нет владельца данных или плана восстановления, это не экономия. Это неопределённость, которую бизнес ещё не назвал деньгами.

Discovery — это работа, которая уменьшает число решений, принимаемых во время спринта под давлением срока. Discovery должен дать конкретные артефакты: карту пользовательских сценариев, правила для ролей, список систем-участников, варианты архитектуры и реестр рисков.

Для бюджета важен не сам термин discovery, а вопрос: какие вводные станут известны после него и кто подтвердит результат. Например, интеграция с учётной системой может выглядеть как один пункт в roadmap. После разбора выясняется тип обмена, частота синхронизации, ответственный за API, правила обработки ошибок и объём данных для миграции. Это уже меняет диапазон затрат.

В годовом плане стоит выделить контрольную точку после discovery. В ней команда и бизнес утверждают границы первой версии, список зависимостей и сценарии, которые уходят в следующий этап. Я считаю такую точку обязательной: так резерв превращается в список управляемых рисков.

В блоке создания продукта легко начать с набора ролей: два разработчика, дизайнер, тестировщик. Для защиты бюджета полезнее начать с результата: какие сценарии должны работать, как они проверяются и от каких данных зависят.

Например, «личный кабинет готов» слишком широко для расчёта. Список ролей, регистрация, согласование заявки, история операций, уведомления, экспорт данных и правила доступа — отдельные элементы. У каждого есть свои интерфейсы, ошибки и проверки. Такая декомпозиция помогает увидеть, какие части можно перенести, а какие определяют ценность первой версии.

Это особенно важно, когда product roadmap растёт быстрее, чем согласование бюджета. В нашем кейсе 4fresh мы переносили интернет-магазин натуральной косметики с 1С-Битрикс на собственную платформу и параллельно развивали backend, CMS, web и mobile. Когда меняются вводные для нескольких потоков работ, бюджет должен запускать пересмотр границ и ресурсов, а не прятать это изменение в резерв.

Интеграция редко ограничивается вызовом API. В бюджет входят вопросы, которые проявляются после первого успешного запроса: кто выдаёт доступы, как меняется схема данных, что происходит при недоступности партнёра, где хранится журнал, кто устраняет ошибку и как команда восстанавливает данные.

По данным ENISA, зависимость от внешних ИКТ- и security-сервисов добавляет организациям риски, а среди распространённых ответов — требования к поставщикам, аудиты и условия безопасности в договорах. Отчёт не даёт цену отдельной интеграции. Он напоминает, почему доступы, логирование, проверка поставщика и распределение ответственности нельзя оставлять вне бюджета.

Карту интеграций можно собрать в одной таблице: система, сценарий, владелец API, данные, частота обмена, лимит, режим при ошибке, мониторинг и дата пересмотра. Если в строке остаются пустые ячейки, оценка пока описывает только желаемую связь систем.

Когда такая карта собрана, в Qtim можно разобрать сложную SaaS-платформу на функциональные, интеграционные и инфраструктурные слои. Мы используем такую декомпозицию как основу для оценки без обещания типовой стоимости.

Инфраструктурный бюджет часто появляется в обсуждении после первого инцидента. К этому времени команда уже выбирает между срочным исправлением, потерей данных и переносом релиза.

В годовом плане должны быть видны среды разработки и тестирования, CI/CD, наблюдаемость, резервное копирование, восстановление, управление секретами, нагрузочные проверки и правила доступа. Для каждого пункта нужны единицы учёта: количество окружений, объём хранения, класс нагрузки, целевое время восстановления, число критичных интеграций.

FinOps описывает, как практики FinOps переносят фокус с разовой оптимизации на видимость затрат, распределение, прогнозирование и governance. В опросе участвовали организации, отвечавшие примерно за 69 млрд долларов публичных облачных расходов. Эта выборка не задаёт бюджет российскому продукту. Я бы использовал её как подтверждение порядка действий: сначала сделать расходы наблюдаемыми и привязать их к владельцу и сценарию использования.

Отдельно проверьте AI-нагрузку, если она входит в продукт. В том же исследовании 63% респондентов уже управляют расходами на AI, а 97% планируют инвестиции в нескольких инфраструктурных областях. Для бюджета это означает отдельные допущения: модель, объём запросов, хранение контекста, ограничения на данные и правила остановки эксперимента.

После релиза продукт не становится фиксированным объектом. Меняются версии зависимостей, правила внешних систем, поведение пользователей и требования бизнеса. Поддержка покрывает инциденты, обновления, технический долг и небольшие изменения, которые нельзя предсказать на этапе первого прототипа.

Отчёт TNO оценивает долю сопровождения и эволюции долгоживущих программных систем в 75–90% затрат жизненного цикла. Это диапазон для изучаемого класса high-tech систем, а не норматив для любого цифрового продукта. Его стоит использовать как вопрос к собственной модели: какой объём изменений, качества и знаний о системе останется после запуска.

Технический долг тоже лучше вынести из общего резерва. CAST описывает глобальный массив технического долга как 61 млрд рабочих дней устранения в анализируемом коде. Цифра не помогает посчитать конкретный продукт. Но она объясняет, почему у бюджета должно быть отдельное решение: какие ограничения архитектуры допустимы до следующего контрольного периода, кто измеряет последствия и по какому критерию работа попадает в план.

Как сформировать диапазон без произвольного процента

У бюджета есть три слоя: базовый сценарий, рисковый сценарий и список решений, после которых диапазон пересматривается. Такой формат честнее одной «точной» суммы, когда исходные данные ещё меняются.

В нашем кейсе Gallery мы разработали маркетплейс 3D-моделей дрон-шоу с каталогом, визуализатором, оплатой и доступом к купленным материалам. Мы связали цели и ключевые метрики с roadmap, спринтами и приоритетами, поэтому для бюджета здесь важен порядок работ, а не перечень задач без связи с результатом.

Главное возражение к такому подходу обычно звучит практично: «Нам всё равно нужна одна цифра для защиты». Она нужна. Но вместе с ней нужны границы и условия пересмотра. Иначе годовой план создаёт видимость контроля, а каждое новое решение возвращает разговор к смете с нуля.

Правило для защиты бюджета: включайте в годовой план только те суммы, у которых есть результат, зависимость, владелец и дата пересмотра.

Если нужен такой разбор для конкретного продукта, обсудите задачу с нами: на первом созвоне мы разложим сценарии, внешние системы и ограничения на состав работ.