Техническое задание на сайт: как составить, если вы не технарь

Зачем нужно ТЗ

Считается, что ТЗ пишут, чтобы разработчик знал, что делать. Это половина правды. Разработчик и без документа обычно понимает, что делать, — а вот что считать законченным, стороны понимают по-разному.

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

Поэтому проверка качества ТЗ простая: если по документу непонятно, за что можно не подписать акт, — документ бесполезен.

Кто пишет ТЗ

В теории — заказчик. На практике заказчик, не работающий в вебе, физически не может корректно описать технические требования, и попытка это сделать заканчивается скачанным из интернета шаблоном с пунктами про «кроссбраузерность в Internet Explorer 11».

Рабочее распределение выглядит так:

Нормально, когда ТЗ пишет исполнитель: он лучше знает формулировки. Ненормально, когда заказчик его не читает.

Девять разделов ТЗ

1. Задача сайта и измеримая цель

Два-три предложения о бизнесе и одно — о том, что должен сделать посетитель. Плюс число, по которому через полгода станет ясно, сработало ли.

Пример: «Студия косметологии в центре Еревана, 4 мастера, приём по записи. Задача сайта: посетитель с телефона записывается на процедуру без звонка. Цель — 25 записей через сайт в месяц к концу третьего месяца».

2. Аудитория и сценарии

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

Пример: «Сценарий А: местная клиентка ищет в Google на армянском „կոսմետոլոգ Երևան“, заходит с телефона, ей нужны цены и свободное время на завтра. Сценарий Б: русскоязычная клиентка пришла по рекомендации, ищет конкретного мастера и отзывы».

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

3. Карта страниц

Простой список с вложенностью. Пример для той же студии:

/                     Главная
/services/            Услуги (список)
/services/{услуга}/   Страница услуги — типовая, 6 штук
/masters/             Мастера
/prices/              Цены
/about/               О студии
/contacts/            Контакты
/policy/              Политика конфиденциальности

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

4. Поблочное описание типовых страниц

Самый полезный раздел и самый часто пропускаемый. Для каждой страницы — список блоков сверху вниз, в двух-трёх словах каждый.

Пример для страницы услуги:

1. Название услуги, короткое описание, цена «от», кнопка «Записаться»
2. Кому подходит и кому не подходит — списком
3. Как проходит процедура — 3–4 шага
4. Фото работ до/после — галерея, минимум 6 изображений
5. Мастера, выполняющие услугу — карточки с переходом в раздел «Мастера»
6. Цены на варианты услуги — таблица
7. Частые вопросы — 5–7 вопросов
8. Форма записи с выбором даты

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

5. Языковые версии

Перечислите языки и укажите четыре вещи: какая версия основная, кто делает перевод, будут ли у версий отдельные адреса и нужна ли настройка hreflang.

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

Всё, что на сайте выполняет действие:

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

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

7. Технические требования

Тот раздел, который пишет подрядчик. Минимально достаточный набор:

• адаптивность: телефон, планшет, десктоп; проверка на реальных устройствах;
• браузеры: актуальные версии Chrome, Safari, Firefox, Edge;
• скорость: целевой показатель в PageSpeed Insights для мобильной версии;
• SEO-минимум: уникальные title и description, заголовки H1–H3, robots.txt, sitemap.xml, микроразметка организации;
• HTTPS и автопродление сертификата;
• резервное копирование: как часто и куда;
• хостинг и домен: на кого оформлены, кто оплачивает.

8. Контент: кто, что и когда

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

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

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

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

Формулировки: как переписать расплывчатое в проверяемое

Требование в ТЗ имеет смысл только тогда, когда по нему можно однозначно сказать «выполнено» или «нет». Вот типичные замены.

Шесть пунктов, из-за которых потом спорят о доплате

1. Количество раундов правок. Не указано — значит, бесконечно. Указывайте цифру на каждый этап.
2. Кто пишет тексты. Самая частая дыра в ТЗ. Пишите поимённо, по каждой странице.
3. Наполнение каталога. Разработка каталога и загрузка в него двух тысяч товаров — разные работы. Разделяйте строками.
4. Вторая языковая версия. «Сайт на армянском и русском» без уточнения означает либо перевод силами заказчика, либо +25% к смете. Договоритесь на берегу.
5. Что входит в поддержку. Обновления и бэкапы — да. Добавление нового раздела — нет. Опишите границу примерами.
6. Права на код и доступы. Одна строка: «Исходный код, доменное имя, доступы к хостингу, админ-панели и аналитике передаются заказчику после полной оплаты и принадлежат заказчику».

Чего в ТЗ писать не нужно

• Конкретную технологию без причины. Если у вас нет своих разработчиков и особых требований к инфраструктуре — задавайте результат, а не инструмент. «Сайт на React» в ТЗ для визитки салона обычно означает, что заказчик прочитал статью, а не что ему нужен React.
• Скачанные из шаблона пункты про старые браузеры. Поддержка Internet Explorer в 2026 году — лишние часы работы за ваши деньги ради нуля посетителей.
• Пожелания вида «чтобы было красиво». Вместо этого — референсы. Три ссылки на сайты, которые нравятся, работают лучше трёх абзацев прилагательных.
• Требования, которые вы не собираетесь проверять. Каждый пункт ТЗ кто-то будет исполнять, и вы за это платите. Если пункт вам не важен — уберите его.

Насколько длинным должно быть ТЗ

Ориентиры по нашей практике: лендинг — 3–5 страниц, корпоративный сайт — 8–15, интернет-магазин — от 20. Но объём не критерий. Критерий такой: дайте документ разработчику, который не участвовал в переговорах, и посмотрите, сколько вопросов он задаст. Ноль вопросов — ТЗ избыточно детализировано. Больше десяти — недостаточно. Два-три — ровно то, что нужно.