Типы контрактов на IT-разработку — как выбрать

Заказчики обращаются к нам с разными задачами: проектирование MVP, разработка IT-продуктов, UX/UI-аудит, дизайн интерфейсов, создание сайтов. У каждого проекта — свои цели, масштабы и условия. Поэтому мы используем несколько форматов сотрудничества: Fixed Price, Time & Materials (T&M), Retainer — и при необходимости комбинируем их между собой.

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

Time & Material

Time and Material — договор, где фиксируется часовая ставка, а объём задач остаётся гибким. Оплачивается фактически затраченное время и другие ресурсы, необходимые для работы.

Представьте, что нанимаете репетитора для подготовки к экзамену: вы не фиксируете итоговый объём занятий, а платите за каждый проведённый урок. Нужно больше — берёте больше. Понадобились дополнительные материалы — оплачиваете отдельно. Всё гибко и по факту. Точно так же работает Time and Material в IT: рассчитываетесь только за фактически потраченные часы и ресурсы.

Преимущества:

• Эластичность — легко добавлять или убирать задачи по ходу проекта.
• Меньше бюрократии — не нужно каждый раз заключать отдельное соглашение, если объём работ изменился.
• Прозрачность — заказчик видит, кто и сколько времени потратил — всё фиксируется, плюс еженедельное планирование и ежемесячные отчёты.
• Оперативность — возможность тестировать гипотезы и быстро реагировать на новые требования.

Недостатки:

• Сложнее прогнозировать бюджет.
• Требует постоянного контроля и взаимодействия с командой.

Когда выгоден формат T&M?

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

Подходит для:

• IT-продуктов с индивидуальными решениями — задачи появляются постоянно, но объём заранее не посчитать.
• Сайтов и сервисов с высокой нагрузкой и регулярно растущей функциональностью.
• Личных кабинетов, интранетов и корпоративных порталов.
• Поддержки и развития продукта, когда наперёд неизвестно, сколько доработок потребуется.

Что предусмотреть в договоре T&M?

Чтобы формат TM работал прозрачно, важно сразу договориться о правилах игры. Это поможет избежать недопонимания и держать процесс под контролем с обеих сторон. Обычно контракт готовит агентство, но если вы на стороне заказчика — обязательно убедитесь, что в нём прописаны:

• Почасовая ставка команды.
• Периодичность отчётности и демо, чтобы вы видели результат;
• Механизм изменения приоритетов и добавления новых задач.
• Способы учёта времени — например, какие инструменты тайм-трекинга используются и как фиксируются часы.

Примеры проектов под Time and Material

Формат TM мы предложили стартапу «Смартби» — сервису подбора автозапчастей. Пользователь описывает проблему в чате, эксперт подбирает детали, оформляет заказ в ближайшем магазине и следит, чтобы всё дошло вовремя.

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

Команда «Смартби» постоянно проверяла гипотезы и докручивала продукт, поэтому модель оплаты за фактически отработанные часы подошла идеально. Она позволила не раздувать бюджет, быстро переключать приоритеты и ускорила путь к product–market fit.

Fixed Price

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

Хороший пример Fixed Price вне IT — ремонт кухни «под ключ». Вы заранее определяете бюджет, сроки, материал и желаемый результат — скажем, новые фасады, плитка и встроенная техника. Подрядчик рассчитывает смету и обещает сдать работу через месяц. Если вы решите заменить плитку на мрамор или добавить подсветку, придётся подписывать допсоглашение и пересчитывать цену.

Преимущества

• Предсказуемый бюджет и сроки. Сразу понятно, сколько стоит продукт и когда он будет готов — удобно защищать бюджет и планировать нагрузку.
• Минимальная вовлечённость. Есть детально согласованное ТЗ — подрядчик работает по нему, вам не нужно ежедневно принимать решения.
• Чёткие ожидания. Обе стороны понимают, что именно будет сделано, без «мы думали иначе».

Недостатки

• Любые изменения — за доплату. Даже маленькая правка может требовать пересчёта и тормозить процесс.
• Долго готовить ТЗ. Чтобы точно посчитать смету, нужно описать всё до мелочей — это отдельный большой этап.
• Риски для качества. Команда обязана уложиться в сроки, и иногда это давит на глубину проработки или смелость решений.
• Минимум гибкости. Новые вводные не вписываются в рамки без допсоглашений и пересмотра условий.

Когда лучше выбрать Fixed Price?

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

• Простые корпоративные сайты и одностраничные лендинги.
• Услуга UX/UI-аудита.
• Разработка фирменного стиля.
• Разработка элементов дизайна или отдельных страниц.

Что предусмотреть в договоре Fixed Price?

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

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

Примеры проектов под Fixed Price

Мы часто предлагаем Fixed Price новым клиентам, когда задача понятная и чётко ограничена — например, UX/UI аудит сайта. Аудит занимает всего 2-3 недели — и заказчик чётко понимает, что получит и за какую сумму.

Так было с онлайн-кинотеатром Flex. Клиент пришёл понять, что мешает пользователям. Мы погрузились в продукт: поговорили с командой, разобрали цели, собрали карту сценариев и проверили сервис на всех устройствах — от смартфона до ТВ.

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

Retainer

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

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

Преимущества

• Стабильность — команда постоянная, знает продукт и работает без долгих «въездов».
• Гибкость в задачах — можно менять приоритеты и корректировать план внутри оговорённого месячного объёма.
• Предсказуемость — удобно планировать загрузку, не нужно искать, нанимать и удерживать специалистов.

