Приложение к договору на разработку программного обеспечения (ПО), это не просто формальность, а ключевой документ, фиксирующий техническое задание (ТЗ), этапы работ, критерии приемки и права интеллектуальной собственности. Грамотно составленное приложение минимизирует риски споров между Заказчиком и Исполнителем. В данной статье мы разберем структуру, обязательные разделы и нюансы оформления такого приложения на основе судебной практики и типовых бизнес-стандартов.

Юридическая природа и виды приложений

Согласно ГК РФ (ст. 702, 1288, 1290), договор на разработку ПО может оформляться как договор подряда (работы) или договор авторского заказа. Выбор формы влияет на содержание приложения:

• Договор подряда (разработка ПО): Приложение №1 — Техническое задание (ТЗ). Приложение №2 — График-календарный план. Приложение №3 — Акт приема-передачи (форма). Приложение №4 — Спецификация/Смета.
• Договор авторского заказа: Приложение содержит ТЗ с акцентом на творческую составляющую и порядок перехода исключительных прав.

Важно: В самом теле договора часто прописывают фразу: «Условия, не урегулированные настоящим Договором, определяются Приложениями, являющимися его неотъемлемой частью». Это делает приложения юридически обязательными.

Структура типового приложения (Техническое задание)

На практике наиболее востребованным является Приложение №1 — Техническое задание (ТЗ). Ниже приведена рекомендуемая структура, используемая ведущими IT-компаниями (в т.ч. такими как ООО «Дотрунет групп» / Лаборатория IOS и др.).

Общие сведения

1. Наименование изделия: Полное и краткое название (например, «Мобильное приложение «» для iOS/Android»).
2. Назначение: Описание бизнес-задачи (например, «Предоставление пользователю эксклюзивного формата просмотра Интернет-ресурса »).
3. Основание для разработки: Номер и дата договора (Договор № * от ).
4. Исполнитель / Заказчик: Реквизиты сторон (ИНН/ОГРН скрыты: ).

Требования к функционалу (Функциональные требования)

Самый объемный раздел. Рекомендуется использовать пользовательские истории (User Stories) или таблицу «Роль — Действие — Результат».

Нефункциональные требования (NFR)

• Платформы: iOS * (Swift/UIKit/SwiftUI), Android * (Kotlin/Jetpack Compose). Кроссплатформенное решение (Flutter/React Native) — указать версию SDK.
• Производительность: Время холодного старта < 2 сек, потребление памяти < * МБ, FPS UI > 55.
• Безопасность: Хранение токенов в Keychain/Keystore, SSL Pinning, обфускация кода (ProGuard/R8), соответствие 152-ФЗ (персональные данные);
• Совместимость: Поддержка iOS +, Android API +. Адаптация под iPhone SE / планшеты / foldable.
• Локализация: Русский (основной), Английский (опционально).

Требования к UI/UX и дизайну

• Ссылка на макеты в Figma (доступ для роли Developer: *).
• Дизайн-система (токены цветов, шрифтов, иконок).
• Анимации и микровзаимодействия (ссылки на Lottie/After Effects файлы).
• Адаптивность: Safe Area, Dynamic Type, Dark/Light mode.

Архитектура и стек технологий

Фиксация стека в приложении защищает Исполнителя от требований «переписать на другом языке» за счет Заказчика.

• Архитектурный паттерн: Clean Architecture / MVVM / VIPER / MVI.
• DI: Koin / Hilt / Swinject.
• Сетевой слой: Retrofit / Alamofire / Ktor Client.
• БД: Realm / CoreData / Room / SQLite.
• CI/CD: GitLab CI / GitHub Actions / Bitrise / Fastlane (автоматический деплой в TestFlight / Google Play Console).

Интеграции и API

