Как составить ТЗ на доработку сайта

Коротко: Чтобы составить грамотное техническое задание на доработку сайта, необходимо зафиксировать бизнес-цели, детально описать логику работы новых функций, требования к интеграции с CRM и актуальные правила сбора персональных данных. Важно разделять согласия на обработку ПДн и маркетинговые рассылки, а также учитывать требования к локализации данных в РФ и маркировке контента, созданного нейросетями.

Этапы подготовки ТЗ на доработку функционала

Многие собственники совершают одну и ту же ошибку: они приходят к разработчикам с фразой "сделайте нам личный кабинет" или "нужна интеграция с почтой". Это не задача, это мечта. Для того чтобы доработка функционала сайта через ТЗ принесла результат, а не бесконечные правки и раздутый бюджет, нужно пройти путь от бизнес-цели до технического сценария.

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

Второй этап - проектирование пользовательских сценариев (User Stories). Вам нужно описать путь пользователя: что он видит, куда нажимает и какой результат получает. Например, если вы внедряете систему бронирования, сценарий должен включать не только процесс выбора даты, но и обработку ошибок: что произойдет, если выбранное время уже занято, или если у пользователя пропал интернет в момент оплаты. Чем больше таких "тупиковых" ситуаций вы пропишете, тем меньше будет багов на этапе приемки.

Как составить техническое задание на сайт: чек-лист подготовки

Перед тем как открывать пустой документ, соберите вводные данные. Вам понадобятся:

• Текущая архитектура сайта (на какой CMS работает, какие плагины установлены).
• Список необходимых полей для новых форм.
• Скриншоты или прототипы (хотя бы схематичные наброски от руки).
• Список API-методов, если вы планируете связывать сайт с внешними сервисами.

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

Важно понимать, что качественный пример ТЗ на доработку сайта всегда содержит описание "негативных сценариев". Это инструкции о том, как система должна реагировать на некорректные действия пользователя. Если вы об этом не напишете, разработчик сделает "счастливый путь" (happy path), где всё работает идеально, а на любом реальном отклонении сайт просто выдаст ошибку 500 или зависнет.

Описание бизнес-логики и интеграции с CRM

Доработка функционала сайта ТЗ без раздела об интеграции - это работа в пустоту. Сайт сегодня - это не просто витрина, а сложный узел сбора данных. Если пользователь заполнил форму, эти данные должны не просто падать на почту, а бесшовно попадать в вашу CRM (Bitrix24, amoCRM или самописную систему). При этом важно описать не только факт передачи, но и то, как именно данные должны быть распределены.

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

Сценарии передачи данных в CRM

При постановке задачи на интеграцию, разделите процессы на три типа:

1. Создание новой сделки/лида: когда данные пользователя полностью новые.
2. Обновление существующей карточки: когда пользователь вернулся на сайт и заполнил форму повторно.
3. Событийная интеграка: когда действие на сайте (например, скачивание прайс-листа) должно поднять текущую сделку в CRM по определенному статусу.

Также не забудьте про обратную связь. Если CRM меняет статус заказа, должен ли сайт как-то отреагировать? Например, отобразить новый статус в личном кабинете пользователя. Если вы не заложите это в ТЗ, вы получите одностороннюю систему, где сайт "отдает" данные, но "не слышит" изменений в бизнес-процессах компании.

Еще один критический нюанс - обработка очередей. Если на сайт придет резкий всплеск трафика (например, после рекламной кампании), ваша интеграция должна выдержать нагрузку. В ТЗ стоит указать требования к асинхронной передаче данных, чтобы при временной недоступности CRM сайт не "падал", а сохранял данные в буфер и отправлял их позже.

Новые требования к формам сбора персональных данных

Работа с данными в 2026 году требует предельной осторожности. Законодательство в области ПДн стало жестче, и то, что работало еще пару лет назад, сегодня может привести к огромным штрафам. Когда вы описываете требования к формам сбора данных 2026, вы должны ориентироваться не только на удобство пользователя (UX), но и на строгое соответствие ст. 18.1 Закона № 152-ФЗ.

Главное правило: любая форма, где есть поле "Имя", "Телефон" или "Email", автоматически становится точкой сбора персональных данных. Это значит, что под каждой такой формой должна быть ссылка на актуальную Политику обработки персональных данных. И эта политика должна быть доступна в один клик прямо с той страницы, где пользователь оставляет свои данные.

Важно также учитывать, что сбор данных должен быть целевым. Если вы собираете телефон для связи по поводу заказа, вы не имеете права автоматически подтягивать его в базу для маркетинговых рассылок без дополнительного подтверждения. В ТЗ это должно быть отражено как разделение типов данных: транзакционные (необходимые для выполнения обязательств) и маркетинговые (добровольные).

Не забывайте про cookie-уведомления. В 2026 году это уже не просто "всплывающее окошко", а полноценный инструмент управления приватностью. В ТЗ нужно прописать, как именно сайт должен уведомлять пользователя об использовании cookie и как он должен предоставлять возможность отказаться от определенных типов отслеживания (аналитических, рекламных), не блокируя при этом работу основного функционала сайта.

Как правильно внедрить раздельные согласия пользователей

С 1 сентября 2025 года правила игры изменились окончательно: согласие на обработку ПДн больше нельзя "прятать" внутри оферты или делать его частью общего согласия на использование сайта. Это критическая ошибка, которая в 2026 году является прямым нарушением закона. Теперь каждое согласие должно быть оформлено отдельно.

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

Тип согласия	Обязательность	Пример текста в ТЗ
Обработка ПДн	Обязательно	"Даю согласие на обработку персональных данных согласно Политике..."
Маркетинговая рассылка	Добровольно	"Я хочу получать новости и акции на email..."
Передача третьим лицам	Добровольно	"Согласен на передачу данных партнерам для доставки заказа..."

