Техническое задание на приложение: как составить и когда нужен product brief

Короткий ответ: для большинства бизнес-приложений классическое ТЗ на 60 страниц не нужно — нужен продуктовый бриф на 5–10 страниц: цели, пользователи, сценарии, состав первой версии, интеграции, ограничения, критерии приёмки. Формальное ТЗ оправдано в трёх случаях: тендер, корпоративная закупка с регламентом, фиксированный бюджет с жёсткой приёмкой по документу. Ниже — чем документы отличаются, шаблон брифа и ошибки, из-за которых постановка задачи превращается в источник конфликтов.

ТЗ и бриф: в чём разница

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

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

Когда нужно именно ТЗ

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

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

Шаблон продуктового брифа: 8 разделов

1. Контекст и цель. Что за бизнес, какой процесс меняем, какое число должно сдвинуться.
2. Пользователи. Кто они, в какой ситуации откроют приложение, что делают сейчас вместо него.
3. Сценарии. 3–5 главных историй от входа до целевого действия.
4. Состав первой версии. Что входит в MVP и что осознанно откладываем — отсев важнее перечня; методика — в статье о составе MVP.
5. Интеграции. Учёт, CRM, платежи, уведомления: с чем продукт обменивается данными.
6. Ограничения. Платформы, бюджетная рамка, даты, требования к данным и безопасности.
7. Критерии успеха. Метрики первой версии и срок, когда смотрим на них.
8. Роли. Кто принимает решения со стороны заказчика, кто отвечает за контент.

Такой бриф заполняется за один вечер силами заказчика и одного созвона с продуктовой командой. Дальше он превращается в прототип и оценку — это этапы нашего процесса работы.

Типовые ошибки постановки задачи

«Сделайте как у конкурента». У конкурента другая аудитория, экономика и история решений; копируется чужой ответ без чужого вопроса. Правильная формулировка: «у конкурента есть X, нам важен результат Y — предложите, как его достичь».

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

Всё в первой версии. Бриф из 40 функций — это не амбициозность, а отложенный запуск и размытая проверка гипотезы. Дисциплина отсева — главный навык на этом этапе; типовые ловушки разобраны в статье об ошибках при разработке.

Частые вопросы