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

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

Договор на разработку мобильного приложения
СОДЕРЖАНИЕ
0

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

Договор на разработку не должен быть универсальным: мы составляем их каждый раз заново в зависимости от того, какую модель разработки ПО договор должен отражать. Например, наиболее классическим примером можно считать договор, основанный на Waterfall-модели, однако более широко используются Agile-договоры, часто объединяемые с аутстафом (outstaffing) или dedicated team. Они имеют разную начинку и всегда предусматривают внимание к интересам клиента.

Кроме того, всегда существуют дополнительные специфические договоренности между разработчиком и заказчиком: кто получает имущественные права на конечный продукт? Охраняется ли коммерческая тайна? Как разработчик может выйти из проекта? Существует ли порог стоимости разработки? Так еджайл или вотерфол?

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

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

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

Иначе данный вопрос решается в законодательстве в случае, когда для разработки мобильного приложения привлекается физическое лицо. Это может быт и предприниматель, который выступает в качестве единственного разработчика (автора) по договору. В таком случае должен заключаться договор авторского заказа , который регулируется ст.1288-1290 ГК РФ.

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

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

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

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

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

Договор(шаблон договора) на разработку мобильного приложения с указанием реквизитов и ответственности сторон, сроков реализации и приема работ

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

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

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

Как обеспечить информационную безопасность при заказе программного обеспечения? — В этом собственникам бизнеса помогут договоры, заключаемые с IT-компанией: NDA (договор о конфиденциальности и коммерческой тайне) и NCA (договор о неконкуренции).

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

Стороны договора: исполнитель (IT-компания) и заказчик — собственник бизнеса.

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

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

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

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

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

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

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

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

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

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

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

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

Техническое задание (Приложение 1)

План-график этапов и сроки (Приложение 2)

Акт выполненых работ

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

С юридической точки зрения, такой гарантией является заключение договора на поставку программного обеспечения (ПО). Условия использования ПО регулируются лицензией, а также четвертой частью Гражданского Кодекса Российской Федерации. Программное обеспечение может являться готовым («коробочным») программным продуктом, требующим лишь настройки под нужды заказчика, или же может быть специально разработано по техническим требованиям.

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

  1. Стоимость, сроки поставки, этапы разработки и оплаты. Как правило, договор заключается на фиксированную сумму и имеет определенные рамки, регулируемые техническим заданием на проведение работ. В случае необходимости доработки мобильного приложения, не связанного с исправлением его ошибок, такая доработка оформляется дополнительным соглашением к договору.
  2. Условия передачи прав (лицензирование) мобильного приложения и сопутствующего программного обеспечения. Как правило, при разработке мобильного приложения на заказ, все права на приложение как целое передаются заказчику. В случае использования при разработке готовых компонентов, они могут передаваться по той или иной лицензии (как правило, это лицензия, разрешающая использование компонента в составе мобильного приложения, но не передающая исключительные права покупателю приложения).
  3. Условия гарантии на программное обеспечение. Заново разработанный продукт всегда содержит скрытые ошибки, которые исправляются в течение гарантийного периода (как правило, несколько месяцев).
  4. Договор по разработке мобильного приложения чаще всего содержит и дополнительные условия – конфиденциальность, условия приемки-сдачи работ, разрешение споров и прочее.

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

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

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

Вотерфол

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

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

«Стороны соглашаются, что стоимость услуг составляет _ евро за час, при условии, что в сумме Исполнитель потратит _ часов на оказание услуг в соответствии с Техническим заданием.»

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

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

Однако в тех случаях, если заказчик хочет заглядывать под вуаль таинства разработки его ПО, стороны могут договориться о milestone-based pricing (оплата частями в течение определенного периода): в таком случае заказчик может присутствовать на нескольких промежуточных остановках (так называемых milestones), под время которых заказчик отдает часть стоимости, чтобы разработчик мог работать дальше, смотрит на прогресс работы, тестирует уже имеющиеся фишки и в целом убеждается, что работа куда движется.

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

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

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

«Общий срок предоставления Услуг составляет _ месяцев с момента подписания настоящего Договора. После получения Результаты разработки Заказчик, согласно Milestone Schedule, должен в течение пяти рабочих дней проверить Результаты на наличие дефектов и сообщить Исполнителю о результатах тестирования ».

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

Аджайл

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

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

«Заказчик услуги путем привлечения разработчиков из собственного штата и / или самозанятых ИТ-разработчиков (« Команда Разработчиков ») и отвечает за надлежащий уровень экспертизы каждого разработчика.»

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

