кейс разработка мобильного приложения
Кейс. Продвижение мобильного приложения. 3775 установок по 21 руб
Всем привет! С вами маркетолог Дмитрий Дарт и сегодня будет кейс по трафику с Facebook.
Исходные данные: мобильное приложение для создания Stories.
Выбор канала объяснять не стоит, самая целевая аудитория находится именно в этой сети. Заказчик высказал пожелание получать установки по 30 рублей.
Посмотрев приложение, я выделили 3 целевых аудитории по возрастанию их количества.
С SMM-специалистами проблем не возникло, в соцсети представлены подходящие интересы. С любителями Instagram всё оказалось немного сложнее. Интереса связанного с историями не было:
По Instagram был только общий интерес и аудитория про бумеранги:
Заказчиком были предоставлены базы:
Тем, кто уже установил приложение, рекламу показывать не следует. А вот с аудиторией на 160 тыс. человек возник вопрос. Непонятно было её качество, актуальность и свежесть данных. Поэтому обе этих аудитории были исключены из рекламы.
В качестве креативов заказчик подготовил 6 видео формата stories, впоследствии я добавил ещё несколько стандартных креативов для ленты.
Аудитория SMM хорошо себя показала, общий интерес дал намного меньше показов и установок приложения.
Т.к. в целом было понятно что модель работает, а установок нужно было больше, то было принято решение подключить ленту. Следующая неделя:
В ленте были задействованы две аналогичных группы интересов.
На следующей неделе у меня начало закрадываться подозрение что в кампании начинает выгорать интерес SMM и я ввёл общую аудиторию. Здесь видно что она не успела нормально открутиться и принесла всего 2 установки. Данные по неделе:
Проверив в конце недели частоту и CPM я понял что мои опасения были не беспочвенны. Данные за всё время работы кампании (с начала и до конца третьей недели):
По интересу SMM действительно была уже самая большая частота и самый высокий CPM. Заметьте, что по наиболее широкой аудитории был самый низкий CPM, при этом на старте наблюдалась самая дорогая конверсия (установка приложения).
Последняя неделя работы кампании:
На мой взгляд, здесь нет ничего интересного, видно что старые аудитории продолжили дорожать, широкая аудитория в Stories всё ещё не запустилась в полную силу.
В процессе работы кампании несколько раз повышался суточный бюджет + неоднократно менялись предельные ставки по разным группам объявлений.
В сумме удалось сделать 3775 установок приложения по 21,62 руб.
После этого разработчики приложения признали тест удачным и ушли допиливать его функционал, монетизацию, чтобы лучше подготовиться к следующей рекламной кампании.
1. Креативы решают. На широкую аудиторию не хватило именно качественных креативов. Мы не смогли подобрать к ней ключ, поэтому конверсии по ней получились наиболее дорогими.
2. Запланируйте выгорание аудитории. Рано или поздно это неизбежно произойдёт. Дайте ей отдохнуть, чередуя показ различным группам людей.
3. Не зацикливайтесь на одном формате. Исходя из специфики приложения кому-то может показаться нелогичным подключение ленты для рекламы приложения такого рода, но, как показала практика, этот подход может себя оправдать.
5. Рискуйте с умом. Не забывайте об электронном ошейнике для алгоритма, в данном случае это предельная цена.
6. Подберите оптимальный размер аудитории. На прошлой неделе у меня состоялся разговор с сотрудником поддержки ФБ. По его словам минимальная аудитория для локальных кампаний 10 тыс. человек, рекомендуемая 100 тыс. человек (для города). В этом случае кампания была федеральная, поэтому пришлось “немного” расширить их. Основные аудитории были численностью 3,2 и 9,7 млн человек.
7. Ищите нестандартные аудитории. Например в самом конце этой рекламной кампании были запущены креативы по аудитории девушек с интересом «мобильные приложения». К сожалению, она не успела открутиться в достаточной мере, чтобы сделать по ней статистически значимые выводы.
8. Тематика приложения играет роль. Чем шире тематика, тем более низкой цены можно добиться.
9. Внедрите с помощью SDK учёт оплат в приложении или, как минимум, показателей вовлечённости. В этом случае можно оптимизироваться не просто по установкам, а именно по этим показателям. Единственный недостаток, в этом случае для набора данных вам потребуется намного больше установок. Но конечно же, количество установок в этом кейсе совершенно незначительное по сравнению с компаниями, которые заливают трафик в промышленных объёмах. В этом случае банально не хватило бы данных для такой оптимизации.
Если у вас остались вопросы, то задайте их мне в ВК или телегу, актуальные контакты указаны тут.
Кейс разработка мобильного приложения
Дизайнеры Гюльнар и Эльшан Гурбановы рассказали, как попробовали себя в разработке, набили кучу шишек, но добились 5 000 скачиваний частично платного приложения за один месяц. Цена опыта в рублях, советы новичкам в разработке и взгляд на фриланс глазами заказчиков – в статье.
Гюльнар (@Gulnar) и Эльшан Гурбановы (@bowxwod) – графические дизайнеры, продавцы Профессионалы на Kwork.
Создали мобильное приложение для Android «Сказки детям».
Время на разработку: 1 месяц
5 000+ установок с 20 апреля
69 отзывов
4,7 – рейтинг приложения в Play Маркет
Идея и подготовка: первые грабли и инсайты
Вы – успешные дизайнеры на фрилансе. Откуда порыв к разработке?
Давно хотели попробовать себя в чем-то новом. Насчет приложения задумались еще после статьи в блоге Kwork – про перспективные рубрики в разработке. А когда из-за пандемии стало меньше заказов – поняли, что настало время браться за новые идеи.
Наш первый блин в этой теме – приложение Kittle animals – пазлы для детей от трех лет. Там мы использовали рекламу, как средство монетизации. И быстро поняли, что это факап – пазлов на рынке слишком много, игра оказалось никому не нужной.
Скриншоты из Kittle animals. Игра состоит из 26 пазлов животных, в соответствии с английским алфавитом (здесь и далее – комментарии героев)
Итог первого приложения: 41 установка, 30 000 рублей затрат и 50 центов прибыли. Огромная работа была проделана только ради опыта.
Но даже такой результат не заставил вас опустить руки?
Конечно, нет. Но заставил по-другому взглянуть на создание приложений. Мы решили попробовать еще раз – с бюджетом побольше и привлечением профессионалов с аутсорса. Теперь мы знали, что делать можно, а что нельзя.
Расскажите главные выводы из первого опыта.
Во-первых, реклама в приложениях для детей совершенно недопустима. Но отказ от рекламы вынудил нас искать другой способ монетизации. В итоге мы остановились на варианте частично платного приложения: часть контента бесплатно, часть – за символическую цену.
Во-вторых, не нужно лезть туда, где не сможешь сделать лучше существующих конкурентов. В случае с пазлами и другими играми – на рынке уже было много качественных предложений. Мы, новички, не могли их технически перепрыгнуть. Поэтому, решили искать свою силу в другом – в добрых идеях, волшебной атмосфере проекта, заботе о детях. Долго думали, что же сделать.
Что помогло определиться?
Решение подсказал наш ребенок – установил на смартфон сказки. Мы увидели это, и как-то сразу открылось видение всего будущего проекта. Было решено – делаем приложение со сказками для детей. Но не как у всех: сухой текст, озвучка со старых советских мультиков, выложенных в YouTube, реклама раз в две минуты. Мы захотели предложить родителям проект, которому они смогут доверять.
Перед второй попыткой мы установили около 200 аналогичных приложений в русскоязычном сегменте. Читали, слушали, покупали платный контент.
Самая первоначальная идея, сверстанная в Corel Draw, чтобы самим понять, что хотим. Здесь мы планировали делать серии из 10 сказок по пять в двух рядах. Но так как на мобильных устройствах обложки сказок станут нечитаемыми при таком расположении, решили добавить еще две сказки, и сделать по четыре в три ряда
Этот эскиз мы рассылали будущим иллюстраторам игр и программистам – показать идею
Подбор команды на фрилансе
Какие были сложности при поиске исполнителей?
Так как сфера для нас новая, было очень сложно оценивать предложения услуг. Мы ни на что не знали расценки. За одну и ту же работу фрилансеры предлагали цены от 2 000 до 75 000 рублей. В результате, мы просто доверились интуиции.
Где искали специалистов?
Искали везде, чтобы было с чем сравнивать. 80% людей нашли на Кворке, 15% добрали с FL, а иллюстратора пригласили с профильного сайта Illustrators.ru.
Цены на дизайн и иллюстрацию главной концепции варьировались от 6 000 до 70 000 рублей. Мы выбрали исполнителя за 6 000, и он превосходно справился.
Через три дня получили первый профессиональный эскиз
Наш ответ иллюстратору – где какие кнопочки рисовать; что и как будет работать
И вот уже полностью вырисовывается концепт и характер приложения. Получается просто изумительно красиво. В последующем были доработки и исправления, но основная идея осталась неизменной
Дизайн готов, что дальше?
Дальше нам нужен был программист, который «оживит» интерфейс. Главным исполнителем проекта выбрали Дмитрия Чайко (@dimachaiko6). Дима создал весь движок с нуля, запрограммировал, отрегулировал многочисленные настройки, сам тестировал и правил приложение. А еще очень помогал нам разобраться в теме – без него, мы бы застряли в дебрях незнакомых терминов, даже не начав как следует работу над приложением. Огромное ему за это спасибо.
«Оживший» интерфейс приложения
Пока Дмитрий работал над технической частью, мы подбирали сказки и искали иллюстраторов. Изначально хотели, чтобы весь проект вел один иллюстратор. Но, оказалось, художники работают медленно – 7-10 дней на картинку. В нашем приложении первоначально было 12 сказок; в каждой сказке – не меньше трех иллюстраций, то есть самый минимум на серию – 36 изображений. Ждать каждый рисунок по десять дней было невозможно. Поэтому приняли кардинальное решение, что каждую сказку будет выполнять отдельный художник. В итоге, с нами работало 8 иллюстраторов.
Иллюстрации к сказке «Лисица и журавль». Автор Ольга Мойсейкова (@olgaart)
Иллюстрации к сказке «Снегурушка и лиса». Автор Арина Гринберг (@arinagrinberg)
Иллюстрации к сказке «Мужик и медведь». Автор Александра Тунгусова (@zabavasunny)
Быстрее всех работала Александра Тунгусова. Поэтому позже мы полностью доверили ей рисование новой серии оригинальных сказок про мышку Полли. Там 36 иллюстраций, и за две недели были готовы уже 30. Просто потрясающий результат.
Часть иллюстраций к серии сказок про мышку Полли
Отбирая исполнителей, мы отдавали предпочтение тем, кто задавал грамотные вопросы, предлагал альтернативные варианты. Еще огромное преимущество давал быстрый ответ на сообщения, потому что мы хотели быстрее запустить проект. И главное – вежливость.
По сравнению с другими площадками, на Kwork самые вежливые и быстрые исполнители. На этапе отбора мы обратились здесь примерно к 200 исполнителям, и все нам ответили в течение двух часов. На других сайтах отвечали 4 из 10 фрилансеров. Также ни один продавец на Kwork не отказался выполнить заказ, не был против переоценки. Исполнители давали больше вариантов, предлагали правки, делились своим видением поставленной задачи. Это круто.
Дизайнер, программист, восемь иллюстраторов. Уже набирается серьезная команда.
И это не все. Еще у нас есть дикторы, авторы оригинальных сказок и загадок, копирайтер. Подобрать нужного специалиста для каждой задачи было непросто, кропотливо прописывали критерии отбора. Иллюстратора выбирали по портфолио, писателей просили прислать похожие работы. Дикторов выбирали по приятности голоса и цен на озвучку.
В итоге, для создания оригинальных сказок остановились на сотрудничестве с Маргаритой Щегловой (@sovyshka777). Она сразу вникла в суть проекта и очень быстро написала для нас 12 историй. Изумительные загадки написала Евгения Сазонова (@evaeva1). Также на старте идеально точно подобрали трех дикторов, и до сих пор работаем только с ними: Максим Палатов (@maxpal), Илья Веселов (@igraslovkmr) и Анастасия Исакова (@anastasiais).
Кому отдали верстку приложения?
Делали сами. Долго работали над стилистикой – как сверстать так, чтобы при прокрутке вниз не прерывался голос диктора, чтобы было меньше переносов, чтобы количество иллюстраций не было меньше текста, чтобы все шло синхронно… Также приходилось решать проблему с масштабированием, ведь экраны на разных смартфонах имеют разные размеры. В общем, пришлось попотеть.
Сказка «Каша из топора». Запись с экрана мобильного устройства
Продвижение приложения
Как считаете, за счет чего добились первых скачиваний и отзывов?
Первые отзывы мы получили от знакомых, близких и друзей. Также они совершили первые покупки для своих детей. На данный момент приложение находится в пассивной рекламной кампании Google. Плюс, приложение уже индексировалось и выходит в поиске Play Маркет по 200 ключевым словам.
Количество скачиваний и удалений приложения на 13 мая 2020 года
Сколько людей на данный момент купили платные функции в приложении?
С момента, когда ключевые слова нашего приложения вошли в Топ-20 запросов в Маркете – мы получаем по 3-4 покупки в день, из которых одна не совершается по разным причинам. До окупаемости еще далеко, но процесс идет. Отсутствие быстрого заработка нас совершенно не расстраивает, так как мы уверены в качестве своей работы. И мы сделали приложение с любовью к детям.
Статистика покупок в приложении
Создание контента: привлечь и удержать пользователей
Изначально вы запустили приложение только с русской народной серией. Почему позже решили добавить авторский контент?
Все просто: знаменитые сказки есть практически у всех приложений, а эксклюзивных нет почти нигде. Поэтому решили добавить серию уникальных коротких историй – каждая рассказывает один случай из жизни маленькой мышки Полли, которая живет с братиками, сестричками и мамой. Все сказки этой серии носят сугубо воспитательный характер. Вот список основных идей в сказках про мышку Полли:
Мы уверены, что наши сказки помогут родителям привить малышам правильные идеи с раннего детства.
Серия загадок задумана с этой же целью?
Не совсем. После запуска приложения мы наблюдали за поведением пользователей и за отзывами. Пришли к выводу, что в приложении три серьезных упущения:
Подумав, решили, что бесплатная серия загадок в стихах – самое то! Это решает все три проблемы разом. Во-первых, полезная игра для детей – развивает память, мышление и фантазию. Во-вторых, родитель будет видеть, что в приложении много бесплатного контента. В-третьих, 80 загадок удержат пользователей в приложении как минимум на несколько дней. И ко всему, загадки – это тоже литературный жанр, а значит они идеально подходят к нашему концепту.
Скриншоты с загадками
Все загадки поделены по тематическим категориям
Как работаете с авторскими правами?
С авторами мы договариваемся перед заказом. Объясняем сразу, для чего делаем приложение. Обещаем, что укажем их авторство. И сдерживаем обещание – имена всех, чей труд задействован на пользу деткам, опубликованы в разделе об авторах.
Какие планы на развитие приложения?
Планируем добавить серию восточных сказок: 4 японские сказки, 4 азербайджанские и 4 арабские. После этого хотим перевести приложение на наш родной язык – азербайджанский, и запустить его уже у себя в стране. Пока параллельно подбираем исполнителей для перевода и озвучки сказок. Как мы видим наш конечный продукт:
В результате у нас получится приложение, в котором есть место и тем, кто может заплатить, и тем, кто не может.
Итог в цифрах: этапы работы и цены
1. Создание скелета приложения
Дизайн + Программирование + Верстка и логотип (делали сами) – 30 500 рублей
2. Наполнение контентом
Подбор первой серии сказок + Иллюстрации + Дикторская озвучка – 22 500 рублей
3. Запуск и минимальный маркетинг
Регистрация разработчика + Тексты + Ролик + Реклама в приложении – 25 500 рублей
4. Развитие проекта
Создание раздела с загадками в стихах – 15 000
Создание серии сказок про мышку Полли – 42 500
Потратили всего: 136 000 рублей + 22 000 сэкономили на задачах, которые сделали сами.
Фрагмент со страницы приложения, где мы гарантируем, что все собранные средства пойдут на создание новых сказок и расширение приложения в другие регионы
Разработка мобильного приложения для «РосЕвроБанк»: кейс
Весной 2017 года мы выпустили новое мобильное приложение «РосЕвроБанка». О вызовах, с которыми пришлось столкнуться двум командам — Redmadrobot и «РосЕвроБанка» — в процессе разработки, тестирования и внедрения мобильного продукта, рассказываем в нашем очередном кейсе. Итак, «Мобильный РосЕвроБанк: behind the scenes».
К моменту, когда к нам обратился «РосЕвроБанк», мы уже сделали несколько мобильных банковских продуктов: приложения банка “Открытие”, финансовой группы “Лайф” и др. И хорошо представляли себе всю “кухню” — процессы, правила, потребности операторов финансовых услуг, поэтому приступить к разработке смогли очень оперативно.
Артем Гребнев, Product owner, «РосЕвроБанк»
«В начале 2016 года мы собрали внутрибанковскую команду для работы над проектом и стали экспериментировать. К середине года стало окончательно ясно: писать мобильную версию на базе существующих у нас решений нерационально, нужно все переделать с самого начала, и сделать это должен грамотный, подготовленный, с опытом работы с банковским ПО разработчик. Мы изучали рынок, приглашали несколько команд — было открытое предложение, могли участвовать все желающие, но у нас были четкие критерии отбора: во-первых, выделенная команда разработки, во-вторых, плотное взаимодействие вплоть до «высадки» команды разработки непосредственно в офис банка, если это поможет ускорить работу. Рассмотрев все предложения, мы признали, что именно Redmadrobot наилучшим образом соответствует нашим ожиданиям».
В августе 2016 года банк передал нам подробнейшее ТЗ на 64 страницах: в нем содержалось все то, что клиент хотел видеть в будущем приложении. Эти ожидания от продукта нам пришлось совместно корректировать. ТЗ «РосЕвроБанка», в сущности, состояло из трех функциональных блоков: качественный сервис для существующих клиентов, дополнительный сервис вроде электронного кошелька для не-клиентов и платежный агрегатор для любых операций. Все блоки правильные, но их реализация — это огромное количество работы и очень длинный time-to-market: минимум год-два разработки, а за это время — потеря аудитории и огромное отставание от лидеров отрасли. Поэтому мы предложили банку подход, который часто используется на рынке мобильных приложений и FinTech-продуктов: выпуск в стор первой версии приложения с минимальным функционалом за 6-8 месяцев, а затем планомерное развитие продукта.
Чтобы определить минимальный функционал первого релиза мы с банком выделили наиболее критичную для его бизнеса проблему: большое количество корпоративных клиентов с зарплатными проектами, которые предпочитают уводить свои деньги в другие банки или в кэш. Эту боль нужно было отрабатывать в первую очередь, тут мы и сконцентрировали усилия.
Важно было с самого начала заложить в логику приложения и middleware банка возможности для его развития на следующие полгода.
Что умеет приложение
Помимо стандартного набора функций, которые обязаны быть в современном банковском приложении, мы решили реализовать дополнительные возможности, которые встречаются далеко не всегда. А именно автоплатежи и работу с картами других банков, как в кошельке.
Алиса Морозова, менеджер проекта, Redmadrobot
«Все, что связано с банковскими продуктами, у нас собрано на одном экране — счета, кредиты, карты «РосЕвроБанка» и других банков. Можно сразу понять, что у тебя сейчас с деньгами, можно легко перекидывать их туда-сюда».
Внешняя привязанная карта позволяет делать платежи, бесплатно пополнять баланс карт «РосЕвроБанка» и совершать переводы с нее на любые другие карты. Между картами других банков можно совершать переводы с комиссией всего 1%. Для операций с внешними привязанными картами нужно только вводить их CVV/CVC коды.
Для платежей выделена отдельная вкладка и реализовано несколько типов умных автоплатежей. Первый — регулярный: указывается сумма и периодичность переводов, можно настроить ограничения — выполнять до определенной даты или указанного количества переводов.
Второй вид автоплатежей — нерегулярные переводы по факту наступления события: оплата налогов, штрафов, ЖКХ. Здесь можно настроить оплату с лимитом каждой операции и общим лимитом в месяц (например, оплачивать штрафы до 500 рублей автоматом, но не более пяти раз в месяц).
Самое интересное — автоподписка по шаблону: допустим, вы ввели номер свидетельства о регистрации ТС, нашли и оплатили штраф. Этого достаточно, чтобы в будущем система сама отслеживала ваши штрафы, уведомляла о них и предлагала оплатить. То же самое и для оплаты налогов, сборов, можно даже подключить автоматическую оплату счетов своего родственника — например, школьных кружков ребенка.
Кстати, разработка платежей по схемам была самой тяжелой задачей с точки зрения бизнес-логики. Они могут прийти в каком угодно виде, а нужно их красиво отобразить и не дать пользователю запутаться. Множество банковских операций с точки зрения пользователя очень похожи — платежи, автоплатежи, выставленные счета, платежи по шаблону, — а с точки зрения банковской системы это совершенно разные сущности.
Архитектура системы
Как устроена архитектура банка? Есть Business Process Enterprise Layer (BPEL), где можно быстро реализовывать бизнес-логику обработки всех процессов на основе действующих и разрабатываемых сервисов в формате WSDL. Мобильное приложение смотрит на middle-прослойку, та смотрит на BPEL, а BPEL общается со всеми банковскими системами через WSDL через шину.
Middle-прослойка выполняет функцию CMS и одновременно производит трансформацию JSON в WSDL, так как все внутренние сервисы работают с WSDL, а мобильное приложение адаптировано под работу с JSON.
Плюс в ней же хранятся все данные для контента приложения: иконки платежей, логотипы, цветовые схемы и т.д. Например, начинаем добавлять карту «Сбербанка», и после ввода первых цифр номера, фон карты меняется на зеленый цвет. А при оплате МТС фон подсветится красным. Все эти цветовые схемы, логотипы и иной контент хранится как раз в прослойке.
Middle-прослойка — часть работающей наружу DMZ, в которую также вынесены сайт банка и «Виртуальный Офис» (интернет-банк). За DMZ находится основная сеть банка, где работают все остальные системы. Именно там расположен слой бизнес-логики мобильного приложения, который принимает и обрабатывает запросы исключительно от прослойки.
Все общение внутри банка происходит через шину данных, которая предоставляет веб-сервисы для всех систем. В итоге у нас получилось приложение с хорошими возможностями оптимизации. Например, первая версия списков провайдеров услуг была не очень быстрой — мы загружали полные схемы на всех провайдеров, и это занимало 15-20 секунд. Теперь мы выгружаем только список определений, а детали прячем в отдельные запросы, которые не каждому клиенту потребуются.
Алексей Щербаков, IT-руководитель «цифрового банка», «РосЕвроБанк»
«Сейчас мы и веб-приложение переделываем под эту же схему с контент-прослойкой. Ранее оно использовало собственную контент-систему и общалось через WSDL c BPEL. Но на мобильном приложении мы успешно опробовали смену архитектурного подхода, и теперь веб- и мобильное приложения будут синхронизированы и по функциональности, и с архитектурной точки зрения. Унификация упростит дальнейшее развитие банка: любой новый продукт мы можем быстро вывести на все доступные digital-каналы – web, mob, sms, ussd и так далее».
Дмитрий Корчмарек, тим-лид разработки, «РосЕвроБанк»
«Когда мы делали для банка веб-приложение, времени на него ушло гораздо больше — это был огромный проект с множеством требований, для него создавалось много новых систем. Несколько месяцев заняли только подготовительные процессы по реализации API всех систем и началу интеграции, плюс еще несколько месяцев – сама интеграция. Но зато нам удалось объединить все эти системы с точки зрения пользовательской, а не банковской логики. В результате на мобильной версии процесс разработки нового API и нового функционала пошел в очень агрессивном темпе. Нам понадобилось только верхнеуровневое бизнес-требование к мобильной версии, и с помощью Redmadrobot мы всего за несколько месяцев подготовили для него API. Оно получилось не таким уж идеальным, чистым и прозрачным, как хотелось бы (там одних спецификаций 117 страниц, из которых 17 – история изменений), но сама архитектура позволяет нам разрабатывать и внедрять новые функции, не затрагивающие текущую реализацию, на «боевой» сервер прямо на ходу».
iOS-версия приложения писалась на Swift. У нас в Redmadrobot много собственных библиотек – для транспортного уровня, баз данных и так далее, что здорово экономит время.
Ольга Ворона, iOS-разработчик Redmadrobot
«Мы стремимся работать внутри всех проектов компании в одной парадигме, и наш главный архитектор продвигает слоистую архитектуру. Большие слои – сервисный уровень и UI. Сервисный уровень включает транспорт, работу с базой данных, и все это разбивается на отдельные сервисы. Подробно об уровне бизнес-логики можно почитать здесь. Когда-то мы использовали MVVM (Model, View, ViewModel), потом MVPM (Model, View, PresentationModel), сейчас для навигации мы используем Router. Стараемся как можно меньше оставлять во ViewController, больше выносим в PresentationModel. Presentation берет модели из сервисного уровня и создает из них набор ViewModel. View Controller использует эти ViewModel для конфигурации View, которые пользователь видит на экране. Router же мы используем во ViewController’ах для перехода между сценариями или внутри сценария».
Банковские нюансы
Для разработки мобильного банка нужны тестовые аккаунты пользователей, тестовые счета, карты. В тестовой зоне банка, не пересекающейся с «боевой», можно создать клиента с любыми параметрами. Но при этом заранее нужно продумать все комбинации счетов, карт, кредитов, которые могут понадобиться. Для этого нужно хорошо понимать все банковские продукты и их возможные состояния, а это огромное количество вариаций.
На первой стадии, в процессе разработки и тестирования прослойки, в связи с этим возникало много моментов. Из-за особенностей банковского API корректное выполнение некоторых действий со стороны банка может выглядеть как ошибка с точки зрения мобильных разработчиков. Например, в выдачу приложению идут идентификаторы десяти продуктов, среди которых есть и карты, и счета. И с помощью карт запрещено делать ряд операций, которые по правилам банка можно проводить только со счетов. Разработчик подставляет идентификатор карты, вызывает метод для счета, и API выдает ошибку.
Дизайн
Банк был настроен на лаконичный и легкий дизайн, поэтому мы использовали минимум графики, крупные шрифты, простую цветовую гамму.
Татьяна Гущина, дизайнер, Redmadrobot
«Для ускорения разработки максимально применялись стандартные элементы дизайна, разбавленные интересными анимациями. Их задача — дать пользователю обратную связь при выполнении медленных операций, например, загрузке больших массивов данных. Поначалу у нас были только Refresh и Activity Indicator, блокирующий весь экран. Но из-за специфики запросов — их может быть несколько на одном экране, и при прокрутке это должно отображаться — мы отрисовали еще и Loader. Еще одна тема возникла с главным экраном: поскольку в приложении ничего не кэшируется из соображений безопасности, при загрузке экран оставался пустым. Это нарушало ожидания пользователей, и мы добавили специальный промежуточный экран, имитирующий основной, на котором идет процесс загрузки».
Коммуникация в двух командах
Виталий Пальчиков, product manager, «РосЕвроБанк»
«Внутри банка у нас комфортная экосистема взаимодействия между подразделениями: внутрикорпоративный чат, внутренний файлообменник, система управления проектами. Сложность данного проекта состояла, во-первых, в работе распределенной командой, состоящей, с одной стороны, из администраторов, менеджеров, разработчиков и тестировщиков на стороне банка, с другой – «внешней» для экосистемы банка команды. Во-вторых, вызовом для нас был короткий срок запуска проекта. Мы не стали изобретать колесо — чат в WhatsApp из 15-20 людей был экстремальным, но работающим решением 🙂
Было сложно: наши “центры компетенций” развивались на лету, до проекта у нас не было острой нужды в QA, и первое время приходилось лично проверять API наших разработчиков на соответствие спецификации; в рамках тестирования мобильного приложения “снифать” трафик; сравнивать ответ бэка и поведение приложения. А после выпуска приложения — самостоятельно обрабатывать приходящие обращения клиентов, формировать FAQ-базу с предзаготовленными скриптами для передачи функционала обратно на первую линию, пока доработки еще не были реализованы. Нагрузка на менеджеров проектов со стороны обеих команд возросла в разы, но все отлично справились со сложностями».
Командное общение в чате позволило выстроить эффективную коммуникацию по проекту 24/7. В результате общение разработчиков двух команд не замыкалось на администраторе проекта, и между ними выстроилось полноценное, очень тесное взаимодействие.
Мы могли в десять вечера сообщить, что вызов метода дал сбой, в банке оперативно связывались с дежурным админом, узнавали, что сейчас внепланово накатывается срочное обновление, и тут же отвечали “подождите 10 минут, и все заработает”. А не так, что метод не принимается, в Jira заводится баг, и банк реагирует на него на следующий рабочий день. Это существенно ускорило разработку и дало возможность программистам работать в удобное для них время.
По необходимости «РосЕвроБанк» подключал к чату специалистов, отвечающих за те или иные части банковского бэкенда, мы добавляли тестировщиков, и все вопросы решались оперативно. Даже о запуске проекта все члены команды узнали из чата 🙂
Что в итоге
Для нас в Redmadrobot самым важным было правильно выстроить работу с банком. Каким бы продвинутым он ни был — это все же массивная структура, и даже для обособленного диджитал-банка требуются многочисленные согласования и проверки. Серьезное достижение — то, что мы научились работать с такими заказчиками и одновременно научили их работать с тем, как мы делаем архитектуру, дизайн, пишем, проверяем и тестируем системы.
На сегодняшний день мы закрыли примерно 90% доступного в backend банка функционала, и мобильное приложение по возможностям уже обгоняет веб-кабинет банка. Пока мы писали статью, уже реализовали возможность открытия счетов, регистрации нерезидентов, графические отчеты по использованию средств на картах и управление карточными лимитами. Из планов на ближайшее будущее — перевод клиенту банка по номеру телефона, подключение опций – кешбеки, накопительные проценты и смс-информирование, конвертация, чат с операторами и многое другое.