Connect with us

Разработка

Сколько стоит мобильное приложение в 2017 году

AppCraft

Опубликовано

/

     
     

В одной из предыдущих статей мы приводили результаты опроса более 55 компаний – разработчиков мобильных приложений из 15 стран – о стоимости разработки типовых приложений. Вот они:

То есть создать усредненное мобильное приложение стоит около 3–4 млн рублей и занимает 4–4,5 месяца. В той же статье мы упоминали, что разработка MVP обходится гораздо дешевле. Но насколько дешевле? Оценки студий разработки мобильных приложений разнятся в десятки (!) раз как по срокам, так и по стоимости. На графике ниже приведены оценки различных студий по разработке аналога WhatsApp:

Кто-то готов разработать мессенджер за 2 месяца и 1,2 млн рублей ($20k), а кто-то за 6 месяцев при том же бюджете. Другие студии готовы сделать его за 6 месяцев, но с бюджетом не меньше 15 млн рублей.

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

Так как же понять, сколько все-таки должна стоить разработка мобильного приложения, если оценки студий так сильно разнятся? Какова себестоимость создания программного продукта? Мы постараемся ответить на этот вопрос исходя из нашего опыта запуска нескольких десятков продуктов за 2017 год.

Что нужно сделать

Разработка мобильного приложения – понятие в оценке по стоимости даже шире, чем “купить автомобиль”. Речь может идти о создании тестовой сборки для проверки работоспособности концепции; возможно, это будет MVP – минимальный жизнеспособный продукт (minimal viable product), задача которого проверить работоспособность экономической модели; возможно, доработка более полной версии из работающего MVP; это может быть и целый программный комплекс, включающий в себя связки со сторонними сервисами, платежными системами, сложной серверной логикой и так далее.

Поэтому прежде всего в ожидании ответа на вопрос “сколько стоит разработка мобильного приложения” нужно определиться, о каком типе продукта идет речь.

Каким способом делать

Есть множество методологий разработки проектов, однако все они делятся на две большие категории: водопадный (классический) метод и scrum – так называемая “гибкая разработка”.

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

Вторая парадигма (scrum) заключается в итерационном подходе к созданию продуктов. Определяется, как мы можем сделать готовый (это важно) продукт за 2 недели. Далее мы запускаем его, смотрим что получилось, что нужно добавить, и формируем объем работ еще на 2 недели. То есть изучаем, планируем, делаем, проверяем и так далее по циклу.

Водопад

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

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

Минусы:

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

Scrum

Гибкая методология разработки (agile на примере scrum) – подход, заключающийся в построении специального цикла создания продукта с целью минимизации затрат, увеличения скорости и постоянного уточнения направления разработки. Организация работы в этом случае выглядит следующим образом:

Гибкая методология хороша следующим:

  • Она гибкая. Итерации (спринты) длятся примерно 1–2 недели, после чего появляется возможность скорректировать линию разработки частично или полностью;
  • Стоимость начального продукта (MVP) всегда ниже, чем цена версии с полным функционалом;
  • Разработка ведется быстрее за счет того, что маленькие сроки выполнения работ удобнее контролировать и легче исполнять;
  • Вы делаете только то, что нужно вашим потенциальным клиентам. Правило Парето действует и в случае с мобильными приложениями: пользователям нужно только 20% функционала, 80% используется единицами или не используется вообще. В случае со scrum вы платите только за эти 20%.

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

Какова цель проекта

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

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

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

Кто будет его использовать

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

Как рассчитывается стоимость

Стоимость любых работ рассчитывается исходя из двух параметров: их объема и стоимости часа труда:

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

  1. Оформление документации;
  2. Проектирование системы;
  3. Общие вопросы хранения и обработки данных;
  4. Вопросы синхронизации данных;
  5. Прототипирование;
  6. UI/UX дизайн, разработка;
  7. Полировка UI/UX дизайна на прототипе;
  8. Управление аккаунтами пользователей;
  9. Серверная логика;
  10. Интеграция с внешними сервисами;
  11. Реализация Push уведомления, онбоардинг;
  12. Поддержка версионной совместимости;
  13. Тестирование продукта;
  14. Запуск.

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

Стоимость одного часа работ только в России варьируется от 600 до 3500 руб за час, в мире разброс цен выше. Цена зависит как от уровня квалификации специалистов, так и от бренда самой студии.

Пример 1: мессенджер

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

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

Для сообщений также используются существующие протоколы передачи данных (protobuf) с дополнительным шифрованием.

Для разработки мобильного приложения под одну платформу потребуется 2–3 недели работы одного специалиста + пару дней работы дизайнера по графике и анимациям. Если взять стоимость часа специалиста в студии в 1200 руб, то получим ~120 тыс. рублей под одну платформу.

Серверная часть при этом потребует также 2–3 недели работы серверного специалиста (в случае с CallBox больше в силу уникальности технологии). Итого общая оценка приложения под 2 платформы (iOS и Android) вместе с северной частью составит примерно 360 тыс. рублей и 3 недели работы.

