Что должно быть в техническом задании на сайт

Егороснователь студии Plavno
Обновлено 10 августа 2026

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

Зачем вообще нужно ТЗ

Три причины, и все практические.

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

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

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

Что должно быть внутри

Хорошее ТЗ короткое и конкретное. Ниже — минимум, который закрывает большинство конфликтов.

1. Задача сайта

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

Формулировка задачи определяет решения. Сайт для заявок и сайт для имиджа устроены по-разному, хотя оба «современные».

2. Аудитория

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

3. Структура

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

Главная — предложение, услуги, цены, форма
Услуги — описание, что входит, сроки
О компании — команда, опыт, лицензии
Контакты — адрес, телефон, карта, форма

4. Что делает пользователь

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

Каждое действие — это работа. Не записали калькулятор — не ждите калькулятор.

5. Требования к дизайну

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

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

Здесь коротко, но конкретно:

7. Что передаётся при сдаче

Раздел, который чаще всего забывают, а он важнее многих:

8. Границы работ

Прямо напишите, чего в проекте нет: наполнение каталога, фотосъёмка, тексты, интеграция с 1С. Это защищает обе стороны от разговора «а я думал, это входит».

Чего в ТЗ быть не должно

Стостраничного описания очевидного. Документ, который никто не прочтёт, не работает. Если ТЗ длиннее двадцати страниц для обычного сайта — скорее всего, в нём переписаны общие места.

Указаний, как именно делать. Ваша задача — сформулировать результат, а не выбирать за подрядчика технологии. «Сайт должен быстро грузиться» — хорошо. «Использовать такой-то фреймворк» — вы берёте на себя ответственность за решение, в котором можете не разбираться.

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

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

Кто его пишет

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

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

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

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

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

Обязательно ли ТЗ для одностраничного сайта? Полноценный документ — нет. Но структура, список действий пользователя и границы работ нужны даже там. Это страница текста, а не двадцать.

Можно ли менять ТЗ по ходу проекта? Можно и нужно, если появилось понимание. Важно другое: изменения фиксируются письменно вместе с влиянием на срок и стоимость.

Что делать, если подрядчик прислал ТЗ на сто страниц? Прочитать по диагонали и найти разделы про передаваемые доступы и границы работ. Если их нет — объём документа ничего не гарантирует.

Кто владеет исходниками по умолчанию? По умолчанию — никто, пока не написано. Пропишите это явно, иначе при расставании с подрядчиком возможны сюрпризы.

← Все статьи