Договор на разработку по - это основной документ, определяющий отношения между заказчиком и исполнителем. В нём должны быть чётко прописаны не только цена и сроки, но и сам предмет работ, права и обязанности обеих сторон, процедура приёмки и механизм разрешения конфликтов. Многие заказчики ошибаются, думая, что словесных договорённостей достаточно - они не защищают никого, когда возникают разногласия.
Любой договор разработки должен быть согласован с юристом перед подписанием. Приведённые здесь рекомендации - общие ориентиры, а не готовый шаблон. Финальный договор должен отражать специфику вашего проекта и пройти юридическую проверку.
Основные разделы договора на разработку ПО
| Раздел договора | Зачем нужен | На что смотреть заказчику |
|---|---|---|
| Предмет работ и ТЗ | Чётко определяет, что разрабатывается, функции и требования | Ссылка на приложенное ТЗ, описание всех компонентов системы, перечень исключений |
| Сроки выполнения | Устанавливает дедлайны, вехи проекта | Конкретные даты, определение день начала, промежуточные вехи, дата финальной сдачи |
| Стоимость и порядок оплаты | Прозрачность финансов, график платежей | Четкая сумма или ставка, авансовый платеж, промежуточные платежи, условия финального расчёта |
| Права на исходный код | Гарантирует переход ИП на заказчика после оплаты | Явное заявление о полной передаче прав, способ доставки (репозиторий), сроки передачи |
| Приёмка и гарантия | Определяет, как принимается готовая работа, на сколько дней | Процедура проверки, сроки тестирования, определение ошибки vs требование ТЗ, период гарантии (обычно 30 дней) |
| Ответственность сторон | Защита обеих сторон от убытков | Конкретные штрафы/неустойки за срыв сроков, механизм расчёта штрафа |
| Процедура изменений | Контроль scope creep, изменения бюджета и сроков | Как добавить/убрать функции, влияние на бюджет, утверждение изменений письменно |
| Конфиденциальность и NDA | Защита коммерческой тайны обеих сторон | Определение конфиденциальной информации, сроки действия, исключения (требование закона, общеизвестное) |
Что обязательно прописать в договоре на разработку ПО
Договор должен содержать чётко сформулированное описание предмета работ - не просто «разработка приложения», а подробное описание всех компонентов, технологических требований и критериев приёмки. Многие исполнители пытаются скрыть неясности в формулировках, чтобы впоследствии требовать доплату за дополнительные работы. Честный договор ясен обеим сторонам.
- Полное описание предмета работ с указанием всех компонентов, интеграций и модулей
- Ссылка на техническое задание как приложение, с указанием его версии и даты актуализации
- Точные сроки - дата начала, промежуточные вехи (например, end-to-end тестирование, развёртывание), дата финальной сдачи
- Явное перечисление того, что НЕ входит в проект (аренда серверов, обслуживание, рекламные услуги и т.д.)
- Определение того, что считается завершением проекта (код передан, документация готова, развёрнуто в production и т.д.)
- Описание каналов коммуникации и процедуры согласования изменений
Техническое задание - это самая важная часть договора. Чем оно подробнее, тем меньше вероятность конфликтов. ТЗ должно содержать не только список функций, но и требования к производительности, безопасности, дизайну и процедуру тестирования.
Права на исходный код и интеллектуальная собственность
Договор на разработку сайта или приложения должен четко решить вопрос о правах собственности на исходный код - это один из самых критичных пунктов. Заказчику крайне важно убедиться, что после завершения и оплаты проекта он получит полное право на код и сможет использовать его без ограничений. В договоре должно быть явно сказано: «После полной оплаты работ исполнитель передаёт заказчику все права на разработанное программное обеспечение, включая авторское право и право на использование».
Важный момент - способ передачи. Исходный код должен быть предоставлен в удобном формате (обычно git-репозиторий с полной историей коммитов), вместе с документацией, которая позволяет другому разработчику или команде разобраться в проекте и продолжить его развитие. В договоре стоит указать, будет ли исполнитель помогать с деплоем на сервера заказчика, обучать его команду, или это полностью ответственность заказчика.
Кроме того, обсудите статус третьесторонних библиотек и фреймворков. Их лицензии должны быть совместимы с вашими планами использования кода. Некоторые лицензии (например, GPL) могут обязывать вас публиковать свой исходный код. Честная студия разработки всегда использует только лицензии, которые позволяют заказчику свободно распоряжаться кодом без дополнительных обязательств.
- Полный исходный код с историей всех коммитов в git-репозитории или архиве
- Документация: установка зависимостей, настройка окружения, развёртывание, ключевые архитектурные решения
- Список всех использованных библиотек с указанием их лицензий (совместимость с вашей лицензией ПО)
- API документация и примеры использования ключевых модулей
- Согласованный формат передачи (доступ к приватному репозиторию, архив, или другое)
Приёмка, гарантия и ответственность сторон
Договор на разработку программного обеспечения должен содержать четкую процедуру приёмки работ. Обычно она выглядит так: исполнитель передаёт готовый результат на тестирование, заказчик проверяет соответствие техническому заданию и требованиям, и либо принимает работу, либо отправляет обратно на доработку с указанием списка замечаний.
| Параметр | Стандартная практика | Риск для заказчика, если не прописано |
|---|---|---|
| Сроки приёмки | Заказчику даётся 10-15 рабочих дней на проверку | Исполнитель может требовать срочной приёмки или считать работу принятой по истечении неопределённого срока |
| Количество доработок | Обычно 2-3 итерации входят в стоимость | Заказчик может нести дополнительные расходы за каждую правку |
| Гарантийный период | 30 дней после полной оплаты и приёмки | Исполнитель может отказать в исправлении ошибок сразу после сдачи |
| Определение ошибки | Ошибка - несоответствие ТЗ; требование ТЗ - если ТЗ неясно, это не ошибка разработчика | Возможны споры о том, что считается ошибкой |
| Критичность ошибок | Критичные ошибки (блокируют функциональность) vs малые недостатки | Заказчик не может потребовать исправления незначительных косметических багов |
| Доступ к тестированию | Исполнитель предоставляет тестовый сервер, access данные | Заказчик не может проверить работу и вынужден доверять слову разработчика |
Важно оговорить период гарантии. Обычно он составляет 30 дней после приёмки и полной оплаты, в течение которых исполнитель исправляет ошибки, допущенные его командой. Ошибка в этом контексте - это несоответствие коду требованиям технического задания, а не ошибка в самом ТЗ. После окончания гарантийного периода исправление критических ошибок обычно делается на платной основе (обслуживание и поддержка).
Ответственность сторон - ещё один важный пункт. Что грозит исполнителю, если он срывает сроки? Что может потребовать заказчик, если качество ниже оговоренного? Штрафы, неустойки, отказ от платежа, расторжение договора - всё это должно быть описано конкретно. Честный договор предусматривает ответственность обеих сторон, не только исполнителя. Например, если заказчик не предоставил необходимые материалы вовремя, это может оправдать задержку проекта со стороны разработчика.
Модели оплаты: Fixed Price vs Time & Material
Договор должен четко указывать, по какой модели рассчитывается стоимость работ. Каждая модель имеет свои преимущества и риски для обеих сторон.
| Параметр | Fixed Price (фиксированная цена) | Time & Material (время и материалы) | Гибридный подход |
|---|---|---|---|
| Как работает | Полная стоимость проекта указана в договоре. Любые изменения требуют дополнительного соглашения и оплаты | Указана часовая ставка или стоимость за день. Финальная сумма зависит от фактических затрат времени | Discovery фаза на T&M, основная разработка на Fixed Price. Или: Phase 1 Fixed, Phase 2 T&M |
| Риск заказчика | Если ТЗ менялось, есть риск доплатить за scope creep | Открытый бюджет; исполнитель может растянуть сроки; требуется контроль часов | Смешанные риски, но более гибко |
| Риск исполнителя | Если ошибился в оценке, может потерять деньги | Низкий, так как оплачивается фактический труд | Зависит от фаз проекта |
| Когда применять | Когда ТЗ стабильно и полностью понято; проект хорошо известен | Когда требования неясны; exploratory проекты; R&D; поддержка | Для большинства реальных проектов |
| Бюджет контроль | Бюджет закрыт; заказчик знает финальную сумму | Требуется бюджетный лимит и еженедельные отчёты | Закрытый бюджет Discovery + оценённый Fixed для остального |
| Пример контракта | «Разработка мобильного приложения: 2 000 000 ₽» | «Разработка с ставкой 3 000 ₽/день; бюджет не более 1 500 000 ₽; еженедельные отчёты» | «Discovery: до 200 часов на T&M; основная разработка: 1 500 000 ₽ Fixed» |
Для Fixed Price критично, чтобы техническое задание было максимально детальным и согласовано обеими сторонами. Любые изменения требуют письменного согласования и пересчёта сроков и бюджета.
Для Time & Material договор обязательно должен включать ориентировочные сроки, бюджетный лимит и процедуру еженедельных отчётов о проделанной работе. Это позволяет заказчику контролировать расходы и видеть прогресс.
Выбор модели оплаты - это стратегический вопрос, который влияет на весь проект. Fixed Price даёт уверенность в бюджете, но требует предварительного анализа требований. Time & Material даёт гибкость, но может привести к перерасходу. Честная студия разработки всегда готова обсудить обе модели и выбрать оптимальный вариант для конкретного проекта. Помните, что переключение между моделями во время проекта осложняет все расчёты и может привести к конфликтам.
Многие опытные заказчики выбирают гибридный подход: сначала фаза Discovery на Time & Material, где команда изучает требования и уточняет объём работ, а потом Fixed Price для основной разработки. Это минимизирует риски для обеих сторон и должно быть предусмотрено в договоре как вариант сотрудничества.
Риски заказчика и как их закрыть в договоре
| Риск для заказчика | Признаки в договоре | Как закрыть |
|---|---|---|
| Срыв сроков проекта | Нет чётких дедлайнов; вехи размыты | Указать конкретные даты; определить промежуточные вехи; предусмотреть неустойку за задержку (0.5-1% стоимости в день) |
| Некачественный код | Нет критериев приёмки; отсутствует гарантия | Подробное ТЗ с критериями; гарантийный период 30-60 дней; определение того, что такое ошибка |
| Исполнитель не передаёт код | Нет пункта о передаче прав или он размыт | Явное утверждение: полная передача прав на ПО после оплаты; способ передачи (репозиторий с доступом) |
| Scope creep - бесконечно растущий объём работ | Нет процедуры внесения изменений | Определить, как добавляются/убираются требования; любое изменение требует письменного согласования и пересчёта |
| Разногласие о том, что такое «готово» | Размытое описание предмета работ | Детальное ТЗ; чётко определить критерии приёмки; описать, как проверяется каждый компонент |
| Исполнитель исчезает после сдачи | Нет контактных данных; отсутствует обязательство по поддержке | Указать контактные данные; обязательство по гарантийной поддержке минимум 30 дней; процедуру передачи |
Техническое задание как основа договора
Техническое задание - это не просто список функций. Это полное описание того, как должна работать система, какие компоненты входят в разработку, какие нет, как это будет тестироваться, какие метрики производительности должны быть достигнуты. Чем подробнее ТЗ, тем честнее работает договор и тем меньше вероятность конфликтов.
В договоре предмет обычно описывается одной-двумя строчками (например, «разработка веб-приложения на React для управления проектами»), а вся детализация уходит в ТЗ - приложение к договору. Это важно, потому что ТЗ может быть пересмотрено после обсуждения, тогда как сам договор меняется реже и сложнее.
Оговорите также, что считается завершением проекта. Это только разработка, или также включены настройка серверов, помощь с запуском в production, обучение команды заказчика, создание документации? Каждый из этих пунктов стоит отдельно обговорить и оценить.
Качество ТЗ напрямую влияет на качество договора. Плохое ТЗ - это коренная причина большинства конфликтов между заказчиком и разработчиком. Когда требования размыты, разработчик пытается минимизировать объём работ, а заказчик ожидает больше. Инвестиция в подробное ТЗ - это инвестиция в успех проекта. Приглашение разработчика на фазу подготовки ТЗ часто помогает уточнить требования и избежать потом неприятных сюрпризов. Кроме того, хорошее ТЗ дает разработчику уверенность в том, что он правильно понял требования и сможет оценить работу честно.
- Описание всех экранов/функций приложения и их поведение
- Требования к производительности (время загрузки, масштабируемость, количество одновременных пользователей)
- Требования к безопасности (авторизация, шифрование данных, защита от CSRF и т.д.)
- Требования к дизайну (макеты, цветовая схема, адаптивность для мобильных)
- Интеграции (с какими сервисами должно интегрироваться приложение)
- Примеры использования (user stories) для ключевых функций
- Критерии приёмки (как проверяется, что функция работает правильно)
- Исключения (что НЕ входит в проект)
Если ТЗ менялось во время разработки, все изменения должны быть задокументированы письменно и включены в договор или в отдельное соглашение об изменениях. Это защищает обе стороны.
Практические примеры формулировок в договоре
Давайте посмотрим, как правильно формулировать ключевые пункты договора. Вместо размытого «разработка веб-приложения», пишите: «Разработка веб-приложения на React 18 для управления проектами с поддержкой таких-то интеграций, запуск на production на сервере заказчика, документация и часовая консультация для команды». Вместо «гарантия на разумный период», пишите: «Гарантийная поддержка в течение 30 календарных дней после приёмки и полной оплаты работ, в течение которого исполнитель исправляет ошибки, обнаруженные при тестировании».
Для указания ответственности используйте конкретные цифры: «За каждый день задержки сдачи готового проекта исполнитель выплачивает заказчику неустойку в размере 0.5% от стоимости контракта за каждый день просрочки, но не более 20% от полной стоимости». Такой формат исключает возможность толкований и защищает обе стороны. Главное - всё оформить письменно в договоре, а не надеяться на уговоры и обещания.
Красные флаги в договоре, на которые стоит обратить внимание
- Отсутствие точной даты начала или завершения проекта - только «в течение примерно 3-6 месяцев»
- Нет описания того, как вносятся изменения в требования; фраза «изменения согласуются устно»
- Предмет работ описан одной фразой без ссылки на ТЗ или приложение
- Отсутствие гарантии на исходный код после сдачи; фраза «исполнитель не отвечает за ошибки после приёмки»
- Нет процедуры приёмки или она не определена; только «заказчик проверит и одобрит»
- Отсутствие штрафов/неустойки за срыв сроков или они ничтожно малы (менее 0.1% стоимости)
- Исполнитель оставляет себе право на исходный код или требует доплату за его передачу
- Неопределённые сроки гарантии: «гарантия на разумный срок» без конкретного числа дней
- Отсутствие контактных данных исполнителя или неясно, к кому обращаться при проблемах
- Размытое определение ошибки; возможность спора о том, что такое баг и что такое требование
Контрольный чек-лист заказчика перед подписанием
- Предмет работ чётко описан, есть ссылка на детальное техническое задание
- Точная стоимость указана (Fixed Price) ИЛИ определена часовая ставка и бюджетный лимит (Time & Material)
- Расписан график платежей: размер авансового платежа, промежуточные платежи, финальный платёж
- Чётко обозначены даты: начало проекта, промежуточные вехи, финальная сдача
- Раздел о правах на код: полный переход прав на заказчика после оплаты
- Описан способ передачи кода (репозиторий, архив) и сроки передачи
- Определена процедура приёмки: сроки проверки (обычно 10-15 дней), количество доработок в стоимости
- Указан гарантийный период (обычно 30 дней) и что в него входит (только ошибки разработки, не ТЗ)
- Определены штрафы за срыв сроков (обычно 0.5-1% стоимости в день просрочки)
- Есть процедура внесения изменений: как добавить/убрать функции, как это влияет на бюджет
- Оговорено использование проекта в портфолио исполнителя (обычно разрешено без раскрытия конфиденциалии)
- Условия конфиденциальности и NDA ясны обеим сторонам
- Указаны контактные данные обеих сторон (подписывающих лиц, технических контактов)
- Договор подписан в нужном количестве экземпляров (обычно 2 оригинала, по одному у каждой стороны)
Что обязательно приложить к договору
- Техническое задание (ТЗ) с подробным описанием функционала, требований, критериев приёмки
- Макеты (дизайн-макеты экранов приложения, если применимо)
- Архитектурный документ, если это сложный проект (описание компонентов, их взаимодействия)
- Список технологий (какие языки программирования, фреймворки, БД будут использованы)
- Смета расходов (если Time & Material) или breakdown по этапам (если Fixed Price)
- График разработки с вехами и критериями завершения каждого этапа
- Согласованный список исключений (что НЕ входит в проект)
- Положение о конфиденциальности и NDA (если применимо)
- Процедура приёмки (как проверяется готовность, какие тесты должны пройти)
- Описание процедуры коммуникации (как часто встречаются, в каком формате отчёты)
Конфиденциальность, NDA и права на портфолио
Договор должен содержать раздел о конфиденциальности. Обычно исполнитель может показать проект в своём портфолио, но без раскрытия конфиденциальной информации (например, торговые секреты, особенности бизнес-логики, детали интеграций с платёжными системами). Если информация критична для конкуренции, в договор включается полный запрет на публичное упоминание проекта.
NDA (соглашение о неразглашении) может быть подписано отдельно или включено в договор как раздел. Оно должно определять, какая информация считается конфиденциальной, кому её можно раскрывать (например, поддрядчикам, сотрудникам), и на сколько лет действует запрет на разглашение (обычно 3-5 лет после окончания сотрудничества). Исключения: информация, которая требуется раскрыть по приказу суда или государственного органа.
Важный момент - обе стороны должны обязаться хранить конфиденциальную информацию в безопасности. Это значит, что код не должен быть выложен в открытый гитхаб, источники доступа не должны делиться с третьими лицами без согласия, и т.д.
Важно обсудить с исполнителем, какую информацию можно раскрывать в портфолио или при общении с потенциальными клиентами. Например, исполнитель может сказать: «Я разработал веб-приложение для компании в сфере E-commerce с интеграцией платёжных систем», но не может указать название компании, сумму контракта или детали реализации. Это баланс между интересами обеих сторон - разработчик получает портфолио, заказчик сохраняет конфиденциальность. Если после завершения проекта исполнитель разглашает информацию вопреки договору, заказчик может требовать компенсацию убытков через суд.
Что делать при конфликте: механизм разрешения споров
Договор должен содержать процедуру разрешения споров. Обычно это выглядит так:
- Переговоры - стороны пытаются разрешить конфликт путём прямого общения (10-15 дней)
- Медиация (опционально) - привлечение нейтрального третьего лица для помощи в переговорах
- Арбитраж или суд - если договориться не удалось, спор передаётся в арбитражный суд или третейский суд
В договоре должна быть указана подсудность - в каком суде рассматривается спор, если дело дойдёт до суда. Обычно это суд по месту нахождения исполнителя или по согласованию сторон.
Включение процедуры переговоров в договор часто помогает сторонам избежать судебных разбирательств. Суд - это дорого и долго; лучше договориться мирно.
Заключение: честный договор защищает обе стороны
Договор на разработку по - это не просто юридический документ, а соглашение, которое определяет успешность всего проекта. Чем подробнее и честнее договор, тем меньше вероятность конфликтов, непониманий и потери денег. Заказчику стоит потратить время на тщательное согласование контракта - это вложение, которое окупится многократно.
Основные ключи к хорошему договору: детальное техническое задание, чёткие сроки и вехи, прозрачные финансовые условия, ясная процедура приёмки, гарантия и ответственность обеих сторон. Если в договоре что-то непонятно, лучше задать вопросы до подписания, чем разбираться с конфликтами потом. И помните - финальный договор должен быть согласован с юристом.