«Заказчик имеет право требовать исключить конкретного разработчика с Команды Разработчиков, или уменьшить количество Разработчиков, занятых в предоставлении услуг без предварительного согласия Исполнителя.»

Dedicated team отличается от outstaffing если аутстаф предусматривает выделение команды среди трудоустроенных разработчиков, которых работодатель «передает» заказчику ПО в штат (что связано с определенными трудностями ввиду того, что законодательство Украины о труде требует согласия каждого из работников на такое перемещение), то dedicated team фокусируется на распределении трудовых обязанностей внутри трудового коллектива, и не связан с изменением места работы или работодателя.

1. Предмет Договора

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

1.1. Оказание услуг по разработке мобильного приложения «ХХХ» в соответствии с Техническим заданием (Приложение № 1 к настоящему Договору).

1.2. Исполнитель обязуется передать в собственность Заказчика результат оказанных услуг, а Заказчик оплатить и принять оказанные услуги в количестве, качестве в соответствии с Техническим заданием (Приложение № 1 к настоящему Договору), являющимися неотъемлемой частью настоящего Договора.

1.3. Сроки оказания услуг: c момента заключения договора по _____________ года включительно.

1.4. Место оказания услуг: _______________________________________________

На что же еще нужно обратить внимание?

«Заказчик оплачивает выставленный Исполнителем счет (инвойс) в течение _ дней, однако в любом случае не позднее 180 дней с момента выставления счета. В случае, если Заказчик не оплачивает счет (инвойс) в течение _ дней, Исполнитель может обратиться с иском в хозяйственный суд по местонахождению Исполнителя. »

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

«Результаты оказанных услуг передаются Исполнителем Заказчиком путем загрузки Исполнителем таких результатов в Систему, если иное не было согласовано Сторонами.»

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

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

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

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

Сбор и обработка персональных данных. Учитывая то, что наиболее экономически активные страны активно включились в разработку законодательства о защите персональных данных, следует убедиться, что договор предусматривает защиту Вас от ответственности по праву Вашего контрагента. Особенно внимательно следует отнестись контрагентов с ЕС, США (в частности, штат Калифорния), Сингапур, Гонконг, Российской Федерации, Австралии и других стран, которые сейчас крайне внимательно относятся к защите персональных данных своих граждан.

Неконкуренция и защита конфиденциальной информации. Формулировать соглашение о неконкуренции (non-compete agreement) как наказание работника за смену работодателя не следует — это повредит не только репутации как работодателя, но еще и не даст никаких дополнительных шансов победы в суде. Несмотря на то, что суды традиционно становятся на сторону нарушителя, соглашения о неконкуренции могут применяться или как способ предотвратить нарушение работником или контрагентом взятых на себя обязательств, или как способ защитить конфиденциальную информацию, которую такой контрагент или работник получил во время сотрудничества.

  Однако чтобы воспользоваться non-compete agreement (или NCA) как способом предотвратить утечки конфиденциальной информации, следует соблюдать несколько важных условий:

  • четко определить условия о неразглашении конфиденциальной информации;
  • указать, какая информация является конфиденциальной;
  • определить, как фиксируется факт передачи конфиденциальной информации;
  • предсказать, какие именно действия будут считаться разглашением или использованием конфиденциальной информации;
  • расписать, как будет фиксироваться факт разглашения конфиденциальной информации;
  • установить ответственность за такое разглашение (штраф, возмещение убытков).

Только при условии, что все эти элементы будут присутствовать, у владельца конфиденциальной информации появится возможность подтвердить законность своих требований о возмещении в суде. Вместе с тем, если основной целью является все-таки не содержание работника, а конфиденциальности, то лучше отдать предпочтение заключению соглашения о неразглашении (non-disclosure agreement, или NDA), чтобы предотвратить толкованию такого соглашения как нарушение контрагента или работника права на труд .

We are fair ’cause we care. Хороший договор на разработку должно напоминать сторонам о все договоренности, достигнутые на переговорах, а качественный договор призван еще и защищать разработчика или заказчика от непредвиденных ситуаций, не приходят в голову сразу.

8. Обстоятельства действия непреодолимой силы

2.1. Стоимость услуг по Договору составляет __________ (__________) тенге, включая все налоги и сборы.

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

2.3. Оплата производится в тенге, безналичным перечислением денежных средств Заказчиком, на расчетный счет Исполнителя, в течение 30 (тридцати) календарных дней после подписания обеими сторонами акта сдачи-приемки оказанных услуг.

