Методология в договоре: как выбрать модель работы с подрядчиком

Название «разработка CRM» ещё не говорит, какой договор выдержит проект. Сначала нужно понять, что известно о результате и как стороны будут принимать решения по ходу работы.

В понедельник руководитель продукта получает две сметы на «разработку CRM». В первой описаны роли, интеграции, правила доступа и сценарии продаж. Во второй есть только цель: собрать данные о клиентах в одном месте. Цена в обоих документах выглядит уверенно, хотя у задач разная степень неопределённости.

Привет, я Антон Фокин — CEO Qtim

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

У читателя после статьи останется карта из четырёх моделей: фиксированный этап, оплачиваемый discovery, выделенная команда и ограниченные инкременты. Это не юридический шаблон. Перед подписанием условия проверяет юрист; карта помогает подготовить содержательную часть разговора.

Командам нужно договориться, что считается результатом, как принимаются изменения и кто отвечает за решения. Для этого достаточно четырёх вопросов.

Подробные ответы позволяют разбить работу на проверяемые этапы. Когда в каждом пункте остаются неизвестные, стороны выносят их в отдельный список работ и заранее согласуют процедуру возвращения к плану.

Работа в Information изучила 116 завершённых программных проектов и выявила связь недостаточного раннего анализа и планирования с более слабыми результатами в новых продуктах и модернизации. Авторы не доказывают причинность для отдельной компании, поэтому исследование не позволяет предсказывать исход конкретного проекта. Оно даёт заказчику более узкий вывод: неизвестные не стоит прятать внутри фиксированной цены.

В каждой модели дополнительно нужны роли, критерии готовности, порядок изменения приоритетов и контрольные точки.

Систематический Overview, опубликованный в 2026 году, собирает реальные примеры альтернативных подходов к финансированию и контрактам в Agile-разработке. Его практический вывод для заказчика: способ финансирования и договорная конструкция должны учитывать итеративную работу. Обзор не задаёт единую форму договора и не заменяет юридическую экспертизу.

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

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

Исследование Beyond, основанное на интервью с 23 экспертами и практическом кейсе, предлагает разделять работу на фазу до разработки и итеративный этап во время разработки для задач с высокой неопределённостью. Это исследовательская модель закупки, а не готовый договор для любого рынка. Она подтверждает логику отдельной точки решения после прояснения ключевых зависимостей.

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

Роли нужно закреплять отдельно от названия фреймворка

Одно название фреймворка не фиксирует договорные роли, порядок приоритизации и процедуру изменения объёма. Эти правила стороны записывают отдельно.

В нашем кейсе Poison Drop — e-commerce-продукте с каталогом, профилем и заказами — мы вместе с клиентом развивали frontend, backend, интеграции и инфраструктуру. Клиент задавал продуктовый контекст и приоритеты, а наша команда отвечала за инженерную часть; такое разделение и нужно закрепить в модели совместной работы.

Договор называет как минимум четыре роли:

Такой список убирает типичный тупик: команда ждёт решения, а заказчик считает, что его уже приняли на встрече две недели назад.

Список функций не заменяет механизм управления. Особенно на проектах с регулярными релизами стороны заранее согласуют, как задача попадает в работу, по каким условиям считается готовой и что происходит при изменении приоритетов.

Минимальный набор включает предмет этапа или принцип наполнения бэклога, границы поставки и явные исключения, критерии готовности и приёмки, нефункциональные требования, ритм демо, порядок изменения объёма, доступы, права на результат и условия передачи работ.

Работа Enhancing рассматривает несоответствие закупочных процедур и Agile-разработки в сложных ИТ-проектах. Контекст исследования — государственные закупки, поэтому его нельзя переносить в частный договор буквально. Для бизнеса остаётся применимый вопрос: позволяет ли соглашение команде принимать решения в том же ритме, в котором меняется продукт?

Перед выбором подрядчика возьмите одну спорную функцию и пройдите по ней вместе. Например: «клиент меняет адрес доставки после оформления заказа». Определите владельца сценария, затронутые системы, критерий готовности и процедуру согласования изменения.

Этот тест быстро показывает, подходит ли выбранная модель задаче. Фиксированный этап выдержит ситуацию, когда ответы известны. Discovery нужен, когда ответы предстоит найти. Выделенная команда удобна при постоянном потоке приоритетов. Инкременты помогают выпускать ценность частями и принимать решение после каждого выпуска.

Отраслевой Digital.ai за 2025 год фиксирует интерес к измеримым результатам, прозрачности решений и управлению данными. В опросе участвовало около 350 человек, преимущественно консультанты и Agile-коучи крупных предприятий; это ограничивает обобщения. Тем не менее прозрачность решений — полезный критерий для договора, который должен пережить изменение приоритетов.

Вернёмся к двум сметам на CRM. Для первой можно обсуждать фиксированный этап, потому что результат и проверки описаны. Для второй разумнее купить исследование с ясным выходом и вернуться к цене реализации после прояснения зависимостей.

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

Чтобы пройти этот разбор до выбора модели, обсудите задачу с нашей командой через цель продукта, критичные неизвестные и границы первой поставки.