Зачем нужно ТЗ
Техническое задание — это договорённость между вами и разработчиком о том, что именно будет сделано. Без ТЗ вы получите не то, что хотели. А разработчик скажет: «Но вы же не говорили, что это нужно».
ТЗ защищает обе стороны. Заказчик получает конкретное описание результата. Разработчик получает чёткие рамки проекта. Споры решаются ссылкой на документ, а не эмоциями.
При этом ТЗ — не 50-страничный документ с UML-диаграммами. Для малого бизнеса достаточно 3–5 страниц с конкретными описаниями. Дальше покажу, что именно туда включить.
Структура ТЗ: 8 обязательных разделов
1. Цель и задачи сайта
Не «создать красивый сайт», а конкретно: «создать корпоративный сайт юридической компании, который будет привлекать 30–50 заявок в месяц через SEO и Яндекс Директ».
Цель определяет всё: структуру, дизайн, функционал, контент. Сайт для привлечения заявок — это одно. Сайт для имиджа — другое. Сайт для продажи товаров — третье.
Примеры хорошо сформулированных целей: «увеличить количество обращений в клинику на 40% за 6 месяцев», «запустить онлайн-продажи 200 товаров с интеграцией оплаты и доставки», «создать каталог продукции с фильтрацией и возможностью скачивания спецификаций».
2. Целевая аудитория
Кто будет пользоваться сайтом? Возраст, пол, город, уровень дохода, технические навыки, с каких устройств заходят.
Это влияет на дизайн и UX. Сайт для бизнесменов 40–55 лет выглядит и работает иначе, чем сайт для студентов. Если ваша аудитория — мужчины 35–50 лет в Москве, которые ищут юридические услуги с телефона — сайт должен быть максимально простым, быстрым и с крупными кнопками.
3. Структура сайта
Список всех страниц с описанием их назначения. Это скелет сайта.
Пример для юридической компании: главная (оффер, преимущества, CTA), услуги — семейное право, услуги — корпоративное право, услуги — трудовые споры, о компании, команда (страницы юристов), кейсы, блог, контакты.
Не нужно расписывать контент каждой страницы. Достаточно указать: какая страница, для чего она, какие блоки на ней должны быть.
4. Функциональные требования
Конкретный список того, что сайт должен уметь.
Формат: «На странице услуги должна быть форма заявки из двух полей (имя и телефон). При отправке формы данные должны приходить на email и в Telegram. Пользователь видит сообщение "Спасибо, мы свяжемся с вами в течение часа"».
Типичные функции, которые стоит описать: формы обратной связи (какие поля, куда приходят данные), каталог товаров/услуг (сколько позиций, какие фильтры), поиск по сайту (по каким параметрам), личный кабинет (что пользователь может делать), интеграции (CRM, 1С, платёжные системы, доставка), блог (кто будет публиковать, нужен ли визуальный редактор), мультиязычность (какие языки), аналитика (Яндекс Метрика, цели).
5. Требования к дизайну
Не нужно быть дизайнером. Достаточно описать: предпочтения по стилю (минимализм, строго, современно, ярко), примеры сайтов, которые нравятся (3–5 ссылок с комментариями, что именно нравится), фирменные цвета и логотип (если есть), чего хотите избежать (примеры сайтов, которые не нравятся).
Фраза «сделайте красиво» — не ТЗ. Фраза «хочу минималистичный дизайн в тёмных тонах, как у site1.com, но с яркими акцентами как у site2.com» — это ТЗ.
6. SEO-требования
Если планируете продвигаться в Яндексе — SEO нужно закладывать на этапе ТЗ, а не после запуска.
Минимум: ЧПУ (человекопонятные URL), возможность редактирования title и description для каждой страницы, заголовки H1–H3 на каждой странице, alt-теги для изображений, sitemap.xml и robots.txt, скорость загрузки менее 2 секунд, адаптивная вёрстка (mobile-first).
7. Технические требования
Для заказчика, далёкого от IT: адаптивность (сайт должен корректно работать на телефоне, планшете и десктопе), браузеры (Chrome, Safari, Firefox, Яндекс Браузер — последние две версии), хостинг (если есть предпочтения или ограничения), домен (есть или нужно зарегистрировать), SSL-сертификат (https), CMS или админ-панель (чтобы вы могли обновлять контент самостоятельно).
8. Сроки и бюджет
Укажите: желаемый срок запуска, бюджет (хотя бы диапазон: «100–200 тысяч» или «до 500 тысяч»), этапность (если нужно запустить часть функционала раньше).
Бюджет в ТЗ — это не слабость переговорной позиции. Это экономия времени. Разработчик сразу поймёт, какое решение предложить в рамках вашего бюджета, и не будет предлагать то, что вы не можете себе позволить.
Типичные ошибки в ТЗ
«Сделать как у конкурента, только лучше». Это не ТЗ. Что значит «лучше»? Быстрее? Красивее? С другим функционалом? Конкретизируйте.
Слишком размытые формулировки. «Современный дизайн» — это субъективно. «Минимализм, крупная типографика, много воздуха, как на apple.com» — это понятно.
Забытые мелочи. Кто будет наполнять сайт контентом? Нужна ли 404-страница? Как должна выглядеть страница «Спасибо» после отправки формы? Нужен ли favicon? Мелочи суммируются в часы работы.
Нет приоритетов. Если всё «обязательно и срочно» — значит, ничего не приоритетно. Разделите функции на: must have (без этого нельзя запуститься), should have (важно, но можно добавить позже), nice to have (хотелки на будущее).
Бриф vs ТЗ: в чём разница
Бриф — это короткий документ (1–2 страницы), где вы описываете задачу в свободной форме. Кто вы, чем занимаетесь, чего хотите от сайта, какой бюджет.
ТЗ — это детальный документ, который обычно составляется совместно с разработчиком на основе брифа. В нём — конкретные требования к каждому элементу.
Мой процесс: вы заполняете бриф (5 минут), мы созваниваемся и обсуждаем (30–60 минут), я составляю ТЗ и смету (1–2 дня), вы согласуете, и мы начинаем.
Нужно ли писать ТЗ самому?
Не обязательно. Хороший разработчик составит ТЗ за вас — на основе ваших ответов на простые вопросы. Но понимание структуры ТЗ поможет вам: задавать правильные вопросы подрядчику, оценивать предложения от разных исполнителей, контролировать процесс разработки, принимать результат по чёткому чек-листу, а не «на глаз».