Договор Time & Material

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

Цена нашей услуги — 25 000 руб. Срок — 3 рабочих дня.

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

Наш подкаст Договор с разработчиком: зачем и какой?

А еще у нас вышел подкаст на тему «ДОГОВОР НА РАЗРАБОТКУ ПРИЛОЖЕНИЯ: сложные вопросы» → 

Подписывайтесь!

Договор разработки бота

Бот – это объект интеллектуальной собственности, программа для ЭВМ. У разработчика сразу возникают авторские и исключительные права на бот. Именно поэтому важно правильно составить договор на разработку чат-бота, чтобы заказчик смог его использовать по своему усмотрению, не нарушая при этом права автора.

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

Предмет договора

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

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

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

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

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

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

По закону, первоначально исключительное право на чат-бот возникает не у исполнителя, а у конкретного разработчика (физического лица), который занимался созданием бота (п. 3 ст. 1228 ГК). Однако в силу специфики трудовых отношений сделано исключение для служебных произведений. Исключительное право на служебное произведение принадлежит работодателю. Чат-бот признают служебным произведением, если разработка бота входит в трудовые обязанности сотрудника.

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

(пункты 2 и 3 – это альтернативные условия, в договор включается только одно)

2. Исключительное право в полном объеме переходит к заказчику

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

«Исполнитель обязуется передать исключительное право на чат-бот в полном объеме Заказчику»

Разработчик может по своему желанию зарегистрировать чат-бот как программу для ЭВМ в Роспатенте. Тогда смена правообладателя подлежит обязательной государственной регистрации. Правообладателем признается лицо, указанное в Реестре программ для ЭВМ (ст. 1262 Г РФ).

3. Заказчик использует бот в объеме предоставленной лицензии

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

При определении этих пределов нужно согласовать следующие моменты:

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

Лицензионный договор бывает двух видов:

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

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

Обязанности заказчика

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

1. Предоставлять необходимые документы по запросу исполнителя:

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

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

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

Обязанности исполнителя

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

1. Установите обязанность исполнителя закончить работу к определенному сроку.

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

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

4. Определите гарантийный срок, в течение которого исполнитель будет за свой счет восстанавливать работоспособность бота.

Цена договора

Цена договора складывается из двух составляющих.

1. Стоимость работ

Стоимость работ исполнителя определяется по соглашению сторон. Смета не требуется.

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

2. Вознаграждение за исключительное право

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

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

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

Конечно, отчуждение исключительного права намного дороже, чем лицензионное использование.

Приемка услуг

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

Договор должен отвечать на все приведенные ниже вопросы:

1. Какой документ стороны признают доказательством надлежащего выполнения работ?

• Акт приемки, подписанный обеими сторонами
• Акт приемки, подписанный исполнителем, если исполнитель в установленном порядке вызвал заказчика на приемку, но заказчик на приемку не явился

2. Когда работы считаются выполненными надлежащим образом?

• соответствие техническому заданию
• соответствие договору
• соответствие требованиям платформы
• успешное прохождение испытаний

3. По каким каналам связи сообщается о результате и направляются приемочные документы?

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

• электронная почта
• мессенджер
• корпоративные каналы
• бумажное уведомление, направленное по конкретному адресу

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

4. Какие сопроводительные документы должен направить исполнитель для приемки?

• акт приемки
• счет
• счет-фактура
• отчет о созданных результатах интеллектуальной деятельности
• инструкция

5. Как заказчику заявить о недостатках бота?

• направление мотивированного отказа с перечнем выявленных замечаний в n-дневный срок

Форс-мажор

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

• отключение электроснабжения
• отключение Интернета
• блокировка платформы в государстве
• неполадки у хостинг-провайдера
• хакерские атаки

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

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

1. Функции чат-бота:

2. Требования к боту

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

3. Нормативные акты, которым должен соответствовать чат-бот

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

4. Язык программирования

5. Этапы работы с указанием сроков

• Программирование сценария бота
• Запуск бота на платформе (мессенджер, сайт, приложение, голосовой ассистент)
• Техническая поддержка
• Обновление

Юрист для онлайн бизнеса в эпоху цифровизации и удаленки — обоснованная необходимость.

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

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

А еще у нас вышел подкаст на тему «ДОГОВОР НА РАЗРАБОТКУ ПРИЛОЖЕНИЯ: сложные вопросы» → 
Подписывайтесь!

Документы для бизнеса онлайн

Онлайн школа

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

Какие договоры нужны для онлайн школы на старте?

1. Оферта (договор)
2. Соглашение на обработку персональных данных
3. Договор с приглашенным на работу экспертом
4. Положение о конфиденциальности данных (может быть включено в оферту)

Что получу?

Грамотно разработанные документы позволят:

• минимизировать возвраты денежных средств потребителям;
• защитить онлайн бизнес от органов, которые осуществляют контроль за этой деятельностью (среди них: налоговая, Роспотребнадзор — защита потребителя, Роскомнадзор — защита информации и другие).

Хочу пример оферты! Забирайте.

Оферта-о-заключении-договора-оказания-услуг-по-проведению-мероприятий

Онлайн специалист

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

У нас и видео на эту тему имеется:

Хочу такой договор.

А мы и не жадничаем. У нас есть тот самый, рабочий и грамотный образец, который вы можете скачать себе.

