Техническое задание на сайт: как превратить запрос бизнеса в задачу команды

Не превращайте бриф в анкету

Большая анкета может собрать историю компании, любимые цвета, конкурентов и список функций, но не дать команде приоритета. Проблема не в количестве вопросов. Проблема появляется, когда ответы никак не меняют решение по структуре, объему или приемке.

Я делю подготовку проекта на четыре документа. Они могут находиться в одном файле, но выполняют разную работу.

Если все смешать, гипотеза из брифа незаметно становится обязательной функцией, а идея на будущее - причиной задержки запуска. Сильное ТЗ не содержит максимум пожеланий: оно отделяет утвержденный объем от вопросов, допущений и будущих решений.

Начните с текущей точки

Запрос «нужен новый сайт» описывает средство, а не проблему. Перед обсуждением страниц я бы зафиксировал пять фактов:

1. Как бизнес сейчас получает обращения или продажи.
2. Какую роль выполняет действующий сайт, если он есть.
3. Где теряется результат или замедляется работа.
4. Какие решения команда уже пробовала.
5. Почему задача стала приоритетной именно сейчас.

Текущая точка защищает проект от лишнего объема. Если основная проблема - отсутствие отдельной страницы для рекламного направления, полная смена CMS может не быть первым решением. Если компания регулярно запускает новые услуги, но не может сама создавать страницы, простая визуальная доработка также не снимет ограничение.

Материал о создании и продвижении сайта помогает определить маркетинговые входы и роли страниц до дизайна. В ТЗ эти решения получают владельца, объем и способ проверки.

Сформулируйте одно главное изменение

У первой версии должен быть один приоритет. Не единственная польза сайта, а изменение, ради которого проект оправдан.

Формулировка состоит из четырех частей:

1. Кто. должен получить новый маршрут.
2. Что. он сможет понять или сделать.
3. Что изменится. в работе бизнеса.
4. Как команда это проверит. после запуска.

Дополнительные цели не исчезают. Они получают приоритет ниже: поддержать поиск, помочь продажам, собрать экспертные материалы, обновить визуальный образ. Это позволяет обсуждать компромиссы без спора «все важно».

Когда в ТЗ десять равноправных целей, команда не получает свободу. Она получает десять способов считать проект незавершенным.

Разведите решения, гипотезы и неизвестное

До старта не все ответы доступны. С этим не нужно бороться искусственной точностью. Неизвестное становится управляемым, когда у него есть тип, владелец и дата решения.

Например, список услуг может быть решен, структура CRM - зависимостью, новый калькулятор - гипотезой, фирменная система - ограничением, а личный кабинет - бэклогом. В одной строке «нужен сайт с калькулятором и CRM» эти состояния не видны.

Перед оценкой пометьте каждый крупный пункт одним из пяти статусов. Любое неизвестное без владельца превратится в решение разработчика или конфликт на приемке.

Описывайте аудиторию через решение

Возраст, должность и отрасль помогают понять контекст, но не объясняют страницу. Для ТЗ важнее, какое решение человек принимает и что мешает ему двигаться дальше.

Для каждой приоритетной аудитории ответьте:

• с какой ситуацией она приходит;
• что уже знает;
• какое решение принимает;
• какие сомнения должна снять страница;
• какие факты подтверждают ответ;
• какое действие соответствует ее готовности;
• какие данные нужны команде после обращения.

Один человек может менять роль в разных ситуациях. Собственник, который впервые знакомится с подрядчиком, и собственник, который сравнивает коммерческие предложения, нуждаются в разной глубине. Поэтому страница проектируется не «для собственников», а для конкретного этапа решения.

Если аудиторий много, не нужно сразу создавать отдельный раздел для каждой. Сначала проверьте, различаются ли у них вопрос, доказательства и следующий шаг. Методика выбора корпоративной архитектуры раскрыта в статье о корпоративном сайте.

Дайте каждой странице работу

Карта сайта становится требованием только тогда, когда у каждой страницы есть самостоятельная роль. Название раздела «Услуги» или «О компании» еще ничего не говорит о содержании.

Для ключевой страницы достаточно карточки из семи полей:

1. Аудитория и ситуация входа.
2. Решение, которое поддерживает страница.
3. Главное сообщение.
4. Необходимые доказательства.
5. Целевое действие.
6. Источник трафика и внутренние переходы.
7. Признак успешного прохождения.

Так видно, где страницы дублируют друг друга, а где одному запросу негде жить. Если две страницы отвечают на один вопрос одинаковыми доказательствами и ведут к одному действию, их разделение нужно обосновать. Если на общей странице смешаны несколько разных решений, структуру стоит развести.

Подробную проверку логики одной страницы лучше выполнять через прототип. ТЗ фиксирует роль и границы страницы; прототип показывает порядок смыслов внутри нее.

Зафиксируйте готовность материалов

Контент влияет на срок и дизайн так же сильно, как функции. Формулировка «тексты предоставит заказчик» не говорит, существуют ли они, соответствуют ли новой структуре и кто разрешает публикацию.

Для каждого типа материала нужен статус:

