Заказная разработка

Заказная разработка ПО под ключ 2026: контракты и цена

Q: В чём принципиальная разница между fixed price и T&M?

Fixed price — контракт на конкретный результат за фиксированную цену с фиксированной датой. Вы платите за результат, вендор берёт на себя риск превышения сроков и трудозатрат. Подходит для проектов с понятным объёмом работ. T&M (Time and Materials) — контракт на оплату фактически отработанных часов команды по согласованным ставкам. Вы платите за процесс, риск превышения объёма работ — на вашей стороне. Подходит для гибких задач с эволюционирующим объёмом работ. На рынке T&M используется для аутстафф-модели, fixed price — для подряда под ключ. Промежуточные варианты (capped T&M с потолком, milestone-based с привязкой к этапам) существуют, но в чистом виде встречаются реже.

Q: Когда fixed price выгоднее, когда T&M?

Fixed price выгоднее, когда: объём работ можно зафиксировать на 6-16 недель; есть конкретная дата релиза; нужен жёсткий бюджетный контроль; нет внутреннего тимлида для управления командой. Бизнес получает предсказуемость, но платит наценку 20-40% за принятие риска вендором. T&M выгоднее, когда: объём работ эволюционирует по ходу работы; есть R&D-составляющая; нужна гибкость в приоритетах; есть зрелая in-house команда с тимлидом для управления; задача длится 3-12+ месяцев. Бизнес получает гибкость, но принимает на себя риск превышения бюджета. На практике fixed price выгоднее для конкретных roadmap-задач длиной квартал, T&M — для долгих эволюционирующих проектов и расширения in-house команды.

Q: Что такое capex vs opex и как это влияет на выбор контракта?

Capex (capital expenditure) — капитальные затраты, инвестиции в создание активов. Учитываются в балансе как актив, амортизируются за 3-5 лет. Opex (operating expenditure) — операционные расходы, списываются в текущем периоде. Для разработки ПО: разработка нового продукта или существенного нового функционала может учитываться как capex (создание актива в виде ПО, признаваемого по МСФО 38 или РСБУ ПБУ 14). Текущая поддержка, мелкие доработки, аутстафф на «добавление часов команде» — учитываются как opex. Это влияет на выбор контракта: fixed price проект на создание нового модуля удобнее провести как capex (один контракт на актив, активация по приёмке). T&M-проект на эволюционную разработку обычно opex. Если у компании жёсткий opex-бюджет и доступен capex — fixed price даёт дополнительный плюс. Конкретное налоговое и бухгалтерское оформление зависит от вашего CFO и аудитора, но это реальный фактор выбора.

Q: Какие риски у fixed price и как защититься?

Главные риски fixed price на стороне клиента: 1) Размытый объём работ в контракте → споры о том, что входит. Защита — детальный объём работ с критериями приёмки, предпроектное обследование 1-2 недели до подписания. 2) Плохое качество кода в попытке вендора уложиться в бюджет → проблемы при поддержке. Защита — двухуровневое code review (вендор + in-house tech lead), стандарты кода в контракте, промежуточные приёмки. 3) Минимальный объём изменений после старта — каждый change request оплачивается отдельно. Защита — буфер 15-20% в первоначальном бюджете на ожидаемые CR. 4) Дисфункция при недооценке вендором — он начинает сокращать качество, чтобы уложиться. Защита — выбор зрелого вендора с маржой, чтобы изменения сценария не били по качеству. Главное правило — потратить время на этап предпроектного обследования до подписания. Это снижает все четыре риска.

Q: Какие риски у T&M и как защититься?

Главные риски T&M: 1) Открытый бюджет — может разрастись на 30-100% от первоначальной оценки. Защита — capped T&M с потолком (вендор обязуется не превышать N часов), еженедельный controlling часов, ежемесячная review. 2) Нет гарантии даты релиза — никто извне за неё не отвечает. Защита — milestone-based-структура с привязкой части оплаты к датам. 3) Junior-подмена — вендор ставит middle/junior под видом senior. Защита — CV-skip перед стартом, контроль грейдов в команде, периодический code-review клиента. 4) Низкая дисциплина объёма работ — команда работает над разными задачами без фиксации объёма работ per-sprint. Защита — еженедельный sprint planning с чёткими целями. 5) Привязка к подрядчику через накопление knowledge — аутстафф-команда становится незаменимой. Защита — документация ADR, парное программирование, регулярный knowledge transfer. T&M требует зрелого in-house тимлида для управления — это главная организационная защита.

