Техническое задание на сайт: что писать, с образцом структуры
Техническое задание описывает, что должно получиться и как это проверить. Оно нужно в первую очередь заказчику: без него приёмка превращается в спор о том, что подразумевалось. Бриф — это исходные данные о бизнесе, прототип — схема экранов, ТЗ — обязательства.
Структура: девять разделов
- Цель и задачи. Зачем сайт: продавать, собирать заявки, поддерживать текущих клиентов. Без этого раздела остальные превращаются в список хотелок.
- Аудитория и сценарии. Кто приходит и что должен сделать: подобрать, сравнить, рассчитать, оставить заявку.
- Структура и типы страниц. Разделы, шаблоны, что общего и что отличается.
- Функции. Каталог, фильтры, калькулятор, личный кабинет, формы — по каждой описано поведение, а не название.
- Контент. Кто пишет тексты и готовит фото, в какие сроки, в каком объёме.
- Интеграции. CRM, учётная система, оплата, аналитика, коллтрекинг. С указанием, кто даёт доступы.
- Технические требования. Платформа, адаптивность, скорость, требования к безопасности и резервным копиям.
- Требования к передаче. Что передаётся: доступы, исходники, инструкция, права.
- Порядок приёмки. Как проверяется каждый пункт и что считается сделанным.
Формулировки, которые снимают споры
| Плохо | Хорошо | Почему |
|---|---|---|
| Современный дизайн | Макеты трёх типовых страниц, согласованные до вёрстки | «Современный» не проверяется |
| Быстрый сайт | Показатели скорости на трёх шаблонах не хуже заданных | Есть измеримый критерий |
| Удобный каталог | Фильтры по перечисленным параметрам, комбинации сохраняются в адресе | Понятно, что делать и как проверить |
| Интеграция с 1С | Обмен товарами, ценами и остатками по расписанию, заказы — сразу | Определён состав и режим обмена |
Что забывают почти всегда
- Кто отвечает за контент. Проект встаёт не на разработке, а на ожидании текстов и фотографий.
- Что происходит после запуска. Гарантия, сроки исправления ошибок, условия поддержки.
- Права и доступы. Кому принадлежит домен, хостинг, аккаунты аналитики.
- Сохранение адресов. Если сайт заменяет старый, нужны редиректы: иначе накопленные позиции теряются.
Когда ТЗ можно упростить
Для лендинга из одного экрана подробное ТЗ избыточно: хватит прототипа и списка блоков. Полный документ оправдан там, где есть каталог, интеграции или личный кабинет — то есть где ошибка стоит недели работы.
Мы составляем ТЗ как отдельный этап разработки: он же становится основой сметы. Как принимать готовую работу — в материале о поддержке сайта и стоимости разработки.
Спор на приёмке почти всегда упирается в одну фразу: «мы имели в виду другое». ТЗ — это документ, который заранее переводит «имели в виду» в проверяемые пункты.