Как подготовить мобильный проект к оценке

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

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

Почему мобильный проект сложно оценить по одной идее

Формулировка «нужно мобильное приложение для клиентов» описывает направление, но не объём проекта. За ней могут стоять очень разные решения:

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

Даже два продукта с одинаковым количеством экранов могут требовать разного объёма аналитики, дизайна, мобильной разработки, backend, тестирования и интеграций.

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

1. Определите бизнес-цель и границы первого релиза

Начните не с технологий, а с результата. Ответьте на три вопроса:

1. Какую задачу бизнеса решает продукт?
2. Для кого он создаётся?
3. Какой результат должен быть достигнут после первого релиза?

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

После определения цели разделите функции на четыре группы:

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

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

2. Опишите роли пользователей и права доступа

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

Для каждой роли зафиксируйте:

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

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

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

3. Составьте карту ключевых сценариев

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

Для каждого приоритетного сценария опишите:

1. с чего начинает пользователь;
2. какие шаги он выполняет;
3. какие данные вводит или получает;
4. какие системы участвуют;
5. что происходит при успешном завершении;
6. что происходит при ошибке, отмене или потере соединения.

Полезный формат - короткая таблица:

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

4. Укажите платформы и устройства

Нужно заранее определить, для каких платформ и устройств создаётся продукт:

• iOS;
• Android;
• обе мобильные платформы;
• планшеты;
• web-кабинет;
• специализированные устройства или терминалы.

iOS и Android отличаются требованиями к интерфейсам, разрешениям, публикации и тестированию. Дополнительный объём появляется при поддержке старых версий операционных систем, планшетов, нестандартных разрешений экрана, Bluetooth, камеры, геолокации, push-уведомлений и других функций устройства.

Если приложение уже существует, приложите статистику используемых устройств и версий операционных систем. Если такой статистики нет, это нужно указать как неизвестное, которое может повлиять на объём тестирования.

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

5. Опишите backend, данные и API

Мобильный интерфейс редко является самостоятельным продуктом. Для его работы могут понадобиться:

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

Если backend уже существует, подрядчику нужно передать его документацию и описать ограничения. Важно проверить:

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

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

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

6. Зафиксируйте внешние интеграции

Интеграция с внешней системой - это не только один вызов API. На объём работ влияют данные, авторизация, ошибки, лимиты, повторные запросы и изменения на стороне поставщика.

Для каждой интеграции укажите:

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

Часто в мобильных продуктах встречаются интеграции с CRM, ERP, платёжными сервисами, каталогами, системами учёта, картами, уведомлениями и внутренними сервисами компании.

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

7. Опишите нефункциональные требования

Функциональные требования отвечают на вопрос «что делает система». Нефункциональные требования описывают, «как именно она должна работать».

В оценку могут влиять:

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

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

8. Отдельно определите требования к безопасности

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

До оценки зафиксируйте:

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

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

9. Перечислите зависимости и ответственность заказчика

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

Зафиксируйте, кто предоставляет:

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

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

10. Разделите требования, допущения и риски

Хорошая оценка показывает не только список работ, но и уровень определённости.

Удобно разделить информацию на три группы:

Подтверждённые требования

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

Допущения

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

Риски

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

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

11. Как оформить проект для запроса предложений или тендера

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

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

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

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

12. Какой пакет подготовить для подрядчика

Для первого обсуждения обычно достаточно следующего набора:

1. Одноабзацное описание бизнес-задачи.
2. Список ролей пользователей.
3. Три-пять ключевых сценариев.
4. Перечень нужных платформ и устройств.
5. Список существующих систем и интеграций.
6. Описание текущего приложения или backend, если они уже есть.
7. Прототипы, брендбук и другие материалы.
8. Требования к безопасности и данным.
9. Желаемый срок и ограничения проекта.
10. Ориентир бюджета, если он определён внутри компании.

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

Чек-лист перед обращением к подрядчику

Перед отправкой запроса проверьте:

• понятна ли бизнес-цель;
• выделен ли первый релиз;
• описаны ли роли и права доступа;
• перечислены ли ключевые сценарии;
• указаны ли iOS, Android, web и нужные устройства;
• понятно ли, существует ли backend;
• перечислены ли внешние системы;
• обозначены ли требования к безопасности;
• определены ли критерии готовности;
• указаны ли зависимости от заказчика;
• отмечены ли неизвестные и допущения;
• предусмотрен ли процесс изменения требований.

Если на несколько вопросов пока нет ответа, это не причина откладывать проект. Но эти вопросы нужно вынести в отдельный этап исследования, а не скрывать внутри предварительной оценки.

FAQ

Можно ли оценить мобильное приложение по количеству экранов?

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

Нужно ли готовить полное техническое задание до обращения к подрядчику?

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

Что делать, если backend уже есть?

Передать документацию, описать ограничения и предоставить доступ к тестовому контуру. Нужно проверить API, авторизацию, форматы данных, обработку ошибок и готовность backend к новым сценариям.

Можно ли сразу запросить фиксированную цену?

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

Нужно ли описывать все будущие функции?

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

Как подготовить проект с AI-агентом?

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

Итог

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

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

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