Я бы не ждал финальной готовности всего контента, чтобы начать проект. Но временный материал должен иметь владельца и дату замены. Иначе макет принимается на коротком демонстрационном тексте, а реальный заголовок становится «проблемой верстки» в конце.

Переведите функции в сценарии

Список «форма, фильтр, личный кабинет, интеграция» плохо оценивается, потому что за одним названием скрывается разное поведение. Функцию нужно описать через начало, действие, результат и исключение.

Для каждого приоритетного сценария зафиксируйте:

1. Кто и откуда начинает действие.
2. Какие данные видит и вводит.
3. Какие проверки происходят.
4. Что получает пользователь.
5. Какие данные получает команда.
6. Что происходит при ошибке.
7. Как подтверждается успешное выполнение.

Статья о передаче дизайна в разработку отдельно объясняет состояния компонентов и сценарную приемку интерфейса. В ТЗ важно закрепить границу функции и результат, а не диктовать разработчику каждую техническую реализацию.

Укажите свободу и ограничения команды

Плохое ТЗ бывает не только слишком общим, но и чрезмерно предписывающим. Если заказчик заранее назначает технологию, структуру базы и конкретный компонент без понятной причины, он забирает у команды ответственность за решение.

Разделите требования на три вида:

• обязательный результат. что должно работать и быть передано;
• жесткое ограничение. что нельзя менять из-за инфраструктуры, закона, бренда или бизнеса;
• предпочтение. подход, который можно заменить при обосновании.

Например, передача заявок с источником - результат. Использование действующей корпоративной CRM - ограничение. Конкретный внешний вид формы - предпочтение, если он еще не прошел проектирование.

Если платформа уже выбрана, ее собственные ограничения и эксплуатацию нужно проверить отдельно. Для 1С-Битрикс такой контур описан в материале о разработке сайта на Bitrix.

Назначьте владельцев решений

В проекте участвуют руководитель, маркетолог, продажи, редактор, дизайнер, разработчик, SEO-специалист и юрист. Все не должны согласовывать все.

Для каждого типа решения назначьте четыре роли:

1. Кто дает исходные факты.
2. Кто готовит решение.
3. Кто проверяет предметную часть.
4. Кто принимает итоговую версию.

Один человек может совмещать несколько ролей. Но итоговое право решения должно быть одно. Иначе пять комментариев превращаются в пять параллельных версий задания.

Ответственный нужен не для того, чтобы собрать больше мнений. Он нужен, чтобы в назначенный момент превратить мнения в одно решение для команды.

Если решение зависит от участника, который пока не подключен, это фиксируется как блокер, а не скрывается в общем списке согласующих.

Привяжите приемку к исходной задаче

Критерий «соответствует ТЗ» полезен только тогда, когда само ТЗ содержит проверяемые результаты. Я связываю приемку на трех уровнях.

Дополнительно фиксируются визуальные макеты, мобильные состояния, контент, URL, аналитика и технические проверки. Но каждый пункт должен отвечать на вопрос: какой риск он закрывает и чем подтверждается.

Требование входит в объем только тогда, когда у него есть связь с задачей, понятный результат и способ приемки. Остальное остается вопросом, гипотезой или бэклогом.

Соберите первую версию ТЗ в один проход

Не нужно ждать идеального документа. Для первой оценки достаточно собрать девять разделов:

1. Текущая точка и причина проекта.
2. Главное изменение первой версии.
3. Аудитории и решения.
4. Карта страниц с ролями.
5. Материалы и их владельцы.
6. Пользовательские и операционные сценарии.
7. Интеграции, данные и ограничения.
8. Роли принятия решений.
9. Результаты и критерии приемки.

После первого прохода отдельно выпишите неизвестное. Для каждого пункта назначьте действие: получить ответ, провести исследование, принять допущение, оценить диапазоном или убрать из первой версии.

Сильная первая версия ТЗ не закрывает все вопросы. Она не позволяет ни одному важному вопросу остаться невидимым и без владельца.

Только после этого имеет смысл сравнивать оценки. Материал о стоимости сайта показывает, как привести предложения подрядчиков к одному масштабу и не принять отсутствующую строку за бесплатную работу.

Как Медиакод готовит требования к сайту

Медиакод связывает требования с маркетинговой задачей и дальнейшей работой команды. Сначала фиксируется текущее ограничение и изменение первой версии. Затем команда проектирует аудитории, страницы, доказательства, формы, данные, аналитику и приемку. Неизвестное получает владельца, а полезные идеи вне приоритета уходят в отдельный бэклог.

В работе участвуют сертифицированные специалисты по Bitrix, Tilda, frontend, backend, Яндекс Метрике, Яндекс Директу, VK Рекламе, Telegram Ads и SMM; подтверждения собраны в разделе сертификаций. Победы, финалы и позиции Медиакод в топ-5 профессиональных премий зафиксированы в разделе наград.

Роль вопросов формы и передачи контекста в длинном маршруте показывает кейс ремонта квартир: данные об объекте, сроке и бюджете помогали квалифицировать обращение до разговора. Для нового проекта начните с текущей точки, одного главного изменения и карты неизвестного. После этого задачу можно предметно передавать в разработку сайта.