Разработка мобильных приложений для бизнеса: как создавать кроссплатформенные решения быстро и относительно дешево

Меня зовут Валерьян Брунин, я сооснователь и директор ILAVISTA. Мы разрабатываем сложные комплексные продукты: веб-платформы и мобильные приложения, CRM- и ERP-системы, уникальные продукты для стартапов и мобильные приложения для классического бизнеса.

За этот год мы силами одной команды разработчиков создали с нуля и зарелизили 6 приложений для Android и iOS. В этой статье я расскажу, как выстроить процесс, чтобы быстро создавать качественные продукты, как кроссплатформенная разработка на Flutter помогает экономить время и деньги, а также, сколько стоит разработка приложения для бизнеса и из чего складывается цена.

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

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

Нужно сразу уточнить: есть два разных типа приложений — для пользователей и для сотрудников.

Приложение для пользователей нужно в том случае, если

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

• через приложение делать все это пользователю будет проще и удобнее, чем на десктопе или мобильном сайте,

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

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

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

К примеру, один из наших клиентов при помощи приложения оцифровал процесс мониторинга объектов.

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

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

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

При этом, если раньше ошибок в отчетах (старые или не те фотографии, недостоверная информация) было очень много, то после внедрения приложения их количество сократилось до нуля — и клиент получает достоверные отчеты буквально в режиме реального времени.

1. Экономическая эффективность. Приложение должно окупаться или за счет увеличения продаж клиентам, или за счет оптимизации бизнес-процессов. Если этого нет, запал, желание и инвестиции иссякнут очень быстро — и вместо эффективного бизнес-инструмента вы получите мертворожденный продукт.
2. Кроссплатформенность. Приложение должно одинаково работать как на Андроиде, так и на iOS, так как пользователи, как правило, используют разные устройства. Исключение — некоторые корпоративные приложения, которые устанавливаются строго на устройствах, которые централизованно закупает и выдает сотрудникам компания. В этом случае можно выбрать только одну платформу.
3. Стабильность работы на разных устройствах. Даже на старых телефонах приложение должно работать стабильно и быстро, не зависать, не вылетать, не выдавать ошибок, корректно отрабатывать статусы и т.д.
4. Удобный UX/UI и привлекательный дизайн. Чтобы клиенты или сотрудники пользовались приложением, оно должно быть удобнее, чем альтернативные варианты, доступные с десктопов или через мобильный браузер. При этом должно одинаково хорошо выглядеть на разных устройствах с разными разрешениями экранов.
5. Безопасность и защита пользовательских данных. Сверхкритичное условие для бизнеса, так как в случае взлома или утечки может пострадать не только репутация, но и быть причинен серьезный материальный ущерб.
6. Возможность расширять и добавлять функционал. Гибкость — важное условие, так как если на этапе разработки не заложить расширяемость и возможность масштабирования архитектуры и функционала, в дальнейшем это исправить будет почти невозможно, и следующую версию нужно будет создавать с нуля.
7. Адекватная стоимость поддержки. Которая доступна не для всех технологических стеков. К примеру, из-за ситуации на рынке стоимость поддержки приложений, написанных на Go, сейчас такая, что дешевле сделать новый продукт, поддерживать и развивать его.

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

1. Исследование конкурентной среды. UX-исследование.
2. Подготовка технического задания.
   
3. Согласование ТЗ с клиентом.
   
4. Передача проекта в разработку.
   
5. Создание UX/UI дизайна.
   
6. Бэкенд и Flutter разработка (если приложение создается в экосистеме с веб-частью, то здесь еще добавляется этап Front-end разработки).
7. Тестирование приложения.
   
8. Публикация в Google Play и App Store
   

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

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

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

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

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

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

По ходу разработки ТЗ мы непрерывно консультируемся с заказчиком и уточняем требования.

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

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

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

Довольно часто именно так и происходит: клиент видит визуализацию и осознает, что какие-то вещи ему не нужны, а какие-то стоит сделать в первую очередь. Мы, таким образом, получаем возможность еще до передачи в разработку скорректировать приоритеты.

С точки рения расчетов стоимости этапа дизайна также были свои изменения.

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

