Вернуться к блогу
Hola, Amiga! На связи CTO Amiga Артем Салеев.
Главная ошибка при составлении IT-бюджета – принять стоимость релиза за стоимость продукта. Релиз закрывает только проектную часть расходов. После него компания продолжает оплачивать инфраструктуру, лицензии, мониторинг, исправления и изменения, без которых система постепенно теряет устойчивость и пользу для бизнеса.
Поэтому бюджет на 2027 год стоит собирать как модель жизненного цикла. В ней отдельно видны создание продукта, его эксплуатация и развитие. Такая структура не делает раннюю оценку абсолютно точной, но показывает руководителю, какие решения формируют сумму и где пока остается неопределенность.
Чтобы составить IT-бюджет на 2027 год, определите границы продукта и период расчета, затем разделите расходы на создание, запуск, эксплуатацию и развитие. Отдельно учтите интеграции, инфраструктуру, лицензии, AI-сервисы и резерв на подтвержденные риски. Для каждой статьи зафиксируйте единицу расчета, владельца и условие пересмотра.
Формула годового бюджета: проектные расходы + 12 × ежемесячные расходы + переменное потребление AI и внешних сервисов + резерв на выявленные риски.
CTO Amiga Артем Салеев объясняет этот принцип так: «Я против дорогих догадок». Поэтому хорошая оценка показывает не только сумму, но и допущения, риски и данные, которые могут ее изменить.
До расчета важно согласовать период, состав системы и зоны ответственности.
До расчета нужно определить, какое решение должен поддержать бюджет. Запустить первую версию к конкретной дате, заменить действующую систему, обеспечить год эксплуатации или развивать продукт после релиза – это разные задачи. Если смешать их в одной сумме, сравнение вариантов потеряет смысл.
Практическое правило. Для управленческого планирования отделяйте затраты на создание и изменение продукта от расходов на регулярную эксплуатацию. Бухгалтерскую классификацию конкретных расходов согласуйте с финансовой службой компании.
Смета становится полезной, когда каждый блок связан с решением или ограничением. Аналитика зависит от числа процессов и ролей, интеграции – от готовности внешних систем, поддержка – от требуемого времени реакции. Поэтому стоимость лучше обсуждать не по профессиям команды, а по результатам и факторам сложности.
Блок | Что входит | Что влияет на оценку | Характер расходов |
Аналитика и проектирование | Интервью, описание процессов, требования, прототипы, архитектурные решения | Количество ролей и сценариев, состояние документации, число систем | В основном разовые, затем точечная актуализация |
Дизайн | Пользовательские сценарии, интерфейсы, дизайн-система, адаптивные состояния | Число экранов и состояний, платформы, наличие готового бренда | Разовые и последующие доработки |
Разработка | Клиентская и серверная части, административные функции, миграции | Объем функций, архитектура, платформы, технический долг | Основной проектный блок |
Интеграции | Подключение CRM, ERP, платежей, каталогов, авторизации и других сервисов | Готовность API, качество данных, лимиты, владельцы систем | Разовые работы и регулярные платежи поставщикам |
AI-сервисы и модели | LLM и другие модели, API, векторные базы, распознавание речи и изображений, мониторинг качества | Модель, объем токенов и запросов, хранение данных, скорость ответа, требования безопасности | Настройка и переменные регулярные расходы |
QA и безопасность | Тест-план, функциональные и интеграционные проверки, регресс, проверки доступа | Критичность сценариев, число окружений, устройства и браузеры | На каждом релизе и при крупных изменениях |
Инфраструктура и выпуск | Облако, серверы, базы данных, CI/CD, мониторинг, резервное копирование | Нагрузка, отказоустойчивость, хранение данных, требования к размещению | Настройка плюс регулярные платежи |
Поддержка и развитие | Мониторинг, исправления, обновления, консультации, небольшие улучшения | SLA, часы доступности, скорость реакции, объем изменений | Регулярные расходы после релиза |
Структура помогает не потерять аналитику, AI-сервисы, QA, инфраструктуру и поддержку.
Если на старте еще нет согласованных требований, полезно сначала провести системную аналитику. Она снижает долю неизвестных, от которых зависит диапазон оценки.
Проектные расходы отвечают на вопрос, сколько стоит получить согласованную версию продукта. Регулярные показывают, сколько стоит сохранять ее работоспособность и актуальность. Если соединить эти части, сокращение бюджета легко ударит по эксплуатации: релиз состоится, но ресурсов на наблюдение за системой и исправление ошибок не останется.
Разовые или проектные расходы | Регулярные расходы после запуска |
Исследование задачи, требования и архитектура | Облачные ресурсы, серверы, базы данных и хранение файлов |
Проектирование интерфейсов и дизайн | Лицензии, платные API, сервисы рассылок и аналитики |
Разработка первой версии и миграция данных | Мониторинг, резервное копирование и реагирование на инциденты |
Первичная настройка интеграций и окружений | Исправления, обновления зависимостей и регрессионные проверки |
Подготовка к релизу и публикация | Изменения, которые появляются из обратной связи и новых задач бизнеса |
Состав работ после запуска удобно сверить со страницей услуги поддержки и развития проектов Amiga: там перечислены мониторинг, технический аудит, резервное копирование и развитие продукта.
Фраза «подключить CRM» описывает намерение, но не объем работ. Оценку формируют данные, направление и частота обмена, качество API, владелец внешней системы и наличие тестового контура. Пока API не проверен, интеграцию разумно выделить отдельной строкой с диапазоном, допущениями и условием повторной оценки.
Если цифровой продукт использует генерацию текста и изображений, распознавание речи, поиск по базе знаний или другие модели, AI-сервисы стоит вынести в отдельную статью бюджета. Это не только стоимость подключения: регулярные расходы зависят от объема использования, выбранной модели, хранения данных и требований к скорости ответа.
Практическое правило. Пилот и промышленную эксплуатацию AI-функции считайте отдельно. Для запуска зафиксируйте предполагаемый объем использования и стоимость единицы, а после релиза сверяйте прогноз с фактическим потреблением.
По прогнозу Gartner от 21 октября 2026 года, мировые IT-расходы в 2027 году вырастут на 15%, а одним из главных драйверов станет AI-инфраструктура. Это не означает, что бюджет каждого продукта нужно автоматически увеличивать на 15%. Но переменное потребление моделей, хранение данных и наблюдаемость AI-функций нельзя прятать внутри общей строки разработки.
Практика Amiga показывает, почему AI-функцию нельзя оценивать как один вызов API. В мобильном приложении с ML-интеграцией состав работ включал Flutter-разработку, API, нативную часть Android на Kotlin, TensorFlow и кастомные анимации. Приложение с нуля разработали за четыре месяца. При оценке такого проекта эти направления нужно учитывать отдельно.
Резерв без расшифровки плохо защищает бюджет: непонятно, какой риск он покрывает и когда его можно уменьшить. Рабочий подход – вести реестр допущений. Для каждого неизвестного указывают способ проверки, возможное изменение объема и момент, когда оценку нужно пересмотреть.
Неопределенность | Как проверить | Как учесть в бюджете |
Нет документации по внешнему API | Запросить спецификацию, тестовый доступ и примеры ответов | Отдельно оценить обследование и оставить диапазон на реализацию |
Неизвестно качество исходных данных | Взять выборку и проверить полноту, форматы и дубли | Выделить миграцию и очистку данных отдельной строкой |
Не утвержден состав первой версии | Зафиксировать обязательные сценарии и отложенные функции | Считать базовый объем и опции отдельно |
Не определен режим поддержки | Согласовать часы доступности и допустимое время реакции | Сравнить несколько уровней сервиса |
Ожидается рост нагрузки | Описать текущий и целевой объем пользователей и операций | Составить базовый и нагрузочный сценарии инфраструктуры |
Сценарии показывают, какие решения формируют нижнюю и верхнюю границы бюджета.
Одна цифра скрывает компромиссы. Три сценария показывают, что компания получает при каждом уровне финансирования, какие риски принимает и какие возможности откладывает. Различия между сценариями должны объясняться составом продукта и уровнем сервиса, а не произвольным изменением суммы.
Сценарий | Что включить | Когда использовать |
Минимальный | Обязательные пользовательские сценарии, базовые интеграции, необходимая инфраструктура и поддержка критических ошибок | Чтобы проверить нижнюю границу и возможность запуска первой версии |
Базовый | Согласованный объем, рабочий запас инфраструктуры, QA, мониторинг и плановые изменения после релиза | Как основной вариант годового бюджета |
Расширенный | Опциональные функции, повышенная отказоустойчивость, дополнительные исследования и ускоренное развитие | Для оценки верхней границы и выбора приоритетов |
В каждом сценарии стоит показать не только итог, но и состав: этапы, внешние платежи, регулярные расходы, допущения и исключения. Это упрощает сравнение предложений и последующую защиту бюджета.
После запуска продукт становится частью операционного процесса. Любой сбой уже влияет на пользователей, сотрудников или выручку. Поэтому пострелизные расходы стоит привязывать к обязательствам: доступности, скорости реакции, сохранности данных и плану обновлений.
Практический список таких деталей есть в статье «Что забывают добавить в мобильное приложение перед запуском».
Подготовленные исходные данные помогают сузить диапазон предварительной оценки.
Количество страниц презентации почти не влияет на точность оценки. Ее сужают решения о первой версии, интеграциях, нагрузке, безопасности и распределении ответственности. Материалы для подрядчика стоит собирать вокруг этих вопросов.
Критерий качественной оценки. Подрядчик называет диапазон, объясняет его границы и показывает, какие неизвестные изменят сумму. Для годового бюджета это надежнее одной точной цифры без допущений.
Допустим, создание и запуск первой версии стоят 100 условных единиц. Эксплуатация требует 4 единицы в месяц, AI-сервисы — еще 1 единицу в месяц, а резерв на выявленные риски составляет 10 единиц. Тогда бюджет первого года равен 100 + 12 × 4 + 12 × 1 + 10 = 170 условных единиц.
Это не рыночный ориентир и не рекомендуемая пропорция. Пример показывает, почему цена релиза и годовой бюджет продукта не равны.
Для рабочего файла заведите отдельные поля:
На предварительной оценке стоит разделить подтвержденный объем и допущения. По каждому крупному блоку нужно зафиксировать исходные данные, ограничения и вопросы, которые могут изменить решение. Если проект зависит от действующей системы или внешних интеграций, полезно начать с обследования. Его задача – проверить критичные неизвестные, а не детализировать все требования без необходимости.
Если нужно проверить критичные неизвестные до сметы, начните с предпроектного обследования Amiga. Команда зафиксирует границы продукта, интеграции и допущения, которые влияют на диапазон оценки.
Да. На раннем этапе используют диапазон и фиксируют допущения. Чем точнее описаны обязательные сценарии, интеграции, нагрузка и ограничения, тем уже диапазон. Детальную оценку обновляют после аналитики и согласования решений.
Определите ожидаемый объем изменений, часы доступности, допустимое время реакции и состав регулярных работ. Инфраструктуру, лицензии и платные сервисы лучше считать отдельно от трудозатрат команды.
Резерв полезен, когда остаются неизвестные: нет доступа к API, не проверены данные, не согласована первая версия или возможен рост нагрузки. Его размер должен быть связан с этими рисками, а не назначен автоматически.
Кроме разработки учитывают аналитику, дизайн, тестирование, интеграции, инфраструктуру, лицензии, AI-сервисы, мониторинг, поддержку и развитие продукта. Разовые и регулярные расходы лучше показывать отдельно.
Определите единицу потребления: токены, запросы, минуты аудио, изображения или вычислительное время. Затем оцените объем использования, тарифы поставщиков, хранение данных, векторную базу и мониторинг. Для 2027 года полезно подготовить базовый и пиковый сценарии.
Оценку обновляют после аналитики, перед релизом и после появления данных о реальном потреблении. Затем бюджет сверяют с фактом ежемесячно или ежеквартально, а также при изменении объема функций, нагрузки, тарифов или SLA.
Рабочий IT-бюджет отвечает на три вопроса: что компания запускает, сколько стоит стабильная работа продукта после релиза и какие допущения могут изменить сумму. Поэтому в смете нужно отдельно показывать создание, эксплуатацию, AI-сервисы и резерв, а для каждого блока – единицу расчета, владельца и условие пересмотра.
В Amiga мы собираем минимум три сценария – минимальный, базовый и расширенный – и проверяем их по составу продукта, интеграциям, нагрузке и обязательствам после запуска. Такой бюджет можно защищать перед руководством, сверять с фактом и корректировать без «дорогих догадок».
Сначала можно посмотреть актуальные вилки стоимости, а затем рассчитать свой проект в калькуляторе Amiga. Для точной сметы команда проверит материалы, зафиксирует границы первой версии и отдельно посчитает регулярные расходы после релиза.