Недостатки

• Неиспользованные часы сгорают. Если задач в каком-то месяце меньше — объём всё равно считается израсходованным.
• Часовая ставка может оказаться дороже. Если команда загружена не на 100%, формат получается менее экономичным.

Когда лучше выбрать Retainer?

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

• Нет собственного IT-отдела, но нужен крупный проект, который предстоит запустить, развивать и поддерживать.
• Для запуска MVP — когда нужно оперативно собрать первую версию продукта, проверить гипотезы и дорабатывать дальше.
• Внутренняя команда есть, но её нужно быстро усилить опытными специалистами — без долгого и дорогого найма.
• Для техподдержки — когда продукту требуется регулярное сопровождение, исправление ошибок и доработки.

Что предусмотреть в договоре Retainer?

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

• Объём часов в месяц. Сколько времени команда гарантированно работает над вашим проектом и что входит в это количество.
• Ставка и условия переработок. Как оплачиваются часы сверх лимита и что происходит, если задачи занимают больше времени, чем планировалось.
• Состав и роль команды. Кто работает в команде каждый месяц: дизайнеры, разработчики, менеджер — и в каком объёме.
• Формат отчётности и демо. Как часто команда показывает результаты и в каком виде вы получаете отчёты о выполненных задачах.

Примеры проектов под Retainer

Мы предлагаем Retainer там, где продукт большой и постоянно развивается — как в случае с маркетплейсом автотоваров Emex.

Emex — масштабный маркетплейс с 50 млн товаров и ежедневным поступлением десятков тысяч новых позиций. Мы работали с ним более 5 лет: за клиентом закреплены дизайнеры, арт-директор и продукт-менеджер, которые отлично знают продукт и быстро принимают решения. Фиксированная месячная стоимость делает бюджет предсказуемым и позволяет планировать задачи наперёд.

Гибридный формат

Разработка IT-продуктов часто требует гибкости, поэтому мы комбинируем модели сотрудничества. Например, аналитику на старте почти всегда делаем по Fixed Price, а продолжаем в другом формате — и вот почему.

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

Во-вторых, новым клиентам проще заходить в сотрудничество именно с фиксированной ценой за услугу. На старте ещё нет уверенности, насколько комфортно нам будет работать вместе, а Fixed Price даёт понятные рамки и гарантии.

Подход FFF

FFF — это не договор, а подход к разработке IT-продуктов, который помогает нам сочетать дисциплину и гибкость. Он строится на трёх принципах:

• Fix Time — есть конкретный дедлайн, к которому мы запустим продукт.
• Fix Budget — клиент заранее знает бюджет проекта.
• Flex Scope — гибкий функционал — фичи, которые не влезают в рамки, переносятся на следующий этап, не тормозя весь процесс.

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

Преимущества

• Фокус на приоритетах — команда концентрируется на том, что двигает продукт вперёд, а не на десятках мелких фич.
• Быстрый релиз и обратная связь — MVP или первый этап продукта можно сразу тестировать с реальными пользователями.
• Снижение рисков перерасхода времени и бюджета — не тратите ресурсы на ненужные функции.

Недостатки

• Не подходит для продуктов с фиксированным и полным набором функций, так как часть идей переходит на следующий этап.
• Требует дисциплины в планировании и приоритизации задач, иначе Flex Scope может превратиться в хаос.
• Может быть сложно оценить финальный объём работ на старте — часть функций уточняется по ходу проекта.

Когда выгоден формат FFF?

Этот подход отлично работает, когда нужен быстрый и сфокусированный запуск — без потери гибкости и без ухода в долгострой.

FFF стоит выбирать: на старте IT-продукта, когда много идей, но не все они приоритетны. Когда нужно быстро собрать MVP и протестировать гипотезы. Когда бюджет ограничен, но сроки критичны.

Александр Солтан CEO

Что предусмотреть в договоре FFF?

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

• Фиксированные сроки и бюджет — с дедлайном запуска и окончательной суммой.
• Приоритеты функционала. Список того, что входит в MVP, а что — во вторую и последующие итерации.
• Процесс изменения объёма задач. Кто принимает решения, как согласовываются изменения и на основании чего задачи поднимаются или опускаются в списке.
• Критерии готовности продукта. Что считается завершённым этапом и в каком виде команда передаёт результат.
• Формат коммуникации. Периодичность созвонов, демо, статусов — чтобы все были в курсе прогресса и быстро реагировали на изменения.

Примеры проектов под FFF

Мы использовали подход FFF при разработке платформы Freedom Football Manager для молодежной футбольной лиги Казахстана. Создали и запустили MVP, который собрал воедино игры, команды, календарь, статистику, базу знаний и аналитику — при этом платформа полностью заменяет зарубежные аналоги, не адаптированные под местные реалии.

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

Какой формат договора на IT-разработку выбрать

Выбор модели зависит от целей, бюджета и стадии проекта:

• Fixed Price — когда есть чёткое ТЗ и ограниченный бюджет.
• Time and Material — когда продукт требует гибкости, постоянных изменений и тестирования гипотез.
• Retainer — для больших продуктов с постоянной поддержкой и развитием.
• FFF — для ранних MVP и проектов с ограниченными ресурсами.

В идеале команды комбинируют модели: например, анализ и UX-аудит по Fixed Price, а последующую разработку и поддержку — по TM или Retainer. Так вы получаете прозрачный бюджет, контроль и гибкость для роста продукта.