Форматы технического задания для мобильного приложения: документ, презентация или прототип

В реальном проде этот миф обычно разбивается о первый же экран авторизации, где внезапно вспоминаются SSO, двухфакторная аутентификация, восстановление доступа, политика хранения токенов и старый CRM-сервис, который отвечает только по будням и только если с ним разговаривать особым тоном.

Форматы ТЗ для разработки мобильного приложения — не вопрос эстетики и не выбор между Word, Figma и красивыми слайдами. Это способ распределить риск. Текст фиксирует обязательства. Прототип снимает споры о поведении интерфейса. Презентация продаёт идею и объясняет контекст. Если пытаться заставить один формат выполнять работу трёх, на выходе получается дорогой набор костылей, конфликтов и формулировок вроде «мы думали, это очевидно».

Для небольшой внутренней утилиты иногда хватает пары user stories и макетов. Для банковского клиента, медицинского сервиса или приложения, которое встраивается в легаси-ландшафт предприятия, такой оптимизм превращается в технический долг ещё до первого деплоя. Формат ТЗ должен соответствовать не размеру PDF, а цене ошибки.

Классический документ: когда без ГОСТ 34.602-89 не обойтись

Классическое ТЗ — это текстовый документ, где требования к системе изложены последовательно: назначение, функции, ограничения, роли пользователей, требования к данным, интеграциям, безопасности, приёмке и сопровождению. Он может оформляться по ГОСТ 34.602-89, принятому ещё в 1989 году, или опираться на принципы международного стандарта ISO/IEC/IEEE 29148 по работе с требованиями.

Не нужно делать вид, что любой мобильный стартап обязан открывать ГОСТ и страдать. Не обязан. Но в государственных контрактах и крупных enterprise-проектах формальный документ часто не роскошь, а обязательная часть процесса. Там требуется зафиксировать, что именно будет поставлено, на каких условиях система принимается, кто за что отвечает и как новый мобильный клиент стыкуется с остальной инфраструктурой.

В таких проектах приложение — редко самостоятельный продукт. Обычно оно сидит на цепочке зависимостей:

• API-шлюз с собственными лимитами, версиями и авторизацией;
• бэкенд, где часть методов появилась вчера, а часть пережила три смены технологического стека;
• корпоративные справочники, CRM, ERP, MDM или IAM;
• требования к журналированию, хранению персональных данных, мониторингу и аварийному восстановлению;
• процессы приёмки, где фраза «ну оно же работает» имеет примерно нулевой юридический вес.

Документ полезен не тем, что в нём много страниц. Польза появляется, когда в нём можно найти однозначный ответ на вопрос, который на проекте обязательно возникнет. Например: приложение при потере сети показывает данные из локального кеша или блокирует операцию? Какие поля обязательны при создании заявки? Что происходит, если сервер принял платёж, а мобильный клиент не получил ответ по таймауту? Какая версия API поддерживается после релиза? Кто владеет ошибкой между мобильным приложением, API gateway и внешней системой?

Если этих ответов нет, формально красивое ТЗ остаётся литературой. Иногда в жанре фэнтези.

Что текстовое ТЗ фиксирует лучше остальных форматов

У документа есть сильные стороны, которые Figma не перекроет даже самым аккуратным набором фреймов:

1. Границы работ и ответственность сторон. В контрактной разработке это фундамент. Без него «добавьте ещё одну мелочь» быстро становится бесконечной очередью изменений.

2. Нефункциональные требования. Производительность, доступность, безопасность, аудит, поддерживаемые версии ОС, требования к логированию и аналитике не живут в макетах. Их надо формулировать словами и, где возможно, измеримыми критериями.

3. Интеграционные контракты. Описание API, форматов данных, кодов ошибок, сценариев повторной отправки, очередей и идемпотентности нельзя заменить картинкой кнопки «Отправить».

4. Приёмку. Документ задаёт критерии, по которым заказчик и команда понимают, что работа завершена, а не просто «выглядит похоже».

