Разработка мобильных приложений для бизнеса: как создавать кроссплатформенные решения быстро и относительно дешево
Меня зовут Валерьян Брунин, я сооснователь и директор ILAVISTA. Мы разрабатываем сложные комплексные продукты: веб-платформы и мобильные приложения, CRM- и ERP-системы, уникальные продукты для стартапов и мобильные приложения для классического бизнеса.
За этот год мы силами одной команды разработчиков создали с нуля и зарелизили 6 приложений для Android и iOS. В этой статье я расскажу, как выстроить процесс, чтобы быстро создавать качественные продукты, как кроссплатформенная разработка на Flutter помогает экономить время и деньги, а также, сколько стоит разработка приложения для бизнеса и из чего складывается цена.
Предисловие.
Почему я пишу вообще этот материал. Сотни компаний на рынке разрабатывают решения на Flutter. Мы здесь не уникальны и не создали что-то такое, что перевернуло рынок. Нет. Этот материал я пишу с точки зрения того, как, имея отличные процессы в веб-разработки, добавить к услугам еще и приложения.
Также я хочу немного добавить своих мыслей о том, когда бизнесу в целом нужна мобильная разработка. Если в вебе +/- все понятно, то приложение решает все таки специфические задачи и как правило сильно удорожает разработку.
Когда бизнесу нужно мобильное приложение
Нужно сразу уточнить: есть два разных типа приложений — для пользователей и для сотрудников.
Это если мы говорим о бизнесе. Да, есть еще игры, стартапы и так далее. Но мы занимаемся только приложениями для бизнеса и можем делиться опытом только в этой нише.
Приложение для пользователей нужно в том случае, если
покупки совершаются более-менее регулярно: заказ одежды, техники, расходников, разных мелочей, продуктов, такси, цветов, доставка из ресторанов, финансовые сервисы — все, чем люди пользуются на регулярной основе,
через приложение делать все это пользователю будет проще и удобнее, чем на десктопе или мобильном сайте,
- бизнес планирует использовать приложение как дополнительный канал для маркетинга: пуш-уведомлений, специальных акций, розыгрышей и т.д.
Все исследования за последние годы показывают, что мобильное приложение стимулирует пользователей покупать больше и чаще. По сути, оно дает возможность пролезть в телефон к самым лояльным клиентам и напрямую коммуницировать с ними, что увеличивает продажи и укрепляет лояльность к бренду.
Приложение для сотрудников, в свою очередь, есть смысл делать только в одном случае — если оно дает возможность оцифровать какой-то процесс и экономить за счет этого десятки и сотни человеко-часов каждый месяц.
К примеру, один из наших клиентов при помощи приложения оцифровал процесс мониторинга объектов.
Раньше менеджер ездил, фотографировал, загружал фотографии в папку, вручную привязывал их к разным объектам, делал отчет, теряя в процессе часть фотографий (часто приходилось делать их повторно) или ошибаясь и прикрепляя неактуальные фото или снимки с других объектов.
Теперь все это делается в приложении: сотрудник подъезжает к объекту, по геопозиции автоматически определяется, какой именно объект нужно сфотографировать (выбор в один клик), фото делается прямо через приложение и с геометкой и отметкой времени сразу загружается в базу, сводный отчет формируется автоматически и выгружается в один клик.
Так как объектов у компании очень много по всей стране, приложение экономит сотни человеко-часов каждый месяц.
При этом, если раньше ошибок в отчетах (старые или не те фотографии, недостоверная информация) было очень много, то после внедрения приложения их количество сократилось до нуля — и клиент получает достоверные отчеты буквально в режиме реального времени.
Общие требования к мобильному приложению для бизнеса
- Экономическая эффективность. Приложение должно окупаться или за счет увеличения продаж клиентам, или за счет оптимизации бизнес-процессов. Если этого нет, запал, желание и инвестиции иссякнут очень быстро — и вместо эффективного бизнес-инструмента вы получите мертворожденный продукт.
- Кроссплатформенность. Приложение должно одинаково работать как на Андроиде, так и на iOS, так как пользователи, как правило, используют разные устройства. Исключение — некоторые корпоративные приложения, которые устанавливаются строго на устройствах, которые централизованно закупает и выдает сотрудникам компания. В этом случае можно выбрать только одну платформу.
- Стабильность работы на разных устройствах. Даже на старых телефонах приложение должно работать стабильно и быстро, не зависать, не вылетать, не выдавать ошибок, корректно отрабатывать статусы и т.д.
- Удобный UX/UI и привлекательный дизайн. Чтобы клиенты или сотрудники пользовались приложением, оно должно быть удобнее, чем альтернативные варианты, доступные с десктопов или через мобильный браузер. При этом должно одинаково хорошо выглядеть на разных устройствах с разными разрешениями экранов.
- Безопасность и защита пользовательских данных. Сверхкритичное условие для бизнеса, так как в случае взлома или утечки может пострадать не только репутация, но и быть причинен серьезный материальный ущерб.
- Возможность расширять и добавлять функционал. Гибкость — важное условие, так как если на этапе разработки не заложить расширяемость и возможность масштабирования архитектуры и функционала, в дальнейшем это исправить будет почти невозможно, и следующую версию нужно будет создавать с нуля.
- Адекватная стоимость поддержки. Которая доступна не для всех технологических стеков. К примеру, из-за ситуации на рынке стоимость поддержки приложений, написанных на Go, сейчас такая, что дешевле сделать новый продукт, поддерживать и развивать его.
Именно опираясь на эти требования, мы выбрали разработку приложений для бизнеса на Flutter, когда запускали это направление в ILAVISTA.
Flutter — бесплатный набор средств разработки, созданный Google и используемый во многих их продуктах. Т.е. технология не умрет из-за отсутствия поддержки и развития.
Флаттер дает возможность запустить два разных приложения для Android и iOS на одном массиве кода. Т.е. продукт не нужно портировать на разные системы.
Это по меньшей мере на 50% сокращает срок разработки, экономит минимум 30% бюджета на создание приложения для бизнеса и серьезно уменьшает количество багов.
Итого: силами одной команды можно запускать приложения для разных платформ, при этом экономя время и ресурсы.
Разработка мобильного приложения на Flutter для бизнеса: основные этапы
Создание мобильного приложения на Flutter ничем принципиально не отличается от любой другой разработки. Конечно, определенная специфика есть, как и для любого другого инструмента, фреймворка или языка, но в целом, процесс достаточно типовой.
- Исследование конкурентной среды. UX-исследование.
- Подготовка технического задания.
- Согласование ТЗ с клиентом.
- Передача проекта в разработку.
- Создание UX/UI дизайна.
- Бэкенд и Flutter разработка (если приложение создается в экосистеме с веб-частью, то здесь еще добавляется этап Front-end разработки).
- Тестирование приложения.
- Публикация в Google Play и App Store
Немного подробнее расскажу про каждый из этих этапов, чтобы было понятнее, что именно и почему мы делаем на каждом шаге.
Исследовательский этап
Вне зависимости от того, делается приложение для клиентов или сотрудников, мы уделяем исследованиям огромное значение.
- Во-первых, они дают возможность оценить ситуацию на рынке, сориентироваться самим и сориентировать клиента, каким образом мы можем разработать востребованный и конкурентоспособный продукт.
К примеру. Заказчик считает, что его сотрудникам будет удобно отслеживать заведения и заправки на протяжении всего маршрута, чтобы знать, где удобно и приятно остановиться. Но при интервьюировании сотрудников, оказывается, что этим функционалом вообще нет смысла пользоваться, так как движение и остановка идут жестко по графику, а не из позиции, где удобно и приятно остановится. В итоге мы убираем целый блок задач, экономим время и деньги.
На выходе получается достаточно объемный документ, на основе которого в дальнейшем разрабатывается общая архитектура проекта и техническое задание на разработку.
К сожалению, показать пример я не могу (все исследования делаются строго под NDA), но в этой презентации вы можете посмотреть примерный состав работ по одному из исследовательских направлений, который мы презентуем клиентам на установочных встречах.
Подготовка технического задания и согласование его с клиентом
На этом этапе мы раскладываем все требования клиента и на основе результатов исследований разрабатываем подробное ТЗ, по которому в дальнейшем организуем все работы по созданию мобильного приложения для бизнеса.
По ходу разработки ТЗ мы непрерывно консультируемся с заказчиком и уточняем требования.
Когда ТЗ готово, обязательно проводим установочную встречу, чтобы еще раз сверить часы и финально согласовать все детали проекта перед стартом разработки.
Создание UI/UX дизайна
На следующем этапе мы полностью прорабатываем визуальную часть проекта: это важно как для дальнейшей разработки (программисты понимают, как будет выглядеть и работать приложение), так и для самого заказчика, которому важно как можно раньше увидеть, за что же он платит деньги.
Еще один важный момент: только на этом этапе у нас есть возможность безболезненно внести какие-то изменения в архитектуру проекта — добавить какой-то функционал или, наоборот, от чего-то отказаться.
Довольно часто именно так и происходит: клиент видит визуализацию и осознает, что какие-то вещи ему не нужны, а какие-то стоит сделать в первую очередь. Мы, таким образом, получаем возможность еще до передачи в разработку скорректировать приоритеты.
На момент запуска мобильной разработки в компании, все наши дизайнеры работали только с веб-дизайном и адаптивными версиями сайта. Мы столкнулись с тем, что опытный дизайнер уровня middle+ в веб, без опыта в мобильном дизайне по факту начинающий дизайнер в приложениях. Но. скорость обучения у них идет невероятно быстро. Так как они подтягивают знания только по гайдам мобильной разработки, а не весь дизайн.
С точки рения расчетов стоимости этапа дизайна также были свои изменения.
Здесь я бы остановился детальнее. Эта информация будет полезна в основном компаниям-разработчикам. Но не буду перегружать статью и сделаю ссылку на файл расчетов.
Передача проекта в разработку
После согласования с заказчиком техзадания и разработки UI/UX-дизайна, бизнес-аналитик и менеджер проекта передает всю информацию по проекту разработчикам и знакомит их с основными артефактами, созданными к этому моменту:
уставом проекта,
- таблицей рисков,
- follow up,
- road map,
документами об образе и границах проекта,
реестром заинтересованных лиц,
документом с определением классов пользователей и их характеристик,
описанием функциональных возможностей и этапов внедрения,
спецификацией требований к ПО (техническим заданием),
результатами UX-исследования,
готовым UI-дизайном.
Информация доводится до команды разработки, и на ее основе формируется бэклог задачи, которые затем распределяются по спринтам.
Бэкенд и Flutter разработка
Классический итерационный процесс разработки, который строится по таким же принципам, как и создание любых других продуктов и приложений.
- В первую очередь создается окружение разработки на локальном сервере и устанавливаются все необходимые компоненты и библиотеки: инсталляция Flutter SDK, настройка IDE и эмуляторов, установка плагинов и зависимостей, необходимых для выполнения проекта.
- Затем создается GIT репозитории проекта. Обязательно с учетом всех необходимых правил форматирования и комментирования кода. Для обеспечения корректной работы системы контроля версий, нужно учесть требования к именованию веток, правилам коммитов и прочим деталям, связанным с использованием GIT.
- Следующим шагом создается документация по проекту, которая включает описание всех основных функций, элементов интерфейса, а также инструкции по использованию и настройке. Документация должна быть написана на понятном для пользователя языке и содержать достаточное количество информации, чтобы пользователь мог использовать приложение без дополнительной помощи
После чего начинается непосредственно разработка. Особое внимание при этом необходимо уделять безопасности: в этом отношении у Flutter есть определенная специфика, о которой я как-нибудь напишу отдельную статью.
Тестирование приложения
В процессе разработки код проходит через стандартные тесты. Когда основной этап завершен и приложение готово к релизу, оно еще раз прогоняется через серию тестов, которые помогают отловить незамеченные баги и исправить ошибки, которые вылезли на финальных этапах.
На этом же этапе приложение может полноценно протестировать заказчик: как правило, со стороны клиентов на этом этапе также прилетают правки и пожелания, которые нужно реализовать до полноценного релиза.
Публикация в Google Play и App Store. Релиз приложения
Отдельный процесс, в котором есть достаточно много подводных камней и узких моментов. Углубляться в него я не буду (это тема еще для одной большой статьи), пройдусь по основным этапам.
Процесс релиза приложения на 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: Проверка со стороны клиента и публикация.
После релиза: как развивать и дорабатывать приложение для бизнеса
Как правило, в первой версии приложения для бизнеса реализуется самый критичный и нужный функционал. Иногда это может даже какая-то одна функция или киллер-фича, на которой и основывается ключевая ценность приложения для пользователя.
В дальнейшем приложение для бизнеса развивается по двум сценариям:
- Доработка текущего функционала, когда команда разработки занимается тем, что устраняет ошибки и баги, оптимизирует какие-то моменты, следит за тем, чтобы приложение корректно работало на новых устройствах.
- Расширение функционала. Когда в приложении появляются новые возможности, и команда разработки занята их созданием и внедрением.
Обычно работа ведется одновременно по обоим этим направлениям, но распределение задач может очень сильно отличаться в зависимости от особенностей проекта и текущей необходимости.
Важно понимать, что поддержка — это не разовые работы, а постоянный процесс, от которого зависит в конечном итоге как конкурентоспособность, так и работоспособность приложения.
Затраты на поддержку и развитие при этом очень сильно зависят от того, насколько качественно сделан первоначальный продукт.
Стоимость разработки и бюджет на поддержку/развитие
Вопросы о том, сколько стоит разработать мобильное приложение для бизнеса, мне задают все без исключения клиенты в первые 10 минут после начала обсуждения проекта.
К сожалению, однозначных ответов у меня нет: все очень сильно зависит от проекта.
Когда нужно оцифровать какой-то простой интернет-магазин и выпустить его в сторах, бюджет может быть всего 2000-3000 долларов, и с этой задачей справится практически любой более-менее квалифицированный фрилансер.
Для проектов уровня Findgid, про который я рассказывал в одной из прошлых статей, бюджет обычно начинается от 50 000 долларов.
Еще один пример: проект, который мы делали для логистической компании. Клиенту было нужно приложение для бизнеса на iOS и Android, чтобы водители могли планировать график работы и маршруты, получить информацию о заказах и деталях поездок. Также в приложении реализована интерактивная карта маршрута с отображением зон отдыха, заправок и других необходимых данных.
Такого плана решение на сегодняшний день обойдется примерно в 30 000 долларов.
Важно оговориться, что цены указаны очень ориентировочно. Итоговая стоимость разработки приложения очень сильно зависит от того, что будет под капотом, поэтому каждый проект нужно оценивать индивидуально.
Несколько рекомендаций в завершение
- Если вы хотите разработать приложение для своего бизнеса, не пытайтесь сделать сразу второй Амазон или Яндекс — сконцентрируйтесь на узком функционале или какой-то конкретной фиче. В этом случае вы сможете создать и зарелизить продукт достаточно быстро и за разумные деньги.
- Масштабировать функционал стоит уже в следующих версиях, когда вы получите обратную связь от пользователей. Спойлер: здесь вас ждет немало сюрпризов и интересных открытий.
- Если вам нужно кроссплатформенное решение, есть смысл обратить внимание на Flutter. По нашему опыту, это оптимальный инструмент для создания кроссплатформенных приложений для бизнеса с адекватной стоимостью как разработки, так и поддержки.
Буду рад ответить на ваши вопросы в комментариях. Если вам нужна консультация по созданию приложений на Flutter для бизнеса или нужно валидировать какие-то идеи по мобильной разработке, можете связаться со мной в Телеграме, буду рад пообщаться лично.
Если вы занимаетесь разработкой и вашим клиентам нужны приложения, но вы их не делаете — тоже пишите, мы работаем не только с прямыми клиентами, но и на субподряде.
Сколько людей у вас в команде разработки и кто чем занимается?
Сейчас 4 Flutter разработчика. Было 5, но одного в армию забрали в ноябре. Все были с нуля и мы дотянули их до middle примерно. А остальная команда из веб: PM / BA / UX / UI / Front-end на vue.js / Back-end на Laravel / QA
Хорошая инструкция получилась
Спасибо)
Иногда для бизнеса эффективнее сделать чат-бота, который получится значительно дешевле в разработке и обслуживании.
да, по этому в начале статьи написал свои критерии для разработки приложения) к примеру, есть магазин айфонов в гродно с телеграм-чатом. ну просто мрак и ужас. а есть в Минске тоже такой же магазин с приложением в котором не просто каталог, но и заявка на ремонт, стекло и так далее. Заработки разные у компаний по итогу)
Чат-боты же только для совсем примитивных задач подходят, не? Приложение все-таки пофункциональнее будет.