Договор-на-ПО

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

1. не усложняйте: поверьте, программа и ее разработка — это уже сложно, а если еще и договор будет аналогичным, то придется худо;
2. договор должен быть понятным и простым для обеих сторон. Главное — отсутствие двусмысленности. Не стоит использовать оценочные слова, так как каждый из субъектов может расценить их различным образом;
3. договор должен быть основан на уважении (вежливое отношение не только на деле, но и на бумаге): помните о равных правах и обязанностях сторон. Ответственность не должна возлагаться только на одну сторону;
4. не забудьте включить в договор положение о подсудности;
5. реквизиты сторон хотя и находятся в самом конце договора, имеют высокое значение: они во всех заключаемых между сторонами документах должны быть одинаковыми;
6. не используйте шаблоны договоров, которые находятся в интернете: помните о том, что каждый случай индивидуален, а образец — это только ориентир, но не гарант качественной защиты сторон.

Блогер

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

1. Договор о сотрудничестве с блогером;
2. Договор с клиентом;
3. Договор между продюсером и блогером.

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

Случай 1: Отдал 64 000 за фотографию из Вконтакте

Предприниматель — основатель бренда одежды выплатил почти 64 000 рублей за использование во Вконтакте фотографии без разрешения ее автора.

Случай 2: Реклама вина в блоге была признана незаконной

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

Защита контента

Воровство контента (авторских прав) встречается повсеместно. А как быть блогеру/онлайн школе/любому онлайн бизнесу? Нельзя же им совсем ничего не публиковать (но при этом быть защищенным). Юрист для онлайн бизнеса — спасательный круг. Этот круг может и совет дать, как предупредить потенциального воришку о возможных последствиях, и досудебную претензию составить, и в суд пойти, если нужно.

Есть у нас и подкаст на эту тему (если больше любите слушать, а не читать).

Есть еще, помимо подкаста, кейс о том, что можно получить 450 000 рублей на украденном видео с Ютуб. Слушайте.

Во-первых, приятно, что суды не скупятся, назначая сотни тысяч (и даже миллионы) в пользу правообладателя. Во-вторых, печально, что количество запросов типа «Мое видео украли» неуклонно растет, а авторские права при этом никто не бежит защищать.

Отрадно, что в большинстве случаев борьба за авторские права может быть выиграна (тем, что ими обладает). В нашей истории юридическое лицо обратилось в Арбитражный суд с тем, что без его согласия ответчик опубликовал видео на своем сайте, во Вконтакте, на Ютубе (в общем почти везде, где только возможно). К иску истец приложил доказательства факта нарушения права — существенно важное замечание — так делать нужно всегда. Какие это доказательства? Это скриншоты и диск, котором зафиксированы соответствующие нарушения.

Истец писал досудебную претензию, но ответа на нее не получил.

Истец попросил компенсацию в размере 450 000 рублей.

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

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

Расскажем еще об одном случае из судебной практики.

Что случилось?

Общество с ограниченной ответственность обратилось в Арбитражный суд Республики Татарстан с иском к ответчику — Обществу с ограниченной ответственностью — о взыскании 30 000 рублей компенсации за нарушение исключительных авторских прав на фотографическое произведение.

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

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

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

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

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

Что решил суд?

Иск удовлетворить.

Взыскать с ответчика 30 000 рублей компенсации за нарушение исключительных авторских прав, 23 000 руб. расходов на оплату услуг представителя и 2 000 руб. госпошлины.

Защита чести и достоинства, удаление отзывов

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

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

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

Сначала пошли к нотариусу. Что? Да. С ним мы составили протокол осмотра доказательств. Иначе говоря мы подтвердили факт того, что клевета была распространена на Ютуб.

Дальше провели лингвистическую экспертизу (обратились к специалисту). Лингвист оценил высказывания, лексику и агрессивный настрой, негативно охарактеризовал ролик.

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

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

В пункте 7 постановления Пленума Верховного Суда Российской Федерации от 24.02.2005 № 3 «О судебной практике по делам озащите чести идостоинства граждан, а также деловой репутации граждан и юридических лиц» (далее — Постановление № 3) разъяснено, что обстоятельствами, имеющими в силу статьи 152 ГК РФ значение для дела являются: факт распространения ответчиком сведений об истце, порочащий характер этих сведений и несоответствие их действительности. При отсутствии хотя бы одного из указанных обстоятельств иск не может быть удовлетворен судом.

Вот одно из решений судов.

Что произошло?

Общество с ограниченной ответственностью обратилось в Арбитражный суд города Санкт-Петербурга и просило признать сведения, размещенные в отношении Общества на интернет-сайтах: … не соответствующими действительности, порочащими деловую репутацию Общества; и признать данную информацию той, распространение которой запрещено на территории России.

Чем обосновано?

Факт распространения спорной информации подтвержден представленным Обществом в материалы дела нотариально удостоверенным протоколом осмотра спорных интернет-страниц.

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

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

Что решил суд?

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

Юристы онлайн

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

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

Мы можем:

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

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

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

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

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

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

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

Предмет: исполнитель (IT-фирма) разрабатывает программу для ЭВМ в интересах заказчика и на его деньги.

