Техническое задание на приложение: шаблон и чек-лист

Техническое задание на разработку приложения — это документ на 15–40 страниц, который описывает продукт по секциям: аналитика и цели, роли пользователей, карта экранов, логика сценариев, интеграции, требования к App Store и Google Play, аналитика и поддержка. Хорошее ТЗ снижает риск переделок примерно на 30–40% и делает оценку студии точной в пределах ±10–15%, а не «вилкой» в два раза. Ниже — рабочий шаблон по секциям, чек-лист из 20 пунктов и разбор того, что забывают почти все заказчики.

Зачем вообще писать техническое задание

Без ТЗ вы платите дважды: сначала за то, что представляли вы, потом за переделку под то, что имел в виду разработчик. На наших 4 приложениях в App Store (Vitaminico, Unsweet, ShiftRest, DeskCare) мы видим устойчивую закономерность: чем детальнее описан продукт до старта, тем меньше правок на этапе приёмки и тем предсказуемее срок.

ТЗ решает три задачи одновременно. Оно фиксирует объём работ, чтобы обе стороны понимали границы проекта. Оно становится основой сметы — по нему студия считает часы, а не «прикидывает». И оно превращается в критерий приёмки: готово то, что описано, а не то, что «в целом работает».

Отдельно подчеркну: ТЗ — это не техническая простыня для программистов. Это управленческий документ. Его должен понимать и заказчик, и дизайнер, и тестировщик. Если вы не понимаете свой собственный документ, значит студия сможет трактовать его как угодно.

Структура ТЗ по секциям

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

1. Аналитика и цели продукта

Начните не с экранов, а с бизнеса. Опишите проблему пользователя, целевую аудиторию, метрику успеха (например, «удержание на 7-й день не ниже 20%») и модель монетизации. Здесь же — конкуренты и чем вы от них отличаетесь.

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

2. Роли и права пользователей

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

3. Карта экранов и пользовательские сценарии

Составьте полный список экранов и опишите переходы между ними. Формат «пользователь на экране A нажимает кнопку B и попадает на экран C, если выполнено условие D» читается однозначно. Отдельно распишите ключевые сценарии целиком: регистрация, онбординг, первое ключевое действие, оплата.

Именно сценарии, а не картинки, определяют сложность. Один и тот же экран «Профиль» может быть на два часа работы или на две недели — в зависимости от того, что за ним стоит.

4. Функциональные требования

Здесь по пунктам перечислены функции с деталями поведения. Не «поиск», а «поиск по названию и тегам, с историей последних 10 запросов, показом подсказок после третьего символа, обработкой пустого результата». Каждое такое уточнение — это либо строка в смете, либо будущий спор.

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

Платёжные системы, пуш-уведомления, аналитика, карты, авторизация через Apple/Google, CRM, ИИ-модели. Для каждой интеграции укажите, есть ли у вас доступы и документация. Интеграция с чужим API без документации — это не задача на день, это риск на несколько недель.

6. Нефункциональные требования

Поддерживаемые версии iOS и Android, минимальные устройства, локализации, офлайн-режим, требования к скорости запуска, безопасность и хранение персональных данных. Эти пункты не видны в интерфейсе, но влияют на архитектуру и стоимость сильнее многих экранов.

7. Материалы для публикации в магазинах

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

8. Аналитика и события

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

9. Поддержка и развитие после релиза

Гарантийный период на исправление ошибок, срок реакции, регламент обновлений под новые версии ОС. iOS и Android выходят каждый год, и без плана поддержки приложение начинает «сыпаться» уже через 6–12 месяцев.

Что забывают почти все заказчики

По нашему опыту приёма ТЗ от клиентов есть повторяющийся набор пробелов. Они дёшевы на бумаге и дороги в разработке.

• Пустые и ошибочные состояния. Как выглядит экран без данных, при потере интернета, при ошибке оплаты? Это половина реального кода интерфейса.
• Админ-панель. Контент кто-то должен заводить. Если панели нет в ТЗ, её нет в смете — а потом она нужна срочно.
• Уведомления. Какие пуши, когда, кому, с какой логикой отправки и что происходит по нажатию.
• Обработка подписок. Восстановление покупок, пробный период, отмена, возврат, апгрейд тарифа — десятки состояний, каждое из которых надо описать.
• Юридические экраны. Политика конфиденциальности, согласие на обработку данных, удаление аккаунта (обязательное требование магазинов приложений).
• Локализация. Даже одна дополнительная локаль меняет вёрстку — немецкие строки заметно длиннее русских и легко ломают кнопки.

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

Хорошее ТЗ против плохого

