Техническое задание на разработку сайта фиксирует, что именно создаёт команда, как должен работать результат и по каким признакам его можно принять. Оно помогает заказчику и исполнителю одинаково понимать границы проекта.
Хорошее ТЗ не обязано быть документом на сотню страниц. Его подробность зависит от сложности продукта. Для лендинга достаточно компактного описания структуры и функций, а для сервиса с ролями пользователей и интеграциями потребуется формальная спецификация.
Чем ТЗ отличается от брифа
Бриф собирает исходную информацию: чем занимается компания, кто её аудитория, какие задачи должен решить сайт, какие материалы и ограничения уже есть.
Техническое задание описывает согласованное решение. В нём появляются страницы, функции, состояния, интеграции и критерии готовности.
Упрощённо:
- бриф отвечает на вопрос «что мы знаем до начала работы»;
- исследование и проектирование помогают найти решение;
- ТЗ отвечает на вопрос «что именно мы договорились сделать».
Если исполнитель требует от заказчика самостоятельно придумать всю структуру и механику до знакомства с продуктом, важная часть проектной работы перекладывается на человека без нужного контекста.
Когда составлять техническое задание
Полностью фиксировать ТЗ до исследования не всегда возможно. Сначала стороны определяют цель и предварительный объём, затем уточняют структуру и только после этого детализируют решение.
Для проекта с высокой неопределённостью полезно разделить работу на этапы. Сначала провести аналитику и прототипирование, получить понятную архитектуру, а затем оценить дизайн и разработку.
Так смета опирается на реальные решения, а не на предположения, сделанные до знакомства с задачей.
Что включить в ТЗ на разработку сайта
1. Контекст и цель
В начале кратко описывается продукт и причина запуска проекта. Не нужно переносить в документ всю историю компании. Достаточно информации, которая влияет на решения.
Стоит зафиксировать:
- какую бизнес-задачу решает сайт;
- кто основная аудитория;
- какое действие является главным;
- какие проблемы есть у текущего решения;
- что не входит в проект.
Последний пункт особенно важен. Явные ограничения защищают от ситуации, когда участники подразумевают разный объём под одной формулировкой.
2. Состав страниц
Приводится карта сайта и назначение каждого типа страницы. Например: главная объясняет предложение, страница услуги раскрывает конкретное направление, кейс показывает процесс и результат, контактная страница собирает обращение.
Нужно отличать уникальные страницы от шаблонов. Если все статьи используют одну структуру, в ТЗ описывается шаблон статьи и способ добавления новых материалов.
3. Пользовательские сценарии
Сценарий описывает последовательность действий человека. Например:
- Пользователь открывает страницу услуги.
- Изучает условия и подходящие кейсы.
- Нажимает кнопку обсуждения проекта.
- Заполняет форму.
- Получает подтверждение отправки.
- Заявка поступает ответственному сотруднику.
Такое описание помогает увидеть не только экраны, но и состояния между ними.
4. Функциональные требования
Для каждой функции описывается ожидаемое поведение. Формулировка «добавить форму» недостаточна. Нужно определить поля, обязательность, валидацию, согласие на обработку данных, сообщение об успехе и способ доставки заявки.
К функциональным требованиям относятся:
- поиск и фильтры;
- формы;
- авторизация;
- личный кабинет;
- каталог;
- оплата;
- мультиязычность;
- интеграции;
- управление содержимым.
Не следует подробно диктовать технологию, если для бизнеса важен результат, а не конкретный инструмент. Исполнитель может предложить более простое и устойчивое решение.
5. Контент
В ТЗ фиксируется, кто готовит тексты, изображения, видео и юридические документы. Также полезно указать формат передачи и крайние сроки.
Если контент создаёт студия, нужно определить объём: редактура материалов заказчика, тексты с нуля, интервью, подбор изображений или организация съёмки.
Неопределённость в этом разделе часто задерживает проект сильнее разработки.
6. Дизайн и адаптивность
Вместо требования «сделать современно» лучше описать характер бренда, практические ограничения и критерии качества. Полезны примеры с пояснением, что именно в них подходит: типографика, плотность, движение или способ подачи продукта.
Нужно перечислить ключевые разрешения и состояния:
- десктоп;
- планшет, если для него требуется отдельная логика;
- мобильный экран;
- наведение и фокус;
- загрузка;
- пустые результаты;
- ошибка;
- успешное действие.
7. Технические требования
В этот раздел входят требования, влияющие на архитектуру и проверку:
- поддерживаемые браузеры;
- домен и хостинг;
- система управления содержимым;
- внешние сервисы;
- безопасность формы;
- резервное копирование;
- аналитика;
- производительность;
- доступность;
- техническое SEO.
Требование «100 баллов во всех тестах» может быть формальным и конфликтовать с реальной функциональностью. Лучше определить измеримые приоритеты: быстрая загрузка основного содержимого, отсутствие критических ошибок и работа ключевых сценариев.
8. SEO и миграция
Для нового сайта фиксируются title, description, canonical, sitemap, robots.txt и понятная структура заголовков.
При редизайне дополнительно нужен список старых URL. Страницы с накопленными поисковыми сигналами сохраняются или получают постоянные редиректы на релевантные новые адреса. После запуска проверяются ответы сервера и отсутствие случайного noindex.
9. Аналитика
Недостаточно просто установить счётчик. Нужно перечислить события, которые важны бизнесу: отправка формы, переход к контакту, просмотр тарифа, скачивание презентации или начало оформления.
События должны быть связаны с целью страницы. Тогда после запуска можно оценивать не только посещаемость, но и прохождение пользовательского пути.
10. Критерии приёмки
Критерии приёмки переводят пожелания в проверяемые условия. Например:
- все маршруты из карты сайта открываются;
- форма проверяет обязательные поля;
- после отправки появляется подтверждение;
- заявка приходит в согласованный канал;
- страницы корректно отображаются на указанных разрешениях;
- в коде присутствуют согласованные метаданные;
- старые URL перенаправляются по утверждённой таблице.
Субъективные оценки дизайна должны завершиться раньше — на этапе согласования концепции и макетов.
Что не стоит добавлять в ТЗ
Не нужно описывать каждую кнопку языком программной документации, если макет и прототип уже показывают её поведение. Дублирование создаёт риск противоречий.
Также вредны:
- требования без связи с задачей;
- случайный список технологий из чужого проекта;
- формулировки «и другие функции»;
- неограниченное количество правок;
- ссылки на референсы без пояснений;
- критерии, которые невозможно измерить.
ТЗ должно уменьшать неопределённость, а не создавать видимость полноты.
Короткий шаблон ТЗ
Для небольшого сайта можно начать со следующей структуры:
- О продукте и задаче.
- Аудитория и главное действие.
- Карта страниц.
- Сценарии.
- Функции и интеграции.
- Контент и ответственные.
- Дизайн и адаптивные состояния.
- Технические требования.
- SEO и аналитика.
- Критерии приёмки.
- Что не входит в проект.
Документ можно уточнять после прототипа. Главное — чтобы изменения были видны всем участникам и влияли на сроки и стоимость прозрачным образом.
Частые вопросы
Может ли студия подготовить ТЗ сама?
Да. Заказчик предоставляет факты о бизнесе и ограничениях, а студия переводит их в структуру, сценарии и требования. Это нормальная часть проектирования.
Нужно ли ТЗ для небольшого лендинга?
Нужна хотя бы компактная фиксация структуры, формы, адаптивных состояний, аналитики и состава работ. Название документа менее важно, чем одинаковое понимание результата.
Можно ли менять ТЗ во время разработки?
Можно, если изменения фиксируются и команда оценивает их влияние. Проблема возникает не из-за самого изменения, а когда новый объём считается частью прежней оценки без пересмотра сроков и стоимости.