Менеджер управления проектами компании Digital Lab Слава Бах о том, как формируется и от чего зависит стоимость создания мобильного приложения.
Важность мобильной разработки
В 2019 и 2020 годах количество пользователей мобильных приложений значительно увеличилось, а вместе с ним выросли средний возраст юзеров и количество приложений на одного человека.
При этом пользователи из России каждый день проводят в мобильных приложениях на час больше, чем жители Китая, Германии и Франции — значит, отечественная аудитория более лояльна к такому формату.
Крупному бизнесу важно использовать мобильные приложения: в 2021-м это вопрос не репутации, а выживания любого ритейла, банка, информационной площадки или интернет-магазина. Сегодня пользователь, выбирая банк для открытия счета, сначала изучает все возможности мобильного приложения.
Такое приложение улучшает качество и количество взаимодействий пользователя с вашим товаром и брендом и увеличивает выручку. Без мобильных приложений компании теряют потенциальную прибыль: в них пользователям проще заказать товары или получить информацию, чем на сайтах.
Отставание в этом вопросе от конкурентов может привести к критичным последствиям, которые невозможно будет исправить. Ведь пользователи, однажды установившие приложение и удалившие его из-за недостаточного функционала, вряд ли установят его второй раз. А поиск новых и возвращение старых клиентов с помощью офлайн-инструментов обойдется гораздо дороже.
Типы мобильных приложений
Все приложения можно разделить по уровням сложности.
Простые решения – в основном это визитные карточки со ссылками на сторонние ресурсы.
К ним относятся информационные приложения и визитки с небольшим листингом.
Сложные решения
- чат-боты с авторизацией,
- работа с протоколами Bluetooth/Wi-Fi и другими,
- дополненная или виртуальная реальность,
- простые интернет-магазины.
Очень сложные решения
- соцсети;
- мессенджеры;
- заказ такси, доставки и т. п.;
- крупный ритейл с программой лояльности;
- онлайн-банкинг;
- корпоративные приложения.
Про простые решения сказано и написано много, их история линейна:
- Собираем бизнес- и функциональные требования.
- Определяем приблизительную стоимость и сроки.
- Составляем ТЗ.
- Делаем прототипы.
- Определяем точную стоимость и сроки.
- Создаем дизайн.
- Разрабатываем Backend.
- Разрабатываем нативное фронтальное решение.
- Тестируем.
- Релизим.
- Проводим регрессионное тестирование.
Такой пайплайн применим и к сложным проектам, но с большим количеством интеграций с разными системами, высокой нагрузкой, огромным количеством участников проекта и нестандартным подходом к решению бизнес-задач.
Из чего складывается стоимость
Основная составляющая стоимости – ставка специалиста в час. Однако цена зависит не только от функционала и оплаты труда разработчиков, но и от следующих факторов:
- действующая документация,
- описание API,
- дизайн,
- цели приложения,
- уровень погружения в задачу людей со стороны заказчика и сторонних сервисов (например, команда разработки серверной части со стороны заказчика, ERP-заказчика),
- скорость коммуникации.
Команда
В команду разработчиков входят не только программисты. Стандартная команда в сложном проекте выглядит так:
- продакт-менеджер и бизнес-аналитик (обычно со стороны заказчика),
- менеджер проектов,
- системный аналитик,
- дизайнер интерфейсов,
- backend-разработчики,
- IOS-разработчики,
- android-разработчики,
- тестировщики,
- тимлид,
- devops.
И это далеко не предел! Команды могут быть больше, если речь идет о крупном ритейле и производствах, банковском секторе, холдингах и высокобюджетных стартапах. Часто остаются за кулисами, но вносят весомый вклад в общее дело:
- руководитель отдела разработки,
- арт-директор/руководитель отдела дизайна,
- HR-менеджер,
- делопроизводитель и финансовый координатор,
- копирайтеры, аниматоры, иллюстраторы и др.
Держать всех их в штате не только дорого: нужен постоянный приток задач, чтобы избежать простоя специалистов. Преимущество заказной разработки в том, что в студиях разные специалисты работают над параллельными проектами. Это снижает конечную стоимость для заказчика.
Но студиям важно планировать нагрузку и ресурсы.
Принцип формирования оценки
Бриф
Для получения оценки от разработчиков, бизнесу нужно сформулировать бизнес- и функциональные требования и передать их менеджеру проектов команды разработки. Он оценит эту информацию и при необходимости запросит дополнительную.
Обсуждение
После этого менеджер проектов соберет команду из аналитика, дизайнера и разработчиков и опишет им проект. Вопросы и предложения команды, на которые не сможет ответить самостоятельно, он соберет и направит бизнесу.
Оценка
После получения всей информации, менеджер сформирует список задач, каждую из которых декомпозирует на мелкие функциональные требования. Так, задача создания каталога декомпозируется на:
- раздел в навигационной панели,
- выбор магазина,
- список категорий,
- карточку товара,
- детальную карточку товара,
- возможность добавить в избранное,
- кнопку поиска и т. д.
Затем каждый участник команды проставит примерное количество часов на реализацию.
Валидирование
Оценки проходят валидацию и корректировку у руководителей отдела разработки, дизайна и менеджера.
Риски
На собрании обсуждаются риски: итерации согласования дизайна, дополнения к бизнес-требованиям после согласования, интеграции со сторонними сервисами и т. д.
Менеджер проектов формирует смету, где суммарная оценка часов умножается на ставку специалиста. В нее закладывается процент на риски. Условно, незначительный риск – плюс 2 % к часам, значительный – от 2 до 5 %, критичный – от 5 до 15 %.
Основные риски и факторы, влияющие на стоимость
Коммуникация между участниками
Большое мобильное приложение = большое количество участников проекта. Например, участниками создания приложения продуктового ритейла будут:
- бизнес,
- мобильное приложение,
- ERP,
- серверное окружение,
- программа лояльности.
Формирование общего видения решения бизнес-задачи и его фиксация в таком случае – задача нетривиальная и трудоемкая, а стоимость одного конф-колла очень высока.
Кроме того, некоторые решения требуют согласования, их нельзя принять в реальном времени. А при долгом согласовании кто-то вообще может забыть, о чем речь.
Плохая или отсутствующая документация
В проектах с большим количеством интеграций для написания ТЗ бывает мало одних бизнес-требований. Нужно спроектировать решение, подключить системного аналитика и дизайнера к коммуникации со сторонними сервисами, изучить и вникнуть в документацию. А если ее нет – собирать конф-коллы и фиксировать все обсуждения.
Коробочные решения серверной части
Коробочные решения – не гибкие. Их доработка длится долго и обходится дорого, а еще они закрывают не все потребности бизнеса.
Часть решений может быть вынесена в другие информационные системы в контуре мобильного приложения (например, на сервер). Для этого разработчики должны тщательно изучить документацию сторонних сервисов. Ее отсутствие – риск для исполнителя.
Чаще всего оптимальный вариант по сроку и стоимости – комбинирование фронтального решения с готовым функционалом программы лояльности с возможностью дополнить его кастомным серверным решением.
Но с ростом мобильного приложения его серверная структура усложнится, что придется учитывать при разработке.
Отсутствие четких бизнес- и функциональных требований
Заказчик по разным причинам может опускать подробности и детали. В итоге задача будет расплывчатой, а команда потратит время на формирование решения, которое может оказаться заведомо неверным.
Потребность сделать быстрее
Можно вести разработку быстрее и сразу в нескольких направлениях, даже если процесс уже выстроен и спланирован. Для этого надо подключать дополнительный ресурс тимлида и тратить больше времени на планирование, тестирование и отладку. В итоге стоимость фичи может возрасти аж в 2,5 раза!
Важно! Функционал должен разрабатываться модульно и не соприкасаться друг с другом напрямую.
Большое количество интеграций и функционала приложения (Legacy code)
Однажды мобильное приложение может превратиться в огромный продукт с большим количеством интеграций и функционала. Тогда корректировка одного элемента может повлечь сбой в другом.
Различия между IOS и Android
IOS и Android – разные ОС с разными подходами, инструментами разработки и даже аудиториями. Если новый функционал имеет большое количество логики на стороне клиентской части мобильного приложения, то это повлечет дополнительные расходы на этапе дизайна и проектирования интерфейса с учетом особенностей каждой ОС.
Особенности, которые не бросаются в глаза
Важной особенностью мобильной разработки является то, что пользователь работает с установленным приложением, и разработчики не могут исправить ошибку здесь и сейчас.
Неудивительно, что каждая версия приложения проходит проверку у модераторов App Store, Google Play и App Gallery, которая длится как минимум 2 дня.
Поэтому тестирование приложения очень важно и требует дополнительных ресурсов и времени. Его корректная работа должна быть подтверждена на большом количестве устройств. Особенно в случае с Android!
Резюме
Даже кажущееся простым добавление одного экрана с настройками профиля может вылиться в трудоемкую задачу.
Разберем на примере функционала «Электронные чеки»: пользователь может переключить тумблер в приложении и получать чеки за покупки на свою электронную почту. Описание понятно, да и бизнес-задача предельно ясна. Но в ней участвуют 4 информационные системы: ERP, программа лояльности, сервер мобильного приложения и мобильное приложение.
Мобильное приложение должно понимать:
- где и как разместить функционал;
- что и в какой момент оно должно получать;
- что делать, если оно не получит данные;
- как пользователю ввести данные, чтобы это было удобно;
- как сделать так, чтобы пользователь не допустил ошибку;
- как избежать злоупотребления функционалом;
- как организовать проверку и сохранить данные при закрытии приложения или экрана;
- как помочь пользователю разобраться с новым функционалом;
- какие состояния элементов интерфейса могут быть и откуда приложение их получает;
- как пользователю изменить введенные данные.
Интерфейс приложения требует ответов на множество вопросов и проработки каждого сценария. А при возникновении проблемы крайними останутся разработчики: им придется проверять все на своей стороне, даже если проблема в другой информационной системе.
Конечно, это вряд ли относится к простым приложениям, где решения лежат на поверхности. А в сложных проектах нужно связать десятки элементов так, чтобы получилось удобно, красиво и понятно. И разработчикам приходится бесконечно сверяться с макетами дизайна и внимательно следить за своими решениями.
Ответственность ложится и на тестировщика: проверка большого количества сценариев на большом количестве устройств для приложения, которым будут пользоваться десятки и сотни тысяч человек.
В конечном итоге все это важно для пользователей: им нужен доступный, понятный, удобный и приятный функционал. Ведь мобильное приложение – такое же лицо компании, как магазин, кассир или консультант. И это действительно важный инструмент в руках бизнеса.
