Fixed Price и Time and Material

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

Time and Material уместен там, где объём заранее неизвестен: продуктовая разработка, длительное развитие системы, исследовательские задачи, MVP с проверкой гипотез. Заказчик платит за фактическое время и получает главное преимущество — возможность менять приоритеты каждый спринт без переподписания договора. Взамен он берёт на себя управление: если никто со стороны бизнеса не принимает решений и не контролирует объём, T&M превращается в бесконечный процесс. Работающая практика — потолок бюджета на период, регулярная демонстрация результата и отчётность по задачам, а не по абстрактным часам.

На практике большинство здоровых коммерческих проектов используют гибрид, и это не компромисс, а осознанная схема. Discovery и дизайн — по фиксированной цене, потому что их объём предсказуем и результат материален. Разработка — по T&M с потолком на квартал и понятной ставкой. Поддержка — по абонентской модели с зафиксированным SLA. Такая схема распределяет риск по этапам, где он реально находится, вместо того чтобы делать вид, что весь проект одинаково предсказуем от первого дня до последнего.

Полезная проверка при выборе подрядчика: спросите, что происходит при изменении требований. Ответ «по Fixed Price ничего не меняем, всё в договоре» означает, что вы получите ровно то, что описали полгода назад, включая ошибки. Ответ «по T&M просто добавим спринт» без разговора о бюджете и приоритетах означает отсутствие управления. Здоровый ответ описывает процедуру: как оценивается изменение, кто принимает решение, что выпадает из объёма взамен и как это фиксируется.

Смежные термины

• Техническое заданиеТехническое задание — документ, фиксирующий, что именно должно быть сделано и по каким признакам работа считается принятой: цели, роли, сценарии, требования по экранам, интеграции, нефункциональные требования и отдельный раздел о том, что в проект не входит.
• DiscoveryDiscovery — предпроектное исследование на 1–3 недели, в котором формулируют задачу, изучают пользователей и конкурентов, описывают сценарии и ограничения, а на выходе получают прототип, техническое задание и оценку с обоснованной вилкой вместо цифры из воздуха.
• SLASLA — соглашение об уровне сервиса: в нём зафиксированы доступность системы в процентах, время реакции и время устранения по классам инцидентов, часы работы поддержки и компенсации на случай, если подрядчик эти показатели не выдержал.
• Аутсорс и инхаусАутсорс и инхаус — два способа закрыть потребность в разработке: нанять внешнюю команду по договору с фиксированной стоимостью часа или собрать штат, где к зарплатам добавляются страховые взносы, найм, оборудование и управление.
• Продуктовый бэклогПродуктовый бэклог — упорядоченный по приоритету список всего, что может быть сделано в продукте: он не является планом с датами, постоянно пересматривается, и за порядок в нём отвечает один человек — владелец продукта.

Услуги по теме

• IT-консалтинг и продуктовый аудитСамые дорогие ошибки в разработке делаются до первой строчки кода: неверно понятая задача, стек, выбранный по привычке подрядчика, и ТЗ, которого нет. Консалтинг нужен, чтобы разобраться до того, как начнётся счётчик разработки: что именно строить, из чего, за сколько и в каком порядке. Результат — документ, а не мнение на созвоне.
• Разработка сайтов под ключДелаем сайты, которые не разваливаются через полгода: от одностраничника на CMS до магазина и веб-приложения на React и Next.js. Один подрядчик на дизайн, код, интеграции и запуск.
• Разработка веб-приложений и Telegram Mini AppКогда сайта уже мало и нужен продукт: личный кабинет, дашборд, внутренний сервис или Mini App внутри Telegram. Проектируем архитектуру, пишем бэкенд и фронтенд, доводим до релиза.

Почитать подробнее

• Как выбрать подрядчика на разработку: чек-лист вопросов и красные флагиПрактическое руководство по выбору подрядчика: кому подходит фрилансер, а кому интегратор, какие 25 вопросов задать на первом созвоне, как проверить кейсы в портфолио и что обязательно должно быть в договоре.
• Сколько стоит разработка сайта в 2026: разбор сметы по строкамРазбираем смету на разработку сайта построчно: сколько стоит аналитика, дизайн, вёрстка, бэкенд и интеграции, какие расходы всегда появляются после запуска и на чём можно сэкономить без последствий.
• Техническое задание на сайт: структура, шаблон и разбор ошибокТЗ — это не бюрократия, а рычаг: всё, что не соответствует заданию, подрядчик исправляет бесплатно. Разбираем структуру по разделам, показываем заполненный пример для корпоративного сайта и объясняем, как писать критерии приёмки, которые можно проверить.