Предмет, в отличие от названия, отражает суть договора, то есть основные обязанности сторон. В данном случае договор отличается тем, что в результате выполнения работ/ оказания услуг создаются программные комплексы, операционные системы, различные приложения, одним словом, программы для ЭВМ. Такие программы как объекты нематериального мира относятся к интеллектуальной собственности. Правовой режим программ аналогичен картинам, книгам, музыке. Поэтому следует каждый раз подтверждать творческий характер программы; он имеет место, когда произошли функциональные изменения в связи с существенной переработкой кода.

Стороны: заказчик и исполнитель

Применимые нормы права: с точки зрения ГК РФ, договор на разработку ПО является смешанным, то есть содержит в себе элементы договора подряда (гл. 37 ГК РФ) и договора оказания услуг (гл. 39 ГК РФ); в части интеллектуальных прав применяется ст. 1296 ГК РФ.

Требования к программе: чтобы конкретизировать параметры будущей программы стороны подписывают техническое задание. В нем прописываются этапы работ, например: 1) разработка серверного приложения – 2) разработка WEB-портала, — 3) разработка мобильного приложения.

Передача прав на программу: в договоре можно по-разному определить момент перехода исключительного права на программу от исполнителя к заказчику, например:

— при передаче заказчику материального носителя с исходным кодом программы, а также сопроводительной документации, что подтверждается актом приема-передачи;

— после выполнения всех этапов договора при условии полной оплаты цены договора.

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

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

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

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

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

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

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

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

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

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

Договор на разработку ПО важно отличать от договора авторского заказа программы для ЭВМ.

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

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

Естественно, закон особо защищает физических лиц, когда их контрагентами выступают коммерческие компании. Поэтому по договору авторского заказа все права на программу принадлежат разработчику (ст. 1288 ГК РФ).

Учитывайте этот нюанс, если заключаете договор с разработчиком – физлицом.

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

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

Чтобы права на разработанное приложение возникли у работодателя необходимы следующие условия:

а) программист официально трудоустроен у работодателя

б) создание программы – должностная обязанность программиста

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

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

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

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

Конечно, регистрация встанет в копеечку – 4 500 рублей 🙂

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

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

Споры по авторскому праву на программу имеют свои особенности в суде.

Главное отличие от обычных предпринимательских споров – это то, что кассационные жалобы по спорам по авторскому праву на программу подаются в Суд по интеллектуальным правам РФ (СИП). Он находится в Москве, Огородный проезд, д. 5, стр. 2. Например, если компания-нарушитель находится в Москве, то иск подаем в АСГМ, апелляционная жалоба – в 9 арбитражный апелляционный суд, кассационное обжалование – в СИП, а вторая кассация – в Верховном суде.

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

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

За нарушение исключительных прав наряду с пресечением подобного нарушения предусматривается еще один способ защиты, характерный только для исключительных интеллектуальных прав – компенсация. В отличие от обычных убытков здесь не нужно доказывать размер причиненного вреда. Компенсируемая сумма определяется одним из следующих способов: а) по усмотрению суда, но в границах 10 000 руб. – 5 млн руб.; б) 2х стоимости контрафакта; 3) 2х среднерыночной цены лицензии (двойная цена договора, если бы нарушитель правомерно использовал программу по договору с правообладателем).

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

Итак, следует сформулировать несколько рекомендаций для споров по авторскому праву на программу:

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

2) определите в договоре момент перехода исключительного права от исполнителя к заказчику и помните, что до этого момента использование программы – нарушение интеллектуальных прав исполнителя;

3) до подписания договора поинтересуйтесь, каким образом урегулирована передача служебных произведений в компании исполнителя: трудоустроены ли разработчики, охватывается ли процесс создания программы их должностной инструкцией, выплачивается ли им авторское вознаграждение;

4) если не хотите, чтоб исполнитель мог пользоваться программой без вашего ведома, пропишите в договоре условие о таком запрете;

5) при необходимости зарегистрируйте ПО в Роспатенте за своей организацией.

Если ваши авторские права при разработке программ нарушаются, наши юристы помогут выиграть спор и взыскать компенсацию!

Ответ на вопрос «Как вернуть деньги с разработчика?» будет разным, и зависит он от того, какой договор заключили между собой заказчик и разработчик программы.

Программа для ЭВМ (запахло чем-то старым…ЭВМ) — это представленная в объективной форме совокупность данных и команд, предназначенных для функционирования ЭВМ и других компьютерных устройств.

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

А еще у нас вышел подкаст на тему «ДОГОВОР НА РАЗРАБОТКУ ПРИЛОЖЕНИЯ: сложные вопросы» → 
Подписывайтесь!

Модель № 1 – договор подряда/ оказания услуг

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

По умолчанию исключительное право на ПО, созданное в результате договора подряда/ оказания услуг, принадлежит заказчику (ст. 1296 ГК РФ).

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

— потребовать устранение дефектов за счет исполнителя

— уменьшить цену договора

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

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

Еще у нас есть подкаст на эту тему «Договор с разработчиком: зачем и какой?» → 
Подпишитесь сейчас, чтобы не потерять.

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

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

А еще у нас вышел подкаст на тему «ДОГОВОР НА РАЗРАБОТКУ ПРИЛОЖЕНИЯ: сложные вопросы» → 
Подписывайтесь!

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

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

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

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

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

Модель № 2 – договор купли-продажи с предустановленным ПО

В рамках таких договоров продавец осуществляет поставку оборудования, на котором установлена программа. При этом использование оборудования обусловлено работоспособностью ПО.

