Разработка мобильных приложений
4 октября 2019
Кроссплатформенная разработка: за или против?
Кроссплатформенные приложения – быть или не быть? Вопрос непростой, так как у каждого бизнеса есть свои цели и требования к мобильным приложениям. Но сегодня мы точно разберёмся в том, какая разработка подойдёт вам.Что такое кроссплатформенные приложения?
Кроссплатформенные приложения – приложения, которые разрабатываются и затем работают сразу и на Android, и на iOS. Суть разработки в том, что исходный код приложения переводится в нативный, то есть понятный конкретному мобильному устройству. В результате программа может взаимодействовать с установленной на нём операционной системой.
Напомним: нативные приложения, в отличие от кроссплатформенных, пишутся под конкретную ОС.Плюсы кроссплатформенной разработки
расширение пользовательской базы за счёт появления приложения одновременно в нескольких магазинах; одинисходный код избавляет вас от необходимости нанимать нескольких разработчиков для каждой платформы; 75% кодовой базы кроссплатформенного приложения можно использовать повторно, адаптируя её для новых проектов.
Минусы кроссплатформенной разработки
1. Большая зависимость от мобильного устройства
Кроссплатформенные приложения обычно не работают оффлайн. Поэтому их возможности сильно зависят от наличия у пользователя стабильного подключения к интернету. Версия операционной системы и модель аппарата тоже важны. Кроссплатформенное приложение почти гарантировано снизит производительность устройства старше одного-двух лет. В то время как нативное приложение будет стабильно работать даже на древнем гаджете с устаревшей прошивкой. Так что если не хотите, чтобы ваши клиенты читали гневные отзывы о том, как ваше приложение окончательно «добило» чей-то смартфон – выбирайте нативную разработку.
2. Недружелюбный пользовательский интерфейс
Пользователи настолько сильно привыкают к внешнему виду и функционалу своих гаджетов, что ждут от установленных на них приложений максимальной отзывчивости. Они хотят быть уверенными в том, что каждая кнопка будет на своём законном месте, что прокрутка страницы будет идти с оптимальной для них скоростью, а на любое их действие последует незамедлительная реакция. Кроссплатформенные приложения обычно с трудом адаптируются к устройству, да и быстродействием похвастаться не могут.
Проблема в том, что для кроссплатформенной разработки не бывает гайдлайнов – стандартов разработки от создателей ОС. Поэтому кроссплатформенное приложение, сделанное «под Android», не будет удобным пользователю iOS, и наоборот. Можно, конечно, создать отдельные дизайны для каждой платформы, но по объёму трудозатрат это будет равно созданию двух разных приложений, хоть и на одном языке.
3. Борьба за первенство среди инструментов разработки
На рынке решений для кроссплатформенной разработки конкуренция ужесточается с каждым днём. Пока что наибольшей популярностью у разработчиков пользуются React Native и Xamarin, но их вполне может опередить, например, Vue Native. В таком случае экс-лидеры гонки лишатся важнейшего преимущества – оперативной поддержки кода. И такое может произойти с любым кроссплатформенным инструментом.
Нативной разработке подобная проблема не страшна. Внедрение новых инструментов происходит постепенно, а знание нескольких языков программирования, обязательное для узкого специалиста, позволит ему быстро разобраться со всеми нововведениями. Кроме того, существуют огромные профессиональные сообщества вокруг каждой операционной системы, в результате чего любая возникшая сложность решается поиском подобной проблемы на форумах, где тысячи людей готовы подсказать и помочь ее решить.
Какое приложение подойдёт вашему бизнесу?
Перед тем, как ответить на этот вопрос, крайне важно проанализировать свой бизнес. Потребительские сегменты, ценность временных и денежных ресурсов, желательная глубина интеграции приложения с устройствами пользователей плюс чётко очерченные долгосрочные цели – тот минимум, от которого будет зависеть ваш выбор. Но мы сделаем его проще, если вы прямо сейчас ответите на соответствующие вопросы.
1. Чем пользуется ваша аудитория?
Если вы знаете, что соотношение количества пользователей iOS и Android среди ваших клиентов близко к пропорции 50 на 50, выбирайте нативную разработку. Так вы покажете, что в равной степени уважаете потребности всех ваших клиентов вне зависимости от уровня их дохода.
Связь между выбором мобильного устройства и уровнем платёжеспособности в очередной раз подтвердила компания App Annie. В результате исследования числа загрузок и объёма продаж мобильных приложений в Google Play и App Store за первый квартал 2018 года выяснилось, что пользователи Android-смартфонов скачали на 135% больше приложений, чем посетители iOS-магазина. В то же время App Store принёс своим владельцам на 85% больше дохода, чем Google Play.
Путь к успеху очевиден: играть на двух полях сразу. Точнее, на двух магазинах. Просто рассчитайте, в каком из них приложение должно появиться первым. Конечно, если одновременный релиз не является частью вашей digital-стратегии).
2. Сколько у вас времени на разработку?
От ответа на этот вопрос зависят финансовые издержки проекта. Дело в том, что с точки зрения затраченного на разработку времени кроссплатформенное приложение только кажется более выгодным решением. На самом деле, его адаптация под платформы может занять почти столько же времени, сколько и создание двух нативных приложений, поскольку разработчикам придётся писать дополнительные части кода для проблемных мест.
С нативным приложением таких проблем точно не будет, что очень важно для удержания аудитории, которая крайне не толерантна к ошибкам и багам. По статистике компании Compuware, 79% пользователей готовы перезапустить приложение, если оно некорректно заработало во время первого запуска, но вот дать ему ещё один шанс согласны всего 16%. Остальные, скорее всего, просто удалят программу.
3. Какие функции устройства вы планируете использовать?
Мы уже рассказывали о том, что только нативные приложения способны воспроизводить тяжёлую графику быстро и без потери качества. Но этим технические преимущества нативной разработки не ограничиваются. В качестве примера можно взять приложение Facebook. Благодаря выпуску отдельных версий под Android и iOS прокрутка стала более плавной, сократилось время загрузки изображений и были решены все проблемы с кэшем.
Более того, нативные приложения получают прямой доступ ко всем службам устройства, что позволяет вам получить информацию о геопозиции пользователя или его списке контактов. Кроссплатформенным приложениям приходится использовать специальные нативные плагины, что отрицательно сказывается на скорости передачи данных и перегружает оперативную память устройства.
4. К каким результатам вы стремитесь?
Digital-стратегия– это список целей, которых ваша компания может достигнуть с помощью цифровых инструментов. Выбор последних во многом зависит от преимуществ, которые вы хотите получить в итоге.
Разложите процесс от идеи до результата по пунктам, учитывая все имеющиеся ресурсы. Открытия могут быть самыми неожиданными. Например, вы можете обнаружить, что перевести ваш адаптивный сайт с множеством функций и интерактивными элементами в кроссплатформенное приложение, как вы хотели изначально, – слишком затратная задача. Или окончательно убедитесь в том, что мобильный сайт всегда проигрывает мобильному приложению – как кроссплатформенная разработка проигрывает нативной. И среди причин обнаружите те, о которых мы рассказали выше. Вывод: кроссплатформенное приложение выгодно только в одном случае – вы создаёте демо-версию приложения, ограничены в сроках, деньгах и узкопрофильных специалистах. Во всех остальных случаях нативное приложение даст вам в разы больше преимуществ, так как это – качественно иной уровень разработки.
5 основных метрик для контроля качества мобильного приложения
«То, что можно измерить, можно улучшить», — сказал отец современной теории менеджмента Питер Друкер. Но что измерять мобильному стартапу? Как отличить действенные метрики мобильных приложений, основанные на фактических данных, от «тщеславных показателей», способных только тешить самолюбие разработчика? И главное — зачем?Молодой человек изучает показатели эффективности мобильного приложения
Затем, чтобы выявить сильные и слабые стороны приложения. Вы никогда не исправите последние, если будете собирать ошибочные данные или обрабатывать верные данные не тем способом. Чтобы не загубить свой стартап в самом начале, мы рекомендуем отслеживать 5 ключевых показателей эффективности мобильного приложения из нашей статьи. Но перед тем, как перейти к ним, напомним, что любой компании нужно в первую очередь следить за финансовыми метриками, среди которых:
Постоянные и переменные издержки; Остаток денежных средств; Скорость выгорания капитала; Точка безубыточности; Денежный поток; Прибыль.
1. Средний доход с одного пользователя и суммарная прибыль от сотрудничества с ним
Суммарная прибыль c одного клиента — один из основных показателей успешности выбранной вами бизнес-модели. Применительно к мобильной разработке он говорит о финансовой ценности вашей компании, показывая, какой вклад вносит в неё каждый пользователь на протяжении всего времени взаимодействия с приложением. Джозиа Хампфри из Appster предлагает прогнозировать суммарную прибыль с пользователя, умножая годовую стоимость услуг (например, подписки на приложение) на количество лет, на протяжении которых пользователь, как вам кажется, будет оставаться с вами. Например, если в среднем ваш клиент тратит 1200 рублей в год и пользуется приложением в течение 5 лет, то суммарная прибыль от него составит 6000 рублей.Молодые люди определяют концепцию нового прекрасного мобильного приложения
В случае со стартапами, эта формула может не работать из-за отсутствия достаточного объёма данных. Поэтому вместо собственной статистики можно использовать статистику ближайших конкурентов, чтобы понять, к какому показателю надо стремиться. В любом случае, предприниматели сходятся во мнении, что для обеспечения рентабельности компании, суммарная прибыль с одного пользователя должна превышать затраты на его привлечение как минимум в три раза.
Средний доход с одного пользователя (ARPU) — это показатель, связанный с особенностями покупательского поведения вашей аудитории. Он нужен для анализа источника доходов компании. В том числе, его изменения от каждой новой установки мобильного приложения или совершённой в нём покупки. Из этой метрики инвесторы делают выводы о потенциальной прибыльности проекта, а разработчики — о его недостатках. В целом, увеличение обоих показателей наряду с расширением пользовательской базы — в ваших интересах.
2. Стоимость установки приложения и стоимость лояльного пользователя
Стоимость установки (CPI) — это сумма, которую вы тратите на то, чтобы один человек установил ваше мобильное приложение. Вы размещаете рекламу в различных медиа, чтобы увеличить количество установок, и платите фиксированную или плавающую ставку за факт установки приложения. Число органических установок в эту метрику не входит.
Стоимость установки считается как отношение бюджета рекламной кампании к общему количеству установок приложения. Например, если вы потратили на рекламу 300 000 рублей и получили 1500 установок, то стоимость одной будет равняться 200 рублям. Стоимость лояльного пользователя (CPLU) — это сумма, которую вы тратите на то, чтобы заполучить «лояльного» или «активного» пользователя, который заходил в приложение более трёх раз.Студент устанавливает мобильное приложение во время интересной лекции
Эта метрика показывает, какую сумму вы должны потратить, чтобы привлечь аудиторию, которая действительно использует ваше приложение после установки. В связке со средним доходом с одного пользователя она поможет вам посчитать:
Коэффициент возврата инвестиций (ROI) — отношение заработанных средств к вложенным; Точку безубыточности — то количество установок мобильного приложения, при котором сумма постоянных и переменных издержек компании равна её доходу. Когда он превысит затраты, вы начнёте получать прибыль.
Статистика Fiksu DSP на данный момент такова:
Средняя стоимость лояльного пользователя на рынке мобильных приложений — 2,51 доллара; Средняя стоимость установки приложения для iOS — 1,88 доллара; Средняя стоимость установки приложения для Android — 2,42 доллара.
3. Удержание аудитории
На сегодняшний день в магазинах Google Play и App Store доступно более 6 миллионов мобильных приложений. Тем не менее, пользователи тратят почти 85% своего времени в смартфонах всего на 5 из них. А вероятность того, что ваше приложение удалят после 72 часов использования и больше никогда не установят — 4 из 5. Это значит, что люди довольствуются небольшим набором любимых приложений и не склонны его расширять. Очевидно, что в таких условиях удержание аудитории становится серьёзной проблемой, особенно для мобильных стартапов. По оценкам компании Apptentive, всего 4% пользователей iOS- и Android-устройств пользуются одними и теми же мобильными приложениями более года. Джозиа Хампфри из Appster считает, что «в тот момент, когда вы получаете нового пользователя, вы должны сделать всё возможное, чтобы он остался с вами максимально долго».Человек принимает судьбоносное решение
Inc.com и Молли Галетто определяют термин «удержание аудитории» как «способность компании строить и сохранять долгосрочные отношения с как можно большим числом клиентов». Но зачем удерживать пользователей мобильному приложению? Алекс Вальтц уверен, что знание этого показателя является отличным индикатором успешности приложения и количества его реальных пользователей. На основе этих данных вы можете усовершенствовать маркетинговую стратегию и сделать продвижение приложения более целенаправленным, а также подсчитать суммарную прибыль от сотрудничества с каждым клиентом и суммарный доход компании.
4. Вовлечённость аудитории
Вовлечённость — не эмпирический показатель. Её можно оценить, отслеживая и собирая различные данные:
продолжительность сессии; предпочитаемые способы взаимодействия с приложением; количество переходов в приложение через push-уведомления; общее число экранов, просматриваемых за сеанс.
История о том, что нужно отключать уведомления во время совещания
Вовлечённость важна потому, что она говорит о качестве мобильного приложения, дополняя количественные оценки. Активные пользователи не только поднимают показатели удержания аудитории и суммарной прибыли, но и способствуют вирусному распространению приложения через соцсети. Поэтому у крупнейших мобильных приложений, таких как Facebook, показатель вовлечённости очень высок. Подробнее мы разбирали вопрос вовлеченности в одной из прошлых статей.
5. Индекс потребительской лояльности
Индекс потребительской лояльности (NPS) — это один из самых эффективных показателей удовлетворённости пользователя и виральности мобильного приложения. Его можно измерить, задав аудитории следующий вопрос: «По шкале от 0 до 10, какова вероятность того, что вы порекомендуете наше приложение друзьям, коллегам и членам семьи?». Если вы хотите знать причины того или иного отношения к вашему продукту — задайте ещё один вопрос, но не более.
Очень лояльный пользователь мобильного приложения
В зависимости от ответа Netpromoter.com классифицирует пользователей следующим образом:
«Распространители» — ставят 9 или 10 баллов, готовы совершать покупки в вашем приложении и всячески его поддерживать.
«Пассивные потребители» — ставят 7-8 баллов, удовлетворены работой приложения, но вполне могут уйти к вашим конкурентам.
«Критики» — ставят ниже 6 баллов, не удовлетворены приложением и могут испортить репутацию вашего бренда, оставляя негативные отзывы в интернете и в жизни.
Итоговый индекс потребительской лояльности считается как разность между количеством «критиков» и количеством «распространителей».
Каким бы ни был результат, он даст вам представление о впечатлениях аудитории от вашего приложения и поможет:
понять, отвечает ли ваш продукт запросам рынка;
измерить ценность и вирусный потенциал приложения;
оценить, хотят ли пользователи делиться вашим приложением с другими людьми, делая их вашими потенциальными клиентами.
Стоимость разработки мобильного приложения в 2019 году
Сколько в среднем стоит разработка мобильного приложения
Короткий ответ – от 500 тыс до 5 млн рублей. Средняя цена чуть выросла по сравнению с прошлым годом.
Основная особенность рынка разработки мобильных приложений для заказчика – неопределенность цены и сроков. Одна студия может озвучить стоимость в 50 тыс рублей, другая в 20-50 раз большую за тот же объем работ. При этом первая может сделать продукт за два месяца, а вторая – за две недели.
Средние же мировые показатели с разбивкой по категориям приложений и географии студий следующие:
Указанные значения стоимости включают в себя полную разработку на одну платформу, iOS или Android, включая серверную часть, документацию, дизайн, аналитику, тестирование и подготовку к запуску.
Со средней величиной разброса по рынку более подробные данные российских студий следующие:
Базовое (офлайн) приложение, визитная карточка, простой функционал – от 150 до 500 тыс рублей.
Что-то, подразумевающее редактирование/модерацию в онлайне, наполнение статей и контента в админке, т.е. с серверной частью – от 500 до 900 тыс рублей.
Чат бот, интерактивный помощник – в районе 1 млн рублей.
IoT, связка с устройствами по Bluetooth/Wi-Fi/другим протоколам – 1–1.5 млн рублей.
Мессенджер (одно из наиболее популярных направлений) – от 1.5 до 2.5 млн рублей.
Дополненная и виртуальная реальность – 1.8–2.5 млн рублей.
Такси, доставка пицц, воды, продуктов и прочего, включая курьерский модуль – от 2 до 3 млн рублей.
Магазины/каталоги, включая личный кабинет, поиск, механику скидок, эквайринг – около 2 млн рублей.
Социальные сети сильно варьируются по функционалу, но вписываются в рамки от 2 до 4 млн рублей.
Самое дорогое – корпоративные приложения, предполагающие, как правило, интеграцию с целым спектром сервисов и имеющие повышенные требования к защите данных и обеспечению безопасности.
Разработка сразу под две платформы выходит примерно на 30-40% дороже.
.Из чего складывается стоимость разработки
Как правило, пропорции основных работ следующие:
Источник: upwork.com
То есть разработка дизайна для мессенджера, в среднем, будет стоить от 150 до 300 тыс рублей, во столько же обойдется менеджмент продукта, подготовка аналитического отчета и технического задания – 100–200 тыс, остальное (1,5–2 млн) – собственно разработка, тестирование и подготовка к публикации.
Дизайн, как правило, включает в себя прототипирование в InVision, Adobe XD, Marvel, Proto.io и других утилитах.
.Планшеты и поддержка горизонтальной ориентации
Реализация поддержки планшетов увеличивает стоимость продукта на 10-50% в зависимости от его типа. Пространство экрана используется по-другому, что требует и разработки дополнительного дизайна, и его имплементации в логику работы приложения.
Горизонтальная ориентация – плюс 10-30%, опять же в зависимости от того, что нужно повернуть.
.Сколько времени занимает разработка
От месяца до трех – столько по времени разрабатывается большинство мобильных приложений. Да, что-то сложное делается дольше, но 1-2 месяца – стандарт.
.Почему так дорого
Программист, сидящий за компьютером и пишущий прекрасный код – только небольшая часть общей картины по созданию продукта.
Помимо программиста над проектом работают специалист по UI/UX, аналитик, тестировщик и менеджер, курирующий всю разработку. Кроме того, почти всегда требуется разработка и серверной части – базы данных и API, формирующие основной узел информационной системы сервиса.
Себестоимость месячной работы команды из 3-5 человек уже составляет 500-700 тыс рублей (в зависимости от географии офиса и уровня профессионализма сотрудников).
Более крупные команды, включающие более узких специалистов, обходятся дороже. В создании IT продуктов основные деньги тратятся на покупку времени квалифицированных команд.
.Как уменьшить бюджет на разработку
Прежде всего – MVP. Не стоит делать что-то большое, после старта чаще всего случаются неожиданные повороты. Чем меньше функционала – тем легче поворачивать.
Сосредоточиться на цели. Потратить неделю для описания всего возможного функционала. После этого потратить столько же времени, еще неделю, на выкидывание всего лишнего. Если на вопрос “будет ли без этого приложение достигать свою цель?” ответ положительный – выкидывать без колебаний.
Рассмотреть возможность реализации кросс-платформенного приложения. Иногда это имеет смысл для MVP и почти вдвое уменьшает бюджет при реализации продукта сразу на двух платформах, iOS и Android.
Возможно, для достижения вашей цели подойдет и мобильная версия сайта. Иногда этого достаточно для старта и подтверждения рыночной гипотезы.
.Продвижение
Основной бюджет будет уходить на продвижение, а его начало – мягкий запуск со сплит тестированием – самая важная его часть. Поэтому вдвойне важно экономить на разработке, на которую должно приходиться не более 30-40% всего бюджета на создание и запуск продукта.
Про полный цикл разработки, начальное продвижение и экономическую стратегию запуска всего проекта напишем в следующих статьях. Оставайтесь на связи :)
Основные шаги для запуска и раскрутки мобильных приложений
Разработка завершена
Разработка мобильного приложения завершена, оно протестировано и размещено в магазинах приложений. Что делать дальше? Если приложение разрабатывалось для собственных нужд, понятное дело – пользоваться. Но как рекламировать и какие шаги предпринимать, если цель разработки – бизнес?
Наверняка вы просчитали финансовую модель и у вас уже есть сформированное представление о своих потенциальных клиентах. Это люди определенного возраста с определенными потребностями в определенное время и в определенном месте. Поэтому первое, что нужно сделать, – это понять, как к ним можно подступиться. Это может быть группа в социальной сети, в Telegram, подсайт Reddit или канал на YouTube. Совершенно неважно что, но с высокой концентрацией ваших потенциальных клиентов.
Выписав все места обитания целевой аудитории, нужно переходить к выстраиванию обратной связи. Если ваши потенциальные клиенты – “все люди”, значит у вас нет понимания целевой аудитории.
Фидбек
Это самое главное в вашем продукте. Если у вас есть 10 млн рублей на рекламу и вы сразу начинаете промо кампанию с салютом и аниматорами – частично или (что чаще) полностью – это потерянные средства. Главное в любом продукте – решение какой-либо проблемы пользователя с осознанием, что все потребности уже удовлетворены. Если мы хотим есть, то едим. Хотим смотреть фильм – смотрим. Это может быть дорогая еда, с долгим ожиданием, плохая или невкусная. Это может быть фильм в низком качестве, без перевода или с тихим звуком. Но мы будем есть и будем смотреть, так как хотим удовлетворить свои желания. Плохо, дорого, долго – неважно как.
Поэтому если вы не можете сказать, как именно ваши потенциальные клиенты сейчас удовлетворяют свое желание / любопытство, то решаемой проблемы у вашего продукта нет. Вы можете решать проблему быстрее, дешевле, качественнее и так далее, но вы не можете ее создать. Следовательно, еще перед разработкой мобильного приложения, вы должны точно понимать, от чего должны отказаться ваши потенциальные клиенты (старое, неэффективное решение той же проблемы), чтобы начать пользоваться вашим продуктом (новое, крутое решение).
Цитата великого человека о том, что фидбэк - завтрак чемпионов
Понимая решаемую проблему и преимущества вашего метода, вы должны написать несколько коротких статей / постов, рассказывающих о преимуществах вашего продукта от первого лица. Люди гораздо лучше воспринимают реальные истории от конкретных людей, чем обезличенный рекламный контент. Опишите в статье с какой проблемой вы столкнулись, как придумали решение, как его делали, что из этого получилось. Попросите у людей помощи в развитии продукта – уж на что, а на комментарии никто не скупится.
В каждую из статей нужно добавить уникальные ссылки на загрузку приложения, добавив в ее конец отслеживающий тег, чтобы впоследствии вы смогли анализировать особенности поведения каждой привлеченной когорты пользователей.
В мобильном же приложении необходимо реализовать дружественный раздел с обратной связью, в котором можно будет удобно выразить свое мнение (записать отзыв голосом, указать проблемное место на скриншоте и так далее), при этом он не должен быть навязчивым.
Пример дружественного раздела с обратной связью в мобильного приложения
Основная цель – преподнести продукт, как открытую и качественную попытку решения проблемы. Каждое сообщение должно начинаться с описания вашего собственного негативного опыта удовлетворения целевой потребности предыдущими способами. Это неудобно, плохо, дорого. Каждый должен перенести эту проблему на себя, подумав “черт возьми, а ведь действительно – доколе?”. Затем нужно рассказать, как вы решали проблему и к каким результатам пришли, попросив людей дать отзыв об этом решении. Вовлечь людей в тестирование продукта, наладив обратную связь – ключевой момент в запуске.
Анализ обратной связи
Кому-то всегда будет чего-то не хватать, и всегда найдутся люди, предлагающие противоположное. Все мы разные с разными взглядами на все, и это нормально. Важно убрать эмоции, забегание мысли вперед, советы от капитана и понять самое главное – люди считают это решением целевой проблемы или нет? Хоть кто-то стал этим пользоваться? Если нет, почему?
Если решение востребовано – его всегда можно улучшить, доработав. Когда же им не пользуются, то проблему новым сервисом вы не решаете.
Экономика, метрика
Как только вы поняли, что проблема пусть и не идеально, но все-таки решается, нужно скорректировать изначально просчитанную финансовую модель с учетом реального поведения клиентов. Как часто они пользуются продуктом? Готовы ли они платить, как было предположено изначально, и сколько?
Для отслеживания ключевых показателей на этапе разработки мобильного приложения необходимо интегрировать статистические сервисы: АппМетрика от Яндекса, Google Analytics и другие. Достаточно 1–2 инструментов, позволяющих просматривать информацию в целом и по отдельным когортам.
Отслеживание ключевых показателей на этапе разработки приложения
Взяв показатели ARPU (средний доход на пользователя) и CPU (средняя стоимость привлечения одного клиента) несложно посчитать прибыльность сервиса. Как правило, она редко бывает положительной с самого начала. Пользователи только начинают к нему привыкать, нет костяка лояльных клиентов. Вопрос в том, удастся ли вывести продукт на прибыльность в заданное время.
По шагам
Таким образом, запуск разработанного мобильного приложения должен состоять из следующих шагов:
Подготовить список групп, каналов и блогов, где находятся ваши потенциальные пользователи.
Написать сообщения о проблеме, которую вы пытались решить, и о полученном результате.
Попросить помощи в развитии продукта через обратную связь.
Собрать и проанализировать фидбек, наладив его цикличность. Поощрять активных пользователей и дружить с ними.
Понять, решена ли проблема.
Если да, обновить экономическую модель на основе полученных статистических показателей.
В следующих статьях мы расскажем о том, что делать, если проблема не решена, как интерпретировать различные сочетания метрических показателей и другие аспекты запуска и дальнейшего роста продукта.
Сколько стоит мобильное приложение
В предыдущей статье о стоимости разработки мобильного приложения, мы приводили статистические данные о том, что одно и то же приложение можно разработать как за 500 тысяч рублей, так и за 15 миллионов. Скорость и качество работ при этом могут совершенно не отличаться.
Это не может не дезориентировать. И не может не запустить цепочку размышлений: если эта студия готова работать так дешево, может быть они делают некачественно или недооценивают объем работ? Если эта студия популярна, наверняка существенная часть ее предложения обеспечивается брендом, а не работами. Так зачем мне платить за бренд? У этих цена средняя, но нет никакой поддержки. Какой бюджет будет требоваться, чтобы поддерживать проект у другой студии? Не обойдется ли это дороже других предложений?
Чтобы правильно оценивать коммерческие предложения, нужно понимать факторы формирования стоимости.
Почему цена так разнится?
В основном из-за различного подхода к организации рабочего процесса. Представьте ситуацию: студия разрабатывает ваше мобильное приложение, в функционал которого входит оплата товаров картой. Разработчики доходят до этого места и (внезапно) становится понятно, что у них нет доступа к платежной системе. Чтобы он был, необходимо создать аккаунт, который сделать можете только вы, так как там необходимо указывать реквизиты вашей компании, данные счетов и так далее. Студия у вас их запрашивает и старается переключиться на другой момент.
Другим моментом оказывается привязка социальных сетей. Там ситуация поворачивается в то же русло. Чтобы привязать Facebook, необходимо создать страницу приложения в этой социальной сети, которая должна быть создана из-под того аккаунта, который впоследствии сможет управлять его публикацией. То есть нужен ваш аккаунт. Вы не знаете, как это сделать, и запрашиваете инструкцию, которую менеджер начинает готовить.
Программисты, так как им нечего делать, донимают менеджера дальнейшими задачами (с рьяностью, прямо пропорциональной их мотивации). Он же, в свою очередь, занят разъяснениями тонкостей заполнения данных о приложении вам. А там есть, что разъяснять. Круг замыкается, появляется дэдлок.
А теперь самое главное: не так сложно догадаться, кто за все это платит. Программист работает – платите вы. Пьет чай – тоже платите вы. Менеджер спорит с программистом – время их спора оплачиваете вы. Вы объясняете по телефону, как именно нужно сделать тот или иной момент. И за время, пока он вас слушает, тоже платите вы.
Так как вариантов экономических взаимоотношений в разработке мобильных приложений не так много, нужно понимать, за счет чего можно оптимизировать сам процесс.
Оптимизация
Во-первых, это организационный процесс внутри команды.
Именно правильная его архитектура позволяет избежать тех замкнутых кругов, которые были описаны выше. Правильно организованный рабочий процесс всегда простой, быстрый и гибкий. Хорошие результаты дает Scrum и его модификации. Все задачи должны записываться в бэклог, который вы совместно с менеджером должны еженедельно корректировать и приоритизировать. Вы и менеджер должны четко понимать, какие задачи будут закрыты в текущем спринте. Обычно это 1–2 недели. И в каком виде вы сможете увидеть продукт к концу спринта. Да, именно так: если вы не можете что-то потрогать и попробовать через 1–2 неделю разработки, значит процесс выстроен неверно. Производительность каждого спринта должна измеряться, должны анализироваться проблемы, которые мешали сделать этот процесс быстрее.
Одна и та же команда может сделать один и тот же проект за 1 или за 6 месяцев. Это не преувеличение, это горькая правда. Это одни и те же люди, с тем же уровнем профессионализма, одни и те же задачи, одно и то же понимание конечного результата, один и тот же продукт на выходе. Но в одном случае это 1 месяц и 1 млн рублей, в другом – 6 месяцев и 10 млн рублей. Причина в разности подходов. Во многих книгах по Scrum описываются десятки таких примеров.
Во-вторых, это технологии.
Программистам нужно постоянно совершенствоваться в своем мастерстве, с этим сложно поспорить. А теперь представьте ситуацию. Программист закончил текущий проект, появляется следующий (ваш), не слишком сложный и не слишком срочный. Вы не доплачиваете за сверхсрочность, работа идет в штатном режиме. Он думает: “ага, отличная возможность попробовать ту новую парадигму разработки, Flow Coordinators, о которой я недавно прочитал!”.
И он начинает применять эту чудесную технологию. Время разработки затянулось, что совершенно ожидаемо, так как проект был рассчитан исходя из чистой работы в темпе конкретного программиста, а он потратил существенное время на получение новых знаний. Каждое обновление этого проекта затягивается и стоит дороже, так как эту прекрасную технологию знает только этот программист в команде. Любая другая студия скажет вам, что проект хорошо бы переписать, так как в их компании нет носителя этих сокровенных знаний. В результате вы платите за обучение программиста и усложняете поддержку и развитие продукта в будущем. Стоимость конечного продукта возрастает в 2 раза. Почему? Потому что программист прочитал статью о новой технологии и решил ее внедрить.
Плохо ли это? Ну, знания, как говорится, свет (а за свет надо платить), что хорошо с академической точки зрения. Но продукт создается вами чтобы зарабатывать деньги. Деньги вы сможете заработать только если продукт востребован вашими клиентами. Влияют ли на мнение клиента выбранные технологии? Нет конечно, для них совершенно безразлично, на чем написано мобильное приложение. Если они получают через него скидку, или узнают дополнительную информацию, или развлекаются, то есть решают свою проблему, им не важно, как именно это происходит – главное, что это выгодно / хорошо / быстро / приятно / важно.
Выбор технологий с продуктовой точки зрения важен только в ключе скорости, стоимости и гибкости дальнейшей разработки и поддержки. Вы хотите приобрести за плату готовый качественный продукт в срок. Вы не хотите платить за обучение программиста, вдобавок получив запоздалый результат, который потом никто не хочет поддерживать.
Как сделать дешевле и быстрее?
Спросите у потенциального подрядчика не только, что он будет делать (набор услуг), но и как он это сделает. “Ишь чего, это их внутренняя кухня, мне не важно “как”, мне важно в срок, это их проблемы.” – если для вас не имеют значения сроки и стоимость (а в кровавом энтерпрайзе это нередко встречается), то вы, безусловно, правы. Но если вам нужен продукт (а значит скорость) и его стоимость (выгода) для конечного потребителя (которая состоит в том числе из цены разработки проекта подрядчиком для вас), то самое важное, о чем только можно спросить подрядчика, так это о его организационной структуре. Одна и та же команда может сделать один и тот же проект за 1 или 6 месяцев в зависимости именно от организационного процесса.
Поэтому перед началом работ задайте подрядчику подобные вопросы:
“Что будет делать программист, если у него не хватает данных для выполнения текущей задачи?”, “Если вы начали делать второй этап из четырех, а я прислал правки по первому, когда будет выделяться время для их реализации?”, “Как вы отслеживаете продуктивность специалистов?”, “Как часто вы проводите внутренние совещания и как долго они длятся?”.
Ответы на них сложат у вас представление об организации рабочего процесса. Вы сразу поймете, какие ответы правильные, а какие нет.
Мы часто уделяем внимание вопросу что, не обращая внимания на вопрос как, который практически всегда является ключевым не только в сфере разработки мобильных приложений, но и в других областях жизни. Например, кандидаты в президенты почти всегда говорят что они сделают. Это важно с точки зрения психологии и политики. Однако, почти всегда неинформативно с точки зрения взвешенного выбора, так как потребности общества очевидны. Увеличение зарплат; снижение цен, инфляции, ставки рефинансирования; развитие технологий, безопасности; повышение качества социальных услуг и так далее. Не так много сторонников будет у того, кто пойдет на выборы с противоположными тезисами.
Важно как они это планируют сделать. Если вы боретесь с коррупцией и, следовательно, предполагаете, что она разрослась до больших масштабов, что вы будете делать со специалистами высокого класса, погрязшими во взятках? Если вы уволите всех людей с ключевых должностей разом, откуда вы возьмете сразу столько высококачественных специалистов? Когда вы их все-таки найдете, каков риск того, что за то время, пока они будут осваиваться на новых местах и срабатываться в команду, не будет утерян контроль над управлением важными сферами? Если вы будете увольнять коррупционеров постепенно, не создаст ли это двойных стандартов? На основе чего вы будете принимать решения и в каком порядке их менять? кто сможет повлиять на эти решения и как?
Вопросы как будет выполняться работа и как будет строиться сотрудничество – ключевые в понимании ценообразования разработки приложения.
Спросите о том, на каких технологиях будет разрабатываться продукт.
Уточните у других подрядчиков, насколько по их мнению эти технологии распространены. Если мобильное приложение будет разработано на этих технологиях, смогут ли они его доработать? На каких технологиях оно должно быть разработано, чтобы доработки могли быть сделаны быстрее и дешевле?
Разработать мобильное приложение быстрее и дешевле можно убедившись в эффективном организационном процессе, правильно выбранных технологиях и должном уровне профессионализма всей команды разработчиков.
Как сделать дороже и дольше?
Как и во многих сферах жизни при совершении сделки – ни о чем не спрашивать. Обычно это и приводит к такому результату. Бренд студии разработки мобильных приложений, количество сделанных проектов, именитые клиенты – все это, безусловно, косвенно говорит о востребованности услуг конкретного подрядчика. Но если вы не понимаете, как именно они работают, какую организационную структуру используют, насколько они гибки в случае изменения планов (а планы меняются всегда), то в сотрудничестве вы принимаете на себя ряд рисков, за которые будете платить.
