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

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

Казалось бы, есть компания, есть айтишник, компания ставит перед айтишником определенную задачу. Но, что бы Вы ни думали, третий тут лишним не будет 🙂 И этот третий – юрист.

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

Итак, поехали.

Ну, начнем с того, что тема нашей статьи – это ДОГОВОР НА РАЗРАБОТКУ ПРОГРАММЫ. Здесь мы не будем растекаться мыслью по древу, а четко разберем каждый смысловой блок, который должен быть в договоре с разработчиком, поэтому готовьтесь любоваться изысками юридической техники 🙂

Краткий эпилог, зачем вообще эта статья:

• Ни для кого не секрет, что работа программистов нынче ценится отнюдь не дешево, поэтому разработка программы/приложения всегда очень и очень затратна для заказчика. Не исключен риск обращения к недобросовестному айтишнику, который сделает работу спустя рукава (если это, конечно, не успешный фрилансер на Бали в майке без рукавов), а Вы останетесь буквально ни с чем: без денег, без программы, без доверия этому жестокому миру. Договор – надежный инструмент Вашей защиты. Казалось бы, всего лишь бумажка, подписанная двумя сторонами. Но эта бумажка впоследствии может помочь Вам остаться при своих ресурсах.
• Разработка ПО – сложный технический процесс. Заказчику придется разбираться не только в возможностях сложных юридических формулировок, но и в тонкостях и рисках деятельности программиста. Юрист поможет снять с Вас это бремя.
• Да и в целом, это спокойствие. Причем как со стороны Заказчика, так и со стороны Исполнителя. Зная, что обоим грозит справедливая ответственность за неисполнение обязательств, стороны, во-первых, замотивированы в надлежащем исполнении договора, во-вторых, не страдают от ощущения неопределенности.

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

Итак, как же правильно составить договор на разработку программы?

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

Что такое предмет? Это непосредственно то, что должен сделать исполнитель. Предмет – это не объект. Здесь не нужно указывать, что предметом является какая-то конкретная программа. Предмет – это совокупность действий по разработке этой программы.

Предмет следует формулировать кратко и емко.

К примеру, вот так:

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

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

2. Пока мы далеко не ушли от предмета, расскажем Вам про техническое задание.

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

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

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

4) У Заказчика должна быть возможность менять …, без привлечения Исполнителя.

Это совсем примерно. Ниже, в нашем договоре Вы найдете хороший пример оформления ТЗ.

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

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

3. Цена. Любимое условие, но не такое простое, как кажется.

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

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

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

• Поэтому зачастую цена в договоре с разработчиком формируется по принципу Time and Material. Кстати, мы снимали видео про такой договор, советуем ознакомиться, если любите слушать, а не читать:

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

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

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

• Есть еще одна модель — Cost Plus. Применяется не так часто, но имеет место быть.

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

4. Следующий блок – порядок сдачи и приемки работ.

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

Но на практике все осложняется в случае, если ТЗ вовсе не было, или же если в работе оказались недостатки (или наоборот, улучшения, за которые Исполнитель требует доплату). Поэтому превентивно все эти ситуации лучше предусмотреть в договоре.

Здесь Вам следует прописать следующие условия:

— порядок уведомления Исполнителем о выполнении, например, «Исполнитель после выполнения Работ уведомляет об этом Заказчика и направляет ему Отчет…»

— указать время, в течение которого Исполнитель принимает результат и указывает на наличие исправлений (3-5 дней будет достаточно);

— прописать, что недостатки устраняются путем внесения исправлений безвозмездно;

— по желанию осветить момент доработки: «Доработка не считается исправлением и оплачивается отдельно на основании нового заказа».

Наш пример оформления данного раздела:

5. Исключительное право

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

Но для начала стоит понять, что это вообще такое.

«Все, что по договору – это мое!» — думает практически любой заказчик. Однако в случае с интеллектуальной собственностью все не так просто.

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

Закон позволяет в договоре сразу прописать, кому это исключительное право будет принадлежать (ст. 1296 ГК РФ). По общему правилу, исключительное право по договору будет принадлежать заказчику. Оно и логично, ведь цель договора – получить конкретный результат и этим результатом пользоваться.

⇒ Но важно понимать, что автор (программист) все равно будет иметь право пользоваться своим детищем на условиях безвозмездной простой лицензии (п. 2 ст. 1296 ГК РФ).

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

⊕ Дополнительно советуем прописать условие о том, что пока Заказчик не оплатит работу и не подпишет акт приемки, он не имеет права пользоваться ПО. Это успокоит программиста, да и в целом это справедливо и по закону.

6. Конфиденциальность

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

Поэтому выделите этому разделу отдельное место в Вашем договоре и пропишите:

— какую информацию стороны признают конфиденциальной: содержание договора, материалы, результаты и др.

— какая информация таковой не считается: общедоступная, известная из других источников и др.

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

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

Здесь главное не переборщить и придерживаться принципов соразмерности и равентсва.

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

В договоре отдельно пропишите ответственность и Исполнителя, и Заказчика. Вот пример, что можно предусмотреть:

— Укажите, что в случае немотивированного отказа Заказчика принять работы, последний уплачивает пени в размере 1 % (например) за каждый календарный/рабочий день просрочки, но не более 20 % (например) от стоимости заказа.

— Закрепите срок выплаты пени – 5-7 дней. В случае невыплаты процентов Исполнитель вправе приостановить работы.

Соответственно, ответственность Исполнителя должна быть пропорциональной:

— Если Исполнитель задерживает со сдачей работ, то уплачивает 1 % за каждый день просрочки, но не более 20% от стоимости заказа.

— Если Исполнитель за 5 дней не выплатит пени, Заказчик может удержать суммы при следующих оплатах.

Вот, как ответственность в договоре прописываем мы:

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

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

В случае нарушения этого правила установите в договоре штраф в виде фиксированной суммы.

ИТОГИ

Итак, хотим донести до Вас главную мысль.

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

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

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

→ Предусмотрите сразу в договоре подсудность.

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

Итак, как мы и обещали, прикрепляем нашу форму договора. ⇓

Договор на ПО

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

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