Q: Что должно быть в контракте на разработку?

Стандартная структура контракта разработки под ключ. 1) Стороны, предмет, общие положения. 2) Объём работ (приложение 1) — детальный документ с функциями и критериями приёмки. 3) Состав команды (приложение 2) — грейды и рейты per-person. 4) График работ — milestones, контрольные точки. 5) График платежей — обычно 30% при подписании, 30% при промежуточной приёмке, 40% при сдаче. 6) Acceptance procedure — как клиент проверяет результат, сроки приёмки, процедура замечаний. 7) Change requests — как оформляются и оплачиваются изменения объёма работ. 8) SLA-период — что входит в гарантию после сдачи. 9) Передача — что включает, ответственности сторон, метрика готовности. 10) IP и code ownership — переход прав на код клиенту. 11) Конфиденциальность и NDA. 12) Ответственность сторон, штрафы за нарушение SLA и сроков. 13) Разрешение споров — обычно арбитраж в России. 14) Применимое право — РФ. Контракт стандартно 20-40 страниц для проекта под ключ, согласуется 1-2 недели юристами обеих сторон.

Гайд для CTO и CFO: заказная разработка ПО под ключ — модели контрактов (fixed price vs T&M), цена за квартал, capex vs opex, защита от рисков, типовые ошибки.

Обновлено: 15 мая 2026 г.

Что это и что это НЕ: Эта статья — про коммерческую заказную разработку ПО под ключ (контракт на результат, fixed price и T&M). Это не про лицензионные контракты на готовое ПО. И не про разработку MVP с нуля (для этого см. primeit.ru/razrabotka-mvp/). И не про SaaS-разработку с подписочной моделью (см. jitech.ru/razrabotka-saas/).

Заказная разработка ПО под ключ — это не просто «нанять команду и получить код». Это контракт, который определяет, что именно вы покупаете, по какой цене, в какие сроки и с какими гарантиями. В заказной разработке выбор между fixed price и T&M-моделями определяет распределение рисков между клиентом и вендором, бюджетную определённость, гибкость объёма работ и управленческую нагрузку клиента. Это не юридическая формальность, а стратегическое решение CTO и CFO, влияющее на весь ход проекта.

Эта статья — для CTO, CFO и руководителя проекта, который выбирает модель заказной разработки и структуру контракта. Внутри: разбор fixed price и T&M, промежуточные форматы, capex vs opex как фактор выбора, типовые риски и защита, стандартная структура контракта на заказную разработку.

Fixed price vs T&M: что покупается

Fixed price (FP). Контракт на конкретный результат за фиксированную цену с фиксированной датой релиза. Клиент платит за результат. Вендор принимает на себя риск превышения сроков и трудозатрат — если работа займёт больше часов, чем заложено в бюджет, это убыток вендора, не клиента. Подходит для проектов с понятным и зафиксированным объёмом работ. На рынке используется для модели разработки под ключ.

T&M (Time and Materials). Контракт на оплату фактически отработанных часов команды по согласованным ставкам. Клиент платит за процесс — за человеко-часы команды. Риск превышения объёма работ на стороне клиента: если задача займёт в два раза больше часов, чем планировалось, клиент заплатит за все эти часы. Подходит для гибких задач с эволюционирующим объёмом работ. На рынке используется для аутстафф-модели.

Параметр	Fixed price	T&M
Что покупается	Результат	Часы команды
Кто несёт риск превышения	Вендор	Клиент
Бюджетная определённость	Полная	Открытая
Дата релиза	Гарантирована контрактом	Планирует клиент
Критерии приёмки	В контракте, формальные	Клиент определяет сам
Гибкость объёма работ	Через change requests	Высокая
Управленческая нагрузка клиента	Низкая	Высокая
Подходит для	Конкретный объём работ с дедлайном	R&D, расширение команды
Маржа вендора (наценка за риск)	20-40% выше T&M	Базовая

