Как написать ТЗ на мобильное приложение в 2027 году: шаблон

Что такое ТЗ на приложение и чем оно отличается от брифа

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

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

Хорошая новость: вам не нужно писать ТЗ как инженер на 80 страниц. Достаточно 3–6 страниц простого текста по шаблону ниже. Подрядчик допишет технические детали сам, но он не может придумать за вас, что нужно вашему бизнесу.

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

Шаблон ТЗ на мобильное приложение: 10 разделов

Скопируйте этот список в документ и заполните каждый пункт, пусть даже одной-двумя фразами. Пустой раздел — это вопрос, который всё равно придётся решать, но позже и дороже.

1. Цель и измеримый результат. Одна фраза: «клиенты записываются сами, и 30 % записей приходят через приложение». Без цифры допустимо, но тогда напишите, по чему вы поймёте успех.
2. Пользователи и роли. Кто пользуется: клиент, мастер, администратор, курьер. У каждой роли свои экраны и права.
3. Платформы. iOS, Android или обе; нужен ли планшет; хватит ли сайта, который ставится на телефон как приложение (PWA), или нужны магазины приложений. Если сомневаетесь, сначала сравните приложение, сайт и PWA по стоимости и задачам.
4. Карта экранов. Список всех экранов и стрелки между ними: вход, главный, каталог, карточка, корзина, профиль. Можно нарисовать от руки и сфотографировать.
5. Сценарии. По шагам, что делает человек: «открыл, выбрал услугу, выбрал время, оплатил, получил напоминание».
6. Функции с приоритетами. Три колонки: «без этого запускать нельзя», «хорошо бы», «потом». Это самый важный раздел для бюджета.
7. Данные и подключения. Где хранятся пользователи и заказы, с чем связываемся: оплата, CRM, учёт, карты, почта, мессенджеры.
8. Нефункциональные требования. Скорость, работа без интернета, языки, безопасность, доступность (подробнее ниже).
9. Публикация и аккаунты. На чьё имя заводятся аккаунты разработчика, кто пишет описание для магазинов, какие страны.
10. Приёмка и этапы. Как проверяем результат, сколько кругов правок, как делим оплату по этапам.

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

Требования к мобильному приложению: функциональные и нефункциональные

В документе с требованиями (по-английски app requirements document) обычно два типа записей. Функциональные описывают, что приложение делает: «пользователь может перенести запись не позже чем за 2 часа». Нефункциональные описывают, как хорошо оно это делает: быстро, безопасно, понятно, на нужных языках. Именно вторые чаще всего забывают, а потом спорят.

Пример для приложения записи в салон

Роль «клиент». Регистрация по номеру телефона с кодом из СМС. Каталог услуг с ценой и длительностью. Выбор мастера и свободного времени. Предоплата картой. Напоминание за сутки и за 2 часа. Отмена бесплатна не позже чем за 24 часа. Роль «администратор»: расписание мастеров, список записей, возвраты, рассылка акций.

Это функциональная часть. К ней добавляем нефункциональную:

• Скорость. Главный экран открывается без заметной задержки на среднем телефоне пятилетней давности.
• Связь. Что видит клиент без интернета: последнюю запись или сообщение об ошибке? Полноценный офлайн-режим стоит отдельных денег.
• Языки и валюты. Сколько языков интерфейса, в какой валюте цены, как выглядят даты.
• Безопасность и данные. Какие личные данные хранятся, кто их видит, как человек удаляет свой аккаунт. Если вы работаете в вашей стране, уточните требования к персональным данным у юриста: для ЕС это GDPR.
• Доступность. Крупный шрифт, контраст, подписи для экранных читалок. Это и удобство, и требование некоторых рынков.
• Устройства. С какой версии iOS и Android поддерживаем и на каких экранах проверяем.

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

Что записать в ТЗ про App Store и Google Play

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

