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