Договор на разработку мобильного приложения: что проверить заказчику

Какие вопросы должен закрывать договор

Если предложение не отвечает на один из вопросов, это еще не делает исполнителя ненадежным. Но обе стороны пока опираются на предположение, которое лучше обсудить до начала работ.

Приложите проверяемый состав работ

Необязательно перечислять каждый экран в основном тексте договора. Можно сослаться на требования к мобильному приложению и техническое задание, если у приложения есть номер версии или дата.

Описывайте поведение, а не только название функции. «Система записи» может означать простую заявку или расписание сотрудников, предоплату, правила отмены, часовые пояса, уведомления и возвраты. Нужны роли, основные действия, деловые правила, интеграции и важные состояния.

Полезно явно перечислить, чего в первой версии нет. Перенос старых данных, сайт, написание текстов, поддержка планшетов, дополнительные языки и постоянное сопровождение не должны оставаться молчаливыми ожиданиями. Зафиксируйте также предположения о внешних системах, материалах и аккаунтах заказчика.

Договоритесь, как оформлять изменения

Заранее предсказать каждую деталь невозможно. Задача договора не запретить изменения, а сделать их видимыми.

В запросе на изменение стоит указать желаемый результат, затронутые работы, влияние на цену и срок, а также функции, которые будут убраны или перенесены. Нужно определить, кто вправе его согласовать. Сообщения от нескольких участников не должны незаметно расширять уже утвержденную версию.

При гибкой разработке список задач меняется, но бюджет или доступная работа команды остаются под контролем. Договору все равно нужен порядок замены приоритетов и правило, по которому идея становится отдельной оценкой.

Свяжите оплату с понятными результатами

Первый платеж может закреплять команду и покрывать запуск проекта. Следующие платежи проще проверять, если они связаны с результатом: согласованным дизайном, работающим главным сценарием в тестовой среде, версией для публикации или завершенной передачей.

Фраза «серверная часть готова на 80%» неудобна заказчику: процент нельзя проверить, и он не показывает работу продукта целиком. Понятный этап выглядит иначе: пользователь регистрируется, выбирает услугу и проводит тестовую оплату, а администратор видит операцию и выполняет возврат.

Опишите, что происходит при обнаружении ошибок. Разделите блокирующие и незначительные замечания, установите срок проверки и зафиксируйте номер версии. Последствия молчания, использования в работе или пропуска срока нужно отдельно согласовать с учетом применимого права.

Определите приемку до начала разработки

Приемка — не абстрактное утверждение «все работает». Для каждого этапа нужны версия, окружение, исходные данные, ожидаемый результат и способ зафиксировать проверку.

Хороший критерий можно повторить: успешная оплата создает один заказ; отмена по правилам возвращает правильную сумму; обычный пользователь не видит административные данные. Плохой критерий просто повторяет название функции.

Укажите, кто проводит проверку, сколько дней отведено на ответ, где регистрируются ошибки и как выполняется повторная приемка. Список проверок приложения перед запуском поможет сформулировать реальные сценарии.

Разделите права на разные материалы

Приложение — не один объект. В проекте могут быть исходный код мобильной и серверной части, настройки инфраструктуры, структура базы данных, редактируемые макеты, иллюстрации, документация, тексты и карточки в магазинах.

Для каждой категории нужно понять, получает ли заказчик исключительное право, лицензию или ограниченное право использования, в какой момент и на каких условиях. Для дальнейшей поддержки может понадобиться возможность изменять код, нанимать другую команду, запускать продукт в новых странах или передавать его при продаже бизнеса.

Отдельно укажите наработки исполнителя, существовавшие до проекта, и сторонние компоненты: библиотеки, шрифты, изображения, программные наборы и открытый код. Исполнитель не может передать больше прав, чем имеет сам.

Статья 1296 ГК РФ в общем случае связывает исключительное право на программу, созданную по заказу, с заказчиком, если договор не предусматривает иное. Но полагаться только на общее правило опасно: характер договора, конкретные материалы, прежние наработки и условия передачи могут менять вывод. Прямо перечислите результаты и нужные права, а формулировки проверьте с юристом.

Уточните, что означает передача исходного кода

Обещание «передать исходники» иногда заканчивается архивом без истории изменений и инструкции по сборке. В договоре или приложении можно назвать хранилища, доступы, ветки, зависимости, тесты, окружения, порядок выпуска и минимальную документацию.

