Из чего складывается стоимость мобильной разработки

Слава Бах, менеджер управления проектами 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, программа лояльности, сервер мобильного приложения и мобильное приложение.

Мобильное приложение должно понимать:

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

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

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

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