Разница между документами видна в одной таблице. Она же объясняет, почему по одному ТЗ студии дают близкие оценки, а по другому — расходятся вдвое.

Важный нюанс: сильное ТЗ не обязано быть толстым. Для MVP на 8–12 экранов хватает 15–20 страниц. Раздувать документ ради объёма так же вредно, как и экономить на деталях. MVP — это отдельная дисциплина: как отрезать лишнее и запуститься быстрее, мы обычно закладываем ещё на этапе предпроектной аналитики, до первой строки кода.

Чек-лист из 20 пунктов

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

1. Сформулирована проблема пользователя и метрика успеха.
2. Описана целевая аудитория и модель монетизации.
3. Перечислены все роли пользователей и их права.
4. Есть полная карта экранов.
5. Описаны переходы между экранами.
6. Расписаны ключевые сценарии целиком (регистрация, оплата, онбординг).
7. Для каждого экрана есть пустое и ошибочное состояние.
8. Указано поведение при отсутствии интернета.
9. Перечислены все функции с деталями поведения.
10. Описаны интеграции и наличие доступов к ним.
11. Заложена аналитика и список событий.
12. Есть логика пуш-уведомлений.
13. Проработаны подписки: пробный период, восстановление, отмена.
14. Учтена админ-панель или CMS для контента.
15. Указаны поддерживаемые версии ОС и устройства.
16. Определены локализации.
17. Есть юридические экраны и удаление аккаунта.
18. Прописаны материалы для магазинов и ответственный за публикацию.
19. Согласован аккаунт разработчика и прохождение модерации.
20. Зафиксирован гарантийный период и план поддержки.

Если хотя бы 15 из 20 пунктов закрыты, вы уже заметно опережаете большинство заказчиков по качеству постановки задачи. Оставшиеся пункты обычно уточняются на созвоне со студией.

Как ТЗ влияет на выбор подрядчика

Готовое ТЗ — это ещё и фильтр для студий. Дайте один документ трём подрядчикам. Тот, кто вернёт уточняющие вопросы по состояниям и интеграциям, разбирается в деле. Тот, кто сразу назовёт «точную» цену без вопросов, скорее всего, заложил риски в свою маржу или упростит продукт по ходу. Мы подробно разбирали критерии в статье о том, как выбрать студию разработки, а ориентиры по бюджету — в материале о стоимости разработки в 2026.

Ещё один сценарий: у вас нет ресурса писать ТЗ самостоятельно. Это нормально. Часто студия составляет документ вместе с вами на этапе предпроектной аналитики — тогда ТЗ становится первым платным этапом и одновременно защищает вас от размытых договорённостей.

С чего начать своё ТЗ

Если вы дошли до этого места, у вас уже есть каркас для собственного технического задания. Дальше — либо садиться и заполнять секции самому, либо доверить постановку тем, кто прошёл этот путь на живых продуктах. Мы в OQapps помогаем сформулировать ТЗ, оценить объём и собрать приложение под ключ за 4–6 недель — от аналитики до публикации в App Store и Google Play. Посмотреть форматы работы и оставить заявку можно на странице услуг разработки. А если вы блогер и думаете о приложении под свою аудиторию, посмотрите партнёрскую программу и формат white-label для авторов — там ТЗ мы часто берём на себя целиком.

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

Сколько страниц должно быть в техническом задании?

Для MVP на 8–12 экранов — примерно 15–20 страниц. Для полноценного продукта с админ-панелью, подписками и интеграциями — около 30–40 страниц. Объём не самоцель: важнее закрыть все секции, а не набрать листаж.

Кто должен писать ТЗ — заказчик или студия?

Идеально — совместно. Заказчик описывает бизнес-логику и цели, студия переводит это в технические требования, состояния и сценарии. Часто составление ТЗ выделяют в отдельный первый этап проекта, и это оправданно.

Можно ли начинать разработку без ТЗ?

Технически да, по методологии гибкой разработки. Но даже в этом случае нужен хотя бы список экранов, ролей и ключевых сценариев. Полное отсутствие постановки нередко приводит к переделкам и росту бюджета примерно в полтора-два раза.

Чем ТЗ отличается от дизайна и прототипа?

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

Как понять, что ТЗ достаточно детальное?

Простой тест: отдайте документ двум студиям. Если их оценки сходятся в пределах примерно 10–15%, ТЗ детальное. Если расходятся вдвое — в документе слишком много места для трактовок, и его нужно дорабатывать по чек-листу из 20 пунктов.

Евгений Агафонов

10+ лет в мобильной разработке. Основатель OQapps.

Подробнее об авторе →