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

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

Почему возникают ошибки в техническом задании на мобильное приложение

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

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

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

Что обязательно должно быть в ТЗ на мобильное приложение

ТЗ — не описание ради галочки, а документ, по которому считают часы разработки. Хорошее ТЗ отвечает не на вопрос «что построить», а на вопрос «как разработчик посчитает часы и с чем сверит готовый результат». Чем точнее он составлен, тем меньше сюрпризов всплывает после старта работы.

Роли пользователей и сценарии

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

Интеграция с учётными системами

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

Выбор технологии

Если приложение по сути — мобильный интерфейс к учётной системе без сложной кастомной логики, в ТЗ стоит рассмотреть вариант на 1С:Мобильной платформе: она быстрее внедряется там, где не нужен полностью нативный интерфейс с индивидуальным оформлением каждого экрана.

Критерии приёмки

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

Этапы и сроки

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

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

Сюда входит то, что не видно на макетах: поддерживаемые платформы и версии ОС, требования к хранению данных на устройстве, срок автономной работы офлайн-режима. Отдельно указывают, на каких реальных устройствах тестируют приложение перед сдачей — это особенно важно для складских сканеров и терминалов, которые часто работают на устаревших версиях Android. Если приложение обрабатывает персональные данные сотрудников или клиентов — ФИО, телефоны, адреса доставки, — ТЗ должно учитывать требования 152-ФЗ о персональных данных. Для приложений, которые компания планирует использовать в госзакупках, отдельно фиксируют необходимость включения в реестр российского ПО.

Как исправить ТЗ, если разработка уже забуксовала

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

Дальше составляют короткий документ с изменениями, аддендум к ТЗ, а не переписывают всё техническое задание заново: так согласование занимает дни, а не недели. Такой подход подходит и для случаев, когда исходное ТЗ вообще отсутствовало, а разработка шла по переписке в мессенджере — аудит восстанавливает картину по факту сделанного и превращает её в документ, с которым можно двигаться дальше. Для проектов с интеграцией в 1С:Управление торговлей или Комплексную автоматизацию это обычно 5-10 пунктов, которые снимают большую часть неопределённости и позволяют вернуть проект в график без остановки команды.

Что делать, если ошибки в ТЗ повторяются на каждом проекте

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

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

Как предотвратить ошибки в ТЗ на старте

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

Мы собираем такое ТЗ на разработку мобильных приложений с прототипом и картой интеграций до старта работы, чтобы бюджет не менялся через два месяца после запуска. Примеры того, как это выглядит для торговых и сервисных компаний, — на странице B2B-приложение с 1С. Разработка мобильного приложения с нуля начинается от 500 000 рублей — точную сумму называют после детального ТЗ, форматы работ и условия смотрите в разделе цены и тарифы.

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

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

Стоимость ТЗ считают отдельно от разработки и зависит от количества ролей, экранов и интеграций. Сама разработка мобильного приложения с нуля начинается от 500 000 рублей — точную сумму называют после детального ТЗ с прототипом, когда понятен объём работ по интерфейсу и обмену данными с учётными системами.

Что обязательно указывать в ТЗ, если приложение интегрируется с 1С?

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

Сколько времени занимает разработка ТЗ на мобильное приложение?

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

Можно ли начать разработку без детального ТЗ, только по краткому брифу?

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

Нужно ли учитывать в ТЗ требования 152-ФЗ о персональных данных?

Да, если приложение хранит или передаёт данные сотрудников или клиентов — ФИО, телефоны, адреса доставки. В ТЗ фиксируют, где и как хранятся эти данные, кто имеет к ним доступ и как обеспечена защита в соответствии с требованиями 152-ФЗ. Это требование действует независимо от того, где физически размещён сервер приложения.