Как заказать разработку ПО и не слить бюджет: честное сравнение Fixed Price и Time & Materials
Один из самых частых сценариев в заказной разработке: компания решает создать корпоративный портал, клиентский сервис или мобильное приложение. Собирает коммерческие предложения от пяти подрядчиков и видит разброс цен от 1,5 до 9 млн рублей, а по срокам — от «запустим за три месяца» до «минимум год».
В итоге побеждает понятная смета с фиксированной ценой (Fixed Price) на 2,5 млн рублей. Проходит полгода: бюджет исчерпан, релиз переносится в третий раз, подрядчик выставляет допсоглашение на каждый чих, а проект тонет в бесконечных спорах.
Почему фиксация цены редко защищает заказчика и как бизнесу безопасно заходить в заказную разработку? Разбираем механику ценообразования, скрытые ловушки и гибридные модели оплаты.
Главная иллюзия: «Мы зафиксировали смету, значит, защищены»
Когда бизнес заказывает разработку впервые, кажется логичным потребовать: «Посчитайте всё под ключ с фиксированной ценой до копейки и дедлайном в договоре».
Что в этот момент происходит на стороне подрядчика:
- Закладывается коэффициент риска 2 или 2.5. Ни одна опытная студия не подпишется под Fixed Price без подушки безопасности. Если чистая трудоемкость задачи — 100 часов, в смету заложат 180–220 часов на случай форс-мажоров. Вы оплачиваете страхи подрядчика еще до первой строчки кода.
- Срезается качество на финише. Если проект выходит за рамки сметы, команда начинает экономить: убирается автотестирование, упрощается архитектура под нагрузки, пишется хрупкий код — лишь бы формально подписать акты.
- Бюрократизируется любой шаг. Захотели подвинуть кнопку, изменить поле в форме заказа или логику авторизации? Это Change Request. Разработка встает, юристы готовят допсоглашение, сроки сдвигаются на недели.
Сравнение моделей: Fixed Price против Time & Materials
Правило рынка: Fixed Price надежно работает только там, где функционал можно описать математически строго и где исключены изменения в процессе. Если продукт создается с нуля, вводные неизбежно изменятся после первого же тестирования на реальных пользователях.
Гибридный подход: как работают зрелые команды
Чтобы не переплачивать за страхи в Fixed Price и не уйти в неконтролируемые траты по Time & Materials, на практике используют трехэтапную схему
- Фаза аналитики и проектирования (Discovery Phase) — строго Fixed PriceНе начинайте писать код без архитектурного проектирования. На этом этапе оплачивается фиксированная сумма (обычно 10–15% от общего бюджета) за работу системного аналитика, архитектора и UI/UX-дизайнера.
- Что на выходе: интерактивный кликабельный прототип, архитектурная схема, спецификация нефункциональных требований и декомпозиция задач.Результат: осязаемый проект, который уже можно детально и прозрачно оценить в часах у любого подрядчика.
- Разработка базовой версии (MVP) — спринты с лимитом бюджета (Capped T&M)Работа делится на двухнедельные спринты. В начале спринта команда оценивает задачи в часах, а в конце показывает работающий функционал на демо-стенде. Чтобы обезопасить бюджет, в договоре фиксируется предельная верхняя планка (Budget Cap) на ключевой скоуп задач.
- Развитие и поддержка (SLA) — почасовая оплатаПосле релиза проект переводится на сопровождение: оперативное закрытие инцидентов и доработка фичей по фактически затраченному времени.
5 вопросов подрядчику до подписания договора
Эти вопросы на пресейле помогают быстро оценить техническую и юридическую зрелость команды:
- Кому и на каком этапе переходят исключительные права на код?Адекватный ответ: Права передаются заказчику поэтапно по факту подписания промежуточных актов, а разработка с первого дня ведется в Git-контуре клиента.
- Как устроен учет времени и прозрачность процессов?Адекватный ответ: Заказчику предоставляется гостевой доступ в таск-трекер (Jira, Kaiten, YouTrack), к каждому акту прикладываются детализированные тайм-репорты, а демо проводится регулярно раз в 1–2 недели.
- Что входит в гарантийный период после релиза?Адекватный ответ: Бесплатное исправление критических багов по вине команды в течение 1–3 месяцев после сдачи этапа.
- Как закладываются требования безопасности и импортозамещения?Адекватный ответ: Стек подбирается с поддержкой дистрибутивов Linux, тестовые контуры изолированы, архитектура учитывает требования 152-ФЗ.
- Что происходит, если архитектурное решение не справляется с нагрузкой?Адекватный ответ: На этапе Discovery проводится нагрузочное моделирование, а выбор фреймворков и баз данных аргументируется расчетными показателями RPS и объема транзакций.
Разработка цифровых продуктов — это инвестиция в бизнес-актив, а не покупка абстрактных строк кода. Чтобы не сжечь бюджет, проектируйте архитектуру до старта разработки, избегайте попыток загнать сложный продукт в жесткий фикс и работайте только с теми, кто готов к прозрачному учету часов и фиксации прав на код.