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

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

Опубликовано 04.08.2026 · Андрей Савельев, маркетолог

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

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

Практическая польза для владельца бизнеса:

• Понятно, за что платите. Цена привязана к списку работ.
• Видно, что не входит. Часто это важнее того, что входит.
• Есть критерий приёмки. Понятно, когда работа считается выполненной.
• Можно сравнить предложения. С одинаковым заданием на руках сравнение подрядчиков становится честным.

Что обязательно должно быть

1. Цель сайта. Не «представить компанию в интернете», а «получать заявки на такую-то услугу с рекламы».
2. Кто целевой посетитель и с какими вопросами он приходит.
3. Структура: список страниц и блоков на каждой.
4. Кто пишет тексты. Самый частый источник конфликтов.
5. Кто делает и обрабатывает фотографии. Второй по частоте.
6. Приём заявок: куда приходят, в каком виде, есть ли защита от спама.
7. Аналитика: счётчик, цели, метки — с указанием, кто настраивает.
8. Юридическая часть: документы, согласие, cookie.
9. Мобильная версия — отдельным пунктом, а не «сайт будет адаптивным».
10. Скорость загрузки — с измеримым требованием.
11. Сроки по этапам и что происходит при их срыве.
12. Что после запуска: сколько правок входит, что считается правкой, сколько стоит поддержка.

Что забывают чаще всего

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

Как не превратить ТЗ в сорок бесполезных страниц

Огромное задание не защищает — его просто не читают полностью, а спорные места всё равно всплывают.

Что работает лучше:

• Пишите смыслами, а не пикселями. «Блок с ценами и калькулятором» вместо описания отступов.
• Фиксируйте границы, а не детали. Что входит, что не входит, что делает каждая сторона.
• Прикладывайте примеры. Две-три ссылки на сайты с пояснением, что именно нравится и почему — это точнее любого описания.
• Оговорите порядок изменений. По ходу работы что-то обязательно поменяется — важно, как это оформляется.

Кто должен писать задание

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

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

Если подрядчик готов делать сайт вообще без задания и без вопросов о бизнесе — это плохой знак. Скорее всего, вам соберут шаблон, а разбираться в вашей нише никто не станет.

Про то, как выбирать подрядчика и сколько это стоит, — в статьях сколько стоит создание сайта и как проверить подрядчика до оплаты.

Частые вопросы про ТЗ на сайт