ТЗ на мобильное приложение: шаблон на одну страницу

ТЗ на мобильное приложение: короткий ответ

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

Шаблоны на 40 страниц, которые ты найдёшь в интернете, написаны для другой задачи: заказчик заказывает приложение у подрядчика, и ему нужен документ для договора. А ты одновременно и тот, кто принимает решения, и тот, кто строит, часто с помощью ИИ. Твоё ТЗ нужно для двух вещей: принять решения до того, как писать код, и дать Claude, ChatGPT или Cursor понятный контекст, чтобы они построили именно то приложение.

Я публикую свои собственные iOS-приложения. Solys, будильник с мини-играми, и TradaZen, симулятор трейдинга, есть в App Store. Nolera и Clic Apple отклонила, потом я их исправил. Это метод, который я применяю к каждому из них, и именно его я тебе здесь предлагаю.

Почему одной страницы достаточно, чтобы спланировать своё приложение

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

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

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

Что должно быть в ТЗ на мобильное приложение?

Ответь на каждый из этих вопросов одним-двумя предложениями.

1. Кто пользуется приложением и в какой ситуации? Не «люди 18-35 лет». Лучше конкретный человек в конкретный момент дня.
2. Какую проблему решает приложение, одним предложением? Если тебе нужно «а ещё», ты описываешь два приложения.
3. Какая ГЛАВНАЯ функция первой версии? Только одна. Остальные подождут цифр. На странице MVP iOS-приложения объясняется, как выбрать.
4. Как приложение зарабатывает? Подписка, разовая покупка или бесплатно. Этот ответ меняет приложение с первого экрана. Если сомневаешься, прочитай подписка или разовая покупка для iOS-приложения.
5. Что можно делать без создания аккаунта? Если заранее решить, что доступно без регистрации, не придётся переделывать весь онбординг.
6. Какие данные должны пережить смену телефона? Этот вопрос решает, нужен ли тебе бэкенд вроде Supabase или всё может оставаться на устройстве.
7. Только iOS или iOS и Android? Мой совет новичкам: сначала iOS. Почему, подробно объясняю в статье iOS- и Android-приложение одновременно.
8. Что явно НЕ входит в первую версию? Самый полезный раздел документа. Он обрывает споры ещё до того, как они начнутся, и с самим собой, и с ИИ.
9. Как ты поймёшь, что всё работает? Один сигнал, который можно измерить в первые недели после релиза: запущенные бесплатные пробные периоды, подписчики, пользователи, которые возвращаются.
10. Какие у тебя реальные ограничения? Сколько времени в неделю ты можешь на это тратить, твоё оборудование и аккаунт Apple Developer, который стоит 99 $ в год. Нет Mac? Это не проблема, как я объясняю в статье опубликовать iOS-приложение без Mac.

Шаблон ТЗ для копирования

Скопируй этот шаблон в заметку или в текстовый файл в корне проекта, а потом заполни каждую строку.

• Рабочее название приложения: …
• Для кого: человек, который … в момент, когда …
• Решаемая проблема, одним предложением: …
• Главная функция версии 1: …
• Что пользователь видит при первом открытии приложения: …
• Модель монетизации: подписка / разовая покупка / бесплатно, и что платное: …
• Без аккаунта можно: …
• Данные, которые сохраняются между телефонами: никакие / …
• Платформа: сначала iOS (Android позже, если цифры позволят)
• Не входит в версию 1: …, …, …
• Сигнал успеха: …
• Стек: React Native, Expo, Supabase, если нужны аккаунты, RevenueCat для подписок
• Ограничения: … часов в неделю, аккаунт Apple Developer есть или нет, Mac есть или нет
• Приложения, чей UX мне нравится, и почему: …

Добавь три-пять скриншотов приложений, которые тебе нравятся, с парой слов о том, что именно нравится. Это нагляднее, чем брендбук, и для тебя, и для ИИ.

ТЗ это не список желаний. Это список принятых решений.

Пример: заполненная страница для вымышленного приложения

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

• Для кого: студент, который вечером занимается один и отвлекается через десять минут.
• Проблема: он не может просидеть рабочую сессию, не взяв в руки телефон.
• Главная функция: запустить сессию с таймером и видеть свою серию выдержанных дней.
• Первый экран: одна кнопка, чтобы начать сессию.
• Модель монетизации: подписка на подробную статистику, базовая сессия бесплатно.
• Без аккаунта: всё, кроме синхронизации между двумя телефонами.
• Не входит в версию 1: групповой режим, рейтинг среди друзей, виджеты, версия для Android.
• Сигнал успеха: пользователи, которые возвращаются несколько дней подряд.

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

