ТЗ на разработку: как составить, чтобы смета и сроки не поплыли

Бриф отвечает на вопрос «зачем»: какую задачу бизнеса решает продукт, кто им пользуется, что считается успехом. ТЗ отвечает на вопрос «что именно будет сделано»: страницы, сценарии, интеграции, ограничения. Путаница между ними стоит дорого: смета, названная по брифу, - это вилка с честной погрешностью в разы, потому что «личный кабинет» может означать и профиль с историей заказов, и полноценный портал с ролями.

Отсюда правило зрелого процесса: точная цена и сроки фиксируются после ТЗ, а не до. Если подрядчик готов назвать финальную цифру по двум абзацам описания - либо цифра вырастет в процессе, либо в неё заранее заложен большой запас, который вы оплатите.

Форматы различаются, но содержательно рабочее ТЗ закрывает шесть вопросов:

• Цель и метрики: какой показатель должен измениться и как его измерят после запуска.
• Пользователи и сценарии: кто и что делает в системе - по шагам, а не «пользователь может всё».
• Функциональные блоки с приоритетами: что обязательно к запуску, что желательно, что откладывается на потом.
• Интеграции и данные: с какими системами стыкуемся, откуда берутся и куда уходят данные, кто отвечает за доступы.
• Нефункциональные требования: скорость, адаптив, безопасность, нагрузка - всё, что «само собой разумеется», пока не оказалось, что нет.
• Границы проекта: что НЕ входит в объём. Самый недооценённый блок - именно он снимает будущие споры.

Типовые пробелы повторяются из проекта в проект. «Админка само собой разумеется» - а это отдельный интерфейс с ролями и правами, порой сопоставимый по объёму с клиентской частью. «Контент кто-нибудь подготовит» - и за неделю до запуска выясняется, что тексты, фото и карточки товаров не готовы, а в смете их не было. «Там же есть API» - есть, но недокументированный, с лимитами и без нужных полей: интеграция превращается в исследование.

Четвёртая дыра - правки без лимита: «ещё один вариант дизайна» в цикле из десяти итераций. И пятая - приёмка без критериев: если нигде не записано, что значит «готово», финальная стадия проекта превращается в бесконечное «а ещё вот тут поправьте». Каждую из этих дыр закрывает одна строка в ТЗ, написанная до старта.

ТЗ раскрывает свою силу в связке с договором: смета и сроки фиксируются после согласования ТЗ, и с этого момента цена не меняется - без доплат «в процессе». Всё, что появляется сверх ТЗ, оценивается отдельно и стартует только с согласия заказчика. Это защищает обе стороны: заказчика - от растущего бюджета, студию - от бесконечного расширения объёма за те же деньги.

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

Хорошее ТЗ - совместная работа: заказчик приносит знание бизнеса и процессов, студия переводит его в требования, задавая вопросы, о которых заказчик не подумал бы. Требовать от клиента готовое техническое ТЗ - так себе практика; нормальная студия делает аналитику этапом проекта.

Красные флаги на этой стадии видны заранее. Подрядчик готов стартовать «прямо завтра» без ТЗ - значит, объём будет выясняться в процессе за ваш счёт. Не задаёт вопросов о процессах и метриках - значит, будет строить по шаблону. Не готов зафиксировать смету после ТЗ - значит, вилка останется вилкой до самого конца проекта.