Договоры с разработчиками/подрядчиками/маркетинг-агентствами (SOW, SLA)

Суть услуги / когда нужна / что даёт

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

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

Страница «Договоры с разработчиками/подрядчиками/маркетинг-агентствами (SOW, SLA)» нужна именно для таких ситуаций. Это не «договор ради юриста» и не декоративный текст на случай суда. Это инструмент, который превращает внешний аутсорс из набора ожиданий и устных договорённостей в систему, где можно ответить на конкретные вопросы: что делаем, что не делаем, как подтверждаем прогресс, чем закрывается этап, что считается нарушением, как запускаются изменения, какие артефакты должны быть переданы, как ограничиваются доступы и что остаётся у бизнеса на выходе.

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

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

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

Страница связана с кластером IT / Данные / AI-политики для бизнеса и логически соседствует с политикой использования AI, защитой контента и бренда в digital и политикой данных. Это важно, потому что современный договор с цифровым подрядчиком почти никогда не живёт изолированно: доступы, данные, AI-сценарии, права на материалы и контур публикации вовне всё чаще переплетены. Поэтому сильный договор здесь — не просто бумага на подпись, а один из ключевых узлов цифровой управляемости бизнеса.

Когда это обычно нужно и где чаще всего ломается процесс

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

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

• Нет критериев приёмки. Заказчик оценивает результат по впечатлению, подрядчик — по факту собственной активности. Один считает, что работа «ещё сырая», другой — что всё уже сдано и осталось только «собрать замечания». Когда нет чек-листа результата, тест-сценариев, понятного списка артефактов и правил повторной сдачи, любая приёмка превращается в субъективный диалог без точки опоры.

• Изменения требований идут в чате. Это одна из самых дорогих ошибок. Пока правки и новые задачи согласуются в переписке без формального change-control, проект почти гарантированно теряет предсказуемость. Подрядчик копит аргументы «это было дополнительным», заказчик копит раздражение «почему так долго», а бюджет и сроки расползаются без единой карты изменений.

• Оплата отвязана от подтверждённого результата. Бизнес платит по календарю, по инерции или потому что «так принято», но не потому, что есть пакет подтверждений по этапу. В такой модели можно получить красивый статус-репорт, активную переписку и десятки закрытых задач в таск-трекере, но при этом не получить полноценно принимаемый результат.

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

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

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

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

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

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

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

Алгоритм действий

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

1. Сначала разложить проект на реальные поставки. Нужно понять, что именно вы покупаете: разработку функционала, поддержку, рекламное сопровождение, SEO-работы, дизайн-систему, контент, интеграции, аналитику, медийное производство, AI-ассистированный контур или смешанную услугу. Фиксация: список результатов и этапов. Артефакт: первичная карта поставок. Типовая ошибка: пытаться описать сложный проект одной общей фразой.

2. Затем отделить ядро объёма от зоны изменений. Не всё должно входить «по умолчанию». Важно сразу определить, что включено, что исключено, что является зависимостью со стороны заказчика, а что может запускаться только через отдельную процедуру. Фиксация: границы и допущения. Артефакт: черновик SOW. Типовая ошибка: оставлять зону «договоримся по ходу» без рамки.

3. Потом задать критерии приёмки. Для каждого типа результата должны быть понятны признаки готовности: где это проверяется, кем, по какому чек-листу, с какими тестами или контрольными критериями. Фиксация: перечень признаков готовности. Артефакт: чек-лист приёмки и порядок повторной сдачи. Типовая ошибка: считать, что качественный результат «и так видно».

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

5. Отдельно описать порядок изменений. В проекте почти всегда будут новые идеи, уточнения и доработки. Вопрос не в том, чтобы запретить их, а в том, чтобы они не разрушали бюджет и сроки незаметно. Фиксация: форма запроса на изменение, оценка влияния, согласование, очередность. Артефакт: change-request процедура и журнал изменений. Типовая ошибка: разрешать любые изменения в чате без следов.

