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

Разработка начинается с ответа на вопрос «Зачем понадобился продукт?» Например, чтобы получить доход, снизить затраты или оптимизировать процессы. Когда бизнес-цель понятна, обсуждается аудитория будущего приложения, его функции и визуал. Это надо, чтобы сформировать требования, на которые будет опираться команда разработки. Все требования делят на функциональные и нефункциональные.

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

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

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

Здесь же прописывают требования к безопасности и соответствия законам и стандартам. Особенно это касается банковских и fintech-приложений, поскольку они работают с деньгами и подпадают под жёсткое регулирование. Если компания собирает и хранит персональные данные, то надо соблюдать требования 152-ФЗ. Если проводит платежи по пластиковым картам, то стандарт PCI DSS.

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

Разберём этапы разработки бизнес-приложений.

Задача этапа: конкретизировать бизнес-задачу, проанализировать рынок и целевую аудиторию.

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

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

Задача этапа: конкретизировать требования и подготовить техническое задание.

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

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

Задача этапа: разработать дизайн, который будет решать бизнес-задачу заказчика.

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

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

Задача этапа: создать рабочую версию приложения.

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

Задача этапа: исправить ошибки, добиться стабильной работы приложения.

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

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

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

Задача этапа: оценить, насколько приложение отвечает запросам пользователей.

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

Анализ рынка и целевой аудитории, фирменный стиль и большая функциональность не гарантируют, что приложение заинтересует пользователей. Чтобы быстро оценить востребованность продукта и бизнес-модель, можно разработать минимально жизнеспособную версию продукта — minimum viable product (MVP).

MVP обычно включает 1-2 базовые функции. Его можно установить на телефон и протестировать на реальных пользователях, проверить различные гипотезы. По такому принципу развивались Uber, Amazon и многие другие компании.

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

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

Самые популярные платформы в мобильной разработке — Андроид и iOS. На первую приходится 71% рынка, на вторую — 28%. Можно создать приложение только для одной платформы, можно для обеих. Зависит от того, какими устройствами пользуется ваша потенциальная аудитория и на какой бюджет вы рассчитываете.

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

При нативной разработке приложение создают под конкретную платформу, используя определённые технологии. Разработку приложений для бизнеса для iOS ведут на языке Swift, Android-приложения пишут на Java и Kotlin. В итоге получается две независимые версии одного продукта, над каждой из которых работает отдельная команда. Поэтому стоимость нативной разработки под обе платформы выше почти в 2 раза.

Кроссплатформенность даёт возможность создать одну версию продукта, но сразу под Android и iOS. Разработчики пишут код, который работает на разных платформах. Времени в итоге уходит меньше — уменьшаются и расходы на продукт. Кроссплатформенные приложения пишут на стеке Flutter, React Native или Kotlin Multiplatform Mobile.

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

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

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

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

Для работы над продуктом подходят гибкие подходы. Это фреймворки на основе Agile.

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

На основе Agile сформировались разные фреймворки — наборы правил, которым следует команда разработки. Самый популярный из них Scrum.

Создание мобильных приложений для бизнеса по Scrum разбивается на спринты обычно по 2 недели. Каждый день команда собирается на 15-минутные Daily-скрам, чтобы обсудить задачи, оценить прогресс и внести коррективы. Спринт заканчивается обзором и ретроспективой — анализом того, что удалось сделать.

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

CI/CD расшифровывается как Continuous Integration и Continuous Delivery, что в переводе означает непрерывная интеграция и непрерывная доставка. Это набор инструментов, которые позволяют автоматизировать тестирование, сборку и развёртывание приложений на сервере.

Условно это работает так: разработчик пишет код новой функции и добавляет его в общую кодовую базу. Инструменты CI/CD автоматически запускают тестирование нового кода. Если ошибок нет, изменения автоматически публикуются на продакшн-сервере.

Что даёт такое подход:

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

Искать подрядчика можно по рекомендациям, через поиск, изучая десятки сайтов, или на основе рейтингов, например, «Рейтинга Рунета» или Tagline. В результате у вас будет список агентств, в которые можно отправить запрос. На что обратить внимание при выборе.

Есть две модели сотрудничества с агентствами: Fixed Price и Time and Materials.

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

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

Модель Fixed Price подходит вам, если:

Time and Materials (T&M) — модель, в которой оплачивают отработанные подрядчиком часы. Для этого стороны согласовывают почасовую ставку каждого специалиста. В конце месяца подрядчик считает, сколько времени команда занималась вашим продуктом, и выставляет счёт.

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

Модель Time and Materials подходит вам, если:

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

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

Функции — это конкретные действия, которые пользователи смогут выполнять в приложении. Чтобы они работали, надо написать код, нарисовать кнопки и другие UI-элементы, продумать логику смены экранов. Чем больше функций, тем больше времени надо на их разработку.

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

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

В кроссплатформенной разработке на стоимость будет влиять выбор технологий. Если создать на Kotlin Multiplatform Mobile, также нужны две команды. С приложением на Flutter или React Native справится одна команда, а значит, можно сэкономить на оплате специалистов.

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

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

Интеграция — это добавление сторонних сервисов в приложение, например социальных сетей или внутренней CRM. Чтобы реализовать это, разработчику надо потратить время, что также отражается в стоимости.

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

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