Техническое задание на мобильное приложение: структура, которая экономит бюджет

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

Корень почти всегда один — слабое техническое задание или его отсутствие. ТЗ фиксирует, что именно будет сделано: функции, сценарии, экраны, интеграции, ограничения и критерии приёмки. Объём — от 20 до 100 страниц в зависимости от сложности. Готовит его аналитик, обычно на стороне подрядчика, за 1–3 недели и 150–400 тысяч рублей. Это не формальность: в студиях, где разработка мобильных приложений на заказ поставлена на поток, проработанное ТЗ снижает итоговую стоимость проекта на 20–30% — просто за счёт того, что переделок становится в разы меньше.

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

Бриф, ТЗ и документация — не одно и то же

Три документа регулярно путают, а они решают разные задачи.

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

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

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

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

Признаки хорошего ТЗ

Однозначность. Никаких «удобно», «быстро», «красиво». Вместо этого измеримые критерии: «экран каталога открывается не дольше двух секунд при медленном соединении».

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

Структурность. Документ разбит на логические блоки, а не написан сплошным текстом.

Актуальность. Есть номер версии, дата и указание, кто утвердил. Изменения не теряются в переписке.

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

Кто пишет ТЗ и сколько это стоит

Аналитик подрядчика. Самый частый и самый рабочий сценарий: человек, который понимает, как считается смета и как потом будет тестироваться результат. Стоимость — 150–400 тысяч рублей, срок — 1–3 недели. Часто оформляется отдельным договором, чтобы полученный документ можно было отнести другим студиям и сравнить предложения на одинаковом объёме.

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

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

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

Скелет документа

1. Общие сведения. Название проекта, суть идеи, ссылки на существующий сайт или сервис. Контактные лица с обеих сторон: кто принимает продуктовые решения, кто отвечает за техническую часть.

2. Цели и метрики. Что должно измениться после запуска и на сколько. «Через шесть месяцев не менее 30% онлайн-заказов оформляется через приложение», «удержание на тридцатый день не ниже 25%». Без этого раздела невозможно приоритизировать функции — все выглядят одинаково нужными.

3. Пользователи и роли. Не «все клиенты», а конкретные роли с правами: гость, зарегистрированный пользователь, оператор, администратор. Для каждой — что доступно, а что нет.

4. Платформы и устройства. iOS и Android с минимальными версиями, поддержка планшетов, требования к работе без сети.

5. Пользовательские сценарии. Пошаговые пути к цели с развилками. Удобный формат — «Как [роль], я хочу [действие], чтобы [результат]»: он заставляет проговорить цель, а не только механику. Отдельно опишите точки входа: push, deeplink, QR-код.

6. Функциональные требования по модулям. Ядро документа: авторизация, профиль, каталог, корзина, уведомления, настройки.

7. Нефункциональные требования. Производительность, надёжность, безопасность, локализация, доступность.

8. Интеграции и серверная часть. С какими системами обменивается приложение, какие API уже есть, какие нужно разработать, какие данные и в какую сторону передаются.

9. Приёмка и глоссарий. Критерии, по которым работа считается выполненной, и определения терминов — чтобы «заказ» и «заявка» значили одно и то же для всех участников.

Как описывать функции, чтобы их нельзя было понять двояко

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

Пример:

Авторизация по номеру телефона. Пользователь вводит номер в формате +7 XXX XXX-XX-XX, получает SMS с четырёхзначным кодом, срок действия кода — 5 минут. Повторная отправка доступна через 60 секунд. После трёх неверных попыток вход блокируется на 15 минут с показом сообщения. При отсутствии сети показывается экран ошибки с кнопкой повтора. Успешная авторизация создаёт сессию на 30 дней.

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

Для сложной логики удобен формат «если / то / иначе»: «Если пользователь не подтвердил почту в течение 24 часов, отправить напоминание push-уведомлением, иначе больше не напоминать».

Нефункциональные требования — то, что забывают все

Раздел, который пропускают чаще остальных, а потом удивляются проблемам.

• Производительность. Сколько одновременных пользователей выдерживает система, за сколько открывается каталог, какой объём данных считается предельным.
• Поведение при плохой связи. Что происходит в метро и в лифте: приложение показывает кэш, ошибку или белый экран.
• Работа без сети. Какие данные доступны офлайн и как разрешаются конфликты при синхронизации.
• Безопасность. Шифрование данных на устройстве, требования к хранению персональных данных, тайм-аут сессии, поведение при получении root-доступа.
• Локализация. Какие языки, как отображаются валюты и даты, что происходит с вёрсткой при длинных строках.
• Доступность. Поддержка увеличенного шрифта и экранного диктора — для медицинских и государственных сервисов это не опция.
• Совместимость. Какие версии iOS и Android поддерживаются, на каких устройствах проводится приёмка.

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

Состояния экранов: то, из-за чего спорят на приёмке

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

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

Полстраницы текста экономят несколько дней споров.

Админ-панель: раздел, который забывают чаще всего

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

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

По объёму работ админка нередко сопоставима с самим приложением. Её отсутствие в ТЗ — одна из самых дорогих неожиданностей на середине проекта.

Требования к аналитике

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

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

Уровень детализации: где расписывать до кнопки, а где нет

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

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

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

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

Версионирование и согласование

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

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

Как ТЗ превращается в смету и защищает в договоре

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

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

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

Семь ошибок в техническом задании

1. Описание интерфейса вместо требований. «Кнопка синяя, справа сверху» — это дизайн. ТЗ отвечает на вопрос, что происходит при нажатии.
2. Отсутствие приоритетов. Разделите функции на обязательные для первого релиза и на всё остальное. Иначе урезать объём под бюджет придётся в спешке и наугад.
3. Пропуск сценариев ошибок. Что происходит, когда оплата не прошла, товар закончился, сессия истекла.
4. Интеграции без деталей. «Интеграция с учётной системой» — не требование. Нужно: какие сущности, в какую сторону, с какой периодичностью, что считается конфликтом.
5. Требования, которые нельзя проверить. «Приложение работает быстро» непроверяемо. «Каталог из 5000 позиций открывается за две секунды на устройстве среднего класса» — проверяемо.
6. Противоречия внутри документа. В одном разделе гость оформляет заказ без регистрации, в другом оформление доступно только авторизованным. Лечится ревью и одним ответственным за целостность.
7. Нет процедуры изменений. Требования будут меняться. Ненормально, когда нет договорённости, как изменения оформляются и кто их оплачивает.

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

Обязательно ли ТЗ, если делаем минимальный продукт?

Да, но короткое. Для первой версии достаточно 15–25 страниц: роли, ключевые сценарии, список экранов с состояниями, интеграции, критерии приёмки.

Сколько стоит разработка ТЗ?

150–400 тысяч рублей в зависимости от сложности продукта, срок — 1–3 недели. Многие студии засчитывают эту сумму в стоимость проекта, если вы продолжаете работать с ними.

Кому принадлежит ТЗ, написанное подрядчиком?

Тому, кто за него заплатил, если это прописано в договоре. Проверьте формулировку заранее: без неё документ формально остаётся у исполнителя.

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

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

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

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

Что делать, если требования изменились в середине проекта?

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

Нужно ли ТЗ по ГОСТу?

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