6. Затем нужно закрепить артефакты на выходе. Не достаточно написать «результат передаётся заказчику». Нужно явно указать, что именно передаётся: исходники, код, репозитории, макеты, доступы, структуры кабинетов, библиотеки, инструкции, отчёты, выгрузки, реестры, архивы файлов, AI-промпты, если они являются частью результата. Фиксация: перечень обязательных артефактов. Артефакт: приложение о составе сдачи. Типовая ошибка: путать итоговый результат и всё, что нужно для его дальнейшего использования.

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

8. И только после этого собирать всё в договор и приложения. Сам текст договора должен не заменять процесс, а удерживать его. Фиксация: согласованный пакет документов. Артефакт: договор + SOW + SLA + регламент изменений + порядок приёмки + перечень артефактов + модель доступа. Типовая ошибка: надеяться, что один короткий шаблон «про всё» вытянет сложный цифровой проект.

Документы и доказательства

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

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

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

• SLA — уровень сервиса. Нужен там, где есть поддержка, сопровождение, реагирование на обращения, устранение ошибок, режимы доступности и разные типы приоритетов. Он помогает отделить «мы работаем» от «мы обязаны реагировать в заданной модели».

• Чек-листы приёмки. Для разработки, дизайна, контента, настройки аналитики, рекламных кабинетов и иных результатов полезно фиксировать критерии готовности в форме, которую можно реально использовать, а не только цитировать в споре.

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

• Журнал изменений. Один из самых недооценённых документов. Именно он даёт возможность восстановить, какие решения меняли объём, сроки и стоимость, и кто это согласовывал.

• Реестр артефактов передачи. Особенно важен при завершении этапа или смене исполнителя: исходники, файлы, доступы, репозитории, библиотеки, инструкции, выгрузки, пароли/токены передачи, архивы, контактные точки.

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

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

• Отчёты с привязкой к поставкам. Не просто «мы сделали много работы», а отчёт, где видно: какие задачи закрыты, какие артефакты сданы, какие замечания открыты, какие зависимости тормозят этап.

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

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

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

Как мы работаем: действие → фиксация → артефакт

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

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

• Выделяем поставки и зоны результата. Разделяем «активность» и «результат»: что действительно должно быть сдано, в каком виде и по каким признакам готовности. Фиксируем: этапы, поставки, критерии. Артефакт: скелет SOW.

• Конструируем порядок приёмки. Переводим субъективные ожидания в систему проверки: кто принимает, как фиксируются замечания, что считается исправлением, как запускается повторная сдача. Фиксируем: шаги приёмки. Артефакт: регламент приёмки и протокол замечаний.

• Настраиваем change-control. Определяем, как проект обрабатывает новые пожелания, правки, доработки, срочные задачи и перераспределение приоритетов. Фиксируем: порядок подачи и одобрения изменений. Артефакт: форма change-request и журнал изменений.

• Связываем оплату с подтверждениями. Разделяем календарную динамику и юридическую точку перехода к оплате. Фиксируем: условия, документы, этапы, ограничения на предоплату без следов. Артефакт: платежная логика и пакет подтверждений к этапу.

• Описываем права на результат и состав передачи. Выясняем, что именно должно остаться у бизнеса после этапа и после завершения сотрудничества. Фиксируем: перечень результатов, права, момент передачи, ограничения на повторное использование исполнителем. Артефакт: блок о правах + реестр артефактов передачи.

• Закрываем тему доступа, конфиденциальности и субподряда. Определяем, какие данные видит подрядчик, кому может передавать доступы, как контролируется привлечение третьих лиц, что происходит на выходе. Фиксируем: допустимые роли и запреты. Артефакт: разделы о доступах, субподряде, возврате/удалении данных, прекращении доступа.

• Тестируем пакет на реальной жизни. Проверяем, не слишком ли он абстрактен, не создаёт ли лазейки, можно ли им реально пользоваться без перегруза. Фиксируем: слабые места, двусмысленности, точки конфликта. Артефакт: доработанная версия договора и приложений.

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

Типовые ошибки

• Ошибка: использовать один общий шаблон договора на все цифровые проекты. Почему возникает: хочется сократить время и «не усложнять». Чем заканчивается: текст получается слишком общим и не удерживает реальный процесс. Как предотвратить: выносить в приложения конкретный SOW, SLA, артефакты, порядок приёмки и изменений.