Decision tree: какую модель выбрать

Вопрос 1. Можно ли зафиксировать объём работ? Если объём работ понятен, измерим, требования стабильны на 6-16 недель — fixed price работает. Если объём работ эволюционирует, требования формируются по ходу, есть R&D-составляющая — T&M.

Вопрос 2. Насколько критична дата релиза? Если есть жёсткий roadmap-дедлайн, привязанный к внешнему событию (запуск, контракт с партнёром, регуляторный дедлайн) — fixed price гарантирует дату. Если дата плавающая — T&M даёт гибкость.

Вопрос 3. Какая у клиента бюджетная дисциплина? Если бюджет жёсткий, утверждённый раз в год, изменения не приветствуются — fixed price даёт предсказуемость. Если бюджет гибкий, можно его докрутить по ходу — T&M работает.

Вопрос 4. Есть ли in-house тимлид для управления командой? Если нет — fixed price (вендор управляет своей командой). Если есть зрелый тимлид со свободной загрузкой 40-60% — T&M может работать.

Вопрос 5. Тип задачи. Конкретный результат (фича, модуль, интеграция) на квартал → fixed price. Эволюционная разработка ядра продукта, R&D, расширение in-house команды → T&M.

Capex vs opex как фактор выбора

Это часто упускаемый фактор в выборе модели контракта, но он реально влияет на финансовые показатели компании.

Capex (capital expenditure) — капитальные затраты, инвестиции в создание долгосрочных активов. По МСФО 38 (Intangible Assets) и РСБУ ПБУ 14/2007 разработка ПО, отвечающая критериям нематериального актива, может учитываться как capex. Условия: ПО создаёт будущие экономические выгоды; стоимость надёжно оценивается; компания контролирует использование. Capex учитывается в балансе как нематериальный актив и амортизируется обычно за 3-5 лет.

Opex (operating expenditure) — операционные расходы, списываются в текущем периоде. Текущая поддержка ПО, мелкие доработки, исправление багов, аутстафф на «добавление часов команде» — это opex.

Как это влияет на выбор контракта. Fixed price проект на создание нового модуля или сервиса с понятным результатом легче провести как capex: один контракт на создание актива, активация по приёмке, амортизация. T&M-проект на эволюционную разработку обычно opex: вы покупаете часы команды, а не создание актива.

Для компании с жёстким opex-бюджетом и доступным capex это реальный фактор. Например, бюджет opex полностью исчерпан, но есть capex-резерв на инвестиции в продукт. Fixed price-проект на новый модуль попадает в capex и не нагружает opex. Аутстафф с T&M-контрактом на квартал — opex, который нагрузит уже исчерпанный бюджет.

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

Промежуточные форматы контрактов

Между чистым fixed price и чистым T&M есть промежуточные варианты, которые дают компромисс.

Capped T&M. T&M с потолком: вендор обязуется не превысить N часов или сумму M рублей. После потолка вендор оплачивает превышение из своей маржи. Гибкость T&M + бюджетная определённость fixed price. Подходит для проектов с понятным upper bound, но эволюционирующим объёмом работ.

Milestone-based fixed price. Фиксированная цена за каждую веху проекта; вехи определяются на старте, но объём работ каждой вехи может корректироваться. Платежи привязаны к приёмке milestones. Подходит для длинных проектов 6+ месяцев, где объём работ первой вехи понятен, а последующие — формируются по ходу.

Fixed price + hourly extension. Фиксированная цена за основной объём работ + почасовая оплата за изменения и дополнительные функции через change requests. Защищает от споров о CR. Подходит для проектов, где основной объём работ понятен, но известно, что в процессе будут изменения.

Time-boxed с фиксированным составом. Команда фиксированного состава на N месяцев за фиксированную цену. Внутри этого времени объём работ гибкий, клиент управляет приоритетами. Это гибрид fixed price (фиксированная цена и время) и T&M (гибкость объёма работ). Подходит для длинных проектов разработки или для аутстаффа с бюджетной дисциплиной.

