Стоимость разработки программного обеспечения на заказ
Из чего складывается цена заказной разработки, и как выбрать тип договора и не переплатить?
Аксмор внесён в реестр аккредитованных ИТ-организаций
Министерства цифрового развития, связи и массовых коммуникаций Российской Федерации. Аккредитация подтверждает, что основная деятельность компании — разработка и реализация программного обеспечения, а компания соответствует требованиям по ОКВЭД и доле выручки от ИТ-деятельности. Проверить актуальный статус Aксмор можно в официальном реестре аккредитованных ИТ-организаций на Госуслугах. Настоящая страница содержит достоверную информацию о стоимости услуг и порядке её формирования в соответствии с требованиями приказа Минцифры России № 511 от 02.06.2025 для аккредитованных ИТ-компаний.
Почему нет прайс-листа — и что есть вместо него
Заказная разработка не имеет каталога. Программный продукт, созданный под конкретный бизнес-процесс, — это не типовая услуга и не коробочное решение. Его цена определяется составом и трудоёмкостью работ, и главная сложность ее определения заключается в том, что и состав, и трудоемкость бывают неочевидны на старте.
Чтобы определить, насколько трудоемкой будет та или иная задача, оценщик проходит её архитектурно: есть ли проверенные компоненты или придётся писать с нуля, как устроены точки интеграции с внешними системами, где нетривиальные зависимости — и как они поведут себя в реальной среде. На каждом шаге обнаруживаются риски: одни предсказуемые и поддаются оценке, другие проявятся только в реализации. Именно соотношение первых и вторых определяет, можно ли дать фиксированную цену — или честнее признать, что итог станет известен в процессе.
Из этого следуют два типа ситуаций — и два типа контрактов.
Fixed Price фиксирует стоимость заранее. Это работает, когда требования полностью определены до старта и не изменятся в ходе проекта, а риски предсказуемы и минимальны. Цена срабатывания рисков сразу закладывается в общую стоимость решения.
Time & Materials фиксирует состав команды и ставки. Заказчик платит за фактически отработанное время, которое согласовывается перед началом каждого этапа.
Ниже — подробный разбор двух типов контрактов в разработке ПО: как устроена их механика, для каких видов программного обеспечения они подходят, и как выглядит контроль затрат в каждом случае.
Механика работы Time & Materials контрактов: полное руководство
T&M стал стандартом в разработке ПО, потому что лучше других моделей отражает её природу и честнее работает с неопределенностью — проекты, в которых не всё известно заранее, развиваются итерациями, и требования меняются по мере того, как появляется реальный продукт.
В Fixed Price непредсказуемый риск — это нарушение обязательства. Интеграция оказалась сложнее, данные не в том формате, обнаружилась зависимость, которой не было в ТЗ — всё это ставит подрядчика перед выбором: поглотить риск за счёт качества (уложиться в смету, срезав углы) или открыть change request и ждать согласования. В T&M тот же риск — просто новая информация. Команда фиксирует, объясняет, предлагает варианты, заказчик решает: конфликта интересов нет.
Кто платит за риски, которые не случились
Подрядчик не может принять непредсказуемые риски на себя бесплатно. В Fixed Price он закладывает буфер в цену заранее, на случай, если что-то пойдёт не так. Если риски реализовались — буфер покрывает их. Если не реализовались — заказчик всё равно заплатил. Чем выше неопределённость, тем больше буфер, и тем дальше итоговая цена от реальной стоимости работы. Неопределённость существует вне зависимости от типа контракта. В тех случаях, когда она настолько высока, что выполнить проект по фиксированной стоимости становится невыгодно для заказчика, используется T&M.
Как строится работа по T&M
1. Команда под проект
До старта формируется команда: разработчики нужного стека, аналитик, дизайнер, тестировщик, проект-менеджер. Состав и количество специалистов согласовывается с заказчиком — это напрямую влияет на скорость и итоговую стоимость.
2. Планирование итерациями
Работа ведётся спринтами — как правило, двухнедельными. Перед каждым спринтом команда совместно с заказчиком определяет приоритеты: какие функции разрабатываются в ближайшие две недели. Между спринтами порядок задач можно менять.
3. Тайм-трекинг
Все специалисты фиксируют время в системе учёта. Заказчик имеет доступ к отчётам в любой момент: видно, кто, сколько и на что тратит время.
4. Выставление счетов
По итогам каждого периода — как правило, месяца — формируется отчёт: сколько часов отработано, кем и на каких задачах. Счёт выставляется на основании этого отчёта.
5. Управление изменениями
Это принципиальное преимущество T&M. Когда требования уточняются — а в сложных проектах они уточняются всегда — команда адаптируется без переоформления договора. Новая задача появляется в бэклоге и оценивается в часах.
Time and Materials
Time and Materials — контрактная модель, при которой заказчик оплачивает фактически отработанное время специалистов. В отличие от контракта с фиксированной ценой, T&M не фиксирует объём работ: он фиксирует состав команды, ставки и процесс. Счёт выставляется за часы, Каждая задача и трудозатрата видна заказчику в инструментах тайм-трекинга в режиме реального времени, гарантируя прозрачонсть процесса. Приоритеты и состав работ при этом можно менять в любой момент без допсоглашений и без потери темпа.
Распределение платежей по времени
Типы программного обеспечения и выбор контрактной модели
Не существует универсально правильной модели. Выбор между T&M и Fixed Price определяется природой самого программного продукта — его зрелостью, аудиторией и жизненным циклом требований.
Внутрикорпоративное ПО: ERP, CRM, отраслевые системы
Корпоративные системы, созданные для внутреннего использования, часто кажутся хорошо определёнными: бизнес-процессы описаны, пользователи известны, сценарии задокументированы. Здесь Fixed Price применим — при условии, что ТЗ составлено до начала разработки и команда провела полноценный аналитический этап.
На практике корпоративные системы кажутся понятными ровно до момента, когда начинается разработка. Интеграции с унаследованными системами, нестандартная логика в «устоявшихся» процессах, исключения, которые знают только конкретные сотрудники, — всё это превращает FP-проект в серию согласований изменений. T&M или гибридная модель в таких случаях дают более предсказуемый результат при меньшей административной нагрузке.
Рекомендация: FP при наличии зрелого ТЗ; гибридная модель (FP на аналитику + T&M на разработку) при отсутствии.
Пользовательское и рыночное ПО: маркетплейсы, мобильные приложения
Продукты, ориентированные на конечного пользователя, обычно обслуживаются по Time & Materials. Требования здесь не фиксируются на старте — они формируются в процессе: по результатам юзер-тестирования, обратной связи от первых пользователей, анализа конкурентной среды. Зафиксировать их до начала работ — значит разрабатывать то, что устареет к моменту запуска.
Мобильная разработка — один из самых частых T&M-контекстов, и причина не только в изменчивости требований. Специфика здесь техническая: Android-экосистема насчитывает более 24 000 вариантов устройств от свыше 1 300 производителей. Активно используется более десяти версий ОС одновременно. Поведение приложения на конкретном парке устройств — это не теоретический риск, это эмпирический факт, который становится известен только в процессе тестирования на реальной аудитории.
Рекомендация: FP для MVP или прототипа, T&M в большинстве случаев.
SaaS-решения: продукты с непрерывным циклом разработки
SaaS-продукты не имеют момента завершения. Функциональность добавляется итерационно, приоритеты определяются метриками продукта, а не техническим заданием двухлетней давности. Здесь нужна постоянная команда, работающая по T&M — с фиксированными ставками, гибким бэклогом и ежемесячной отчётностью.
Рекомендация: T&M с ежеквартальным пересмотром состава и приоритетов.
Ценообразование в T&M проектах: из чего складывается стоимость и как её контролировать
Стоимость T&M проекта — это суммарное количество часов работы специалистов, умноженное на их ставки. Два рычага определяют итог: трудоёмкость задач и состав команды
Факторы, влияющие на стоимость
Размер команды
Больше специалистов — выше скорость, но и больший расход бюджета в единицу времени. Оптимальный состав зависит от вашего горизонта и объёма задач.
Объём функциональных требований
До старта мы проводим оценку: декомпозируем требования и оцениваем трудоёмкость каждой функции. Это даёт ориентир по бюджету до подписания договора.
Технологический стек
Некоторые технологии требуют специалистов с редкой экспертизой — это влияет на доступность и стоимость ресурсов.
Этапы работ
Аналитика, проектирование, разработка, тестирование, внедрение, поддержка — у каждого этапа своя интенсивность и состав команды.
Как формируется оценка
Прежде чем выставить счёт на первый спринт, команда проводит предпроектный анализ. Это не формальность — от точности этого этапа зависит весь дальнейший бюджет.
1 Сбор и декомпозиция требований
Аналитики Аксмор погружаются в суть рабочего процесса заказчика и переводят бизнес-задачи в функции будущей системы. Результат — декомпозиция: список пользовательских историй, каждая из которых описывает конкретный сценарий использования продукта.
2 Командная оценка в стори-поинтах
Далее команда оценивает каждую историю. Мы используем относительные единицы размера — стори-поинты — и методику планирования покером: каждый участник (разработчик, аналитик, тестировщик, дизайнер) оценивает задачу независимо, затем расхождения обсуждаются. Это снижает субъективность и выявляет скрытые риски на этапе оценки, а не в процессе разработки.
3 Оценка скорости команды
Зная примерный объём в стори-поинтах и производительность команды аналогичного состава по историческим данным, мы получаем диапазон: сколько спринтов займёт проект.
4 Конвертация в бюджет
Диапазон спринтов × состав команды × ставка = диапазон стоимости. Это не точечная цифра, а честный прогноз с явной погрешностью.
Важный принцип: чем точнее сформулированы требования, тем точнее оценка. Но даже при полных требованиях корректная методика даёт диапазон, а не точку. Этот диапазон называют конусом неопределённости: на старте проекта погрешность может составлять ±50%, но к моменту, когда проведены первые 2–3 спринта и получена реальная скорость команды, точность оценки резко возрастает.
Именно поэтому первые спринты T&M-проекта ценнее любого ТЗ: они переводят оценку из предположений в данные.
Инструменты контроля бюджета в T&M
Временной бюджет
Перед каждым спринтом согласовывается плановое количество часов. Отклонение от плана обсуждается немедленно, а не в конце месяца.
Capped T&M — потолок расходов
Устанавливается максимальная сумма, которую нельзя превысить без явного согласования. Гибкость T&M + ограничение риска = модель, которую предпочитают заказчики с конкретным бюджетным горизонтом.
Еженедельные демо
Каждая итерация завершается демонстрацией готового функционала. Заказчик видит, на что потрачены часы, — и принимает решение о приоритетах следующего спринта на основе результата, а не плана.
Право остановить
В T&M заказчик может в любой момент скорректировать состав команды, приостановить разработку или изменить приоритеты. Это не расторжение договора — это его нормальная механика.
Отраслевая специфика: выбор модели для разных типов проектов
Стоимость T&M проекта — это суммарное количество часов работы специалистов, умноженное на их ставки. Два рычага определяют итог: трудоёмкость задач и состав команды.
Факторы, влияющие на стоимость
Размер команды
Больше специалистов — выше скорость, но и больший расход бюджета в единицу времени. Оптимальный состав зависит от вашего горизонта и объёма задач.
Объём функциональных требований
До старта мы проводим оценку: декомпозируем требования и оцениваем трудоёмкость каждой функции. Это даёт ориентир по бюджету до подписания договора.
Технологический стек
Некоторые технологии требуют специалистов с редкой экспертизой — это влияет на доступность и стоимость ресурсов.
Этапы работ
Аналитика, проектирование, разработка, тестирование, внедрение, поддержка — у каждого этапа своя интенсивность и состав команды.
Как формируется оценка
Прежде чем выставить счёт на первый спринт, команда проводит предпроектный анализ. Это не формальность — от точности этого этапа зависит весь дальнейший бюджет.
1 Сбор и декомпозиция требований
Аналитики Аксмор погружаются в суть рабочего процесса заказчика и переводят бизнес-задачи в функции будущей системы. Результат — декомпозиция: список пользовательских историй, каждая из которых описывает конкретный сценарий использования продукта.
2 Командная оценка в стори-поинтах
Далее команда оценивает каждую историю. Мы используем относительные единицы размера — стори-поинты — и методику планирования покером: каждый участник (разработчик, аналитик, тестировщик, дизайнер) оценивает задачу независимо, затем расхождения обсуждаются. Это снижает субъективность и выявляет скрытые риски на этапе оценки, а не в процессе разработки.
3 Оценка скорости команды
Зная примерный объём в стори-поинтах и производительность команды аналогичного состава по историческим данным, мы получаем диапазон: сколько спринтов займёт проект.
4 Конвертация в бюджет
Диапазон спринтов × состав команды × ставка = диапазон стоимости. Это не точечная цифра, а честный прогноз с явной погрешностью.
Важный принцип: чем точнее сформулированы требования, тем точнее оценка. Но даже при полных требованиях корректная методика даёт диапазон, а не точку. Этот диапазон называют конусом неопределённости: на старте проекта погрешность может составлять ±50%, но к моменту, когда проведены первые 2–3 спринта и получена реальная скорость команды, точность оценки резко возрастает.
Именно поэтому первые спринты T&M-проекта ценнее любого ТЗ: они переводят оценку из предположений в данные.
Инструменты контроля бюджета в T&M
Временной бюджет
Перед каждым спринтом согласовывается плановое количество часов. Отклонение от плана обсуждается немедленно, а не в конце месяца.
Capped T&M — потолок расходов
Устанавливается максимальная сумма, которую нельзя превысить без явного согласования. Гибкость T&M + ограничение риска = модель, которую предпочитают заказчики с конкретным бюджетным горизонтом.
Еженедельные демо
Каждая итерация завершается демонстрацией готового функционала. Заказчик видит, на что потрачены часы, — и принимает решение о приоритетах следующего спринта на основе результата, а не плана.
Право остановить
В T&M заказчик может в любой момент скорректировать состав команды, приостановить разработку или изменить приоритеты. Это не расторжение договора — это его нормальная механика.
Как это выглядит на практике: три сценария выбора модели
Ниже — три реальных типа ситуаций из нашей практики. В каждом своя логика выбора между Fixed Price и T&M. Обратите внимание: в двух из трёх кейсов мы рекомендуем не T&M.
Сценарий 1. Пилот по Fixed Price → полный проект по T&M
Ситуация:
Заказчик приходит с концепцией продукта и хочет сначала проверить её реализуемость, прежде чем инвестировать в полную разработку. Нужен proof-of-concept (проверка технической реализуемости концепции): ограниченный функционал, без сложных интеграций, без взаимодействия со сторонними системами, без нагруженной аналитики. Горизонт — один-три месяца.
Почему здесь Fixed Price
Задача чётко ограничена. Технических рисков минимум — не потому что задача простая, а потому что она изолированная. Изменения требований в таком объёме некритичны. Мы можем дать точную оценку — и даём её.
Что происходит дальше
Пилот завершён, концепция проверена. Начинается основная разработка: интеграции с внешними системами, сложная бизнес-логика, накапливающиеся требования. Здесь Fixed Price уже нецелесообразен, и вот почему. Чтобы поставить фиксированную цену на задачу с интеграцией в незнакомую систему, разработчик должен досконально описать каждый шаг. Но чтобы описать шаг с нужной точностью, нужно технически его проработать. А проработать — значит наполовину реализовать. Получается, что детальное ТЗ для Fixed Price стоит почти столько же, сколько сама разработка. И потом ещё неделя-две на согласование и подписание — пока задача уже могла быть в производстве.
Поэтому на основной стадии переходим на T&M: прозрачная ежемесячная отчётность, гибкий бэклог, согласование каждого шага.
Что получает заказчик: Уверенность до инвестиции в полный проект — по Fixed Price. Скорость и гибкость на основной разработке — по T&M. Без дополнительного буфера за риски, которые не реализовались.
Сценарий 2. Полностью Fixed Price — функционал уже реализован на другой платформе
Ситуация:
У заказчика есть работающий веб-сайт с функциями электронной коммерции: личный кабинет, каталог, корзина, оформление заказа — вся бизнес-логика описана и проверена в реальной эксплуатации. Теперь он хочет мобильное приложение с тем же функционалом.
**Почему здесь Fixed Price: **
Задача понятна — не потому что простая, а потому что мы видим, как она уже работает. Мы смотрим на реализованную корзину, на логику авторизации, на структуру каталога. Нам не нужно угадывать. Рисков нет, неопределённость минимальна. В такой ситуации мы можем сделать точную оценку — и зафиксировать её.
Это принципиальный момент: Fixed Price — не про сложность задачи, а про уровень неопределённости в ней. Мобильная разработка технически непростая. Но если мы видим, что именно нужно сделать — мы не будем закладывать буфер, которого нет оснований закладывать.
Что получает заказчик: Предсказуемый бюджет там, где это честно возможно. Именно потому, что мы предлагаем Fixed Price только тогда, когда уверены в оценке, — такое предложение что-то значит.
Сценарий 3. Только T&M — работа с физическим оборудованием без доступа к реальной среде
Ситуация:
Заказчик занимается промышленной автоматизацией. Программный продукт должен взаимодействовать с физическим оборудованием: считывать данные с датчиков, управлять устройствами, работать с потоком данных в реальном времени.
Проблема:
Оборудование работает в режимной среде. Служба безопасности не может предоставить доступ к реальной инфраструктуре. Разработка и тестирование ведутся в изолированной среде — с синтетическими данными и программными эмуляторами вместо боевого оборудования.
Почему Fixed Price здесь невозможен:
Корректность кода на реальном оборудовании нельзя подтвердить без проверки на этом оборудовании. Зафиксировать стоимость в такой ситуации означает одно из двух: либо заложить значительный резерв на риски — и заказчик платит за то, что может не случиться, — либо подрядчик принимает риск убытков на себя. Оба варианта не отражают реальную структуру затрат.
Как работает T&M здесь:
Итерациями. Реализовали на тестовых данных — передаём заказчику для проверки на реальном оборудовании. Если что-то не работает — совместно разбираемся в причинах, согласовываем следующий шаг. Каждый час работы прозрачен и согласован заранее.
Что получает заказчик: Управляемый прогресс вместо декларативных гарантий. И бюджет, который отражает фактические трудозатраты — а не скрытый резерв подрядчика на риски, которые не реализовались.
Полная стоимость владения ПО: развитие и поддержка
Успешный программный продукт развивается: появляются новые сценарии использования, растёт аудитория, меняются интеграции. Поддержка, обновления и масштабирование — естественная часть жизненного цикла ПО и составляет так называемую TCO (Total Cost of Ownership) или совокупную стоимость владения. То, насколько управляема эта стоимость, во многом определяется решениями, принятыми при разработке.
Технический долг: каждый отложенный компромисс стоит дороже при следующем касании
Технический долг — это компромиссы в архитектуре и коде, которые ускоряют разработку сегодня, но замедляют и удорожают её завтра. По данным McKinsey, технический долг поглощает в среднем 20–40% ресурсов команды разработки. Он не возникает сам по себе — его накапливают конкретные решения.
В Fixed Price проектах технический долг чаще закладывается вынужденно: подрядчик укладывается в бюджет и сроки за счёт архитектурных упрощений, которые не видны при приёмке. В T&M, где работа ведётся итерациями с постоянной видимостью кода и архитектурных решений, накопление долга можно отслеживать и управлять им как плановой статьёй.
Сопровождение ПО: модель контракта формирует стоимость каждого обращения к подрядчику после запуска
После запуска появляются патчи безопасности, обновления зависимостей, изменения в сторонних API, регуляторные требования. То, как они оплачиваются, зависит от контрактной модели.
В Fixed Price каждое постпродакшн изменение — отдельный контракт: постановка задачи, оценка, согласование. Это создаёт транзакционные издержки, зато каждая задача имеет чёткий объём и фиксированную цену до начала работ. Модель удобна, когда задачи поддержки крупные и хорошо определённые.
В T&M изменения проходят через уже действующий механизм: часы фиксируются и выставляются без переоформления договора. Это удобно для частых небольших задач, но требует активного управления бюджетом — часы накапливаются без жёстких контрактных границ.
Масштабирование: Fixed Price требует прогнозировать нагрузку до запуска, T&M — позволяет реагировать на реальные данные
В Fixed Price требования к масштабированию фиксируются до начала разработки. Если прогноз оказался точным — модель работает хорошо: команда реализует ровно то, что согласовано. Если фактическая нагрузка или сценарии использования оказались другими, масштабирование становится отдельным проектом с новой оценкой и новыми сроками.
T&M позволяет принимать решения о масштабировании по мере накопления реальных данных. Когда первые месяцы эксплуатации показывают фактические паттерны нагрузки, команда может скорректировать приоритеты и адресовать проблему до того, как она станет критической — в рамках текущего рабочего процесса, без нового контракта.
Полная стоимость владения: экономия на разработке не снижает совокупные затраты — она их перераспределяет
Fixed Price фиксирует бюджет на разработку — это реальная и ценная гарантия. Постпродакшн изменения выходят за её рамки и оформляются отдельно: каждое с собственной оценкой и согласованием. Количество таких обращений контракт не ограничивает.
T&M не даёт фиксированного бюджета, но не создаёт и контрактных разрывов между разработкой и дальнейшим развитием продукта. Главный риск — расползание скоупа: без явных границ объём работ может расти незаметно. Управление этим риском — часть работы по модели: регулярные ревью бэклога, согласование приоритетов на каждом спринте, при необходимости бюджетный лимит на период.
Ни одна из моделей не выгоднее другой сама по себе. Если требования стабильны и постпродакшн изменения редки, то FP даёт предсказуемый бюджет без необходимости управлять текущим объёмом. Если продукт будет активно развиваться — T&M избавляет от контрактного цикла на каждое изменение, но требует дисциплины в управлении бэклогом и бюджетом.
