Техническое задание на мобильное приложение: что в нём должно быть

Сначала — три решения, без которых ТЗ писать рано

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

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

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

Структура: 10 разделов

Порядок не случайный — он идёт от «зачем» к «как проверим». Первые три раздела пишутся за час, и уже они снимают половину недоразумений.

1. Что это и зачем — на полстраницы

Одним абзацем: что за приложение, для кого, какую задачу человека решает. Дальше — три пункта, ради которых раздел существует.

• Метрика успеха. «Считаем запуск удачным, если за первый месяц 200 регистраций и 50 оформленных заказов». Без цифры этот раздел — сочинение.
• Что мы НЕ делаем в первой версии. Самый ценный список в документе. «Нет чата с поддержкой, нет оплаты частями, нет веб-версии, нет iPad-раскладки».
• На чём проверяем идею. Если приложение делается на проверку гипотезы, скажите это прямо: команда иначе принимает решения о том, что делать надёжно, а что временно.

2. Пользователи и роли

Не «портрет ЦА» в маркетинговом смысле, а список ролей и того, что каждой доступно.

Гость          — смотрит каталог, не оформляет; при попытке оформить — экран входа
Клиент         — всё, что гость, + заказы, история, профиль, отмена заказа до статуса «в работе»
Курьер         — только список назначенных заказов, смена статуса, звонок клиенту
Администратор  — веб-панель, в мобильное приложение не входит

Здесь же — как человек становится клиентом: сам регистрируется или его заводит менеджер. Это одно предложение, а влияет оно на несколько экранов и на всю логику доступа.

3. Платформы и устройства

• iOS и Android или что-то одно; с какой версии ОС.
• Телефоны, планшеты или и то и другое. Планшет — это не «то же самое, крупнее», это отдельная раскладка и отдельные деньги.
• Ориентация экрана: только вертикальная или обе.
• Нужна ли работа без интернета и в каком объёме (посмотреть сохранённое — одно, оформить заказ офлайн — совсем другое).
• Где публикуемся: App Store, Google Play, RuStore, APK на сайте. Для российских проектов RuStore часто оказывается основным каналом, и лучше это решить до разработки, а не после.

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

4. Экраны — ссылкой на макет, а не текстом

Этот раздел в типовых шаблонах занимает две трети объёма и приносит меньше всего пользы. Замените его так:

4. Экраны и переходы
Макет: https://maketa.pro/app/?b=XXXX  (кликабельный, переходы работают)
Перечень экранов и назначение — таблица ниже.
Всё, что не видно на макете (правила, состояния, тексты ошибок), — в разделах 5 и 6.

И таблица на 5–12 строк: экран — назначение — что с него открывается. Всё. Описывать словами, что кнопка находится под заголовком, не нужно: это видно.

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

5. Функциональные требования — по сценариям, не по кнопкам

Пишите сценариями пользователя, а не перечнем элементов интерфейса. Плохой и хороший вариант одного и того же требования:

✕ Должна быть кнопка «Оформить заказ».

✓ Клиент из корзины оформляет заказ: выбирает адрес из сохранённых или вводит новый, выбирает время доставки (сегодня/завтра, интервалы по 2 часа), выбирает способ оплаты (картой онлайн или наличными курьеру), подтверждает. После подтверждения заказ появляется в разделе «Мои заказы» со статусом «Принят», клиенту приходит пуш.

Второе можно проверить, первое — нет.

Формулировки, которые снимают споры на приёмке:

• «Обязательно» / «желательно» — расставьте у каждого пункта. Без этого при нехватке времени команда сама решит, чем пожертвовать.
• Числа вместо прилагательных. Не «быстрый поиск», а «результаты поиска появляются не позже чем через 1 секунду при 10 000 позиций в каталоге».
• Границы данных. «Название до 120 символов», «до 20 фото на объявление», «телефон в формате +7XXXXXXXXXX».

6. Состояния, ошибки и пустота — раздел, который забывают все

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

Половину этих ответов можно не писать текстом, а показать отдельными экранами в макете и подписать примечаниями прямо на нём — так их точно не потеряют.

7. Интеграции и внешние сервисы

Для каждой: что за сервис, кто платит, у кого доступы, что делаем, если сервис недоступен.

Оплата          — СБП через <банк>. Договор и ключи — на стороне заказчика.
                  Если платёж не прошёл: заказ остаётся в статусе «Ожидает оплаты» 30 минут.
Пуш-уведомления — FCM (Android) / APNs (iOS). Сертификаты — заказчик.
Карты           — Яндекс.Карты, ключ заказчика, лимит запросов уточняется.
Учётная система — обмен заказами с 1С, формат и доступ — по отдельному документу.
                  На старте: выгрузка раз в 15 минут, не онлайн.

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

8. Данные, приватность и требования площадок

Раздел не про юристов, а про то, без чего приложение не пустят в стор:

• Что за персональные данные собираем и зачем (телефон, почта, геопозиция, фотографии, контакты). Для проектов в РФ — политика обработки по 152-ФЗ и согласие пользователя; страница политики должна быть по публичной ссылке ещё до подачи в стор.
• Удаление аккаунта. Google Play требует, чтобы приложение с регистрацией давало удалить аккаунт — и внутри приложения, и по внешней ссылке. Это отдельный экран и отдельная страница на сайте; забывают почти всегда.
• Разрешения: камера, геопозиция, уведомления, галерея — каждое нужно обосновать в описании для сторов, а в приложении объяснить пользователю, зачем спрашиваем.
• Возрастной рейтинг и проверка возраста. С 2025–2026 годов Apple и Google ужесточили требования к возрастным категориям и добавили механизмы определения возраста и родительского контроля; в ряде юрисдикций проверка возраста стала обязательной. Практически это означает, что экран проверки возраста и/или родительского согласия может оказаться обязательной частью онбординга, — и это экран, которого нет ни в одном типовом шаблоне ТЗ. Уточните требования площадок на момент старта: правила здесь меняются быстрее, чем любая статья.
• Аналитика: что считаем, каким инструментом, и попадает ли туда что-то персональное.

9. Дизайн и бренд

Короткий раздел, но его отсутствие дорого стоит:

• Есть ли дизайн: готовый макет в Figma, дизайн заказывается у исполнителя или «делаем на системных компонентах без дизайна». Третий вариант — законный, если сказать о нём вслух.
• Логотип, цвета, шрифты — есть ли гайдлайн и у кого исходники.
• Тёмная тема — нужна или нет. Ответ «нужна» удваивает работу по интерфейсу.
• Иконка приложения и экран запуска — кто делает.
• Языки интерфейса.

10. Приёмка — как поймём, что сделано

Раздел, ради которого стоит терпеть слово «техническое» в названии документа.

• Как принимаем: сборка на устройстве заказчика, прохождение сценариев из раздела 5, срок проверки (например, 5 рабочих дней), формат замечаний.
• Что считается ошибкой, а что новой задачей. Одна фраза, которая экономит месяцы: «Ошибка — расхождение с ТЗ или макетом. Всё, чего в ТЗ и макете нет, — новая задача и оценивается отдельно».
• Классы ошибок: блокирующая (нельзя пользоваться), серьёзная (сценарий работает с обходом), косметическая — и разные сроки исправления.
• Что передаётся: исходный код и где он лежит, сборки, доступы к сторам, инструкция на публикацию, документация на API.
• Гарантия: сколько времени ошибки чинятся бесплатно и что в гарантию не входит.
• Публикация в сторах: кто подаёт, на чьём аккаунте разработчика, кто отвечает за прохождение ревью и за доработки по требованию модерации.

Что в ТЗ писать НЕ надо

Технологии, если у вас нет причины их выбирать. «Приложение на Flutter, база PostgreSQL» — уместно, если у вас есть команда поддержки на этом стеке или совместимость с существующими системами. Иначе вы ограничиваете исполнителя, ничего не получая взамен.

Сроки внутри ТЗ. Сроки живут в договоре и в плане. В ТЗ они устаревают в первый же день и потом вносят путаницу.

Описание экранов словами при наличии макета. Дублирование — источник противоречий: через месяц макет обновили, текст нет, и на приёмке спорят, что главнее.

Требования вида «удобно», «современно», «интуитивно понятно». Их нельзя проверить, а на приёмке они превращаются во «мне не нравится». Если важен внешний вид — референсы и дизайн; если важна скорость — цифры.

Всё, что вы не собираетесь проверять. Каждый непроверяемый пункт снижает доверие к документу целиком.

Сколько это занимает

Реалистично для приложения на 5–9 экранов: разделы 1–3 — час; макет экранов — вечер; разделы 5–7 — 3–4 часа; разделы 8–10 — час, если решения уже приняты. Итого рабочий день плюс вечер, и это несравнимо дешевле, чем переделка второй половины проекта.

Если писать не хочется совсем — отдайте исполнителю макет и список правил, а ТЗ пусть напишет он, а вы вычитаете. Это нормальная практика: проверять чужой документ намного легче, чем писать свой с нуля. Опасность одна — ТЗ, написанное исполнителем, всегда описывает то, что ему удобно сделать. Поэтому раздел 10 («приёмка») читайте особенно внимательно и правьте под себя.

Частые вопросы

Чем ТЗ отличается от брифа?

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

Нужен ли ГОСТ?

Только если этого требует ваш регламент или закупка. Для коммерческого проекта важно содержание: проверяемые требования, макет и критерии приёмки. Форму диктует здравый смысл.

Может ли ТЗ заменить макет?

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

Можно ли написать ТЗ нейросетью?

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

У нас уже есть похожее приложение у конкурента. Можно написать «сделайте как у них»?

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

Что если в процессе всё поменяется?

Это норма. Заложите в договор порядок изменений: как оформляется новая задача, кто её оценивает, что происходит со сроком. ТЗ без процедуры изменений не выживает ни один проект.