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