Зачем нужно ТЗ, если уже есть бриф
Бриф и техническое задание решают разные задачи. Бриф собирает контекст: чем занимается компания, кто её клиенты, что уже пробовали и почему это не сработало. ТЗ описывает результат, который можно проверить: что сайт должен делать и по каким признакам вы поймёте, что он готов.
Если этот шаг пропустить, подрядчик будет опираться на собственное представление о задаче. Оно расходится с вашим обычно не из-за недобросовестности, а в деталях: сколько форм на странице, куда уходят заявки, что показывать, если товара нет в наличии, нужен ли раздел с документами.
Простой признак плохого ТЗ: по нему нельзя составить список проверок. Если из документа не следует, что именно вы будете открывать и нажимать при приёмке, работа над ТЗ не закончена.
Раздел о задаче: результат вместо прилагательных
Первый раздел отвечает на вопрос, что должно измениться после запуска. Формулировка «нужен современный сайт, чтобы повысить доверие» не проверяется никак. Формулировка «посетитель находит услугу, видит состав работ и стоимость, оставляет заявку с контактом» проверяется: можно открыть сайт и пройти этот путь целиком.
К задаче добавьте, где будет виден результат. Заявка с формы должна оказаться в CRM и в отдельном списке, переход в мессенджер — считаться событием, звонок — фиксироваться. Это требование к измеримости, а не обещание роста: вы фиксируете, как будете смотреть на факты.
Отдельным пунктом перечислите, чего в первой версии не будет. Список «не делаем» экономит больше времени, чем список пожеланий: он снимает ожидание, что «раз мы платим, то и это тоже войдёт».
Пользователи и сценарии
Перечислите роли, которые будут работать с сайтом: новый посетитель, клиент с повторным заказом, менеджер, редактор. Для каждой роли достаточно двух-трёх сценариев от входа до результата. Лишние роли в ТЗ не нужны — они увеличивают объём без пользы.
Сценарий описывают шагами, включая неудачные ветки. Что видит человек, если форма не отправилась, фильтр не дал результатов, оплата не прошла, а он вернулся на следующий день. Именно эти ветки чаще всего остаются недоделанными, потому что о них не договорились заранее.
- Откуда человек пришёл: поиск, реклама, ссылка из письма, повторный визит
- Что он делает: ищет, сравнивает, заказывает, скачивает документ
- Какие данные вводит и какие из них обязательны
- Что получает в результате: заявку, счёт, письмо, доступ
- Что видит при ошибке и куда может обратиться
- Кому уходит уведомление и в каком виде
Структура и контент: кто за что отвечает
Перечень страниц в ТЗ — не список ради количества, а таблица: адрес, задача страницы, тип шаблона, источник контента, ответственный. Без ответственного за текст работа встаёт на этапе вёрстки, когда выясняется, что подставлять в макет нечего.
Определите заранее, кто пишет тексты и кто их согласовывает. Если тексты готовит подрядчик, это отдельный объём работ и он должен быть в договоре. Если вы — назовите дату, к которой материалы будут готовы, иначе старт съедается ожиданием, а виноватым оказывается разработчик.
Для каталога и магазина добавьте, сколько характеристик у товара и какие обязательны, что делать с позициями без фото и описания. Это влияет сразу на три вещи: дизайн карточки, шаблон импорта и правила фильтрации.
Данные и интеграции
Самая частая причина споров после запуска — состав данных заявки. Перечислите поля, их обязательность и формат: телефон, почта, согласие на обработку, комментарий, приложенный файл. Отдельно опишите, что происходит при отправке: письмо, запись в CRM, сообщение в мессенджер, дублирование в таблицу.
Интеграции описывают не названием системы, а задачей: какие данные, в какую сторону, как часто, кто источник истины. Для 1С важно уточнить предмет обмена: товары и цены, остатки, оформление заказов, статусы. От этого зависит объём работ, а не от версии конфигурации.
Проговорите, кто выдаёт доступы и тестовый контур. Проверять обмен на рабочей базе рискованно: ошибка в правилах создаёт лишние документы и движения, которые потом разбирать вручную.
- Систему и её версию, если версия влияет на способ обмена
- Направление обмена и систему-источник
- Набор передаваемых данных и обязательные поля
- Частоту: по событию или по расписанию
- Ключ сопоставления записей: артикул, код, идентификатор
- Что делать при расхождении и при недоступности системы
- Кто отвечает за доступы и тестовые данные
Критерии приёмки
Приёмка — это не «нравится или не нравится», а прохождение списка проверок. Чем конкретнее список, тем меньше эмоций в финале и тем проще доказать, что работа выполнена или не выполнена. Критерии пишут до старта: тогда подрядчик проектирует решение под них.
Проверки должны быть воспроизводимыми: не «сайт быстрый», а «страница открывается в мобильном профиле за отведённое время по оговорённой метрике». Не «удобно на телефоне», а «на экране 360 px нет горизонтальной прокрутки и обрезанного текста».
- Адаптив на 360, 768, 1280 и 1920 px без горизонтальной прокрутки
- Длинные заголовки, длинные названия товаров, цены с копейками
- Пустые состояния: нет результатов поиска, нет товаров в категории
- Ошибки форм: неверный телефон, пустое обязательное поле, сбой отправки
- Метатеги, заголовки, robots.txt и sitemap.xml на всех типах страниц
- Редиректы со старых адресов и корректная страница 404
- Доступы к админке, репозиторию и серверу переданы вам
- Инструкция для редактора и разбор одного типового изменения вместе с ним
Ошибки, из-за которых ТЗ не работает
Даже подробный документ может оказаться бесполезным, если в нём смешаны требования и пожелания. Требование проверяется, пожелание обсуждается. Когда они в одном списке, подрядчик выполняет те пункты, которые понял, а остальное всплывает на приёмке.
Вторая типичная ошибка — ТЗ, написанное без знания своих же процессов. Если вы не знаете, кто у вас обрабатывает заявки и в каком порядке, описание сценариев получится фантазийным, а интеграция — бесполезной.
- Список страниц без задач: понятно, сколько их, но не понятно, зачем каждая
- Требование «сделать как у конкурента» без объяснения, что именно нравится
- Отсутствие ответственного за контент и даты его готовности
- Технологии, навязанные до понимания задачи: «только так и никак иначе»
- Критерии приёмки, дописанные после сдачи работ
- Одна версия документа без истории изменений: непонятно, что и когда поменялось
- Объём на десятки страниц, в котором теряется главное — что сайт должен делать