Как составить ТЗ на мобильное приложение: структура, примеры, ошибки
ТЗ на мобильное приложение — это документ, который фиксирует цель продукта, список экранов и функций, роли пользователей, требования к интеграциям и критерии приёмки. Грамотное ТЗ состоит из 8–10 разделов, пишется языком проверяемых формулировок и экономит заказчику от 20% бюджета разработки за счёт отсутствия переделок.
Зачем нужно ТЗ и сколько стоит его отсутствие
За 19 лет работы и 300+ проектов мы в Applications.kz видели одну и ту же закономерность: проекты без внятного ТЗ дорожают и затягиваются не из-за плохих программистов, а из-за разного понимания задачи. Заказчик представлял «приложение как Glovo», подрядчик сделал «каталог с корзиной» — формально обе стороны правы, по факту продукт переделывается.
Техническое задание решает три практические задачи:
- Фиксирует объём работ. Смета и сроки считаются от конкретного списка функций, а не от ощущений. Без этого любая оценка сроков разработки приложения — гадание.
- Служит арбитром в спорах. Когда возникает вопрос «это входит в договор или это доработка за отдельные деньги?» — ответ ищут в ТЗ, а не в переписке.
- Позволяет сравнивать подрядчиков. Три студии, получившие одно ТЗ, дадут сопоставимые сметы. Три студии, получившие устный рассказ, дадут цены, отличающиеся в 3–4 раза.
Цена ошибки конкретна: переделка архитектуры на середине проекта в Казахстане в 2026 году обходится в 1,5–4 млн ₸ — это стоимость 1–2 месяцев работы команды, которые уходят не на новые функции, а на исправление недопонимания.
Структура ТЗ: 9 обязательных разделов
Универсального ГОСТа для мобильных приложений нет, но рабочая структура, по которой мы принимаем проекты в работу, выглядит так.
1. Цель и бизнес-контекст
Один абзац: какую проблему решает приложение, кто платит и за что. Пример формулировки: «Приложение позволяет клиентам сети автомоек записываться на услуги без звонка. Цель — снизить нагрузку на администраторов и уменьшить долю незаполненных слотов».
2. Целевая аудитория и роли
Перечислите все типы пользователей: клиент, курьер, менеджер, администратор. У каждой роли — свой набор экранов и прав. Пропущенная роль на этапе ТЗ — это целый незапланированный интерфейс на этапе разработки.
3. Платформы и устройства
iOS, Android или обе; минимальные версии ОС; нужна ли планшетная вёрстка; нативная разработка или кроссплатформа (Flutter). От этого выбора зависит до 40% бюджета — подробнее мы разбираем это на странице о разработке мобильных приложений.
4. Карта экранов и пользовательские сценарии
Самый важный раздел. Списком или схемой: все экраны приложения и переходы между ними. Каждый ключевой сценарий описывается по шагам: «Пользователь открывает каталог → выбирает товар → добавляет в корзину → оформляет заказ → получает push о статусе».
5. Функциональные требования
По каждой функции — что именно она делает. Не «авторизация», а «вход по номеру телефона с SMS-кодом, повторная отправка кода через 60 секунд, автологин при повторном открытии».
6. Интеграции
Платёжные системы (Kaspi Pay, Halyk, Freedom Pay), 1С или CRM, SMS-шлюзы, карты, аналитика. Для каждой интеграции укажите: есть ли у сервиса API, есть ли у вас доступы и кто отвечает за них со стороны заказчика.
7. Нефункциональные требования
Языки интерфейса (для Казахстана типично русский + казахский), офлайн-режим, время отклика, ожидаемая нагрузка, требования к хранению персональных данных.
8. Админ-панель и серверная часть
Что должен видеть и редактировать администратор: товары, заказы, пользователей, push-рассылки, статистику. Админку часто забывают в ТЗ, хотя по трудозатратам она сопоставима с самим приложением.
9. Критерии приёмки
Как заказчик поймёт, что работа выполнена: «заказ, оформленный в приложении, появляется в 1С в течение 30 секунд», «приложение опубликовано в App Store и Google Play». Каждый критерий должен быть проверяемым.
Примеры формулировок: как нельзя и как нужно
Качество ТЗ определяется не объёмом, а проверяемостью формулировок. Сравните:
| Плохо (нельзя проверить) | Хорошо (можно проверить и оценить) |
|---|---|
| «Удобная регистрация» | «Регистрация по номеру телефона: ввод номера → SMS-код из 4 цифр → ввод имени. Не более 3 экранов» |
| «Приложение должно быстро работать» | «Каталог из 500 товаров открывается не дольше 2 секунд на устройствах 2022+ года» |
| «Интеграция с 1С» | «Выгрузка остатков и цен из 1С:Управление торговлей 8.3 каждые 15 минут; заказы из приложения создаются в 1С со статусом «Новый»» |
| «Push-уведомления» | «Автоматические push при смене статуса заказа (4 статуса) + ручные рассылки из админки по сегментам: все / неактивные 30 дней» |
| «Красивый современный дизайн» | «Дизайн в фирменных цветах по брендбуку (приложен); референсы: [2–3 ссылки на приложения]; тёмная тема не требуется» |
Правило простое: если по формулировке нельзя однозначно ответить «сделано или не сделано» — её нужно переписать.
Типовые ошибки в ТЗ, которые мы видим чаще всего
- ТЗ описывает мечту, а не первую версию. В документ попадает всё: бонусная программа, чат, видеозвонки, AI-рекомендации. Бюджет растёт до неподъёмного, запуск откладывается на год. Правильный подход — выделить ядро и запустить MVP мобильного приложения, а остальное вынести в «версию 2».
- Забытая админ-панель. Описаны 30 экранов для клиента и ни одного для администратора. На смете это означает +30–50% к озвученной цене.
- Нет негативных сценариев. Что видит пользователь без интернета? Что происходит при отклонённой оплате? Если этого нет в ТЗ, разработчик решит сам — и не всегда так, как удобно вашему бизнесу.
- «Как у конкурента, только лучше». Ссылка на чужое приложение — хороший референс, но не замена ТЗ: вы не знаете, какие функции конкурента реально используются, а какие убыточны.
- Интеграции «на словах». «У нас есть CRM, нужно подключить» — а у CRM нет API, или доступ к нему стоит отдельных денег. Проверяйте техническую возможность интеграций до подписания договора.
- Смешение ТЗ и дизайна. Требование «кнопка должна быть синей слева» — не для ТЗ. Документ фиксирует «что делает система», макеты — «как это выглядит».
Кто пишет ТЗ и сколько это стоит в Казахстане
Есть три рабочих варианта, и у каждого своя цена и свои риски.
| Вариант | Стоимость (₸, 2026) | Кому подходит |
|---|---|---|
| Пишете сами по структуре из этой статьи | 0 ₸ (ваше время) | Простые приложения до 15 экранов, типовые сценарии |
| Нанимаете независимого бизнес-аналитика | 300 000 – 800 000 ₸ | Средние проекты, когда нужен нейтральный документ для тендера |
| Discovery-этап в студии (аналитика + прототип + смета) | 400 000 – 1 200 000 ₸ | Сложные продукты с интеграциями, маркетплейсы, финтех |
В Applications.kz discovery-этап включает интервью с заказчиком, карту экранов, кликабельный прототип и детальную смету — и оформляется отдельным договором. Это честная схема: получив документы, вы вправе уйти с ними к любому подрядчику. На фоне бюджета разработки в 5–20 млн ₸ вложение 5–8% в проработку требований — самая дешёвая страховка из существующих.
Чек-лист: проверьте ТЗ перед отправкой студии
- Цель приложения описана одним абзацем, и из неё понятна бизнес-модель.
- Перечислены все роли пользователей, включая администратора.
- Есть полный список экранов — посчитайте их, это база для оценки.
- Каждая функция описана проверяемой формулировкой.
- Для каждой интеграции подтверждено наличие API и доступов.
- Указаны языки интерфейса и платформы с минимальными версиями ОС.
- Описаны негативные сценарии: нет сети, ошибка оплаты, пустые состояния.
- Функции разделены на «первая версия» и «потом».
- Сформулированы критерии приёмки.
Если по 7–8 пунктам из 9 ответ «да» — документ готов к оценке. Пришлите его нам на разбор: мы работаем с заказчиками из Алматы и всего Казахстана, а также на рынках ОАЭ и Таиланда — детали на странице разработки мобильных приложений в Алматы. Смету по готовому ТЗ даём за 24 часа: +7 (707) 928-13-15.
Частые вопросы
Какой объём должен быть у ТЗ на мобильное приложение?
Объём вторичен, важна полнота. Для простого приложения на 10–15 экранов достаточно 5–8 страниц со списком экранов и проверяемыми формулировками. Для продукта с интеграциями, несколькими ролями и админкой нормальный объём — 20–40 страниц. ТЗ на 100 страниц чаще говорит о воде, чем о проработке.
Можно ли начать разработку без ТЗ?
Технически да — по гибкой модели с оплатой за время команды. Но для заказчика с фиксированным бюджетом это риск: без зафиксированного объёма невозможно назвать финальную цену. Компромисс — короткий discovery-этап: за 2–3 недели появляются прототип и смета, и только потом подписывается договор на разработку.
Чем ТЗ отличается от брифа?
Бриф — это анкета на 1–2 страницы о бизнесе, целях и пожеланиях; он нужен для первичной оценки «вилкой». ТЗ — детальный документ с экранами, сценариями и критериями приёмки, который становится приложением к договору. Бриф отвечает на вопрос «о чём проект», ТЗ — «что именно будет сделано».
Кто должен оплачивать составление ТЗ — заказчик или студия?
Проработка требований — это работа аналитика, дизайнера и технического специалиста, поэтому она оплачивается заказчиком: в Казахстане это 300 000 – 1 200 000 ₸ в зависимости от сложности. Бесплатное «ТЗ» от студии обычно означает поверхностный документ, риски которого позже закладываются в цену разработки.
Нужно ли ТЗ, если у меня уже есть дизайн-макеты?
Да. Макеты показывают интерфейс, но не описывают логику: что происходит при ошибке оплаты, как считается скидка, откуда берутся данные, как работает админка и интеграции. Связка «макеты + ТЗ» — идеальный комплект: по ней любая студия даст точную смету без скрытых допущений.