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

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

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

Зачем нужно ТЗ на доработку сайта

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

Документ особенно важен, если сайт уже работает, а его код создавался разными подрядчиками. На проекте могут быть нестандартные модули, старые интеграции, ограничения CMS, подключённые системы аналитики и скрытые зависимости между страницами. Изменение одного элемента иногда влияет на формы, корзину, мобильную версию или поисковую индексацию.

• Владелец бизнеса получает понятный объём работ и может сравнивать предложения подрядчиков по одинаковому заданию.
• Менеджер проекта понимает приоритеты, границы ответственности и порядок согласований.
• Разработчик видит входные данные, ограничения и критерии готовности, а не пытается угадывать ожидания заказчика.
• Маркетолог может заранее проверить, не повредит ли изменение заявкам, аналитике и поисковому трафику.

Хорошее ТЗ отвечает на четыре вопроса: что меняем, зачем это нужно, как должно работать и как проверить результат.

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

С чего начать подготовку задания

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

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

Опишите исходную ситуацию

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

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

Сформулируйте цель

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

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

Как описать задачу понятным языком

Каждую доработку удобно оформлять отдельным блоком. В нём должны быть название задачи, текущая ситуация, требуемое изменение, страницы и роли пользователей, ограничения, материалы и критерии приёмки.

Пишите сценарий от лица пользователя: «Посетитель открывает страницу услуги, выбирает вариант, заполняет обязательные поля и нажимает кнопку. Если телефон введён неверно, форма показывает понятное сообщение и не отправляет данные». Такой формат помогает увидеть пропущенные состояния и не ограничиваться описанием внешнего вида.

Разделяйте обязательное и желательное

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

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

Какие разделы включить в ТЗ

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

1. Общие сведения. Адрес проекта, назначение сайта, CMS, окружение, контактные лица и ожидаемые сроки.
2. Цели и приоритеты. Какая проблема решается, что входит в первый этап, а что остаётся за рамками текущей задачи.
3. Описание текущей версии. Ссылки на страницы, существующее поведение, найденные ошибки и важные ограничения.
4. Функциональные требования. Что должен делать пользователь, администратор, менеджер или другой участник процесса.
5. Требования к интерфейсу. Состав блоков, состояния элементов, тексты сообщений, правила для мобильных экранов и особенности отображения.
6. Интеграции и данные. Какие письма, записи в CRM, платежи, файлы и события аналитики должны передаваться.
7. Поисковая оптимизация. Что происходит с адресами страниц, заголовками, метаданными, внутренними ссылками и индексацией.
8. Проверка и приёмка. Список сценариев, тестовые данные, допустимые ограничения и порядок исправления замечаний.

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

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

Как описать требования к функциям

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

Пример задания для формы

• Форма размещается на странице услуги и открывается также в модальном окне по кнопке «Получить расчёт».
• Обязательные поля: имя и телефон. Поле для комментария необязательное.
• Телефон проверяется по заданному формату, пустое или некорректное значение не отправляется.
• После успешной отправки пользователь видит сообщение о получении заявки и не отправляет её повторно случайным нажатием.
• Менеджер получает письмо с адресом страницы, названием услуги и параметрами рекламного источника, если они были переданы.
• Событие отправки фиксируется в системе аналитики только после успешного ответа сервера.

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

Опишите состояния интерфейса

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

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

Что учесть в дизайне и мобильной версии

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

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

Не перегружайте ТЗ точными значениями отступов, если вы не разрабатываете макет самостоятельно. Достаточно определить назначение блока, порядок элементов, обязательные состояния и ограничения. Конкретные размеры исполнитель уточнит в макете или прототипе, согласованном до программирования.

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

SEO, аналитика и интеграции в задании

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

Для новых элементов укажите, какие данные должны быть доступны поисковым системам, а какие предназначены только для посетителя. Например, фильтр может менять видимые товары без создания отдельных адресов, либо каждая комбинация фильтра может иметь собственную страницу. Это разные задачи по объёму и последствиям.

Проверьте аналитику

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

Если сайт связан с CRM, почтой, телефонией, складом, платёжным сервисом или системой доставки, опишите направление обмена данными. Важно указать обязательные поля, правила обработки дублей, реакцию на ошибку и ответственное лицо, которое проверит результат. Фраза «подключить CRM» не заменяет требования к передаваемым данным.

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

Как оценить сроки, бюджет и порядок работ

