Какие критерии приёмки обязательно добавить в техническое задание

01

Почему без критериев приёмки ТЗ не защищает результат

Техническое задание обычно отвечает на вопрос «что сделать»: добавить форму, каталог, личный кабинет или обмен с CRM. Но этой формулировки недостаточно для контроля результата. Разработчик может сделать форму, которая визуально похожа на макет, однако не передаёт источник обращения, допускает пустой телефон или создаёт лид без ответственного. Формально задача выполнена, для маркетинга и продаж — нет.

Критерий приёмки отвечает на другой вопрос: «по каким наблюдаемым признакам работа считается выполненной». В нём должны быть действие пользователя, исходные условия, ожидаемый результат и способ проверки. Не «интегрировать с CRM», а «после отправки формы “Получить расчёт” создаётся лид с телефоном, e-mail, страницей обращения, значениями UTM и ответственным из очереди отдела продаж».

Такой подход полезен не только при сдаче проекта. Он позволяет подрядчику точнее оценить объём, менеджеру — не потерять ограничения при передаче задачи, а заказчику — проверить критичные бизнес-сценарии до запуска рекламы. Для сайта на 1С-Битрикс это особенно важно: видимая страница, настройки инфоблоков, почтовые события и обработчик интеграции могут быть разными частями одной функции.

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

03

Соберите критерий вокруг бизнес-сценария, а не экрана

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

У сценария есть предусловия. Например, в CRM настроена воронка «Новые обращения», создана очередь менеджеров, а тестовый пользователь не авторизован. Затем указывается действие: посетитель открывает страницу услуги с параметрами рекламной кампании и отправляет форму. После этого фиксируются проверяемые результаты: сообщение на сайте, данные в CRM, уведомление, отсутствие дубля при повторной отправке.

Не смешивайте критерий с реализацией. Заказчику важно, что поле utm_source передаётся в карточку лида и сохраняется; использовать ли скрытое поле формы, cookie или обработчик на сервере — предмет проектирования. Но если бизнесу требуется конкретный механизм из-за ограничений безопасности или существующей архитектуры, его тоже надо прямо назвать.

04

Что обязательно проверить у форм, CRM и аналитики

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

Отдельно укажите состав данных, которые попадут в лид или сделку: NAME, PHONE, EMAIL, название формы, URL страницы, реферер, дата, utm_source, utm_medium, utm_campaign, utm_content, utm_term. Если используются пользовательские поля CRM, в ТЗ нужны их коды и правило заполнения, а не только человекочитаемые подписи.

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

06

Как зафиксировать приёмку интеграций и нестандартной логики

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

Для 1С-Битрикс полезно разделять интерфейсную проверку и техническую. Менеджер принимает, что товар, цена или статус заказа отображаются верно. Технический специалист дополнительно сверяет логи, очередь задач, HTTP-коды и отсутствие повторной обработки одного события. Если обмен основан на штатных механизмах, в документации 1С-Битрикс можно сверить терминологию и возможности интеграционных инструментов платформы.

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

1. 1

   Назовите объект. Заказ, товар, контакт, лид или документ — с идентификатором, по которому его можно найти в обеих системах.

2. 2

   Опишите направление. Укажите, какая система является источником и можно ли редактировать данные в получателе.

3. 3

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

4. 4

   Задайте время. Определите расписание обмена или максимальную задержку для события в реальном времени.

5. 5

   Проверьте отказ. Создайте контролируемую ошибку и убедитесь, что данные не исчезли, а ответственному пришло сообщение.

07

Нефункциональные требования тоже должны быть измеримыми

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

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

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

08

Приёмочный чек-лист: кто, где и чем проверяет

У критерия должен быть владелец проверки. Маркетолог принимает UTM, цели и содержимое писем; руководитель продаж — карточку лида, очередь и уведомления; контент-менеджер — редактирование материалов; технический специалист — логи, права, резервные копии и отсутствие ошибок. Когда владелец не указан, команда часто считает, что проверку выполняет кто-то другой.

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

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

09

Что включить в ТЗ до передачи в разработку

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

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

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