Меня зовут Валерьян Брунин. Наша команда занимается разработкой продуктов и приложений на аутсортсинге.

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

Предисловие

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

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

Когда бизнесу нужно мобильное приложение

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

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

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

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

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

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

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

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

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

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

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

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

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

Общие требования к мобильному приложению для бизнеса

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

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

3. Стабильность работы на разных устройствах. Даже на старых телефонах приложение должно работать стабильно и быстро, не зависать, не вылетать, не выдавать ошибок, корректно отрабатывать статусы и т.д.

4. Удобный UX/UI и привлекательный дизайн. Чтобы клиенты или сотрудники пользовались приложением, оно должно быть удобнее, чем альтернативные варианты, доступные с десктопов или через мобильный браузер. При этом должно одинаково хорошо выглядеть на разных устройствах с разными разрешениями экранов.

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

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

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

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

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

Флаттер дает возможность запустить два разных приложения для Android и iOS на одном массиве кода. Т.е. продукт не нужно портировать на разные системы.

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

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

Разработка мобильного приложения на Flutter для бизнеса: основные этапы

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

1. Исследование конкурентной среды. UX-исследование.

2. Подготовка технического задания.

3. Согласование ТЗ с клиентом.

4. Передача проекта в разработку.

5. Создание UX/UI дизайна.

6. Бэкенд и Flutter разработка (если приложение создается в экосистеме с веб-частью, то здесь еще добавляется этап Front-end разработки).

7. Тестирование приложения.

8. Публикация в 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: Проверка со стороны клиента и публикация.

После релиза: как развивать и дорабатывать приложение для бизнеса

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

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

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

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

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

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

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

Стоимость разработки и бюджет на поддержку/развитие

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

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

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

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

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

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

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

Несколько рекомендаций в завершение

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

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

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

Буду рад ответить на ваши вопросы в комментариях.