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

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

Зачем нужно ТЗ и кто его пишет

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

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

Кто может его составить

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

Цели, аудитория и сценарии

Начните с того, зачем нужен сайт. «Современный удобный сайт» — не цель. Цель — то, что можно проверить: «получать заявки на монтаж кондиционеров из Москвы и области», «сократить количество звонков с вопросом о статусе заказа», «принимать предоплату за мастер-классы онлайн».

Затем опишите аудиторию: кто эти люди, с какого устройства чаще заходят, что для них важно при выборе. Для B2B-закупщика и молодой мамы, выбирающей детский сад, нужны совершенно разные сайты.

Самая полезная часть этого раздела — сценарии. Это короткие истории вида «кто — хочет — чтобы»:

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

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

Структура и функциональность

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

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

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

Интеграции и контент

Для каждой интеграции укажите: с какой системой, какие данные и в каком направлении передаются, как часто, кто предоставит доступы. Например: «заявки с сайта создают сделку в amoCRM в воронке „Сайт“, с полями имя, телефон, услуга, UTM-метки». Если у системы нет API или доступа нет, это нужно выяснить до оценки, а не на середине проекта.

Раздел о контенте закрывает самый частый источник задержек. Пропишите:

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

Дизайн-референсы и нефункциональные требования

Ссылки на сайты, которые нравятся, полезны, только если к каждой есть пояснение: «нравится, как подан каталог», «нравится спокойная цветовая гамма». Голая ссылка «хочу как здесь» каждый поймёт по-своему. Приложите фирменный стиль, если он есть, и антипримеры — что точно не подходит.

Нефункциональные требования описывают не что сайт делает, а как:

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

Критерии приёмки

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

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

Шаблон ТЗ: чек-лист разделов

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

1. Общие сведения: компания, контактное лицо, сроки, бюджет.
2. Цели сайта и показатели, по которым будет понятен результат.
3. Аудитория и ключевые сценарии пользователей.
4. Структура: список страниц и шаблонов с назначением каждого.
5. Функциональность с приоритетами: обязательно, желательно, позже.
6. Интеграции: системы, данные, направление обмена, доступы.
7. Контент: кто готовит, объём, перенос со старого сайта.
8. Дизайн: фирменный стиль, референсы с пояснениями, антипримеры.
9. Нефункциональные требования: скорость, адаптивность, безопасность, персональные данные, SEO.
10. Администрирование: роли и права в админке.
11. Хостинг, домен и передача доступов.
12. Критерии приёмки и гарантийные обязательства.

Частые ошибки

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

Хорошее ТЗ не обязано быть длинным — оно обязано быть однозначным. Если по нему можно сделать оценку и потом принять работу без споров, своё дело оно выполнило. Как это ТЗ потом превращается в этапы работ, мы рассказывали в статье о разработке сайта под ключ.

Частые вопросы

Обсудим проект

Нужна похожая разработка?

Расскажите о задаче — уточним детали, предложим формат запуска и подготовим предварительную оценку. Это бесплатно.

Ваше имя Способ связиTelegramVKMAXТелефонПочта

Контакт

Отправить заявкуНаписать напрямую

Опубликовано 12 октября 2026 г. · Обновлено 12 октября 2026 г.