Марк Тьюрин – Договор без ловушек: Как проверить оплату, сроки, ответственность и расторжение (страница 2)

Это не запрещает Илье или другим сотрудникам участвовать в проекте. Но поток комментариев превращается в управляемую процедуру. Если любой сотрудник может добавить новую задачу фразой «а давайте ещё попробуем», исполнитель получает бесконечно расширяющееся обязательство.

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

Короткая реплика для бухгалтерии или менеджера:

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

Счёт от третьей компании, перевод на карту сотрудника или просьба перечислить деньги «временно на другой счёт» — не бытовая мелочь. Такие действия меняют доказательства того, кто получил деньги и в счёт какого обязательства.

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

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

В проекте Анны словосочетание «разработка фирменного стиля» звучало убедительно, пока Марина не попросила превратить его в перечень результата. Оказалось, что даже базовые элементы стороны понимали по-разному.

Анна считала, что в состав входят:

логотип и его варианты;

цветовая палитра и шрифтовая пара;

руководство по использованию фирменного стиля;

шаблоны меню;

оформление упаковки для трёх категорий продукции;

макет наружной вывески;

файлы для печати и цифрового использования.

Илья говорил о другом:

«Нам нужен брендбук, чтобы открывать новые точки. Если потом понадобится меню, оно должно быть внутри. Иначе какой смысл в фирменном стиле?»

Так возникает главный вопрос предмета: что именно исполнитель должен сделать, передать или предоставить заказчику и в каком объёме?

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

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

Фраза «сделать качественно» не устанавливает критерий качества. Фраза «сделать в соответствии с брендбуком» бесполезна, если брендбук ещё не передан или сам будет разработан исполнителем. Фраза «под ключ» опасна, если стороны не перечислили, что именно находится под этим ключом.

Марина переписала предмет договора:

«Исполнитель разрабатывает фирменный стиль сети кафе, включающий две концепции логотипа, одну доработанную концепцию, цветовую палитру, рекомендации по использованию шрифтов, руководство по применению фирменного стиля объёмом до 30 страниц, макеты меню для форматов А4 и А3, макет наружной вывески для одной типовой точки, макеты упаковки для трёх видов продукции, а также передаёт итоговые файлы в форматах, указанных в Приложении 1».

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

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

какой результат должен быть создан;

сколько единиц или вариантов входит в объём;

в каком виде результат передаётся;

кто предоставляет исходные материалы;

когда обязательство считается выполненным;

что не входит в цену?

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

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

Реплика до начала работ:

«Чтобы одинаково понимать задачу, зафиксируем результат в перечне: что входит, в каком количестве передаётся, кто предоставляет материалы и какие действия считаются дополнительными».

Реплика, если заказчик уже добавляет новую задачу:

«Это можно сделать, но в текущем объёме такой работы нет. Предлагаю отдельно согласовать её содержание, цену и влияние на срок. После подтверждения включим работу в план проекта».

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

Приложения — не запасная папка, а часть сделки

В договоре Анны стояла фраза: «Объём работ определяется техническим заданием». Само техническое задание прислали отдельным файлом без номера, даты и подписи. В теме письма было написано: «ТЗ финал 3, точно последнее».

Через неделю Илья переслал другой файл: «ТЗ финал 4». В нём появились оформление стаканов и дополнительные шаблоны публикаций. Когда Марина спросила, какая редакция действует, Илья ответил: «Последняя, конечно».

Такая ситуация встречается не только в дизайне. У поставщика спецификация меняется после отправки счёта. При ремонте смета хранится в одном чате, план работ — в другом, а чертёж отправлен фотографией с пометками. В разработке программного решения техническое задание существует в нескольких версиях, и никто не установил, какая из них относится к подписанному договору.

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

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

Пример рабочей формулировки:

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

Для коммерческих и технических документов можно установить иной порядок:

«По вопросам состава и характеристик результата приоритет имеет спецификация; по вопросам оплаты, ответственности и расторжения — договор».

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

Анна попросила включить в договор перечень приложений:

Приложение 1 — техническое задание с составом работ и результатом.

Приложение 2 — календарный план и порядок передачи материалов.

Приложение 3 — стоимость этапов и порядок дополнительных работ.

Приложение 4 — требования к файлам и способу передачи результата.

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

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

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

Плохая реплика: «Давайте подпишем сейчас, а детали уточним по ходу».

Рабочая реплика: «Сейчас мы можем зафиксировать общие правила сотрудничества, но запуск конкретного этапа начнём только после подписания задания с объёмом, ценой и сроком».