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

В инженерных проектах спор редко начинается со слов «мы неправильно поняли договор». Обычно всё выглядит приличнее: заказчик считает, что вместе с оплатой получил все права на разработку, инженер уверен, что передал только комплект КД, производство ждёт ещё три доработки, а бухгалтерия не платит, потому что «результат пока не принят».

И где-то между STEP-файлом, актом и перепиской в Telegram внезапно появляется юрист.

Эта статья полезна тем, кто заказывает или выполняет инженерные услуги: разработку оборудования, реверс-инжиниринг, восстановление КД, модернизацию машин, расчёты, 3D-моделирование, подготовку производства. Я разберу не юридическую теорию, а места, где договор непосредственно сталкивается с чертежом, станком и деньгами.

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

Фраза «разработка изделия» почти ничего не означает.

Что входит в результат?

3D-модель? Комплект рабочих чертежей? Спецификация? Расчёты? Прототип? Исходные CAD-файлы? Технологическая документация? Авторское сопровождение производства?

Разница может составлять сотни часов работы.

Я видел достаточно проектов, где заказчик говорил: «Ну чертежи ведь уже есть, осталось немного доработать». А под словом «немного» обнаруживались изменение конструкции, перерасчёт нагрузок, выпуск новой спецификации и сопровождение первой партии.

Поэтому предмет договора должен отвечать не на вопрос «что делает инженер», а на вопрос:

что конкретно заказчик получит в конце и в каком виде.

Если передаётся КД, нужно определить состав документов. Если 3D-модели, указать формат. Если расчёт, зафиксировать расчётный случай, исходные нагрузки и критерии.

Инженерная шутка здесь простая: неопределённое ТЗ тоже имеет допуск. Обычно примерно ±100% по объёму работ.

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

Кто отвечает за ошибку?

Если договор молчит, начинается спор.

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

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

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

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

Одна из самых дорогих фраз в разработке:

«А можно ещё вот это добавить?»

Можно.

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

В договоре нужен механизм изменения объёма работ.

Например: дополнительные требования выполняются после письменного согласования стоимости и срока.

Без такой нормы инженер легко попадает в бесконечную разработку. Формально договор один, фактически возникает версия 2.0, 3.0 и 4.0.

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

Это одна из самых недооценённых частей инженерных договоров.

Заказчик может получить комплект чертежей. Но означает ли это, что он получает исключительное право на все технические решения внутри этих чертежей?

Не обязательно.

Есть как минимум три разных объекта:

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

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

Если один из таких элементов использован в новом проекте, это не означает автоматически, что заказчик приобрёл всю библиотеку.

Поэтому я считаю разумным прямо отделять:

background IP, то есть знания и разработки, существовавшие до проекта,

и project IP, созданное специально по договору.

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

Для небольшого проекта это выглядит почти бюрократией.

До первого коммерческого тиража.

Фраза «мы же вам заплатили» сама по себе не решает вопрос интеллектуальной собственности.

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

Передача исключительных прав должна быть оформлена отдельно и достаточно ясно.

Особенно внимательно нужно относиться к формулировкам вроде:

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

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

Цена одной невнимательно прочитанной страницы иногда выше стоимости всего договора.

«Передал файлы» и «выполнил договор» не всегда одно и то же.

Лучше установить процедуру приёмки.

Например, заказчик получает комплект документации и в течение 10 рабочих дней либо подписывает акт, либо передаёт мотивированный перечень замечаний.

Не «нам что-то не нравится», а конкретные несоответствия техническому заданию.

Если срок прошёл и замечаний нет, результат считается принятым.

Такая механика защищает обе стороны.

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

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

Если после выпуска чертежа заказчик решил заменить двигатель 7,5 кВт на 11 кВт и потребовалось изменить раму, это уже новая работа.

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

Иначе почти любое новое пожелание легко назвать «исправлением».

Для инженера это постепенно превращается в бесплатное конструкторское бюро.

Проектировщик разработал деталь.

Производитель нарушил термообработку.

Поставщик заменил сталь 40Х на неизвестный аналог.

Монтажник затянул соединение не тем моментом.

Через месяц узел вышел из строя.

Кто отвечает?

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

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

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

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

Это не попытка уйти от ответственности.

Это нормальная инженерная причинно-следственная связь.

В крупном промышленном проекте стоимость разработки может составлять $10 000, а потенциальный простой оборудования — $100 000 в сутки.

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

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

Конкретная формулировка зависит от законодательства и характера проекта, но экономику риска нужно понимать до подписи.

Инженер не страховая компания завода.

NDA нужен не только заказчику.

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

Разработчик защищает собственные модели, методы, расчёты и технические решения.

Нужно определить, что считается конфиденциальной информацией, кому её можно передавать и на какой срок действует ограничение.

Отдельный вопрос — субподрядчики.

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

Иначе формально даже отправка модели подрядчику на ЧПУ может нарушать NDA.

Для независимого инженера это вполне коммерческий вопрос.

Можно ли после завершения работ написать:

«Разработана новая конструкция редуктора»?

Можно ли показать фотографию?

Можно ли назвать заказчика?

Можно ли опубликовать чертёж?

Лучше определить это договором.

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

Это нормальная переговорная позиция.

Ненормально выяснять это после публикации кейса.

Представим вполне реальную ситуацию.

Проект выполнен на 70%. Стороны прекращают сотрудничество.

Что получает заказчик?

Что происходит с уже выплаченным авансом?

Можно ли использовать промежуточные модели?

Кому принадлежат разработанные к этому моменту решения?

Обязан ли исполнитель передать исходники?

Без ответа на эти вопросы расторжение превращается в маленькую промышленную драму.

Поэтому договор должен описывать не только счастливый финал.

В инженерии версия документа иногда важнее подписи.

Housing_final.step

Housing_final2.step

Housing_final_REAL.step

Через полгода никто уже не смеётся.

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

Для серьёзных проектов я бы отдельно фиксировал перечень передаваемых файлов.

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

Самые опасные вещи часто находятся не на первой странице.

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

Например, в договоре говорится о разработке документации.

А в приложении внезапно появляется обязанность обеспечить достижение определённой производительности оборудования.

Это уже совершенно другой уровень ответственности.

Я всегда читаю ТЗ вместе с договором, а не после него.

Перед инженерным проектом у меня есть четыре вопроса:

Хороший инженерный договор не должен превращать проект в юридический трактат на 80 страниц.

Но он обязан описывать границы.

Инженеры привыкли ставить размеры, допуски и посадки, потому что фраза «сделать примерно 50 мм» плохо работает в производстве.

С договором ровно та же механика.

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