О чем статья?
Сегодня я попытаюсь раскрыть тему, как разработать успешное мобильное приложение на платформе 1С. Это будет интересно и разработчикам, и ИТ-руководителям, и тем, кто хочет инвестировать в мобильную разработку. Я раскрою нюансы и особенности, возможные сложности в этой теме.
Почему стоит прислушаться?
Расскажу немного о том, почему можно прислушаться к нашему опыту. Мы разрабатываем мобильные приложения с 2013 года. Начинали еще на одной из первых бета версий мобильной платформы. Тогда она была слишком сырая, и на ней ничего нельзя было опубликовать. На текущий момент наши тиражные решения установили более 1,5 миллиона человек, из них более 10 000 человек поставили нам оценку и отзыв. Общая средняя оценка составляет 4,5 балла. Это очень хороший показатель.
Также наши приложения попадали в топ-10 в App Store и Google Play в 88 странах. Кроме этого нас несколько раз выбирали в подборки приложений от App Store.
Мы вообще занимаемся тиражной разработкой и иногда делаем разработку под заказ. Но сегодня речь пойдет про тиражную.
Наши приложения
На текущий момент у нас три флагманских решения. Первое – Boss. Это решение для управления малого бизнеса. Его скачали больше 400 тысяч человек, средняя оценка – 4,5 балла. Всего у нас 3 тысячи оценок на это приложение.
Посмотрим на динамику скачиваний: в месяц сейчас 25 тысяч установок. Мы его перевели на 20 языков. Вообще к переводам мы относимся серьезно и сразу, когда разрабатывали, мыслили глобально на весь мир.
Посмотрим, как у нас делятся установки по языкам.
Первое место занимает португальский язык, русский – второе. Но доли примерно равны. Заметно меньшие доли у испанского, турецкого, английского и вьетнамского рынка. Есть и другие языки, но у них заметно меньшие доли, поэтому я их не стал выводить.
Так выглядит динамика платных пользователей наших. Эта кривая вверх за последние 1,5 года мне очень нравится, надеюсь, так и будет продолжаться.
Следующее наше приложение – Fitness. Это приложение не про бизнес, это для обычных людей, для тех, кто ходит в спортзал поддерживать свою форму или профессионально занимается спортом. На текущий момент по установкам это самое популярное приложение, разработанное на платформе 1С: его установили уже больше 800 тысяч человек. И у него также самая высокая оценка – 4,7 балла в App Store и 4,6 балла в Google Play. Всего оценок 6000. В среднем его качают сейчас чуть больше 50 тысяч человек, приложение переведено на 20 языков.
Посмотрим, как выглядят установки в разрезе стран.
На слайде можно увидеть, что Россия занимает второе место, а первое место – Бразилия. Третье место у Италии, затем США. У них доли сопоставимы, у других стран доли намного меньше.
Еще одно наше приложение – Budget – приложение для учета личных финансов. Это наше самое первое приложение, которое мы сделали. На текущий момент его установили 250 тысяч человек, у него 4,6 баллов в App Store и 4, 3 балла в Google Play. Всего 2 тысячи оценок, и качают его сейчас в среднем где-то 10 тысяч человек в месяц. Также переведено на 20 языков.
Кто такой мобильный разработчик 1С?
Существует мнение, что если мы умеем программировать на настольной платформе, то мы автоматически умеем программировать на мобильной платформе. Я бы, наверное, не согласился с этим мнением. Если мы говорим о коммерческой тиражной разработке, либо о разработке под заказ, где от 50 пользователей, то там это совершенно не работает. И просто так «настольный» программист не вольется, он не сможет сделать сходу нормальное приложение. На то есть ряд объективных причин. Некоторые из них выведены на слайде. Но это далеко не все.
Вообще, чтобы погружаться в мобильную разработку, нужно развивать несколько другие компетенции.
Первое – у мобильного приложения слабое железо. И у нас, как у разработчиков, нет права на неоптимизированный код. Мы не можем писать не оптимизировано, потому что если мы так сделаем, слабое железо будет работать настолько медленно, что этим невозможно будет пользоваться.
Второе – маленькие экраны. Это я бы выделил в отдельную компетенцию, которой нужно учиться, которую нужно развивать, – умение писать интерфейсы для маленьких экранов. Это очень нетривиальная задача, когда нужно сделать удобный и понятный интерфейс на таких экранах.
Третья особенность – много интеграций. Как правило, мобильное приложение – зеркало какой-то уже существующей системы. А во многих организациях есть «зоопарк» систем, они хотят видеть в одном приложении главные показатели. Поэтому там может быть много интеграций. В последнем нашем проекте, например, было 5 интеграций с разными системами.
Четвертая особенность – специализированные функции. Я здесь имею в виду не только такие функции, как геопозиционирование либо sms, либо звонки. Это довольно простые функции, и им не нужно учиться, с ними можно быстро разобраться. Я имею в виду еще и функции других приложений. Очень часто в реальной жизни нужно использовать функции других приложений, и это очень нетривиальная задача, которая решается с помощью внешних компонент. Один из примеров – это авторизация. Сейчас практически все приложения делают авторизацию – Google, Facebook.
Следующая особенность – это анализ поведения пользователей. В настольной разработке это не очень актуальная тема, но в мобильной, если мы делаем коммерческое тиражное решение, это практически обязательная вещь. Мы должны анализировать, как нашим приложением пользуются, понимают ли клиенты приложение, может быть, неправильно учет ведут, может быть, какими-то функциями не пользуются, какие проблемы они испытывают при использовании. Если мы это все не анализируем, то у нас шансов на успех очень мало. Практически все успешные мобильные приложения этим занимаются, значительная часть из них на это тратит больше ресурсов, чем на разработку самих приложений.
Путь создания мобильного приложения: от идеи до продвижения
Шаг 1. Найти идею. Как найти хорошую идею?
Первое: мы придумываем, креативим, фантазируем.
Второй совет – обязательно смотрите, что есть на рынке, что есть в App Store, Google Play, на других ресурсах. Но не ограничивайте себя в пределах России. Смотрите самый конкурентный рынок – Америку, смотрите другие рынки. Один из лайфхаков – смотрите Appannie.com, он публикует тренды – те приложения, которые набирают сейчас популярность, которые только-только появились.
Недавно я нашел очень прикольное приложение. Например, мы собираемся с друзьями в кафе. И мы решили, что не будем трогать телефоны, чтобы общаться. Это актуальная тема сейчас. И кто-то разработал приложение, которое контролирует, чтобы никто не пользовался телефоном. Если кто-то возьмет телефон, посмотрит в него, что-то начнет делать, то он будет платить за счет. Круто же?!
В общем, когда мы смотрим, мы можем очень много интересных идей найти.
Третье – улучшаем. Все мы пользуемся какими-то уже популярными сервисами, всем нам что-то не нравится в них, что-то неудобно или непонятно. Мы можем сделать подобное приложение и в нем решить эту проблему, что дает нам конкурентное преимущество. Здесь есть много плюсов. Например, сформирована пользовательская база.
Шаг 2. Когда мы выбрали идею, нам нужно ее проверить, экономически проверить. Вдруг мы фигню какую-то придумали, и это никогда нам денег не принесет. Как проверить?
Один из первых пунктов – проверяем конкурентов. Смотрим прямых. Если нет прямых, смотрим косвенных. Есть пару ресурсов, которые нам в этом помогут, – Appannie.com и Sensortower.com.
Они помогут выявить конкурентов, покажут, сколько скачивают у конкурентов, и какая у них выручка. Appannie.com покажет вам это с абсолютной точностью, но это платный ресурс. А Sensortower.com вам покажет приблизительные цифры, но это ресурс бесплатный.
Шаг 3. Нам нужно посчитать потенциальную выручку, чтобы проверить экономическую целесообразность идеи. Для этого нам нужно узнать количество пользователей и эффективную цену. Что мы делаем, чтобы это выяснить? Мы опираемся на факты, которые знаем, которые нам известны. А где нет фактов, мы опираемся на гипотезы. Гипотезы старайтесь делать максимально правдоподобными.
Чтобы фактов было больше, чем гипотез, проводите такие вещи, как опросы. Они вам помогут узнать больше об этой среде. Чтобы выявить эффективную цену, делайте эксперименты, собирайте фокус-группы из ваших потенциальных пользователей и узнавайте больше о этой среде. Это вам поможет рассчитать выручку правильно.
Также не забывайте, что есть много публичных исследований. Очень много аналитических компаний делают исследования, публикуют их, и это может здорово помочь.
Шаг 4. Когда мы определились с идеей и сделали экономическую проверку, подумаем о разработке, о ее стоимости. По нашему опыту, чтобы сделать качественно только первый релиз, обращаю внимание, что это у нас, уходит примерно год разработчика, три месяца дизайнера и три месяца проектировщика. Это немало, это хороший срок. И это только первый релиз. Если мы сравним функционал из проецируемого на настольную разработку и на мобильную, то на мобильной он будет, как правило, сложнее и дороже.
Шаг 5. Когда мы выбрали идею, знаем стоимость разработки, нужно сделать техническую проверку. Мы уже знаем, какие функции несет наше приложение, и нужно проверить, возможно ли их вообще сделать на платформе 1С. Если возможно, то проверяем достаточным ли будет уровень удобства, конкурентный ли этот уровень удобства приложения, сможем ли мы сделать конкурентный уровень интерфейсов.
Шаг 6. Если все хорошо, мы можем переходить к следующему этапу – проектированию. Для всего, что касается разработки, начиная с проектирования, сопровождения проектирования и даже для дизайна, у нас есть один важный принцип – делать понятно и удобно. Только соблюдая этот принцип, можно сделать действительно качественное полезное приложение для пользователей. Не нужно делать так, как изображено на слайде.
Я думаю, тот, кто сделал это, он, наверное, сам не разберется.
Приведу несколько примеров плохого и хорошего проектирования. На слайде изображена кабина пилотов в Boeing 747.
Если мы посмотрим на панель справа, то там примерно 500 приборов. Они довольно монотонно расположены, и человеку, даже если он знает, как они работают, будет сложно управлять ими. Это пример плохого проектирования.
А теперь посмотрите на кабину самолета Boeing 787.
Здесь система стала гораздо сложнее, на порядок минимум. Но посмотрите, как выглядит панель приборов у пилотов. Она намного меньше, там только нужные элементы, она очень хорошо сгруппирована, интуитивно все вещи понятны, они расположены в правильных местах. В общем, это здорово.
Посмотрим примеры ближе к нашей среде.
Мне кажется, чтобы разобраться с этой программой, мне нужно получать какое-то дополнительное образование. Я не знаю, как с этим работать.
А вот пример хорошего проектирования.
В принципе элементов не так уж и мало, но мне сразу понятны все разделы, я сразу понимаю, какая информация выводится, как мне менять эту информацию, как фильтровать ее.
Теперь давайте ближе к нашей теме – про интерфейс 1С. Что можно на 1С сделать с точки зрения проектирования? Когда мы проектируем систему и когда вообще начинаем разрабатывать, мы сталкиваемся с необходимостью адаптации всех форм. Мы не можем взять форму в таком виде, как она генерируется платформой. Также мы сталкиваемся с тем, что нам нужно менять очень много бизнес процессов форм.
Покажу на примерах, чтобы было наглядно.
Слева – экран телефона. Обратите внимание на нижнюю панель. Это панель разделов. Она присутствует практически в каждом приложении, это очень привычная вещь в нативных приложениях. Но платформа не умеет ее рисовать, и справа показано, как это можно сделать на 1С.
На этом слайде обратите внимание на верхнюю панель. Это панель действий, тоже довольно привычная вещь в нативных приложениях. Она открывает какие-то документы, может быть, фильтр или отчеты. Это тоже можно на 1С сделать настройками.
Это форма списка. Если мы оставим форму списка такой, какой ее генерирует платформа, то это будет сливающийся текст, без разрывов, и будет очень сложно его читать. Как ее можно настроить, сделать более читаемой, более понятной и более удобной? Мы добавили группировки, добавили иконки, выделили более важные элементы, какие-то сделали практически невидимыми. И тогда это довольно понятно читается.
Здесь пример той ситуации, когда мы выходим за рамки 1С. Мы написали эти формы на html, потому что у нас была задача – сделать красивые формы с красивым фоном, красивыми картинками (два левых скриншота). На 1С сделать это нельзя, зато все можно встроить. Поэтому мы используем и другие технологии.
Справа на слайде скриншот тоже на html. Это тот случай, когда нужно вывести много информации, и очень важно то, как информация расположена, чтобы ее можно было усвоить и понятно прочитать. Там очень тонкая настройка, поэтому мы это сделали на html.
Еще примеры.
Слева пример стандартного решения. Это индикаторы, это пишется самой платформой.
Посредине – это уже не изменение формы, это измененный бизнес процесс. Мы выбираем новую валюту или какой-то элемент из маленького списка, и мы этот список прямо в этой же форме показываем. Это удобнее и понятнее.
Справа – форма подбора, тоже более упрощенная, но получается измененный бизнес процесс. Открывается форма подбора, и мы просто кликаем на нужные нам элементы и накидываем это все в корзину. Это тоже довольно привычная вещь в нативных приложениях, но стандартно не сделано.
Для многих примеров, которые я сейчас показал, можно скачать исходный код на Инфостарте по этому QR-коду.
Расскажу про ошибки, которые мы часто встречаем в своей практике. Пожалуйста, не делайте так!
Первая из ошибок – это сложная реализация функций. Бывают, действительно, сложные функции, и разработчик все параметры этой функции скидывает в какую-то форму. Когда пользователь это видит, он входит в ступор, он не знает, с чего начать, что смотреть, что важно, что неважно. Часто когда мы меняем такие вещи, мы видим, что большинство параметров можно все-таки предзаполнить и не заставлять пользователя заполнять это самостоятельно. Потом это можно сгруппировать по разным характеристикам, можно выделить какие-то вещи, а можно провести пользователя за руку, чтобы для него всё было логично. Это намного упрощает работу.
Вторая вещь, с которой мы часто сталкиваемся, – это уведомления без предложений. Что это такое? Например, мы выводим документ продажи, и нам система выдает ошибку «у вас нет остатка этого товара», и на этом все заканчивается. Это пример плохого проектирования, так не нужно делать. Потому что в большинстве случаев мы знаем, в чем причина этой проблемы. Так почему бы не предложить решение прямо здесь, это же удобно? Пользователю не надо выходить, смотреть какие-то отчёты, какие-то документы. Мы можем сказать ему, что у него этого нет, и сразу предложить сделать приход, прямо здесь, одним кликом, и сразу же этот расход провести. Или предложить инвентаризацию сделать, еще какие-то варианты. Но в любом из этих вариантов разработчик системы, как правило, в курсе, в чем проблема.
Еще ошибка – много функционала. Есть такое мнение, что если мы много функций в приложение запихнем, значит, наше приложение классное. Но практика показывает, что приложение всего с одной функцией становится намного популярнее, его все используют. Поэтому рекомендация – пишите самые основные функции приложения.
1С – терминология – это та проблема, с которой мы тоже все время сталкиваемся. Нашим обычным пользователям 1С-терминология не понятна. Например, одна из самых распространенных команд «провести». Пользователь думает, что это такое, куда провести, зачем провести. Потому что обычные пользователи не связаны с 1С, они вообще не понимают его. И таких примеров много. Даже такие простые понятия, как «справочник» и «документы», не понятны обычным пользователям, хотя казалось бы, что это понятные вещи. Но люди думают, какие документы, может, вы паспорт хотите….
Пятая ошибка – отказ от ответственности. Я бы хотел на этот пункт обратить особое внимание, потому что он очень важен с точки зрения разработки – это изменение мышления. Приведу пример про программиста Вовочку и пользователя Петечку. Программист сделал какую-то классную функцию, он собой доволен, он думает, что все очень здорово, он так видит, и он это выкатывает в production. Пользователь Петечка видит, что вышла какая-то новая функция, он сразу же бежит разбираться с этим, вводит данные, но вдруг приложение выдает ошибку. Он думает, что это такое, опять эти программисты сделали какую-то фигню, опять баги выпускают. Пользователь пишет в поддержку, что ввел все данные правильно, но выпадают какие-то ошибки. Программист Вовочка смотрит на это и думает, блин, опять то же самое. Он пишет Петечке, что эта программа придумана не так, учет здесь вообще по-другому устроен, и вам нужно было сделать вот так и так. А про себя программист Вовочка думает, какие эти пользователи криворукие. Но, строго говоря, не бывает криворуких пользователей, бывает плохо спроектированная система. И я бы хотел заложить вам мысль, что если вдруг ваши пользователи регулярно сталкиваются с какими-то проблемами, это не их беда, это не они криворукие, это значит, что настало время что-то изменить, конкретную функцию, чтобы она стала понятной. Это очень важная мысль.
Шестая ошибка относится не к разработке, а скорее к оценке, к продажной части проекта. Многие исполнители, когда берут в работу мобильное приложение, оценивают его по настольной версии. Но это неправильно (я уже на предыдущих слайдах привел несколько причин, почему это не так). И они думают, что, наверное, сделали бы это за пару месяцев на настольной. Но поскольку это мобильное приложение, наверное, можно еще быстрее сделать. Но это в корне неправильно. На самом деле мобильное приложение делается дольше. И оно дороже – в среднем на 50 процентов дороже.
У мобильной разработки есть особые функции. Первая – синхронизация. Я бы хотел заострить на ней тоже ваше внимание, потому что к синхронизации мобильной предъявляют другие требования, более высокие, чем к настольной. Обычно когда мы разрабатываем мобильное приложение, наши заказчики хотят онлайн-синхронизацию. Им не интересна причина, что у них разные версии, поэтому они не синхронизируются. Они хотят синхронизировать всегда, и неважно, какая версия. Кто-то обновился, кто-то не обновился, а должно работать всегда. Не должно быть никаких дополнительных настроек. Кроме того, не должно быть для каждой синхронизации разворачивания отдельного сервера. И конечно, синхронизация должна быть высоко оптимизированная, потому что устройство слабое. Когда мы смотрим перенос синхронизации с настольной в мобильную, мы постоянно сталкиваемся с проблемой, что в настольной все работает хорошо, а на мобильной – синхронизируется настолько долго, что ждать невозможно и невозможно пользоваться. Поэтому нам приходится переписывать синхронизацию и часто архитектурно менять многие вещи.
Шаг 7. Мы уже определились с идеей, сделали все проверки, спроектировали наше приложение. Теперь пора переходить к продвижению. Я бы хотел поделиться опытом, чтобы предостеречь, чтобы вы не бежали делать рекламу. Потому что в подавляющем большинстве расходы на рекламу не окупаются. Лучше сфокусируйте свое внимание на поисковом продвижении. Это не требует денежных расходов, но может быть очень хорошая отдача в продвижении.
Что здесь необходимо делать? Речь идет про ключевые слова в маркетах. Каждый раз, когда мы выпускаем новые обновления, мы должны менять ключевые слова. То есть перед каждым обновлением проверяйте ваши ключевые слова, какие позиции занимают те или иные поисковые фразы. Если мы видим, что мы в поиске находимся очень далеко, и никто не находит приложение, значит, нужно эти слова заменить на какие-то другие, чтобы все ключевые слова работали хоть как-то. Также не забывайте, что со временем ваше приложение меняет свою популярность, и вам нужно также менять свои ключевые слова: менее популярные слова менять на более популярные. Тогда у вас будет больше трафика.
Обязательно смотрите ключевые слова конкурентов, потому что вы можете просто что-то упустить важное. Посмотреть слова конкурентов вы можете на сервисах по ссылкам на слайде.
Когда вы добавляете новые ключевые слова, обязательно анализируйте уровень их конкуренции. Потому что вы можете слишком конкурентные слова добавить, и вы будете в конце списка, и вас опять-таки никто не найдет. А могут быть вообще не конкурентные слова, и тогда вы хоть и будете первыми в списке, но вас никто качать не будет. Потому что никто не ищет по этому слову.
Шаг 8. Немножко про монетизацию. Я здесь буду говорить только о самом популярном виде монетизации – когда мобильное приложение бесплатное, и мы продаем подписки за какой-то платный функционал.
Здесь очень важно разделить функционал между бесплатным и платным. Бесплатный функционал отвечает за удержание пользователя. Поэтому он должен быть достаточным, чтобы пользователь получал какие-то полезные вещи с вашего приложения и постоянно возвращался. Платный функционал должен убеждать в покупке. Если мы, например, дадим слишком много бесплатного функционала, пользоваться будут, но никто не захочет покупать. А если мы дадим мало бесплатного функционала, то даже пользоваться не будут.
На этом моя основная часть доклада закончена. Спасибо.
Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2018 EDUCATION.