5. След изменений. В длинных проектах требования меняются. Нормально. Ненормально — не понимать, какая договорённость была актуальна на момент реализации конкретной функции.

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

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

Текстовый формат работает, если он поддерживается как живой артефакт: с версиями, статусами требований, ссылками на решения и понятным процессом изменения scope. Если после подписания файл лежит в папке final_final_3_точнофинал.docx, это уже не документация. Это легаси в зачатке.

Интерактивный прототип: хорош для экранов, слаб для архитектуры

ТЗ на разработку приложения в виде прототипа стало почти стандартным ответом для продуктовых команд. И это логично. Кликабельный сценарий в Figma или Axure показывает пользовательский путь быстрее и точнее, чем десять страниц описания переходов: человек открывает экран, нажимает кнопку, видит следующее состояние. Меньше пространства для трактовок. Меньше шансов, что дизайнер имел в виду одно, аналитик описал другое, а мобильный разработчик собрал третье.

Прототип особенно полезен, когда основная неопределённость лежит в UX, а не в сложной интеграционной части. Он хорошо отвечает на практические вопросы:

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

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

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

Кнопка в Figma не знает про idempotency key. Ей и не положено.

Антипаттерн: «всё есть в макетах»

Фраза «всё есть в макетах» знакома каждому, кто хоть раз принимал мобильный релиз. Обычно она означает, что на макетах есть happy path: пользователь авторизовался, получил данные, нажал кнопку, увидел результат. Прод между тем специализируется на unhappy path.

В боевых приложениях нужно отдельно договориться как минимум о таких состояниях:

• сервер недоступен или отвечает дольше допустимого времени;
• пользователь ушёл в фон во время отправки формы;
• сеть переключилась с Wi‑Fi на мобильную и запрос оборвался;
• данные изменились на сервере, пока пользователь редактировал их локально;
• токен истёк посреди сценария;
• API вернул ошибку, которую нельзя показывать пользователю как NullPointerException;
• пуш пришёл на устройство, где пользователь уже разлогинен;
• приложение обновилось, а структура локального хранилища изменилась.

Прототип не обязан описывать всё это визуально до последнего пикселя. Но его надо связать с текстовыми правилами, спецификациями API и задачами в backlog. Иначе дизайнерский сценарий станет красивой обложкой для набора предположений.

Презентация концепции: полезна до того, как начинается инженерия

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

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

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

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

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

Хорошая презентация оставляет после себя не иллюзию готовности, а список решений, которые надо оформить дальше:

1. Какие пользовательские сценарии войдут в первый релиз, а какие сознательно отложены.

2. Какие внешние системы критичны для запуска.

3. Какие технические неизвестные требуют исследования или прототипирования.

4. Какие ограничения уже приняты: платформы, авторизация, поддержка офлайна, целевые устройства.

5. Какие показатели определят, что первая версия принесла пользу, а не просто вышла в стор.

Гибридный подход: backlog, прототип и документация без религиозных войн

Agile-команды часто отказываются от монолитного ТЗ в пользу user stories и backlog в Jira или Notion. Это здравое движение, пока оно не вырождается в набор карточек с описанием «как пользователь хочу быстро и удобно». Быстро и удобно — не критерий. Это открытка от продуктовой мечты.

Рабочая схема для мобильной разработки обычно гибридная. В ней каждый артефакт отвечает за свой слой неопределённости.

User story фиксирует ценность и роль: кому нужна функция, какую задачу она решает, какой ожидается результат. Например, сотрудник выездной службы должен видеть назначенные заявки и менять их статус без звонка диспетчеру.

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

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

Техническая спецификация описывает API, модель данных, авторизацию, миграции, аналитику, особенности платформ и эксплуатационные требования. Именно здесь живут детали, которые превращают «изменить статус заявки» в реализуемую функцию.

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

