Техническое задание на сайт — это документ, защищающий обе стороны: клиент получает именно то, что описал, студия работает по согласованному плану. Без ТЗ объём работ размывается, правки становятся бесконечными, а конечная стоимость выходит за рамки бюджета.
ТЗ — это не бюрократия. Это способ говорить на одном языке.
Однажды на приёмке заказчик сказал: «А где личный кабинет?». В брифе кабинета не было, в макетах — тоже. Мы делали лендинг, он ждал портал. Формально правы обе стороны — и обе теряют время и нервы. Такой разговор почти всегда заканчивается одинаково: переделка и вопрос «кто виноват». Техническое задание существует ровно для того, чтобы этого разговора не было.
Что такое техническое задание
Техническое задание (ТЗ) — документ, который описывает, что именно будет сделано, как будет работать и какому критерию соответствовать. Не «сделайте красиво» — а «на главной странице фильтр с тремя параметрами: тип услуги, регион, бюджет; при выборе параметра список обновляется без перезагрузки страницы».
ТЗ защищает клиента от «а мы думали вы имели в виду другое». Защищает студию от «ну вы же должны были понять». Это документ, на который обе стороны ссылаются при любом споре.
Чтобы разница была наглядной — две колонки, как проект идёт с ТЗ и без него:
| Ситуация | Без ТЗ | С ТЗ |
|---|---|---|
| Объём работ | размытый | зафиксирован |
| Правки | бесконечные | по согласованному списку |
| Цена в итоге | растёт непредсказуемо | предсказуема |
| Споры | «вы должны были понять» | ссылка на документ |
| Сроки | плывут | привязаны к объёму |
| Приёмка | «нравится / не нравится» | проверяемые критерии |
Что должно быть в ТЗ
Общие цели и аудитория
Краткое резюме из брифа: цель сайта, ЦА, ключевое действие пользователя. Это ориентир для всех решений дальше.
Структура сайта
Все страницы, их иерархия, связи между ними. Обычно оформляется как карта сайта: Главная → Услуги (3 подстраницы) → О компании → Блог → Контакты.
Функционал — самый важный блок
Каждая функция описана: что делает, кто видит, как работает. Форма заявки: поля (имя, телефон, тип услуги), куда отправляется (email + CRM), что видит пользователь после (страница благодарности или попап).
Каждая неописанная функция — потенциальный источник разногласий. «Там должна быть кнопка поделиться» — в ТЗ не было, студия не делала, клиент удивлён.
Интеграции
Какие внешние системы подключаются: CRM (и какая — Битрикс24, amoCRM, другая), аналитика (Яндекс Метрика, GA4), онлайн-чат, колл-трекинг, оплата. Каждая интеграция — это дополнительные работы и нередко дополнительная стоимость.
Технические требования
CMS или кастом, стек технологий (если важен), хостинг (чей), скорость загрузки (PageSpeed не ниже X), браузеры и устройства (Safari, Chrome, мобильные), SEO-требования (мета-теги, sitemap, robots.txt).
Дизайн-требования
Референсы, фирменный стиль (если есть — приложить гайдлайн или хотя бы цвета, шрифты, логотип), что нельзя использовать.
Контент
Кто пишет тексты — студия или клиент? Кто предоставляет фото? Если клиент — в какой срок? Этот пункт часто стопорит проект: студия сделала макет, ждёт контент три недели.
Критерии приёмки
По каким критериям клиент принимает работу. «Форма работает», «сайт открывается на iPhone 14», «скорость загрузки не ниже 70 по PageSpeed» — конкретные, проверяемые вещи.
ТЗ защищает, но не ограничивает
ТЗ — живой документ. В процессе появляются новые идеи, меняется понимание задачи. Это нормально. Главное — изменения фиксируются письменно, с обновлённой оценкой сроков и стоимости. Не «ну добавьте ещё», а «добавляем X, это + N рублей и + M дней».
С тем заказчиком мы в итоге договорились. Доделали нужный функционал за дополнительную оплату. Но потратили две недели на разбирательства, которых не было бы с ТЗ. Теперь мы не начинаем разработку без него. Никогда.
Как делаем мы. ТЗ составляем сами по итогам брифа и согласуем с вами до старта. Изменения по ходу — только письменно, с обновлённой ценой и сроком. Так на приёмке нет сюрпризов ни у вас, ни у нас — на многостраничном сайте, где страниц и решений больше, это особенно заметно.
Если коротко
- ТЗ — не бюрократия, а страховка обеих сторон: фиксирует, что именно будет сделано.
- Обязательные блоки: цели и ЦА, структура, функционал, интеграции, тех-требования, дизайн, контент, критерии приёмки.
- Самый важный блок — функционал: каждая неописанная функция превращается в будущий спор.
- ТЗ — живой документ: изменения фиксируются письменно с новой ценой и сроком.
- Даже для лендинга нужно мини-ТЗ — оно снимает большинство конфликтов на приёмке.
Частые вопросы
ТЗ нужно даже для простого лендинга?
Да, хотя бы короткое. Для лендинга это 1–2 страницы: структура, блоки, функции форм, критерии приёмки. Даже мини-ТЗ снимает большинство будущих споров.
Кто составляет ТЗ — я или студия?
Обычно студия по итогам брифа, а вы согласуете и дополняете. Хорошая студия задаёт правильные вопросы; ваша задача — честно ответить и проверить, что всё описано так, как вы хотите.
Что, если в процессе захочется что-то поменять?
Это нормально, ТЗ — живой документ. Изменения фиксируются письменно с новой оценкой сроков и стоимости: «добавляем X — это +N рублей и +M дней». Так нет сюрпризов ни у кого.
Можно ли начать без ТЗ, чтобы быстрее?
Можно, но это экономия, которая дорого обходится: размытый объём, бесконечные правки, споры на приёмке. «Быстрее без ТЗ» почти всегда оборачивается «дольше и дороже».
Чем ТЗ отличается от брифа?
Бриф — это ваши пожелания и вводные своими словами. ТЗ — перевод брифа в проверяемые требования: что делает каждая функция, как принимается работа. Бриф — вопрос, ТЗ — ответ.