На уровне Верховного суда такой вопрос рассматривался в рамках потребительского спора (п. 4 Обзора ВС РФ от 20.10.2021). Женщина купила смарт-часы, которые учитывали физическую нагрузку с помощью онлайн-сервиса. В последующем компания-производитель перешла на другое ПО, а старое ПО отключено. В результате фитнес-браслет перестал выполнять свою функцию и представлять какой-либо интерес для хозяйки. Позиция Верховного суда: понятие качества товара охватывает и качество программного обеспечения, используемого в технически сложном устройстве (ст. 469 ГК РФ). Эта позиция является универсальной и может применяться предпринимателями.

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

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

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

Модель № 3 – лицензионный договор

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

«Неисключительное право, не являясь вещью, не может быть некачественным», — Постановление 11 арбитражного апелляционного суда от 23.04.2022 по делу № А72-12397/2020.

Для лицензионного договора в принципе неважно, использует лицензиат программу или нет. Если ему дано право ей пользоваться, то он обязан платить по лицензионному договору, даже если вообще ее не использует.

Еще нужно отметить, что как правило лицензии содержат оговорку «as is» = «как есть». То есть программный продукт предоставляется таким, какой он есть, со всеми недостатками и без гарантий любого рода.

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

Указанное дает нам право предположить, что иски о возврате роялти по причине некачественного ПО – ненадлежащий способ защиты. Это предположение подтверждается практикой судов. Как указал 9 арбитражный апелляционный суд в постановлении по делу № А40-111104/2012, по лицензионному договору необходимо установить передачу права пользования программой. Для этого проверяется соответствие условий договора и приемочного акта в части наименования программы. Обстоятельства, связанные с недостатками программного обеспечения, не охватываются предметом лицензии, так как она предоставляет только право, но не предполагает оказание услуг по внедрению и технической поддержке.

Не следует использовать такой иск как признание лицензионного договора незаключенным. В судебной практике это требование широко распространено: приобретатели лицензии ссылаются на то, что нет подписанного обеими сторонами бумажного договора. Этот аргумент неубедителен по двум причинам: 1) законом предусмотрена такая форма заключения договора как обмен электронными документами, 2) нельзя ссылаться на незаключенность договора, если спор возник после его фактического исполнения.

Успешные кейсы по судам с разработчиком программы встречаются в тех случаях, когда лицензиат докажет, что разработчик программы не выполнил обязанность по обеспечению доступа к ПО, а также то, что лицензиату был закрыт прямой доступ к серверам этой программы; при этом, доступ может быть предоставлен как путем передачи электронного носителя, так и посредство интернета с использованием логина и пароля (Постановление СИП от 03.11.2017 по делу № А46-13129/2016). В этом случае можно подавать в суд на разработчика программы о расторжении договора о возврате денег.

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

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

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

Это три основные модели существующих отношений между теми, кто нуждается в ПО, и теми, кто способен его создать. Эти модели могут выстраиваться в комбинации. Например, легко представить договор поставки оборудования с предустановленным ПО с предоставлением лицензии на использование этого ПО. Или можно встретить лицензионные договоры, предусматривающие обязанность лицензиара оказать услуги по установке технической поддержке. Такие «гибриды» регулируются по частям: элементы, относящиеся к работам/ услугам регламентируются гл. 37 и гл. 39 ГК РФ, условия о поставке оборудования с ПО – нормами о купле-продаже, а части, касающиеся передачи исключительного интеллектуального права на ПО – нормами части 4 ГК РФ.

Резюмируя изложенное, можно составить матрицу способов защиты в спорах с разработчиками ПО:

Наша команда юристов убеждена, что развитие IT-сферы напрямую

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

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

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

Еще у нас есть подкаст на эту тему «Договор с разработчиком: зачем и какой?» → 
Подпишитесь сейчас, чтобы не потерять.

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

Виды договоров с разработчиками ПО:

1. Договор оказания услуг по разработке программного обеспечения.

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

А еще у нас вышел подкаст на тему «ДОГОВОР НА РАЗРАБОТКУ ПРИЛОЖЕНИЯ: сложные вопросы» → 
Подписывайтесь!

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

При заключении договора на услуги с физическим лицом или индивидуальным предпринимателем помните о рисках переквалификации такого договора в трудовой.

>>> Как выиграть спор о признании договора трудовым?

2. Договор Time&Material.

По своей сути, договор T&M – разновидность договора оказания услуг. Почвой для появления этого особого договора послужили проекты в сфере IT, для которых на начальном этапе невозможно определить точный перечень задач. В целом, выделяют четыре случая, когда договор Time&Material будет оптимальной моделью для работы над программным обеспечением: 1) проект направлен на испытание программы, 2) договор заключается с целью обновления ПО на постоянной основе, 3) мини-проекты, рассчитанные на команду из 2 – 5 человек, со сроком выполнения до полугода, 4) напротив, проекты-гиганты, рассчитанные на команду минимум из 25 человек, со сроком выполнения более года.

Такой договор позволяет максимально пространно сформулировать основную обязанность разработчика: «исполнитель обязуется разработать программное обеспечение для системы». Конкретные задачи формулируются в спецификации, которая подлежит периодической актуализации (сроки актуализации фиксируются в контракте). Возможность актуализации задач делает невозможным зафиксировать твердую цену, поэтому соглашение Time&Material – это договор с почасовой оплатой; заранее определяется только стоимость часа и максимальное количество часов для выполнения задачи из спецификации.

