Договор на разработку софта
Договор на разработку софта
Писать контракты сложно, скучно и не доставляет удовольствия. Но, когда клиент за пять минут до завершения работы заявляет, что расторгает договор и не заплатит ни копейки за уже проделанную работу, вы будете рады, если предусмотрели в договоре выход из такой ситуации.
Эта статья рассматривает взаимоотношения между заказчиком и разработчиком при создании программы эксклюзивно по заказу. И подскажет, на что обратить особое внимание при составлении такого контракта.
Этапы в работе
Для заказчика нет ничего хуже, чем заказать разработчику создать программу, потом ничего не слышать от него несколько месяцев и в результате получить полностью неудовлетворяющую программу.
Избежать такой ситуации можно, если разбить работу на несколько этапов. В конце каждого этапа разработчик обязан предоставить заказчику определенную часть работы. А заказчик должен ее утвердить.
Этапы могут стандартными при разработке программного обеспечения - альфа-, бета-версия и готовая программа (финальная версия). Таким образом, клиент контролирует процесс создания программы, вовремя высказывает свои замечания и может даже досрочно расторгнуть договор, если разработчик делает совсем не то и не так.
Эти же этапы можно использовать при оплате. В конце каждого этапа заказчик оплачивает определенную в договоре часть общей суммы.
Конец каждого этапа работы - удобный момент для обсуждения проблем, возникающих в работе, произведения изменений к спецификации, их оценки, внесения соответствующих изменений в сроки исполнения и оплаты работы. И когда все вопросы решены, можно приступать к следующему этапу.
Для разработчика работа по этапам удобна также и потому, что в конце каждого этапа клиент подтверждает (лучше письменно), что он принимает работу. Поэтому в конце работы он не сможет заявить, что готовая программа его полностью не устраивает.
Кто собственник?
Программное обеспечение является авторской программой и защищается законами об авторских правах. С момента, когда программный код записан в память компьютера или на бумагу, возникают авторские права на него. В тот же момент кто-то становится владельцем этих прав. Кто это будет - разработчик или заказчик? Все зависит от того, что записано в договоре. Факт, что клиент является заказчиком программы и платит за нее деньги, не означает, что ему принадлежат и авторские права.
Первоначально авторские права принадлежат программисту, который придумывает и записывает код программы. Исключение, если программист по договору передал права на программу заказчику, или, он является работником по трудовому договору и выполняет задание работодателя. В последнем случае авторские права на все, что создает программист в рамках трудовых отношений, принадлежат работодателю. При этом работодателем может быть как разработчик, так и заказчик.
Итак, у заказчика есть только два пути, как стать владельцем авторских прав на программу. Первый - принять программиста на работу, заключив с ним трудовой договор. Второй - в договоре на разработку программы предусмотреть передачу авторских прав.
Здесь нужно отметить, что авторские права не являются чем-то единым и неделимым. Авторские права состоят из множества различных прав - права преобразовывать код программы, изготовлять, распространять и сдавать в аренду копии программы и других прав. И каждое такое право может передаваться отдельно. Более того, авторские права могут переданы эксклюзивно и неэксклюзивно.
Обычно, если программа создается под заказ, заказчик не желает, чтобы в дальнейшем его программа использовалась для других целей. Для этого ему необходимо владеть всеми авторскими правами.
Объем, в котором передаются авторские права, является предметом для переговоров и согласований между разработчиком и заказчиком. Здесь возможно много вариантов. Начиная от варианта, когда все авторские права на все элементы программы в полном объеме эксклюзивно передаются заказчику, и заканчивая вариантом, когда все авторские права остаются за разработчиком, а заказчику передается неэксклюзивная лицензия на использование одной копии программы. Между этими двумя крайними вариантами существует еще множество промежуточных. Чем больше прав хочет получить заказчик, тем дороже ему обойдется программа.
Еще существенный момент - в своей работе программист часто использует одни и те же повторяющиеся в разных программах элементы. Обычно, это стандартный код для выполнения одних и тех же функций. Эти наработки экономят программисту много времени, так как их не надо каждый раз создавать заново. Но если по договору заказчик получает эксклюзивные авторские права на программу, он будет владеть и правами на эти наработки. А это значит, что программист в дальнейшем не сможет их использовать.
Разработчику можно рекомендовать предусмотреть в договоре, авторские права на подобные элементы остаются за ним, а заказчик получает неэксклюзивную лицензию на их использование.
Оплата работы разработчика
Есть два варианта оплаты труда разработчика - фиксированная плата за готовую программу и почасовая оплата. Заказчику обычно удобнее первый вариант - так он точно знает, во что выльется проект. Разработчик же, наоборот, может установить фиксированную плату только в случае, если заранее во всех деталях знает масштабы проекта и может предположить, сколько труда потребует его воплощение. А для этого разработчику необходима детальная спецификация. В противном случае труд разработчика должен оплачиваться, исходя из количества часов, фактически потраченных на создание программы.
В договоре необходимо предусмотреть порядок, как заказчик может внести изменения к спецификации. В процессе создания программы у заказчика часто появляются новые идеи, как можно улучшить программу. Редко какой проект заканчивается в точном соответствии с первоначальной спецификацией. Если в результате изменений спецификации у разработчика увеличивается объем работы, необходимо определить, как будут оцениваться эти изменения.
Оплату разумно разбить на несколько частей. Их можно привязать к этапам создания программы - альфа- , бета-, финальная версии программы. После того, как заказчик утвердил очередной этап, он платит установленную часть оплаты.
Тестирование
Каждую программу необходимо должным образом протестировать перед тем, как использовать. Программа должна выполнять все, что предусмотрено в спецификации. Особенно важно надлежащее тестирование программ, связанных с безопасностью или защитой информации. Например, программа, обеспечивающая электронные банковские расчеты через Интернет, или программа, обеспечивающая функционирование аттракциона «американские горки», требуют очень серьезного тестирования.
Большая часть работ по тестированию программы ложится на разработчика. Перед тем, как «сдать» работу заказчику, он должен проверить все ли работает так, как надо. Но и заказчик не может принять работу, не проверив ее как следует. Заказчик может проводить тестирование самостоятельно
Писать контракты сложно, скучно и не доставляет удовольствия. Но, когда клиент за пять минут до завершения работы заявляет, что расторгает договор и не заплатит ни копейки за уже проделанную работу, вы будете рады, если предусмотрели в договоре выход из такой ситуации.
Эта статья рассматривает взаимоотношения между заказчиком и разработчиком при создании программы эксклюзивно по заказу. И подскажет, на что обратить особое внимание при составлении такого контракта.
Этапы в работе
Для заказчика нет ничего хуже, чем заказать разработчику создать программу, потом ничего не слышать от него несколько месяцев и в результате получить полностью неудовлетворяющую программу.
Избежать такой ситуации можно, если разбить работу на несколько этапов. В конце каждого этапа разработчик обязан предоставить заказчику определенную часть работы. А заказчик должен ее утвердить.
Этапы могут стандартными при разработке программного обеспечения - альфа-, бета-версия и готовая программа (финальная версия). Таким образом, клиент контролирует процесс создания программы, вовремя высказывает свои замечания и может даже досрочно расторгнуть договор, если разработчик делает совсем не то и не так.
Эти же этапы можно использовать при оплате. В конце каждого этапа заказчик оплачивает определенную в договоре часть общей суммы.
Конец каждого этапа работы - удобный момент для обсуждения проблем, возникающих в работе, произведения изменений к спецификации, их оценки, внесения соответствующих изменений в сроки исполнения и оплаты работы. И когда все вопросы решены, можно приступать к следующему этапу.
Для разработчика работа по этапам удобна также и потому, что в конце каждого этапа клиент подтверждает (лучше письменно), что он принимает работу. Поэтому в конце работы он не сможет заявить, что готовая программа его полностью не устраивает.
Кто собственник?
Программное обеспечение является авторской программой и защищается законами об авторских правах. С момента, когда программный код записан в память компьютера или на бумагу, возникают авторские права на него. В тот же момент кто-то становится владельцем этих прав. Кто это будет - разработчик или заказчик? Все зависит от того, что записано в договоре. Факт, что клиент является заказчиком программы и платит за нее деньги, не означает, что ему принадлежат и авторские права.
Первоначально авторские права принадлежат программисту, который придумывает и записывает код программы. Исключение, если программист по договору передал права на программу заказчику, или, он является работником по трудовому договору и выполняет задание работодателя. В последнем случае авторские права на все, что создает программист в рамках трудовых отношений, принадлежат работодателю. При этом работодателем может быть как разработчик, так и заказчик.
Итак, у заказчика есть только два пути, как стать владельцем авторских прав на программу. Первый - принять программиста на работу, заключив с ним трудовой договор. Второй - в договоре на разработку программы предусмотреть передачу авторских прав.
Здесь нужно отметить, что авторские права не являются чем-то единым и неделимым. Авторские права состоят из множества различных прав - права преобразовывать код программы, изготовлять, распространять и сдавать в аренду копии программы и других прав. И каждое такое право может передаваться отдельно. Более того, авторские права могут переданы эксклюзивно и неэксклюзивно.
Обычно, если программа создается под заказ, заказчик не желает, чтобы в дальнейшем его программа использовалась для других целей. Для этого ему необходимо владеть всеми авторскими правами.
Объем, в котором передаются авторские права, является предметом для переговоров и согласований между разработчиком и заказчиком. Здесь возможно много вариантов. Начиная от варианта, когда все авторские права на все элементы программы в полном объеме эксклюзивно передаются заказчику, и заканчивая вариантом, когда все авторские права остаются за разработчиком, а заказчику передается неэксклюзивная лицензия на использование одной копии программы. Между этими двумя крайними вариантами существует еще множество промежуточных. Чем больше прав хочет получить заказчик, тем дороже ему обойдется программа.
Еще существенный момент - в своей работе программист часто использует одни и те же повторяющиеся в разных программах элементы. Обычно, это стандартный код для выполнения одних и тех же функций. Эти наработки экономят программисту много времени, так как их не надо каждый раз создавать заново. Но если по договору заказчик получает эксклюзивные авторские права на программу, он будет владеть и правами на эти наработки. А это значит, что программист в дальнейшем не сможет их использовать.
Разработчику можно рекомендовать предусмотреть в договоре, авторские права на подобные элементы остаются за ним, а заказчик получает неэксклюзивную лицензию на их использование.
Оплата работы разработчика
Есть два варианта оплаты труда разработчика - фиксированная плата за готовую программу и почасовая оплата. Заказчику обычно удобнее первый вариант - так он точно знает, во что выльется проект. Разработчик же, наоборот, может установить фиксированную плату только в случае, если заранее во всех деталях знает масштабы проекта и может предположить, сколько труда потребует его воплощение. А для этого разработчику необходима детальная спецификация. В противном случае труд разработчика должен оплачиваться, исходя из количества часов, фактически потраченных на создание программы.
В договоре необходимо предусмотреть порядок, как заказчик может внести изменения к спецификации. В процессе создания программы у заказчика часто появляются новые идеи, как можно улучшить программу. Редко какой проект заканчивается в точном соответствии с первоначальной спецификацией. Если в результате изменений спецификации у разработчика увеличивается объем работы, необходимо определить, как будут оцениваться эти изменения.
Оплату разумно разбить на несколько частей. Их можно привязать к этапам создания программы - альфа- , бета-, финальная версии программы. После того, как заказчик утвердил очередной этап, он платит установленную часть оплаты.
Тестирование
Каждую программу необходимо должным образом протестировать перед тем, как использовать. Программа должна выполнять все, что предусмотрено в спецификации. Особенно важно надлежащее тестирование программ, связанных с безопасностью или защитой информации. Например, программа, обеспечивающая электронные банковские расчеты через Интернет, или программа, обеспечивающая функционирование аттракциона «американские горки», требуют очень серьезного тестирования.
Большая часть работ по тестированию программы ложится на разработчика. Перед тем, как «сдать» работу заказчику, он должен проверить все ли работает так, как надо. Но и заказчик не может принять работу, не проверив ее как следует. Заказчик может проводить тестирование самостоятельно
(0)
© 2024, JohnCMS