Теперь представим, что нужно добавить пересылку фотографий в чатах, стикеры и видеозвонки:

  1. Добавление возможности отправки фотографий в чате на клиентской стороне (мобильное приложение) – примерно 2–3 дня и ~24 тыс. рублей. Серверная часть также требует доработок;
  2. Стикеры – еще 2–3 дня и такая же сумма под одну платформу, плюс от одной недели работы художника в зависимости от количества стикеров в наборах. Это будет стоить от 50 тыс. рублей;
  3. Видеозвонки требуют бóльших трудозатрат и на клиентскую, и особенно на серверную сторону, их интеграция потребует около 2-х недель работы и 300 тыс. рублей для трех специалистов.

В результате эти доработки обойдутся примерно в 450 тыс. рублей и займут еще 3–4 недели. То есть дополнительные функции по объему стоят больше, чем само приложение. При этом, что важно, практически в любом наборе функционала действует закон Парето: только 20% функций будут востребованы, только они будут формировать ценность для пользователя. Таким образом, если не продумывать функционал тщательно, просто добавляя его по собственному желанию, 80% средств на разработку будет потрачено впустую.

Пример 2: качество вождения автомобиля

На этот раз есть задумка сделать приложение для автоматического отслеживания качества вождения автомобилей и продать весь сервис или его услуги страховым компаниям. Что-то аналогичное сервису AXA FlexiDrive.

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

  1. Просматривать совершенные поездки;
  2. Получать информацию о качестве собственного вождения;
  3. Получать рекомендации по повышению качества вождения;
  4. Просматривать каталог страховых компаний;
  5. Связаться с представителями страховых компаний;
  6. Находить свой автомобиль на парковке;
  7. Оплачивать парковку.

Реализация всего этого функционала займет примерно 2 месяца работы при стоимости 1–1,5 миллиона рублей. Однако и здесь действует тот же принцип: бóльшая часть функционала приложения не будет востребована подавляющим большинством пользователей.

Итак

Стоимость разработки мобильного приложения складывается не только из объема работ, но и из ответов на вопросы как именно его нужно разработать, для кого и с какими целями. Важно постоянно держать во внимании два аспекта:

  1. Принцип Парето: 20% работы дают 80% эффективности, 80% работы дают только 20% пользы;
  2. Мы делаем приложение не для себя, а для пользователей.

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

Стоимость разработки MVP практически любого мобильного приложения составляет 150–250 тыс. рублей под одну платформу – это 2–4 недели работы опытного специалиста. Две платформы (iOS и Android) и серверная часть – 350–450 тыс. рублей при тех же сроках.

Доработка расширенного функционала может занимать большое количество ресурсов – сложность решений может быть высокой с большими трудозатратами на их реализацию.

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

  1. Какие именно работы включены в оценку?
  2. Сколько времени занимает работа с документацией?
  3. Сколько времени занимает дизайн?
  4. Какие работы помимо документирования, дизайна и программирования входят в расчетный объем?
  5. Какова стоимость одного часа работ?
  6. Даете ли вы рекомендации по необходимому и избыточному функционалу?

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

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

 

Комментарии
Если вы нашли опечатку - выделите ее и нажмите Ctrl + Enter! Для связи с нами вы можете использовать info@apptractor.ru.
Advertisement
Click to comment

You must be logged in to post a comment Login

Leave a Reply

Новости

Интересные материалы: 21.02

В новой подборке ASCII-арт, карты развития, практики и ловушки.

Леонид Боголюбов

Опубликовано

/

Весь день мы собираем лучшие материалы о разработке и маркетинге технологий, стартапов, мобильных приложений и игр для iOS и Android из самых разных источников:

Комментарии
Продолжить чтение

Программирование

Создание анимации в 7 строк кода

Android-разработчик Леонардо Пирро рассказывает, как создать простую анимацию при помощи ConstraintLayout и ConstraintSet.

Анна Гуляева

Опубликовано

/

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

ConstraintLayout + ConstraintSet

Я хочу поделиться с вами новым способом создания анимаций в приложении при помощи всего семи строк кода, используя Keyframe Animations, ConstraintLayout и ConstraintSet. Эта концепция заключается в создании двух разных макетов: одного для начальной точки и одного для конечной точки анимации. Давайте посмотрим, что мы хотим создать: наша цель — создать плавную анимацию детали, которая будет появляться при нажатии пользователем на экран.

Анимация создается при помощи двух файлов макета: circuit.xml and circuit_detail.xml. Эти макеты очень похожи и различаются только тем, что на первом элементы вынесены за экран, а на втором — находятся в нужной позиции.

Поэтому давайте создадим анимацию и увидим, как просто создавать анимацию при помощи ConstraintLayout и ConstraintSet.

Пусть магия произойдет

Сначала создадим отдельный ConstraintSet, куда мы скопируем ограничения второго макета, вызвав метод clone():

val constraintSet = ConstraintSet()
constraintSet.clone(this, R.layout.circuit_detail)

Теперь создадим объект перехода, используемый для установки интерполятора и продолжительности анимации:

