Техническое задание — это не бюрократия, а договорённость о том, что именно получит заказчик. Разбираем, из чего состоит рабочее ТЗ на сайт, кто его пишет и какие формулировки оборачиваются неделями переделок.
Зачем нужно ТЗ, если «и так всё понятно»
На первой встрече почти всегда кажется, что задача ясна: «нужен современный сайт с каталогом и формой заявки». Проблема в том, что у каждого участника в голове своя картинка. Директор представляет каталог на 40 позиций с красивыми фотографиями, менеджер по продажам — фильтр по 15 параметрам и выгрузку прайса, а маркетолог — блог и квизы. Пока эти картинки не записаны, они не сталкиваются. Сталкиваются они на приёмке, когда переделывать уже дорого.
По нашему опыту, в проектах без внятного ТЗ на доработки после «почти готового» сайта уходит от 20 до 40% исходного бюджета времени. Для проекта на три месяца это как раз тот самый потерянный месяц. Хорошее техническое задание не убирает изменения совсем — бизнес живёт, и требования меняются, — но переводит их из разряда «мы же имели в виду» в разряд осознанных решений с понятной ценой.
У ТЗ есть и вторая функция, о которой вспоминают реже: это документ для будущего. Через два года на сайт придёт новый маркетолог или другой подрядчик по поддержке, и первое, что ему понадобится, — описание того, как всё устроено и почему именно так.
Кто пишет техническое задание
Распространённое заблуждение — что ТЗ обязан принести заказчик. На практике у заказчика редко есть человек, который одновременно понимает бизнес-процессы, пользовательские сценарии и ограничения технологий. Поэтому рабочая схема выглядит так: заказчик приносит бриф и знание своего бизнеса, а подрядчик превращает это в техническое задание, задавая неудобные вопросы.
В нашей практике ТЗ пишет аналитик проекта при участии дизайнера и ведущего разработчика. Заказчик участвует в двух-трёх интервью, отвечает на вопросы в общем документе и согласует итоговую версию. На сайт-каталог средней сложности этот этап занимает обычно две-три недели. Важно, чтобы в интервью участвовал не только руководитель, но и люди, которые ежедневно отвечают клиентам: они лучше всех знают, какие вопросы задают покупатели и где сейчас теряются заявки.
Если вы всё же пишете ТЗ сами — например, чтобы разослать его нескольким подрядчикам и сравнить предложения, — не пытайтесь сделать его техническим. Опишите задачи, аудиторию, структуру и функции человеческим языком. Выбор CMS, архитектуры базы данных и способа интеграции лучше оставить тем, кто будет за это отвечать.
Из каких разделов состоит рабочее ТЗ
Универсального шаблона нет, но у хорошего технического задания на сайт почти всегда есть следующие разделы.
- Цели и метрики. Что должен делать сайт для бизнеса: приводить заявки от дилеров, снижать нагрузку на менеджеров, подтверждать статус компании на тендерах. Желательно с ориентиром: «не менее 60 заявок в месяц через полгода после запуска».
- Аудитория и сценарии. Кто приходит на сайт и зачем. Не «мужчины 25–45», а «снабженец, который сравнивает трёх поставщиков и ищет сертификаты».
- Структура. Карта разделов с уровнями вложенности и примерным количеством страниц каждого типа.
- Описание шаблонов страниц. Какие блоки есть на главной, в карточке товара, в разделе услуг. Именно здесь ТЗ связывается с прототипом.
- Функциональные требования. Формы, фильтры, поиск, личный кабинет, калькуляторы — с логикой работы, а не просто названием.
- Интеграции. 1С, CRM, системы аналитики, службы доставки: что с чем обменивается, как часто и в каком направлении.
- Административная часть. Что заказчик будет редактировать сам, какие роли нужны в админке.
- Нефункциональные требования. Скорость загрузки, поддерживаемые браузеры, адаптивность, требования к безопасности и хостингу.
- Контент. Кто и когда готовит тексты, фото, описания товаров, в каком объёме.
- Критерии приёмки. Как стороны поймут, что работа выполнена.
Последний пункт часто пропускают, и зря: именно он превращает спор «нравится — не нравится» в проверку по списку.
Как писать функциональные требования, чтобы их нельзя было понять двояко
Главная ошибка — описывать функцию одним словом. «Фильтр товаров» может означать три чекбокса и может означать зависимые фильтры с пересчётом количества, диапазонами и сохранением выбора в адресе страницы. Разница в трудоёмкости — в разы.
Рабочий приём — описывать каждую функцию через сценарий: кто, что делает, что видит в ответ и что происходит в исключительных случаях. Сравните две формулировки.
| Размыто | Проверяемо |
|---|---|
| Удобная форма заявки | Форма из 3 полей: имя, телефон или email (одно из двух обязательно), комментарий. После отправки — сообщение на странице и письмо на адрес отдела продаж, заявка передаётся в CRM с пометкой источника |
| Поиск по сайту | Поиск по названию и артикулу товара, подсказки после ввода 3 символов, учёт опечаток в одну букву, при нуле результатов — показ популярных категорий |
| Быстрая загрузка | Время загрузки главной и карточки товара на мобильном соединении — не более 3 секунд, показатели Core Web Vitals в «зелёной» зоне |
| Интеграция с 1С | Выгрузка из 1С каждые 2 часа: номенклатура, цены по трём типам, остатки по двум складам. Обратно — заказы с сайта в реальном времени |
Правая колонка длиннее, но именно она экономит время. По ней разработчик может оценить работу, а заказчик — проверить результат, не полагаясь на ощущения.
Типичные ошибки, которые стоят месяц переделок
Список пожеланий вместо приоритетов
ТЗ на 60 страниц, где всё одинаково важно, — плохой знак. Попросите аналитика разделить требования на три группы: без чего сайт не запускается, что нужно в первые три месяца после запуска и что «было бы здорово». В одном проекте для дистрибьютора стройматериалов такое разделение сократило первую очередь почти вдвое — и сайт вышел на шесть недель раньше, а вторая очередь запускалась уже с учётом реальной статистики.
Ссылка на чужой сайт как требование
«Сделайте как у конкурента» — не требование. Уточните, что именно нравится: подача каталога, скорость, конкретный блок на главной. Иначе дизайнер скопирует не то, а вы получите сайт, похожий на чужой.
Забытый контент
Самая частая причина сорванных сроков — не код, а тексты и фотографии. Если в ТЗ не записано, кто готовит 300 описаний товаров и к какой дате, это ляжет на заказчика в последний момент. Имеет смысл сразу заложить отдельный этап наполнения контентом или хотя бы график передачи материалов.
Нет владельца решения
Если со стороны заказчика согласовывают пять человек и ни у кого нет последнего слова, ТЗ будет переписываться бесконечно. Назначьте одного ответственного, который собирает мнения внутри компании и возвращает подрядчику единую позицию.
Совет студии: перед согласованием ТЗ пройдите его глазами трёх людей — нового клиента, постоянного клиента и сотрудника, который будет обрабатывать заявки. Если хотя бы для одного из них сценарий обрывается или непонятен, требование нужно дописать.
Как ТЗ связано с прототипом и сметой
Техническое задание и прототип хорошо работают в паре. Текст описывает логику и правила, прототип — расположение и приоритет блоков. Мы обычно ведём их параллельно: сначала согласовываем структуру и ключевые сценарии, затем рисуем схемы основных страниц, а уточнения, которые всплывают при прототипировании, возвращаем в ТЗ.
После согласования ТЗ становится основой для точной сметы. До этого любая оценка — это вилка, иногда с разбросом в полтора-два раза. После — у каждого пункта есть трудоёмкость, и можно осознанно решать, что перенести во вторую очередь, если бюджет ограничен. Ориентиры по стоимости разных типов проектов собраны на странице цен, но точная цифра появляется именно из ТЗ.
Отдельно договоритесь, как будут вноситься изменения после согласования. Рабочая практика — запрос на изменение с оценкой трудоёмкости и влияния на срок, который заказчик подтверждает письменно. Это не формализм: так обе стороны видят, почему проект подорожал или сдвинулся, и не спорят об этом на финише.
Чек-лист: готово ли ваше ТЗ
Перед тем как подписывать техническое задание, пройдитесь по списку. Если на какой-то вопрос нет ответа, лучше потратить ещё неделю сейчас, чем месяц потом.
- Записаны цели сайта и хотя бы один измеримый ориентир.
- Описаны 3–5 ключевых сценариев пользователей, а не только разделы меню.
- Есть карта структуры с количеством страниц каждого типа.
- Каждая функция описана через сценарий и исключения, а не одним словом.
- Для интеграций указаны системы, направление обмена, частота и состав данных.
- Понятно, что заказчик редактирует сам и какие для этого нужны роли.
- Зафиксированы требования к скорости, адаптивности и браузерам.
- Определено, кто готовит контент, в каком объёме и к какому сроку.
- Требования разделены по приоритетам: запуск, первые месяцы, потом.
- Есть критерии приёмки и порядок внесения изменений.
- Со стороны заказчика назначен один ответственный за согласование.
Хорошее ТЗ не обязано быть толстым. Для лендинга достаточно пяти страниц, для B2B-портала может понадобиться пятьдесят. Важен не объём, а то, что после чтения документа у заказчика и команды разработки в голове одна и та же картинка будущего сайта.
