Задач будет много
Сегодня разработка модуля, завтра интеграция, потом поддержка и доработки. Общие условия лучше согласовать один раз.
Рамочный договор для долгосрочной работы: общие условия закрепим в MSA, а конкретные задачи — в SOW, заявках, ТЗ и приложениях.
Первый проект — до 3 рабочих дней после получения исходных данных.
Сегодня разработка модуля, завтра интеграция, потом поддержка и доработки. Общие условия лучше согласовать один раз.
Конкретику удобно выносить в SOW, приложение, заказ, ТЗ или спецификацию: объём, сроки, цена, команда, результат.
Стороны уже согласовали базовые правила, поэтому новый этап можно запускать через короткую заявку или приложение.
MSA помогает описать субподрядчиков, доступы, ответственность, NDA, права на результат и порядок взаимодействия команд.
Роли сторон, порядок постановки задач, документы проекта, приоритет MSA, SOW, ТЗ, счетов, актов и переписки.
Как оформляются новые проекты, этапы, change request, спринты, дополнительные работы и изменения сроков.
Предоплата, постоплата, milestone, hourly rate, retainer, акты, электронная приемка, сроки проверки результата.
Кому переходят права на код, дизайн, документацию, базы данных, настройки, интеграции и производные материалы.
Конфиденциальность, коммерческая тайна, доступ к репозиториям, инфраструктуре, данным, API-ключам и личным кабинетам.
Лимиты ответственности, штрафы, возмещение убытков, прекращение SOW, завершение MSA, возврат материалов и передача дел.
Главный рамочный договор: общие условия, которые применяются ко всем будущим задачам и приложениям.
Описание конкретного проекта: объём, результат, сроки, стоимость, команда, этапы и критерии приемки.
Техническая детализация результата: требования, макеты, интеграции, API, окружения, тесты и ограничения.
Уровни сервиса, время реакции, приоритеты инцидентов, плановые работы, компенсации и исключения.
Конфиденциальность, персональные данные, субподрядчики, передача прав, тарифы, акты и дополнительные условия.
Работы начались по переписке, но нет объёма, цены, сроков и критериев приемки. В споре неясно, что именно было заказано.
В MSA одно, в ТЗ другое, в счёте третье. Без правила приоритета сложно понять, какой документ главнее.
Код передали, оплатили частично, проект остановился. Стороны спорят, что можно использовать и дорабатывать.
Change request не оформляли, а объём вырос в два раза. Подрядчик требует доплату, заказчик считает всё включённым.
Единый стандарт юридической проработки во всех вариантах. Различаются результат, комплектация и объём правок.
Услуга 1
Выявим риски и дадим рекомендации по безопасной работе с договором.
Вариант 1
3 000 ₽
Анализ рисков, комментарии и рекомендации.
Вариант 2
4 500 ₽
Правовое заключение и исправленный договор в Word или протокол разногласий.
Услуга 2
Подготовим договор под вашу задачу и обеспечим необходимыми документами.
Вариант 1
6 000 ₽
До двух приложений и до трёх циклов правок.
Вариант 2
8 500 ₽
Все необходимые формы и приложения; правки без ограничения в пределах первоначальной задачи.
01
Договор, реквизиты, описание сделки и коммерческие условия — всё, что уже согласовано или есть у контрагента.
02
Подтверждаем результат, комплектацию, срок и точную цену до начала работы.
03
Стандартный первый проект — в течение 3 рабочих дней после получения исходных данных.
04
Вносим правки в объёме выбранного варианта и передаём итоговые документы в Word и PDF.
Договор разработки обычно описывает один проект. MSA задаёт общие правила для серии проектов, а конкретика каждого проекта выносится в SOW, ТЗ, заявку или приложение.
Можно только для очень простой модели, но в IT это рискованно. Обычно нужны SOW или заявки, где указаны объём, сроки, цена, результат и критерии приемки.
Statement of Work — документ к MSA, который описывает конкретную работу: результат, этапы, сроки, стоимость, команду, приемку и специальные условия проекта.
В MSA нужно прямо указать порядок: например, MSA задаёт общие условия, SOW уточняет проект, ТЗ описывает технические требования, а специальные условия SOW имеют приоритет по конкретной задаче.
Да, базовые условия можно включить в MSA. Для сложных проектов лучше сделать отдельные приложения: NDA, SLA, DPA, правила доступа, ставки и шаблон SOW.
MSA должен описать общий принцип, но конкретный результат, момент перехода прав и связь с оплатой лучше уточнять в SOW или акте по конкретному проекту.
Да. В MSA можно закрепить ставки, учёт времени, отчёты, лимиты бюджета, согласование переработок и порядок приемки фактически оказанных услуг.
MSA должен описывать прекращение: оплату выполненного, передачу материалов, закрытие доступов, статус прав, возврат конфиденциальной информации и переходный период.
На странице IT-договоров — NDA, SLA, SaaS, лицензии, разработка ПО, интеграции, сайты и SEO.
Справка
MSA — это рамочный договор. Он не должен заменять конкретные задания, но должен объяснять, как такие задания появляются, согласуются, оплачиваются, принимаются и прекращаются. Для IT это особенно важно, потому что один клиент может заказывать разработку, интеграции, поддержку, аудит, консультации и доработки в течение длительного периода.
Практическая ценность MSA в том, что стороны один раз согласуют базовые условия: права, конфиденциальность, ответственность, порядок изменений, доступы, субподрядчиков и приоритет документов. После этого новые работы можно запускать через короткие SOW, заявки или приложения.
Напишите нам в мессенджер — ответим в течение 10 минут.