4.1. Приемка результатов оказанных услуг осуществляется приемочной комиссией, назначенной Заказчиком с участием представителя (представителей) Исполнителя.

4.2. Приемочная комиссия, получившая сообщение Исполнителя о готовности к сдаче результатов оказанных услуг, обязана приступить к их приемке в течении 5 (пяти) рабочих дней .

4.3. Приемка услуг осуществляется не более 5 рабочих дней.

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

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

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

4.6. Исполнитель обязан устранить все обнаруженные недостатки (дефекты) за свой счет в сроки, указанные в протоколе.

4.7. Устранение Исполнителем в установленные сроки выявленных Заказчиком недостатков (дефектов) не освобождает его от уплаты штрафа и (или) неустойки (штрафа, пени).

4.8. Датой приемки оказанных услуг считается дата подписания акта приемки-сдачи услуг.

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

Предлагаем ознакомиться:  Основания для прекращения брака в суде

8.2. Сторона, для которой надлежащее исполнение обязательств оказалось невозможном вследствие возникновения обстоятельств непреодолимой силы, обязана в течение 5 (пяти) календарных дней с даты возникновения таких обстоятельств уведомить в письменной форме другую Сторону об их возникновении, виде и возможной продолжительности действия.

8.3. Если обстоятельства непреодолимой силы будут длиться более 30 (тридцати) календарных дней с даты соответствующего уведомления. Каждая из Сторон вправе расторгнуть настоящий договор без требования возмещения убытков, понесенных в связи с наступлением таких обстоятельств.

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

8.4. В случае действия обстоятельств непреодолимой силы менее 30 (тридцати) дней срок исполнения договора Сторонами отодвигается соразмерно времени, в течение которого действуют обстоятельства непреодолимой силы и их последствия.

9.1. Настоящий Договор вступает в силу с момента его заключения и действует до полного исполнения Сторонами своих обязательств по настоящему Договору.

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

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

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

9.4. Любое уведомление, которое одна Сторона направляет другой Стороне, направляется в письменной форме почтой или факсимильной связью с последующим представлением оригинала. Уведомление вступает в силу в день получения его лицом, которому оно адресовано. Если иное не установлено законом.

9.5. Во всем, что не предусмотрено настоящим Договором, Стороны руководствуются действующим законодательством Республики Казахстан.

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

Приложение №1: Техническое задание на _ л. в 1 экз.;

Казахстан, г. Астана, Улица Дом, оф. №

Телефон 8 (7172) хх хх хх

АО «Казкоммерцбанк» <наименование ЮЛ или ФЛ по виду договора>

ИИК KZхххххххххххххххххх БИК KZKOKZKX АО «Казкоммерцбанк»

м.п. <должность, ф.,и.,о. лица, подписывающего договор, подпись, печать, если лицо физическое, то его ИИН>

6. Ответственность сторон

3.1.1. Оказать услуги по разработке мобильного приложения «ХХХ» в соответствии с Техническим заданием (Приложение №1 к настоящему Договору), надлежащего качества. В срок, указанный в пункте 1.3 Договора.

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

3.1.3. Согласовать с Заказчиком действия. Предпринимаемые в целях исполнения настоящего Договора.

3.1.4. Выполнить в полном объеме все свои обязательства, предусмотренные в других пунктах настоящего Договора.

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

3.1.6. Устранить за свой счет недостатки, иные дефекты, выявленные Заказчиком в ходе контроля за ходом оказания Услуг. В течение гарантийного срока предусмотренного в пункте 5.2 настоящего Договора.

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

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

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

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

3.2. Заказчик обязуется

3.2.1. Принять надлежащим образом оказанные Исполнителем Услуги по акту сдачи-приемки оказанных услуг и оплатить их в соответствии с условиями настоящего Договора.

3.2.2. Провести поверку оказанных Услуг на соответствие Техническому заданию.

3.2.3. Оказывать содействие Исполнителю при оказании Услуг в объёме и на условиях, предусмотренных Договором.

3.2.4. Предоставить Исполнителю по его письменному запросу информацию, необходимую для оказания Услуг.

3.2.5. Сообщить Исполнителю о выявленных дефектах качества оказанных Услуг.

3.3. Исполнитель имеет право

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

3.3.2. Требовать оплаты надлежащим образом оказанных Услуг в соответствии с разделом 2 настоящего Договора.

3.4. Заказчик имеет право

