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