Техническое задание на сайт пишет исполнитель, а утверждает заказчик: заказчик знает бизнес и не обязан знать ограничения платформы, исполнитель знает ограничения и не вправе выдумывать бизнес. Готовое ТЗ идёт приложением к договору — чего в нём нет, того нет и в стоимости.
Внутри обязаны быть пять вещей: структура страниц, сценарии пользователя, интеграции, требования к мобильной версии и критерии приёмки.
Чем ТЗ отличается от брифа
Бриф — вход, ТЗ — выход. Бриф заполняет заказчик на языке бизнеса: чем занимается компания, кто покупает, что должно происходить после запуска, бюджет и срок. Техническое задание — то же самое в проверяемых требованиях. «Нужен современный удобный сайт» — бриф. «Семь типов страниц, из них три уникальных шаблона; заявка уходит в CRM и дублируется письмом; каталог фильтруется по трём параметрам» — техническое задание.
Разница практическая: по брифу нельзя ни оценить работу, ни принять её. Спор «это входило или нет» разрешается только текстом ТЗ — документ, который не проверяется пункт за пунктом, техническим заданием не является, как бы он ни назывался.
Как ТЗ связано с договором — предметом, порядком приёмки, правами на исходники — разобрано отдельно: договор на разработку сайта.
Кто пишет техническое задание на сайт
Написание ТЗ — проектная работа: нужно понимать, что платформа умеет, во что упрётся и сколько стоит каждое требование. Заказчик, написавший задание сам, чаще всего получает документ про внешний вид — «шапка», «слайдер», «блок преимуществ». Поведение при этом не описано: куда уходит заявка, что видит человек после отправки, что происходит с товаром, которого нет на складе.
Обратная крайность — ТЗ, присланное сразу на подпись. Утверждение не формальность: заказчик единственный, кто знает, что заявки обрабатывает не отдел, а один человек.
Рабочий порядок: бриф и интервью — черновик от исполнителя — вычитка заказчиком — согласованная версия за подписью обеих сторон. Работа над ТЗ оплачивается отдельным этапом. Если задание обещают «бесплатно, за час», получится перечень блоков.
Что должно быть внутри
Структура страниц и типы шаблонов
Не «разделы сайта», а перечень страниц с указанием, какие собираются по одному шаблону: тридцать страниц услуг по единому образцу дешевле, чем пять, нарисованных по-разному. Отдельно отмечается, какие страницы заказчик редактирует сам после запуска — это влияет и на цену, и на дальнейшую независимость от исполнителя.
Сценарии пользователя
Самая пропускаемая часть. Сценарий описывает путь целиком, включая исключения: человек открывает страницу услуги, заполняет три поля, отправляет; заявка уходит в CRM и дублируется письмом; появляется подтверждение; при ошибке отправки введённые данные не пропадают.
Проверка задания на прочность — поискать в нём ошибки и пустоту. Что видит посетитель, когда в каталоге не осталось товаров по фильтрам, что показывать, если оплата не прошла. Отсутствие этих ответов гарантирует правки после сдачи.
Интеграции и обмен данными
Каждая интеграция описывается тремя параметрами: что передаётся, в какую сторону и как часто. «Интеграция с 1С» — название задачи, а не требование. Требование звучит иначе: остатки и цены выгружаются из учётной системы раз в час, заказы передаются обратно после оплаты, ключом сопоставления служит артикул.
Правило сопоставления — пункт ТЗ, а не деталь реализации: типичный источник дублей именно здесь. Контрагент заводится заново, потому что не совпал формат телефона, и один заказ создаётся дважды. Тут же фиксируется, кто даёт доступы.
Требования к мобильной версии
«Сайт должен быть адаптивным» не проверяется и ничего не гарантирует. Проверяемые требования звучат конкретно: страницы открываются на экранах от 360 пикселей; горизонтальной прокрутки нет; таблицы прокручиваются внутри своей области, а не растягивают страницу; кнопки не мельче пальца. Мобильных посетителей обычно большинство, и претензии после запуска чаще всего касаются телефона — список устройств для проверки дешевле спора на приёмке.
Контент и наполнение
Кто пишет тексты, откуда берутся фотографии, кто заполняет карточки и к какому сроку. Пункт «контент предоставляет заказчик» справедлив, но без даты превращает проект в бессрочный.
Критерии приёмки
Список утверждений, на каждое из которых можно ответить «да» или «нет». Форма отправляется, письмо доходит. Заказ появляется в CRM с полями из формы. Страницы открываются на перечисленных устройствах. Счётчик установлен, целевое действие размечено.
Оценочное «сайт работает корректно» бесполезно обеим сторонам: заказчику нечем доказать несоответствие, исполнителю нечем закрыть этап.
Сколько стоит и от чего зависит
Публичных прайсов у практики Dodigi нет. Цифры ниже — по опубликованным прайсам студий, они показывают порядок сумм на рынке.
| Что делается | Опубликованный диапазон |
|---|---|
| Лендинг | от 100 тыс. ₽ |
| Многостраничный сайт, интернет-магазин | от 200 тыс. ₽ |
| Сайт на Тильде | 250 тыс. — 1,5 млн ₽ |
| Сайт или веб-сервис на своём коде | от 2 млн ₽, от 3 месяцев |
| Поддержка и развитие | от 2 000 ₽/час |
Место проекта внутри диапазона определяет то, что перечислено в ТЗ: число уникальных шаблонов, количество сценариев с исключениями, наличие каталога и личного кабинета, число интеграций. Подробное задание не удорожает проект — оно показывает настоящую цену до старта.
Сроки для калибровки: витрина услуг ОК Оригинал запускалась за месяц; интернет-магазин ОК Вода и сайт услуг ТСК Лаборатория с 20+ направлениями — за два месяца. Восемь страниц Getsman на собственном коде собрались за два дня: ни каталога, ни оплаты, задание умещалось на страницу.
Что происходит, когда ТЗ нет
Проект не останавливается — он начинает описываться на ходу, в переписке. Смета растёт на 20–40%: невыясненная деталь всплывает тогда, когда её дороже всего чинить — фильтр каталога, выгрузка остатков, вторая языковая версия. Приёмка превращается в переговоры: замечания принимать не по чему, обсуждается вкус, а не соответствие, и правки становятся бесконечными.
Дальше появляется зависимость. Требования, жившие только в голове разработчика, следующий подрядчик восстанавливает по коду — отсюда знакомое «никто, кроме них, в этом клубке не разберётся». ТЗ и есть тот документ, который делает проект передаваемым.
На что смотреть
- «ТЗ будет согласовано позднее» в договоре. Предмет не определён, предоплата уходит за работу неизвестного объёма. Разумнее два этапа: проектирование с результатом в виде ТЗ и сметы, затем разработка.
- Задание про внешний вид вместо поведения. «Стильный дизайн» есть, ни одного сценария нет — спорные места остались нетронутыми.
- Нет раздела про доступы и исходники. В ТЗ уместно перечислить, что передаётся при сдаче: домен, хостинг или аккаунт конструктора, админка на правах владельца, макеты, аналитика.
- Интеграции одной строкой. «Подключить оплату и CRM» — намерение, а не объём. Без описания полей ручная сверка останется навсегда.
- ТЗ не обновляется по ходу. У задания должны быть версия и дата, иначе изменения живут в чате и всплывают на приёмке.
Вопросы и ответы
Где взять образец технического задания на сайт? Образцы в открытом доступе есть и как каркас годятся: разделы примерно одинаковые. Но содержательная часть — сценарии, интеграции, критерии приёмки — в любом образце пустая, она уникальна для проекта. Практический способ: взять образец за оглавление и заполнять вместе с исполнителем.
Чем техническое задание на создание сайта отличается от задания на разработку? Ничем: это разные названия одного документа. Разница в масштабе объекта. Для лендинга ТЗ умещается в две-три страницы — один шаблон, одна форма, один сценарий. Для магазина или сервиса с личным кабинетом документ вырастает в разы за счёт сценариев и обмена данными.
Нужно ли делать ТЗ по ГОСТ? Для коммерческого сайта — нет, если этого не требуют условия закупки. Государственные стандарты задают строгую структуру, обязательную в тендерах и полезную в крупных системах; обычному проекту они добавляют объём, а не ясность.
Кто платит за разработку технического задания? Заказчик: это отдельный оплачиваемый этап. Разумная схема — ТЗ и смета оформляются первым этапом, результат принадлежит заказчику. Тогда с готовым заданием можно пойти к нескольким исполнителям и получить сопоставимые предложения; в этом вторая практическая ценность документа.
Что делать, если по ходу работы понадобились изменения? Фиксировать письменно как дополнение к ТЗ, с оценкой влияния на срок и стоимость. Полезно заранее договориться о порядке: как оформляется запрос и за какое время даётся оценка.
Коротко
Техническое задание — перевод пожеланий в проверяемые требования. Пишет исполнитель, утверждает заказчик, оплачивается отдельно, прикладывается к договору. Минимум внутри: страницы и шаблоны, сценарии с исключениями, интеграции с описанием полей, требования к мобильной версии, критерии приёмки.
Подготовка технического задания или разбор уже полученного до подписания договора — задача обсуждаемая: контакты. Ответ в течение дня.