>>> Заказать разработку договора Time&Material

3. Договор подряда.

От услуг этот договор отличается наличием овеществленного результата. В сфере IT обнаружить овеществленный результат крайне трудно. Максимум —  информационный носитель. Но очевидно, что сама по себе флешка или диск не представляют ценности для заказчика. Однако и стороны, и суды используют «подрядные» формулировки. Это абсолютно правомерно, так как закон прямо допускает смешанные договоры (услуги + подряд). Если это делает отношения сторон более понятными, почему нет?

4. Лицензионный договор.

Данный договор регулирует вопросы передачи исключительного (интеллектуального) права на ПО. Сама программа разрабатывается по вышеперечисленным соглашениям. В некоторых случаях договор на услуги и лицензионный договор идут в связке. Например, в деле № А40-45539/2013 IT-компания разрешила использовать свое ПО заказчику по лицензионному договору, а также обязалась внедрить это ПО в систему заказчика. Суды квалифицировали эту связку как договор на разработку нового ПО путем переработки исходного. Важный вывод из этого дела: передача прав на продукт по лицензии не считается состоявшейся без передачи самого продукта. Поэтому заказчику удалось взыскать с разработчика аванс.

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

На практике встречаются различные названия договоров на разработку ПО, даже сам их текст иногда не содержит слово «услуги» (к примеру, «договор на внедрение информационной системы»). Но все они по своей сути, квалифицируются как договоры возмездного оказания услуг (гл. 39 ГК РФ) или подряда (гл. 37 ГК РФ). Например, Арбитражный суд г. Москвы рассматривал спор из договора, по которому «продавец обязуется передать в собственность Комплект Системы, а также право на пользование сервисом «Горячая Линия», а Покупатель обязуется принять этот Комплект Системы и оплатить в соответствии с условиями настоящего Договора». Суд подчеркнул, что собственность – это последнее, что могут придумать заказчик разработчик; договор на самом деле представляет собой договор на информационные услуги.

Если стороны не потрудились заключить письменный договор, то их будущие отношения по поводу создания программы будут регулироваться непосредственно Гражданским кодексом РФ. А если соглашение подписано, то положения Гражданского кодекса будут применяться к вашим отношениям только в той части, в которой они не урегулированы договором. В силу прямой нормы закона к услугам применяются правила о подряде (ст. 702 – 729, ст. 779- 782 ГК РФ). Если по какой-то причине заказчик и разработчик не заключают письменный договор, они должны иметь в виду, что закон допускает немотивированный отказ от договора услуг как со стороны заказчика, так и со стороны разработчика. Договором нельзя лишить этого права, но можно регламентировать порядок и сроки отказа, определить размер убытков за отказ от контракта. Закон также предполагает личное исполнение договора разработчиком; в то время как на практике используются договоры с правом привлечения субисполнителей. Кроме того, закон закрепляет обязанность заказчика предоставить всю необходимую документацию для создания ПО. В данном случае формулировка «вся необходимая информация» является крайне неопределенной, а разработчик может воспользоваться ей, чтоб максимальной продлить срок выполнения заказа. В договоре можно прямо перечислить, какие сведения понадобятся заказчику, тем самым исключить подобные риски.

Акт приемки

При избрании любого договора фактическое выполнение задания подтверждается отдельным документом – акт приемки. Заказчик подписывает этот важнейший документ только в том случае, если его полностью устраивает программа. Если в ПО есть недочеты, то акт возвращается разработчику неподписанным вместе с письмом, где изложен мотивированный отказ от подписания акта. Неправильный вариант действий со стороны заказчика: проигнорировать акт, то есть не направить мотивированный отказ от подписания. Обычно в договоры включается пункт по поводу последствий неподписания акта, например: «если по истечении N дней от заказчика не поступило мотивированного отказа от подписания акта, услуги считаются оказанными в полном объёме с надлежащим качеством». Даже если такой пункт не включен в договор, суды придерживаются того же мнения: бывает достаточно доказать, что акт направлен заказчику по правильному адресу.

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

Однако даже при наличии подписанного акта заказчик может доказывать суду, что услуги оказаны в меньшем объеме, чем зафиксировано в акте (п. 12 Информационного письма ВАС № 51 от 24.01.2000).

Претензия к разработчику

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

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

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

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

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

Договор оказания услуг дает право любой стороне на безусловный и немотивированный отказ от его исполнения. Единственное условие – другой стороне возмещаются все ее затраты на исполнение договора. Закон запрещает включать в такие договоры условия о недопустимости одностороннего отказа или устанавливать штраф за отказ. Но допускается устанавливать в договоре денежную компенсацию за отказ (п. 3 ст. 310 ГК РФ).

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

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

Иски разработчиков и заказчиков: вариации судебных споров

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

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

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

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

1. Активная позиция заказчика

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

На случай пассивного поведения стороны в АПК РФ есть п. 3.1 ст.70: если одна сторона ссылается на определенные факты, а вторая сторона ничего не высказывает против этих фактов, то они считаются признанными.

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

