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

Ирония в том, что обе стороны часто относятся к нему формально: заказчик подписывает не глядя, студия собирает документ по шаблону. А потом на проде выясняется, что «интеграция с 1С» в голове заказчика и в голове разработчика — это две совершенно разные интеграции.

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

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

Архитектура требований: почему ТЗ — это не просто список функций

Первое, что стоит проверить, — структуру. Не отдельные формулировки, а то, как документ собран целиком. Хорошее ТЗ организовано не как перечень хотелок, а как система требований, где каждый элемент можно проследить от бизнес-цели до конкретной технической задачи.

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

Например, требование «добавить пуш-уведомления» само по себе почти бессмысленно. Какие именно уведомления? О чём? Кто их получает? В какой момент? Можно ли отключить рассылку? Ведёт ли пуш на конкретный заказ, товар или раздел приложения? Без этих ответов разработчик сделает технически рабочую механику, а бизнес получит ещё один канал, который нельзя нормально использовать.

Вот из чего обычно складывается внятная архитектура требований:

• Бизнес-требования — зачем приложению существовать. Не «нам нужно мобильное приложение», а конкретная задача: сократить нагрузку на поддержку, сделать повторные покупки удобнее, дать сотрудникам доступ к внутреннему сервису вне офиса.
• Пользовательские требования — кто и в каком контексте пользуется продуктом. «Мужчины 25–45 лет» — не портрет пользователя, а кусок презентации. В ТЗ важнее понять, что человек делает, в каком состоянии находится, как часто возвращается и какими данными уже располагает.
• Функциональные требования — что приложение должно делать. Желательно, чтобы каждое требование имело идентификатор: FR-001, FR-002 и так далее. Не ради красоты: так удобно ссылаться на конкретный пункт в обсуждении, оценке и приёмке.
• Нефункциональные требования — как именно продукт работает: скорость, стабильность, безопасность, доступность, поведение при слабой сети, ограничения по устройствам.
• Ограничения и допущения — что уже задано внешней средой. Например, серверная часть существует, авторизация идёт через корпоративный контур, дизайн должен опираться на брендбук, а часть данных нельзя хранить на устройстве.

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

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

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

Технический фундамент: совместимость с ОС и производительность

Раздел, который часто пишут для галочки. Студии любят вставить общую фразу «приложение должно работать на iOS и Android» и считать задачу закрытой. Это примерно как в строительном проекте написать «фундамент должен быть надёжным».

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

При оценке технического задания на разработку приложения стоит посмотреть на несколько вещей.

Поддерживаемые версии операционных систем

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

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

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

Типы устройств и особые режимы

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

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

Измеримые критерии производительности

Фраза «приложение должно быть быстрым» не подлежит проверке. Для одного пользователя «быстро» — это моментальное открытие каталога, для другого — возможность не потерять форму при нестабильном интернете.

Вместо оценочных слов в ТЗ нужны условия, в которых измеряется результат. Например:

Последняя строка — отдельная история. «Работа при нестабильном интернете» — это не требование, а заголовок для десятка требований. Что происходит с формой, которую человек заполнял несколько минут, если связь исчезла в момент отправки? Данные сохраняются локально или пропадают? Можно ли повторить операцию? Как приложение сообщает, что заказ уже создан, но ответ от сервера не пришёл?

Если в ТЗ написано только «приложение должно работать офлайн», в проде вы получите неодинаковое поведение на разных экранах. Потому что каждый разработчик будет самостоятельно решать, что считать офлайном и насколько далеко нужно заходить в поддержку.

Поддержка платформы — не галочка «iOS / Android». Это заранее очерченная граница: на каких устройствах, в каких версиях ОС и в каких условиях продукт обязан вести себя предсказуемо.

Логика взаимодействия: User Stories и сценарии обработки ошибок