Точную стоимость нельзя надёжно определить только по числу страниц. На неё влияют состояние кода, CMS, наличие готового дизайна, количество ролей, интеграции, требования к тестированию и необходимость переносить данные. Поэтому подрядчик должен изучить сайт и уточнить задачу перед расчётом.

По рынку небольшая правка без изменения логики может занимать от нескольких часов до 2-3 рабочих дней. Изменение формы, каталога или шаблона страницы часто занимает от 3-10 рабочих дней. Сложные интеграции, личный кабинет и доработка магазина могут потребовать от 2-6 недель, особенно если нужны макеты, обмен с внешними системами и полноценное тестирование.

Это ориентиры для типичного проекта, а не готовая смета. В коммерческом предложении должны быть разделены работы, материалы заказчика, тестирование, публикация и последующие изменения. Для оценки услуг студии RDMN точная смета формируется после брифа, актуальные направления и условия собраны на странице цен на услуги студии.

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

Как принимать выполненную доработку

Критерии приёмки должны быть проверяемыми. «Сделано красиво» или «работает быстро» не позволяют однозначно принять результат. Лучше описать конкретное поведение, страницы, устройства и данные, на которых проходит проверка.

• Все обязательные сценарии из ТЗ выполнены на тестовом стенде или рабочем сайте по согласованной процедуре.
• Форма не отправляется с пустыми обязательными полями и показывает понятные сообщения об ошибках.
• Успешная заявка приходит в согласованный канал, а данные не теряются и не дублируются без причины.
• Новая функция корректно работает в актуальных версиях основных браузеров и на мобильном устройстве.
• После публикации сохраняются нужные адреса страниц, метаданные, события аналитики и доступы администратора.
• Ошибки, найденные при проверке, фиксируются в общем списке с приоритетом и статусом исправления.

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

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

Типичные ошибки при подготовке ТЗ

Описание только желаемого внешнего вида

Фраза «сделать современно и удобно» оставляет слишком много трактовок. Дизайн должен помогать решать конкретную задачу: показать условия, довести до заявки, упростить выбор или снизить число вопросов менеджеру. Укажите сценарий и критерии, а визуальные решения согласуйте в макете.

Смешение задач разных специалистов

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

Отсутствие границ проекта

Если не указать, какие страницы и функции входят в задачу, список требований будет расти уже в процессе. Добавьте раздел «не входит в работу» и правило для новых пожеланий. Дополнительные задачи можно оценивать отдельно, не меняя первоначальные договорённости задним числом.

Игнорирование старого кода

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

Нет ответственного за решение

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

Приёмка только на компьютере

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

Частые вопросы

Можно ли составить ТЗ самостоятельно?

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

Нужно ли писать в ТЗ конкретный способ реализации?

Обычно нет. Заказчику важно зафиксировать требуемое поведение и ограничения, а исполнитель подбирает способ реализации с учётом CMS и текущего кода. Исключение составляют обязательные технологии или правила инфраструктуры, которые действительно заданы заранее.

Что делать, если я не знаю причину проблемы?

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

Нужно ли включать в ТЗ дизайн-макеты?

Если меняется интерфейс, макет или прототип значительно сокращает число разночтений. Но макет не заменяет функциональное описание. В документе всё равно нужно указать состояния, поведение формы, адаптацию для телефона и связь с данными.

Как понять, что доработка не повредит SEO?

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

Как оформить ТЗ, если сайт делает несколько подрядчиков?

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

Что делать: короткий план

1. Соберите список проблем сайта и подтвердите каждую ссылкой, скриншотом или примером обращения клиента.
2. Для каждой проблемы определите цель, пользователя, желаемый результат и приоритет.
3. Опишите текущий сценарий, будущую логику, поля, состояния, сообщения и исключения.
4. Укажите страницы, устройства, роли, интеграции, аналитику и ограничения CMS.
5. Приложите тексты, изображения, таблицы, макеты, тестовые данные и доступы, необходимые для работы.
6. Разделите обязательные задачи и дополнительные пожелания, отдельно обозначьте то, что не входит в этап.
7. Согласуйте критерии приёмки, порядок тестирования, сроки обратной связи и ответственных лиц.
8. Передайте ТЗ подрядчику для технического осмотра, уточнений и расчёта. До начала работ зафиксируйте состав, сроки и порядок согласования изменений.
9. После запуска проверьте основные пользовательские сценарии, заявки, интеграции, мобильную версию, аналитику и поисковые адреса.

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

Полезные страницы по теме

• Создание сайтов под ключ