Промежуточные форматы используются примерно в 30-40% проектов на 2026 год. Чистый fixed price — около 35-45%, чистый T&M — около 20-25%.

Структура контракта на разработку

Стандартная структура контракта разработки под ключ.

1. Преамбула. Стороны, предмет договора, общие положения.

2. Приложение 1: объём работ. Детальный документ с функциями и критериями приёмки. Это главный документ, на который ссылаются все споры. На крупный проект — 20-50 страниц.

3. Приложение 2: состав команды. Грейды каждой роли, имена или anonymized profiles (CV-skip от клиента до старта), рейты per-person.

4. Приложение 3: график работ. Milestones, контрольные точки, промежуточные приёмки.

5. График платежей. Стандарт для проекта под ключ — 30% при подписании, 30% при промежуточной приёмке, 40% при сдаче. Для длинных проектов — milestone-based с привязкой 25% к каждой основной вехе.

6. Acceptance procedure. Как клиент проверяет результат, сроки приёмки (обычно 5-10 рабочих дней), процедура замечаний, число итераций по замечаниям, что такое финальный sign-off.

7. Change requests. Как оформляются и оплачиваются изменения объёма работ. Стандартная процедура: CR-документ с описанием изменения и его оценкой по часам и срокам, подписание клиентом и вендором, обновление объёма работ в контракте.

8. SLA-период. Что входит в гарантию после сдачи. Стандарт — 1-3 месяца с уровнями P1 < 4 часов, P2 < 24 часов, P3 < 5 рабочих дней. Что входит в SLA (баги в коде вендора), что не входит (новый функционал — CR; проблемы клиента — opex клиента).

9. Передача. Что включает передача, ответственности сторон, метрика готовности («первое срочное исправление без нашего участия»), что включается в стоимость, что — отдельно.

10. IP и code ownership. Весь код, который вендор пишет для клиента, переходит в его собственность с момента оплаты соответствующего этапа. Никаких исключений в виде «общих библиотек вендора».

11. Конфиденциальность и NDA. Стандартный NDA, обязательства о неразглашении после окончания проекта.

12. Ответственность сторон. Штрафы за нарушение SLA и сроков. Стандарт — 0.1-0.3% от стоимости проекта за каждый день просрочки сдачи, до 10-20% от общей суммы.

13. Разрешение споров. Обычно арбитраж в России (МКАС при ТПП РФ или другие коммерческие арбитражи).

14. Применимое право. РФ для внутрироссийских контрактов.

Объём контракта. 20-40 страниц для проекта под ключ средней сложности. Юридическое согласование — 1-2 недели для обеих сторон.

Типовые ошибки в контрактах

Ошибка 1: Размытый объём работ в контракте. Контракт подписан с объёмом работ «сделать платёжный модуль». Через 3 недели — споры. Защита — детальный объём работ с критериями приёмки, предпроектное обследование 1-2 недели до подписания.

Ошибка 2: Отсутствие процедуры change requests. Изменения вносятся «на словах», без формального оформления. К концу проекта — споры о том, что входит в финальную приёмку. Защита — формальная процедура CR с подписанием каждого изменения.

Ошибка 3: Слишком жёсткий или слишком мягкий SLA. P1 < 1 часа с штрафом 5% за каждый час — нереалистично, ни один вендор не подпишет. P1 без штрафа — никто не торопится. Стандарт — P1 < 4 часов с штрафом 0.1-0.3% за день просрочки.

Ошибка 4: IP-неопределённость. В контракте не сформулирован переход прав на код. Через год клиент использует код в новых продуктах, а вендор требует роялти. Защита — явная формулировка перехода прав с момента оплаты.

Ошибка 5: Отсутствие плана передачи в контракте. «Передача — по обычной процедуре» — это ничего не значит. Защита — детальный план передачи в контракте с конкретными активностями и метрикой готовности.

Ошибка 6: Отсутствие потолка штрафов. Штрафы безлимитные — вендор не подписывает или подписывает с риском. Стандарт — потолок штрафов 10-20% от общей суммы контракта.

Ошибка 7: Подписание без юридической проверки на стороне клиента. Контракт пишет вендор, клиент подписывает «как есть». Защита — обязательная юридическая проверка договоров на стороне клиента, особенно по разделам IP, ответственности, разрешения споров.

