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