Иначе получится, как в деле № А07-4176/2019. Разработчик вышел с иском об оплате  лендинга для сайта. В качестве доказательства выполненных работ он представил неподписанный заказчиком акт, который однако последним получен. Заказчик не явился ни в одно судебное заседание и даже не потрудился написать коротенький отзыв. В результате суд полностью удовлетворил иск программистов, расценив процессуальное бездействие заказчика как признание обстоятельств дела.

2. Настаивайте на экспертизе некачественного ПО

Экспертиза – почти единственный способ отыскать правду, так как судьи и представители – это правоведы, а не специалисты в сфере IT.

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

>>> Как составить качественное ходатайство об экспертизе в арбитраж?

Ходатайство нужно заявлять своевременно и в соответствии со всеми процессуальными требованиями. Иначе в его удовлетворении могут отказать, сочтя позднее заявление ходатайства, да еще и без согласия эксперта и  внесения денег на депозит, затягиванием судебного процесса (дело № А47-17870/2019).

Для начала нужно определить, какие вопросы задать эксперту. Вопросы должны касаться сути спора, то есть качества ПО. В то же время, нельзя ставить перед экспертом вопросы права, к примеру «оказал ли разработчик услуги надлежащим образом?».

Примеры вопросов можно увидеть в деле № А57-4773/2020, которое разрешилось в пользу заказчика благодаря экспертному заключению:

— Установить, пригоден ли для использования по назначению в соответствии с условиями договора и техническим заданием функционал программного продукта?

— Соответствует ли результат выполненных работ условиям договора, а также требованиям норм и правил, описанным в техническом задании?

— Каковы объем и стоимость качественно выполненных разработчиком  работ в соответствии с условиями договора?

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

В деле № А40-91171/2015 исход тоже определила экспертиза. Разработчик вплоть до кассации пытался оправдать свои разработки по двум этапам и просил заплатить хотя бы за них. Но эксперт заключил, что объем выполненных работ лишь 23,4%, но программное обеспечение не способно корректно выполнять операции. Поэтому внесенный заказчиком аванс был полностью ему возвращен.

3. Доказывайте, что отдельные этапы выполнения разработки не имеют потребительской ценности для заказчика

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

В деле № А40-121450/2016 суды неправильно истолковали договор на разработку сайта и пришли к неверному выводу о необходимости оплаты каждого этапа. Московская кассация отправила дело на пересмотр, обязав суды провести экспертизу по делу, чтобы установить, имеет ли часть работ потребительскую ценность для заказчика. Другими словами, можно ли использовать результат выполненных исполнителем работ вне результата работ, на достижение которого был направлен договор в целом. К слову, это дело завершилось победой разработчика тоже благодаря экспертизе, которая установила, что эскизы страниц, дизайн-макеты и верстка сайта могут быть использованы заказчиком, хотя только с привлечение другого IT-специалиста.

4. Используйте нестандартные доказательства.

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

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

Можно заявить об обеспечении доказательств судом (ст. 72 АПК РФ). Это требуется в тех случаях, когда контрагент после подачи иска в суд может внести изменения в программу или удалить ее. Суд своим определением запрещает разработчику совершать такие действия. Если запрет будет нарушен, то это будет расцениваться против разработчика.

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

Договор Time & Material получает все больше и больше признания со стороны предпринимателей, особенно в IT-индустрии. Составление договора T & M лучше поручить юристам, которые специализируются на таких договорах.

С английского договор Time & Material буквально переводится как «договор времени и материалов». Название отражает саму суть такого договора: оплата зависит от того, сколько затрачено времени и ресурсов (материальных, человеческих и других). Вы можете встретить и другие названия этого контракта – «оплата по факту», «почасовая ставка».

Заказать договор Вы можете на нашем сайте по ссылке.

Еще у нас есть подкаст на эту тему «Договор с разработчиком: зачем и какой?» → 
Подпишитесь сейчас, чтобы не потерять.

Иностранные слова в названии не означают, что договор Time & Material не известен российскому праву. Хотя в Гражданском кодексе такое название, действительно, не встречается. На самом деле, такой договор – это разновидность договора возмездного оказания услуг, глава 39 ГК РФ. Поэтому все императивные правила нашего старого доброго договора на услуги относятся и к договору T & M. Обновим их в памяти и будем двигаться дальше (а если вы постоянно читаете наш блог и хорошо усвоили, как регулируются услуги, то переходите сразу за горизонтальную черту):

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

б) по общему правилу, поручать работу кому-то другому (субисполнителю) нельзя.

в) все выплаты в пользу исполнителя облагаются налогами (НДФЛ/ НДС и др.)

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

_______________________________________________________________________

А теперь – сущность и особенности договора Time & Material.

Если вы вспомните, как в настоящее время структурируются «стандартные» договоры, например, поставка или подряд, вы поймете, что модель иная по сравнению с договором Time & Material. Заключая договор подряда, стороны рассчитывают получить конечный материальный результат – новое здание, отремонтированную дорогу и подобное. Все характеристики объекта фиксируются в техническом задании. Заказчик желает получить результат, полностью соответствующий техническому заданию. Поскольку объект определен и его проектные характеристики не будут изменяться с течением времени, то и цена определяется по принципу «твердой сметы». То есть в таких договорах цена определяется на старте проекта, так как она находится в прямой зависимости от определенного конечного результата, а фактические временные и материальные затраты исполнителя на нее не влияют (влияют только прогнозируемые затраты, оговоренные на старте). Твердая смета может быть изменена только по соглашению сторон. Но в таких случаях очень трудно прийти к консенсусу, так как интересы сторон прямо противоположны. Заказчик не хочет ничего доплачивать, мол, цены итак были выше рынка. Исполнитель же не готов сделать лишнюю работу. Но так как эта работа все-таки необходима, весь проект останавливается на неопределенный срок. Описанная выше модель называется fixed price. Как видите, у нее есть плюс – заказчик четко понимает, что он получит и сколько за это заплатит. Но и минус у этой модели тоже существует – учесть изменения условий, влияющих на проект, очень сложно.

