1Бриф — это цель, ТЗ — это контракт объёма
Бриф отвечает на вопрос «зачем»: какую задачу бизнеса решает продукт, кто им пользуется, что считается успехом. ТЗ отвечает на вопрос «что именно будет сделано»: страницы, сценарии, интеграции, ограничения. Путаница между ними стоит дорого: смета, названная по брифу, — это вилка с честной погрешностью в разы, потому что «личный кабинет» может означать и профиль с историей заказов, и полноценный портал с ролями.
Отсюда правило зрелого процесса: точная цена и сроки фиксируются после ТЗ, а не до. Если подрядчик готов назвать финальную цифру по двум абзацам описания — либо цифра вырастет в процессе, либо в неё заранее заложен большой запас, который вы оплатите.
2Структура рабочего ТЗ: шесть блоков
Форматы различаются, но содержательно рабочее ТЗ закрывает шесть вопросов:
- Цель и метрики: какой показатель должен измениться и как его измерят после запуска.
- Пользователи и сценарии: кто и что делает в системе — по шагам, а не «пользователь может всё».
- Функциональные блоки с приоритетами: что обязательно к запуску, что желательно, что откладывается на потом.
- Интеграции и данные: с какими системами стыкуемся, откуда берутся и куда уходят данные, кто отвечает за доступы.
- Нефункциональные требования: скорость, адаптив, безопасность, нагрузка — всё, что «само собой разумеется», пока не оказалось, что нет.
- Границы проекта: что НЕ входит в объём. Самый недооценённый блок — именно он снимает будущие споры.
3Дыры, из-за которых смета плывёт
Типовые пробелы повторяются из проекта в проект. «Админка само собой разумеется» — а это отдельный интерфейс с ролями и правами, порой сопоставимый по объёму с клиентской частью. «Контент кто-нибудь подготовит» — и за неделю до запуска выясняется, что тексты, фото и карточки товаров не готовы, а в смете их не было. «Там же есть API» — есть, но недокументированный, с лимитами и без нужных полей: интеграция превращается в исследование.
Четвёртая дыра — правки без лимита: «ещё один вариант дизайна» в цикле из десяти итераций. И пятая — приёмка без критериев: если нигде не записано, что значит «готово», финальная стадия проекта превращается в бесконечное «а ещё вот тут поправьте». Каждую из этих дыр закрывает одна строка в ТЗ, написанная до старта.
4ТЗ и договор: как это работает вместе
ТЗ раскрывает свою силу в связке с договором: смета и сроки фиксируются после согласования ТЗ, и с этого момента цена не меняется — без доплат «в процессе». Всё, что появляется сверх ТЗ, оценивается отдельно и стартует только с согласия заказчика. Это защищает обе стороны: заказчика — от растущего бюджета, студию — от бесконечного расширения объёма за те же деньги.
Второй элемент — этапность: работа спринтами с демо, где прогресс виден на каждом шаге, а не в финале. К ТЗ это относится напрямую: приёмка по этапам с критериями из ТЗ снимает главный страх заказной разработки — «заплатили и ждём чёрный ящик».
5Кто пишет ТЗ — и красные флаги
Хорошее ТЗ — совместная работа: заказчик приносит знание бизнеса и процессов, студия переводит его в требования, задавая вопросы, о которых заказчик не подумал бы. Требовать от клиента готовое техническое ТЗ — так себе практика; нормальная студия делает аналитику этапом проекта.
Красные флаги на этой стадии видны заранее. Подрядчик готов стартовать «прямо завтра» без ТЗ — значит, объём будет выясняться в процессе за ваш счёт. Не задаёт вопросов о процессах и метриках — значит, будет строить по шаблону. Не готов зафиксировать смету после ТЗ — значит, вилка останется вилкой до самого конца проекта.