• Ошибка: не разделять объём и изменения. Почему возникает: на старте кажется, что всё можно «договорить по ходу». Чем заканчивается: проект расползается, а спор идёт о том, кто что имел в виду. Как предотвратить: фиксировать ядро объёма, исключения и change-control с первого дня.

• Ошибка: принимать результат «по ощущениям». Почему возникает: неудобно тратить время на чек-листы и формализацию. Чем заканчивается: заказчик недоволен, подрядчик считает всё закрытым, оплата подвисает, конфликт растёт. Как предотвратить: строить критерии готовности и протокол замечаний заранее.

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

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

• Ошибка: не ограничивать субподряд. Почему возникает: доверяют бренду агентства целиком. Чем заканчивается: работу фактически выполняют третьи лица, а заказчик узнаёт об этом постфактум. Как предотвратить: закреплять правила привлечения субподрядчиков, доступов и конфиденциальности.

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

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

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

• Ошибка: считать отчётность доказательством результата. Почему возникает: много активности создаёт ощущение движения. Чем заканчивается: отчёты есть, а сдачи как таковой нет. Как предотвратить: отделять activity-report от delivery-proof.

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

• Ошибка: не проверять, кто реально принимает работу внутри компании. Почему возникает: заказчик думает, что «кто-нибудь из команды посмотрит». Чем заканчивается: приёмка зависает или проходит формально без глубины. Как предотвратить: заранее назначать роли: кто смотрит функционал, кто данные, кто публикацию, кто бизнес-логику.

Триггеры и ранние признаки

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

• Признак: команда не может быстро объяснить, что именно считается завершением этапа. Что это значит: приёмка не спроектирована. Первый шаг: сформировать чек-лист готовности хотя бы для одного ближайшего этапа.

• Признак: все важные решения живут в переписке. Что это значит: проект зависит от памяти и интерпретаций. Первый шаг: вынести критичные решения в реестр или протокол подтверждений.

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

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

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

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

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

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

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

Мини-кейсы

• Кейс 1. «Мы думали, что это входит». Компания заказала развитие сайта и маркетинговую поддержку. Подрядчик работал активно, но каждая новая идея, правка или уточнение быстро превращались в отдельный счёт. Заказчик считал это обычной частью сопровождения, подрядчик — новым объёмом. Корень проблемы был не в конфликтности сторон, а в отсутствии нормального SOW и границ. После пересборки проекта на поставки и change-control спорное поле резко сузилось: стало видно, где базовый объём, где новые задачи и на что реально тратятся деньги.

• Кейс 2. «Результат вроде есть, но принять нечем». Дизайн и контент по проекту были подготовлены, однако внутренней команде заказчика было неясно, что именно считать финальной поставкой. Не было формата приёмки, списка обязательных файлов, контрольных критериев по качеству и протокола замечаний. В результате подрядчик считал этап закрытым, а заказчик — нет. После введения чек-листа приёмки и процедуры повторной сдачи конфликт ушёл из эмоциональной зоны в управляемую.

• Кейс 3. «Хотим сменить подрядчика, но боимся потерять всё». Маркетинговая команда вела рекламные кабинеты, аналитику, структуру контента и часть технических настроек. Когда качество перестало устраивать, бизнес столкнулся с неприятным фактом: слишком много зависело от внешней стороны, а перечень того, что должно быть передано, никогда не фиксировался. Решение потребовало не только переговоров, но и сборки реестра артефактов, прав и доступов. Без этого замена команды означала бы почти ручную пересборку маркетингового контура.

• Кейс 4. «Подрядчик использует AI, а договор молчит». Агентство ускоряло производство контента и части креативов через AI, но заказчик узнал об этом только после спорной публикации. В договоре не было ни ограничений, ни режима раскрытия таких сценариев, ни требований к человеческой проверке результата. После инцидента пришлось пересматривать не только формулировки о качестве, но и связывать договор с правилами по данным и AI. Иначе скорость подрядчика объективно росла бы быстрее, чем контроль бизнеса.

• Кейс 5. «Отчёты хорошие, а денег жалко всё равно». Подрядчик регулярно присылал красивые отчёты: таблицы, статусы, комментарии, планы. Но собственник не мог ответить на простой вопрос — что именно стало активом компании после каждого месяца работы. Когда отчётность привязали к артефактам, а не к активности, картина резко прояснилась: часть задач была полезной, часть — шумом, а часть — не должна была оплачиваться без подтверждённого результата.

