Коротко: ТЗ на приложение описывает, кто пользуется приложением, какие экраны и функции в нём есть, что умеет админ-панель, с какими сервисами оно связано и на каких платформах работает. По ТЗ считают точную цену и срок, а потом проверяют, всё ли сделано. Заказчику достаточно описать идею и бизнес-задачи, а подробное ТЗ составляет аналитик разработчика.
Зачем нужно ТЗ
- Точная цена. Без ТЗ разработчик может назвать только вилку, а с ним — смету по каждой функции.
- Нет споров. Если функция описана в ТЗ, она входит в стоимость. Если нет — это доработка.
- Сравнение подрядчиков. Несколько студий считают одно и то же, а не каждая свой вариант.
- Приёмка. По ТЗ проверяют готовое приложение пункт за пунктом.
Из чего состоит ТЗ на приложение
| Раздел | Что описывают |
|---|---|
| Цели и метрики | Зачем приложение бизнесу: повторные заказы, запись онлайн, разгрузка операторов |
| Роли пользователей | Клиент, курьер, мастер, администратор — у каждого свои экраны и права |
| Пользовательские сценарии | Путь клиента по шагам: открыл → выбрал → оплатил → получил уведомление |
| Экраны и функции | Список экранов, что на каждом и что происходит при нажатии |
| Админ-панель | Что сотрудники делают через панель: товары, заказы, клиенты, push-рассылки, отчёты |
| Интеграции | Оплата (Kaspi Pay, карты), 1С, CRM, карты и геолокация, SMS, службы доставки |
| Платформы и требования | iOS, Android, веб; минимальные версии ОС; языки; офлайн-режим |
| Нефункциональные требования | Скорость, нагрузка, безопасность, хранение персональных данных |
Что заказчик может подготовить сам
- Описание бизнеса и того, какую проблему клиента решает приложение.
- Список главных функций, без которых приложение не имеет смысла.
- 2–3 приложения-примера и что в них нравится или не нравится.
- Как сейчас устроены процессы: где хранятся товары и клиенты, как принимаются заказы и оплата.
- Бюджет и желаемую дату запуска.
Этого достаточно, чтобы разработчик назвал предварительную стоимость. Подробное ТЗ с экранами и сценариями лучше доверить аналитику: он задаст вопросы, о которых заказчик обычно не думает. Например, что видит клиент, если оплата не прошла, или что происходит с заказом, когда курьер отказался.
Частые ошибки в ТЗ
- «Как у Яндекс Еды, только дешевле». Крупные сервисы годами развивались командами в сотни человек. Опишите, что нужно именно вам на старте.
- Забытая админ-панель. Приложение — только половина системы, вторая половина — панель, где сотрудники работают с заказами.
- Всё сразу. Двадцать функций в первой версии — это долго и дорого. Лучше начать с MVP и добавлять функции по отзывам пользователей.
- Нет сценариев ошибок. Нет интернета, нет товара, отменили заказ — эти случаи тоже нужно описать.
Прототип вместо длинного документа
Для приложения хорошо работает связка короткого ТЗ и кликабельного прототипа: схемы всех экранов, по которым можно «пройти» на телефоне. Прототип понятнее заказчику, чем сто страниц текста, а разработчики видят каждый экран. В MD Lab аналитика, ТЗ и прототип — первый этап разработки. Подробнее о том, что происходит дальше, — в статье «Этапы разработки мобильного приложения».
Есть идея, но нет ТЗ? Напишите в WhatsApp — бесплатно оценим проект за 24 часа. Подробнее — на странице разработки мобильных приложений.
Частые вопросы
Кто должен писать ТЗ на приложение?
Заказчик описывает идею, бизнес-задачи и главные функции. Подробное ТЗ с экранами, сценариями и интеграциями составляет аналитик разработчика — это первый этап проекта.
Можно ли начать разработку без ТЗ?
Можно получить предварительную оценку по описанию идеи, но точную цену и срок фиксируют только после ТЗ или прототипа.
Сколько времени занимает составление ТЗ?
Для MVP — обычно 1–2 недели вместе с прототипом, для сложных проектов с интеграциями — дольше.
Что важнее: ТЗ или прототип?
Лучше вместе: прототип показывает экраны и путь пользователя, а ТЗ описывает логику, админ-панель, интеграции и требования, которых не видно на экранах.