После согласования с заказчиком техзадания и разработки UI/UX-дизайна, бизнес-аналитик и менеджер проекта передает всю информацию по проекту разработчикам и знакомит их с основными артефактами, созданными к этому моменту:

• уставом проекта,

• таблицей рисков,
• follow up,
  
• road map,
  

• документами об образе и границах проекта,

• реестром заинтересованных лиц,

• документом с определением классов пользователей и их характеристик,

• описанием функциональных возможностей и этапов внедрения,

• спецификацией требований к ПО (техническим заданием),

• результатами UX-исследования,

• готовым UI-дизайном.

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

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

• В первую очередь создается окружение разработки на локальном сервере и устанавливаются все необходимые компоненты и библиотеки: инсталляция Flutter SDK, настройка IDE и эмуляторов, установка плагинов и зависимостей, необходимых для выполнения проекта.
• Затем создается GIT репозитории проекта. Обязательно с учетом всех необходимых правил форматирования и комментирования кода. Для обеспечения корректной работы системы контроля версий, нужно учесть требования к именованию веток, правилам коммитов и прочим деталям, связанным с использованием GIT.
• Следующим шагом создается документация по проекту, которая включает описание всех основных функций, элементов интерфейса, а также инструкции по использованию и настройке. Документация должна быть написана на понятном для пользователя языке и содержать достаточное количество информации, чтобы пользователь мог использовать приложение без дополнительной помощи

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

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

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

Отдельный процесс, в котором есть достаточно много подводных камней и узких моментов. Углубляться в него я не буду (это тема еще для одной большой статьи), пройдусь по основным этапам.

Процесс релиза приложения на Flutter в Google Play Market:

• Шаг 1: Создание учётной записи разработчика
• Шаг 2: Настройка android части
• Шаг 3: Тестирование приложения
• Шаг 4: Сборка и подписание приложения
• Шаг 5: Регистрация в Google Play Console
• Шаг 6: Описание приложения и подготовка визуальной части приложения для страницы в Google Play
• Шаг 7: Выбор категории и тегов
• Шаг 8: Проверка приложения
• Шаг 9: Проверка со стороны клиента и публикация.
  

Процесс релиза приложения в App Store:

• Шаг 1: Получение DUNS номера
• Шаг 2: Создание учётной записи разработчика
• Шаг 3: Настройка iOS части проекта
• Шаг 4: Тестирование приложения
• Шаг 5: Сборка и подписание приложение проходит
• Шаг 6: Регистрация в AppStore
• Шаг 7: Описание приложения и подготовка визуальной части приложения для страницы в AppStore
• Шаг 8: Выбор категории и тегов
• Шаг 9: Проверка приложения
• Шаг 10: Проверка со стороны клиента и публикация.
  

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

В дальнейшем приложение для бизнеса развивается по двум сценариям:

1. Доработка текущего функционала, когда команда разработки занимается тем, что устраняет ошибки и баги, оптимизирует какие-то моменты, следит за тем, чтобы приложение корректно работало на новых устройствах.
2. Расширение функционала. Когда в приложении появляются новые возможности, и команда разработки занята их созданием и внедрением.

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

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

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

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

Для проектов уровня Findgid, про который я рассказывал в одной из прошлых статей, бюджет обычно начинается от 50 000 долларов.

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

Такого плана решение на сегодняшний день обойдется примерно в 30 000 долларов.

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

1. Если вы хотите разработать приложение для своего бизнеса, не пытайтесь сделать сразу второй Амазон или Яндекс — сконцентрируйтесь на узком функционале или какой-то конкретной фиче. В этом случае вы сможете создать и зарелизить продукт достаточно быстро и за разумные деньги.
2. Масштабировать функционал стоит уже в следующих версиях, когда вы получите обратную связь от пользователей. Спойлер: здесь вас ждет немало сюрпризов и интересных открытий.
3. Если вам нужно кроссплатформенное решение, есть смысл обратить внимание на Flutter. По нашему опыту, это оптимальный инструмент для создания кроссплатформенных приложений для бизнеса с адекватной стоимостью как разработки, так и поддержки.

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

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