Стоимость разработки программного обеспечения на заказ

Из чего складывается цена заказной разработки, и как выбрать тип договора и не переплатить?

Аксмор внесён в реестр аккредитованных ИТ-организаций
 
Министерства цифрового развития, связи и массовых коммуникаций Российской Федерации. Аккредитация подтверждает, что основная деятельность компании — разработка и реализация программного обеспечения, а компания соответствует требованиям по ОКВЭД и доле выручки от ИТ-деятельности. Проверить актуальный статус 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 заказчик может в любой момент скорректировать состав команды, приостановить разработку или изменить приоритеты. Это не расторжение договора — это его нормальная механика.

Отраслевая специфика: выбор модели для разных типов проектов

Ритейл и электронная коммерция

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

E-commerce платформа, как правило, запускается итерационно: MVP с базовым каталогом и оплатой, затем интеграции с маркетплейсами, персонализация, логистические сценарии, аналитика. Каждый следующий этап зависит от того, что показал предыдущий. T&M даёт возможность перераспределять ресурсы по данным, а не по первоначальному плану без переоформления договора.

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

Вывод: T&M для платформ и продуктовой разработки; поэтапный FP для ограниченных интеграционных задач.

Производство и промышленная автоматизация

Промышленные проекты нередко выглядят предсказуемыми на старте — техническое задание подробное, логика понятна. Неопределённость здесь другая: физическая среда. Программный продукт взаимодействует с реальным оборудованием, которое работает в режимных условиях. Разработчик получает доступ не к боевой инфраструктуре, а к тестовой среде — эмуляторам, синтетическим данным, упрощённому стенду.

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

Производство и промышленная автоматизация

Промышленные проекты нередко выглядят предсказуемыми на старте — техническое задание подробное, логика понятна. Неопределённость здесь другая: физическая среда. Программный продукт взаимодействует с реальным оборудованием, которое работает в режимных условиях. Разработчик получает доступ не к боевой инфраструктуре, а к тестовой среде — эмуляторам, синтетическим данным, упрощённому стенду.

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

T&M работает итерациями: реализовали на тестовых данных, передаём на проверку, получаем обратную связь, согласовываем следующий шаг. Ни одного часа без понимания, на что он уходит.

Вывод: T&M как единственная модель, при которой ни одна из сторон не берёт на себя риск, который не может оценить.

Логистика и транспорт

Логистические платформы интегрируются с системами, которые разработчик не контролирует: API перевозчиков, таможенные сервисы, системы отслеживания, WMS склада. Документация внешних систем часто устаревает или не соответствует реальному поведению. Добавьте географическую вариативность — разные правила, разные форматы данных, разные граничные случаи по странам — и получите контекст, в котором объём невозможно зафиксировать без существенного резерва.

Интеграционная логика проявляется только в процессе работы. Сценарий, который выглядит однозначным в ТЗ, оказывается исключением из исключения на третьей итерации. T&M позволяет разбираться с этим по мере обнаружения, а не платить заранее за риск, который может не реализоваться.

Гибридная модель используется там, где граница между известным и неизвестным чёткая: например, FP на разработку собственного функционала платформы и 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 избавляет от контрактного цикла на каждое изменение, но требует дисциплины в управлении бэклогом и бюджетом. Карта рисков

Культурные аспекты выбора контрактной модели: российская специфика

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

Логика заказчика понятна. Подпись под фиксированной суммой ощущается как защита: подрядчик взял обязательство, нарушение которого имеет последствия. Time & Materials, напротив, воспринимается как открытый счётчик, который трудно остановить.

Этот страх рационален — но он описывает не модель контракта, а качество отношений с конкретным подрядчиком.

На западных рынках T&M является стандартом именно потому, что там сложилась культура управления процессом: регулярные демо, детальные отчёты о трудозатратах, доступность команды в реальном времени. Подрядчик не исчезает после подписания договора — он работает рядом, и каждый потраченный час виден. Такой формат экономичнее: заказчик платит за то, что сделано, а не за то, что было запланировано год назад. В Fixed Price риски заложены в смету — вы платите за них вне зависимости от того, реализовались они или нет.

Нельзя сказать, что Fixed Price однозначно хуже. Он работает там, где работает: когда требования зрелые, задача хорошо определена, а изменения действительно маловероятны. Проблема в другом: FP слишком часто выбирается не потому что требования готовы, а потому что заказчик недостаточно доверяет подрядчику для другого формата.

Но есть и обратная сторона этого выбора, о которой редко говорят вслух. Fixed Price при высокой неопределённости — это не защита бюджета, это перенос риска внутрь сметы. Подрядчик не берёт риски на себя: он закладывает их в цену. Иногда это 20%, иногда 50% сверху — на случай, если что-то пойдёт не так. Заказчик платит за эти риски вне зависимости от того, реализовались они или нет. Если не реализовались — подрядчик просто зарабатывает больше. Это тоже модель, только непрозрачная. T&M в такой ситуации честнее: мы называем предварительную оценку, объясняем, где и почему неопределённость, и тратим деньги заказчика только на то, что действительно произошло. Когда прозрачность обеспечена инструментально — тайм-трекинг, еженедельные демо, открытый бэклог — T&M перестаёт быть источником тревоги и становится тем, чем является по существу: честным расчётом за честную работу.

Структура и содержание Fixed Price контракта: что важно знать до подписания

Fixed Price работает — когда правильно структурирован. Ключевые элементы контракта с фиксированной ценой:

Техническое задание — фундамент.
Не концепция продукта, а точная спецификация: какие экраны, какая бизнес-логика, какие интеграции, какой объём данных, какие пользовательские роли, какие граничные случаи. Чем точнее ТЗ, тем меньше пространства для разночтений при приёмке. Размытое ТЗ — это не экономия на аналитике, это перенесённый конфликт.

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

Change Management — обязательный раздел.
Самое болезненное место FP-проектов. Каждое изменение требований должно проходить формальную процедуру: запрос изменения, оценка трудоёмкости, дополнительный бюджет, согласование. Без прописанного процесса изменения либо молча включаются в объём за счёт качества, либо становятся предметом конфликта.

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

Гарантийный период — с чёткой границей. Стандартная практика — гарантийный период после сдачи, в течение которого выявленные дефекты устраняются без доплаты. Ключевой момент: явно определить, что считается дефектом (несоответствие ТЗ), а что — новым требованием (оплачивается отдельно).