Техническое задание — один из самых непонятных документов для заказчика. Кажется, что нужно описать каждую кнопку и каждый пиксель. Или наоборот — достаточно написать «сделайте как у Uber, только для нашего бизнеса». Оба подхода ведут к проблемам. Первый — к бесконечному согласованию, второй — к тому, что результат не совпадёт с ожиданиями.
В этой статье расскажем, что должно быть в ТЗ на мобильное приложение, как его составить и какие ошибки обходятся дороже всего.
Зачем нужно ТЗ
ТЗ решает три задачи:
Фиксирует договорённости. После всех обсуждений, встреч и переписок ТЗ становится единым источником правды. Это документ, к которому возвращаются при разногласиях: «Мы договорились, что здесь работает так».
Позволяет точно оценить стоимость. Без ТЗ оценка сроков и бюджета — это гадание. С ТЗ — обоснованный расчёт, в котором каждая функция имеет понятную трудоёмкость.
Ускоряет разработку. Разработчик, который работает по ТЗ, не тратит время на додумывание бизнес-логики. Он знает, что должно произойти при каждом действии пользователя.
Что должно быть в ТЗ
1. Описание продукта и целей
Краткое описание: что за продукт, для кого, какую задачу решает. Это контекст для всей команды. Разработчик, который понимает бизнес-логику, принимает лучшие технические решения.
2. Пользовательские роли
Кто будет пользоваться приложением? Часто ролей несколько: клиент, администратор, курьер, менеджер. У каждой роли свой набор функций и свой интерфейс.
3. Функциональные требования
Это ядро ТЗ. Для каждого экрана и каждой функции описывается:
- Что видит пользователь
- Какие действия может совершить
- Что происходит в результате каждого действия
- Как обрабатываются ошибки и граничные случаи
Пример хорошего описания:
«Экран оформления заказа. Пользователь видит список товаров в корзине, итоговую сумму, поле для промокода и кнопку «Оформить заказ». При нажатии на кнопку система проверяет наличие товаров, рассчитывает стоимость доставки на основе адреса и переводит на экран оплаты. Если товар закончился после добавления в корзину — показываем уведомление и убираем его из списка.»
Пример плохого описания:
«Корзина. Стандартный функционал.»
4. Интеграции
С какими внешними системами должно работать приложение: платёжные системы, CRM, ERP, сервисы доставки, SMS-провайдеры, карты. Для каждой интеграции — что именно передаётся и в какую сторону.
5. Нефункциональные требования
Требования к производительности (время загрузки экрана), доступности (процент uptime), безопасности (шифрование, аутентификация), поддерживаемым устройствам и версиям ОС.
Чего НЕ должно быть в ТЗ
Технической реализации. ТЗ описывает «что», а не «как». Выбор языка программирования, архитектуры, фреймворков — это зона ответственности команды разработки. Заказчик, который диктует технические решения, обычно ограничивает команду и получает худший результат.
Избыточной детализации. Не нужно описывать размер шрифтов и отступы — для этого есть дизайн-макеты. ТЗ описывает логику, а не визуал.
Размытых требований. «Приложение должно быть быстрым» — не требование. «Экран загружается не более 2 секунд при скорости подключения 10 Мбит/с» — требование.
Кто должен составлять ТЗ
Частый вопрос: должен ли заказчик писать ТЗ самостоятельно? Короткий ответ — нет.
Заказчик знает свой бизнес, но не знает, как структурировать требования для разработки. Идеальный вариант — составлять ТЗ совместно с командой подрядчика:
- Заказчик описывает бизнес-логику, ограничения, приоритеты
- Продуктовый аналитик или менеджер структурирует информацию, задаёт уточняющие вопросы, находит пробелы
- Дизайнер визуализирует сценарии через прототипы
- Технический специалист оценивает реализуемость и предлагает оптимальные решения
Результат совместной работы всегда качественнее, чем ТЗ, написанное одной стороной.
Типичные ошибки при составлении ТЗ
Описывать решение вместо задачи. «Нужна кнопка отправки push-уведомления» — это решение. «Нужна возможность напомнить пользователю о брошенной корзине» — это задача. Формулируя задачу, вы даёте команде возможность найти лучшее решение.
Не описывать граничные случаи. Что происходит, если пользователь оформил заказ, а ресторан закрылся? Если при оплате произошла ошибка? Если два пользователя заказали последний товар одновременно? Граничные случаи — это 80% проблем после запуска.
Перегрузить MVP. Первая версия ТЗ часто содержит всё, что хочется когда-либо увидеть в продукте. Чёткое разделение на MVP и последующие итерации — обязательно.
Зафиксировать и забыть. ТЗ — живой документ. В процессе разработки появляется новая информация, и ТЗ должно обновляться. Жёсткое следование устаревшему ТЗ — такая же ошибка, как работа без ТЗ.
Итоги
Хорошее ТЗ — это не толстый документ, а точное описание того, что должен делать продукт. Оно фиксирует бизнес-логику, определяет границы проекта и позволяет точно оценить бюджет. Составлять его лучше совместно с командой разработки — так вы получите документ, который реально работает, а не пылится в папке.
Нужна помощь с подготовкой ТЗ для мобильного приложения? Обсудим ваш проект — поможем структурировать требования и определить scope.