В целом, модель fixed price подходит для «стандартных» договоров, предметом которых является овеществленный результат. Но в XXI веке большую долю рынка занимают «цифровые» сферы: разработка программного обеспечения, мобильных приложений.  Договор на разработку ПО нежелательно структурировать по принципу fixed price. Как указано выше, у fixed price есть две основные особенности: 1) заказчик и исполнитель четко и одинаково представляют себе конечный результат, 2) цена договора находится в прямой зависимости от характеристик этого конечного результата.

Но договор с разработчиком требует куда большей гибкости. Ведь часто заказчик понимает функцию, которую должно выполнять ПО, или проблему, которую оно помогает решить. Но каким в итоге должно быть приложение понять на старте очень трудно. Более того, компьютерные технологии нуждаются в постоянном обновлении. Поэтому зачастую договоры с создателями софта подписываются не только для создания программы, но и для ее обновления. Это влечет длительное сотрудничество сторон, обычно более года. А регулировать такие долгосрочные отношения обычными инструментами очень трудно. Таким образом, на ряду с договорами fixed price возникает договор Time & Material. Он применяется в тех сферах, где договор с фиксированной ценой неэффективен.

Конкретики в вопросе, когда нужно выбрать Time & Material нет. Но в общем подходящими считаются следующие проекты:

— испытание программы

— постоянное обновление уже готового приложения

— «маленькие» проекты: требуется команда до пяти человек, срок проекта – до 6 месяцев

— «масштабные проект»: требуется команда от 25 человек, срок проекта превышает год

Далее подробно расскажем об особенностях договора Time & Material.

1. Итак, первая особенность – объект договора настолько сложен, что сформулировать его характеристики на начальном этапе работы невозможно. Описание продукта выглядит максимально общим образом. Движение к конкретике осуществляется маленькими шажками. «Шажки» — это задачи. На начальном этапе их мало. По мере поступления результатов исследований, круг задач расширяется. К середине проекта большое количество мелких задач уже решено. А к моменту выхода программы в свет мы видим весь спектр задач, которые нужно было решить. В этом смысле работа по договору с разработчиком похожа на то, как растет дерево. Сначала только отросток, потом на нем все больше и больше появляются ветки, и вот перед нами большое дерево с массивной кроной. Вот пример формулировки основной обязанности по договору на разработку ПО. Мы видим, что эта обязанность сформулирована максимально пространно:

2. Размытость договора с разработчиком имеет свои границы. Все-таки примерный план работ у сторон имеется. Он отражается в исходной спецификации. Но ключевой момент здесь – «исходная». В зависимости от внешних условий, действий конкурентов или запросов потребителей в эту спецификацию без проблем могут быть внесены изменения. Это вторая важная особенность договора T & M.

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

Допустимость изменений снимает с исполнителя необходимость закладывать в цену риски, связанные с непредвиденными затратами. Такие риски характерны для fixed price. Причина – цена определяется на старте и не корректируется, даже если в этом появилась нужда (только через процедуру подписания доп.соглашений). Поскольку в договоре Time and Material новые задачи появляются без каких-либо сложностей, то и цена по нему не нагромождается за счет подобных рисков.

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

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

3. В договоре T & M работа поделена на этапы. Но в отличие от обычного подряда здесь этапы гораздо менее продолжительные, так как направлены на решение более узких задач. Поэтому в договоре T and M этапы называются спринтами. Эта третья особенность нашего соглашения.

Результат каждого спринта может быть выражен в наработке, выполняющей отдельно взятую функцию в будущей программе. По итогам каждого спринта подписывается акт приемки услуг. Подписание такого акта означает, что разработчик передал объект интеллектуальной собственности заказчику, а последний должен заплатить за него. После этого заказчик получает реальный доступ к функции ПО, например через Облако. Есть второй вариант: заказчик не получает доступ к наработкам после спринтов, а ПО передается после завершения проекта и подписания итогового акта приема-передачи. Но для заказчика это не выгодный вариант, так как сроки в договоре T and M «плавающие», и неизвестно когда проект будет успешно завершен.

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

4. Означает ли все это, что заказчик никогда не знает, сколько он должен платить по договору с разработчиком? Переходим к четвертой особенности договора Time & Material – отсутствие фиксированной оплаты. На практике подписываются договоры на разработку ПО с почасовой оплатой. Стоимость часа оговаривается с самого начала. Чтобы устранить неопределенность в вопросе оплаты, разработчик перед каждым спринтом обязан информировать заказчика о том, сколько часов ему понадобится для выполнения каждой конкретной задачи. Определить временные затраты разработчику помогут time-tracking-приложения. За этот лимит, по общему правилу, выходить нельзя. Иначе сложилась бы невыгодная для заказчика ситуация: исполнитель специально затягивает время, чтоб получить побольше денег. Но можно предусмотреть более гибкий вариант. Например, отразить в договоре максимальное количество часов, на которые может отклониться исполнитель. Вся эта процедура называется прогнозированием часов.

