Структура технического задания на мобильное приложение: критически важные разделы

Для аналитика, дизайнера, iOS- и Android-команды — четыре разных набора предположений. В итоге пользователь получает приложение, которое формально умеет всё нужное, но на экране регистрации теряет сессию, на оплате просит лишние разрешения, а после обновления не проходит публикацию.

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

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

Начинать нужно не с экранов, а с границ продукта

В состав ТЗ для мобильного приложения обычно первым попадает описание продукта: цель, целевая аудитория, перечень экранов. Это полезно, но недостаточно. Список экранов не объясняет, что пользователь делает, в каком порядке и какой результат должен получить.

Например, «экран оформления заказа» не является требованием к функционалу. Требование появляется, когда мы фиксируем сценарий:

1. Пользователь добавляет товар в корзину без авторизации.

2. Меняет количество позиций и видит пересчитанную сумму, скидку, стоимость доставки и итог.

3. Переходит к оформлению.

4. Авторизуется, не теряя состав корзины и введённые данные.

5. Выбирает адрес, способ доставки и оплаты.

6. Получает понятный статус операции: заказ создан, платёж ожидает подтверждения, оплата не прошла, товар закончился.

7. Возвращается в историю заказов и открывает детали.

Здесь уже видно, где обычно ломается флоу: после логина, при возврате из платёжного SDK, при одновременном изменении остатков, при переключении между Wi‑Fi и мобильной сетью. Именно эти точки должны попасть в ТЗ, а не остаться в головах участников проекта.

В начале документа я бы закрепила пять вещей:

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

Последний пункт многие недооценивают. А потом оказывается, что в CRM нет поля для нужного статуса, сайт не передаёт корзину, а сервис авторизации не умеет отдать приложению данные в ожидаемом виде. Мобильный интерфейс в таких ситуациях становится витриной чужих ограничений — и пользователю от этого не легче.

Хорошее ТЗ не описывает набор экранов. Оно фиксирует путь, на котором пользователь не должен потерять данные, контекст и доверие.

Технические требования и совместимость: не прятать платформу в одну строчку

Фраза «разработать для iOS и Android» создаёт иллюзию ясности. В реальности она не отвечает даже на базовые вопросы: какие версии ОС поддерживаются, какие устройства находятся в фокусе, нужен ли планшетный сценарий, работает ли приложение в портретной и альбомной ориентации, что происходит на складных экранах, есть ли веб-версия как резервный путь.

Разделы технического задания для разработчиков должны содержать отдельный блок о платформах и совместимости. Не стоит копировать в него случайные перечни устройств из интернета. Лучше зафиксировать матрицу, которая соответствует реальной аудитории и модели использования.

Для Google Play параметр target API — не декоративная деталь сборки. Это обязательство приложения работать с актуальной моделью платформы: разрешениями, фоновыми ограничениями, поведением уведомлений и доступом к данным. Если релиз планируется после 31 августа 2026 года, для новых обычных Android-приложений и обновлений в Google Play потребуется target Android 16, то есть API level 36 или выше. Для Wear OS и Android Automotive ориентир — Android 15, API 35; для Android TV и Android XR — Android 14, API 34.

До этой даты нельзя записывать эти значения как уже действующие требования. Но в ТЗ проекта с длинным циклом разработки их необходимо учитывать как календарный риск. Особенно если продукт проходит несколько раундов согласований, интеграций и закрытого тестирования. У Google Play предусмотрена возможность запросить продление срока обновления target API до 1 ноября 2026 года, но строить релизный план вокруг исключения — слабое продуктовое решение.

Отдельно стоит описать поведение при смене состояния устройства. Пользователь не мыслит категориями жизненного цикла приложения. Он просто свернул приложение на входящем звонке, развернул его через пять минут, повернул экран или вернулся после подтверждения в банковском приложении. ТЗ должно прямо отвечать:

• сохраняется ли введённая форма;
• возвращается ли пользователь в прежнюю точку флоу;
• нужно ли заново проходить авторизацию;
• как обновляются данные, которые могли измениться на сервере;
• что приложение показывает, если ссылка, пуш или внешний диплинк ведут на недоступный объект.

Это не «краевые случаи». Для мобильного опыта это обычный день.

Безопасность и данные: описывать не абстрактную защиту, а каждый обмен

Раздел «Безопасность» часто выглядит так: «обеспечить защиту персональных данных». Эта формулировка не помогает никому. Она не говорит, какие данные есть в продукте, где они живут, как пользователь получает доступ к аккаунту, какие действия требуют повторного подтверждения и что именно передают внешние SDK.

Рабочий раздел строится от карты данных. Для каждого типа данных нужно зафиксировать:

