Statement of Work: чем SOW отличается от ТЗ и как описать проект для подрядчика в США

Statement of Work (SOW) — приложение к договору, в котором стороны фиксируют сделку: что делается, какой результат сдаётся, к какому сроку, по каким критериям его принимают и сколько он стоит. ТЗ описывает систему. SOW описывает обязательства и деньги. В американской практике ТЗ входит в SOW приложением — так устроено ТЗ по американской практике.

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

Короткий ответ: SOW и ТЗ

Российское ТЗ отвечает на вопрос «что должна уметь система». SOW отвечает на другой: кто, что, когда и за какие деньги сдаёт. Путать их дорого.

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

Где SOW в договоре: MSA и SOW на каждый проект

Привычная цепочка в США — NDA, затем рамочный договор MSA (Master Services Agreement), затем SOW на конкретный объём. MSA подписывают один раз. В нём живут ответственность сторон и её предел, конфиденциальность, права на результат, гарантийный срок на исправление дефектов, применимое право и порядок разрешения споров. SOW подписывают на каждый проект или этап, и каждый такой документ ссылается на MSA по дате и номеру.

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

Права на код и конфиденциальность ставят в MSA. В SOW остаётся практическая сторона: что именно передаётся в день сдачи — репозиторий, доступы, документация, исходники макетов. Насколько подробно это пишут, видно по шаблону SOW Управления общих служб США (GSA): там есть пункт, что весь код, созданный по заказу, становится собственностью государства (шаблон GSA, раздел 6.8). В частном договоре формулировка своя, но принцип тот же: владелец результата назван прямо, без отсылок к «обычаям делового оборота».

Добавьте в MSA пункт о старшинстве документов (order of precedence). Если SOW и MSA противоречат друг другу, спор решает этот пункт. Без него решит суд.

Разделы SOW: что в нём должно быть

Правило из Federal Acquisition Regulation, 37.602 требует от госзаказчиков США описывать работу «в терминах требуемых результатов», а не через то, как её делать или сколько часов на неё уйдёт, и давать измеримые стандарты исполнения. Коммерческий SOW в США строят по той же логике, что и государственный.

Для веб-проекта минимальный набор разделов выглядит следующим образом:

• Scope — границы работ в двух-трёх абзацах: какие страницы, модули и интеграции входят в проект.
• Deliverables — список того, что сдаётся: макеты, код, развёрнутый сайт, документация для редактора и разработчика.
• Timeline — вехи с конкретными датами или с отсчётом в неделях от подписания SOW.
• Acceptance criteria — как именно проверяют каждый результат и сколько дней на это есть у заказчика.
• Payment schedule — какая доля суммы платится после какой вехи и в какой валюте выставляется инвойс.
• Change request — как вносятся изменения объёма, кто их оценивает и кто подписывает решение.
• Assumptions — допущения, от которых зависит оценка: сроки материалов, доступы, готовность сторонних сервисов.
• Out of scope — прямой перечень того, что в этот SOW точно не входит.

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

Допущение звучит так: «Заказчик предоставляет тексты всех страниц до начала вёрстки». Если тексты опоздали на три недели, срок сдвигается без переговоров. Сорванное допущение становится основанием для change request, и никто не тратит время на поиск виноватого.

Out of scope защищает обе стороны. Напишите прямо: перевод на испанский, наполнение блога, настройка рекламы не входят. Через два месяца никто не будет гадать, что «подразумевалось» на первом созвоне.

Change request описывают тремя строками: что меняется, как это влияет на срок, сколько это стоит. Решение принимает заказчик, и оно фиксируется письменно — в письме или подписанном дополнении к SOW. Устное «да, добавьте» на созвоне потом не докажет ни одна сторона.

График платежей привязывают к принятым вехам. Дата в календаре сама по себе платёж не открывает. Если американский заказчик — средняя или крупная компания, его бухгалтерия может платить с отсрочкой net-30 и требовать номер заказа (PO) в инвойсе. Эти условия тоже вписывают в SOW, иначе первый же платёж застрянет в чужом отделе.

Критерии приёмки: как написать проверяемо

Критерий хорош, если два разных человека проверят результат и получат один ответ. «Удобно» и «корректно» этот тест не проходят.

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

Договоритесь и о том, что считается дефектом, а что — новым пожеланием. Дефект — это расхождение с записанным критерием, а всё остальное идёт через change request как новая работа со своей ценой.

Fixed price, time & materials, retainer: как модель меняет SOW

Модель цены определяет, какие разделы SOW несут основную нагрузку. Госрегулирование США формулирует разницу жёстко: контракт с фиксированной ценой по FAR 16.202-1 не пересматривается по фактическим затратам исполнителя, и весь риск по стоимости лежит на нём. Time & materials по FAR 16.601 применяют, когда объём или длительность работ на момент подписания точно оценить нельзя.

Смешанная модель встречается чаще, чем кажется. Раздел с большой неопределённостью лучше вынести в T&M с потолком часов. Иначе один неясный кусок превращается в спор по всей смете, и страдают даже те этапы, где всё было понятно с первого дня.

У ретейнера своя ловушка. Объём там измеряется часами, и SOW легко превращается в строку «20 часов в месяц на задачи заказчика». Такой документ ничего не защищает. Впишите в него, какие задачи входят в пакет (правки контента, обновления, мелкие доработки), за какое время подрядчик реагирует на срочное обращение, как считаются часы сверх пакета и сгорают ли неиспользованные часы в конце месяца. Добавьте ежемесячный отчёт по задачам и часам: по нему заказчик видит, за что платит, а подрядчик получает подписанное подтверждение выполненной работы.

Для time & materials главный раздел — потолок. Без суммы not-to-exceed и правила «превышение только после письменного согласия» заказчик узнаёт об итоговой цене из последнего инвойса.

Где нужно ТЗ внутри SOW

Функциональные требования в тело SOW не вставляют. Их прикладывают как Exhibit A или Appendix A и ссылаются: «результат соответствует требованиям Приложения А, версия 1.2». Номер версии обязателен. Без него через месяц у сторон окажутся два разных приложения, и каждая будет права по-своему.

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

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

Сроки подготовки такого пакета на нашей странице услуги: небольшой проект — от 1 недели, система с интеграциями — от 3.

Шаблон SOW для веб-проекта

Ниже скелет. Юридических формулировок в нём нет: их дописывает юрист под ваш MSA. Проект вымышленный — пример, корпоративный сайт на 12 страниц.

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

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

Контекст всего выхода на рынок — домен, хостинг, законы о доступности и приватности, SEO — собран в руководство по сайту для бизнеса в США.