Этот раздел — сердце ТЗ. Если здесь дыра, красивые макеты и аккуратная архитектура мало помогут: приложение может выглядеть убедительно, пока пользователь идёт по идеальному маршруту, и разваливаться при первом отклонении от него.

User Story и Use Case — два удобных формата, которые не конкурируют, а дополняют друг друга. User Story фиксирует намерение: «Как покупатель, я хочу сохранить товар в избранное, чтобы вернуться к нему позже». Use Case раскрывает механику: шаги, предусловия, альтернативные ветки, ограничения, ошибки и итоговое состояние.

Как проверить ТЗ на разработку приложения в этой части? Не читать только заголовки сценариев, а буквально пройти каждый путь пальцем — от первого экрана до результата.

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

2. Альтернативные сценарии должны быть не формальными. Пользователь добавил товар в корзину, но платёж не прошёл. Что он видит? Сохраняется ли корзина? Можно ли выбрать другой способ оплаты? Получит ли пользователь повторное списание, если нажмёт кнопку ещё раз? Формулировка «в случае ошибки показать сообщение» ничего не решает: непонятны текст, действие кнопки, возможность повторной попытки и состояние заказа.

3. Граничные условия нельзя оставлять на усмотрение команды. Что будет, если в поле имени вставили слишком длинную строку? Если один и тот же документ одновременно редактируют несколько сотрудников? Если товар закончился в тот момент, когда покупатель перешёл к оплате? Если пользователь несколько раз быстро нажал кнопку «Отправить»? Именно на таких стыках обычно появляются дорогие и неприятные дефекты.

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

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

Сценарий обработки ошибки, описанный фразой «вывести сообщение», — это не сценарий. В нём не хватает главного: что пользователь сможет сделать дальше и что станет с его данными.

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

Интеграции и API: как зафиксировать обмен данными с внешними системами

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

«Интеграция с CRM» может означать что угодно: от получения карточки клиента до двусторонней синхронизации заказов, статусов, истории коммуникаций, остатков и прав доступа. Внешне это одна строка в смете. Технически — совершенно разный объём работ.

В чек-лист ТЗ на разработку мобильного приложения здесь стоит включить следующие вопросы.

Какая система подключается и кто за неё отвечает

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

Мобильная команда не может гарантировать интеграцию с системой, к которой нет доступа, тестовых данных и человека, способного объяснить, почему поле в ответе вдруг стало пустым.

Какие данные и в каком направлении движутся

Для каждой сущности нужен отдельный ответ:

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

Сущности лучше называть прямо: пользователь, заказ, товар, остаток, адрес, статус доставки, бонусный счёт. Фраза «синхронизация данных клиента» слишком широка: она может включать только имя и телефон, а может — весь профиль с персональными и финансовыми данными.

Как устроен API и где лежат границы ответственности

REST, SOAP, GraphQL, WebSocket — не магические слова, а способ договориться о взаимодействии. В ТЗ не обязательно превращать бизнес-документ в справочник API, но должны быть зафиксированы доступные методы, форматы данных, авторизация, лимиты запросов, ожидаемые ответы и ошибки.

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

Что происходит, когда внешний сервис не отвечает

Внешний сервис может быть медленным, недоступным, возвращать неожиданный формат или менять правила авторизации. Это не повод паниковать, но повод заранее описать поведение.

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

UX/UI стандарты: от брендбука до измеримых критериев удобства

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

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

В рабочем ТЗ должны быть следующие слои.

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

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

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

Измеримые ограничения для ключевых действий. Например, число шагов до оформления заказа, обязательные поля формы, поведение автозаполнения, доступность действия одной рукой, размер интерактивных зон. Для сенсорных элементов обычно ориентируются на рекомендации платформ: Apple Human Interface Guidelines и Material Design задают минимальные комфортные размеры зон нажатия. Важнее не механически вписать цифру, а убедиться, что маленькие ссылки и иконки не окажутся недоступными на реальном устройстве.

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

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

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

Резюме: как работать с чек-листом

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

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

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

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