Хорошее техническое задание на приложение отвечает на пять вопросов: для кого создаётся продукт, какую задачу решает, что входит в первую версию, с какими данными и системами она работает, как стороны проверят результат. Документ не обязан заранее описывать каждую техническую деталь. Его задача состоит в том, чтобы убрать опасные разночтения и сделать объём работы проверяемым.
Начните с короткой версии на 5–10 страниц, таблицы сценариев и списка открытых вопросов. После обсуждения с командой её можно дополнить прототипом, моделью данных и техническими решениями. Такой порядок полезнее, чем большой документ, в котором бизнес-цель теряется среди экранов и кнопок.
Бриф, PRD, ТЗ и user story: что выбрать?
| Документ | На какой вопрос отвечает | Когда нужен |
|---|---|---|
| Бриф | Что за задача и почему ею занимаемся | Первое знакомство и предварительная оценка |
| PRD | Какой продукт нужен пользователю и бизнесу | Согласование цели, функций и границ продукта |
| Техническое задание | Что должно работать и как это проверить | Проектирование, оценка, договор и приёмка |
| User story | Что конкретный пользователь хочет сделать | Декомпозиция сценариев для разработки |
Названия могут отличаться. Важнее, чтобы пакет требований связывал задачу бизнеса со сценариями и критериями проверки. Для MVP продукта документ должен особенно ясно фиксировать функции, которые сознательно отложены.
Структура ТЗ на разработку приложения
- Контекст и проблема. Как процесс работает сейчас, где возникают потери и почему изменение нужно именно теперь.
- Цель и метрика. Измеримый результат: сократить время операции, снизить число ошибок, увеличить долю завершённых заявок.
- Пользователи и роли. Кто работает с системой, что видит, создаёт, согласует и администрирует.
- Границы версии. Что входит в работу, что выполняется вручную и что перенесено в следующие этапы.
- Пользовательские сценарии. Пошаговый маршрут от события до результата, включая ошибки и возврат к предыдущему шагу.
- Данные. Сущности, обязательные поля, источники, сроки хранения, поиск и история изменений.
- Интеграции. CRM, 1С, платёжные системы, почта и другие сервисы: направление обмена, частота и поведение при сбое.
- Бизнес-правила. Расчёты, статусы, лимиты, уведомления и условия перехода между этапами.
- Нефункциональные требования. Нагрузка, доступность, устройства, безопасность, журналирование и резервное копирование.
- Критерии приёмки. Наблюдаемые условия, при которых функция считается выполненной.
Пример: сервис обработки заявок
Предположим, компания получает заявки из формы на сайте, почты и Telegram. Менеджеры вручную переносят их в таблицу, поэтому часть обращений теряется.
| Слабая формулировка | Проверяемая формулировка |
|---|---|
| Сделать удобную форму | Пользователь отправляет имя, телефон и тип услуги за один экран; обязательные поля проверяются до отправки |
| Интегрировать с CRM | После отправки система создаёт сделку в выбранной воронке, сохраняет источник и не создаёт дубль при повторном запросе |
| Быстро уведомлять менеджера | Ответственный получает сообщение не позднее 60 секунд после успешного создания сделки |
| Обеспечить безопасность | Оператор видит только назначенные заявки; действия входа, просмотра и изменения статуса записываются в журнал |
| Сделать красивый кабинет | Макеты для мобильной и настольной ширины согласуются отдельно; интерфейс поддерживает перечисленные состояния |
Основной сценарий можно записать так: клиент отправляет заявку, система проверяет поля, создаёт карточку, назначает менеджера и отправляет подтверждение. Затем добавляются альтернативы: CRM недоступна, телефон уже существует, ответственный отсутствует, клиент исправляет данные.
Что делать, если часть требований неизвестна?
Неизвестное не следует маскировать точной формулировкой. Создайте реестр открытых вопросов: кто принимает решение, когда оно нужно, как будет проверена гипотеза и на какую часть проекта влияет ответ.
- пометить допущения и владельца решения;
- провести интервью с пользователями;
- собрать кликабельный прототип;
- проверить критичный API небольшим экспериментом;
- измерить качество исходных данных;
- заложить отдельный исследовательский этап.
До снятия главных неизвестных оценка остаётся диапазоном. Это нормальная инженерная практика. Для сложной идеи полезно начать с диагностики задачи, а затем фиксировать объём разработки.
Как написать критерии приёмки?
Критерий строится из начального состояния, действия и наблюдаемого результата. Например: «Если оператор вошёл с ролью менеджера и заявка назначена другому сотруднику, карточка не отображается в его списке и недоступна по прямой ссылке».
- 01
Основной случай
Пользователь проходит весь маршрут с корректными данными.
- 02
Граничные значения
Пустые поля, лимиты, повторные операции и одновременные изменения.
- 03
Сбой зависимости
Внешняя система недоступна, отвечает медленно или возвращает ошибку.
- 04
Права доступа
Каждая роль видит и меняет только разрешённые данные.
- 05
Восстановление
Понятно, что произойдёт после повтора запроса или возврата сервиса.
Семь ошибок в техническом задании
- перечень экранов есть, а цель продукта и пользовательский маршрут отсутствуют;
- слова «удобно», «быстро» и «надёжно» не имеют измеримого определения;
- не перечислены функции, которые не входят в первую версию;
- интеграция названа одним пунктом без данных и аварийного поведения;
- роли описаны названиями без матрицы прав;
- макет принимают за полное описание логики;
- изменения требований не имеют процедуры оценки и согласования.
Что передать исполнителю вместе с ТЗ?
- контакты владельца продукта и экспертов процесса
- приоритеты и желаемую дату проверки гипотезы
- прототипы и визуальные материалы
- обезличенные примеры исходных данных
- описания API и тестовые доступы
- ограничения по инфраструктуре и безопасности
- порядок демонстраций и принятия решений
- условия передачи кода, документации и аккаунтов
Попросите команду вернуть декомпозицию, список допущений и рисков. Сравнивать предложения стоит по одинаковой границе результата. В статье о стоимости веб-приложения мы разобрали, какие части обычно формируют бюджет.
Частые вопросы
Кто должен писать техническое задание?
Владелец продукта лучше всех знает задачу и ограничения бизнеса, а аналитик умеет превращать их в проверяемые требования. Рабочий вариант рождается совместно: заказчик отвечает за смысл и приоритеты, команда разработки уточняет техническую реализуемость.
Можно ли начать без готового ТЗ?
Да. Для диагностики и оценки следующего шага достаточно описать пользователя, проблему, один основной сценарий и системы, с которыми предстоит работать. Полное ТЗ формируется после исследования неизвестных.
Нужно ли описывать каждую кнопку?
Нет, если макеты и общие правила интерфейса уже передают поведение. Подробность оправдана там, где действие связано с деньгами, правами, необратимым изменением данных или нетипичной логикой.
Можно ли менять ТЗ после начала разработки?
Можно, если действует управляемый процесс изменений. Новое требование оценивают по влиянию на срок, бюджет и уже сделанные части, затем принимают решение о замене, переносе или расширении объёма.
Чем ТЗ отличается от договора?
ТЗ описывает предмет и проверяемый результат работы. Договор определяет юридические условия: оплату, сроки, права, ответственность, порядок изменений и приёмки. Документы дополняют друг друга.
Источники и границы материала
- Atlassian: как составить Product Requirements Document
- Atlassian: шаблон продуктовых требований
- ISO/IEC/IEEE 29148: requirements engineering
Материал носит информационный характер. Конкретная архитектура, бюджет, режим работы с данными и уровень человеческого контроля зависят от процесса и требований компании.
Превратите идею в проверяемый контур
Пришлите описание задачи обычными словами. Мы выделим пользователей, главный маршрут, неизвестные и критерии первой версии.