договор на разработку мобильного приложения на платформах android и ios
Договор на разработку мобильного приложения 2021
Как выбрать образец договора на разработку мобильного приложения
Отличия договоров на разработку мобильного приложения
Выбор договора производится с учетом того, какое лицо занимается разработкой мобильного приложения.
В отличие от договора заказной разработки, создание мобильного приложения по договору авторского заказа не влечет автоматического перехода исключительного права на приложение заказчику. Для этого необходимо включать в договор прямую говорку об отчуждении прав заказчику и указывать размер вознаграждения за передачу прав отдельно от стоимости работ по созданию мобильного приложения. В противном случае исключительные права сохраняются в полном объеме за автором.
Помимо этого при заключении договора на разработку мобильного приложения с автором следует помнить, что законом жестко ограничена ответственность автора за нарушения. Автор не возмещает упущенную выгоду, в отличие от разработчика – организации. Ответственность по договору авторского заказа ограничена возмещением реального ущерба, причиненного заказчику.
Автор также имеет право на дополнительный льготный срок завершения работ по договору авторского заказа продолжительностью в 1/4 от срока, установленного для выполнения работ.
В остальном договор авторского заказа существенно не отличается от договора заказной разработки. Теперь вы с уверенностью можете выбрать подходящий договор на разработку мобильного приложения.
Примеры документов
Наша организация работает с клиентами на основании договора между юридическими лицами. Так же возможно заключение договора с индивидуальным предпринимателем или физическим лицом.
Договор содержит описание регламента оказания услуг, стоимость, права на интеллектуальную собственность.
Техническое задание (ТЗ) является основным документом, содержащим задачу разработки. Именно в ТЗ должно быть описано все, до малейших деталей. Чем проработанней документ технического задания, тем меньше вероятности, что наши программисты сделают что-то, что не ожидает заказчик. Техническое задание является главным описанием задачи в возможных вопросах спора реализации мобильных приложений и других разработок. Мы описали процесс написания технического задания для мобильного приложения.
Этапы разработки и сроки по этапам выделяются в приложение 2 — Гант. Данный документ содержит описание процесса создания мобильного приложения, сайта или сервиса по этапам его реализации, тестирования, запуска, доработки, а так же гарантийной поддержки. Послегарантийная поддержка мобильных приложений выполняется на особых условиях, не входящих в договор, и являются отдельным предметом договоренностей.
Если задача на создание проекта нуждается в передаче дополнительных данных (например ключи доступа, сертификаты, фотографии, документы), то они должны быть перечислены в договоре в виде спецификации (Приложение 3), а так же переданы на электронном носителе или в виде ссылки на файловый обменник.
Исполнение договора подтверждается подписанием акта выполненных работ. В исключительных случаях, проект может быть разделен на несколько этапов разработки и оплаты. В данном случае формируются и подписываются промежуточные акты.
Пример договора на разработку мобильного приложения ООО «Дотрунет групп» (Лаборатория IOS)
Договор на разработку мобильного приложения на платформах android и ios
В общем случае аналитика может на два спринта идти быстрее разработки. На один спринт вперед — дизайн. Программирование — догоняет. А за программированием идет опять аналитика (сбор обратной связи от пользователей и генерация новых функций). Это позволяет добиться высокой утилизации, но довольно сложно управляется. Нагрузка высокая, причем на менеджера и со стороны студии, и со стороны заказчика. Много бумаг, много потоков, много нужно держать в голове. Но это цена за точные оценки сроков и бюджетов, их фиксацию в договоре и высокую скорость работ.
Поэтому есть разумная альтернатива. После того, как мы с клиентом притерлись, знаем, что друг от друга ожидать — вполне логично перейти с итераций в режим канбана с оплатой работ по факту затраченных работ. Клиенту создается канбан-доска, куда он может накидывать задачи и ставить приоритеты. Крупные задачи будут обработаны спринтами. Мелко-срочные — в порядке очереди, но по более высокому рейту. Для работы в таком формате мы подписываем приложение на техническую поддержку. Оно рассчитано на работу по отдельным задачам или небольшими спринтами.
Не забываем, что мы говорим про разработку по scrum. Поэтому в ходе работ у нас может поменяться список задач на следующий этап, по которому приложение уже подписано. В этом случае мы заключаем с заказчиком дополнительное соглашение к приложению, в котором фиксируем только те пункты, которые изменились. Наши шаблоны приложений построены так, что по сути мы переподписываем только смету.
Ошибки в документах могут стоить очень дорого. Поэтому мы придерживаемся (и вам рекомендуем) следующих правил при подготовке договоров:
Сам документооборот в студии и другие шаблоны и регламенты мы разбираем в нашем с Теглайном курсе управления digital-проектами. Присоединяйтесь!
Права на мобильное приложение: какие договоры заключить?
Конкуренция в современном бизнесе очень высока. Каждая компания хочет первой вывести продукт на рынок и обойти конкурентов. В таких условиях стоит защитить не только свои бизнес-идеи, но и программные разработки.
Как обеспечить информационную безопасность при заказе программного обеспечения? — В этом собственникам бизнеса помогут договоры, заключаемые с IT-компанией: NDA (договор о конфиденциальности и коммерческой тайне) и NCA (договор о неконкуренции).
Договор о конфиденциальности: NDA (Non-Disclosure Agreement)
Договор NDA — это фактически соглашение о коммерческой тайне. Стороны этого договора: заказчик — владелец бизнеса и компания-разработчик программного обеспечения.
При заключении NDA компания-разработчик (исполнитель) обязана держать в тайне следующие сведения:
• данные о заказчике и его бизнесе
• идею проекта, которая дает заказчику преимущество на рынке
• исходные коды программного обеспечения
• пробные версии ПО
• дизайн проекта
• используемые в ПО формулы и алгоритмы
• техдокументацию и т.п.
Если исполнитель нарушает договор NDA, заказчик вправе обратиться в суд и доказать факт кражи информации. В этом случае исполнитель будет выплачивать заказчику штрафные санкции, утвержденные в договоре NDA.
В свою очередь компания-разработчик программного обеспечения обязана принять меры, чтобы ее сотрудники не передали конфиденциальную информацию третьим лицам. Иначе разработчик будет нести серьезную финансовую ответственность.
Срок действия договора NDA — как правило, от 1 года до 5 лет. Принято считать, что дальше информация устаревает и уже не требует конфиденциальности.
Договор о неконкуренции: NСA (Non-Compete Agreement)
Если NDA договор понятен и распространен, то NCA используется гораздо реже и требует к себе внимательного отношения.
Как работает NCA? Представьте: вы, владелец бизнеса, нанимаете компанию-разработчика программного обеспечения для создания мобильного приложения. В ходе разработки исполнитель может понять, что продукт даст серьезную прибыль, и у него появится соблазн самому использовать вашу идею и стать вашим прямым конкурентом. Или — продать сведения сторонним фирмам, которые опять же станут вашими конкурентами.
От этого риска владельцев бизнеса и защищает договор NCA. В случае его подписания исполнитель обязуется в течение некоего срока после завершения проекта (как правило, это 2-5 лет) не становиться вашим конкурентом и не выполнять аналогичные проекты для конкурирующих организаций.
Взамен на ограничение деятельности исполнитель-разработчик должен получить компенсацию: высокую оплату работы, процент от будущей прибыли… Иначе ему будет просто невыгодно заключать договор NCA.
Теперь рассмотрим основные договоры по оформлению прав на программное обеспечение.
Договор на разработку программного обеспечения
Это самый распространенный тип договора, по которому компания-заказчик получает программное обеспечение и права на него.
Стороны договора: исполнитель (IT-компания) и заказчик — собственник бизнеса.
При заключении договора на разработку ПО следует максимально точно и четко определить требования к продукту. В этом вам поможет техническое задание, приложенное к договору. Без него заказчик рискует получить нерелевантный результат. Еще одно обязательное условие — сроки выполнения работ.
Интересно, что договор на разработку программного обеспечения будет действительным и без указания цены проекта, хотя на практике такое встречается редко.
По договору на разработку ПО исключительное право на софт принадлежит заказчику. Однако исполнитель может использовать ПО для собственных некоммерческих целей — публиковать кейсы, размещать в портфолио и т.д. Можно также отдельно прописать в договоре, что исключительное право на софт остается у исполнителя.
Договор авторского заказа
По сути, это одна из разновидностей договора на разработку ПО, но заключается он не между двумя компаниями (заказчик-исполнитель), а между заказчиком и автором — физическим лицом.
Смешанные формы договоров
На практике встречаются договоры на софт, который разрабатывается одной компанией, а затем «допиливается» другими разработчиками.
В этом случае надо заключить договор на приобретение неисключительного права на первоначальное ПО и исключительное — на ПО производное.
Еще один вариант: покупка лицензии на ПО, которое затем дорабатывается по договору по настройке (адаптации) продукта, т.е. в программное обеспечение вносятся изменения, связанные с особенностями его функционирования на конкретных девайсах или платформах.
Если серьезных доработок не планируется, то адаптацию ПО можно смело выполнять, без страха нарушить исключительные права на софт.
К числу сопутствующих договоров отнесем:
• договор на техподдержку (заключается после приобретения ПО)
• договор на гарантийное сопровождение (исполнитель бесплатно корректирует ошибки программного кода)
• договор на настройку ПО
• договор на модификацию (мелкие доработки по просьбе заказчика)
Это основные виды договоров, которые заключаются между компанией-заказчиком и разработчиком программного обеспечения. Мы работаем со всеми видами договоров и с каждым заказчиком прорабатываем этот момент индивидуально.
Будьте внимательны к деталям, выбирайте надежные команды, и тогда ваше ПО принесет прибыль вашему бизнесу!
Договор на разработку мобильного приложения
Зачем нужен договор
У любого договора есть две функции — коммуникативная и юридическая. Коммуникативная помогает убедиться в том, что стороны правильно поняли друг друга. Они обсуждают условия работы, приходят к согласию и фиксируют эти договорённости на бумаге.
Юридическая функция даёт страховку на случай, если одна из сторон нарушит обязательства. Если спор не удаётся решить мирно, — поможет арбитражный суд. Он рассмотрит доводы сторон и вынесет решение, исходя из условий договора. Поэтому формулировки в нём должны быть чёткими: всё неясное, неточное и обтекаемое проясните до того, как поставите подпись.
В чём особенность договора на разработку мобильного приложения
Разработка приложения — длительный и сложный процесс, на который влияет множество факторов как со стороны заказчика, так и со стороны исполнителя. Прописать все нюансы и учесть все риски в техническом задании невозможно. В ходе разработки появляются новые идеи, которые нужно учесть, меняются условия использования дополнительных сервисов, возникают технические проблемы, наступают кризисы. Это приводит к срывам сроков и изменению общей стоимости проекта.
Чтобы обезопасить себя от непредвиденных рисков, нужно заключить договор, который защитит обе стороны. При конфликтных ситуациях используйте его для того, чтобы найти компромисс и продолжить сотрудничество, а не для того, чтобы давить на другую сторону. Составьте договор так, чтобы заказчик и исполнитель чувствовали себя партнёрами и знали, что у них равные права и обязанности. Тогда в процессе работы вам не придётся тратить время на волокиту с документами.
Структура договора на разработку мобильного приложения
Договор на разработку мобильного приложения комбинирует два типа договоров — на оказание услуг (исполнитель работает над приложением) и на передачу права интеллектуальной собственности (заказчик получает результат чужого интеллектуального труда). Он состоит из десяти пунктов:
1. Предмет и основные условия. Что? Для кого? За сколько? В этом пункте договоритесь об обязательствах сторон, этапах работы, о процессе оплаты и об электронной подписи.
2. Расчёты. В этом пункте — про условия оплаты. Облагается ли она налогами? Когда считается завершённой? Нужно ли отправлять бумажную версию отсканированного счёта? Ответы должны устраивать обе стороны.
3. Сдача и приёмка работ. Пункт про то, как работа сдаётся исполнителем и принимается заказчиком. Помимо очевидных вещей, в пункте прописано как себя вести, если пошло не так: заказчик долго не выходит на связь с исполнителем или исполнитель предоставляет некачественный результат.
4. Передача интеллектуальной собственности. Благодаря этому пункту, заказчик получает исключительные права на всё, что было сделано в рамках проекта. Договоритесь о том, в какой момент передаются права.
В отдельном подпункте укажите, что в разработке используются результаты интеллектуального труда третьих лиц. Готовые наработки — библиотеки, тексты, иконки, иллюстрации, программные коды — делают разработку быстрее и дешевле. Часто они находятся в свободном доступе и не требуют дополнительного соглашения. Но их использование может сопровождаться условиями, которые важно учитывать. Не все готовые решения можно применять в коммерческом закрытом ПО.
Пример. Вы разрабатываете мобильный мессенджер с платной подпиской. Чтобы сэкономить время, вы используете модифицированный код Telegram, который находится в открытом доступе. Согласно его условиям распространения, вы должны открыть финальный код своего приложения для всех.
5. Гарантии. Про срок, в течение которого исполнитель устраняет ошибки и недочёты в своей работе. В пункте оговаривается, на что гарантия не распространяется и в каких случаях она прерывается досрочно. Например, если заказчик решил поправить приложение своими силами и нарушил его работу, то разработчик больше не отвечает за его функционирование.
6. Конфиденциальность. В этом пункте стороны договариваются о неразглашении информации, заказчик разрешает исполнителю опубликовать результаты работ в портфолио. Аналогичное соглашение подписывается с третьими лицами, если они участвовали в разработке.
7. Ответственность и обстоятельства непреодолимой силы. Что происходит, когда стороны не выполняют свои обязательства. В пункте — начисление неустоек за срыв сроков и порядок досудебного разбирательства с последующим обращением в суд. Вы избегаете ответственности только в том случае, если на вашу работу повлияли обстоятельства непреодолимой силы. Но без справки от компетентных органов в это никто не поверит.
8. Действие и расторжение. Про сроки действия договора, возможность его продления и расторжение. В пункте говорится, что о пожелании расторгнуть договор нужно предупредить за месяц, и описывается порядок досрочного расторжения.
9. Иные условия. В пункте — стандартные вещи про документооборот: договор действует на основании ГК РФ, а дополнительные соглашения являются его неотъемлемой частью.
10. Реквизиты. Здесь указываются актуальные данные заказчика и исполнителя: адреса, налоговые идентификаторы, номера счетов, ставится дата и подпись.
Готовый договор от «Лайв Тайпинга»: скачайте и начните разработку сейчас
Работать с шаблоном от «Лайв Тайпинг» несложно: в нём есть интерактивное оглавление, с которым вы быстро просмотрите все разделы. Наш договор — рамочный, в нём прописаны общие правила и обязанности сторон, а договорённости и детали по конкретному проекту вам придется самостоятельно зафиксировать в дополнительных соглашениях. Вы найдете их под основным документом. В приложениях также есть шаблоны технического задания.
Чтобы получить готовый договор, вам нужно:
Какое дополнительное соглашение выбрать
Допсоглашения конкретизируют условия рамочного договора. Их основная задача — во всех деталях описать то, что клиент хочет получить от студии по итогу работы. Наш договор предусматривает три варианта шаблонов дополнительных соглашений, подходящих для разных видов сотрудничества:
1. Fixed price. Заказчик покупает законченный продукт или его часть. Например: создание кликабельного прототипа приложения, разработку дизайна мобильного приложения или разработку приложения под iOS целиком с нуля. Это доспоглашение описывает этапы работы с фиксированными ценой и сроками. Вариант Fixed price подходит для работы над простыми проектами с понятной функциональностью, чётко прописанной в ТЗ. Выход за рамки ТЗ с сохранением прежних сроков и стоимости работы невозможен. Если заказчик хочет на лету менять требования и не зависеть от ТЗ, то лучше выбрать более свободную модель оплаты.
2. Time&Materials. Заказчик платит за время специалистов, потраченное на работу над его проектом. Круг задач и стоимость часа работы оговариваются в допсоглашении. Например, клиенту нужно создать приложение для iOS. Для этого нужны менеджер проекта, дизайнер, разработчик и тестировщик. В течение месяца эти специалисты трудятся на проекте, а в конце месяца клиент получает отчёт о количестве затраченных часов и оплачивает их. Этот вид сотрудничества хорош тем, что клиент гораздо быстрее видит результат и может вносить изменения в процессе. Этот вариант подходит для долгосрочных проектов.
Лучше разобраться в тонкостях Fixed price и Time&Materials вам поможет наша статья.
3. Time&Materials period (он же Retainer). Данная практика пришла в ИТ из юридического бизнеса. Заказчик «оптом» выкупает всю команду, нужную для ведения проекта, на долгий срок. Период, состав команды и цена фиксируются в допсоглашении. Оплата и приём работ происходят раз в месяц/неделю. Это самый эффективный вариант работы над проектом, потому что в нём не нужно бесконечно подписывать документы, скрупулёзно считать часы и согласовывать каждый шаг. В начале периода заказчик и разработчик составляют план работ, в конце — подводят итог и фиксируют результаты, подписывая акт, который передаёт клиенту права на сделанные работы. Одновременно он является актом приёмки этих работ. Способ подходит для сложных и долгосрочных проектов, на которых важна полная вовлечённость всех участников команды.