Что выбирать в типовых ситуациях

Ситуация: квартальный roadmap-дедлайн, новая фича к продукту. Fixed price на проект под ключ. 6-12 недель, 1.5-4 млн рублей, гарантия даты, формальная приёмка.

Ситуация: расширение in-house команды на квартал под пиковый релиз. T&M на аутстафф. 2-3 senior на 3-4 месяца, бюджет 4-12 млн рублей, гибкое управление приоритетами.

Ситуация: длинная программа разработки на 6-12 месяцев. Milestone-based fixed price с фиксированными ценами за вехи. Каждая веха — отдельная приёмка, отдельный риск.

Ситуация: R&D-проект с неопределённым объёмом работ. T&M или capped T&M. Время-ограниченный эксперимент с лимитом часов и регулярной review.

Ситуация: миграция функционала с одного стека на другой. Fixed price на миграцию под ключ. Понятный начальный и конечный объём работ, время на этап предпроектного обследования 2-3 недели, исполнение 8-16 недель.

Ситуация: интеграция с внешней системой. Fixed price на интеграцию под ключ с буфером 15-20% на change requests (внешние API часто оказываются сложнее документации).

Сопутствующие материалы — разработка под ключ, разработчики на проект 2026, аутстафф vs под ключ, найм senior-разработчика vs под ключ, фича под ключ: как принять результат.

Сравнительная таблица: модели контрактов разработки

Параметр	Fixed price	Time & Materials (T&M)	Outcome-based
Цена	Зафиксирована в контракте	Часовая ставка × фактические часы	Привязана к бизнес-результату
Риск перерасхода	На подрядчике	На заказчике	На обеих сторонах
Гибкость объёма работ	Низкая (через change request)	Высокая	Средняя
Прозрачность работ	Низкая (важен результат)	Высокая (timesheet)	Зависит от метрики
Подходит для	Чёткий объём работ, дедлайн, измеримое	Гибкий объём работ, длинная разработка	Платформы с измеримой ценностью
Типичный аванс	30-50%	10-20% за период	Зависит от контракта
Стандартные штрафы за просрочку	0,5-1% / день от стоимости	Нет (платится за факт)	Размыкается выплата

Fixed price подходит для формата под ключ: объём работ измерим, дедлайн критичен, заказчик хочет переложить риск на подрядчика. T&M — для длинной разработки с эволюцией требований. Outcome-based — для зрелых партнёрств, где обе стороны имеют общий измеримый KPI (выручка, конверсия, активные пользователи).

Структура fixed price контракта на разработку

Типовой fixed price контракт между зрелой продуктовой компанией и подрядчиком под ключ на сумму 3-5 млн рублей включает:

Предмет контракта. Конкретный результат: фича, модуль, интеграция. Отсылка к приложению с объёмом работ и критериями приёмки.
Сроки. Дата начала, milestones, дата сдачи, окно опытной эксплуатации.
Цена и порядок расчётов. Аванс (30-50%), промежуточный платёж по milestone (20-30%), финальный платёж после приёмки (30-40%).
Критерии приёмки. Отдельное приложение, фиксирует каждый критерий приёмки. Подписывается обеими сторонами до старта.
Состав результата. Код, тесты, документация, инструкция по эксплуатации, передача. Что именно передаётся в собственность заказчика.
Передача. 30-60 дней, состав работ, метрика готовности «первое срочное исправление без вендора».
SLA-период. 1-3 месяца после сдачи с фиксированными временами реакции.
Штрафы и пени. За просрочку (1/300 ЦБ или 0,5-1% / день), за нарушение SLA, за несоответствие критериям приёмки.
Право собственности на код. Передаётся заказчику с момента оплаты соответствующего milestone.
Конфиденциальность и NDA. Расширенный режим, особенно для fintech/healthtech.

Антипример: T&M-контракт без верхней границы

