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

Техническое задание, или ТЗ, фиксирует, какой сайт должен получить заказчик и как стороны поймут, что работа выполнена. Бизнесу не нужно самостоятельно описывать архитектуру базы данных или выбирать библиотеки. Его задача — передать цели, аудиторию, процессы и ограничения. Подрядчик должен превратить эти данные в понятные, проверяемые требования.

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

Не смешивайте бриф, прототип, смету и ТЗ

Эти документы связаны, но решают разные задачи.

• Бриф собирает исходные данные: чем занимается компания, кто покупатель, какие продукты важны, кто принимает решение.
• Карта сайта показывает будущие разделы и их иерархию.
• Прототип раскрывает содержание и логику ключевых страниц. В отдельной статье разобрано, что проверить заказчику в прототипе сайта.
• Смета связывает объём работ со стоимостью. Сравнить состав расходов помогает материал о том, из чего складывается цена разработки сайта.
• Техническое задание объединяет согласованные решения и задаёт критерии их выполнения.
• Договор фиксирует юридические и финансовые условия сотрудничества. ТЗ может быть приложением к договору, но не заменяет его.

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

Кто должен составлять техническое задание

Рабочая схема — совместная подготовка с понятным разделением ответственности.

Заказчик сообщает:

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

Подрядчик описывает:

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

Фраза «заказчик должен принести готовое ТЗ» — тревожный сигнал, если у компании нет собственной продуктовой команды. Исполнитель знает технологию лучше и обязан задавать вопросы. Но и формулировка «мы сами всё придумаем» опасна: без участия бизнеса подрядчик начнёт заполнять пробелы догадками.

Что включить в ТЗ на разработку сайта

1. Цель и границы проекта

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

Затем перечислите, что входит в проект и что остаётся за его пределами. Если фирменный стиль, фотографии, тексты, CRM или продвижение выполняет другая команда, это нужно указать прямо. Границы помогают сравнить сметы: одинаковое слово «сайт» у двух подрядчиков может скрывать разный объём.

2. Аудитория и пользовательские сценарии

Опишите не абстрактных «мужчин и женщин 25–60 лет», а ситуации, с которыми человек приходит. Например: выбрать проект дома по площади, понять различия технологий, получить расчёт и договориться о встрече.

Для каждого ключевого сценария укажите:

1. откуда приходит пользователь;
2. что хочет узнать;
3. какие страницы или функции ему нужны;
4. какое действие считается успешным.

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

3. Структура и типы страниц

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

Зафиксируйте:

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

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

4. Содержание страниц и прототипы

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

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

5. Функции и бизнес-правила

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

Слабая формулировка: «добавить калькулятор стоимости».

Проверяемая формулировка: «пользователь выбирает тип дома и площадь; калькулятор показывает предварительный диапазон, передаёт выбранные параметры в форму и отправляет их вместе с контактами в CRM».

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

6. Интеграции и обмен данными

Перечислите CRM, телефонию, 1С, платёжные системы, службы доставки, почту и другие сервисы. Для каждой интеграции укажите:

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

Не передавайте пароли в самом ТЗ. Достаточно назвать владельца доступа и безопасный способ передачи после старта работ.

7. Контент и ответственность

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

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

8. SEO и аналитика до запуска

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

• редактируемые Title, Description и H1;
• понятные постоянные URL;
• canonical, robots.txt и sitemap.xml;
• корректные коды ответа и редиректы со старых адресов;
• отсутствие случайного noindex на публичной версии;
• внутренние ссылки на важные страницы;
• доступность контента для поисковых роботов;
• правила для фильтров и параметров, если есть каталог.

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

9. Адаптивность, скорость и доступность

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

Скорость тоже задают через способ измерения, а не словом «быстро». Конкретные пороги зависят от проекта и исходных данных, поэтому подрядчик должен объяснить, что измеряется на тестовом стенде, а что — после запуска на реальном домене.

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

10. Приёмка, передача и поддержка

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

Отдельно закрепите, что получает заказчик после запуска:

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

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

Как управлять изменениями во время проекта

Даже хорошее ТЗ не отменяет новых идей. Важно заранее определить, как они влияют на сроки и стоимость.

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

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

Практический пример: заложить рост до первой версии

В проекте строительной компании «Надёжный дом» первой задачей был рекламный лендинг. При этом архитектуру сразу проектировали с запасом: страница должна была стать основой полноценного сайта, а не временным макетом.

Позже появились посадочные по типам домов, каталог проектов и карточки с параметрами. Сайт начал обслуживать и Яндекс Директ, и органический поиск. Расширение прошло в одной логике, потому что будущие разделы и связи между ними учли заранее. Подробный разбор опубликован в кейсе разработки сайта «Надёжного дома».

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

Чек-лист перед началом разработки

Проверьте десять пунктов:

1. Цель сайта выражена через бизнес-задачу и действие пользователя.
2. Границы проекта и исключения перечислены явно.
3. Есть карта сайта и список типов страниц.
4. Для ключевых сценариев подготовлены прототипы или понятные описания.
5. Функции сформулированы через входные данные, результат и ошибки.
6. Интеграции и владельцы доступов определены.
7. Контент распределён по ответственным и срокам.
8. SEO и аналитика включены до запуска.
9. Приёмка опирается на проверяемые критерии.
10. Порядок изменений, передача доступов и поддержка согласованы.

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

Команда Дзенмаркетинг начинает разработку сайта для бизнеса с анализа задачи, спроса, конкурентов и будущих сценариев. Чтобы обсудить проект, подготовьте описание продуктов, аудитории, текущего процесса продаж, обязательных интеграций и примеры сайтов, которые помогут объяснить ожидания. Этого достаточно для первой встречи; технические решения команда сформулирует вместе с вами.

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