Плохое техническое задание — главная причина конфликтов между заказчиком и разработчиком. «Я имел в виду другое» — фраза, которая стоит бизнесу тысячи долларов переделок. Хорошее ТЗ экономит время, деньги и нервы обеих сторон. Разберём, как его составить.

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

ТЗ фиксирует ожидания. Без него каждый участник проекта представляет результат по-своему: заказчик ждёт «как у Apple», дизайнер рисует «как в тренде», разработчик делает «как проще». Результат — три разных продукта в голове трёх человек и ни одного в реальности.

ТЗ — это контракт на уровне продукта. Оно определяет, что будет сделано, в каком объёме и с каким качеством. Всё, чего нет в ТЗ — не входит в scope, и за это платят отдельно.

Структура ТЗ

Описание проекта — 2–3 абзаца о том, что за продукт, для кого и какую проблему решает. Контекст помогает разработчику принимать самостоятельные решения в неоднозначных ситуациях.

Функциональные требования — что система должна делать. Описывайте через пользовательские сценарии: «Пользователь вводит email и пароль, нажимает «Войти». Система проверяет данные. Если верны — перенаправляет на дашборд. Если нет — показывает ошибку.»

Нефункциональные требования — производительность (страница грузится за 2 секунды), доступность (99.9% uptime), безопасность (HTTPS, шифрование паролей), совместимость (Chrome, Firefox, Safari, мобильные).

Дизайн и UX — макеты, wireframes или хотя бы референсы. «Сделайте красиво» — не требование. «Шапка фиксированная, меню бургер на мобильных, цвета по брендбуку (ссылка)» — требование.

Ограничения — стек технологий (если важно), бюджет, дедлайны, интеграции с внешними сервисами.

Критерии приёмки — как вы будете проверять, что работа выполнена. Чек-лист конкретных пунктов: «форма отправляет данные в CRM», «мобильная версия корректно отображается на iPhone 14».

Антипаттерны

«Сделайте как у конкурента» — без конкретики это не ТЗ, а мечта. Какие именно элементы? Какие функции? Какие исключить? Дайте ссылку и аннотируйте скриншоты.

«Должно быть интуитивно понятно» — субъективное требование, которое невозможно проверить. Замените на конкретное: «новый пользователь должен разместить объявление без инструкции за 3 минуты».

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

Процесс согласования

ТЗ — не документ, который заказчик «кидает через забор». Это результат совместной работы. Оптимальный процесс: заказчик описывает бизнес-требования, разработчик задаёт уточняющие вопросы, вместе формулируют функциональные требования, оба подписывают финальную версию.

Изменения после подписания — через формальный запрос (change request) с оценкой влияния на сроки и бюджет. Без этого scope ползёт незаметно, дедлайн срывается, и все недовольны.

Пример мини-ТЗ на лендинг

Вот как выглядит минимальное, но достаточное ТЗ:

Проект: лендинг для сервиса SEO-аудита. Цель — сбор заявок на бесплатный аудит. Целевая аудитория: владельцы малого бизнеса с сайтом, без глубоких знаний SEO. Структура: первый экран (заголовок + форма), блок проблем (3 боли), блок решения (что входит в аудит), кейсы (3 карточки с до/после), отзывы (2–3), форма заявки, FAQ (5 вопросов). Форма: имя, email, URL сайта. Данные отправляются на email и в Telegram-бот. Дизайн: референс — [ссылка]. Стиль минималистичный, основной цвет — синий (#2563EB), фон белый. Технические требования: адаптивная вёрстка (мобильный + десктоп), LCP ниже 2.5с, HTTPS. Критерии приёмки: форма отправляет данные, мобильная версия корректна на iPhone 14 и Samsung Galaxy S24, PageSpeed Score выше 90.

ТЗ для дизайнера vs ТЗ для разработчика

Дизайнеру нужны: бизнес-контекст (для кого, зачем), целевое действие, структура и порядок блоков, референсы стиля, текстовый контент или его черновик. Не нужны: технические детали реализации, формат API, описание серверной логики.

Разработчику нужны: готовые макеты (от дизайнера), функциональные требования (что делает каждый элемент), интеграции (какие API, какие сервисы), нефункциональные требования (скорость, безопасность), критерии приёмки. Не нужны: объяснения, зачем бизнесу этот проект, маркетинговые метрики, описание целевой аудитории (если это не влияет на логику).

Хорошее ТЗ — инвестиция 4–8 часов, которая экономит 40–80 часов переделок. Не пропускайте этот этап.