В такой модели backlog не отменяет документацию. Он дробит работу на поставляемые куски. Прототип не отменяет требования. Он делает их визуально проверяемыми. А документ не отменяет разговоры. Он сохраняет результат разговора после того, как люди разошлись по календарям и начали помнить его по-разному.

Agile не означает «без документации». Он означает «без документа, который притворяется заменой обратной связи».

Как определить глубину описания до старта

Выбирать формат ТЗ для приложения стоит по четырём признакам, а не по привычке руководителя проекта.

• Цена ошибки. Если некорректная операция влияет на деньги, персональные данные, юридически значимые действия или производственный процесс, текстовая фиксация требований и сценариев приёмки нужна глубже.
• Количество интеграций. Чем больше внешних систем и владельцев, тем меньше шансов вывезти проект на одних макетах. Интеграция — это не стрелочка на слайде, а контракт, доступы, лимиты, ошибки и сопровождение.
• Стабильность предметной области. Если бизнес-процесс давно установлен и меняется редко, подробная спецификация окупается. Если команда ищет product-market fit, тяжёлый документ может стать якорем.
• Зрелость команды. Сработавшаяся команда с аналитиком, дизайнером, мобильными разработчиками и понятным API может держать значительную часть контекста в коротких артефактах. Новый подрядчик, распределённая команда или несколько вендоров требуют более явных договорённостей.

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

Риски выбора формата: документация не лечит баги

Есть ещё один популярный миф: подробное ТЗ гарантирует отсутствие багов. Нет. Документ снижает количество ошибок из-за неясных требований. Это уже много. Но он не отменяет дефекты реализации, проблемы инфраструктуры, ошибки API, недооценённые нагрузки, особенности конкретных устройств и человеческий фактор. Последний, как всегда, самый производительный.

Баги появляются и в проектах с идеальными документами. Особенно если требования не тестируются на реальных сценариях, стенд не похож на прод, а QA получает сборку за день до релиза с просьбой «посмотреть по-быстрому». Бумага не спасает от отсутствия observability, от непродуманного rollback и от деплоя в пятницу вечером. Тут даже ГОСТ бессилен.

Плохой выбор формата обычно проявляется не на первой демонстрации, а позже:

• команда реализует не тот сценарий, потому что бизнес-цель была только в голове у заказчика;
• API меняется без версии и ломает уже опубликованный клиент;
• дизайнер передал один экран, а разработчик не получил состояний загрузки и ошибок;
• функции принимаются «на глаз», потому что нет критериев готовности;
• новая команда не может понять, почему система работает именно так, и начинает чинить легаси новыми костылями;
• каждая доработка превращается в спор о первоначальных договорённостях.

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

Вердикт: выбирать надо не носитель, а уровень риска

Классический документ оправдан там, где приложение становится частью большого контура, работает с критичными данными, проходит формальную приёмку или связывает несколько систем с разными владельцами. ГОСТ 34.602-89 и подходы ISO/IEC/IEEE 29148 здесь полезны как дисциплина: они заставляют не забыть про границы, требования и приёмку.

Интерактивный прототип в Figma или Axure нужен, когда команда обсуждает поведение мобильного интерфейса. Он быстрее текста снимает спор о переходах, состояниях и логике экрана. Но за красивыми стрелками не живут безопасность, API, синхронизация и эксплуатация.

Презентация нужна для решения о продукте, а не для передачи задачи в разработку. Она собирает контекст, помогает договориться о целях и границах. Дальше её обязан подхватить backlog, прототип и техническая спецификация.

Для большинства живых мобильных продуктов разумный выбор — гибрид. Короткие проверяемые user stories, кликабельные пользовательские сценарии, отдельные спецификации на интеграции и зафиксированные архитектурные решения. Не бюрократия ради бюрократии. И не Figma как универсальная религия.

Хорошее ТЗ не выглядит самым толстым документом в папке проекта. Оно выглядит как команда, которая перед релизом спорит о продукте и рисках, а не о том, что вообще собиралась сделать.