Как выбрать модель договора с подрядчиком на разработку ПО
Как выбрать модель договора с подрядчиком на разработку ПО? Сначала нужно понять, что известно о результате, каких решений пока нет и как стороны будут управлять изменениями.
Две задачи могут называться одинаково, хотя для одной уже известны роли, интеграции и критерии запуска, а для другой определён только желаемый эффект. Для них нужны разные договорённости о работах.
Страница даёт карту из четырёх моделей: фиксированный этап, оплачиваемый discovery, выделенная команда и ограниченные инкременты. Это не юридический шаблон: перед подписанием условия проверяет юрист.
Сначала измерьте неопределённость задачи
Выбор начинается с четырёх вопросов: какой пользовательский результат нужен к конкретной дате; какие интеграции, данные, роли и ограничения подтверждены; кто расставляет приоритеты со стороны заказчика; что жёстче ограничено — бюджет, срок, набор функций или ёмкость команды.
Подробные ответы позволяют разбить работу на проверяемые этапы. Когда ответов нет, стороны выносят неизвестные в отдельный список работ и заранее согласуют процедуру возвращения к плану.
Работа в Information изучила 116 завершённых программных проектов и выявила связь недостаточного раннего анализа и планирования с более слабыми результатами. Авторы не доказывают причинность для отдельной компании.
Четыре модели, которые решают разные задачи
В каждой модели дополнительно нужны роли, критерии готовности, порядок изменения приоритетов и контрольные точки.
Систематический Overview 2026 года собирает реальные примеры альтернативных подходов к финансированию и контрактам в Agile-разработке. Он не задаёт единую форму договора и не заменяет юридическую экспертизу.
Когда discovery снимает лишние обязательства
Discovery нужен, когда цена зависит от ответов, которых пока нет: где лежат данные клиентов, какие роли должны видеть историю заказов и как система свяжется с учётной платформой.
Заказчик и подрядчик фиксируют в первом этапе карту сценариев, перечень интеграций, вариант архитектуры, уточнённый бэклог, оценку следующих работ и список рисков. До старта они определяют, кто принимает артефакты и какое решение последует по итогу.
Исследование Beyond предлагает разделять работу на фазу до разработки и итеративный этап при высокой неопределённости. Это исследовательская модель закупки, а не готовый договор для любого рынка.
Обсудить формат разработки с командой Qtim можно после фиксации границ первой поставки и списка неизвестных.
Роли нужно закреплять отдельно от названия фреймворка
Одно название фреймворка не фиксирует договорные роли, порядок приоритизации и процедуру изменения объёма. Эти правила стороны записывают отдельно.
В нашем кейсе Poison Drop мы развивали e-commerce-продукт с каталогом, профилем и заказами. В Qtim вместе с клиентом развивали frontend, backend, интеграции и инфраструктуру; разделение продуктового контекста и инженерной части показывает, почему роли стоит закреплять в модели совместной работы.
В любой модели стороны называют владельца продуктового решения, представителя подрядчика по инженерным решениям и оценке рисков, тех, кто принимает этап, и участников эскалации.
В договоре должны жить правила изменений и проверки качества
Список функций не заменяет механизм управления. Договору нужны предмет этапа или принцип наполнения бэклога, границы поставки и исключения, критерии готовности и приёмки, нефункциональные требования, ритм демо, порядок изменения объёма, доступы, права на результат и условия передачи работ.
Работа Enhancing рассматривает несоответствие закупочных процедур и Agile-разработки в сложных ИТ-проектах. Контекст исследования — государственные закупки, поэтому его нельзя переносить в частный договор буквально.
Проверяйте модель на одном решении
Возьмите спорную функцию: например, изменение адреса доставки после оформления заказа. Вместе определите владельца сценария, затронутые системы, критерий готовности и процедуру согласования изменения.
Фиксированный этап подходит при известных ответах. Discovery помогает найти ответы. Выделенная команда удобна при постоянном потоке приоритетов. Инкременты позволяют выпускать ценность частями и принимать решение после каждого выпуска.
Отраслевой Digital.ai за 2025 год фиксирует интерес к измеримым результатам, прозрачности решений и управлению данными. В опросе участвовало около 350 человек, преимущественно консультанты и Agile-коучи крупных предприятий; это ограничивает обобщения.
Правило выбора: зафиксируйте управляемое, исследуйте неизвестное
Договор фиксирует то, что стороны уже умеют проверить, и задаёт процедуру для всего, что ещё предстоит выяснить.
Команда Qtim поможет обсудить задачу через цель продукта, критичные неизвестные и границы первой поставки.
