Краткий гид по рынку заказной разработки мобильных приложений
Справочная информация для тех, кто пытается разобраться как устроена отрасль или ищет мобильного разработчика
Объемы рынка мобильной разработки
Несмотря на юный возраст, рынок заказной мобильной разработки уже сформировался и благодаря растущему спросу продолжает расти.
Общее количество зарегистрированных в совместной базе Рейтинга Рунета и CMS Magazine компаний-мобильных разработчиков — 610. Общее количество разработанных ими приложений на iOS и Android — 13 229 (из которых 8 250 — на iOS, 4 979 — на Android).
Среднестатистическая компания, специализирующаяся на мобильной разработке, имеет в штате 8-15 специалистов и за год разрабатывает 4 приложения.
Стоимость услуг по разработке приложений
Компании, разрабатывающие приложения, делятся на четыре ценовых сегмента: Нижний ( до 200 000 рублей), Средний (от 200 000 рублей до 500 000 рублей), Верхний (от 500 000 рублей до 1 000 000 рублей) и Премиум (от 1 000 000 рублей и выше). Для того, чтобы выбрать подходящего под финансовые возможности подрядчика, стоит воспользоваться ценовыми срезами рейтинга: Нижний, Средний, Верхний и Премиум.
В среднем заказная разработка приложения обходится в 588 236 рублей, на iOS — 604 729 рублей, на Android — 570 380 рублей.
Помимо операционной системы на размеры бюджета также влияют следующие факторы: месторасположение разработчика, категория/функционал приложения, необходимость всевозможных интеграций.
Средняя стоимость разработки приложений в различных городах составляет:
- Москва — 829 408 рублей
- Санкт-Петербург — 761 977 рублей
- Новосибирск — 660 000 рублей
- Ростов-на-Дону — 496 875 рублей
- Краснодар — 376 406 рублей
Как выбрать мобильного разработчика?
Рейтинг, отзывы клиентов и прямое общение с кандидатами — пожалуй, самые главные инструменты для выбора. На какие именно критерии обращать внимание? Вот список основных:
- Опыт разработки приложений на нужной ОС
- Опыт разработки приложений схожей тематики и функционала
- Временной прогноз на реализацию проекта
- Ценовая ниша разработчика
- Победы в отраслевых конкурсах (по необходимости)
Иногда хочется посмотреть не только на цифры и позиции в рейтинге, но и на то, как мыслит ваш будущий потенциальный партнер. Поэтому мы взяли небольшие интервью у руководителей и ведущих специалистов агентств, которые уже работали в сфере разработки ПО.
Дмитрий Лемайкин, iOS-лид в Globus IT
Мобильное приложение — это приложение конечного пользователя. Поэтому основные отрасли, которые чаще всего используют мобильную разработку, — это ритейл, индустрия развлечений, контентно-ориентированные компании (аудио, видео, тексты). Однако и те, которые производят ПО, нередко разрабатывают мобильные приложения и привлекают для этого подрядчиков.
Условно можно выделить следующие направления разработки МП для софтверных компаний:
- Автоматизация процессов управления персоналом (кадровые процессы, внутрикорпоративная коммуникация, взаимодействие с бухгалтерией и т. д.).
- Автоматизация работы офисов (мобильные приложения для входа в здание, для бронирования рабочих мест и переговорок, управления принтерами и иной техникой и т. д.).
- Обертки и дополнения для сервисов крупных компаний, которые пишут ПО. Например, Яндекс или Сбер пишут какие-то сервисы, подрядчики делают к ним МП как для продвижения этих сервисов, так и для их коммерческого использования.
- Выделение отдельного SDK из существующего приложения для переиспользования как в отдельных продуктах, так и для самостоятельного коммерческого использования. Например, разработка SDK для оплаты товаров в магазине с помощью сканирования лица человека.
- Интеграция платежных систем. Если у софтверной компании мобильная разработка — непрофильное направление, то им дешевле привлечь сторонних специалистов с опытом для реализации сложных задач, таких как интеграция платежной системы.
Кроме того, существует «движение» от кроссплатформы в сторону нативной разработки и наоборот. Бывает так, что несколько лет назад проект написали на кроссплатформе, но потом решили от этого отказаться, потому что, например, сложно искать разработчиков под устаревшую кроссплатформу или в какой-то момент времени руководство решило перейти на натив, чтобы обеспечить большую стабильность работы приложения и предсказуемость разработки.
Но есть и обратный поток, который идет от натива в сторону новых кроссплатформ, — например, Kotlin Multiplatform. Недавно вот появилась новая кроссплатформа SCADE 2.0 на Swift, на которой можно также делать интересные проекты с общей логикой.
Что касается ошибок. Они одинаковые для всех компаний, разрабатывающих мобильные приложения и софтверные здесь не исключение:
- Попытка развивать проект на старом и не всегда хорошо работающем коде, вместо того чтобы разработать новый вариант сервиса;
- Неумение и/или нежелание слушать команду разработчиков;
- Директивный подход в управлении сложными техническими проектами;
- Незаинтересованность в конечном результате со стороны менеджмента.
Каждый отдельный проект — это отдельная история, и складывается она по-разному. Мы же стараемся найти заинтересованного в успехе проекта заказчика и подсказать ему, как мы можем сделать лучше. Для этого разъясняем заказчику последствия принимаемых решений.
Заинтересованный в успехе проекта заказчик, способный принимать решения, — это ключ к успешному созданию мобильного приложения.
Николай Николенко, технический директор KODE
С 2013 года мы создаём цифровые продукты для государства и крупного бизнеса в России и Европе. Что мы можем подытожить, исходя из нашего опыта работы с софтверной тематикой:
1. Стек технологий должен «подходить» заказчику
Когда продукт делается на заказ, важно понимать, как его будут в дальнейшем эксплуатировать, поддерживать и дорабатывать. От ответов на эти вопросы зависит весь стек разработки и конкретных решений.
Мы стараемся всегда создавать продукт так, чтобы ИТ-команда заказчика (или любой другой вендор) могли его сопровождать после приёмки продукта, для этого предоставляем полную и понятную документацию, современный стек с учётом особенностей заказчика.
Здесь необходимо придерживаться здравого смысла и соблюдать баланс: если у заказчика есть компетенция, но эта технология устарела, то лучше использовать актуальное решение, принятое на рынке, и где-то доучить команду заказчика, либо помочь ему нанять нужного специалиста.
Это будет оптимально по времени и деньгам. Продукты, которые мы делаем сейчас, будут работать ещё долгое время и должны быть масштабируемыми как по функционалу, так и по нагрузкам.
2. Информационная безопасность и инфраструктура — кладезь сюрпризов
Практически любая разработка глубоко интегрирована с внутренними системами и процессами компании. Нельзя просто взять и сделать сервис в вакууме.
Он должен где-то находиться, как-то доставляться на прод, запускаться, мониториться, принимать и передавать какие-то данные и при этом соответствовать требованиям информационной безопасности и политикам компании, а также быть вписан в текущую инфраструктуру заказчика.
Это бывает такой же сложной задачей, как и разработка самого сервиса. У заказчика могут быть десятки других сервисов. Если каждый будет оригинальным образом запускаться и доставляться на прод, то когда-то это плохо закончится.
Мы анализируем ИТ-ландшафт и используемые технологии, выясняем, откуда сервис будет получать необходимые данные, как и куда их передавать, какой объём данных будет храниться и перемещаться по сети.
Это нужно, чтобы построить правильную архитектуру и инфраструктуру системы, пройти согласования с отделом ИБ и обеспечить необходимый уровень отказоустойчивости, безопасности и масштабируемости. Интересная задача для архитектора, DevOps-специалистов и аналитиков.
Выводы
Нельзя создать сервис в вакууме. Мы не делаем продукты, которые потом лежат на полках: мы хотим, чтобы они работали и приносили людям пользу.
Вот несколько областей, где нужно находить компромисс с заказчиком:
- Команда разработки должна проектировать сервис, который сможет интегрировать в инфраструктуру заказчика.
- Стэк разработки должен быть актуальным. Инхаус-команда заказчика должна уметь поддерживать выбранные решения, а при необходимости заказчик в любой момент мог найти на рынке специалистов для доработки и обслуживания системы.
- Отдел ИБ — наши друзья, которые делают сервис безопасней.
- Не слепо выполнять ТЗ, а понимать конечную цель продукта.
Другие советы по теме digital-маркетинга для разработки ПО