В ТЗ на доработку функционала сайта обязательно пропишите логику работы этих чекбоксов. Что происходит, если пользователь нажал "Отправить", но не поставил обязательный чекбокс ПДн? Система должна выдать понятную ошибку, а не просто не отправлять форму. А если пользователь отказался от маркетинга, но согласился на ПДн - форма должна уйти, а в CRM должен прийти флаг "маркетинг запрещен".

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

Технические требования к хранению данных в РФ

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

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

При проектировании архитектуры системы, учитывайте следующие пункты:

• Местоположение серверов БД (строго РФ).
• Шифрование каналов связи (SSL/TLS протоколы не ниже актуальных стандартов).
• Протоколы резервного копирования (бэкапы также должны храниться на территории РФ).
• Логирование доступа к персональным данным (кто, когда и зачем смотрел карточку клиента).

Часто компании пытаются обойти это правило, используя зарубежные SaaS-решения. Однако в 2026 году контролирующие органы смотрят на это очень внимательно. Если ваша архитектура подразумевает, что данные клиента летят напрямую в облако в Европе или США, минуя российские серверы - вы под ударом. В ТЗ нужно четко прописать маршрутизацию данных: Сбор (Сайт) -> Первичная обработка и хранение (РФ) -> Аналитика/Интеграция (в зависимости от типа данных).

Маркетинговые блоки и маркировка контента нейросетями

Маркетинговые инструменты на сайте постоянно эволюционируют, но вместе с ними растут и требования к их прозрачности. С 6 ноября 2026 года вступили в силу важные уточнения в законодательстве о рекламе: если в ваших рекламных материалах, баннерах или видеороликах на сайте использовался контент, созданный с помощью нейросетей, вы обязаны это прямо указывать. Это касается не только изображений, но и текстов, которые могут быть восприняты как экспертные мнения.

При подготовке ТЗ на доработку маркетинговых блоков, заложите возможность быстрой маркировки. Например, это может быть небольшая плашка или текстовая пометка "Контент создан при помощи ИИ" в углу баннера или в футере статьи. Это не только требование закона, но и вопрос доверия аудитории. Пользователь должен понимать, где он видит работу человека, а где - автоматизированную генерацию.

Кроме того, при внедрении новых рекламных форматов (pop-up, слайдеры, виджеты), проверяйте их на соответствие актуальным правилам маркировки рекламы. Любой блок, который продвигает конкретный товар или услугу стороннего бренда, должен иметь соответствующую идентификацию. В ТЗ это стоит зафиксировать как требование к "информационной чистоте" блоков: разработчик должен предусмотреть поле для вставки идентификатора рекламы (erid) в коде блока.

Также не забывайте про интеграцию с рекламными кабинетами. Если вы внедряете новые маркетинговые блоки, они должны корректно передавать события (events) в системы аналитики и рекламные сервисы. В ТЗ нужно описать, какие именно действия пользователя (клик по баннеру, просмотр видео, скролл до рекламного блока) должны триггерить отправку события, чтобы вы могли точно считать ROI каждой доработки.

Типичные ошибки при постановке задач разработчикам

Даже если вы стараетесь писать подробно, ошибки случаются. Самая распространенная - это "размытые формулировки". Фразы вроде "сделайте, чтобы работало быстро" или "интерфейс должен быть интуитивным" не являются техническими требованиями. Разработчик не может измерить "интуитивность". Вместо этого пишите: "время отклика страницы при загрузке формы не должно превышать 200 мс" или "пользователь должен совершить целевое действие не более чем за 3 клика".

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

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

Типичные ошибки можно сгруппировать в таблицу для быстрой проверки:

Ошибка	К чему приводит	Как правильно
Отсутствие сценариев ошибок	Сайт "падает" при неверном вводе данных	Прописать негативные сценарии (error handling)
Смешивание согласий	Штрафы от Роскомнадзора за нарушение 152-ФЗ	Раздельные чекбоксы для ПДн и маркетинга
Неполная логика интеграции	Потеря лидов из-за сбоев связи с CRM	Описать очереди, нормализацию и уведомления об ошибках
Игнорирование маркировки	Штрафы за немаркированную рекламу/ИИ	Добавить поля для маркировки в шаблоны блоков

Как проверить готовность функционала после внедрения

Приемка работы - это не просто просмотр сайта на мобильном телефоне. Это системный процесс, который должен быть прописан в ТЗ как этап тестирования. Если вы не заложили критерии приемки (Acceptance Criteria), вы не сможете аргументированно требовать исправления багов. Проверка должна проходить по трем направлениям: функциональность, безопасность и соответствие законодательству.

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

Во-вторых, проверка юридической чистоты. Это критично в 2026 году. Проверьте:

• Все ли обязательные чекбоксы работают?
• Можно ли прочитать Политику ПДн прямо из формы?
• Разделены ли согласия на ПДн и на рассылку?
• Есть ли маркировка на рекламных блоках и контенте, созданном ИИ?
• Соблюдается ли локализация (проверьте через инструменты разработчика, куда уходят запросы при отправке формы)?

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

Что запомнить:

• ТЗ должно содержать не только "как должно быть", но и "что делать, если что-то пошло не так".
• Согласия на ПДн и маркетинговые рассылки в 2026 году должны быть строго разделены и не могут быть предзаполнены.
• Все данные пользователей должны проходить первичную обработку на серверах внутри РФ.
• Любой контент, созданный нейросетями, должен иметь явную маркировку.
• Интеграция с CRM требует детального описания форматов данных и обработки ошибок связи.