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

Новости

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

Обсуждаем дизайн заказа бургеров, рост приложений и читаемость кода.

AppTractor

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

/

Автор:

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

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

Дизайн и прототипирование

Инструменты дизайна и прототипирования – что используют разработчики приложений

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

AppTractor

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

/

Автор:

Дмитрий Нор, директор компании SkySoft

  

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

После того, как требования известны, мы приступает к созданию прототипа. В основном мы используем программу Balsamiq Mockups, так как в ней можно делать прототипы для веб-сайтов и мобильных приложений. Программа простая и очень удобная. И с помощью нее можно решить практически любые задачи по созданию прототипов. Иногда мы используем Axure RP. Выбор программы зависит от задач проекта и в основном он делается так: в чем удобнее, там и рисуем.

После того как прототип или прототипы (опять же зависит от сложности проекта и его задач) мы отдаем его на согласование клиенту и рассказываем, как потом все будет работать (если он сам не понимает). Если у клиента не возникает желания что-то переделать, то пускаем в дальнейшую работу, если возникает – переделываем и после утверждения пускаем в дальнейшую работу.

Потом рисуется сам дизайн по прототипу. Иногда рисуется самостоятельно, иногда берутся готовые шаблоны (все опять же зависит от задач проекта и его бюджета). Из программного обеспечения мы в основном используем Adobe Photoshop. Его функционала достаточно для создания тех проектов, которые мы делаем. Иногда мы используем Adobe Illustrator. В этом приложении удобно рисовать векторную графику.

После того, как макет дизайна готов – мы отдаем на согласование клиенту. Если возникают правки – делаем, еще раз согласовываем и запускаем в дальнейшую работу.

Дина Мильштейн, руководитель отдела дизайна EastBanc Technologies

    

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

На старте проекта для каждого мобильного приложения мы вырабатываем дизайн-концепцию на 5-10 экранов и согласовываем с заказчиком.

Итак, мы договорились об основах, как будет выглядеть и работать мобильное приложение. В сказках всё кончается словами «Они поженились и жили долго и счастливо», а на деле тут-то и начинается самая большая и кропотливая работа. Также и у нас.

Прототипирование UI/UX — бумага и Sketch

Чтобы разобраться, как будет работать мобильное приложение, мы делаем первые наброски на бумаге, а потом переносим их в Sketch. Мы прошли путь от Photoshop к Sketch, эргономичной программы, сделанной для разработки интерфейсов. От Photoshop категорично не отказываемся, он идеально подходит для работы с растрами. Выбор инструмента всегда зависит от задачи. Всё должно быть уместным.

Нужен цифровой бренд-бук. Если его нет — надо создать

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

Иллюстрации в Illustrator

Мы делаем наши приложения «тёплыми», чтобы люди, работая с ними, испытывали не только удобство, но и теплые эмоции. Поэтому в случаях, когда это уместно, мы добавляем иллюстрации в наши приложения. Идеальным инструментом для создания иллюстраций, на наш взгляд, является программа Illustrator.

Интерактивный прототип — Invision

Когда логика и стилистика готовы, мы примеряем этот «костюм» на заказчика и представляем ему решение. Чтобы презентовать задуманное, используем анимированный прототип решения в Invision. Это повышает эффективность коммуникации как с заказчиком, так и с разработчиками.

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

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

Анимация и поведение — Flinto

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

Нарезка и передача в разработку — Zeplin

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

Качественный результат гарантирован процессом

Мы щепетильно относимся к мелочам и фактам. Всё должно соответствовать задаче и выглядеть достоверным, чтобы заказчик сразу соотносил увиденное со своими рабочими процессами.

На каждом этапе разработки UI/UX от идеи до готового продукта мы последовательно фиксируем понятный, ограниченный и полностью проработанный элемент визуальной платформы. На рынке постоянно дорабатываются существующие и появляются новые инструменты. Главное держать в голове, зачем они нужны именно вам и какой именно результат вы планируете получить.

Евгения Горбунова, Finch

  

Мы уже 10 лет создаем приложения для крупных брендов вроде ТНТ, Спартака, ТВ-3, Столото. В нашей работе мы используем достаточно стандартный набор инструментов: Sketch, Zeplin, Sympli, Adobe Photoshop, Adobe Illustrator.