Еще одна деталь – это изменение стоимости часа. Обыкновенная ситуация – сотруднику IT-компании, который задействован в проекте, поднимают зарплату. Так уж сложилось в бизнес-среде, что, как правило, повышение зарплаты ударит по карману заказчика. Но это лишь общее правило: в договоре можно переложить этот риск на самого разработчика. Кроме того, заказчик еще перед началом следующего спринта узнает о повышении цены часа. Такое изменение декларируется в прогнозных часах. Если заказчик не готов к росту цены, то вопрос можно решить многочисленными способами. Например, распределить повышение зарплаты между сторонами (50 % — заказчик, 50 % — подрядчик) или заменить сотрудника.

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

5. Поскольку оплата по договору Time & Material зависит от затраченного времени, нужно четко фиксировать часы – это пятая особенность нашего договора. Форма фиксация произвольная и обычно является приложением к договору. Но есть позиции, которые обязательно должны быть отражены в вашей таблице. Во-первых, это перечень работ, другими словами комплекс задач, необходимый для реализации проекта. Второе – список специалистов, которые будут трудиться над проектом. И третье – отразить, сколько времени потратил каждый сотрудник. Ставка оплаты у каждого сотрудника может быть своя. Умножив количество часов на почасовую ставку, получим стоимость услуг разработчика за конкретный период.

Очевидно, что при такой модели заказчик платит только за «эффективные» часы. Мы привыкли, что по трудовому договору оплачиваются все часы с 09:00 до 18:00. Даже те, когда работник никакую полезную для работодателя функцию не выполнял. Здесь же стороны подсчитывают, сколько часов потратил бы квалифицированный сотрудник на выполнение спринта. Время на «попить чаек» сюда не входит.

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

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

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

Договоры на разработку ПО с почасовой оплатой в большинстве своем заключают те заказчики, которые заинтересованы в качестве продукта. С одной стороны, новшества нужны для повышения качества продукта и конкуренции с другими производителями. С другой стороны, эти новшества нужно будет дополнительно оплатить. И каждый раз нужно будет положить на чаши весов одно и другое, и все-таки выбрать какой-то вариант. Отсюда шестая особенность — договор T & M стимулирует заказчиков детально обдумывать планируемые задачи и изменения. Поскольку и заказчик, и исполнитель вовлечены в процесс создания программы, можно заранее утверждать, что результат превзойдет все ожидания. Эта особенность выгодно отличает Time & Material от fixed price.

_______________________________________________________________________

Некой альтернативой сразу двум подходам Time & Material и fixed price выступает fixed budget. Такой проект является двухэтапным. Первый этап нацелен на разработку ядра проекта. Он структурируется по принципу fixed price. Ядро проекта описывается достаточно четко, возможность внесения изменений почти отсутствует. Фиксируются сроки разработки этого «ядра». И самое главное – оплата будет фиксированной. Таким образом, заказчик быстро получает квази-конечный продукт, который на начальном этапе будет смотреться достаточно неплохо. Но чтобы поддерживать конкурентоспособность в долгосрочной перспективе, надо переходить к этапу номер 2. На втором этапе fixed price уступает место T & M. Разработчик формирует команду, чтобы осуществлять техническую поддержку программы, постоянно обновлять и корректировать ее работу. В итоге качество приложения растет. Пользователи оценивают, что их рекомендации учитываются. При этом, заказчик платит только за «эффективные» часы. Таким образом, fixed budget учитывает плюсы ранее рассмотренных подходов и может служить хорошим способом структурирования договоров в сфере IT.

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

— по договору Time & Material вы платите не за итоговый результат, как в fixed price, а за согласованные затраты времени и материальных ресурсов. Поэтому риски недостижения конечного результата лежат на заказчике.

 — по статистике, цена по договору T & M в несколько раз меньше, чем по модели fixed price.

— выбор модели зависит от конкретного проекта: используйте T & M там, где fixed price неэффективен.

— модель T & M придаст проекту гибкость и актуальность.

— немалую часть в сотрудничестве по модели T & M занимает доверие сторон друг к другу. Но не в том смысле, что такой договор заключается только между контрагентами, которые доверяют друг другу. Скорее, результатом сотрудничества по принципу Time & Material становится взаимное уважение и доверие сторон. Заказчик, получивший хорошее приложение, придет еще и еще.

— заключать договоры T & M выгодно с начинающими разработчиками либо с IT-компаниями, не потерявшими умение ценить и, в хорошем смысле, «охотиться» на клиента. Стартапы стремятся зарекомендовать себя на рынке и создать безупречную репутацию. Такие компании не будут «накручивать» часы или завышать их стоимость.

— не только договор на разработку ПО можно структурировать по типу договора T & M. Удобно заключать такие сделки с целью правового (юридического) сопровождения проектов и в других сферах бизнеса.

— альтернативой T & M и fixed price считается fixed budget. По этой модели можно структурировать проекты от самого начала и до функционирования приложения на рынке, включая тех.поддержку и постоянные обновления.

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