Приложение приняли, но обновление не вышло: аккаунт разработчика оформлен на подрядчика, а договор не обязывает его передать доступ или заниматься публикацией. Исходный код у заказчика есть, но управлять выпуском продукта он не может. В мобильной разработке приемка сборки, права на результаты и контроль над аккаунтами — отдельные вопросы. Их стоит решить до начала работ.
Речь преимущественно о договоре, к которому применяется российское право. Если заказчик или разработчик находится в другой стране, условия об интеллектуальных правах, персональных данных и разрешении споров нужно отдельно проверить с учетом применимого права.
Сначала определите, что именно должен получить заказчик
Фраза «разработать приложение для iOS и Android» не объясняет, должен ли функционал на двух платформах совпадать, кто отвечает за серверную часть и входят ли в работу дизайн, панель администратора и размещение в магазинах. Общие условия можно закрепить в договоре, а детали — в приложениях: техническом задании, плане этапов, порядке приемки, перечне передаваемых материалов и учетных записей.
В техническом задании опишите пользовательские сценарии: регистрацию, оплату, уведомления, работу без сети, удаление аккаунта. Для важных сценариев нужны ожидаемый результат и условия проверки. Вместо «удобной авторизации» укажите способы входа, поведение приложения при потере соединения и после истечения сессии.
Границы проекта тоже лучше обозначить прямо. Если оплата, интеграция с CRM или локализация не входят в стоимость, это должно быть видно из документов. Иначе новая функция легко становится предметом спора: одна сторона считает ее дополнительной работой, другая — «очевидной частью приложения».
Что проверить в описании результата
- Платформы и версии: для каких операционных систем и минимальных версий готовится приложение; кто решает вопрос о поддержке новых версий во время проекта.
- Состав системы: мобильные клиенты, сервер, API, панель управления, база данных, инструменты аналитики и связи между ними.
- Материалы: исходный код, дизайн-макеты, графика, тексты интерфейса, документация, тесты и инструкции по сборке.
- Среды: где размещаются репозитории, тестовые стенды и рабочие сервисы, кто оплачивает инфраструктуру.
- Критерии готовности: какие проверки проходят сборки и какие ошибки мешают приемке.
Прототипы и макеты обозначайте версиями и датами. Если договор ссылается на файл, который постоянно меняется, без сохраненной согласованной версии будет трудно установить, какой интерфейс стороны утвердили.
Этапы, изменения и зависимость от материалов заказчика
Разработчику нужны решения и материалы заказчика: утвержденные экраны, описание услуг, реквизиты, доступ к API, тестовые данные. Перечислите в договоре, что и когда предоставляет заказчик, в какой срок отвечает на вопросы и как стороны фиксируют решения. Если задержка с его стороны сдвигает график, определите порядок пересчета сроков и уведомления о препятствии. Правило, привязанное к конкретной задержке и затронутому этапу, понятнее автоматического продления «на любое время».
Этапы удобно привязать к результатам, которые можно предъявить: утвержденным макетам, тестируемому клиенту, интеграциям, релизной сборке. Для каждого укажите срок, стоимость и способ подтверждения выполнения. Тогда демонстрацию промежуточной версии не придется путать со сдачей оплачиваемого этапа.
Новую функцию оформляйте заявкой: что меняется, как это влияет на цену и сроки, кто согласует работу. Переписка поможет подтвердить договоренности, но из нее должно быть ясно, вправе ли менеджер проекта обещать дополнительные работы от имени компании. Закрепите допустимый канал связи и круг лиц, чье подтверждение меняет задание. Для мелких правок можно упростить согласование, сохранив запись о самом изменении.
Права на код и другие результаты: не одна общая фраза
В приложении есть разные охраняемые результаты: программы для ЭВМ, элементы дизайна, иллюстрации, тексты, иногда база данных. Одна лишь оплата разработки не отвечает на вопрос, может ли заказчик менять продукт, поручить поддержку другой команде или использовать его части в следующих проектах. Условия о правах должны соответствовать предмету договора и тому, кто фактически создает результаты.
Перечислите результаты, создаваемые по заданию, и определите правовую модель: переход исключительных прав к заказчику или предоставление лицензии. Укажите, с какого момента она действует. Для лицензии важны способы использования, срок, территория и возможность модификации. Если исключительные права переходят заказчику, согласуйте момент перехода с приемкой и оплатой, чтобы условия не допускали разных толкований. В договорах по российскому праву также проверяют специальные нормы ГК РФ о программах, созданных по заказу, и о результатах работы сотрудников исполнителя: формулировка зависит от устройства конкретного проекта.
Подрядчик может включить в приложение свои библиотеки, шаблоны и инструменты, созданные до проекта. Исключительные права на них заказчику нужны не всегда. Но ему необходимо право пользоваться такими компонентами в составе приложения, обновлять и поддерживать продукт. Отделите их перечень от вновь созданного кода. Если подрядчик привлекает субподрядчиков и дизайнеров, он должен получить права, необходимые для исполнения договора с заказчиком, и подтвердить это документами.
Проверьте лицензии сторонних SDK, шрифтов, изображений и открытого ПО. Они могут устанавливать условия распространения или требовать уведомлений. В договоре можно обязать исполнителя заранее раскрывать значимые зависимости и согласовывать замену компонентов, которая способна повлиять на выпуск продукта. Фраза «передать все права на весь код» не отменяет условий лицензий третьих лиц.
Как принять приложение, а не только посмотреть демонстрацию
Работа мобильного приложения зависит от устройства, версии операционной системы, сети и внешних сервисов. Поэтому порядок приемки должен позволять повторить проверку: где взять тестовую сборку, на каких устройствах или их типах ее проверяют, какие сценарии выполняют, как фиксируют ошибки и сколько времени отводят на исправление.
Разделите дефекты по последствиям. Блокирующий не дает пройти ключевой сценарий или создает существенную угрозу безопасности. Некритичный может затрагивать, например, отображение второстепенного элемента. Привяжите эти категории к функциям конкретного приложения вместо неопределенного требования «работает корректно». Из-за мелкого дефекта не обязательно откладывать приемку всего этапа: стороны могут зафиксировать перечень исправлений и дату их внесения.
Согласуйте форму замечаний и способ подтверждения исправлений. Для случая, когда заказчик не отвечает в установленный срок, можно предусмотреть последствия молчания. Но условие должно быть ясным, а у заказчика — реальная возможность проверить результат. Если подрядчик не предоставил сборку или доступ к стенду, начало срока приемки почти неизбежно станет предметом спора.
Приемка функционала не равна публикации в магазине. Проверка платформой зависит от ее правил и решений, на которые подрядчик не всегда влияет. Разграничьте обязанности подготовить сборку с учетом требований платформы, заполнить карточку приложения, отправить его на проверку и устранить замечания, связанные с работой исполнителя. Безусловное одобрение магазина обещать не стоит.
Аккаунты магазинов, ключи и техническая передача
Права на программу не дают автоматического контроля над аккаунтом публикации, облаком или сертификатами подписи. Заранее определите, кому принадлежат аккаунты магазинов и подключенных сервисов. Если сразу зарегистрировать их на заказчика нельзя, опишите временную схему, доступ подрядчика и последующую передачу с учетом правил платформы.
Передача продукта — это не только архив с исходниками. Нужны репозиторий с историей изменений, инструкция по сборке, перечень зависимостей, параметры окружений, описание API и сведения о резервном копировании. Отдельно укажите, кто создает и хранит ключи подписи, как их передают уполномоченным лицам и что делать при утрате. Пароли и секреты не следует вписывать в акт открытым текстом: факт передачи можно подтвердить, не раскрывая в подписанном документе сами значения.
Если у приложения есть серверная часть, закрепите доступ к облачному кабинету, доменам, push-сервису, аналитике и платежным интеграциям. Когда все это привязано к личной учетной записи сотрудника подрядчика, смена команды или прекращение договора может остановить выпуск обновлений даже после полной передачи исходников.
Данные пользователей и требования платформ
Приложение может обращаться к геолокации, контактам, камере, платежным и другим данным. Распределите задачи по проектированию согласий, настройке разрешений, защите передачи данных, ведению журналов и удалению учетной записи — там, где этого требуют функции продукта и применимые правила. При этом договор с разработчиком не заменяет документы и действия, необходимые владельцу сервиса для соблюдения законодательства о персональных данных.
Определите, вправе ли исполнитель использовать реальные данные пользователей при тестировании и поддержке, на каком основании и в каком объеме. Для отладки часто достаточно обезличенных или специально подготовленных наборов. Если нужен доступ к рабочей среде, ограничьте его по ролям и установите порядок выдачи и отзыва, требования к защите и действия при инциденте. Отдельно решите, кто готовит сведения для карточки приложения о собираемых данных и используемых SDK. Разработчик предоставляет техническую информацию, а опубликованное описание должно соответствовать фактической работе продукта.
Цена, поддержка и досрочное прекращение
За работу можно платить фиксированную цену за этап, по трудозатратам или сочетать оба подхода. При почасовой оплате нужны ставки, состав работ, порядок утверждения оценок и отчеты. При фиксированной — четкие границы объема и правила оплаты дополнительных функций. Проверьте расходы на аккаунты разработчика, облачные сервисы, коммерческие библиотеки и устройства для тестирования: без них согласованный бюджет может оказаться неполным.
После релиза приложению обычно нужны исправления и обновления под новые версии операционных систем. Разделите исправление дефектов по вине исполнителя, выявленных в согласованный период, и платные работы по развитию продукта. Установите сроки реакции и исправления с учетом серьезности проблемы, часы доступности команды и порядок срочных выпусков. Из слов «поддержка включена» непонятно, обязан ли подрядчик обновлять приложение, когда магазин меняет требования.
Продумайте и досрочное прекращение договора. Какие результаты и материалы передают на эту дату? Как рассчитывают оплату выполненного, возвращают неиспользованный аванс и отзывают доступы? Передачу текущей версии репозитория и документации не стоит ставить исключительно в зависимость от окончательного разрешения всех денежных разногласий. Условия передачи и встречного исполнения лучше прописать отдельно.
Проверка перед подписанием
- Сверьте перечень результатов в техническом задании, актах и условиях о правах: названия и состав должны совпадать.
- Проверьте, кому принадлежат аккаунты магазинов, репозиторий и облачная инфраструктура и кто оплачивает их использование.
- Убедитесь, что критерии приемки подходят для конкретных сборок, а публикация отделена от проверки функционала.
- Установите, кто согласует дополнительные задачи и как их стоимость влияет на график.
- Запросите перечень сторонних компонентов и проверьте порядок доступа к данным пользователей.
Перед подписанием сопоставьте договор и приложения с планом передачи продукта. Если в плане указан ключ подписи релизной сборки, в договоре должны быть столь же ясно названы его хранитель и способ передачи, как и срок сдачи кода. Материал носит информационный характер и не заменяет индивидуальную юридическую консультацию.