Для дизайна макетов в основном используем Sketch. Что касается самого процесса разработки дизайна, то тут всегда по-разному. Обычно мы работаем по алгоритму «бумага» → «прототип» → «дизайн». То есть наш дизайнер сперва тратит время на поиска решения на бумаге, затем начинает рисовать прототипы и макеты в Sketch и только после этого занимается дизайном. На последнем этапе, как правило, клиенты оставляют наибольшее количество правок: цвета не те, иконки другие, форму стоит поменять и т.д. Поэтому у нас бывали случаи, когда после финального дизайна, мы начинали все по новой и вновь ныряли с головой в проект, чтобы найти другое решение.

Ольга Костина, ведущий UI/UX дизайнер Seven Winds Studio

   

В нашей студии разработка дизайна мобильных приложений происходит следующим образом. На основе ТЗ создаётся прототип. До настоящего времени мы использовали для прототипирования NinjaMock, но планируем перейти на другую платформу. Сейчас присматриваемся к другим сервисам, среди которых Marvel, Invision и Flinto.

Дизайн интерфейса создаём в Sketch, и затем экспортируем готовые экраны в Zepelin для работы верстальщиков с ними. Иногда, наравне со Sketch, используем Figma. Этот сервис удобен тем, что над одним проектом могут работать несколько дизайнеров одновременно, и все изменения сохраняются в одном проекте, c которым впоследствии работают те, кто верстает экраны.

Юлия Гулюк, Grapheme

    

Раньше для проектирования и разработки интерфейсов мы использовали связку Sketch Zeppelin, а для демонстрации дизайна клиенту мы создавали интерактивные прототипы в Marvel или Invision. Когда макет дизайн был утвержден, мы прибегали к помощи моушн-дизайнера, чтобы упростить коммуникацию с верстальщиками. Он визуализировал идеи команды дизайнеров, чтобы разработчикам можно было наглядно объяснить, какие эффекты задумали дизайнеры и как их нужно реализовать. В общем, это был достаточно сложный процесс. Он требовал применения различных инструментов и отнимал много времени специалистов. Особенно много времени и сил уходило на коммуникацию. Но самым большим недостатком этого подхода была невозможность установить Sketch на любые другие платформы, кроме macOS.

Потом мы открыли для себя Figma и стали счастливее. Это приложение позволяет работать всей команде одновременно в одной среде на любой ОС. Там же осуществляется коммуникация как друг с другом, так и с клиентом посредством комментариев к элементам, ведь в Figma можно делать интерактивные прототипы и сразу показывать клиентам. Обычно работа над дизайном проекта начинается с прототипирования. У нас этим занимается любой свободный дизайнер. Со свежей головой он вникает, задает вектор и приглашает в приложение еще одного дизайнера, если приложение сложное или требуется взгляд со стороны. На этом этапе идет детальная разработка прототипов. Уже здесь команда решает, какая будет сетка и почему, какие будут шрифты, кегли, легко ли они будут читаться пользователем. Все это прорабатывается параллельно с архитектурой приложения, создания гайдов для элементов. Пожалуй, это самая сложная и длительная часть в разработке дизайна приложения.

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

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

Подкаст AppTractor: дизайн мобильных приложений

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

Новости

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

В новом дайджесте рассказы про Material Design, ухудшающие A/B тесты и, как обычно, улучшения продуктивности – теперь для соло-разработчиков.

AppTractor

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

/

Автор:

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

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

Медиа

Podlodka #60: Женщины в IT

Для юбилейного выпуска выбрали щекотливую тему – женщины в IT.

AppTractor

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

/

Автор:

Podlodka

Несмотря на довольную веселую подачу с шутками и прибаутками, авторы попытались разобраться в сложной теме дайверсити. Действительно ли есть такая проблема, а главное, что с этим всем делать, чтобы не перегнуть палку? Выпуск полон историй из жизни Кати Петровой из стартапа и Аси Кононовой из Яндекса, а также присыпан щепоткой микроагрессии от Егора и Стаса. Словарное слово выпуска: “цисгендер”.

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

Реклама

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

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

Вакансии

Популярное

X
X

Спасибо!

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