Компания заказала у подрядчика «разработку аналитического дашборда» по модели T&M со ставкой 4500 ₽/час и оценочной сметой 1500 часов. Контракт не содержал верхней границы и критериев приёмки — только описание функционала. К концу 18-й недели подрядчик предъявил счёт на 2100 часов (на 40% больше сметы) с обоснованием «новые требования, обнаруженные в ходе разработки». Заказчик согласился, поскольку остановка работ означала бы потерю инвестиций. Через 24 недели — счёт на 2800 часов. Итого вместо запланированных 6,75 млн рублей проект обошёлся в 12,6 млн. Урок: T&M без либо подробной change-request процедуры, либо «not to exceed» ограничения превращается в открытую расходную статью.

Источники по теме контрактов

ГК РФ, глава 38 — договор подряда, базовая юридическая рамка.
Хабр Юрист, статьи на habr.com/ru/articles — практика судебных споров по IT-контрактам.
martinfowler.com/articles — Continuous Delivery, change requests в Agile-контрактах.
PMI Practice Standard for Contract Management — международные практики (опционально).

Стандартные штрафные санкции в IT-контрактах РФ

Нарушение	Типовая санкция
Просрочка сдачи финального результата	0,5-1% от стоимости контракта / день, лимит 10%
Нарушение SLA P1 (production down)	Возврат 100% месячной оплаты SLA + штраф 100 тыс. ₽
Нарушение SLA P2	Возврат 50% месячной оплаты SLA
Несоответствие критериям приёмки	Удержание оплаты до устранения
Утечка конфиденциальной информации	До 5 млн ₽ + возмещение убытков
Нарушение прав на код	Возврат 100% оплаты + штраф

Эти санкции — стандарт российского IT-рынка для контрактов 2-10 млн рублей. Для крупных контрактов (от 20 млн рублей) ставки штрафов могут быть выше, для микро-контрактов (до 1 млн) — ниже.

Связанные материалы — фича под ключ, разработка под ключ, аутстафф vs под ключ.

FAQ о заказная разработка

В чём принципиальная разница между fixed price и T&M?

Fixed price — контракт на конкретный результат за фиксированную цену с фиксированной датой. Вы платите за результат, вендор берёт на себя риск превышения сроков и трудозатрат. Подходит для проектов с понятным объёмом работ. T&M (Time and Materials) — контракт на оплату фактически отработанных часов команды по согласованным ставкам. Вы платите за процесс, риск превышения объёма работ — на вашей стороне. Подходит для гибких задач с эволюционирующим объёмом работ. На рынке T&M используется для аутстафф-модели, fixed price — для подряда под ключ. Промежуточные варианты (capped T&M с потолком, milestone-based с привязкой к этапам) существуют, но в чистом виде встречаются реже.

Когда fixed price выгоднее, когда T&M?

Fixed price выгоднее, когда: объём работ можно зафиксировать на 6-16 недель; есть конкретная дата релиза; нужен жёсткий бюджетный контроль; нет внутреннего тимлида для управления командой. Бизнес получает предсказуемость, но платит наценку 20-40% за принятие риска вендором. T&M выгоднее, когда: объём работ эволюционирует по ходу работы; есть R&D-составляющая; нужна гибкость в приоритетах; есть зрелая in-house команда с тимлидом для управления; задача длится 3-12+ месяцев. Бизнес получает гибкость, но принимает на себя риск превышения бюджета. На практике fixed price выгоднее для конкретных roadmap-задач длиной квартал, T&M — для долгих эволюционирующих проектов и расширения in-house команды.

Что такое capex vs opex и как это влияет на выбор контракта?

Capex (capital expenditure) — капитальные затраты, инвестиции в создание активов. Учитываются в балансе как актив, амортизируются за 3-5 лет. Opex (operating expenditure) — операционные расходы, списываются в текущем периоде. Для разработки ПО: разработка нового продукта или существенного нового функционала может учитываться как capex (создание актива в виде ПО, признаваемого по МСФО 38 или РСБУ ПБУ 14). Текущая поддержка, мелкие доработки, аутстафф на «добавление часов команде» — учитываются как opex. Это влияет на выбор контракта: fixed price проект на создание нового модуля удобнее провести как capex (один контракт на актив, активация по приёмке). T&M-проект на эволюционную разработку обычно opex. Если у компании жёсткий opex-бюджет и доступен capex — fixed price даёт дополнительный плюс. Конкретное налоговое и бухгалтерское оформление зависит от вашего CFO и аудитора, но это реальный фактор выбора.