val transition = ChangeBounds()
transition.interpolator = AnticipateOvershootInterpolator(1.0f)
transition.duration = 1200

Сейчас вызовем TransitionManager.beginDelayedTransition(), который используется для осуществления перехода на следующий кадр рендеринга. Затем мы вызываем applyTo(), чтобы начать анимацию.

TransitionManager.beginDelayedTransition(constraint, transition)

constraintSet.applyTo(constraint)

Это действительно семь строк кода. Вот и все! Вы можете посмотреть полный пример в моем репозитории GitHub по этой ссылке.

Комментарии
Продолжить чтение

Разработка

Как мы сократили размер приложения с 31 МБ до 2 МБ

Создатель приложения WhatSaga поделился историей разработки и борьбы за качество конечного продукта.

Анна Гуляева

Опубликовано

/

Четыре недели назад я опубликовал первое приложение в Google Play. Немного бэкграунда: меня зовут Иршад, я учусь на последнем курсе колледжа по направлению информатики и уже несколько лет занимаюсь программированием и разработкой. История началась около пяти месяцев назад: однажды второкурсник Атул Наир сказал мне, что хочет поучиться разработке приложений на Android.

Лучший способ узнать что-то — делать это непосредственно. Я посоветовал ему создать простое приложение и предложил несколько идей:

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

Функция “статуса” в WhatsApp в то время была довольно новой, поэтому эти идеи казались мне вполне интересными.

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

Что дальше?

Мы разделили задачи на три группы:

  1. Текущие статусы
  2. Видеостатусы
  3. Аудиостатусы

Благодаря первоначальному энтузиазму я смог создать первую функцию за 2–3 дня, так как это было довольно простой и знакомой задачей.

Затем я начал помогать Атулу в создании видеостатусов. У меня было несколько других проектов, поэтому в основном я только искал библиотеки для работы с видео, пока он писал сам код. Вскоре функция была закончена, но была одна проблема.

Да, Атул быстро учился, и он отправил мне APK через неделю, но размер файла был 31 МБ и я не мог этого понять. Мы решили использовать популярную библиотеку ffmpeg для обработки видео, хотя проще всего было использовать Ffmpeg-Android от WritingMinds. Встроенные библиотеки весили больше 27 МБ, что вносило самый большой вклад в размер APK. Я сказал, что мы должны сделать размер файла как можно меньше.

После нескольких недель он вернулся и размер APK составлял уже 18 МБ, а приложение работало, как и раньше. Атул последовал этому совету и включил только версию armv7, что сократило размер приложения в два раза. Но этого было недостаточно: люди не будут скачивать приложение, которое занимает больше 5 МБ. Я был упрям. Я показал ему несколько видеоредакторов в Google Play, которые занимали менее 5 МБ и спросил, почему мы не можем сделать так же.

В итоге, после ещё нескольких попыток Атул пришел с хорошей новостью. Он сократил размер APK до 2.6 МБ. Он был таким же упрямым и нашел нужное решение. Он использовал нативный компилированный C++ файл .so с минимальными функциями ffmpeg, который включал и нужную нам функцию. Файл занимал 4 МБ, но после сжатия стал весить всего 2 МБ. Вот анализ APK-файла версии 1.2:

Да, теперь он занимает 2.9 МБ после обновления с поддержкой WhatsApp for Business

Кроме того мы использовали такие функции, как proguard minify и drawable optimization, чтобы другие ресурсы не занимали много места. Все пошло быстрее, мы создали функцию аудиостатусов, а потом выпустили наше приложение в Google Play в течение нескольких дней!

Мы назвали приложение WhatSaga, и вы можете посмотреть его здесь.

Представьте, если бы я сдался быстрее. Мы бы сделали решение в 10–15 МБ или даже больше, и это не идет ни в какое сравнение с 2.6 МБ. Действительно ли размер приложения так важен в современных смартфонах с гигабайтами памяти и трафика? Ответ: да. Если у вас будет два приложения с похожим интерфейсом и функциями, но одно из них будет на 3–4 МБ тяжелее, какое вы выберете?

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

Так что будьте настойчивы в качестве всего,что вы делаете. Дизайн, время загрузки или внешний вид — не успокаивайтесь, пока продукт не будет обладать тем качеством, которое вы хотите видеть.

Комментарии
Продолжить чтение

Новости

Интересные материалы: 20.02

Сегодня у нас в дайджесте санаторий для мозга, фреймворк для онбординга и тормоза разработки.

Леонид Боголюбов

Опубликовано

/

Весь день мы собираем лучшие материалы о разработке и маркетинге технологий, стартапов, мобильных приложений и игр для iOS и Android из самых разных источников:

Комментарии
Продолжить чтение

Постеры для разработчиков

Наша рассылка

Каждому подписавшемуся - "1 час на UI аудит": бесплатный ускоренный курс для разработчиков!

Нажимая на кнопку "Подписаться" вы даете согласие на обработку персональных данных.

Вакансии

Популярное

X
X

Спасибо!

Теперь редакторы в курсе.