Один из самых заметных трендов рунета — стремительный рост мобильной аудитории. По данным на конец 2013 года, каждый четвертый хит сети совершается из мобильного браузера. Ежемесячная мобильная аудитория рунета составляет уже свыше 130 миллионов человек, а ежедневно в сеть со смартфонов и планшетов выходят 20-25 миллионов пользователей.
В связи с этим множество e-commerce-компаний и подразделений задумываются над тем, нужно ли сражаться за мобильную аудиторию. Ответ «да» порождает целый вал вопросов. Какие проблемы предстоит решить перед созданием своего первого приложения? Какие риски учесть? Как появление приложения повлияет на бизнес компании и на отдел разработки? К чему готовиться и как жить дальше?
С появлением мобильных устройств в IT-бизнесе возникла необходимость находить новые подходы к проектированию и разработке. Чем это обусловлено?
Различия в потребностях аудитории. Во-первых, аудитории мобильной версии сервиса и веб-версии могут сильно различаться. Во-вторых, мобильной аудитории не нужны все функции основной версии. Например, мы исследовали, чем пользуются пользователи «больших» Денег Mail.Ru и платежного приложения. Как выяснилось, с мобильного чаще всего платят за сотовую связь, за интернет, социальные сети, делают покупки в нескольких магазинах — и все. Целый ряд функций основной версии на телефоне не востребован.
Портативность. Еще одна особенность заключается в том, что телефон находится при нас гораздо больше времени, чем компьютер. Отсюда новые возможности, которые можно реализовать в мобильных приложениях.
Изменение ориентации экрана. При разработке мобильного приложения или мобильной версии сайта необходимо учитывать, что во время сессии ориентация экрана может быть как горизонтальной, так и вертикальной.
Тачскрин. Поменялись способы взаимодействия – для управления тачскрин-устройствами вместо мышки используют пальцы. Причем кто-то использует один палец, а кто-то — несколько.
Частые прерывания. Необходимо помнить, что сессия на мобильном устройстве в любой момент может быть прервана. Пропадает связь в лифте, подходят ребята на улице и просят «мобилу позвонить», села батарейка, уткнувшийся в смартфон человек натыкается на столб или спотыкается о клумбу. Это прерывания внешние, а есть еще и внутренние — внезапный звонок или SMS.
Необходимость изобретать велосипед. В некоторых случаях при разработке мобильных приложений приходится придумывать совершенно новые подходы к привычным вещам. Хороший пример – решение для удобного и быстрого ввода пароля в мобильном приложении. В силу специфики работы мне иногда приходится просыпаться по ночам и выходить в сеть, чтобы посмотреть, что происходит на рабочих серверах. Так вот, пароль на клавиатуре компьютера я наберу за секунду с закрытыми глазами даже в три часа ночи, а на мобильном телефоне порой требуется несколько минут, чтобы ввести пароль в почте или в платежной системе.
Делаем выбор между веб-версией и мобильным приложением
Все мы стремимся зарабатывать больше денег. Как? С помощью расширения аудитории, которое возможно в двух направлениях. Во-первых, это привлечение новой аудитории. Во-вторых, это повышение вовлеченности имеющейся аудитории, что представляется мне гораздо более важным и перспективным делом. Необходимо добиться, чтобы ваши пользователи увеличивали средний чек, чаще открывали приложение или заходили на сайт и проводили там больше времени. Именно для того, чтобы удерживать и вовлекать в процесс старую аудиторию, компании и создают новые сервисы, в том числе и для мобильных устройств.
Есть два способа дотянуться до смартфона пользователя: это мобильная версия сайта и мобильное приложение. Рассмотрим плюсы и минусы обоих вариантов.
Мобильная версия. Одна из сложностей пользования мобильной версией сайта состоит в том, что пользователю нужно как-то запоминать URL вашего сайта. В веб-браузере это просто, но не каждый пользователь мобильных Opera или Firefox догадается, как это можно сделать.
Во-вторых, разработчик должен понимать, с какого именно мобильного устройства пользователь приходит на сайт, и учитывать тонкости его работы.
В-третьих, скорость загрузки у мобильной версии существенно ниже, чем у приложения. Кроме того, может возникнуть проблема с навигацией в интерфейсе. Не всегда пользователю мобильной версии ясно, сработала ли кнопка, сможет ли он пройти по данной ссылке и т.д.
Из преимуществ можно отметить относительную несложность разработки. Для того чтобы сделать мобильную версию сайта, не нужно привлекать новых специалистов. Как правило, это можно делать силами собственной команды с использованием привычных инструментов, тех же самых IDE, которые используются для разработки основного сайта.
Существенный плюс, что при этом разработчики не зависят от требований сторонних организаций: Google Play, Apple App Store и иже с ними. Не надо заполнять кучу форм при выходе очередного релиза и ждать, пока продукт проверят модераторы. Не нужно судорожно вчитываться в лицензионные соглашения, боясь, как бы вас ненароком не выкинули из магазина приложений.
Приложение. Минусы мобильных приложений можно разделить на две группы: внешние и внутренние.
Один из внешних минусов — молодость отрасли, история которой насчитывает не более 5-7 лет. Как следствие, нет достаточного объема информации, стабильных framework’ов, вокруг которых появились сложившиеся сообщества, где можно пообщаться и задать вопрос. Однажды пытался найти информацию в интернете и все, что удалось обнаружить – это диалог двух китайских программистов, которые обсуждают проблему на своем китайском форуме. Только по английским словам в их фразах можно было понять, о чем там, собственно, речь, и сложить паззл, пытаясь найти решение.
Также возникают сложности с поиском специалистов, что опять же связано с молодостью отрасли.
Внутренний минус — это зависимость от других сотрудников компании, не являющихся членами команды. Как показывает практика, мобильному подразделению не всегда доступны все ресурсы: верстальщики, дизайнеры, маркетологи и прочие.
Тем не менее, есть и плюсы, и они очень весомые. Во-первых, создавая мобильное приложение, мы оказываемся у клиента в кармане, то есть в мобильном устройстве, и рано или поздно он начнет использовать приложение.
Во-вторых, мобильное приложение может дать новый импульс развитию бизнеса в целом, принести новые идеи. Ведь мобильные устройства имеют множество возможностей: качественная камера, распознавание голоса, геолокация, push-уведомления. Можно также вспомнить про упрощенный способ обмена информацией, NFC и многое-многое другое, что можно использовать для развития вашего продукта.
В-третьих, будет расти эффективность компании — новое направление, которое подразумевает постоянное общение между отделами и перераспределение ресурсов, заставит находить и налаживать способы обмена информацией, вводить стандарты внутренних взаимодействий.
В-четвертых, повысится уровень профессионализма программистов, дизайнеров и менеджеров. Поскольку информации в сфере мобильной разработки немного, всем членам команды приходится заниматься самообразованием, получать новые знания.
Набираем команду
Итак, вы сделали выбор, пришло время набирать команду для разработки. Кто должен в нее входить?
Менеджер. Подозреваю, что вызову недовольство разработчиков, но главный человек в команде — это менеджер. Зачастую именно от него зависит, насколько успешным будет все мобильное направление в вашей компании — он занимается координацией действий отделов в компании, ищет ресурсы, следит за новинками отрасли и думает, как будет работать приложение.
Дизайнеры. Что касается дизайнеров, то их часть работы, как правило, выносится на аутсорс, и не только внутренний (то есть внутри компании), но и внешний. При этом можно столкнуться с тем, что дизайнер не имеет представления о мобильной разработке. К примеру, он может не понимать, что вот этот нарисованный им красивый градиент разряжает батарею на 10% быстрее. Взаимопонимание с дизайнером лежит на совести менеджера, который должен ясно донести до него задачу.
Разработчики. Число разработчиков должно быть пропорционально количеству выбранных вами платформ. При этом важно обеспечить непрерывные циклы разработки, не допуская, чтобы работа простаивала, когда человек уходит в отпуск, заболевает или уезжает на конференцию. Для этого вам придется продублировать некоторые сущности. Либо над платформой будет работать по два программиста, либо с двумя платформами будут работать три программиста, один из которых ориентируется в обеих платформах.
Ну и, конечно, не забудем про тестировщиков.
Вписываем мобильное направление в структуру компании
Вы сформировали команду и приступаете к работе. Какое место займет она в структуре компании? Все будет зависеть от размера организации.
Если компания маленькая, то команда работает на всю организацию, занимаясь всеми ее продуктами. Как правило, и сервисов у такой компании не очень много, поэтому, скорее всего, команда будет работать над одним-двумя приложениями.
Если компания большая, как Mail.Ru Group, где работает более трех тысяч человек, то у каждого департамента, скорее всего, будет собственная команда разработки мобильного направления. Каждая из них может идти собственным путем, расставлять приоритеты, поддерживать свой набор платформ.
Несколько моментов, помогающих повысить эффективность взаимодействия команд разработки в большой компании:
Делитесь опытом. Важно делиться опытом между подразделениями, поскольку, как я уже упоминал, информации в мобильной отрасли мало. Когда команды делают более-менее похожие продукты, у них будут возникать схожие вопросы. Создавайте базу данных о граблях, на которые вы наступили, и она обязательно поможет вашим коллегам сэкономить время.
Выделяйте общий код, которым могут пользоваться другие команды мобильной разработки. Опишите свои компоненты и стандартизируйте библиотеки.
Создавайте общие репозитории и общие build-серверы. Соответственно, не будет необходимости каждый раз покупать большое количество железа, поскольку вполне допустимо совмещение мощностей для разных команд.
Ведите общую статистику. Согласовывайте между собой хранилища данных. Общая статистика порой может привести к интересным выводам. К примеру, есть возможность сравнить, как одно приложение повлияло на рост аудитории другого.
Делитесь трафиком. Подумайте об интеграции, о том, как с помощью популярного приложения привлечь трафик в только что запущенное. Например, в Mail.Ru Group есть мессенджер Агент и есть мобильное платежное приложение. Мы задумались о том, что интеграция вызова оплаты услуг IP-телефонии в мессенджер может дать рост трафика в платежном приложении.
Позаботьтесь о типизации. В нашей компании есть хороший опыт придерживаться при создании приложений единого стиля. Пользователь при виде нового сервиса чувствует, что он ему знаком и близок, и, вероятно, будет охотнее пользоваться новинкой.
Считаем расходы
С запуском мобильного направления в бюджете компании появляются несколько новых статей расходов.
Мобильные устройства. К сожалению, на эмуляторах, установленных на компьютерах, работу приложения качественно не протестируешь. Придется покупать самые разные мобильные устройства, которых очень много на рынке; кроме того, они часто выходят и быстро устаревают. Один только зоопарк Android-устройств насчитывает около 2,5 тысяч. Кроме смартфонов, обязательно нужно будет купить несколько планшетов.
Программное обеспечение. Для разработки мобильных приложений необходимо свое программное обеспечение. Отмечу, что надо использовать любой шанс сэкономить — к примеру, можно найти довольно приличное бесплатное ПО либо купить облегченную версию вместо полной. Пример: приходит к вам разработчик и говорит: «Я хочу полноценный Photoshop», а он стоит космических денег. «А для чего?», — спрашиваете вы. – «А мне надо графику резать». Покупаете ему Photoshop Elements, и он доволен: все работает. А стоит гораздо дешевле.
Железо для разработчиков. Придется также приобрести серверы для сборок и тестирования, поскольку не все можно собирать в виртуальных средах. Особенно это касается iOS. Если разработчику необходимо держать на компьютере несколько виртуальных сред, то ему нужна мощная машина с увеличенным объемом памяти. Кроме того, не помешает большой монитор, поскольку с графикой программисты клиентских приложений работают достаточно много. В июне этого года мы подсчитали, на что тратят рабочее время наше разработчики, и выяснили, что 32% времени ушло у них на работу над визуальными интерфейсами — на ячейки, градиенты, кучу кнопочек, ползунков и прочую красоту.
Зарплата разработчиков. Не открою нового, если скажу, что с кадрами в мобильной разработке проблема — есть спрос на специалистов, который не удовлетворяется предложением. Крупные компании ищут профессионалов по всей России, готовы даже давать подъемные на обустройство в новом городе. Например, мобильных разработчиков в нашу команду мы подтягивали из Брянска, Екатеринбурга, Челябинска и других городов. Соответственно, повышенная зарплата разработчикам может стать солидной статьей расходов для компании.
Планируем (о чем еще стоит подумать менеджеру)
Планирование. Создание первой версии – процесс небыстрый. Как, впрочем, и второй. Дело в том, что разработчики набираются опыта, учатся, и через полгода, посмотрев на свой код, написанный вначале, они обязательно захотят его переписать. Поэтому менеджер должен заложить 20% рабочего времени на переделку, улучшение и ускорение продукта.
Привет дизайнерам! Дизайнеры могут стать злейшими врагами разработчика в мобильном направлении. Чтобы этого не случилось, до них обязательно нужно доносить, что стандартные компоненты порой работают лучше и быстрее и не тратят ресурсы батареи.
Что выбрать: скорость, качество или красоту? Сразу три пункта из трех выбрать не получится. Нельзя сделать дешевый продукт быстро и качественно. Менеджеру постоянно приходится выбирать, причем на разных этапах разработки приоритеты могут меняться.
Найти фишку. Необходимо найти элемент, который будет удерживать аудиторию в вашем приложении. К примеру, наша команда в свое время разработала приложение для Товаров Mail.Ru с гороскопом покупок. Это полушутливые предсказания о том, что именно покупать в тот или иной день. Мы сами были удивлены, но достаточно большое количество пользователей — 12-15% — каждый день открывают и читают этот гороскоп. Подобные фишки помогут привлекать аудиторию без особых затрат.
Продвижение. Занимаясь продвижением, обязательно нужно помнить о требованиях магазинов приложений. Важны даже самые незначительные требования. Помимо этого, необходимо не только внешнее, но и внутреннее промо продукта – сотрудники компании должны пользоваться приложением. Только в этом случае оно будет более эффективно развиваться. Также важно постоянно обновляться. Если этого не происходит, про сервис быстро забудут.
Серверная часть. Во-первых, обязательно помните, что ваш пользователь сидит на медленном интернете. В лучшем случае у него Wi-Fi, в худшем — GPRS. Во-вторых, обратите внимание на поддержку версий API. Подумайте о том, как вы будете обновлять версии. Заложите в вашем приложении возможность доносить до пользователя сообщение: «Приложение работает уже не очень хорошо, пора пойти обновиться». Как показывает наша практика, процесс миграции не мгновенный, пользователь может жить на старой версии приложения еще несколько месяцев после выхода новой.
Тестирование. На разных этапах жизни сервиса стоимость исправления багов будет различна. Самое выгодное — исправить ошибку на этапе проектирования. Ход мыслей должен быть такой: «А вот это может привести к багу, давайте сделаем по-другому». Если баг обнаруживается на production-стадии, может оказаться, что исправляя проблему, вы будете вынуждены полностью переписать приложение. Версии с критичными багами вообще выпускать противопоказано, иначе пользователь сразу посчитает ваше приложение никчемным, не станет ждать, пока вы исправитесь, и найдет другое.
Монетизируем
Практически все приложения можно монетизировать. Другой вопрос, что не всегда это будут деньги, которые можно пощупать. Существуют приложения с очевидной возможностью монетизации. Это:
- платные игры
- платные бизнес-приложения
- приложения с подпиской на контент
Есть и другие, неочевидные виды монетизации:
- платное размещение (баннеры и спонсорство)
- модель freemium (пользователя подсаживают на крючок, побуждая платить за дополнительные опции)
- pay-for-service (создание некоторых платных опций в бесплатном приложении, которыми пользуется определенная группа юзеров)
- white label (сдача в аренду приложений и API под брендом другой компании. Что касается аренды API, то иногда может дать хороший результат взаимодействие с оффлайновыми сервисами. К примеру, можно сотрудничать с компанией, которая занимается оформлением фотографий в виде бумажных открыток. Вы можете сделать для нее приложение, которое позволит отправить фотографию с конференции в виде открытки друзьям и коллегам.
Как пощупать результат, если приложение бесплатное
Важно понимать, как аудитория воспринимает ваше приложение, чтобы определиться с направлением дальнейшего развития сервиса. Если приложение бесплатное, простой учет количества скачиваний ваших приложений из AppStore ничего не даст. Для этого нужна более кропотливая работа.
Во-первых, выработайте точные цели, которых хотите достичь. Сформируйте лист требований, которые будете учитывать. Среди них может быть количество запусков, популярность разных функций — оценивайте, какое количество пользователей их использует, сравнивайте и делайте выводы.
Во-вторых, оценивайте конверсию.
В-третьих, научитесь собирать статистику использования — храните все данные. Даже если сегодня они кажутся ненужными, завтра они могут сильно пригодиться. Постоянно занимайтесь анализом, прогнозируйте, проверяйте и перепроверяйте свои выводы и прогнозы.
Максим Бабич
руководитель разработки мобильных платежных сервисов Mail.Ru Group
Автор: WebByte
