Программы и мобильные приложения стали неотъемлемым атрибутом жизни каждого человека. Профессия айтишника стала очень уважаемой и вошла в топы рейтингов.
А задумывались ли Вы когда-нибудь над юридической стороной вопроса? О том, как важно и сложно составлять договор на разработку мобильного приложения? И нужно ли это вообще?
Да, за многими, казалось бы, сугубо техническими процессами кроется прочная юридическая опора. Если хотите получить качественную программу, необходимо обязательно составлять договор на приложение с юристом.
А еще у нас вышел подкаст на тему «ДОГОВОР НА РАЗРАБОТКУ ПРИЛОЖЕНИЯ: сложные вопросы» → 
Подписывайтесь!
Вы можете заказать нашу услугу по разработке мобильного приложения по этой ссылке.
В этой статье мы хотим не столько себя порекламировать, сколько рассказать о важности договорных конструкций в таких процессах. Мы Вам расскажем, зачем вообще нужен договор, какая должна быть структура у договора на разработку мобильного приложения, как согласовать условия, как составить ТЗ, какой порядок оплат лучше выбрать.
Предлагаем для начала ответить на вопрос, а для чего вообще такой договор нужен и нужен ли вообще?
Нужен. Юристы вошли в сферу IT не как самозванцы, а как необходимое звено по пути к достижению цели.
Представьте: Вы хотите для своей компании разработать качественное приложение, которое будет работать на конкретных устройствах, выполнять конкретные задачи и функции, обновляться с определенной периодичностью, быть удобным в использовании, не лагать и много всего прочего.
Конечно, можно пойти к какому-нибудь частному программисту, устно изложить все свои пожелания и надеяться на лучшее. Гарантий качественного и желаемого результата Вам никто не даст. Зато деньги и время Вы точно потратите.
Когда Вы заказываете торт на День Рождения друга, то, разумеется, показываете кондитеру фотографию результата. И в случае, если цвет не тот, форма не та, Вам будет, как говорится, за что «предъявить», поскольку перед кондитером была поставлена четкая задача – сделать торт именно той формы и именно того вида, что были представлены на картинке.
С мобильным приложением сложнее. Это не просто какой-то визуальный образ, и это не просто какая-то схема действия. Это воссоединение множества компонентов в едином продукте – приложении. Чтобы получить желаемый результат, необходимо все требования изначально зафиксировать в договоре.
Разумеется, зачастую в процессе разработки приложения появляется необходимость внести правки, добавить какие-то функции, что-то убрать. Поэтому договор должен быть гибким, допускать эти изменения со стороны заказчика.
Важно понимать, что договор на разработку мобильного приложения – это не только про будущие споры и судебные разбирательства. Это и про поиск взаимных компромиссов и уступок. Обе стороны заинтересованы в результате: заказчик – в получении хорошего приложения, исполнитель – в полной и своевременной оплате своей работы.
Итак, каким же должен быть этот договор на приложение, составленный юристом?
Думаем, начать стоит с того, что такой договор по своей сути является рамочным договором. Что это значит? Рамочный договор – гибкое соглашение, которое позволяет сторонам менять/добавлять различные условия, при этом не составляя новых договоров и экономя время.
Многие из таких рамочных договоров имеют трехступенчатую структуру, это:
- Заказ на проектирование – тут стороны договариваются о том, а что вообще нужно сделать, «притираются» друг к другу, формируют макет.
- Заказ на разработку – непосредственно создание самого приложения.
- Заказ на сопровождение – приложение не будет вечно функционировать само по себе, нужен контроль за его работой со стороны IT-специалиста. Конечно, лучше, чтобы результат контролировал сам создатель.
Структура договора на создание мобильного приложения
Важно понимать, что такой договор по своему содержанию представляет сочетание двух договоров – договора на оказание услуг и на передачу исключительных прав. Отсюда и особенности в его структуре.
- Предмет договора
Условие о предмете – существенное условие для любого договора. Тем не менее, здесь не стоит усердствовать и стремиться расписать все, что будет входить в обязанности программиста.
Достаточно указать в этом разделе формулировку: «Исполнитель по заданию Заказчика выполняет определенные техническим заданием и приложением к Договору работы, а Заказчик обязуется вовремя их оплатить». Это примерная формулировка, но суть Вы поняли.
Поскольку договор на разработку приложения рамочный, все эти условия следует расписать в других разделах, а не загромождать предмет соглашения.
- Материалы
«Какие тут могут быть материалы?» — спросите Вы. Все просто: в данном договоре материал = информация.
Чтобы исполнитель смог качественно и в срок сделать свою работу, он должен получить от заказчика необходимый объем информации.
В случае, если заказчик запрашиваемой информацией не обладает, или ее достоверность находится под вопросом, или если на ее поиск заказчику нужно время, то в договоре следует прописать сроки, в течение которых заказчик должен исполнить свою обязанность по предоставлению информации.
В договоре также можно указать, что исполнитель будет работать исключительно с имеющимся у него самого объемом информации. Но важно понимать, что в договорах с подобным условием зачастую указывается, что в данном случае риски ненадлежащего выполнения ложатся на сторону заказчика, который отказался предоставить нужную информацию.
Таким образом, юрист может предусмотреть абсолютно разные условия, в зависимости от того, чью сторону ему надлежит защищать в договоре. Важно понимать, что юрист должен оставаться не просто специалистом со знаниями по праву, но и обладать сведениями о том, как разрабатываются мобильные приложения, как они работают, какие нюансы могут возникнуть.
- Порядок сдачи-премки
Чтобы принять продукт, он должен соответствовать установленному заказчиком заданию. В случае, если заказчик по каким-то причинам отказывается принять приложение, то этот отказ должен быть мотивирован и письменно оформлен.
Может быть и такое, что возникнет необходимость в доработке или внесении исправлений. Следует понимать, что это разные вещи, поэтому договором лучше сразу очертить границы двух этих категорий во избежание споров.
Например, условие договора может быть сформулировано так: «Доработка результата, исходя из новых данных и требований Заказчика, которые не были указаны в задании, не является исправлением. Такие доработки выполняются только за отдельную плату на основании отдельного задания. Исполнитель вносит исправления за свой счёт. Срок исправлений входит в общий срок выполнения задания».
На практике нередко бывает и так, что заказчик по каким-то причинам вовсе отказывается принимать работы, без объяснения причин. Поэтому исполнителю лучше подстраховаться и включить в договор условие о том, что в случае, в течение N дней после сдачи работы, отчета и актов работ, работы считаются автоматически принятыми.
- Интеллектуальные права
Важный раздел договора. Заказчику не стоит надеяться на то, что по заказу ему принадлежит абсолютно все. Автором остается разработчик. А заказчик ограничен рамками договора и может требовать передачи прав лишь на программный код, изображения, дизайн и т.д.
Более того, зачастую разработчики прибегают к использованию средств, права на которые принадлежат совсем другим авторам. Разработчик получает разрешение у такого автора на использование модуля в конкретных целях – для разработки приложения на продажу. Получается, что конечный потребитель, заказчик, может использовать этот продукт чужого интеллектуального труда только в мобильном приложении. Нюансов много, их можно и нужно отразить в приложениях к договору. Необходимо не только превентивно анализировать ситуацию, но и контролировать сам процесс разработки приложения, ведь от этого зависят условия соглашения.
- Конфиденциальность
Казалось бы, кому, от кого и что скрывать. НО:
— разработка договора на мобильное приложение с юристом и оплата труда программиста – это дорого: не особо захочется делиться результатом плодотворных работ и способом его достижения с конкурентами, согласитесь?
— мобильное приложение – это уникальный продукт, который предназначен для оптимизации тех или иных процессов, он связан со стратегиями развития и продвижения бизнеса;
— исполнители заинтересованы в том, чтобы их методики и инструменты остались секретом для других разработчиков.
Поэтому в конфиденциальности некоторых сведений могут быть заинтересованы как исполнители, так и заказчики. В договоре следует прописать, что вообще стороны понимают под конфиденциальными сведениями, и в каких пределах и целях она может распространяться.
Важный нюанс – портфолио разработчика. В договоре Вы можете указать, в праве ли исполнитель указывать в своем портфолио какие-то сведения о Вас и в каком объеме (например, наименование заказчика, товарный знак, его специализацию и др.)
- Ответственность сторон
Условия и размер ответственности юрист предусматривает исходя из того, на чьей он стороне 🙂 Тем не менее, чтобы не возникало разногласий, ответственность должна быть более-менее уравновешена для обеих сторон.
Например, следует установить, что в случае, если заказчик отказывается оплачивать работу или делает это невовремя, то он обязан уплатить исполнителю неустойку за каждый день просрочки. А если исполнитель задерживается с выполнением работ, то на него может быть возложена ответственность в виде удержании пени из его гонорара или, если задержка существенная, заказчик может отказаться от работ и оплатить только то, что фактически успело быть выполнено.
- Порядок оплаты и определения стоимости
Коли уж начали говорить про шум волн, давайте и про само море.
Существует два варианта оценки и оплаты работ:
- Оценивается и оплачивается сразу весь объем работ по ТЗ.
- Оценивается и оплачивается объем затраченных человеко-часов на выполнение каждого этапа разработки приложения.
Второй вариант представляется наиболее удобным и часто встречающимся. Такая договорная конструкция оплаты называется Time and Material. Мы даже записывали видео на эту тему.
—
Однако оба варианта имеют свои подводные камни.
-> В первом случае исполнитель скорее всего завысит стоимость работ. И не потому, что хочет нажиться, а потому, что на начальном этапе трудно определить реальную стоимость работ, поэтому в его же интересах подстраховаться.
-> Во втором случае никто не даст гарантий заказчику в том, что все оплаченные часы действительно были отработаны, а не «накручены» себе программистами ;). Поэтому рекомендуем почитать отзывы про работу того или иного разработчика. Если увидите жалобы на то, что приходилось платить, когда еще даже не было хоть какого-то видимого результата, то, возможно, стоит задуматься.
Договором также должны быть предусмотрены и многие другие условия: обстоятельства непреодолимой силы, срок договора, условия его расторжения, этапы работ, их приемка и расчеты, гарантийные обязательства, документооборот, реквизиты и подписи. Составление договора на разработку приложения или ПО – действительно трудная работа, поскольку требует от юриста комплексных знаний и абстрактности мышления.
В любом случае, не стоит забывать, что в договоре:
— у сторон должны быть равные права;
— формулировки не должны быть двусмысленными, неоднозначными, размытыми;
— должна быть учтена специфика бизнеса и проанализированы его основные особенности и потребности.
Наши юристы готовы помочь Вам в составлении договора на разработку мобильного приложения. Более того, мы сможем Вам помочь и в случае, если договор осложнен иностранным элементом: например, если заказчик или исполнитель не из России. В этом случае потребуется дополнительно предусмотреть порядок рассмотрения споров, применимое право, процедуру перехода прав на результат интеллектуальной деятельности и др. Мы специализируемся на разрешении споров и установлении договорных отношений с иностранными лицами.
Поделиться в соцсетях