• Спецификация API (OpenAPI/Swagger) — версия , доступ по ссылке .
• Сторонние SDK: Аналитика (Firebase / Amplitude / ), Платежи (ЮKassa / Stripe / ), Пуши (Firebase / OneSignal / ), Карты (Mapbox / Яндекс.Карты / ).
• Требования к бэкенду Заказчика (SLA, формат дат, пагинация, версионирование).

Этапы работ и приемка (График-календарный план)

Часто выносится в отдельное Приложение №2, но может быть секцией ТЗ.

1. Этап 0: Discovery / Проектирование (* дн.) — Уточнение ТЗ, прототипирование, оценка рисков. Результат: Подписанное ТЗ, оценка трудозатрат.
2. Этап 1: MVP / Альфа-версия (* дн.), Базовый функционал (Auth, Core Flow). Результат: Сборка в TestFlight / Internal Testing, Акт приемки скрытых работ (код).
3. Этап 2: Бета-версия (* дн.) — Полный функционал, UI полировка, багфиксы. Результат: Сборка для QA Заказчика.
4. Этап 3: Релиз / Публикация (* дн.), Подготовка метаданных (ASO), скриншотов, политика конфиденциальности. Публикация в App Store / Google Play. Результат: Акт приема-передачи итогового результата (исключительных прав/лицензии).
5. Этап 4: Гарантийная поддержка (* мес.) — Исправление багов, обновление под новые ОС. Условия: SLA, стоимость (входит в цену / отдельно).

Ключевые правовые блоки в приложении

Интеллектуальные права (Критично!)

В приложении или доп. соглашении обязательно прописывается:

• Кому принадлежат исключительные права: Заказчику (переход по умолчанию при оплате по договору подряда) или Исполнителю (лицензия Заказчику).
• Право на доработки: Кто может вносить изменения в код.
• Использование библиотек Open Source (MIT, Apache 2.0, GPL) — обязательное указание лицензий, чтобы не «заразить» проприетарный код вирусным GPL.
• Право на портфолио: Может ли Исполнитель указывать проект в CV/на сайте (под NDA или открыто).

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

Избегайте формулировок «приложение должно работать быстро». Пишите измеримо:

• Все тест-кейсы из Test Plan (ссылка: ) пройдены со статусом Passed.
• Критических (Critical) и Блокирующих (Blocker) багов — 0.
• Major багов, не более .
• Покрытие кода Unit/UI тестами — не менее % (если согласовано).
• Прохождение модерации App Store / Google Play (риск отказа со стороны маркетов часто ложится на Заказчика контента, но технические отказы — на Исполнителя).

Порядок изменений (Change Request)

Любая правка ТЗ после подписания — это Дополнительное соглашение или Change Request.

1. Заказчик присылает запрос на почту *.
2. Исполнитель оценивает трудозатраты и влияние на сроки (в течение рабочих дней).
3. Стороны подписывают протокол согласования изменений / доп. соглашение.
4. Изменения вносятся в ТЗ (версия v1.1, v1.2…).

Пример оформления заголовка приложения

ПРИЛОЖЕНИЕ № 1
к Договору на оказание услуг по разработке программного обеспечения № * от «» 202 г.

ТЕХНИЧЕСКОЕ ЗАДАНИЕ
на разработку мобильного приложения «»

Версия документа: 1.0 (Финальная)
Дата утверждения: «___» ___________ 202 г.

ГОРОД *

СТОРОНЫ:
Заказчик: * (ИНН , ОГРН ), в лице Генерального директора ,
действующего на основании Устава,
именуемое в дальнейшем «Заказчик»,
Исполнитель:  (ИНН , ОГРН ), в лице Генерального директора *,
действующего на основании Устава,
именуемое в дальнейшем «Исполнитель»,

вместе именуемые «Стороны», составили настоящее Техническое задание о нижеследующем:

Типичные ошибки и риски

