Чем ТЗ отличается от брифа и прототипа
Эти материалы дополняют друг друга.
| Документ | На какой вопрос отвечает | Что содержит |
| Бриф | Зачем нужен сайт и какие задачи он решает? | Данные о проекте, аудитории, продажах, сроках и ограничениях |
| Прототип | Как человек будет пользоваться сайтом? | Страницы, блоки, навигацию и основные сценарии |
| Техническое задание | Что именно нужно реализовать и как проверить результат? | Функции, данные, интеграции, требования к контенту, условия проверки и передачи |
Застройщику не обязательно самостоятельно описывать программную реализацию. Полезнее собрать исходные данные и бизнес-требования, а технические решения уточнить с командой разработки и ответственными за действующие системы.
Что подготовить до составления ТЗ
Соберите описание ЖК, аудитории и предложения, фирменный стиль, планировки и визуализации. Укажите, какие материалы уже утверждены, какие находятся в работе и кто отвечает за их готовность.
Для действующего проекта понадобятся сведения о сайте, аналитике, CRM и системе учёта квартир. Если речь идёт о редизайне, полезно описать конкретные проблемы: неудобный выбор квартиры, устаревшие данные, потеря контекста заявки или сложности с обновлением страниц
Также определите:
- дату, к которой сайт нужен бизнесу, и её причину;
- доступный бюджет или диапазон для обсуждения;
- функции первой версии и последующих этапов;
- ответственного за согласование со стороны застройщика;
- участников со стороны маркетинга, продаж и технической команды.
Это позволит обсуждать объём работ с учётом реальных условий проекта.
Десять разделов технического задания на сайт ЖК
1. Задача сайта и границы первой версии
Начните с конкретной ситуации: старт продаж нового ЖК, запуск очереди, продвижение отдельного ассортимента или обновление действующего сайта.
Опишите основной сценарий покупателя и ожидаемое действие. Например:
Покупатель выбирает квартиру по параметрам, открывает её карточку и оставляет запрос на условия покупки. В обращении сохраняется идентификатор выбранной квартиры.
Отдельно перечислите функции, которые должны быть готовы к запуску, и задачи следующих этапов. Если на старте достаточно подборки планировок, а полноценный каталог планируется позже, это должно быть видно из ТЗ и сметы.
Цели по обращениям после запуска учитывают вместе с трафиком, предложением и работой отдела продаж. Для приёмки разработки нужны проверяемые требования к самому сайту.
2. Структура и типы страниц
Зафиксируйте карту сайта: главная, каталог, карточка квартиры, информация о проекте, ход строительства, контакты и другие необходимые разделы.
Для каждой страницы укажите её задачу, основные блоки, действия посетителя и способ обновления содержания.
Различайте уникальный шаблон и страницы, которые создаются на его основе. Один шаблон карточки может использоваться для большого числа квартир. При этом перенос и проверка данных остаются самостоятельной частью работы.
Если предусмотрены посадочные страницы под рекламу, перечислите их и обозначьте, что в них будет общим, а что потребует отдельной разработки. Состав блоков подробнее разобрали в статье «Что должно быть на сайте ЖК, чтобы покупателю было удобно обратиться».
3. Каталог квартир и правила работы с данными
Опишите параметры поиска, состав карточки и доступные действия. Например: фильтрация по комнатности, площади, цене, этажу и корпусу; просмотр планировки; запрос условий по выбранной квартире.
Также нужно определить:
- источник характеристик, цен и статусов;
- способ и периодичность обновления;
- правила показа проданных и забронированных квартир;
- поведение при отсутствии подходящих вариантов;
- порядок действий при ошибке обновления.
Фраза «данные обновляются автоматически» требует уточнения: какие данные, из какой системы и с каким допустимым запаздыванием. Эти условия согласуют после проверки возможностей источника.
4. Формы и сценарии обращения
Для каждой формы опишите её назначение, поля, обязательность заполнения, проверки и результат отправки.
Пример формулировки:
В карточке квартиры доступна форма запроса условий покупки. Телефон обязателен, имя и комментарий — необязательны. Вместе с обращением передаются идентификатор квартиры и адрес страницы. При ошибке ввода сайт показывает пояснение рядом с полем. Подтверждение отправки появляется после успешного приёма данных сайтом.
Нужен и сценарий сбоя: какое сообщение увидит посетитель и как сможет повторить действие. Подписи полей, инструкции и обратная связь должны оставаться понятными, в том числе при использовании вспомогательных технологий.
Если форма предлагает запись на встречу, уточните: она отправляет пожелание менеджеру или подтверждает конкретное свободное время. Это разные функции.
5. Интеграции: заявки, каталог и бронирование
За строкой «интеграция с CRM» могут стоять разные задачи:
| Задача | Что необходимо определить |
| Передача обращения | Какие поля передаются, куда попадает заявка и кто получает уведомление |
| Обновление каталога | Какая система хранит достоверные цены и статусы, как сайт получает изменения |
| Бронирование | Что резервируется, где подтверждается бронь и как проверяется доступность |
Для каждой интеграции укажите систему, направление обмена, необходимые доступы, ответственных и способ проверки.
Заранее обсудите недоступность внешнего сервиса. Например, если CRM временно не отвечает, обращение может сохраняться для повторной передачи — но такой механизм должен быть предусмотрен и реализован. Его нельзя считать включённым автоматически.
Также согласуйте обработку повторных отправок, чтобы один запрос не создавал несколько одинаковых обращений. Онлайн-бронирование включайте отдельной задачей: обычная форма запроса сама по себе квартиру не резервирует.
6. Контент и ответственность за материалы
Перечень страниц не определяет, кто готовит их содержание. В ТЗ полезно добавить таблицу материалов.
| Материал | Что зафиксировать |
| Тексты | Кто пишет, кто проверяет факты, кто утверждает |
| Планировки | Какие исходники передаются, нужна ли обработка, сколько вариантов готовится |
| Визуализации и фотографии | Используются готовые материалы или требуется создание новых |
| Цены и характеристики | Источник, формат, ответственный и дата актуализации |
| Документы и сведения о проекте | Кто предоставляет утверждённые материалы и поддерживает их актуальность |
Отдельно укажите объём первоначального наполнения. Настроить шаблон карточки, загрузить несколько примеров и заполнить весь каталог — разные объёмы работ.
7. Дизайн, мобильная версия и удобство использования
Зафиксируйте исходный фирменный стиль, перечень уникальных экранов, этап согласования концепции и количество предусмотренных раундов доработки.
Референсы сопровождайте пояснениями: удобная навигация, способ показа планировок, характер типографики. Так команде будет понятнее, какие качества вы хотите получить.
Для мобильной версии опишите ключевые сценарии: фильтры доступны, планировка увеличивается, поля можно заполнить при открытой клавиатуре, закреплённые элементы не перекрывают действия.
Также согласуйте устройства и браузеры для проверки. Если в ТЗ есть требования к скорости, укажите метрики, целевые значения и условия измерения. Формулировка «сайт должен быстро работать» не задаёт способа приёмки.
8. Подготовка к поисковому продвижению и аналитика
Опишите, какие страницы предназначены для поиска, кто заполняет Title и Description, как устроены заголовки и адреса. Для каталога отдельно решите, какие страницы фильтров должны быть доступны поисковым системам.
При редизайне составьте соответствие старых и новых адресов, предусмотрите постоянные перенаправления на подходящие страницы и обновление внутренних ссылок. Такой подход соответствует рекомендациям Google по переносу сайта.
В аналитике перечислите события: просмотр квартиры, открытие формы, успешный приём заявки, клик по телефону и другие согласованные действия. Для каждого события укажите момент фиксации и способ проверки.
Подготовку сайта к продвижению, ведение рекламы и регулярную SEO-работу лучше выделить в отдельные задачи с понятным составом результата.
9. Управление сайтом и обслуживание
Определите, что маркетолог сможет менять самостоятельно: тексты, фотографии, новости, документы, карточки или настройки отдельных блоков.
Платформу выбирайте с учётом этих операций, интеграций и дальнейшего развития. Если технология уже задана, укажите её и известные ограничения.
Зафиксируйте, кто управляет доменом, хостингом и внешними сервисами, какие доступы получает заказчик и какие регулярные расходы возникают после запуска.
Также стоит определить порядок резервного копирования и восстановления, если он входит в объём обслуживания, и назначить ответственного за технические обращения.
10. Этапы, приёмка и передача результата
Разделите работу на понятные результаты: структура и прототип, дизайн, разработка, интеграции, наполнение, проверка и публикация.
Для каждого этапа укажите необходимые исходные данные, ответственного за согласование и критерии завершения. В графике учитывайте время на материалы и обратную связь заказчика.
Согласуйте перечень передаваемых доступов, макетов, файлов и инструкций. Он зависит от выбранной платформы: возможности конструктора и сайта с собственной кодовой базой могут различаться.
Опишите порядок исправления ошибок и последующих изменений: кто принимает обращения, как фиксируется задача и как оценивается дополнительный объём.
Как превратить пожелания в проверяемые требования
Для каждого важного пункта задайте вопрос: «Как мы поймём, что это работает?»
| Общее пожелание | Проверяемый результат |
| Удобный каталог | Выбранные фильтры ограничивают выдачу; при отсутствии вариантов показывается понятное сообщение и возможность изменить условия |
| Заявки поступают в CRM | Тестовое обращение появляется в согласованном разделе системы с нужными полями и идентификатором квартиры |
| Актуальные цены | Изменение тестовой цены в источнике появляется на сайте в согласованный срок |
| Работающая форма | Некорректные данные вызывают пояснение; корректные принимаются, посетитель получает подтверждение |
| Защита от повторных отправок | Повторная попытка передачи одного тестового запроса не создаёт дубликат в рамках согласованного сценария |
| Передача управления заказчику | Ответственный сотрудник с выданной ролью выполняет предусмотренные обновления по инструкции |
Для функций, зависящих от внешних сервисов, проверяйте успешный сценарий и согласованное поведение при сбое. Результаты удобно фиксировать в списке проверок с отметками и ответственными.
Пример Гратус: почему нужно перечислять посадочные страницы
Короткий шаблон ТЗ на сайт ЖК
Используйте этот список для первого обсуждения. После него требования нужно дополнить согласованными сценариями и критериями проверки.
- Проект: [название ЖК, город, этап реализации, очереди].
- Задача сайта: [какое предложение представить и какое действие должен совершить посетитель].
- Первая версия: [страницы и функции к запуску]. Следующие этапы: [что планируется позже].
- Структура: [список страниц, уникальных шаблонов и рекламных посадочных].
- Каталог: [поля, фильтры, карточка, источник данных, порядок обновления].
- Формы: [назначение, поля, обязательность, контекст, подтверждение и ошибки].
- Интеграции: [системы, направление обмена, передаваемые данные, ответственные].
- Материалы: [что готово, что создаётся, кто предоставляет и утверждает].
- Дизайн: [фирменный стиль, экраны, референсы с пояснениями, согласование].
- Мобильная версия: [сценарии, устройства, браузеры, условия проверки].
- SEO и аналитика: [метаданные, адреса, перенос старых страниц, события].
- Управление: [платформа, редактируемые данные, роли и доступы].
- График и бюджет: [этапы, зависимости, согласования, разовые и регулярные расходы].
- Приёмка и передача: [проверки, доступы, файлы, инструкции, порядок поддержки].
До оценки проекта отметьте пункты, по которым решения ещё нет. Для них следует определить способ уточнения: обсуждение, проверка системы, прототипирование или отдельный этап обследования.
Частые вопросы
Нужно ли приходить в агентство с готовым ТЗ?
Нет. Для первого разговора достаточно описания задачи и имеющихся материалов. Агентство может помочь сформировать требования, а технические детали согласовать с вашей командой. Объём подготовки ТЗ стоит определить до начала этой работы.
Можно ли изменять ТЗ после старта?
Да. Изменение нужно описать и оценить его влияние на уже согласованные решения, сроки и стоимость. У команды должна оставаться одна актуальная версия требований, а принятые изменения — фиксироваться.
Нужно ли подробное ТЗ для небольшого лендинга?
Документ может быть короче, но в нём всё равно нужны состав блоков, материалы, формы, интеграции, мобильная версия и критерии готовности. Объём описания должен соответствовать сложности задачи.
Стоит ли заменять действующий сайт, если заявок мало?
Сначала проверьте источники трафика, предложение, мобильную версию, формы и обработку обращений. Причина может быть в конкретном этапе пути покупателя. По результатам анализа станет понятно, достаточно ли доработок, нужна ли отдельная посадочная страница или требуется новая структура.