Какие риски у fixed price и как защититься?

Главные риски fixed price на стороне клиента: 1) Размытый объём работ в контракте → споры о том, что входит. Защита — детальный объём работ с критериями приёмки, предпроектное обследование 1-2 недели до подписания. 2) Плохое качество кода в попытке вендора уложиться в бюджет → проблемы при поддержке. Защита — двухуровневое code review (вендор + in-house tech lead), стандарты кода в контракте, промежуточные приёмки. 3) Минимальный объём изменений после старта — каждый change request оплачивается отдельно. Защита — буфер 15-20% в первоначальном бюджете на ожидаемые CR. 4) Дисфункция при недооценке вендором — он начинает сокращать качество, чтобы уложиться. Защита — выбор зрелого вендора с маржой, чтобы изменения сценария не били по качеству. Главное правило — потратить время на этап предпроектного обследования до подписания. Это снижает все четыре риска.

Какие риски у T&M и как защититься?

Главные риски T&M: 1) Открытый бюджет — может разрастись на 30-100% от первоначальной оценки. Защита — capped T&M с потолком (вендор обязуется не превышать N часов), еженедельный controlling часов, ежемесячная review. 2) Нет гарантии даты релиза — никто извне за неё не отвечает. Защита — milestone-based-структура с привязкой части оплаты к датам. 3) Junior-подмена — вендор ставит middle/junior под видом senior. Защита — CV-skip перед стартом, контроль грейдов в команде, периодический code-review клиента. 4) Низкая дисциплина объёма работ — команда работает над разными задачами без фиксации объёма работ per-sprint. Защита — еженедельный sprint planning с чёткими целями. 5) Привязка к подрядчику через накопление knowledge — аутстафф-команда становится незаменимой. Защита — документация ADR, парное программирование, регулярный knowledge transfer. T&M требует зрелого in-house тимлида для управления — это главная организационная защита.

Какие промежуточные форматы контрактов существуют?

Между чистым fixed price и чистым T&M есть промежуточные варианты. 1) Capped T&M — T&M с потолком: вендор обязуется не превысить N часов, после потолка оплачивает превышение из своей маржи. Гибкость T&M + бюджетная определённость fixed price. Подходит для проектов с понятным upper bound, но эволюционирующим объёмом работ. 2) Milestone-based fixed price — fixed price за каждую веху проекта; вехи определяются на старте, но объём работ каждой вехи может корректироваться. Подходит для длинных проектов 6+ месяцев. 3) Fixed price + hourly extension — fixed price за основной объём работ + почасовая оплата за изменения и дополнительные функции. Защищает от споров о CR. 4) Time-boxed с фиксированным составом — команда фиксированного состава на N месяцев за фиксированную цену; внутри этого времени объём работ гибкий. Промежуточные форматы дают компромисс между предсказуемостью и гибкостью.

Что должно быть в контракте на разработку?

Стандартная структура контракта разработки под ключ. 1) Стороны, предмет, общие положения. 2) Объём работ (приложение 1) — детальный документ с функциями и критериями приёмки. 3) Состав команды (приложение 2) — грейды и рейты per-person. 4) График работ — milestones, контрольные точки. 5) График платежей — обычно 30% при подписании, 30% при промежуточной приёмке, 40% при сдаче. 6) Acceptance procedure — как клиент проверяет результат, сроки приёмки, процедура замечаний. 7) Change requests — как оформляются и оплачиваются изменения объёма работ. 8) SLA-период — что входит в гарантию после сдачи. 9) Передача — что включает, ответственности сторон, метрика готовности. 10) IP и code ownership — переход прав на код клиенту. 11) Конфиденциальность и NDA. 12) Ответственность сторон, штрафы за нарушение SLA и сроков. 13) Разрешение споров — обычно арбитраж в России. 14) Применимое право — РФ. Контракт стандартно 20-40 страниц для проекта под ключ, согласуется 1-2 недели юристами обеих сторон.