• Отсутствие версии ТЗ: Стороны работают над разными версиями документа. Решение: Нумерация версий (v1.0, v1.1) на каждой странице.
• Ссылка на «сайт/приложение конкурента» как ТЗ: «Сделать как у *». Это не ТЗ. Суды не принимают это как определенный предмет договора. Решение: Детальная декомпозиция функций.
• Игнорирование бэкенда: Если бэкенд делает Заказчик или третья сторона, ТЗ должно содержать раздел «Требования к API бэкенда» с SLA. Иначе мобильная команда не сможет сдать работу в срок.
• Отсутствие процедуры приемки кода: Передача только .ipa/.aab файла без доступа к репозиторию (Git) и документации (README, архитектурная диаграмма) создает риск невозможности дальнейшей поддержки.
• Нечеткие сроки: «Как можно быстрее». Только календарные даты или привязка к событиям (например, «через 20 рабочих дней после подписания Акта этапа 0»).

Дополнительные приложения (Чек-лист)

Помимо ТЗ, к договору рекомендуется прикрепить:

1. Приложение №2: График-календарный план / Дорожная карта (Roadmap).
2. Приложение №3: Форма Акта приема-передачи результатов работ (КС-11 / свой бланк). С полями для подписей сторон, даты, перечня передаваемого (исходный код, ключи подписи, аккаунты разработчика, документация).
3. Приложение №4: Смета / Спецификация цен. Фиксированная цена (Fixed Price) или ставки (Time & Materials: * руб/час за Senior iOS, * руб/час за QA и т.д.).
4. Приложение №5: Регламент взаимодействия (Communication Protocol). Мессенджеры (Slack/Telegram ), еженедельные созвоны (понедельник :), отчетность (Jira/YouTrack/Trello доступ: ).
5. Приложение №6: Политика конфиденциальности / NDA (если отдельным документом).
6. Приложение №7: Перечень передаваемых материалов Заказчиком (брендбук, логотипы, контент, доступы к Apple Developer Program / Google Play Console — логин: *).

Особенности для ИП и патентного налога (УСН/Патент)

Если Исполнитель — ИП на патенте (деятельность 62;01 «Разработка программного обеспечения»), в приложении/договоре важно:

• Четко разграничить «работы» (сдаются по актам) и «услуги» (консультации, поддержка). Патент покрывает именно деятельность по разработке.
• В акте приемки указывать: «Результат работы — исключительное право на программу для ЭВМ / лицензия», а не просто «услуга оказана».
• Стоимость работ в договоре не должна превышать предел дохода для патента (в 2026 г. — млн руб. в год, уточняйте по региону *).

Качественное приложение к договору — это инвестиция в предсказуемость проекта. Экономия на юристах/аналитиках на этапе составления ТЗ почти всегда приводит к превышению бюджета в -% и более, а также к судебным спорам (как в деле по договору на разработку ПО с взысканием средств у Исполнителя).

Главные правила:

1. Детализация: ТЗ должно быть достаточным для оценки трудоемкости сторонним экспертом.
2. Версионирование: Любое изменение — новая версия с историей правок.
3. Приемка по этапам: Не ждите финал. Принимайте и оплачивайте по милстоунам (Milestones).
4. Исходники и доступы: Пропишите момент передачи Git-репозитория, ключей подписи (Keystore, .p12), аккаунтов в маркетах.
5. Гарантия: Четко разграничьте «гарантийное исправление багов» (бесплатно) и «новую разработку/доработки» (платно).

Данная статья носит информационный характер и не является правовым консультированием. Перед подписанием договора и приложений рекомендуется согласовать их с профильным IT-юристом с учетом специфики вашего проекта и актуального законодательства РФ (ГК РФ, 152-ФЗ, 63-ФЗ).

Полезные ссылки (образцы для скачивания):

• Бланк договора на разработку ПО (Word/PDF) — доступны на правовых порталах (КонсультантПлюс, Гарант, FreshDoc, ).
• Пример структуры ТЗ для мобильного приложения (Google Docs шаблон): ссылка на шаблон .