Мы в IPStyle почти уверены, что у вашего бизнеса уже есть разработанный по заказу веб-сайт, или даже бот на основе искусственного интеллекта или собственное приложение.
Сегодня диджитализация бизнеса, независимо от отрасли, имеет значительное влияние на его успех и может стать решающим фактором для максимизации прибыли. Однако для достижения этого недостаточно только заказать разработку софта. Поскольку любой программный продукт и/или его части являются объектами права интеллектуальной собственности, критически важно вовремя позаботиться о правовой стороне процесса разработки.
Ниже мы расскажем о том, как правильно построить и оформить отношения между заказчиком и разработчиком для успешного запуска вашего диджитального продукта.
Отношения «заказчик» — «разработчик»
Отношения между заказчиком и разработчиком обычно базируются на договоре о выполнении работ или оказание услуг по разработке программного обеспечения или на договоре по консультированию в сфере информатизации.
При этом, разработчиком может быть:
а) компания, которая нанимает физических лиц-предпринимателей (ФЛП) для выполнения ваших работ, и по сути выступает для ФЛП заказчиком;
б) компания, которая использует наемных работников в своем штате;
в) непосредственно ФЛП.
Сегодня мы рассмотрим основные аспекты, на которые нужно обращать внимание при заключении договоров между заказчиком и разработчиком-ФЛП. А на отношениях между заказчиком и компанией, которая использует наемных работников, мы остановимся в наших следующих материалах.
I. Способы организации работы по договору
Есть два варианта работы по договорам между заказчиком и разработчиком — waterfall и agile.
Waterfall — это линейный процесс организации работ по договору. Он заключается в наличии закрепленной договором четкой последовательности этапов и требований к ним, сроков выполнения каждого этапа и их проверки.
Положительной стороной waterfall является возможность четко предусмотреть ключевые вопросы, установить требования к каждому из этапов, что означает наличие у заказчика полного понимания того, что и на каком этапе он ожидает от разработчика. В то же время негативной стороной waterfall является невозможность внести существенные изменения в уже разработанный софт согласно установленных этапов. Проблемы с софтом могут не возникнуть при его принятии в соответствии с этапом, а проявиться позже.
Модель waterfall не подходит заказчикам, которые на момент подписания договора до конца не понимают свой конечный продукт и не могут сформировать четкие требования к нему, рассчитать имеющийся бюджет или сроки исполнения.
Agile — это менее строгий по waterfall процесс организации работ по договору. Он не требует от заказчика четко предусматривать этапы разработки софта и требования к ним, а позволяет лишь определить общую сферу и цель взаимодействия. Agile предполагает наличие маленьких промежуточных этапов и постоянное взаимодействие сторон. Это означает, что после выполнения одной задачи, разработчик согласовывает ее результаты с заказчиком и согласовывает следующий промежуточный этап.
Agile — это о постоянном взаимодействии заказчика и разработчика и постоянном согласовании между ними промежуточных этапов для создания конечного продукта. Разработчик имеет определенную свободу по такому договору и может основательно понять желания заказчика, а иногда помочь ему сформировать их. Заказчик так же может определять более приоритетные направления разработки, сферы, нуждающихся в улучшении и тому подобное.
Существенным плюсом agile является возможность быстро и эффективно реагировать на необходимость внесения каких-либо изменений (в софте, в задачах заказчика и т.д.). Однако это означает, что сложно заранее определить бюджет разработки, а процесс согласования между разработчиком и заказчиком может занимать много времени, приводить к конфликтам из-за отсутствия четких этапов и требований.
Выбор между waterfall или agile будет зависеть от конкретных потребностей заказчика и возможностей разработчика. В договоре на разработку софта должны быть все существенные условия, четко выражена модель организации работы и взаимодействия между заказчиком и клиентом, их права и обязанности. Поскольку несоблюдение может привести к затягиванию разработки, конфликтам, а иногда и судебным спорам.
ІІ. Предмет
Предмет — это основа любого договора.
Заказчику и разработчику нужно согласовать, будут ли предметом работы, услуги, будет ли разработка связана с простым созданием и передачей результатов, или, возможно, потребует тестирования, поддержки уже после передачи.
ІІІ. Коммуникации
Каким образом стороны между собой взаимодействуют и какие средства для этого используют, на первый взгляд, является не столь важным и существенным элементом договора. Однако от его включения в договор иногда зависят важные результаты, особенно при выборе модели agile.
Типичная ситуация, когда заказчик выплачивает разработчику предоплату, а позже из-за неудовлетворительного выполнения хочет эти средства вернуть. Он не может этого сделать, поскольку договором и дополнительным соглашением не было четко определено модель организации работы, установлены требования для разработчика, что затрудняет доказывание ненадлежащего исполнения.
В таких ситуациях в качестве доказательства часто можно использовать переписки по электронной почте, в мессенджерах между сторонами. Суды по-разному оценивают такие доказательства, поэтому необходимо в самом договоре предусматривать возможность взаимодействия между заказчиком и разработчиком в электронном формате.
Также сторонами могут использоваться различные программы для управления процессом разработки софта, как Jira, Trello, Slack, GitLab, о чем тоже нужно упоминать в договоре со ссылкой на идентификационные данные сторон (имя пользователя, электронная почта, номер телефона и т.д.).
Таким образом, даже если заказчик выбрал модель agile, он всегда сможет доказать причинно-следственную связь между договором и перепиской с разработчиком и соответственно неудовлетворительность работ. Разработчик наоборот сможет показать, что софт разработан в соответствии с указаниями заказчика.
IV. Оплата вознаграждения разработчика
Если при выборе waterfall очевидна возможность зафиксировать в договоре цену за весь проект (подход fixed bid), то при agile целесообразной является оплата за потраченные часы работы разработчика (подход time & materials).
Однако стороны могут установить и другой формат оплаты, например, за каждый отдельный этап или отдельную часть программы, которая разрабатывается, установить дополнительные бонусы за выполнение работ ранее определенного срока. Также стороны могут согласовать наличие предоплаты в форме аванса.
V. Интеллектуальная собственность
Софт может выступать объектом авторского права, а потому в договоре необходимо предусмотреть положение о переходе всех прав на софт от разработчика к заказчику, чтобы последний мог фактически его использовать. При этом целесообразно будет подписание по каждой отдельной или самостоятельной части кода соответствующего акта приема-передачи. Способы передачи кода также могут различаться: это может быть загрузка кода на GitHub или использование электронной почты.
Для дополнительной охраны прав заказчика можно получить регистрацию авторского права. Такая регистрация осуществляется на основании договора об отчуждении прав. Поэтому дополнительно к договору подряда или оказания услуг, по которому обычно работает ФЛП, нужно заключить договор о передаче авторских прав.
VI. Конфиденциальность
В большинстве случаев по требованию заказчика разработчик подписывает отдельное соглашение о неразглашении полученной конфиденциальной информации. Часто такие соглашения предусматривают виды информации или носителей, которые передаются и принадлежат заказчику, но относятся к конфиденциальной информации.
Разработчик при подписании соглашений должен детально анализировать каждое положение, каждый вид информации, чтобы такое соглашение потом не ограничило возможность его деятельности как специалиста. Заказчик же наоборот — должен как можно конкретно и неабстрактно определить перечень информации, которая является конфиденциальной, а также определить размеры штрафов за нарушения.
Вывод
Отношения между разработчиком и заказчиком можно строить по различным моделям, которые будут зависеть от цели заказчика и возможностей разработчика. Основой таких отношений будет выступать договор, который должен подробно отражать то, относительно чего стороны пришли к соглашению, описывать весь процесс организации работ, права и обязанности, момент передачи прав и ответственность.
Если вы заказчик софта, который все еще не определился со способом эффективного построения работы с разработчиком, или разработчик, который получил договор с непонятными для себя условиями, вы всегда можете обратиться к IPStyle и мы вам поможем. Мы проанализируем отношения «заказчик» — «разработчик», подберем оптимальное решение для вашей ситуации и позаботимся о том, чтобы ваша интеллектуальная собственность работала на максимизацию прибыли.
***
В следующей статье мы расскажем о правильном оформлении отношений «инвестор» — «разработчик»: когда инвестор вкладывает свои ресурсы в софт разработчика для возврата средств с процентом или для получения части бизнеса разработчика, основанный на таком софте. Stay tuned!