Ваш первый проект с клиентом прошёл гладко по двухстраничной смете. Теперь второй проект крупнее, клиент присылает своё техническое задание со ссылкой на свои стандартные условия для поставщиков, и где-то в середине работы результат приходит с опозданием, а счёт остаётся неоплаченным. Вы указываете на свою смету. Они указывают на свои условия для поставщиков. Чьи документы на самом деле имеют силу? Если вы не можете ответить на этот вопрос одним предложением, ваши договоры уже отстали от отношений — и решение не в более длинной смете, а в структуре из двух документов: рамочный договор плюс техническое задание для каждого проекта.
Это руководство объясняет, что входит в каждый документ, почему их разделение избавляет вас от пересогласования одних и тех же условий в каждом проекте, и какие ошибки сводят на нет всю структуру. Одна стандартная оговорка перед началом: это общая информация о том, как устроены договоры на оказание услуг, а не юридическая консультация по вашей конкретной ситуации.
Два документа на одной картинке
Рамочный договор (MSA) содержит все условия, которые остаются неизменными для всех проектов с одним и тем же клиентом: как вы получаете оплату, кому принадлежит работа, кто за что отвечает, как любая из сторон может выйти из договора. Техническое задание (SOW) описывает ровно один проект: что вы создадите или поставите, к какому сроку, за какую сумму и как клиент это принимает.
| Рамочный договор | Техническое задание | |
|---|---|---|
| Отвечает на вопрос | Как мы работаем вместе? | Что вы делаете на этот раз? |
| Срок жизни | Месяцы или годы, охватывает много проектов | Один проект, затем в архив |
| Пересогласовывается | Редко, если вообще | Заново для каждого проекта |
| Типичное содержание | Механика оплаты, конфиденциальность, основы интеллектуальной собственности, гарантии, возмещение убытков, лимиты ответственности, срок и расторжение | Объём работ, результаты, этапы, стоимость, критерии приёмки, порядок изменений |
| Подписывают | Обе стороны, один раз | Обе стороны, для каждого проекта |
Представьте, что MSA — это операционная система, а каждое SOW — приложение, работающее поверх неё. Когда приходят третий, четвёртый и пятый проекты, вы согласовываете только SOW — уже согласованный лимит ответственности, передача прав на интеллектуальную собственность и условия оплаты остаются на месте.
Что входит в рамочный договор
Всё в MSA должно быть верно для каждого проекта, который вы когда-либо выполните для этого клиента. Если условие будет меняться от проекта к проекту, ему место в SOW, а не здесь.
Предмет отношений. Как ни парадоксально, MSA обычно вообще не содержит объёма работ по проекту — только рамочное положение о том, что клиент может привлекать вас для услуг, описанных в будущих технических заданиях. Сопротивляйтесь желанию вставить сюда детали проекта. Как только specifics проекта просачиваются в рамочный договор, вам приходится вносить в него изменения при каждом изменении работ — именно та рутина, для устранения которой и существует эта структура.
Механика оплаты. Не цена какого-либо проекта, а механизм получения денег: в течение скольких дней счета подлежат оплате, что считается просрочкой, размер пени или процентной ставки, кто оплачивает расходы и как они документируются, требуется ли предоплата до начала работ. Закрепите пеню здесь один раз — распространённая формулировка: 1,5 процента в месяц на просроченные суммы — и каждое будущее SOW унаследует её без новых споров.
Конфиденциальность. Взаимное обязательство в отношении непубличной информации каждой из сторон, срок его действия после прекращения договора и стандартные исключения для информации, которая уже была публичной или разработана независимо. Фрилансеры часто пропускают это в отдельных сметах; в MSA это ничего не стоит включить и защищает обе стороны во всех проектах.
Основы интеллектуальной собственности. MSA устанавливает правило владения — как правило, вы передаёте готовые результаты клиенту, желательно после полной оплаты, — плюс исключение для вашей ранее существовавшей интеллектуальной собственности: фреймворков, шаблонов, библиотек кода и методик, которые существовали до проекта и остаются вашими, лицензируемые клиенту только в составе результатов. Затем SOW определяет, на какие результаты распространяется это правило в каждом проекте. Держите правило в рамочном договоре, а перечень — в SOW.
Гарантии и возмещение убытков. Краткая гарантия того, что вы выполните услуги профессионально и что результаты не нарушат чью-либо чужую интеллектуальную собственность, в паре с положением о возмещении убытков, обязывающим каждую сторону защищать другую от определённых претензий третьих лиц. Эти положения выглядят как формальность, пока заимствованный код субподрядчика или нелицензированное стоковое фото не вызовет претензию — и тогда они решают, кто оплачивает защиту.
Ограничение ответственности. Положение, ограничивающее вашу максимальную экспозицию, почти всегда установленное как вознаграждение, выплаченное по соответствующему SOW за предшествующие 12 месяцев, плюс взаимный отказ от косвенных и последующих убытков. Согласуйте это один раз в MSA — и оно покроет каждый проект. Примите здесь неограниченную ответственность — и вы приняли её и для всех будущих работ, поэтому это то условие, за которое стоит бороться сильнее всего на рамочном уровне.
Срок, расторжение и завершение. Как долго действует MSA, как любая из сторон может его расторгнуть (обычно с письменным уведомлением за 30 дней), прекращает ли расторжение уже начатые SOW или позволяет им завершиться, и что происходит в конце: возврат конфиденциальных материалов, оплата работ, выполненных до даты расторжения, и любая помощь при передаче дел. Самое ценное предложение для фрилансеров — это компенсация при отмене: если клиент отменяет проект на полпути, выполненные к моменту отмены работы плюс определённая плата за завершение всё равно оплачиваются.
Порядок приоритета. Положение, отвечающее на сценарий из начала статьи: при конфликте документов какой из них побеждает? Типичная иерархия ставит SOW выше MSA по условиям конкретного проекта, а оба — выше любого заказа на закупку или мелкого шрифта в счёте. Без этого положения портал закупок клиента может незаметно переписать ваши согласованные условия с каждым заказом.
Что входит в техническое задание
Если MSA — это конституция, то SOW — это законодательство: конкретное, датированное и одноразовое. Каждое SOW должно быть самодостаточным полным описанием одного проекта, при этом ссылаясь на MSA во всём остальном. Пять элементов несут почти всю нагрузку.
Объём работ плюс список того, что не входит. Опишите результаты, этапы, сроки и обязанности каждой из сторон — включая то, что клиент должен вам предоставить, например доступ к данным, обратную связь в течение пяти рабочих дней и одного ответственного за принятие решений. Затем напишите зеркальное отражение: явный перечень того, что не включено. Дополнительные раунды правок, поддержка внедрения, срочные доработки, работа в инструментах, о которых вы не договаривались, — назовите их и укажите, что всё выходящее за рамки объёма требует письменного заказа на изменение с дополнительной оплатой. Этот абзац превращает большую часть расползания объёма работ из спора в счёт.
Стоимость для этого проекта. Фиксированная цена, почасовая ставка и потолок или сумма абонентского вознаграждения — только цифры этого SOW, поверх механики оплаты из MSA. Привяжите каждый платёж к этапу с календарной датой или проверяемым событием и укажите, является ли предоплата невозвратной и зачитывается ли она в общую сумму. График этапов выполняет двойную функцию: задаёт ритм вашему денежному потоку и даёт клиенту причину поддерживать обратную связь, поскольку его задержка наглядно сдвигает его же сроки.
Критерии приёмки. Как клиент принимает каждый результат и — что критично — что происходит, если он молчит. Положение о подразумеваемой приёмке, обычно десять рабочих дней без письменных возражений, не даёт клиенту бесконечно откладывать подписание и держать ваш финальный этап в заложниках. Размытые SOW без критериев приёмки — самый распространённый источник расползания объёма работ: когда «готово» не определено, всё ещё входит в объём.
Порядок изменений. Процедура в один абзац: изменения объёма, сроков или стоимости должны быть запрошены в письменной форме, оценены вами и подписаны обеими сторонами до начала изменённых работ. Нет подписанного заказа на изменение — нет изменённых работ. Фрилансеры, последовательно применяющие это правило, сообщают, что оно прекращает большинство разговоров о расползании объёма ещё до их начала, потому что клиент видит цену отклонения до того, как на него согласится.
Зависимости и ключевой персонал. Если ваш график зависит от вклада клиента, укажите, что срок сдвигается день за днём при задержках клиента. Если клиент покупает ваше агентство ради конкретных людей, назовите их и укажите, что произойдёт, если кто-то уйдёт из проекта. Любое из этих предложений не даёт трёхнедельному молчанию другой стороны превратиться в ваш пропущенный срок.
Этапы, условия оплаты и приёмка: где деньги встречаются с документами
График этапов в SOW — это не просто план проекта, а ваш прогноз выручки в договорной форме, и ваш бухгалтерский учёт должен его отражать. Когда у каждого этапа есть определённая сумма и триггер приёмки, выставление счетов становится механическим: этап принят, счёт отправлен, отсчёт срока оплаты начат на условиях MSA. Когда этапы размыты, выставление счетов превращается в переговоры каждый раз.
Учитывайте каждое SOW как отдельный поток доходов в своих книгах. Предоплата, полученная до начала работ, ещё не выручка — это обязательство (незаработанный доход), пока вы не сдадите этап, в зачёт которого она была зачтена. Платежи по этапам чётко соответствуют датированным счетам, что превращает отчёт о старении дебиторской задолженности в систему раннего предупреждения: если SOW одного клиента постоянно уходят в просрочку, а остальные платят вовремя, проблема в клиенте, а не в вашем процессе выставления счетов. А во время налоговой отчётности записи по каждому SOW позволяют легко показать, какой доход относится к какому году, вместо восстановления этого из годовой выписки по банковским депозитам. Документация Beancount показывает, как текстовые реестры делают такой учёт на уровне проектов проверяемым без аврала в конце месяца.
Права на интеллектуальную собственность в двух документах
Разделение условий об интеллектуальной собственности между MSA и SOW путает людей, поэтому вот распределение обязанностей. MSA устанавливает правило владения и исключения: результаты передаются клиенту после полной оплаты, ваш ранее существовавший инструментарий остаётся вашим на условиях лицензии, и вы сохраняете права на портфолио, если это согласовано. SOW определяет результаты, к которым применяется правило, — дизайны, код, отчёты или контент, созданные в рамках этого проекта.
Здесь фрилансеров подстерегают две ловушки. Первая — полагаться только на формулировку «work made for hire» (работа, созданная по найму). По закону США об авторском праве эта доктрина охватывает сотрудников и лишь узкие категории специально заказанных работ; большинство результатов фрилансеров под неё не подпадают, и суды неоднократно постановляли, что называние чего-либо работой по найму в договоре не делает её таковой. Собственность на самом деле передаёт письменное положение о передаче прав в вашем MSA — сохраните его, а формулировку о работе по найму рассматривайте как подстраховку, а не как механизм.
Вторая ловушка — пробел с субподрядчиками. Если кто-то ещё прикасается к работе, ваш договор с субподрядчиком должен передавать их результаты вверх по цепочке вам. Иначе вы пообещаете клиенту право собственности на результаты, которыми юридически не владеете, и гарантия об интеллектуальной собственности в MSA превратится в нарушение, ожидающее даты обнаружения.
Ограничение ответственности: ограничьте один раз — покройте все проекты
Условия об ответственности вознаграждают структуру MSA больше, чем любое другое положение, потому что их труднее всего согласовать и опаснее всего ошибиться. Добивайтесь трёх вещей на рамочном уровне.
Во-первых, лимит, привязанный к тому, что клиент фактически заплатил, — обычно это вознаграждение, выплаченное по затронутому SOW за 12 месяцев до претензии. Избегайте лимитов, привязанных ко всем вознаграждениям по MSA, если вы выполняете большой объём работ для одного клиента, поскольку эта сумма с каждым годом растёт, превращаясь во всё более крупную мишень. Во-вторых, взаимное исключение косвенных, случайных и последующих убытков: без него опоздание с результатом теоретически может сделать вас ответственным за упущенную выручку клиента от запуска. В-третьих, узкие исключения, на которые лимит не распространяется, — обычно нарушение конфиденциальности, нарушение прав на интеллектуальную собственность и умышленное нарушение. Держите этот список коротким. Каждое исключение — дыра в защите, и правка клиента, добавляющая «или любое нарушение настоящего договора» в исключения, тихо удалила ваш лимит полностью.
Фрилансеры-одиночки иногда думают, что эти положения — корпоративный театр. Это не так. Лимит ответственности, установленный на уровне выплаченного вознаграждения, означает, что ваш худший случай по проекту на 15 000 долларов — примерно 15 000 долларов: неприятно, но выживаемо. Без лимита ваш худший случай — это то, что судья сочтёт убытками клиента. Подпишите лимит один раз — и каждое SOW, подписанное под этим MSA, его унаследует.
Типичные ошибки, сводящие на нет всю структуру
Система из двух документов работает только тогда, когда документы действительно связаны. Вот самые частые провалы.
Подписание SOW, который не ссылается на MSA. SOW, свободно парящее без рамочного договора, — это просто ещё одна отдельная смета, ни одна из согласованных вами защит к нему не прикрепляется. Каждое SOW должно начинаться с включения MSA по дате и названию. Для этого достаточно одного предложения.
Позволение мелкому шрифту заказов на закупку победить. Многие клиенты проводят каждый проект через закупки, и заказы приходят с условиями на обороте, противоречащими вашему MSA по срокам оплаты, ответственности и интеллектуальной собственности. Положение вашего MSA о порядке приоритета должно ставить заказ на закупку последним, и вы никогда не должны подписывать заказ, лицевая сторона которого противоречит SOW, не отметив это. Заказ на закупку — это платёжный инструмент, а не пересогласование.
Изменения на рукопожатии. Каждая услуга вне объёма, выполненная по устному «разберёмся», приучает клиента обходить ваше положение о порядке изменений — и оставляет вас без подписанной записи, когда приходит счёт. Оцените изменение, получите подпись, затем выполняйте работу. Нет подписи — нет работы.
Автоматическое продление без пересмотра ставок. MSA, автоматически продлевающиеся год за годом, удобны, пока вы не осознаёте, что ваши ставки в SOW заморожены с 2023 года, а ваши расходы выросли на 20 процентов. Свяжите автоматическое продление с ежегодным окном пересмотра ставок, чтобы ваше ценообразование могло следовать за рынком.
Копирование MSA крупной компании фрилансером-одиночкой. Корпоративные MSA предполагают страховые полисы, сертификаты безопасности и юридические отделы, которых у вас нет. Подписание такого документа дословно может обязать вас к ежегодным аудитам SOC 2, SLA с доступностью 99,9 процента или страховому покрытию на семизначные суммы. Читайте каждое обязательство как обещание, которое лично вы должны сдержать, и вычёркивайте или сужайте те, что созданы для поставщиков в сто раз крупнее вас.
Нужен ли вам MSA уже сейчас?
Не каждый проект требует полной структуры. Разовый проект с определённым результатом и чётким завершением вполне обходится одним хорошо написанным отдельным договором — создание MSA для клиента, которого вы, возможно, больше никогда не увидите, это лишние процессы без отдачи.
Сигналы того, что вы переросли единый документ: повторный бизнес от одного клиента, абонентская работа или постоянная поддержка, где «готово» — это не дата, субподрядчики, присоединяющиеся к вашим проектам, и закупочные документы, приходящие с условиями на обороте. Агентства достигают этих сигналов быстро, часто с первым многопроектным клиентом. Фрилансеры-одиночки обычно достигают их ко второму или третьему проекту с хорошим клиентом — и именно тогда предложить MSA проще всего, потому что обе стороны уже хотят продолжения отношений. Подайте это как эффективность, а не как эскалацию: «Давайте соберём постоянные условия в одном месте, чтобы для будущих проектов требовалось только короткое SOW».
Держите финансы проектов такими же организованными, как и договоры
MSA плюс SOW для каждого проекта дают каждому проекту определённый объём, график этапов и документальный след — а это именно то сырьё, на котором работает хороший бухгалтерский учёт. Когда каждое SOW соответствует своему потоку доходов, предоплаты сидят в незаработанном доходе до их заработка, а счета по этапам наглядно стареют в вашей дебиторской задолженности, ваши книги показывают прибыльность по каждому клиенту, а не единую размытую картину. Beancount.io предлагает текстовый бухгалтерский учёт, дающий вам полную прозрачность и контроль над вашими финансовыми данными — никаких чёрных ящиков, никакой привязки к поставщику. Начните бесплатно и узнайте, почему разработчики и финансовые специалисты переходят на текстовый бухгалтерский учёт.