Как использовать ТЗ, чтобы направлять ИИ

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

Положи страницу в постоянный контекст проекта. Claude Code читает файл CLAUDE.md в корне, у Cursor свои файлы правил. Вставь туда ТЗ вместе со стеком. Тогда каждый запрос будет исходить из одной базы.

Ссылайся на раздел «не входит в версию 1», когда ИИ перебарщивает. Ассистенты охотно предлагают лишние функции: тёмную тему, шаринг, уведомление. Твой список исключений даёт готовый ответ: не сейчас.

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

Давай ему перечитать страницу, а не только код. Спроси: «какие вопросы в этом ТЗ размыты или противоречат друг другу?». Это недооценённый способ использовать ИИ, и он спасает от недель работы не в том направлении.

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

Превращаем решения в критерии проверки

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

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

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

Решение из ТЗ	Что проверить	Ожидаемый результат
Базовая сессия доступна без аккаунта	Установить приложение и запустить сессию без регистрации	Никакая форма регистрации не мешает старту
Прерванная сессия не засчитывается в серию	Остановить сессию до конца, затем открыть историю	Никакая завершённая сессия не добавляется
История хранится на устройстве	Завершить сессию, закрыть и снова открыть приложение	Сессия отображается один раз с правильной длительностью
Базовый таймер работает без сети	Включить авиарежим и завершить сессию	Таймер и локальное сохранение работают
Подробная статистика платная	Открыть статистику без подписки	Показывается предложение; базовая сессия остаётся доступной

Всё, что пока размыто, превращается в решения, которые нужно принять. Например: что делать, если пользователь блокирует экран или меняет время на телефоне во время сессии? Не позволяй агенту молча выбирать за тебя. Запиши нужное поведение, потом добавь этот случай в сетку. Чтобы организовать такое тестирование на реальной установке, используй гайд тестировать iPhone-приложение через TestFlight.

Что убрать, когда первая версия разрастается

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

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

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

Ловушка каталога функций

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

Хорошая первая версия делает одну вещь и делает её хорошо. Но берегись и обратной крайности: Apple требует, чтобы приложение было чем-то большим, чем упакованный сайт, согласно правилу 4.2 App Review Guidelines. Одна главная функция да; пустая оболочка нет: это причина отказа по guideline 4.2.

Чего не должно быть в ТЗ на мобильное приложение

• Полный брендбук. На старте хватит нескольких референсных скриншотов.
• План по дням. У тебя пока нет информации, чтобы его выдержать. Хватит цели на неделю.
• Детальная техническая архитектура. Выбери проверенный стек, а детали пусть решаются по ходу разработки.
• Функции «на потом», перемешанные с остальным. Все они идут в раздел «не входит в версию 1».

Когда обновлять ТЗ?

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

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

От страницы к опубликованному приложению

Если ты ответил на десять вопросов, ты уже сделал работу, которую многие проекты пропускают. Дальше: построить главную функцию, протестировать её на iPhone, подключить подписки и подготовить всё для Apple.

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

Не уверен, что твоя идея готова уместиться на одной странице? Бесплатная диагностика покажет, что сейчас тормозит твой проект и с какого этапа начать. А на главной показано, как создать мобильное приложение на основе этого ТЗ с Claude Code.

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

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

Как написать ТЗ на мобильное приложение?

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

В какой программе писать ТЗ на приложение?

Подойдёт обычная заметка или текстовый файл в корне проекта: копируешь туда шаблон и заполняешь каждую строку. Ещё можно скачать шаблон и чек-лист проверки (.md), без регистрации. Чтобы направлять ИИ, потом положи его в файл контекста проекта.

Нужно ли ТЗ на 40 страниц для приложения?

Нет, если ты делаешь своё приложение: хватит одной страницы. Шаблоны на 40 страниц из интернета написаны для заказчика, который заказывает приложение у подрядчика, и ему нужен документ для договора. А ты сам решаешь и сам строишь: твоя страница нужна, чтобы принять решения до кода и дать контекст ИИ.

Как передать ТЗ ИИ, который пишет код?

Положи страницу в постоянный контекст проекта: Claude Code читает файл CLAUDE.md в корне, у Cursor свои файлы правил. Ссылайся на раздел «не входит в версию 1», когда ИИ перебарщивает. Перед большой задачей попроси план, который соответствует странице, без немедленного написания кода.

Как проверить, что функция соответствует ТЗ?

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

Чего не стоит писать в ТЗ на приложение?

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