Коротко: ТЗ на мобильное приложение должно отвечать на пять вопросов — кто пользуется, что он делает, какие данные участвуют, какие ограничения действуют и как проверить, что всё работает. Всё остальное — детализация. Документ, написанный языком пользовательских сценариев и проверяемых условий, полезнее для оценки и приёмки, чем сотня страниц общих фраз вроде «интуитивно понятный интерфейс» и «высокая производительность».
Зачем нужно техническое задание
- Оценка. Без описания функций исполнители оценивают разные продукты. С ТЗ предложения становятся сопоставимыми.
- Договор и приёмка. ТЗ обычно становится приложением к договору. По нему проверяют, выполнена ли работа, и решают споры.
- Общий язык команды. Дизайнер, разработчики и тестировщики опираются на один документ, а не на разные воспоминания о созвоне.
- Независимость от исполнителя. Если придётся сменить команду, новая быстрее разберётся в продукте. Как выбрать исполнителя и что закрепить в договоре — в статье «Как выбрать подрядчика для разработки приложения».
ТЗ пишется на втором этапе проекта, после исследования и до дизайна (подробнее о последовательности — в статье «Этапы разработки мобильного приложения»). Прежде чем садиться за документ, полезно свериться с коротким списком вопросов до начала разработки (см. «Четыре вопроса до разработки»). В гибких командах документ живой: первая версия фиксирует объём MVP, дальше требования уточняются в задачах трекера, но ключевые договорённости по-прежнему записываются.
Бриф, ТЗ, спецификация, бэклог: чем отличаются
На проекте часто путают эти документы, а потом удивляются, почему подрядчик просит «ещё какое-то ТЗ», хотя бриф уже есть. У каждого документа своя задача и свой автор.
| Документ | Кто пишет | Когда | Детализация | Для чего |
|---|---|---|---|---|
| Бриф | Заказчик | До выбора подрядчика | Низкая: цели, роли, функции без деталей | Предварительная оценка сроков и стоимости, отбор подрядчиков |
| Техническое задание | Заказчик с аналитиком | После исследования, до дизайна | Средняя-высокая: сценарии, критерии приёмки, данные | Приложение к договору, основа оценки и приёмки |
| Техническая спецификация | Архитектор или тимлид исполнителя | На этапе проектирования | Высокая: API, схемы данных, экраны | Рабочий документ команды разработки |
| Бэклог | Продакт-менеджер заказчика | Весь жизненный цикл продукта | От эпика до задачи на день | Планирование спринтов и приоритизация |
Для небольшого проекта бриф и ТЗ часто объединяют в один документ; спецификация и бэклог появляются позже — но в ТЗ должно быть достаточно деталей, чтобы по нему можно было и оценить работу, и проверить результат.
Структура ТЗ: разделы и их содержание
Для коммерческих мобильных приложений обычно не требуется следовать государственным стандартам. Для государственных и корпоративных автоматизированных систем используют ГОСТ 34.602-2020 «Техническое задание на создание автоматизированной системы» (действует с 1 января 2022 года); его структуру можно взять за основу и для крупного проекта, но для небольшого приложения она избыточна. Практичная структура выглядит так:
| Раздел | Что описать |
|---|---|
| 1. Общие сведения | Название, цель продукта, бизнес-задача, критерии успеха, глоссарий терминов |
| 2. Пользователи и роли | Кто пользуется (клиент, сотрудник, администратор), права каждой роли |
| 3. Пользовательские сценарии | Истории и сценарии первой версии с приоритетами |
| 4. Функциональные требования | Детальное поведение по экранам и модулям, правила и ограничения |
| 5. Данные | Сущности, поля, откуда берутся данные, какие персональные данные собираются |
| 6. Интеграции | Внешние системы, способы обмена, что делать при их недоступности |
| 7. Нефункциональные требования | Платформы и версии ОС, производительность, офлайн, безопасность, доступность, локализация |
| 8. Дизайн | Ссылки на прототип и макеты, брендбук, требования к адаптивности и тёмной теме |
| 9. Администрирование | Функции панели управления, кто наполняет контент, отчёты |
| 10. Аналитика | Какие события и метрики отслеживаются |
| 11. Публикация и передача | Магазины, аккаунты, состав передаваемых материалов (код, документация, доступы) |
| 12. Приёмка | Критерии приёмки, порядок тестирования, гарантийный период |
Пользовательские сценарии: как описывать функции
Удобный формат — пользовательская история: «Как [роль], я хочу [действие], чтобы [ценность]». К каждой истории добавляются критерии приёмки — проверяемые условия, при выполнении которых функция считается готовой.
История: Как клиент, я хочу перенести свою запись на другое время, чтобы не звонить администратору.
Критерии приёмки:
- кнопка «Перенести» доступна в карточке будущей записи не позднее чем за 2 часа до её начала;
- при переносе показываются только свободные слоты того же специалиста на ближайшие 30 дней;
- после подтверждения старый слот освобождается, новый — занимается атомарно (два клиента не могут занять один слот);
- клиент получает push-уведомление и видит обновлённую запись в разделе «Мои записи»;
- администратор видит перенос в панели управления с отметкой «перенесено клиентом»;
- при отсутствии интернета кнопка неактивна, показывается сообщение о необходимости подключения.
Такое описание сразу отвечает на вопросы, которые иначе возникли бы у дизайнера, разработчика и тестировщика, и позволяет исполнителю точно оценить работу.
Плохие и хорошие формулировки
| Размыто | Проверяемо |
|---|---|
| Приложение должно быстро работать | Главный экран открывается не дольше 2 секунд на устройстве уровня [модель] при подключении 4G |
| Удобная регистрация | Регистрация по номеру телефона с кодом подтверждения; повторная отправка кода не чаще раза в 60 секунд |
| Интеграция с 1С | Остатки товаров синхронизируются из 1С каждые 15 минут; заказ передаётся в 1С в момент оплаты; при ошибке — повтор 3 раза и уведомление администратору |
| Поддержка всех устройств | iOS 17 и новее, Android 9 и новее; экраны от 4,7 до 6,9 дюйма; планшеты — в режиме растянутого интерфейса без отдельной вёрстки |
| Безопасное хранение данных | Токены хранятся в Keychain/Keystore; обмен с сервером только по HTTPS; пароли на сервере — в виде хеша |
| Удобная админка | Администратор добавляет, редактирует и скрывает товар за 3 действия; изменение появляется в приложении не позднее 5 минут; в списке товаров есть поиск по названию и артикулу |
| Приложение отправляет уведомления | Push о смене статуса заказа отправляется в течение 1 минуты после изменения в админке; пользователь отключает уведомления по категориям в настройках; немаркетинговые уведомления не отправляются с 22:00 до 8:00 по местному времени |
Значения в правом столбце — примеры формулировок; конкретные версии ОС и пороги выбираются под вашу аудиторию.
Нефункциональные требования
Их чаще всего пропускают, а потом именно из-за них возникают споры при приёмке. Минимальный набор:
- Платформы и версии. Минимальные версии iOS и Android, поддержка планшетов, ориентация экрана; чем старее поддерживаемые версии, тем больше тестирования. Отдельно стоит зафиксировать технологию разработки — от неё зависят сроки выхода на вторую платформу (см. «Нативная или кроссплатформенная разработка»).
- Производительность. Время запуска и загрузки ключевых экранов, работа с большими списками, размер приложения.
- Работа без сети. Что доступно офлайн, как синхронизируются изменения, как разрешаются конфликты.
- Безопасность. Способ авторизации, хранение токенов, шифрование, срок сессии, защита API, журналирование действий администраторов.
- Персональные данные. Перечень собираемых данных, место хранения (для пользователей из России — базы данных на территории РФ), согласия и удаление аккаунта. Подробно — в статье «Персональные данные в мобильном приложении».
- Доступность. Поддержка экранного диктора, системного размера шрифта, достаточный контраст.
- Локализация. Языки интерфейса, форматы дат и валют.
- Нагрузка. Ожидаемое число пользователей и пиковых запросов — важно для серверной части.
Требования магазинов, которые надо заложить в ТЗ
Часть требований задаёт не бизнес, а правила магазинов приложений. Не учесть их в ТЗ — значит дорабатывать продукт уже после сдачи, перед самой публикацией.
- Удаление аккаунта изнутри приложения. App Store требует, чтобы приложения с созданием аккаунта позволяли инициировать удаление прямо внутри приложения, а не через письмо в поддержку (Guideline 5.1.1(v)); временной деактивации недостаточно. Google Play требует того же плюс веб-ссылку для запроса удаления аккаунта и данных — она должна работать, даже если пользователь уже удалил приложение с телефона.
- Политика конфиденциальности и формы магазинов. В ТЗ стоит указать, кто готовит текст политики и кто заполняет анкету о данных при публикации — у Apple это App Privacy, у Google Play — форма Data safety. Ошибки в этих анкетах — частая причина отклонения при модерации.
- Возрастной рейтинг. Указывается при подаче в любой магазин; в RuStore используется шкала, аналогичная PEGI (0+, 6+, 12+, 16+, 18+). Весь путь до витрины по шагам — в статье «Публикация приложения в RuStore, App Store и Google Play».
- Встроенные покупки цифровых товаров. Для продажи цифровых товаров и подписок App Store и Google Play требуют собственные платёжные механизмы (In-App Purchase и Google Play Billing) с комиссией магазина; оплата физических товаров и офлайн-услуг сторонними системами обычно разрешена отдельно — это стоит прописать в разделе про монетизацию.
Отдельно — технические требования 2026 года, которые стоит заложить как ограничение по версии SDK и срокам публикации:
| Требование | App Store | Google Play | RuStore |
|---|---|---|---|
| Версия сборки | С 28.04.2026 — Xcode 26, SDK iOS 26 | С 31.08.2026 — target API level 36 (Android 16); продление до 01.11.2026 по запросу в Play Console | Сборка проходит обязательную проверку при публикации; технические требования сверяйте с актуальным гайдом RuStore |
| Статус разработчика | Физлицо, ИП, юрлицо | Физлицо, ИП, юрлицо | Физлицо, самозанятый, ИП, юрлицо; с 01.02.2026 самозанятым недоступны платёжные SDK RuStore — для монетизации нужен переход на ИП/ЮЛ |
| Язык описания | Любой, с локализациями | Любой, с локализациями | Основное описание — на русском |
Что чаще всего забывают описать
Список пробелов, который стоит пройти перед отправкой ТЗ исполнителям:
- Администрирование. Кто и как добавляет товары, услуги, новости, отвечает на обращения? Без панели управления приложение невозможно эксплуатировать.
- Уведомления. Какие события вызывают push, e-mail или SMS, можно ли их отключить, в какое время они не отправляются.
- Состояния экранов. Загрузка, пустой список, ошибка сети, нет прав доступа, устаревшая версия приложения.
- Разрешения. Когда и с каким объяснением запрашивается доступ к камере, геолокации, уведомлениям; что происходит при отказе.
- Удаление аккаунта. App Store требует, чтобы в приложениях с созданием аккаунта была возможность инициировать его удаление изнутри приложения; Google Play тоже требует способ запросить удаление аккаунта и данных.
- Принудительное обновление. Механизм, который попросит пользователя обновиться, если старая версия несовместима с сервером.
- Аналитика. Какие события отслеживать, чтобы проверить критерии успеха — этому стоит посвятить отдельный раздел ТЗ, а не оставлять на усмотрение разработчика.
- Юридические тексты. Политика конфиденциальности, пользовательское соглашение, согласия — кто их готовит и где они размещаются.
- Передача результатов. Исходный код, доступы к репозиторию, серверам, аккаунтам магазинов, документация по развёртыванию.
- Гарантия и поддержка. Сколько длится гарантийный период и что в него входит.
Как проверить ТЗ перед отправкой подрядчикам
Пройти документ самому дешевле, чем потом разбирать разные по смыслу предложения от подрядчиков из-за нечёткого текста.
- Прочитать глазами тестировщика. По каждому пункту: можно ли однозначно проверить, что он выполнен? Ответ «смотря как понимать» — сигнал переписать формулировку.
- Найти расплывчатые слова. «Быстро», «удобно», «современный дизайн» — за каждым должна стоять измеримая величина или ссылка на макет.
- Пройти каждую роль по сценариям. Буквально прожить путь клиента, сотрудника и администратора от входа до завершения задачи, включая ошибки.
- Сверить с чек-листом. Пройтись по пунктам ниже и убедиться, что каждый отражён в тексте, а не только подразумевается.
- Дать прочитать будущему пользователю. Человеку вне обсуждений: если сценарии и термины ему непонятны, разработчику будет ещё сложнее.
- Запросить у 2–3 подрядчиков список уточняющих вопросов. Их количество и качество — хороший индикатор пробелов в документе.
Кто пишет ТЗ и сколько это занимает
Есть три рабочих варианта:
| Вариант | Плюсы | Минусы |
|---|---|---|
| Заказчик пишет сам | Лучше всех знает бизнес-задачу; документ не зависит от исполнителя | Технические разделы могут быть неполными; нужен опыт |
| Исполнитель на этапе аналитики | Технически грамотно, сразу с оценкой | Документ может быть заточен под конкретную команду и её стек |
| Независимый аналитик | Нейтральный документ для тендера между несколькими исполнителями | Дополнительные расходы и время |
Частый и разумный компромисс — заказчик описывает цели, роли и сценарии (разделы 1–3), а технические разделы готовятся вместе с исполнителем на оплачиваемом этапе аналитики. На небольшое приложение это обычно занимает от одной до нескольких недель, в зависимости от числа интеграций и скорости согласований.
Если по ТЗ вы собираетесь выбирать подрядчика, отправьте всем кандидатам один и тот же документ и попросите оценку по его разделам — так предложения будет проще сравнивать.
Короткий шаблон для старта
Если полноценное ТЗ пока не нужно, для первичной оценки достаточно брифа на 2–3 страницы:
- Цель продукта одной фразой и критерий успеха через 3–6 месяцев после запуска.
- Роли пользователей (2–4) и по 3–5 главных сценариев для каждой.
- Список функций первой версии с пометками must / should / could — подход подробно описан в статье «MVP мобильного приложения».
- Платформы: iOS, Android, веб; минимальные версии ОС.
- Интеграции с существующими системами и сервисами.
- Какие персональные данные собираются.
- Примеры приложений, которые нравятся, и что именно в них нравится.
- Желаемые сроки, бюджетные рамки и кто принимает решения со стороны заказчика.
Такой бриф позволяет получить предварительные оценки и понять, какие вопросы нужно проработать в полном ТЗ. Как оценки превращаются в бюджет — в статье «Сколько стоит разработка мобильного приложения».
Чек-лист готового ТЗ
- Каждая функция привязана к роли и сценарию
- У сценариев есть проверяемые критерии приёмки
- Описаны состояния ошибок и работа без сети
- Перечислены интеграции и поведение при их сбое
- Указаны платформы и минимальные версии ОС
- Описаны персональные данные и место их хранения
- Учтены требования магазинов: удаление аккаунта, возрастной рейтинг, политика конфиденциальности
- Есть раздел об админке и уведомлениях
- Определён состав передаваемых результатов
Частые вопросы
Нужно ли ТЗ, если мы работаем по Agile?
Нужно, но в другой форме. Вместо исчерпывающего документа — видение продукта, бэклог пользовательских историй с критериями приёмки и описание нефункциональных требований. Важно, чтобы договорённости фиксировались письменно и были доступны всей команде.
Сколько страниц должно быть в ТЗ?
Объём не показатель качества. Для небольшого приложения может хватить 10–20 страниц со сценариями и критериями; для системы с интеграциями и несколькими ролями документ будет больше. Проверяйте полноту по чек-листу, а не по числу страниц.
Можно ли использовать ТЗ, подготовленное одним исполнителем, для работы с другим?
Зависит от условий договора на подготовку ТЗ. Если вы за него заплатили, закрепите в договоре переход прав на документ к вам — тогда его можно использовать свободно.
Нужно ли прикладывать дизайн к ТЗ?
Желательно хотя бы вайрфреймы ключевых экранов. Они снимают множество вопросов, которые сложно описать словами. Финальные макеты обычно готовятся после утверждения требований.
Как зафиксировать изменения требований после подписания ТЗ?
Через согласованную процедуру: запрос на изменение, оценка влияния на срок и бюджет, письменное согласование. В гибких моделях оплаты это проще, в фиксированной цене — через дополнительные соглашения.
Сколько стоит подготовка ТЗ и кто за неё платит?
Это отдельная оплачиваемая работа аналитика, её обычно оценивают в часах: от нескольких часов на бриф до пары недель на подробный документ с интеграциями. Платит заказчик, если нанимает независимого аналитика или пишет сам, либо часы включены в оплачиваемый этап аналитики у исполнителя. Бесплатное «полноценное ТЗ» от подрядчика чаще всего на деле короткое коммерческое предложение.
Нужно ли ТЗ для MVP?
Да, но в сокращённом виде: роли, 3–5 ключевых сценариев с критериями приёмки, платформы, минимальный набор данных и требования магазинов — без второстепенных функций, которые попадут в следующие итерации.
Итог
Хорошее техническое задание описывает продукт глазами пользователей и в проверяемых условиях: роли, сценарии, критерии приёмки, данные, интеграции, ограничения и состав результата. Оно не обязано быть длинным, но должно закрывать пробелы, из-за которых проекты чаще всего выходят за рамки: админка, уведомления, состояния ошибок, удаление аккаунта, требования магазинов, аналитика и передача доступов.