Аудит отвечает, что происходит и какие проблемы приоритетны; техническое задание описывает, что именно должен реализовать исполнитель и как проверить результат. Одной рекомендации из аудита часто недостаточно для однозначной разработки.
Содержание статьи
Аудит фиксирует проблему, подтверждает её и расставляет приоритеты. Техническое задание описывает решение: где изменить сайт, как он должен работать и по каким критериям принимать результат. Между этими этапами есть проектирование, оценка и согласование.
Заказчик получает большой отчёт, передаёт его разработчику и ожидает оценку внедрения. Разработчик задаёт десятки уточняющих вопросов: какие страницы менять, какое поведение считать правильным, что делать на мобильных устройствах и кто утвердит тексты. Кажется, что аудит оказался бесполезным, хотя проблема может быть в ожиданиях от документа.
Разберём, какой результат нужен от каждого этапа, что можно объединить в одну работу и где возникают лишние согласования. Это поможет выбрать услугу под текущую задачу и договориться с исполнителем до начала проекта.
На какие вопросы отвечает аудит
Аудит — исследование текущего состояния сайта. Он нужен, чтобы увидеть ограничения, отделить подтверждённые проблемы от предположений и определить разумную последовательность работ. Объём зависит от задачи: первичная диагностика одной группы страниц и глубокое обследование большого каталога требуют разной глубины.
В качественном отчёте полезно искать четыре элемента:
- Наблюдение. Что именно найдено: страница, шаблон, ответ сервера, интерфейс или данные аналитики.
- Подтверждение. На чём основан вывод: примеры URL, проверка, скриншот, выгрузка или повторяемый сценарий.
- Влияние. Почему проблема важна именно этому бизнесу и что ограничивает.
- Приоритет. Что исправлять сначала и от каких условий зависит следующий шаг.
Большое количество строк само по себе не делает отчёт содержательным. Автоматический сканер может обнаружить повторяющиеся симптомы, но выбор решения требует контекста продукта, структуры и возможностей CMS.
Что добавляет техническое задание
ТЗ переводит выбранное решение в требования для исполнителя. Оно описывает не только желаемый итог, но и конкретное поведение страницы или функции. Часть требований относится к SEO, часть — к интерфейсу, данным, интеграциям или аналитике.
- Цель изменения и границы задачи.
- Страницы, шаблоны, компоненты и состояния, которых касается работа.
- Текущее поведение и ожидаемое поведение после внедрения.
- Правила для мобильной версии и пограничных случаев.
- Данные, тексты, макеты и зависимости от других задач.
- Проверяемые критерии приёмки.
ТЗ не обязано быть огромным. Для небольшой правки достаточно короткой однозначной постановки. Если затронуты корзина, фильтры и интеграции, детализация должна помогать управлять сложностью, а не прятать её за общей фразой "сделать удобно".
Аудит и ТЗ: сравнение результата
| Критерий | Аудит | Техническое задание |
|---|---|---|
| Главный вопрос | Что мешает результату и чем это подтверждено? | Что именно изменить и как принять работу? |
| Отправная точка | Текущее состояние сайта и задача бизнеса | Согласованная проблема и выбранное решение |
| Типовое содержание | Находки, примеры, влияние, приоритеты | Логика, состояния, требования, зависимости, проверки |
| Для кого | Собственник, маркетолог, руководитель проекта | Разработчик, дизайнер, контент-специалист, проверяющий |
| Критерий полезности | Понятно, что важно и почему | Понятно, что делать и какой результат считать выполненным |
Пример: что делать с дублями страниц
В аудите можно обнаружить, что один товар доступен по нескольким URL и это мешает однозначно работать с его адресами. Дальше нужно выбрать решение с учётом CMS, истории сайта, фильтров и внутренней навигации. Само наблюдение ещё не описывает весь объём разработки.
В отчёте
У одной товарной карточки найдены несколько адресов. Приведены примеры, показаны внутренние ссылки и предложено согласовать основной URL.
В техническом задании
- Перечислить затронутые шаблоны и типы адресов.
- Зафиксировать правило формирования основного URL.
- Описать необходимые изменения внутренних ссылок и других сигналов.
- Указать, как обрабатывать существующие альтернативные адреса.
- Проверить ссылки из каталога, поиска, избранного и корзины, если они есть.
Конкретная реализация зависит от проекта. Выбирать один и тот же способ для всех дублей без обследования неправильно. Вначале нужно понять историю адресов, внутренние связи и сценарии использования, затем согласовать решение и составить проверку для затронутых шаблонов.
Пример: форма заявки и мобильная версия
Фраза "форма неудобная" не помогает разработчику оценить работу. Сначала нужно воспроизвести проблему: на какой ширине экрана, после какого действия и с какими данными пользователь не может завершить обращение.
Для ТЗ важно описать:
- какие поля видит пользователь и какие из них обязательны;
- какие форматы ввода допускаются и как работает проверка;
- как выглядят ожидание, успешная отправка и ошибка;
- что происходит при повторном нажатии;
- куда отправляются данные и когда заявка считается принятой;
- как окно открывается, закрывается и управляется с клавиатуры;
- какие состояния проверяются на мобильном экране.
Такая постановка связывает интерфейс с реальным сценарием. Иначе можно получить аккуратную кнопку, которая меняет цвет, но не приводит к принятой заявке.
Где заканчивается SEO-ТЗ и начинается комплексное
SEO-ТЗ может касаться индексации, метаданных, внутренних ссылок, шаблонов страниц и других поисковых требований. Если задача затрагивает выбор комплектации, логику цены, оформление заказа или интеграцию с внешней системой, понадобится описание более широкого пользовательского и технического поведения.
Комплексное ТЗ объединяет согласованные требования SEO, GEO, UX и технической части. Оно должно показывать, где эти требования связаны, а где решения независимы. Например, новая структура услуг влияет и на навигацию, и на содержание, и на адреса страниц.
При этом не каждое изменение стоит расширять до большого проекта. Иногда достаточно короткого задания на один шаблон и понятного чек-листа проверки.
Как согласовать объём и избежать двойной работы
До начала полезно зафиксировать, какие материалы уже есть, можно ли им доверять и чего в них не хватает. Если проведён свежий аудит с исходными данными, не нужно без объяснения повторять те же проверки. Но проектирование решения и описание состояний интерфейса могут потребовать отдельного времени.
- Соберите действующие отчёты, доступы, макеты и ограничения CMS.
- Согласуйте перечень задач, которые переходят из аудита в ТЗ.
- Уточните, кто принимает спорные решения и предоставляет материалы.
- Разделите подготовку документа, разработку и проверку внедрения.
- Зафиксируйте формат изменений после утверждения.
Стоимость документа разумно оценивать по глубине и объёму задачи, а не только по числу страниц. Одно сложное правило работы фильтра может требовать больше проработки, чем несколько простых исправлений текста.
Как принимать ТЗ и внедрение
Само ТЗ принимают по полноте и однозначности требований. Внедрение — по фактическому поведению сайта. Это две разные проверки. До разработки полезно убедиться, что исполнитель понимает задачу и может назвать зависимости и ограничения.
- У каждого требования есть конкретный объект изменения.
- Указаны важные состояния и исключения.
- Критерии можно проверить действием, запросом или просмотром данных.
- Понятно, что входит в текущий этап и что перенесено дальше.
- После публикации проверяется рабочий сайт, а не только тестовый стенд.
Например, требование "страница должна хорошо открываться" расплывчато. Проверяемая постановка указывает конкретные адреса, ожидаемый ответ сервера, элементы страницы и отсутствие описанной ошибки в согласованных условиях.
Что выбрать в вашей ситуации
| Ситуация | Подходящий первый шаг |
|---|---|
| Неясно, почему сайт не даёт ожидаемого результата | Диагностика и приоритеты в аудите |
| Проблема подтверждена, но разработчику не хватает требований | Техническое задание на выбранное изменение |
| Нужна новая структура запросов и посадочных страниц | Семантическое ядро и карта структуры |
| Планируется большой редизайн с изменением сценариев | Обследование и комплексное ТЗ с этапами внедрения |
Если сомневаетесь, полезно начать с короткого обсуждения задачи. Хороший результат такого разговора — понятный следующий шаг и состав работ, который можно проверить.
Как рекомендация превращается в задачу разработки
Фраза «наладить индексацию фильтров» подходит для направления исследования, но не для оценки разработки. В ТЗ нужны перечень разрешённых посадочных страниц, правила адресов и ссылок, поведение пустых сочетаний, canonical и sitemap, исключения и примеры проверки. Отдельно задают, как редактор будет управлять новыми посадочными страницами. Только после этого разработчик может оценить решение, а заказчик — принять его без спора о смысле общей рекомендации.
Переносите в ТЗ подтверждённую проблему, выбранный способ решения, требования к интерфейсу и данные для приёмки. Если есть несколько допустимых вариантов, сначала согласуйте выбор, а не оставляйте его скрытой догадкой исполнителя. Для интеграций указывайте источник данных, формат, ошибки и ответственную систему. Для SEO-правок сохраняйте исходный URL и проверяемое конечное состояние. По завершении разработки нужен контроль внедрения: наличие документа не означает, что сайт изменился.
| Ситуация или объект | Что проверяем / решение | Критерий |
|---|---|---|
| Аудит | Проблема и доказательство | Почему задача нужна |
| Проектирование | Выбор решения | Какой вариант согласован |
| ТЗ | Требования и исключения | Что должен сделать исполнитель |
| Приёмка | Сценарий проверки | Как подтвердить результат |
Что проверить на практике
- Не путать исследование и внедрение.
- Проверить достаточность примеров для разработчика.
- Согласовать спорные решения до оценки.
- Назначить владельца проверки на опубликованном сайте.
Частый вопрос
Нужно ли всегда заказывать отдельное ТЗ после аудита?
Нет. Простое исправление может быть достаточно описано в карточке находки. Отдельная проработка нужна, когда есть несколько сценариев, изменения шаблонов, интеграции или неоднозначные критерии результата.