Как составить ТЗ на сайт
Техническое задание на сайт — не формальность и не попытка заранее описать каждую кнопку. Это общий рабочий документ, который помогает заказчику и разработчику одинаково понимать цель проекта, границы работ, требования к содержанию и критерии готовности.
Хорошее ТЗ уменьшает количество спорных трактовок, но не должно превращаться в сотню страниц. Для большинства корпоративных сайтов достаточно последовательно ответить на семь групп вопросов: зачем нужен сайт, кто им будет пользоваться, какие страницы и функции нужны, откуда берутся материалы, с какими системами он связан, как должен выглядеть и по каким признакам работа считается принятой.
1. Начните с цели и измеримого результата
Первый раздел ТЗ должен объяснять бизнес-задачу. Формулировка «нужен современный сайт» не задаёт направления: современность нельзя проверить, а разные участники понимают её по-разному. Гораздо полезнее указать, какое действие должен совершить посетитель и что компания будет делать с результатом.
Например: получать заявки на конкретные услуги, показывать портфолио, принимать запросы на расчёт, публиковать вакансии или давать клиентам доступ к документам. Для каждой цели обозначьте основной показатель — отправленная форма, звонок, запись, скачивание документа или вход в кабинет. Не обещайте заранее рост продаж: сайт влияет на результат вместе с трафиком, предложением и обработкой обращений.
Если проект заменяет существующий сайт, отдельно перечислите причины: неудобное управление, медленная загрузка, устаревшая структура, ошибки на телефонах или невозможность подключить нужные сервисы. Это позволит отличить обязательные задачи от пожеланий.
2. Опишите аудиторию и ключевые сценарии
Опишите две или три основные группы пользователей. Не нужны вымышленные биографии персонажей; достаточно задач, контекста и ограничений. Один посетитель ищет услугу с телефона и хочет быстро связаться, другой сравнивает подрядчиков с компьютера, третий уже стал клиентом и открывает документы в личном кабинете.
Для каждой группы запишите короткий путь: откуда человек приходит, что должен увидеть первым, какие сведения ему нужны для решения и какое действие завершает сценарий. Так становится понятно, где нужны цены, примеры работ, ответы на вопросы, форма, карта, фильтр или авторизация.
Сценарии помогают убрать лишние функции. Если элемент не поддерживает ни одну задачу пользователя и не нужен сотрудникам, его стоит вынести за рамки первой версии. А если важный шаг зависит от ручного ответа менеджера, это нужно указать сразу — иначе красивый интерфейс не решит проблему обработки заявок.
3. Зафиксируйте структуру и состав страниц
Составьте карту сайта: главная, страницы услуг, портфолио, о компании, контакты, блог и служебные страницы. Для каталога добавьте категории и карточки; для нескольких языков укажите, какие разделы переводятся и кто отвечает за переводы. Структура должна отражать реальные материалы, а не только пункты меню.
Для каждого типа страницы перечислите блоки и данные. Например, страница услуги может включать заголовок, краткое предложение, этапы работы, примеры, ответы на вопросы и форму. Карточка проекта — задачу, решение, технологии, изображения и ссылку. Такой перечень даёт разработчику понимание повторяющихся шаблонов и помогает точнее оценить объём.
До начала дизайна полезно подготовить материалы по чек-листу владельца бизнеса. Если часть контента появится позже, отметьте, какие страницы можно наполнить временно и кто заменит материалы перед публикацией.
4. Соберите функциональные требования
Функциональные требования описывают не внешний вид, а поведение системы. Для формы укажите поля, обязательность, проверку данных, сообщение после отправки, получателя заявки и место хранения. Для поиска — по каким данным он ищет. Для личного кабинета — роли, доступные разделы, статусы, файлы и действия пользователя.
Записывайте условия и результат: «после отправки заявка сохраняется, получает номер и передаётся менеджеру; при временной ошибке доставки данные не теряются». Это полезнее фразы «подключить CRM». Путь обращения от формы до менеджера подробно разобран в статье о передаче и контроле заявок.
Не забудьте о сообщениях об ошибках, пустых состояниях, ограничениях загрузки файлов, защите от повторной отправки и правах доступа. Также укажите, какие действия выполняет администратор сайта: редактирует страницы, меняет статусы, экспортирует данные или управляет пользователями.
5. Перечислите материалы, интеграции и доступы
Сделайте таблицу контента: текст, фотографии, логотипы, документы, цены, юридические данные и переводы. Напротив каждого пункта назначьте ответственного и срок. Если разработчик должен редактировать или создавать материалы, это отдельная работа, которую нужно включить в оценку.
Интеграции перечисляйте с направлением обмена: сайт передаёт заявки в CRM, получает товары из учётной системы, отправляет уведомления в Telegram или показывает доступность из внешнего календаря. Укажите владельца каждой системы, наличие документации и тестового доступа. Не передавайте постоянные пароли в самом ТЗ — доступы выдаются отдельно и с минимальными правами.
Заранее зафиксируйте, кому принадлежат домен, хостинг, аналитика, почта, репозиторий и сторонние кабинеты. Это защищает проект от зависимости от личного аккаунта одного сотрудника или подрядчика.
6. Определите требования к дизайну и адаптивности
Вместо расплывчатого «сделать красиво» приложите два или три примера и подпишите, что именно в них подходит: плотность, навигация, подача кейсов, анимация или цвет. Отдельно перечислите элементы фирменного стиля — логотип, палитру, шрифты и правила использования.
Определите приоритетные размеры экранов и поведение сложных блоков на телефоне. Адаптивность — не уменьшенная настольная версия: меню, таблицы, формы, карточки и заголовки должны оставаться удобными без горизонтальной прокрутки и неестественных переносов.
Укажите требования к доступности, контрасту, читаемости, клавиатурной навигации и подписям к изображениям, если они важны для проекта. Анимации должны поддерживать смысл и не мешать чтению. После реализации проверяйте не только скриншот, но и реальные состояния: длинные заголовки, ошибки формы, пустые списки и медленную сеть.
7. Согласуйте этапы, проверку и поддержку
Разделите работу на этапы: прототип, дизайн, разработка, наполнение, тестирование и публикация. Для каждого этапа определите результат, формат согласования и ответственного со стороны заказчика. Также договоритесь, как фиксируются изменения после утверждения — иначе новые пожелания незаметно расширят объём проекта.
Критерии приёмки должны быть проверяемыми: страницы открываются по согласованной структуре, формы доставляют тестовые заявки, роли не видят чужие данные, изображения имеют подписи, а мобильные версии не выходят за ширину экрана. Перед запуском используйте технический чек-лист сайта.
Отдельно опишите гарантийный период и дальнейшее сопровождение: обновления, резервные копии, мониторинг, исправления и время реакции. Поддержка после запуска — самостоятельный процесс, а не неограниченное продолжение разработки.
Практический чек-лист перед передачей ТЗ
Перед отправкой разработчику проверьте ТЗ по короткому списку:
- цель сайта и главное действие посетителя;
- аудитории и ключевые пользовательские пути;
- карта сайта и состав повторяющихся страниц;
- формы, кабинеты, поиск, уведомления и роли;
- источники контента и ответственные за материалы;
- интеграции, владельцы аккаунтов и порядок выдачи доступов;
- референсы, фирменный стиль и мобильные требования;
- этапы, критерии приёмки и правила изменения объёма;
- условия публикации и дальнейшей поддержки.
После этого запросите оценку по этапам и проверьте, что в неё входят все обязательные работы. Дополнительные ориентиры есть в статье о прозрачной оценке разработки. Заполнить бриф на разработку сайта — поможем превратить исходные пожелания в понятный план проекта.
Как проверить готовое ТЗ
Хороший способ проверить, как составить ТЗ на сайт, — передать документ человеку, который не участвовал в обсуждениях. Если он понимает цель, границы работ, роли и критерии приёмки без устных пояснений, документ пригоден для оценки.
Перед согласованием сверьте требования с рекомендациями W3C по доступности веб-интерфейсов. Это помогает заранее учесть контраст, клавиатурную навигацию и понятные подписи, а не исправлять их после запуска. Так практический ответ на вопрос, как составить ТЗ на сайт, превращается в проверяемый план, а не в список пожеланий.