3.4.1. Требовать предоставление информации, касающейся оказания Услуг по настоящему Договору.

3.4.2. Потребовать устранение обнаруженных при приемке оказанных услуг в период гарантийного срока недостатков (дефектов) за счет Исполнителя.

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

3.4.3. Задержать оплату оказанных услуг до устранения обнаруженных недостатков (дефектов).

6.1. За неисполнение или ненадлежащее исполнение своих обязательств по Договору Стороны несут ответственность в соответствии с действующим законодательством Республики Казахстан.

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

6.3. Размер неустойки (штрафа, пени) устанавливается в размере 1 (одного) % от стоимости оказанных услуг (пункт 2.1 настоящего Договора).

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

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

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

6.7. В случае неисполнения или ненадлежащего исполнения Исполнителем своих обязательств Заказчик взыскивает с Исполнителя штраф. Размер штрафа устанавливается в размере 10 (десяти) % от стоимости оказания услуг (пункт 2.1 настоящего Договора).

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

6.9. Уплата неустойки (штрафа, пеней) и (или) штрафа не освобождает Исполнителя от исполнения обязательств, предусмотренных Договором, в натуре.

7. Разрешение споров

7.1. Стороны принимают все меры к тому, чтобы любые спорные вопросы, разногласия либо претензии, касающиеся исполнения настоящего Договора, были урегулированы путем переговоров с оформлением совместного протокола урегулирования споров.

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

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

Договор о конфиденциальности: NDA (Non-Disclosure Agreement)

Договор NDA — это фактически соглашение о коммерческой тайне. Стороны этого договора: заказчик — владелец бизнеса и компания-разработчик программного обеспечения.

• данные о заказчике и его бизнесе

• идею проекта, которая дает заказчику преимущество на рынке

• исходные коды программного обеспечения

• пробные версии ПО

• используемые в ПО формулы и алгоритмы

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

• техдокументацию и т.п.

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

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

Срок действия договора NDA — как правило, от 1 года до 5 лет. Принято считать, что дальше информация устаревает и уже не требует конфиденциальности.

Договор о неконкуренции: NСA (Non-Compete Agreement)

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

Как работает NCA? Представьте: вы, владелец бизнеса, нанимаете компанию-разработчика программного обеспечения для создания мобильного приложения. В ходе разработки исполнитель может понять, что продукт даст серьезную прибыль, и у него появится соблазн самому использовать вашу идею и стать вашим прямым конкурентом. Или — продать сведения сторонним фирмам, которые опять же станут вашими конкурентами.

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

От этого риска владельцев бизнеса и защищает договор NCA. В случае его подписания исполнитель обязуется в течение некоего срока после завершения проекта (как правило, это 2-5 лет) не становиться вашим конкурентом и не выполнять аналогичные проекты для конкурирующих организаций.

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

Теперь рассмотрим основные договоры по оформлению прав на программное обеспечение.

Договор с разработчиками

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

Владимир Беляев, координатор «Центра управления законом»

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

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

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

Предлагаем ознакомиться:  Мне до сих пор не прислали налоги

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

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

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

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

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

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

1. Передача исключительных прав.

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

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

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

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

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

2. Предусматривание ответственности за использование чужих материалов.

Соглашение с пользователями

Чем точнее в документе учтена специфика сервиса, тем меньше вероятность того, что у вас не найдется адекватного решения при возникновении конфликтной ситуации.

Павел Мищенко, юрист

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

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

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

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

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

Вайсфельд Мэтт, автор книги «Объектно-ориентированное мышление»

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

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

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

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

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

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

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

Государство позаботилось о правильности создания ТЗ, выпустив для этого соответствующие межгосударственные стандарты (ГОСТ, ОСТ). Вот только проблема в том, что они несколько устарели. Например, ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы» был выпущен еще в 1989 г. Не советую использовать ГОСТ как основу для создания качественного ТЗ, хотя вы можете почерпнуть там что-то полезное.

Как и договор, ТЗ в процессе работы над приложением может изменяться. Не стоит относиться к договоренностям так, будто они высечены на камне – эти времена давно прошли. Действуйте гибко. Если выгодно изменить договор, в том числе техническое задание, – меняйте. Жизнь часто вносит коррективы, и лучше вовремя приспосабливаться к происходящему.

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

1. Назначение, цели, задачи и результат.

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

2. Целевая аудитория.

Комментировать
0
Комментариев нет, будьте первым кто его оставит

Это интересно
Adblock detector