Договор на техническую поддержку сайта нужен, когда бизнес хочет стабильную работу сайта и понятные правила на случай ошибок, сбоев и изменений. Без договора поддержка быстро превращается в бесконечные срочные просьбы, споры о том, кто виноват, и что именно входит в оплату.
Хороший договор фиксирует три вещи. Что именно вы поддерживаете. Как вы работаете с инцидентами и изменениями. И как вы измеряете качество сервиса через сроки и правила коммуникации.
Зачем нужен договор и какие задачи он решает
Договор защищает обе стороны. Бизнес получает прогнозируемость. Подрядчик получает понятный контур задач и порядок согласований.
Обычно договор решает такие задачи:
- фиксирует состав работ: мониторинг, обновления, резервные копии, устранение ошибок, мелкие правки, администрирование
- определяет формат работы: куда писать, кто принимает задачи, кто согласует, как проходит эскалация
- задаёт правила по срокам: что считается временем реакции, что считается временем решения, в какие часы работает поддержка
- разделяет баги и доработки, чтобы снизить конфликт, когда бизнес просит новую функцию, а ожидает, что её сделают как исправление ошибки
- фиксирует ответственность: кто отвечает за доступы, хостинг, домен, сторонние сервисы, контент и согласования
- описывает процесс передачи: что происходит при смене подрядчика, как передают доступы, документацию и исходные материалы
Чем техподдержка отличается от гарантийных исправлений
Гарантийные исправления относятся к периоду после запуска и закрывают ошибки, которые появились по вине разработки. Обычно это баги, которые мешают корректной работе того, что уже сделали и согласовали.
Техническая поддержка работает шире. Она включает регулярные задачи, которые появляются в любой живой системе:
- обновления CMS, модулей и зависимостей
- контроль доступности и реакция на сбои
- восстановление после ошибок, в том числе из резервных копий
- доработки и изменения по запросу бизнеса
- работа с инфраструктурой и интеграциями, если это входит в контур поддержки
Из-за этого важно не смешивать гарантию и поддержку в один размытый блок. Если вы не разделите эти режимы, вы получите спор уже на первой неделе после запуска.
Когда договор особенно важен для бизнеса
Договор нужен всегда, но есть ситуации, когда без него бизнес теряет деньги и время:
- сайт приносит заявки и продажи — любой простой сразу бьёт по выручке и репутации
- есть интеграции: платежи, CRM, телефония, онлайн-запись, доставка, аналитика — любой сбой требует понятного процесса и ответственных
- над сайтом работают разные люди: маркетинг, контент-команда, подрядчики по рекламе — без регламента они легко ломают настройки и спорят, кто должен чинить
- есть персональные данные и доступы: формы, личный кабинет, базы пользователей — нужно заранее описать безопасность и порядок действий при инциденте
- сайт регулярно меняется: акции, новые страницы, новые услуги — поддержка без правил быстро превращается в хаос
Термины и определения, без которых договор работает плохо
Договор поддержки часто ломается на словах. Одна сторона думает, что инцидент — это падение сайта. Другая считает инцидентом любую просьбу в мессенджере. Поэтому в начале договора нужны определения.
Минимальный набор терминов, которые стоит зафиксировать:
- что такое сайт: домены и поддомены, страницы и функциональные модули, админ-панель, формы и интеграции
- какие окружения вы поддерживаете: production — боевой сайт, stage — тестовая среда, dev — среда разработки
- что такое инцидент: событие, которое нарушает работу сайта или ключевых функций
- что такое баг: дефект в уже согласованной функциональности, который воспроизводится по шагам
- что такое доработка: изменение логики, интерфейса или функций — это изменение требований, а не баг
- что такое обновление: плановая установка обновлений CMS, модулей и библиотек
- что такое запрос, приоритет, время реакции и время решения
Эти определения не делают договор тяжелее. Они делают его рабочим. Когда термины совпадают, поддержка идёт спокойно и без постоянных уточнений.
Что считается сайтом и окружениями prod, stage, dev
В договоре слово «сайт» часто звучит слишком широко, из-за чего подрядчик и заказчик по-разному понимают, что именно надо поддерживать. Пропишите состав сайта как набор компонентов: публичная часть и админ-панель, база данных, серверная часть и интеграции. Сюда же часто входят формы заявок, личный кабинет, каталог, корзина и оплата, сервисы аналитики и уведомлений. Если есть поддомены, мультиязычность, мобильная версия или PWA, это тоже стоит перечислить.
Дальше зафиксируйте окружения. Prod — рабочая среда, где сайт доступен пользователям. Stage — среда для финальной проверки перед релизом. Dev — среда разработки. В договоре важно прямо указать, какие окружения входят в поддержку и что именно делает подрядчик в каждом из них.
Ещё один частый источник конфликтов — инфраструктура. Если сервер, домен, SSL-сертификат, CDN или почта находятся у третьих лиц, обозначьте это. Укажите, кто отвечает за оплату, продление и доступы, и кто делает настройки, если нужно поменять хостинг или параметры безопасности.
Что такое инцидент, баг, доработка, обновление
Инцидент — это сбой, который влияет на работу сайта или его части: сайт не открывается, не отправляются формы, не проходит оплата, ломается личный кабинет, падает интеграция. Инцидент требует реакции по SLA, потому что бизнес теряет заявки, деньги или данные.
Баг — это ошибка в существующей логике, которая проявляется при корректном использовании. Важно закрепить, что считается багом относительно согласованного поведения. Если в ТЗ и приёмке этого поведения не было, спор почти неизбежен.
Доработка — это изменение или расширение функциональности: новый фильтр в каталоге, новый отчёт, новый тип уведомлений, новая роль в админке. Доработка почти всегда требует оценки, согласования сроков и отдельной приёмки.
Обновление — это плановая работа, которая поддерживает сайт в актуальном и безопасном состоянии. Обновление сохраняет поведение системы, а доработка меняет поведение. Если используются сторонние сервисы, добавьте правило: сбой у стороннего поставщика — это инцидент для бизнеса, но не всегда ответственность подрядчика.
Как фиксируются приоритеты и уровни критичности
Без правил приоритизации поддержка превращается в очередь из срочных задач. Начните с принципа: приоритет зависит от влияния на деньги, заявки и ключевые сценарии. Второй фактор — количество затронутых пользователей. Третий — наличие обходного решения.
Удобно закрепить несколько уровней: критичный (сайт недоступен или не работает ключевая функция), высокий (сильно ломается сценарий, но сайт остаётся доступным), средний (есть дефект, но бизнес работает с ограничениями), низкий (проблема влияет на удобство или внешний вид, но не блокирует процесс).
Дальше договор должен сказать, кто присваивает приоритет и как его меняют. Обязательно укажите, как вы считаете время: по рабочим часам или по календарю. Если бизнесу нужен режим 24/7, его нельзя подразумевать — его нужно отдельно фиксировать.
Объём работ и границы ответственности сторон
Договор поддержки работает только тогда, когда у него есть границы. Они защищают обе стороны. Заказчик понимает, за что он платит и что получит. Подрядчик понимает, что он должен делать регулярно, а что относится к отдельным работам.
Опишите, какие работы входят в стандартное сопровождение, а какие считаются дополнительными. Укажите каналы постановки задач и формат, зафиксируйте часы работы и правила срочных обращений. Разделите ответственность по зонам: контент и публикации часто остаются на стороне заказчика, инфраструктура может быть у заказчика или у подрядчика, интеграции находятся в смешанной зоне.
Что обычно входит в сопровождение сайта
Сопровождение — это набор регулярных и реактивных работ. Его цель простая: сайт должен стабильно работать, оставаться безопасным и развиваться без хаоса. Обычно сюда входят:
- мониторинг доступности и быстрый разбор сбоев
- исправление багов и восстановление работоспособности форм, страниц и интеграций
- обновления CMS и модулей в рамках согласованных правил
- контроль безопасности, резервные копии и восстановление при сбое
- небольшие правки: тексты, баннеры, контактные данные, блоки на странице, метрики аналитики
- контроль связок с CRM, оплатой, доставкой и почтовыми сервисами
И наконец отчётность. Даже простая поддержка должна оставлять след: подрядчик даёт список выполненных задач и статус открытых обращений за период.
Что не входит и как оформляются дополнительные задачи
Рядом со списком работ, которые входят в сопровождение, нужен отдельный список того, что не входит. Обычно это всё, что меняет продукт или бизнес-логику: новые страницы и разделы, новый функционал и интеграции, переработка дизайна, перенос на другой стек, наполнение сайта контентом, работа с рекламными кабинетами.
Чтобы дополнительные задачи не превращались в конфликт, пропишите простой процесс из трёх шагов. Заказчик ставит задачу в согласованном канале с целью, ссылкой и критерием готовности. Исполнитель классифицирует запрос — баг это или доработка — и даёт оценку по срокам и стоимости. Заказчик подтверждает, после чего задача попадает в план работ и получает приоритет.
Добавьте правило про срочные внеплановые работы: срочная задача идёт только после отдельного согласования и может считаться по другой ставке или в другом окне времени.
Обязанности заказчика: доступы, контент, согласования
Поддержка ломается не из-за разработки, а из-за отсутствия доступа, ответственных и правил согласования. Назначьте одного владельца продукта со стороны заказчика: он принимает работы, согласует приоритеты и даёт финальное добро на релизы.
Пропишите доступы. Заказчик предоставляет доступ к админке, хостингу или серверу, домену, почте, аналитике, репозиторию и сторонним сервисам, отвечает за актуальность учётных данных и за порядок их выдачи. Уточните, кто готовит контент и кто отвечает за его корректность и права на материалы.
Пропишите правила согласования: сколько времени заказчик даёт на ответ по макетам, правкам и релизам и что происходит, если ответа нет. И отдельно — заказчик уведомляет о любых изменениях, которые делает третья сторона, иначе поддержка превращается в поиск причин в темноте.
SLA и матрица инцидентов: как прописать уровень сервиса
SLA — это правила, по которым вы обслуживаете сайт. Он отвечает на один вопрос: как быстро поддержка реагирует и что считает нормой. Без SLA договор выглядит как обещание поддерживать сайт «в целом». Это опасно и для бизнеса, и для исполнителя.
SLA лучше фиксировать не общими словами, а измеримыми параметрами: время реакции, время решения и время восстановления, приоритеты, рабочие часы, окно плановых работ и способ измерения выполнения. Если сайт приносит заявки и деньги, добавьте связь SLA с бизнес-функциями — отдельный высокий приоритет для формы заявки, корзины, оплаты и авторизации.
Время реакции, время решения, время восстановления
Время реакции — сколько проходит от обращения до первого ответа и взятия задачи в работу. Это подтверждение, что инцидент увидели и начали разбираться.
Время решения — сколько нужно, чтобы устранить причину и закрыть инцидент. Это может включать разработку, тестирование и выкладку и зависит от типа проблемы и доступности окружений.
Время восстановления — сколько нужно, чтобы вернуть работоспособность критичной функции, даже если корень проблемы ещё остаётся: включили временный обходной сценарий, откатили релиз, отключили конфликтующий модуль. Важно описать, как вы считаете время и что считается паузой, например ожидание доступа или ответа заказчика.
Приоритеты инцидентов и окно плановых работ
Матрица приоритетов нужна, чтобы команда не спорила о важности, а бизнес понимал, почему одни задачи идут раньше других. К каждому уровню привяжите критерии, а не эмоции:
- критичный: сайт недоступен, не работает оплата или отправка заявок, сломана авторизация, есть утечка или подозрение на взлом
- высокий: ошибка затрагивает заметную часть пользователей, ломается ключевой сценарий, но есть обходной путь
- средний: ошибка есть, но она не блокирует сценарий, неправильно работает один блок
- низкий: мелкие правки, косметика, уточнения текста, улучшения без влияния на работу
Зафиксируйте окно плановых работ — время, когда вы выкатываете обновления, делаете профилактику и проверяете бэкапы, чтобы релизы не происходили в случайные моменты. И добавьте правило эскалации: кто и как поднимает приоритет и кто принимает решение.
Как измерять SLA и что считать нарушением
Сначала договоритесь о единицах измерения. Зафиксируйте рабочие часы поддержки, часовой пояс и праздничные дни, укажите, действует ли SLA в нерабочее время. Опишите, от какого события начинается отсчёт, и что считается подтверждением — например ответ исполнителя в тикете с номером задачи.
Заранее определите правила остановки таймера: когда заказчик не дал доступы, не подтвердил изменения, не предоставил данные для воспроизведения или когда сайт ломает внешний сервис, к которому нет доступа. Опишите, что именно считается нарушением SLA: превышение времени реакции или времени восстановления для критичных инцидентов, и только при корректно оформленной заявке.
Добавьте способ контроля: все обращения идут через единый список задач с обязательными полями — тема, описание, шаги воспроизведения, скриншоты или логи, приоритет, окружение, контакты. Так вы сможете строить отчёты по SLA и видеть узкие места.
Доступы, безопасность и защита данных
Поддержка не работает без доступа. Но открытый доступ без правил создаёт риски. В договоре опишите, кто и как получает доступы, кто их хранит и как вы их отзываете. Минимальные меры безопасности часто важнее любых штрафов, потому что защищают данные и репутацию.
Разделите доступы по уровням: сервер, админка сайта, репозиторий, панели сторонних сервисов, аналитика и почта. Для каждого уровня укажите, нужен ли доступ постоянно или по запросу и кто согласует выдачу. Сразу зафиксируйте правила работы с данными: поддержка почти всегда видит заявки, формы и логи, иногда с персональными данными.
Регламент доступа к серверу, админке, репозиторию
Опишите формат доступа. Индивидуальные учётные записи лучше общих: они дают контроль и журнал действий. Заказчик выдаёт доступы на конкретных людей или роли, и доступы закрываются при увольнении или смене команды.
Укажите, какие доступы нужны для старта поддержки — обычно хостинг или сервер, админ-панель и репозиторий, если поддержка затрагивает код. Если репозитория нет, зафиксируйте, где хранится исходный код. Добавьте правило про окружения: в идеале вы используете stage для проверки и только потом делаете релиз в prod.
Определите, кто имеет право на деплой и как вы фиксируете факт релиза — например запись в тикете с датой и списком изменений. Это помогает разбирать инциденты и спорные ситуации.
Работа с персональными данными и конфиденциальностью
Определите, какие данные вы считаете конфиденциальными: коммерческие документы, доступы, логи, данные клиентов, базы пользователей, финансовые сведения. Укажите, что исполнитель использует их только для выполнения работ, без передачи третьим лицам и без публикации.
Если сайт собирает персональные данные через формы, личный кабинет или оплату, зафиксируйте базовые правила: кто отвечает за содержание форм и тексты согласий, кто хранит данные и где, кто имеет доступ. Чем меньше людей видят данные, тем ниже риск.
Опишите, как вы работаете с логами и выгрузками: когда они нужны, где хранятся и когда удаляются. Выберите один безопасный канал для передачи секретов — например менеджер паролей — и пропишите, кто имеет право запросить такие данные.
Действия при инциденте безопасности и уведомления
Опишите, что вы считаете инцидентом безопасности: взлом админки, подмена контента, утечка базы, подозрительная активность, неожиданные новые администраторы, массовые рассылки с сайта. Такие определения помогают включить правильный режим работ без споров.
Зафиксируйте порядок действий: кто принимает обращение, кто запускает первичные меры — смена паролей, отзыв токенов, блокировка доступа, включение режима обслуживания, проверка логов. Решение о публичных коммуникациях всегда остаётся зоной заказчика, но поддержка может дать технические факты.
Опишите сроки уведомления и порядок эскалации: кому звонить, если инцидент критичный, и какие контакты работают вне рабочего времени. По итогам полезен короткий отчёт: что произошло, когда началось, что сделали, какие данные могли затронуть и что снизит вероятность повторения.
Резервные копии и аварийное восстановление
Резервные копии и план восстановления закрывают два риска: потерю данных и простой сайта. Если эти правила не прописать, спор начинается в момент аварии. Бизнес ожидает быстрый возврат в рабочее состояние, подрядчик может считать, что отвечал только за код. Договор должен заранее снять это напряжение.
Сразу разделите два слоя: резервные копии данных и резервные копии кода. Данные обычно меняются каждый день, код — по релизам. Эти слои хранят и восстанавливают по разным сценариям.
Частота бэкапов и сроки хранения
Зафиксируйте, что именно попадает в бэкап: база данных, файлы сайта, пользовательские загрузки, конфигурации и ключевые настройки. Если сайт использует сторонние сервисы, отметьте, что их данные не всегда можно восстановить из бэкапа сайта — тогда нужна отдельная политика экспорта.
Опишите частоту по категориям — база данных, файлы и медиа, конфигурации — не общими словами «делаем регулярно», а с конкретным режимом. Опишите сроки хранения и привяжите их к рискам бизнеса: для бухгалтерских и юридических данных срок обычно нужен больше, для промо-сайта — меньше.
Зафиксируйте место хранения: один сервер рядом с продом часто не спасает при сбое диска или взломе. И добавьте проверку бэкапов — копия без тестового восстановления часто оказывается пустой формальностью.
Порядок восстановления и ответственность за простои
Восстановление всегда идёт по сценарию. Опишите его простыми шагами:
- кто фиксирует инцидент и через какой канал
- кто принимает решение о восстановлении и откате
- на какую точку восстановления откатываетесь
- как проверяете работоспособность после восстановления
- кто даёт добро на возврат трафика и открытие сайта
Пропишите границы ответственности за простой: сайт может упасть из-за хостинга, домена, внешних API, платежей или действий сотрудников заказчика. Укажите, кто несёт риск потери данных при согласованном откате — если бизнес выбирает быстрый откат на вчерашнюю копию, он принимает потерю части новых данных.
Что должно быть в инструкции и кто её обновляет
Договору нужны приложения, иначе он остаётся декларацией. По бэкапам и восстановлению полезно иметь короткую инструкцию, которую можно открыть в момент аварии. В ней зафиксируйте минимум:
- список систем и компонентов, которые нужно резервировать
- где лежат бэкапы и как туда зайти, кто имеет доступ
- порядок восстановления по шагам и как поднять сайт на stage для проверки
- как проверить ключевые сценарии: главная, формы, оплата, личный кабинет, админка
- контакты для эскалации со стороны заказчика и подрядчика
Определите владельца документа: кто обновляет инструкцию после релизов и изменений инфраструктуры. Частая ошибка, когда инструкция устаревает через два месяца и в аварии никто не понимает, где что лежит.
Услуга по теме
Возьмём ваш сайт на техническую поддержку
Настроим понятную поддержку с SLA, мониторингом, бэкапами и регламентом доступов. Разделим инциденты, доработки и обновления, дадим прозрачные отчёты по задачам и часам. Код, аккаунты и ключи останутся у вас.
Доработки, обновления и изменения объёма работ
Поддержка почти всегда переходит в развитие. Бизнес просит новые блоки, интеграции, личный кабинет, новые отчёты. Если договор не разделяет поддержку и развитие, команда начинает спорить, что входит в ежемесячные работы.
Зафиксируйте принцип: поддержка сохраняет работоспособность и безопасность, доработки меняют функциональность или добавляют новую, обновления могут быть и тем, и другим. Опишите, как вы меняете объём работ: кто инициирует запрос, в каком виде ставится задача, как оцениваются сроки и стоимость, кто согласует и ставит приоритет, как планируется релиз и тестирование.
Как отличить баг от новой функциональности
Баг — это отклонение от согласованного поведения. Было в ТЗ, прототипе или принятой версии сайта, но работает иначе. Например: форма отправляет заявку, но письмо не приходит; кнопка не нажимается в мобильной версии, хотя должна.
Новая функциональность — это изменение требований. Раньше такого сценария не было, и вы хотите, чтобы он появился: добавить новый способ оплаты, сделать личный кабинет, подключить новую CRM. В договоре удобно закрепить критерии решения:
- есть ли описание нужного поведения в исходных материалах проекта — ТЗ, прототипы, макеты, переписка с подтверждением
- был ли этот сценарий в приёмке и работал ли он в продакшене до изменений
- изменились ли внешние условия — провайдер поменял API, хостинг обновил версии, браузеры изменили требования
- кто инициировал изменение — если бизнес меняет правила, это почти всегда новая задача
Процесс Change Request: оценка, согласование, приоритизация
Change Request — это контролируемый способ менять объём работ. Он защищает обе стороны: бизнес получает прозрачность по срокам и цене, команда — понятный приоритет и критерии приёмки. Минимальный состав заявки: описание задачи и цель, ссылки на страницы и сценарии, ожидаемый результат, критичность для бизнеса, ограничения и критерии приёмки.
Дальше закрепите цикл согласования: регистрация запроса в едином канале, первичная оценка и проверка зависимостей, оценка сроков и трудозатрат, выбор модели оплаты, согласование приоритета и план релиза.
Отдельно зафиксируйте правило приоритизации. Инциденты и безопасность обычно идут выше развития. Изменения, которые влияют на деньги и заявки, получают высокий приоритет. Косметические правки планируются в регулярные релизы.
Приёмка изменений, тестирование и релиз
Без понятной приёмки изменения зависают: бизнес говорит, что ещё не готово, команда — что уже сделано. Обычно работает простая схема: команда показывает результат на тестовом окружении, заказчик проверяет по согласованным критериям и даёт список замечаний в одном месте, команда исправляет и повторяет показ, после приёмки изменения выкатываются в продакшен в согласованное окно.
В тестировании разделите зоны ответственности. Команда проверяет техническую часть: вёрстку, работу форм, интеграции, базовые сценарии. Заказчик проверяет бизнес-смысл: тексты, цены, условия, юридические формулировки и корректность контента.
Пропишите, что включает релиз: деплой на сервер, базовую проверку работоспособности, обновление зависимостей и инструкции, если изменения затронули админку. И укажите, что срочные релизы возможны, но требуют отдельного согласования окна и приоритета.
Оплата, отчётность и дополнительные расходы
Оплата в поддержке должна быть простой и измеримой. Тогда вы планируете бюджет и не спорите о том, что именно сделано. В договоре стоит разделить регулярную поддержку, работы по развитию и внешние расходы.
Сразу определите, как команда фиксирует фактические работы: где хранится список задач, сколько времени ушло, что вошло в отчёт и как часто вы его получаете. Удобный минимум — отчёт по задачам и часам за период плюс статус по инцидентам и релизам.
Модели оплаты: подписка, пакет часов, time and materials
Подписка. Вы платите фиксированную сумму за период и получаете оговоренный уровень сервиса и объём работ. Модель подходит, когда важна предсказуемость и есть регулярные задачи. В договоре нужно чётко описать, что входит в подписку.
Пакет часов. Вы покупаете определённое количество часов поддержки на месяц или квартал, команда списывает их по факту. Важно прописать, переносятся ли неиспользованные часы, как считается минимальная единица списания и как подтверждаются трудозатраты.
Time and materials. Вы платите по фактическим трудозатратам по согласованной ставке. Модель подходит для задач с неопределённым объёмом: сложные доработки, интеграции, миграции. Часто бизнес комбинирует модели: подписка или пакет часов закрывают базовую поддержку и SLA, а крупные изменения идут отдельными оценками.
Лицензии, хостинг, сторонние сервисы: кто оплачивает
За поддержку сайта почти всегда платят отдельно от расходов на инфраструктуру и сервисы. Перечислите в договоре список обязательных расходов: домен и DNS, хостинг или сервер, SSL-сертификаты, почтовые сервисы, резервное копирование, CDN, платные модули, сервисы аналитики и рассылок, платёжные шлюзы. У каждой позиции укажите, кто владелец аккаунта и кто оплачивает.
Безопаснее, когда ключевые аккаунты оформлены на заказчика, а подрядчик работает по выданным доступам. Пропишите порядок оплаты и подтверждения расходов, лимиты и что считается дополнительным расходом, требующим отдельного согласования бюджета.
Зафиксируйте, что происходит при просрочке оплаты инфраструктуры: если домен или хостинг не оплачены, сайт может остановиться. Подрядчик не отвечает за простой, если доступ к сервисам заблокировала третья сторона из-за неоплаты.
Акты и отчёты: какие метрики и периодичность
Акты и отчёты делают поддержку управляемой. Обычно их готовят раз в месяц; при частых релизах добавляют промежуточные отчёты раз в неделю или две. Состав отчёта по работам: список задач, тип работ, дата и время выполнения, фактически затраченное время, результат и ссылка на подтверждение.
Просите метрики, которые реально помогают, а не статистику ради статистики:
- количество инцидентов по приоритетам
- время реакции и время восстановления по каждому критичному инциденту
- доля выполненных заявок в срок по согласованным приоритетам
- остаток часов в пакете или фактические часы по модели time and materials
- список рисков и технического долга: устаревшие плагины, уязвимости, неактуальные бэкапы, проблемы производительности
Пропишите форму приёмки: кто со стороны заказчика принимает работы и в какой срок, что считается принятием — например подписанный акт или отсутствие замечаний в течение оговоренного срока.
Права на исходный код и результаты доработок
Права на код и результаты доработок часто становятся проблемой не в момент подписания, а при росте проекта — когда вы хотите сменить подрядчика, привлечь внутреннего разработчика или продать продукт. Если договор молчит, каждая сторона будет трактовать ситуацию в свою пользу.
В договоре на поддержку важно разделить три вещи: что вы уже получили при разработке сайта (исходный код, макеты, доступы), что появляется в ходе поддержки (патчи, новые модули, интеграции, документация) и что относится к сторонним компонентам (платные темы, библиотеки, плагины с собственной лицензией). Для бизнеса практично прописать, что результаты оплаченных доработок переходят заказчику.
Кому принадлежат доработки и дизайн-материалы
Этот пункт лучше сделать максимально конкретным. Дайте перечень артефактов:
- исходный код и скрипты
- дизайн-файлы и прототипы
- контент и тексты, если их создавали в рамках работ
- документация, инструкции, схемы, спецификации
- настройки и конфигурации, созданные под ваш проект
Определите момент перехода прав — обычно после оплаты и приёмки. Если оплата помесячная, удобно закрепить переход прав на результаты каждого отчётного периода после подписания акта. Если проект включает персональные данные, отдельно закрепите, что подрядчик не получает права на данные и не может использовать их вне поддержки.
Доступ к репозиторию и порядок передачи артефактов
Репозиторий и артефакты передачи — это ваша страховка. Договор должен ответить на три вопроса: где лежит код, кто имеет доступ и что вы получите на выходе. Практичный вариант для заказчика — репозиторий в его аккаунте, а подрядчик получает доступ по ролям. Запретите общие аккаунты и используйте персональные учётные записи.
Помимо репозитория вам нужны доступы к серверу и панели хостинга, к CMS и админке, перечень доменов и DNS, список сторонних сервисов, инструкция деплоя и отката, инструкция восстановления из бэкапа и файл с переменными окружения. Укажите сроки передачи при расторжении и кто принимает передачу со стороны заказчика.
Закрепите право на копию: даже если репозиторий у заказчика, подрядчик обязан выгрузить архив кода и документации по запросу. Это помогает при форс-мажоре и ускоряет аудит.
Что предусмотреть для непрерывности при смене подрядчика
Смена команды поддержки всегда несёт риск простоя. Опишите, какие артефакты вы передаёте и в каком виде: доступы, список интеграций, схема окружений, инструкции по деплою, правила резервного копирования. Если документации нет, так и зафиксируйте — и добавьте обязанность актуализировать её в ходе поддержки.
Зафиксируйте порядок передачи доступов: кто создаёт учётные записи, кто выдаёт права, как меняются пароли, как фиксируется факт передачи. Это помогает избежать ситуации, когда доступы есть, но они не работают.
Опишите, как продолжится поддержка в переходный период. Частая практика: действующий подрядчик закрывает критичные инциденты до даты передачи и не берёт новые крупные доработки, а новый подрядчик подключается к диагностике и постепенно принимает ответственность.
Расторжение договора и план передачи поддержки
Расторжение часто происходит не из-за конфликтов, а из-за изменения задач: компания меняет инфраструктуру, пересобирает команду, переходит на другую модель поддержки. Договор должен описывать расставание так же чётко, как и старт.
Сделайте передачу частью процесса. Определите, кто инициирует, кто принимает, какие сроки и обязательные шаги. Свяжите этот раздел с правами на результаты работ и доступом к репозиторию — тогда передача станет технической процедурой, а не предметом переговоров в последний момент.
Сроки уведомления и переходный период
Укажите срок уведомления о расторжении. Он нужен обеим сторонам: заказчик получает время на поиск новой команды, подрядчик — на закрытие критичных задач и подготовку передачи. Опишите, какие работы подрядчик выполняет в переходный период: обработка инцидентов по текущему SLA, плановые обновления только по согласованию, консультации для новой команды.
Уточните, как меняется приоритизация на выходе. Обычно в переходный период бизнесу важнее стабильность, чем развитие, поэтому договор должен позволять заморозить доработки и сосредоточиться на поддержке прод-окружения.
Пропишите, когда прекращается доступ подрядчика к системам. Не делайте это мгновенно, если подрядчик ещё отвечает за стабильность, но и не оставляйте доступы бессрочно — зафиксируйте дату, после которой доступы отключаются или переводятся в режим только чтение.
Чек-лист передачи доступов, данных, документации
Добавьте к договору приложение с чек-листом передачи. Он экономит время и снижает риск забыть важное, закрывая три слоя — доступы, данные и документацию.
- доступы: сервер и панель хостинга, домен и DNS, SSL-сертификаты, CMS и админ-панель, база данных, репозиторий и система задач, аналитика и сторонние сервисы
- данные: актуальные дампы базы, файлы сайта и загрузки пользователей, конфигурации окружений, список интеграций и ключей API, контакты провайдеров
- документация: описание архитектуры и окружений prod, stage, dev, инструкция деплоя и отката, расписание бэкапов и сценарий восстановления, описание критичных модулей и точек отказа
В чек-листе важно указать ответственных и форму подтверждения передачи: акт передачи, письмо на корпоративную почту или запись в системе задач. Тогда у бизнеса остаётся понятный след.
Что происходит с незавершёнными задачами и оплатой
Договор должен заранее определить, что делать с задачами в работе на момент расторжения. Разделите их на три группы: инциденты, затрагивающие доступность и ключевые функции, обычно доводят до восстановления; плановые работы можно остановить на понятной точке и передать статус, исходники и комментарии; ещё не стартовавшие задачи фиксируют как отменённые или переносят к новому подрядчику.
Опишите правила расчёта. Для подписки и пакета часов укажите, как считаются неиспользованные часы и что происходит с переносом. Для time and materials — что подрядчик выставляет счёт по фактически выполненным работам с отчётом и списком задач.
Зафиксируйте, что происходит с доступами при наличии задолженности. Компромисс часто строится так: заказчик сохраняет доступы к критичной инфраструктуре, а подрядчик может приостановить новые работы до погашения задолженности. Это снижает риск остановки сайта из-за финансового спора.
