Мобильные приложения стали неотъемлемой частью жизни большинства людей. От заказа пиццы и вызова такси до банковских сервисов и просмотра фильмов. Практически все операции можно выполнить с их помощью. Активная популяризация установки и дальнейшего использования приложений вызывает у многих представителей бизнеса вопрос о стоимости их разработки.
Ценообразование в мобильной разработке – вопрос сложный, т.к. заказчик не всегда понимает те работы, которые необходимо выполнить для реализации продукта, а исполнитель не может сделать полноценную оценку до тех пор, пока не узнает весь реализуемый функционал и специфику. Подобные сложности требуют предварительной подготовки и анализа исходных данных.
В общем случае, стоимость разработки мобильного приложения зависит от следующих связанных между собой факторов:
- сложность «продукта»;
- количество задействованных специалистов, их роль и квалификация (навыки);
- общая длительность процесса разработки;
- используемый вид приложения (нативное или гибрид);
- дополнительные нефункциональные требования к продукту;
- специфические отраслевые требования (например, характерные для «финтех-проектов») и дополнительные интеграции;
- прочие дополнительные затраты.
Рассмотрим каждый фактор подробнее.
Сложность мобильного приложения
Как узнать, мобильное приложение простое или сложное?! Достаточно взглянуть на те функции, которые оно должно выполнять. Простые мобильные приложения, как правило, не имеют панели администрирования, не собирают данные пользователей и выполняют простые однотипные процессы. В большинстве случаев, они не имеют баз данных, в наборе минимум интеграций с другими объектами. Чаще всего они статичны и не имеют сложной серверной части («Backend»). Сюда же можно отнести и продукты, использующие готовый «движок»/платформу для быстрого построения приложения на базе шаблонных решений.
Приложения средней сложности отличаются более разнообразным функционалом, с точки зрения реализации, ведут обмен с базами данных, поддерживают интеграцию с другими продуктами. Классический пример – интернет-магазин с возможностью полного оформления покупки товара, авторизации, оплаты заказа, выбора условий доставки, написания отзывов и выставления оценок (система рейтинга продукции). Приложения средней сложности, к примеру, являются: сервисы бронирования билетов, подборщик туристических путевок, включающий полный цикл их оформления, сервисы заказы еды и т. п. Это самая популярная категория мобильных приложений и, в большинстве случаев, клиент, обратившийся за разработкой продукта, подразумевает именно её.
Сложные мобильные приложения могут осуществлять синхронизацию в режиме реального времени, имеют сложную серверную часть и архитектуру, включают в себя множество сторонних интеграций, глубокую аналитику данных. Часто они строятся на основе алгоритмов машинного обучения. Сюда можно отнести любое приложение следующих направлений: онлайн-кинотеатры, музыкальный стриминг, сервисы заказа такси, навигаторы и др.
Сложность мобильного приложения влияет на привлекаемых к разработке специалистов и общую длительность до конечной реализации продукта.
Количество задействуемых специалистов
Обращаясь за разработкой мобильного приложения, заказчик преимущественно оплачивает время работы специалистов, которые принимают участие в проекте. В зависимости от специфики объекта разработки привлекаются:
- менеджер проекта/продукта – координирует действие всех участников команды, расставляет приоритеты, принимает ключевые решения, взаимодействует с заказчиком;
- системный/бизнес-аналитик – разработка концепции и общего видения, сбор и документирование функциональных и нефункциональных требований, написание пользовательских инструкций, управление изменениями и их фиксирование;
- интернет-маркетолог – конкурентный анализ, исследования рынка и целевой аудитории;
- UX/UI-дизайнер – определяет внешний вид продукта, отвечает за удобство использования мобильного приложения конечными потребителями;
- системный архитектор – отвечает за разработку архитектуры всего мобильного приложения;
- frontend-разработчик – реализация пользовательской части продукта, может использовать такие технологии, как «React Native», «Kotlin», «Flutter»;
- backend-разработчик – отвечает за внутреннюю часть продукта, задействует в зависимости от специфики «Node.js», «Python», «Java», «Swift», «Go», «Си»;
- «Data Engineer» - проектировщик/разработчик баз данных;
- «тестировщик» - отвечает за тестирование/отладку функционала мобильного приложения, дает заключение о готовности исследуемого объекта;
- системный администратор – работоспособность серверов и развёртка серверного ПО;
- аналитик данных («Big Data») – в крупных проектах внедряет алгоритмы для обработки больших массивов различных «полезных» для бизнеса сведений, структурирование и наглядная визуализация разрозненной информации;
- специалист по ML – реализация алгоритмов машинного обучения;
- «DevOps» - отвечает за разделение зон разработки и рабочего продукта, перенос принятых и прошедших процесс тестирования изменений в эксплуатацию;
- специалист по информационной безопасности – разрабатывает меры для предотвращения утечки данных пользователей, сокращает риски взломов, реализует защиту от современных интернет-угроз.
«Backend» и «frontend» разработчики мобильных приложений иногда ещё подразделяются отдельно на Android и iOS-разработчиков.
В проекте могут задействоваться и другие специалисты в зависимости от конкретной специфики. Чем сложнее проект, тем больше людей будет участвовать в команде. Данная зависимость представлена в таблице ниже.
Специалист/ сложность разработки | Простая | Средняя | Сложная |
менеджер проекта/продукта | + | + | + |
системный/бизнес-аналитик | + | + | + |
интернет-маркетолог | + | + | + |
UX/UI-дизайнер | + | + | + |
системный архитектор | - | + | + |
frontend-разработчик | + | + | + |
backend-разработчик | - | + | + |
«Data Engineer» | - | + | + |
тестировщик | + | + | + |
системный администратор | - | + | + |
аналитик данных | - | - | + |
специалист по ML | - | - | + |
DevOps | - | - | + |
специалист по информационной безопасности | - | + | + |
В простых проектах чаще всего не привлекается системный архитектор, т.к. все функциональные операции просты, достаточно задействовать сценарии использования, за разработку которых отвечает системный аналитик. «Backend-разработчик» в работах не участвует, в связи с использованием готового «движка»/платформы или отсутствия серверной части в целом.
В проектах средней сложности количество задействуемых специалистов возрастает. Иногда некоторые роли совмещаются. Например, «backend-разработчик» может являться и «Data Engineer», проектируя базы данных. Задачи системного архитектора могут быть возложены (разбиты) на системного аналитика, frontend-разработчика и backend-разработчика. Роль специалиста по информационной безопасности также может быть разделена (чаще всего на системного администратора и backend-разработчика).
Сложные мобильные приложения изначально задают высокие требования ко всем функциональным особенностям. В связи с чем, к работе могут быть привлечены дополнительные участники - аналитик данных, специалист по ML (иногда роль первого и последнего бывает совмещена), DevOps. Разработка продукта связана с большими рисками и поэтому требует большей детализации шагов. Если в простых и средней сложности проектах роль системного архитектора упраздняется и/или совмещается другими специалистами, то при разработке сложных мобильных приложений необходимо его активное участие на всех стадиях.
Общая длительность разработки
Простые мобильные приложения обычно реализуются за 1-2 месяца. Разработка делается последовательно (каскадная модель), либо гибко (подразумевается использование методологий Agile/Scrum).
Проекты средней сложности выполняются от 3 до 6 месяцев. Разработка ведётся по Agile/Scrum, реже Agile/Kanban. Это позволяет разбить весь процесс создания продукта на шаги (спринты), каждый из которых приращает функциональность или вносит корректировки/улучшения в предыдущие. Длительность спринта стараются вмещать в 2 недели. Подобный подход позволяет вести разработку мобильного приложения наглядно и открыто, а заказчику контролировать данный процесс, видя результат каждого шага.
Сложные проекты редко привязывают к какой-либо определенной методологии. Часто используют комбинации. К примеру, ключевая серверная часть проекта может быть построена последовательно, а затем на неё наращивается функционал итеративно по спринтам. Их длительность, в обшей сложности, может достигать от 6 месяцев до нескольких лет.
Сложность |
Примерный срок разработки |
Простая | 1-2 месяца (150-290 часов) |
Средняя | 3-6 месяца (300-800 часов) |
Сложная | Более 6 месяцев |
Как видно из таблицы, разработать качественное сложное мобильное приложение за 1 месяц, как многие считают, не получится.
Используемый вид приложения
Разновидность разрабатываемого мобильного приложения значительно влияет на общую стоимость конечного продукта. С ценовой точки зрения дешевле сделать гибрид (кроссплатформенный мобильный продукт), который подойдёт для пользователей обеих платформ: Android и iOS. Дороже стоят нативные мобильные приложения, подразумевающие отдельный софт для каждой операционной системы. Более подробно о различиях гибридных и нативных приложений читайте в нашей соответствующей статье.
Примерное приращение в часах приведено в таблице ниже.
Сложность | Гибридное приложение | Нативное приложение |
Простая | 150 | до 290 |
Средняя | 300-500 | 400-600 |
Сложная | Более 600 | +30% |
Приращение длительности разработки нативных продуктов по отношению к гибридным не превышает 2 раза, т.к. исходники кода продукта для одной платформы можно оптимизировать и переработать под другую.
Дополнительные нефункциональные требования к продукту
Помимо функциональных требований к мобильным приложениям всегда предъявляются дополнительные нефункциональные, благодаря которым и происходит конечная оценка качества продукта пользователями. Само по себе понятие «качественное приложение» весьма субъективно и требует декомпозиции его свойств и функционала. К примеру, обеспечение стабильности работы даже при низкой скорости интернета или его временного отсутствия, автоматическое восстановление работоспособности при возникновении аварийных ситуаций, возможность выдерживать высокие пиковые нагрузки со стороны пользователей, восстановление последней сессии с сохранением изменений до сбоя и т. п.
Чем больше нефункциональных требований предъявляется к приложению, тем дороже стоимость разработки. Свойства могут быть предъявлены, как к всему продукту в целом, так и его отдельным функциям (частям). К примеру, при заполнении форм должны появляться подсказки на основе изучения интересов пользователя в рамках работы данного приложения.
Примечание: одним из ключевых нефункциональных требований является «юзабилити», отвечающее за удобство пользования продуктом конечными потребителями мобильного приложения. Для принятия заключения о «реальном удобстве» рекомендуется в рамках проекта проводить соответствующие исследования (не менее 5-10) с оценкой от интернет-пользователей.
Специфические отраслевые требования и дополнительные интеграции
Специфические отраслевые требования – отдельный важный атрибут, который необходимо учитывать при ценообразовании. Для примера рассмотрим одну из самых сложных областей разработки мобильных приложений - финансовые технологии. Разрабатываемый продукт должен соответствовать требованиям ЦБ РФ и профильному законодательству в целом. К примеру, законы «О защите персональных данных» - в России или «GDPR» (его аналог) в Европе. Нарушения могут привести к высоким штрафам (до 4% от годового оборота компании) и/или приостановке деятельности.
Кроме того, при реализации «финтех-проекта» потребуется учесть в работе модели идентификации и аутентификации, а также решить ряд вопросов с обеспечением безопасности при проведении каких-либо операций. Не сложно догадаться, что это увеличивает объем работ и значительно усложняет проект.
При разработке простых и средней сложности проектов редко выдвигаются дополнительные отраслевые требования. В ту же очередь, может понадобиться дополнительная интеграция и синхронизация с другими программными продуктами. Для интернет-магазина это чаще всего учётная система («1С») и сервисы онлайн-отслеживания статуса товара. Пиццерия может иметь отдельную систему управления заказами, что заставит в обязательном порядке разработчиков внедрить двухсторонний симплексный или дуплексный обмен данными.
Прочие дополнительные затраты
Сюда можно отнести оплату аккаунтов «Apple» и «Google Developer», без которых нельзя будет выложить мобильное приложение на плеймаркетах. Отдельно могут потребоваться сервисы смс и push-уведомлений, аренда серверного облачного оборудования («Яндекс.Облако», «Microsoft Azure», «Amazon Web Servers» и т.п.), приобретение сторонних платных решений.
К прочим расходам можно отнести и маркетинговые исследования поведенческих факторов пользователей, анализ целевой аудитории, предварительное тестирование продукта конечными потребителями.
Какова же стоимость разработки мобильного приложения
Для удобства восприятия информация представлена в виде таблицы:
Сложность | Гибридное приложение, тыс. руб. | Нативное приложение, тыс. руб. |
Простая | 300 | 400 |
Средняя | 1 500 | 2 300 |
Сложная | Более 2 000 | Более 3 000 |
Итак, средняя стоимость разработки простого приложения будет составлять в среднем 300-400 тысяч в зависимости от разновидности.
Мобильный продукт средней сложности будет стоить от 1500000 до 2300000 рублей.
«Сложные» приложения рассчитываются индивидуально. Начальная «планка» от 2000000 за гибрид и 3000000 за нативный продукт.
В любом из случаев, точную оценку стоимости можно произвести только после понимания всего реализуемого в проекте функционала и особенностей конкретной разработки.
Вместо заключения
Разработка мобильного приложения – сложный процесс, в котором задействуется множество специалистов различных областей. Если вы планируете пойти данным путём, заранее продумайте продвижение в интернете (оно тоже будет стоить денег), эксплуатационные расходы и общее время, необходимое на разработку полноценного и нормально функционирующего интернет-продукта.
Комментарии