Доступ заказчика к хранилищу во время разработки снижает риск неприятного открытия в последний день. При переносе репозитория нужно проверить не только файлы, но и владельца организации, автоматическую сборку, пакеты, страницы, ключи и оплату.

Практический критерий передачи прост: специалист, не участвовавший в проекте, может собрать тестовую версию по полученным материалам. Подробная проверка есть в руководстве по документации и передаче приложения.

Оформляйте важные аккаунты на компанию

App Store Connect, Google Play Console, домен, облачный сервер, платежи и другие критичные сервисы обычно лучше создавать на юридическое лицо или устойчивую корпоративную учетную запись заказчика. Исполнитель получает необходимые роли.

Apple и Google разрешают перенос приложений между аккаунтами при соблюдении условий, но связанные настройки, история и сервисы переносятся не всегда одинаково. Назначить правильного владельца до первой публикации проще, чем исправлять это после запуска.

Определите, кто оплачивает подписки, получает предупреждения и может менять рабочую среду. Истекшая личная карта или почта бывшего сотрудника не должны останавливать исправно переданный продукт.

Проверьте сторонние компоненты и регулярные расходы

Запросите список важных зависимостей, лицензий и подписок. Для небольшого проекта достаточно понятной таблицы; для продуктов с повышенными требованиями может понадобиться формализованный перечень компонентов.

Можно заранее решить, кто согласует нового поставщика и что делать при росте цены, смене лицензии или закрытии сервиса. Открытый исходный код не означает отсутствия условий использования.

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

Не ограничивайтесь словами «безопасно» и «по закону»

Общие обещания плохо проверяются. Требования к входу, правам доступа, шифрованию, журналам, резервным копиям, поиску уязвимостей и сообщению об инцидентах нужно связать с обязанностями сторон.

Если исполнитель получает настоящие персональные данные пользователей, потребуется определить цели, поручение на обработку, меры защиты, доступы, привлекаемые сервисы, возврат и удаление. Для российских проектов полезно отдельно проверить требования 152-ФЗ; основные вопросы разобраны в статье о персональных данных в мобильном приложении.

Укажите, в каких средах разрешены настоящие данные, кто имеет доступ к рабочей базе и как он отзывается. Обезличенные тестовые наборы снижают ненужный риск.

Отличайте ошибку от доработки и обслуживания

Ошибка — отклонение от согласованного требования. Доработка меняет поведение. Обслуживание включает совместимость с новыми версиями систем, обновление зависимостей, наблюдение и дальнейшие улучшения.

Задайте период исправления, уровни важности, канал связи и границы. Бессрочная бесплатная поддержка звучит неопределенно, но объявлять любую найденную ошибку новой платной задачей тоже неправильно.

После выпуска условия сопровождения можно вынести в отдельное соглашение. В материале о стоимости поддержки мобильного приложения перечислены работы, которые продолжаются после публикации.

Продумайте передачу проекта при прекращении работ

Сотрудничество может закончиться по стратегической, финансовой или организационной причине. Договор должен описывать готовые и незавершенные результаты, расчеты, лицензии, данные, конфиденциальную информацию и уже зарезервированную работу команды.

Лучше обновлять минимальный комплект передачи после каждого крупного оплаченного этапа: код, редактируемый дизайн, документацию, окружения, зависимости и список известных проблем. Дополнительная помощь другой команде может иметь заранее определенный срок и стоимость.

Заказчик должен уметь отозвать доступы без остановки приложения. Исполнитель должен иметь возможность подтвердить возврат или согласованное удаление данных.

Тревожные признаки

Проверьте расплывчатое «приложение принадлежит заказчику», одностороннюю автоматическую приемку без критериев, передачу кода только после неопределенного «окончательного расчета», личные аккаунты, отсутствие порядка изменений и скрытые сторонние компоненты.

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

Как Appfyl готовит проект к договору

До юридической проверки Appfyl раскладывает первую версию по ролям, сценариям, функциям панели администратора, интеграциям и обязанностям заказчика. Так техническое приложение опирается на проверяемые факты.

Мы также заранее определяем корпоративные аккаунты, демонстрации этапов и состав передачи. Приемка строится вокруг работающих цепочек, а не абстрактных процентов.

Вопросы к студии мобильной разработки помогут сравнить предложения. Интерактивный бриф Appfyl позволяет собрать функции до согласования цены, срока и договора.

Посмотрите, как Appfyl превращает объем работ в запущенные продукты. Смотреть кейсы Appfyl.

Частые вопросы