• откуда они поступают: пользователь вводит сам, приложение получает из API, камера считывает документ, геолокация определяется устройством;
• зачем они нужны конкретному сценарию;
• где обрабатываются и хранятся;
• кому передаются: серверу продукта, платёжному сервису, аналитической системе, сервису пушей, рекламному или иному SDK;
• как пользователь может отозвать доступ или удалить данные, если такой сценарий предусмотрен продуктом;
• что происходит, если он не даёт согласие или запрещает разрешение.

Структуру требований по безопасности удобно сверять с областями OWASP MASVS: защита данных на устройстве, криптография, аутентификация и авторизация, защищённый сетевой обмен, безопасное взаимодействие с платформой, обработка кода, защита от реверс-инжиниринга и приватность. Это не волшебный сертификат безопасности и не гарантия модерации. Зато такой каркас не даёт пропустить очевидные дыры между дизайном, мобильным клиентом и серверной частью.

Особенно внимательно я смотрю на авторизацию. В ТЗ должны быть не слова «вход по номеру телефона», а набор состояний:

1. Пользователь вводит номер в допустимом формате.

2. Получает код или иной способ подтверждения.

3. Вводит неверный код, истекает срок действия кода или превышает число попыток.

4. Меняет номер, возвращается на предыдущий экран, закрывает приложение в середине процесса.

5. Восстанавливает доступ или входит на новом устройстве.

6. Выходит из профиля.

7. Сталкивается с окончанием сессии во время критичного действия.

Если приложение управляет деньгами, медицинскими данными, документами или корпоративными процессами, детализация будет ещё выше. Но даже для обычного сервиса доставки нельзя оставлять на усмотрение команды, что делать с корзиной после разлогина или как выглядят данные другого пользователя, вошедшего на том же устройстве.

Разрешения на устройстве также нужно описывать по сценарию, а не по списку API. Камера нужна для сканирования QR-кода — так и пишем. Геолокация нужна, чтобы показать ближайший пункт выдачи после нажатия «Найти рядом» — фиксируем этот момент. Push-уведомления предлагаются после того, как пользователь понял их ценность, а не на первом экране до онбординга.

Android рекомендует запрашивать только минимально необходимый набор разрешений именно в момент, когда они нужны для текущей функции. Это хороший UX-паттерн даже без оглядки на рекомендации платформы: пользователь легче даёт доступ, когда видит прямую связь между действием и запросом.

Для Google Play потребуется заполнить декларацию Data safety, включая приложения, которые не собирают пользовательские данные. Также нужна ссылка на политику конфиденциальности. В декларации учитываются не только собственные серверы продукта, но и сторонние библиотеки: аналитика, crash reporting, авторизация, реклама, карты. В ТЗ полезно назначить владельца этой инвентаризации. Иначе перед релизом команда начинает лихорадочно выяснять, что именно отправляет очередной SDK.

Для App Store заранее собирают сведения о приватности приложения и интегрированных партнёрах: они попадут в App Privacy Details на странице продукта. Эти сведения не заменяют ни политику конфиденциальности, ни согласия пользователя, ни выполнение применимых требований к обработке данных. Это отдельный слой прозрачности для стора и пользователя.

Функциональные сценарии и качество интерфейса: CJM вместо «сделать удобно»

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

Для каждой функции нужен компактный, но полный набор:

• триггер: что запускает сценарий;
• предусловия: нужна ли авторизация, сеть, активная подписка, разрешение;
• основной путь: последовательность действий пользователя и реакции системы;
• альтернативы: отмена, возврат, пропуск, выбор другого варианта;
• ошибки: нет сети, сервер недоступен, данные устарели, лимит исчерпан;
• результат: что пользователь видит, получает и может сделать дальше;
• аналитическое событие: какой шаг нужно измерять, если он влияет на продуктовую метрику.

Возьмём запись на услугу. Недостаточно написать «пользователь выбирает время». Нужны ответы: слот блокируется на время оформления или нет; что увидит человек, если другой клиент занял время секунду назад; можно ли отменить запись; приходит ли напоминание; куда ведёт пуш; что происходит, если пользователь открыл старую ссылку на уже недоступный слот.

Именно на таких переходах рождается ретеншн. Не потому, что пользователь замечает хорошо спроектированное состояние. Он его не замечает. Он просто завершает задачу без раздражения.

Дизайн-раздел в ТЗ не должен быть коллекцией вкусовых оценок вроде «современный стиль» или «минималистично». Его работа — зафиксировать паттерны, доступность и приоритеты контента. На iOS и iPadOS Apple рекомендует делать интерактивные контролы размером 44×44 pt. Минимальный размер обозначен как 28×28 pt. Для элементов с рамкой ориентиром служит примерно 12 pt свободного пространства вокруг, для элементов без видимой рамки — около 24 pt до видимых границ.

Эти цифры не стоит превращать в механическое правило для каждого пикселя. Но маленькая иконка «закрыть», прижатая к краю, или кнопка фильтра, в которую нужно попадать ногтем, убивают ощущение собранного продукта быстрее любого брендбука.

В ТЗ также стоит закрепить требования к доступности:

• текст не должен существовать только в виде изображения;
• смысл статуса не должен передаваться одним цветом;
• интерактивные элементы должны иметь понятные названия для технологий чтения с экрана;
• ошибки формы должны объяснять, что исправить, а не просто красить поле;
• при увеличенном системном шрифте критичный контент не должен исчезать за обрезанными блоками;
• порядок фокуса и навигации должен соответствовать логике экрана.

Это не факультативная полировка. Если человек не может прочитать цену, нажать кнопку или понять причину ошибки, функция для него отсутствует.

Бесшовный интерфейс — это не отсутствие экранов. Это отсутствие моментов, когда пользователь вынужден угадывать, что делать дальше.

Подготовка к публикации: сторы нужно включать в ТЗ, а не в последний спринт

Особенности написания ТЗ на iOS и Android проявляются не только в компонентах интерфейса. У платформ разные требования к публикации, метаданным, приватности и фактическому поведению приложения.

Для App Store релизная сборка должна быть финальной, с необходимыми метаданными и рабочими URL. Приложение нужно предварительно протестировать на устройстве на ошибки и стабильность. Если внутри есть авторизация, команде потребуется предоставить на ревью демо-аккаунт или заранее согласованный демо-режим. Это надо заложить в ТЗ отдельным требованием, а не искать тестовый номер телефона за час до отправки.

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

Для обеих платформ в ТЗ нужен блок релизных материалов:

• название, подзаголовок и описание;
• иконка, скриншоты и при необходимости видео;
• категории и возрастной рейтинг;
• ссылки на политику конфиденциальности и поддержку;
• контактные данные для модерации;
• инструкция для ревьюера, если есть нестандартный вход, аппаратное устройство, корпоративная интеграция или географические ограничения;
• перечень стран и языков первого релиза;
• список SDK и их роль в обработке данных;
• требования к App Privacy Details и Data safety.

Удобно разделить критерии приемки на продуктовые и сторные. Первые подтверждают, что пользователь может выполнить сценарий. Вторые — что сборку, описание, доступы и декларации можно отправлять на площадку. Это разные финиши. Продукт может выглядеть готовым на демо, но остановиться на публикации из-за нерабочей ссылки, отсутствующего тестового доступа или расхождения между декларацией и поведением SDK.

Матрица тестирования и производительность: измерять путь, а не надежду

Фраза «протестировать приложение» в ТЗ ничего не означает без матрицы. Невозможно проверить всё на всех устройствах, но можно честно определить репрезентативный набор: актуальная версия ОС, несколько распространённых сочетаний устройства и ПО у целевой аудитории, разные диагонали, реальный смартфон и эмуляторы для нестандартных форм-факторов.

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

Производительность тоже надо переводить в наблюдаемые состояния. Android рекомендует либо быстро запускать приложение, либо показывать пользователю сигнал ожидания, если загрузка занимает больше двух секунд. Это не повод рисовать бесконечный спиннер через 2,01 секунды. Лучше определить, что загружается сначала, какой контент доступен сразу и как интерфейс объясняет задержку.

Для плавности интерфейса ориентир — отрисовка кадра каждые 16 мс или быстрее, то есть около 60 кадров в секунду. Не каждое приложение одинаково чувствительно к микролагам. Но скролл каталога, раскрытие фильтров, переходы между карточками, ввод в форму и жесты на карте — те места, где задержка ощущается рукой мгновенно.

Полезно добавить в ТЗ критерии качества в человеческих формулировках:

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

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

ТЗ должно довести пользователя до результата, а не команду до формальной сдачи

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

Платформенные требования, target API, декларации приватности, размеры контролов, матрица устройств и скорость интерфейса не существуют отдельно от этого пути. Они определяют, сможет ли человек войти, выбрать, оплатить, вернуться и повторить действие через неделю без нового обучения.

Мой практический вердикт простой: если документ описывает только функции, проект почти наверняка потратит время на разночтения. Если он описывает сценарии, состояния, данные, ограничения платформ и критерии готовности, команда получает не бюрократию, а рабочий инструмент. Именно такое ТЗ сокращает число сюрпризов до релиза — и не заставляет пользователя расплачиваться за них своим терпением.