• Аккаунты разработчика. Apple берёт $99 в год, Google Play — $25 один раз. Мы оформляем приложение на ваш аккаунт, поэтому записывайте, кто его заведёт и кто хранит доступы.
• Готовая версия для проверки. По правилам Apple (раздел 2.1, «полнота приложения») на проверку отправляют законченную сборку: без заглушек и временных страниц, с рабочими ссылками, а если есть вход в аккаунт — с демо-доступом для проверяющего, и серверная часть в этот момент должна работать. В ТЗ это превращается в пункт приёмки: «тестовый аккаунт и описание для проверяющего готовы».
• Тестирование для Google Play. Для новых личных аккаунтов разработчика Google требует закрытое тестирование: не менее 12 тестировщиков, подключённых 14 дней подряд, и только потом открывает выпуск для всех. Заложите эти две недели в срок или заводите аккаунт организации; актуальные условия смотрите в справке Google Play.
• Тексты и картинки для магазинов. Описание, скриншоты, политика конфиденциальности, возрастной рейтинг. Кто их пишет и на каких языках.
• Платежи. Если в приложении продаются цифровые товары или подписки, у магазинов есть свои правила и комиссии. Для физических товаров и услуг правила другие. Запишите, что вы продаёте, и подрядчик подскажет нужную схему.

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

Пять ошибок в ТЗ, из-за которых растут сроки и цена

1. Нет приоритетов. Когда всё «очень нужно», оценка включает всё, а первую версию вы запускаете через полгода вместо двух месяцев. Разделите функции на «обязательно», «хорошо бы» и «потом».
2. Нет критериев приёмки. «Красиво и удобно» нельзя проверить. «Запись создаётся не более чем за четыре касания» — можно.
3. Забыта админка и роли. Приложение для клиента — половина продукта. Вторая половина — инструмент вашей команды.
4. Размытые интеграции. «Связать с CRM» означает разные объёмы работы для разных систем. Назовите систему и опишите, какие данные куда идут.
5. Нет ответственного. Если решения от вашей стороны принимают три человека, проект тормозит на согласованиях. Назначьте одного, кто говорит «да» или «нет».

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

Проверьте, готово ли ТЗ к оценке

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

Кто должен писать ТЗ: вы, подрядчик или вместе

Есть три рабочих сценария, и выбор зависит от того, насколько ясна ваша идея.

• Вы пишете сами по шаблону. Подходит, если идея простая, а вы знаете свою аудиторию. Получите несколько оценок и сравните их.
• Подрядчик пишет по вашему брифу. Удобно, но помните: чем подробнее документ, тем точнее смета. Бесплатное ТЗ нередко превращается в «ТЗ под нашу цену», поэтому спросите, кому оно принадлежит, если вы выберете другую команду.
• Платная предпроектная работа. Для сложных продуктов (роли, оплаты, несколько систем) мы делаем это отдельным этапом: архитектурная сессия за €3 500. На выходе карта продукта, смета и план первой версии. Эта сумма засчитывается в проект, а сама карта остаётся у вас в любом случае, даже если вы потом выберете другую команду.

Если нужны экраны, а не только текст, добавьте дизайн и прототип, от €1 990: кликабельный прототип на телефоне объясняет идею лучше десяти страниц описания. В готовых пакетах приложения дизайн уже входит.

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

Что выбрать в вашей ситуации

• Идея простая: один сценарий, одна роль. Заполните шаблон сами, отправьте двум-трём командам и сравните ответы. Приложение на iOS и Android у нас от €10 900, точная сумма считается в смете после ТЗ.
• Есть несколько ролей, оплата, интеграции. Не пишите всё вслепую: начните с архитектурной сессии и получите ТЗ в виде карты продукта и сметы.
• Нет уверенности, что приложение вообще нужно. Возможно, хватит сайта на телефоне или Telegram-приложения. Сравните варианты и стоимость до того, как писать документ.
• Уже есть ТЗ от другой студии. Покажите его нам и другим подрядчикам: один документ, несколько предложений. Как честно сравнить ответы, разбирает статья как сравнить подрядчиков и коммерческие предложения.
• Нужно запуститься как можно быстрее. Опишите только обязательные функции и отдайте остальное во вторую версию.

Не знаете, с чего начать? Пройдите квиз «Готовы ли вы к разработке своего продукта?»: 17 вопросов, персональный разбор и скидка на разработку по промокоду, который придёт письмом на вашу почту (кроме «Сайта за 24 часа»). Он покажет пробелы в идее и поможет выбрать формат старта в вашем городе или удалённо.