Что такое ТЗ на сайт и нужно ли оно малому бизнесу

Слово «ТЗ» звучит солидно и пугает одинаково обе стороны. Заказчик думает, что его заставят писать документ на много страниц. Подрядчик подозревает, что без документа его потом завалят правками. Оба опасения справедливы, но решаются они не тем документом, о котором обычно думают.

Что такое ТЗ на сайт?

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

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

В малом проекте условия другие. Заказчик один, исполнитель один, обсуждение идёт напрямую. И документ, который в корпорации экономит время, здесь часто его съедает.

Нужно ли ТЗ малому бизнесу?

В классическом виде - обычно нет, и вот почему.

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

Второе: ТЗ устаревает на первом же изменении. Как только вы посмотрели на первый макет и поняли, что хотите иначе, документ перестаёт описывать проект.

Но вывод «значит, ничего фиксировать не надо» - ошибочный, и он дороже обоих вариантов.

Что нужно зафиксировать письменно в любом случае?

Не ТЗ, а объём. Минимальный набор, без которого начинать нельзя:

Список страниц или блоков, поимённо. Не «сайт компании», а перечень.

Ключевые функции - формы, каталог, фильтры, личный кабинет, языковые версии. Каждая названа отдельно.

Кто даёт контент - тексты, фотографии, логотип. Это самая частая причина срыва сроков.

Что входит в правки, а что считается новой задачей.

Цена и порядок оплаты.

Что передаётся по завершении - доступы, исходники, инструкция.

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

Чем бриф отличается от ТЗ?

Бриф отвечает на вопрос «зачем», ТЗ - на вопрос «как».

Бриф заполняет заказчик, и это короткие вопросы про бизнес: чем занимаетесь, кто клиенты, что должен делать человек на сайте, какие примеры нравятся, что не нравится. Его смысл - передать контекст, а не спроектировать решение.

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

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

Кто должен писать ТЗ - вы или подрядчик?

Если оно действительно нужно, писать его должен подрядчик, а утверждать заказчик.

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

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

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

Что делать, если вы не знаете, чего хотите?

Это нормальное состояние, и оно не мешает начать.

Заказчик редко может описать дизайн словами. Зато он почти всегда может показать: вот такие сайты нравятся, вот такие нет, вот здесь понятно, а здесь перегружено. Референсы работают лучше описаний.

Поэтому визуальное направление разумнее согласовывать до полной сборки, на паре примеров и первом экране, а не описывать в документе заранее. Развернуться на референсах ничего не стоит, развернуться на готовом сайте - дорого.

Что действительно нужно знать заранее - не дизайн, а задачу: что человек должен сделать на сайте и откуда он придёт.

Как зафиксированный объём защищает от споров о правках?

Спор о правках возникает всегда из одного: стороны по-разному понимают, где заканчивается согласованная работа.

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

Что помогает:

Разделить исправления и изменения. Исправить ошибку, опечатку, несоответствие согласованному - входит всегда. Добавить новую секцию, сменить структуру, переделать под новую идею - отдельная задача.

Назвать состав правок заранее - сколько итераций по дизайну и по контенту входит в цену.

Фиксировать согласование этапов письменно, хотя бы сообщением в чате.

Это не бюрократия, а защита обеих сторон. Заказчик знает, что получит, подрядчик знает, где остановиться.

Сколько стоит ТЗ и входит ли оно в цену?

У меня фиксация объёма входит в работу и отдельно не стоит: бриф, предложение с перечнем работ, цена на согласованный объём. Лендинг от $190, многостраничный сайт от $490, сложный проект по запросу.

Отдельно оплачиваемое ТЗ имеет смысл только там, где проектирование само по себе большая работа: интеграции с учётными системами, личные кабинеты, сложная логика. В таких проектах документ экономит больше, чем стоит.

Из чего складывается цена сайта: сколько стоит сайт в Ташкенте.

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