«Нам нужно приложение типа Uber, только для доставки еды, и ещё чтобы курьеры были на карте» — типичный «бриф» от заказчика. Результат: оценка от 500К до 5 млн у разных подрядчиков, потому что каждый понял по-своему. Качественное ТЗ снижает разброс оценок с 5x до 1.3-1.5x и экономит 30-50% бюджета на переделках.
В этой статье — как составить ТЗ на мобильное приложение, даже если вы не технический специалист. Структура, обязательные разделы, примеры и типичные ошибки.
без ТЗ
с качественным ТЗ
подготовку ТЗ
Зачем нужно ТЗ
ТЗ (техническое задание) — не формальность и не документ «для юристов». Это инструмент, который решает три задачи:
Точная оценка стоимости. Подрядчик оценивает не «приложение», а конкретные функции: 15 экранов, интеграция с ЮKassa, push-уведомления, геолокация, чат. Каждая функция — конкретная стоимость. Без ТЗ — «от 200К до 2 млн».
Единое понимание. Вы и подрядчик одинаково представляете, что будет сделано. «Чат» для вас — мессенджер с историей, файлами и push. Для подрядчика — текстовое поле с кнопкой «Отправить». ТЗ устраняет эту разницу.
Юридическая защита. Если подрядчик не сделал функцию, которая в ТЗ — это нарушение договора. Если функция не описана — «мы так и не договаривались». ТЗ — приложение к договору.
Структура ТЗ на мобильное приложение
1. Общее описание проекта
Что за продукт, для кого, какую проблему решает. Не технический текст — бизнес-контекст.
Что включить:
Название проекта. Цель приложения (1-2 предложения). Целевая аудитория (кто будет пользоваться, 2-3 портрета пользователей). Конкуренты и аналоги (3-5 приложений, что нравится/не нравится в каждом). Бизнес-модель (как будете зарабатывать: подписка, комиссия, реклама, разовая оплата).
Пример: «Приложение для записи к частным специалистам (массаж, косметология, психология). Аудитория: женщины 25-45, Москва и СПб. Аналоги: Profi.ru (слишком универсальный), YCLIENTS (для бизнеса, а не клиентов). Бизнес-модель: комиссия 15% с каждой записи».
2. Роли пользователей
Кто использует приложение и что может делать. Для каждой роли — свой набор функций.
Типичные роли: Клиент (покупатель, пользователь). Исполнитель (продавец, курьер, мастер). Администратор (модерация, настройки, аналитика). Иногда: менеджер, партнёр, суперадмин.
Для каждой роли опишите: что видит (экраны), что может делать (действия), что не может делать (ограничения). Пример: «Клиент может отменить запись не позже чем за 2 часа. Исполнитель может заблокировать время в расписании. Админ может заблокировать исполнителя с указанием причины».
3. Функциональные требования
Ядро ТЗ. Описание каждой функции: что делает, при каких условиях, какой результат.
Формат описания функции:
Описывайте все ключевые функции в таком формате. Для MVP обычно 10-20 функций.
4. Экраны и навигация
Список всех экранов приложения с описанием элементов на каждом. Идеально — wireframes (схематичные макеты). Но и текстовое описание достаточно для оценки.
Пример описания экрана: «Экран: Список специалистов. Элементы: поле поиска (по имени и специализации), фильтры (категория, рейтинг, цена, расстояние), карточки специалистов (фото, имя, рейтинг, специализация, минимальная цена, расстояние), кнопка «Показать на карте». Действие при нажатии на карточку: переход на экран профиля специалиста».
Не обязательно рисовать в Figma — можно нарисовать от руки или описать текстом. Но чем точнее — тем точнее оценка. Подробнее о подготовке к разработке — в статье «Как составить бриф».
5. Нефункциональные требования
Технические параметры, которые не видны пользователю, но влияют на стоимость:
Платформы: iOS, Android, обе? Минимальная версия ОС (iOS 15+, Android 10+). Кроссплатформа (Flutter, React Native) или нативная разработка. Подробнее о выборе — в статье «Разработка iOS-приложения».
Производительность: ожидаемое количество пользователей (1 000 или 100 000?), максимальная нагрузка (пиковые часы), допустимое время отклика (<2 секунды для всех экранов).
Безопасность: шифрование данных, двухфакторная аутентификация, GDPR/152-ФЗ, PCI DSS (если онлайн-оплата).
Локализация: один язык или несколько? RTL-поддержка? Часовые пояса?
Офлайн-режим: что работает без интернета? Синхронизация при восстановлении связи?
6. Интеграции
Список внешних систем, с которыми приложение обменивается данными:
Платёжная система: ЮKassa, Тинькофф, Stripe. Какие способы оплаты: карта, СБП, Apple Pay, Google Pay. Подписки, автоплатежи, возвраты.
Аналитика: Firebase Analytics, Яндекс.Метрика для приложений, Amplitude, Mixpanel.
Push-уведомления: Firebase Cloud Messaging (Android), APNs (iOS), OneSignal.
Карты и геолокация: Яндекс.Карты, Google Maps, 2GIS. Геокодирование, маршруты, отслеживание.
CRM/бэкенд: 1С, AmoCRM, Битрикс24, собственное API. Что синхронизируется, в каком формате, в реальном времени или по расписанию.
Мессенджеры: WhatsApp, Telegram (для уведомлений или чата).
7. Дизайн
Описание визуального стиля: минималистичный/яркий, светлая/тёмная тема, референсы (приложения, чей дизайн нравится). Если есть брендбук (цвета, шрифты, логотип) — приложите. Если нет — это отдельная задача: 50-150К за дизайн мобильного приложения.
8. Сроки и бюджет
Ожидаемые сроки (не «как можно скорее», а конкретно: «MVP к 1 сентября»). Бюджетные ограничения: «до 500К», «до 1 млн», «зависит от оценки». Приоритеты: что обязательно в MVP, что можно отложить на фазу 2.
Что НЕ нужно включать в ТЗ
Технический стек. Не пишите «бэкенд на Node.js, база PostgreSQL». Это решает подрядчик. Вы описываете ЧТО, а не КАК. Исключение: если есть жёсткие ограничения (например, бэкенд уже на Python и менять нельзя).
Детали реализации. Не пишите «использовать WebSocket для чата» или «хранить сессии в Redis». Это технические решения подрядчика. Пишите: «Чат с историей, вложениями, индикатором «печатает», доставка сообщений < 1 секунды».
Слово «интуитивно понятный». Бессмысленное требование. Вместо этого: «Менеджер без IT-опыта должен разобраться за 15 минут без обучения» — это проверяемо.
Типичные ошибки в ТЗ
Как оценить качество ТЗ
Проверьте ТЗ по этим критериям перед отправкой подрядчику:
Тест «новый сотрудник». Дайте ТЗ человеку, не участвовавшему в обсуждении. Если он понял, что за приложение, для кого и что оно делает — ТЗ хорошее. Если задал 10+ уточняющих вопросов — доработайте.
Тест «подрядчик». Разошлите ТЗ 3 подрядчикам. Если оценки различаются менее чем в 1.5x — ТЗ детальное. Если в 3x+ — слишком абстрактное.
Проверяемость требований. Каждое требование можно проверить. «Быстрое приложение» — непроверяемо. «Время загрузки экрана < 2 секунд на iPhone 12, 4G» — проверяемо.
Полнота сценариев. Для каждой функции описаны: основной сценарий (happy path), ошибки (error handling), граничные случаи (edge cases). Если описан только happy path — бюджет вырастет на 30%.
Не обязательно писать ТЗ самостоятельно. Многие студии предлагают услугу «аналитика + ТЗ» за 50-150К. Профессиональный аналитик проведёт интервью, составит ТЗ и согласует с вами. Инвестиция окупается: точная оценка, меньше переделок, быстрее разработка. У нас эта услуга доступна в рамках разработки мобильных приложений. Также полезно прочитать «Техническое задание на разработку».
Кто должен составлять ТЗ
Заказчик (CEO/Product Owner). Описывает: бизнес-цель, аудиторию, бизнес-правила, приоритеты, бюджет. Это знание, которого нет у подрядчика.
Аналитик (со стороны подрядчика). Формализует: пользовательские сценарии, экранные формы, нефункциональные требования, интеграции. Переводит бизнес-требования на технический язык.
Оптимальная модель: заказчик пишет бриф (3-5 страниц: что, для кого, зачем, основные функции, бюджет). Аналитик подрядчика проводит 2-3 интервью и превращает бриф в полноценное ТЗ (15-30 страниц). Стоимость: 50-150К. Срок: 2-4 недели.
FAQ
Сколько времени занимает подготовка ТЗ?
Бриф от заказчика: 1-3 дня. Полноценное ТЗ с аналитиком: 2-4 недели. Для сложного приложения (маркетплейс, fintech): 4-6 недель. Не экономьте время на ТЗ — каждая неделя аналитики экономит 2-3 недели разработки и 100-300К бюджета.
Какой объём должно быть ТЗ?
Для MVP (5-10 экранов): 10-20 страниц. Для среднего приложения (15-30 экранов): 20-40 страниц. Для сложного (50+ экранов): 40-100 страниц. Если ТЗ меньше 10 страниц — скорее всего, пропущены важные детали. Если больше 100 — скорее всего, описывается реализация, а не требования.
Можно ли обойтись без ТЗ?
Для прототипа / MVP за 200-300К — можно обойтись брифом + регулярными созвонами с подрядчиком (Agile). Для проекта от 500К — ТЗ обязательно. Без ТЗ: нет фиксированной стоимости (подрядчик считает по часам), нет юридической защиты, высокий риск переделок. Time & Material без ТЗ работает только при полном доверии к подрядчику.
Что делать, если требования меняются в процессе?
Это нормально — 100% проектов меняют требования. Решение: в договоре предусмотрите процедуру Change Request (CR): описание изменения → оценка стоимости и влияния на сроки → согласование → реализация. Без CR — хаос. Бюджет на изменения: заложите 15-20% от основного бюджета.
Нужны ли wireframes в ТЗ?
Идеально — да. Wireframes (схематичные макеты экранов) убирают 80% недопониманий. Но не обязательно делать в Figma — достаточно рисунков от руки или простых схем в Miro/Balsamiq. Стоимость wireframes: 30-80К (если делает аналитик/дизайнер). Альтернатива: текстовое описание каждого экрана (элементы, действия) — менее наглядно, но работает.
Как выбрать подрядчика по ТЗ?
Разошлите ТЗ 3-5 подрядчикам. Оцените: 1) точность оценки (детальная разбивка по модулям или «примерно 1 млн»?), 2) вопросы (хороший подрядчик задаёт 10-20 уточняющих вопросов, плохой — «всё понятно»), 3) портфолио (есть ли похожие проекты), 4) процесс (Agile/Scrum, регулярные демо, CI/CD). Подробнее — в статье «Как выбрать подрядчика».