Как написать техническое задание на разработку, которое поймут

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

Ниже — структура ТЗ, которой мы пользуемся, пример описания сценария и ошибки, из-за которых документ на сотню страниц не помогает.

Зачем нужно техническое задание?

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

ТЗ решает три задачи:

• оценка — по списку сценариев можно посчитать работу, а не назвать цифру «на глаз»;
• приёмка — у каждого сценария есть критерии, по которым понятно, готов он или нет;
• память проекта — через полгода новый разработчик или новый подрядчик поймёт, почему система устроена именно так.

Важно, чего ТЗ не делает: оно не заменяет общение. Документ, который написали, отдали команде и больше не открывали, устаревает с первой же недели разработки.

Из чего состоит хорошее ТЗ?

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

Раздел	На какой вопрос отвечает	Пример
Цель и метрики	Зачем продукт и как понять, что он работает	Сократить время обработки заявки до 1 часа
Роли	Кто пользуется системой и что ему разрешено	Покупатель, менеджер, администратор
Сценарии	Что пользователь делает от начала до конца	Оформить заказ, вернуть товар
Данные	Какие сущности хранятся и как связаны	Заказ, позиция, клиент, оплата
Интеграции	С какими внешними системами обмен	Платёжный сервис, CRM, служба доставки
Нефункциональные требования	Скорость, нагрузка, безопасность, языки	Страница каталога быстрее 1 секунды
Вне рамок	Что точно не делаем в этой версии	Мобильное приложение, программа лояльности

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

Фото: Unsplash

Как описывать сценарии, чтобы их поняли разработчики?

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

Шаблон сценария

Сценарий: Покупатель оплачивает заказ картой
Роль: покупатель (авторизован)
Предусловие: в корзине есть хотя бы один товар в наличии

Основной путь:
  1. Покупатель нажимает «Оформить заказ»
  2. Система показывает итог: товары, доставку, сумму
  3. Покупатель выбирает оплату картой
  4. Система переводит на страницу платёжного сервиса
  5. После оплаты заказ получает статус «Оплачен», покупатель — письмо

Альтернативы:
  3а. Товар закончился, пока покупатель оформлял заказ — показать, какой, и убрать из итога
  5а. Оплата отклонена — вернуть на шаг 3, заказ остаётся «Ожидает оплаты»
  5б. Банк прислал подтверждение повторно — заказ не оплачивается дважды

Критерии приёмки:
  - оплаченный заказ виден менеджеру в админке в течение минуты
  - повторное уведомление банка не меняет статус и не шлёт второе письмо

Такой формат читается без технической подготовки и при этом даёт разработчику всё, чтобы оценить работу и написать тесты.

Кто должен писать техническое задание?

Писать ТЗ должны вместе заказчик и команда разработки, обычно через аналитика или менеджера продукта. Заказчик приносит знание бизнеса и пользователей, команда — понимание, что сложно, что дорого и что можно сделать проще.

Как распределяются роли на практике:

1. Заказчик формулирует цель, описывает пользователей и процессы «как сейчас».
2. Аналитик проводит интервью и собирает сценарии, ищет противоречия и пробелы.
3. Техлид оценивает сценарии, предлагает упрощения и фиксирует технические ограничения.
4. Дизайнер по сценариям делает прототипы ключевых экранов.
5. Заказчик читает итог и подтверждает, что это то, что ему нужно.

Для первой оценки полного ТЗ не требуется — достаточно описания продукта и основных сценариев, как мы писали в статье о том, из чего складывается оценка MVP. Подробный документ собирается на этапе аналитики.

Какие ошибки делают ТЗ бесполезным?

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

Ошибки, которые встречаются чаще всего:

• «Сделать как у конкурента» без описания, какую задачу решает функция у вас.
• Размытые требования: «удобный интерфейс», «быстрая работа», «надёжная система» — без цифр и условий.
• Только счастливый путь: не описано, что происходит при ошибке оплаты, пустом списке или потере связи.
• Готовые технические решения от заказчика: «использовать микросервисы» вместо «выдерживать 500 заказов в час».
• Документ, который не обновляют: решения с созвонов остаются в переписке, а ТЗ описывает уже несуществующую систему.

Как проверить ТЗ перед отправкой подрядчику

Прочитайте каждый сценарий и спросите себя: могу ли я по этому тексту проверить, что работа сделана? Если ответ «нет» или «ну, посмотрим» — сценарию не хватает критериев приёмки. Второй тест: дайте документ человеку, который не участвовал в обсуждениях, и попросите пересказать, что делает продукт.

Коротко

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