• Кейс 6. «Ушёл ключевой человек, и проект ослеп». У подрядчика сменился специалист, который держал архитектуру, историю решений и часть доступов. Заказчик обнаружил, что слишком многое не было вынесено в документы, реестры и инструкции. Этот кейс хорошо показывает: договорная модель должна защищать не только от недобросовестности, но и от обычной человеческой текучести. Потому что бизнесу всё равно, почему именно потеряна управляемость — из-за конфликта или из-за смены людей. Потери наступают одинаково.

Частые вопросы

• Нам нужен именно SOW, если уже есть договор?

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

• SLA обязателен для любого подрядчика?

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

• Можно ли всё решить приложением к типовому договору?

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

• Насколько подробно нужно описывать приёмку?

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

• Стоит ли жёстко запрещать субподряд?

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

• Нужно ли включать доступы и данные в договор с подрядчиком?

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

• Как быть, если подрядчик уже работает, а договор слабый?

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

• Если подрядчик пользуется AI, нужно ли это отдельно раскрывать?

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

• Достаточно ли просто прописать передачу прав?

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

• Что важнее: сильный текст договора или дисциплина исполнения?

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

Куда обратиться и что подготовить

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

• действующий договор и все приложения, если они есть;

• ТЗ, брифы, коммерческие предложения, презентации, scope-файлы, если через них реально описывался объём;

• примеры спорных переписок, где обсуждались правки, сроки, новые задачи, приёмка и замечания;

• список систем, кабинетов, файловых хранилищ и иных точек доступа, куда подрядчик включён фактически;

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

• перечень уже случившихся проблем: просрочки, споры по объёму, неполная сдача, хаос версий, вопрос по правам, удержание материалов, нестабильная реакция на инциденты;

• если подрядчик использует AI или работает с чувствительными данными — краткое описание этих сценариев.

Что делать дальше внутри кластера:

• если параллельно нужно определить, как сотрудники и подрядчики могут использовать нейросети, переходите в Политику использования AI;

• если ключевая проблема в хранении данных, доступах, передаче файлов и DLP-логике, переходите в Политику данных;

• если уже есть копии, фейки, спорные публикации или digital-инцидент вокруг результата работы подрядчика, переходите в Защиту контента / бренда в digital;

• если нужен общий контекст ветки, вернитесь в IT / Данные / AI-политики для бизнеса.

Артефакты на выходе и критерии готовности

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

• Артефакт: основной договор или усиленный пакет к существующему договору.

• Артефакт: SOW с декомпозицией поставок, границ, допущений и исключений.

• Артефакт: SLA, если проект предполагает поддержку, сопровождение, инциденты и сроки реакции.

• Артефакт: чек-листы приёмки по типам результата и протокол замечаний.

• Артефакт: change-control: форма запроса на изменение, логика согласования, журнал изменений.

• Артефакт: перечень артефактов передачи: исходники, доступы, репозитории, макеты, инструкции, реестры, выгрузки.

• Артефакт: блок по правам на результат и режиму использования материалов.

• Артефакт: матрица ролей/доступов или ссылка на неё, если проект затрагивает данные и системы.

• Артефакт: порядок выхода из проекта и замены исполнителя без потери накопленного результата.

• Артефакт: логика связки с AI-политикой и политикой данных, если проект работает с AI или чувствительными данными.

Критерии готовности здесь очень конкретные:

• бизнес может объяснить, что именно входит в проект, а что проходит как изменение;

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

• оплата привязана к подтверждённым поставкам, а не к общему ощущению движения;

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

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

• спор о результате можно вести на документах, а не на воспоминаниях;

• если подрядчик использует AI или работает с чувствительными данными, это отражено в правилах и не живёт в серой зоне;

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

Смотрите также

• IT / Данные / AI-политики для бизнеса

• Политика использования AI (доступы / логирование / запреты)

• Защита контента / бренда в digital (удаление копий/фейков / репутационные претензии)

• Политика данных (классы данных / хранение / DLP-логика)

Получить консультацию

Мы можем предложить Вам следующие услуги: