ТЗ для приложения: платформы, сторы, UX и пуш-уведомления

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

Что такое ТЗ для приложения и почему «как у топов» — плохой ориентир

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

Фразы «как у банка, но проще», «интуитивное приложение», «как у топов» — плохое ТЗ. В них нет ни платформ, ни сценариев, ни требований к сторам. Разработчик вынужден додумывать: он выбирает архитектуру и объём на свой вкус, а на приёмке выясняется несовпадение. Итог — переработка и срыв релиза.

Хорошее ТЗ отвечает на вопрос: какую задачу пользователь решает в приложении и на каких платформах? Если на это есть ответ — сценарии, платформы, сторы — задача поставлена.

Структура ТЗ на приложение

Полноценное ТЗ на мобильное приложение состоит из девяти блоков. Каждый критичен: без платформ непонятен объём, без сценариев — что строить, а без плана публикации релиз может застрять на модерации.

1. Цель и аудитория

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

2. Платформы и тип разработки

Под какие платформы делаем: iOS, Android или обе. Тип разработки: нативная или кроссплатформенная. Это ключевое решение, которое влияет на бюджет, сроки и возможности. Кроссплатформа не всегда дешевле — зависит от функционала.

3. Сценарии пользователя

Ключевые пути пользователя шаг за шагом: открыть каталог, добавить в корзину, оплатить, отследить заказ. Выделите основной сценарий и дополнительные. Сценарии — основа проектирования экранов.

4. Дизайн и UX

Есть ли готовый дизайн или его нужно создать. Требования к навигации, стилю, фирменным цветам. Референсы: приложения, которые нравятся, с пояснением что именно. Учитывайте гайдлайны платформ: Human Interface Guidelines для iOS и Material Design для Android.

5. Бэкенд и API

Нужен ли сервер и есть ли он. Какие данные хранит, какие методы отдаёт. Если бэкенда нет — это отдельная большая часть работы, её нужно явно выделить в ТЗ и бюджете.

6. Пуши и офлайн-режим

Какие уведомления отправляем и в каких событиях: статус заказа, напоминание, акция. Что работает без интернета: просмотр истории, черновики. Эти требования влияют на архитектуру.

7. Аналитика

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

8. Публикация в сторах

План релиза: аккаунты разработчика для App Store и Google Play, требования модерации, сроки рассмотрения. У каждой платформы свои правила — их нужно учесть заранее, чтобы релиз не застрял.

9. Приёмка

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

Раздел ТЗ: что писать и частые ошибки

Мини-пример: фрагмент ТЗ на приложение доставки

Чтобы было понятнее, вот как может выглядеть реальный фрагмент ТЗ на приложение доставки:

Цель: заказ еды с доставкой. Платформы: iOS и Android, кроссплатформа.

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

Пуши: уведомление о статусе заказа — принят, готовится, в пути, доставлен. Офлайн: просмотр истории заказов.

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

Релиз: публикация в App Store и Google Play, аккаунты разработчика предоставлены. Приёмка: основной сценарий проходит на реальном устройстве, пуши приходят, оплата проходит в тестовом режиме.

Такое ТЗ позволяет разработчику точно оценить объём, а заказчику — принять приложение по конкретным сценариям.

Что уточнит мобильный разработчик

Профессионал не начнёт с фразы «как у банка». Он задаст вопросы:

• Под какие платформы делаем и какой тип разработки — нативная или кроссплатформа?
• Какие ключевые сценарии пользователя и какой из них основной?
• Есть ли бэкенд или его нужно разработать с нуля?
• Какие пуш-уведомления нужны и что работает офлайн?
• Есть ли аккаунты разработчика для сторов и учтены ли требования модерации?
• Какой дизайн: готовый или с нуля, есть ли референсы?

Если заказчик не может ответить на эти вопросы, разработчику стоит сначала помочь докрутить бриф. Иначе смета и сроки окажутся непредсказуемыми.

Чек-лист ТЗ на приложение

• Определена цель и аудитория приложения.
• Выбраны платформы и тип разработки.
• Описаны ключевые сценарии пользователя.
• Прописаны требования к бэкенду и интеграциям.
• Учтены пуш-уведомления и офлайн-режим.
• Спланирована публикация в сторах с учётом модерации.
• Определены критерии приёмки на реальных устройствах.

Если на все пункты можно ответить «да» — ТЗ готово, и приложение дойдёт до релиза без сюрпризов на модерации.

Что дальше

Хорошее ТЗ экономит бюджет и сроки, вторая половина успеха — надёжный мобильный разработчик. На Workink заказчик и разработчик фиксируют договорённости в чате заказа — такая переписка имеет силу ТЗ, а деньги защищены безопасной сделкой до приёмки. Комиссия — 11% за заказ и 0% за вывод, действует доработка до результата.

Зарегистрируйтесь на Workink и закажите мобильное приложение в категории «Разработка и IT». А для смежных задач пригодятся гайды «ТЗ для сайта: структура, дизайн и приёмка» и «ТЗ для разработки ПО: как поставить задачу».