Блог

Техническое задание для сайта: что нужно знать заказчику до старта

Техническое задание (ТЗ) на разработку сайта — это юридически значимый документ, фиксирующий требования к дизайну, функционалу и структуре будущего веб-ресурса. Оно переводит бизнес-цели заказчика на язык программистов, исключает двойные трактовки и является главным критерием приемки готового проекта, защищая бюджет и сроки от неконтролируемого разрастания.

Зачем бизнесу нужно техническое задание

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

ТЗ и Бриф: в чем принципиальная разница

Многие заказчики путают бриф и техническое задание. Бриф — это анкета, в которой вы описываете свой бизнес, целевую аудиторию, конкурентов и общие пожелания (например, «нужен строгий дизайн в корпоративных тонах»). Бриф отвечает на вопрос «Что мы делаем и для кого?». В свою очередь, ТЗ — это инженерный документ. Он отвечает на вопрос «Как именно это должно работать? и с помощью каких технологий?».
💡 Совет: Никогда не прикрепляйте бриф к договору в качестве основного приложения. Бриф не содержит конкретных технических метрик, и недобросовестный разработчик сможет интерпретировать его на свое усмотрение, формально не нарушив обязательств.

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

Это один из самых частых вопросов на старте. Заказчик редко обладает нужной технической экспертизой, чтобы описать архитектуру баз данных, принципы маршрутизации, REST API или требования к серверному окружению. Поэтому идеальный сценарий — это совместная работа.
Обычно ТЗ пишет системный или бизнес-аналитик со стороны исполнителя на основе серии глубинных интервью с заказчиком. Ваша задача — предоставить исчерпывающую бизнес-информацию, регламенты компании и понимание процессов, а профильные специалисты переведут ее в строгий технический формат.

Структура идеального технического задания для сайта

Качественное ТЗ состоит из нескольких обязательных разделов. Пропуск хотя бы одного из них чреват проблемами на этапе релиза и тестирования.

1. Термины и определения (Глоссарий)

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

2. Общие требования к проекту

Здесь фиксируются базовые технические аспекты, которые влияют на весь проект в целом:
  • Выбор технологий (стек): Языки программирования (PHP, Python, JavaScript), используемые фреймворки или конкретные CMS-системы (WordPress, 1С-Битрикс, Tilda).
  • Требования к серверу: Необходимая мощность хостинга, операционная система, версия базы данных.
  • Кроссбраузерность и адаптивность: Список браузеров и минимальные разрешения экранов, для которых сайт должен отображаться корректно (например, Chrome, Safari последних версий, мобильные устройства от 320px).

3. Структура сайта (Sitemap)

ТЗ должно содержать наглядную карту сайта в виде дерева страниц. Это показывает иерархию разделов: Главная страница, О компании, Услуги, Каталог, Карточка товара, Корзина. К каждому узлу прописываются пути перехода и вложенность.

4. Функциональные требования

Самый объемный раздел. Здесь детально описывается логика работы каждого элемента, базы данных и пользовательских ролей.
💡 Пример правильного описания: Вместо размытого «сделайте форму обратной связи» пишем: «Форма содержит поля: Имя (обязательное), Телефон (обязательное, маска +7 (XXX) XXX-XX-XX). При успешной отправке данные сохраняются в БД, на почту администратора уходит email, а пользователю показывается поп-ап "Спасибо"».
В этом же разделе прописываются сторонние интеграции: подключение платежных шлюзов (эквайринг), интеграция с CRM-системами (amoCRM, Битрикс24), службами доставки (СДЭК, Почта России) и складскими программами (1С:Предприятие).

Типичные ошибки при составлении ТЗ

Анализируя сотни неудачных запусков, можно выделить несколько критических ошибок, которые допускают заказчики и неопытные исполнители:
  • Субъективные формулировки: Использование слов «красивый», «удобный интерфейс», «современный дизайн». Замените их на конкретные референсы или UI/UX метрики, иначе доказать некачественную работу будет невозможно.
  • Игнорирование SEO-требований: Сайт должен сдаваться с базовой технической оптимизацией. В ТЗ нужно заложить человекопонятные URL (ЧПУ), наличие мета-тегов Title/Description, генерацию файла sitemap.xml и правильную иерархию заголовков H1-H6.
  • Отсутствие сценариев ошибок: Важно описать не только идеальный путь (happy path), но и негативные сценарии. Что произойдет, если пользователь введет неверный промокод, или отвалится соединение с банком?

Как заказчику проверять готовое ТЗ перед подписанием

Когда разработчик или аналитик присылает вам готовое ТЗ, не торопитесь ставить подпись, даже если документ выглядит солидно. Возьмите паузу на несколько дней. Пройдитесь по каждому пункту, задавая себе контрольный вопрос: «Понимаю ли я, как именно это будет реализовано и смогу ли я это проверить?». Проверьте документ на наличие ссылок на внешние инструменты проверки.

Часто задаваемые вопросы (FAQ)

Можно ли вносить изменения в ТЗ в процессе разработки?

Классическая модель (Waterfall) предполагает, что ТЗ не меняется. Любое добавление функции — это дополнительное соглашение, переоценка бюджета и сдвиг сроков. Если вы понимаете, что требования будут меняться, лучше выбрать гибкие методологии (Agile/Scrum), где формируется не жесткое ТЗ, а бэклог задач с короткими итерациями.

Сколько стоит разработка технического задания?

Написание детального ТЗ — это полноценный аналитический этап, занимающий от нескольких дней до месяцев. На рынке услуг он оценивается в среднем от 10% до 20% от общего бюджета проекта. Бесплатное ТЗ «в подарок», как правило, сводится к формальной отписке на пару страниц и не несет реальной ценности.

Кому принадлежат авторские права на созданное ТЗ?

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

Нужно ли описывать в документе админ-панель?

Да, обязательно. Многие концентрируются только на клиентской части (frontend), забывая о том, как контент-менеджеры будут управлять сайтом. В ТЗ должно быть указано, какие поля можно редактировать визуально, нужны ли разные роли (администратор, редактор, SEO-специалист) и каковы их права доступа.
01.10.2026