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

Как выбрать образец договора на разработку мобильного приложения

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

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

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

Если вы нанимаете для создания мобильного приложения организацию или индивидуального предпринимателя со штатом, то необходимо использовать договор заказной разработки программного обеспечения . Такой договор регулируется положениями ст.1296 ГК РФ. По умолчанию исключительное право на результаты работ по договору принадлежит заказчику. Хотя договором может быть предусмотрено предоставление заказчику лицензии на результаты интеллектуальной деятельности разработчика.

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

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

Автор также имеет право на дополнительный льготный срок завершения работ по договору авторского заказа продолжительностью в 1/4 от срока, установленного для выполнения работ.

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

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

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

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

Правовые вопросы для дилетантов

Обычно на разработку какого-либо информационного продукта уходит много времени и исполнители часто срывают сроки. Если они будут прописаны в договоре, то разработчики постараются выполнить свою задачу вовремя. А без письменной договоренности, неизвестно, когда программист соизволит её закончить. Ведь при срыве своих обязательств, ему придется выплачивать проценты заказчику или он, может остаться без компенсации.

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

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

Передача исключительного права

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

Это интересно:  Договор купли продажи недвижимости с рассрочкой платежа

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

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

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

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

Предусмотренная ответственность

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

Техническое задание

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

В приложении 2, описывают весь производственный процесс поэтапно. Сюда входит реализация, тестирование, запуск, доработка и гарантия. Отдельно договариваются о послегарантийной поддержке.

В приложении 3 перечисляют дополнительные данные в виде сертификатов, фотографий, ключей доступа, документов.

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

Условия по приему-передаче дизайнерской разработки

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

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

Нераспространение информации

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

Результат сотрудничества

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

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

Условия оплаты

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

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

Заключение

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

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

Людям, не искушенным в документообороте, этот текст может показаться довольно запутанным. А тем, для кого оформление контрактов — рутина, наоборот, слишком простым. Но нас часто спрашивают, как у нас организована работа по scrum с точки зрения документооборота, и как выглядят наши договоры.

Даже если вам покажется, что получается слишком много бумаг, или всё слишком сложно — это не так. Мы используем простые и понятные контракты, в которых проработаны интересы как клиента, так и студии. Адекватно. Без перегибов. На уровне здравого смысла. Моя политика простая — либо win-win, либо не связываться.

Это интересно:  Гражданско правовой договор бланк

Наши шаблоны договоров рассчитаны в первую очередь на работу по scrum. То есть на итеративную разработку, когда проект запускается поэтапно. Сначала — самые важные с точки зрения бизнеса функции. С которыми уже можно жить и обеспечивать продажи. Затем системно выпускаются новые версии. Состав работ можно менять на ходу — что-то убирать, добавлять или заменять на равноценные функции. Это позволяет заказчику проверить свою бизнес-идею и запустить самое важное как можно быстрее. Поэтому мы подписываем с заказчиком рамочный договор, где фиксируем общие условия сотрудничества. Принципы. То, на чем пожали руки. На отдельные этапы работ мы подписываем приложения к договору.

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

Свои шаблоны мы постепенно меняли с учетом изменений в законодательстве и новых подводных камней, на которые натыкались. Не переписывали полностью, но добавляли «заплатки». В итоге они стали громоздкими и неудобными. Поэтому в этом году мы решили сделать рефакторинг, навести порядок в шаблонах документов и практически полностью их переработали (@ПавелМищенко, спасибо).

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

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

В начале работы над проектом вместе с рамочный договором мы подписываем приложение на агрегацию требований.

Мы исходим из предпосылки, что ни клиент, ни мы сами точно не знаем, как и в каком виде лучше всего сделать проект. И нужно выполнить предпроектную работу:

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

Эта работа стоит денег, но она — относительно дешевая. Заказчику психологически проще оплатить первый счет, когда он в пределах 24-60 часов. К тому же только после этапа агрегации требований у нас появляется согласованная структура, верхнеуровневый roadmap будущего проекта: мы можем уточнить список страниц, которые необходимо прототипировать.

Вторым этапом мы подписываем приложение на разработку прототипов страниц, и, если этого просит клиент, — технического задания. В классическом scrum-е технического задания не предполагается, вместо него используется бэклог — список всех хотелок, которые клиент хочет когда-нибудь реализовать. Однако многие по старинке хотели бы иметь такой документ. Проблем нет, мы его готовим, причем именно с той целью, чтобы затем раздербанить на бэклог. Наличие технического задания на проекте не заставляет нас строго следовать его букве. Конечный состав работ определяется СМЕТАМИ в приложениях на каждый отдельный спринт.

В общем случае аналитика может на два спринта идти быстрее разработки. На один спринт вперед — дизайн. Программирование — догоняет. А за программированием идет опять аналитика (сбор обратной связи от пользователей и генерация новых функций). Это позволяет добиться высокой утилизации, но довольно сложно управляется. Нагрузка высокая, причем на менеджера и со стороны студии, и со стороны заказчика. Много бумаг, много потоков, много нужно держать в голове. Но это цена за точные оценки сроков и бюджетов, их фиксацию в договоре и высокую скорость работ.

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

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

Ошибки в документах могут стоить очень дорого. Поэтому мы придерживаемся (и вам рекомендуем) следующих правил при подготовке договоров:

  • Использовать единые шаблоны договоров. Каждый новый договор мы обязательно делаем из шаблона, а не из договора от предыдущего заказчика. Чтобы руководителям проектов было проще при подготовке документов, места, которые могут меняться, выделены в цветом.
  • Править шаблон сразу, если обнаружили в договоре какую-то нестыковку или неожиданный нюанс (которым, естественно, больно прилетело по лбу). Так важные изменения в договорах гарантированно будут тиражироваться по всем последующим документам.
  • Периодически проводить ревизию шаблонов и актуализировать их. Мы обычно делаем это один-два раза в год.
  • Не отправлять договоры заказчикам без дополнительной проверки. При проверке приложений дополнительно надо обращать внимание на сроки, сверять все строки сметы, пересчитывать итоговые суммы.

В приложении к статье — джентльменский набор документов. Рамочный договор. Приложение на аналитику (агрегацию требований). И комплексное приложение на одну итерацию разработки. Остальные приложения (кроме, пожалуй, техподдержки и работы по канбану) логично вытекают из этих документов (да и нам просто жадно). Шутка.

Сам документооборот в студии и другие шаблоны и регламенты мы разбираем в нашем с Теглайном курсе управления digital-проектами. Присоединяйтесь!

Примеры документов

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

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

Техническое задание (ТЗ) является основным документом, содержащим задачу разработки. Именно в ТЗ должно быть описано все, до малейших деталей. Чем проработанней документ технического задания, тем меньше вероятности, что наши программисты сделают что-то, что не ожидает заказчик. Техническое задание является главным описанием задачи в возможных вопросах спора реализации мобильных приложений и других разработок. Мы описали процесс написания технического задания для мобильного приложения.

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

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

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

Пример договора на разработку мобильного приложения ООО «Дотрунет групп» (Лаборатория IOS)

Статья написана по материалам сайтов: narabotu-online.ru, blog.sibirix.ru, ios-lab.ru.

»

Помогла статья? Оцените её
1 Star2 Stars3 Stars4 Stars5 Stars
Загрузка...
Добавить комментарий

Adblock
detector