Флагманский проект ID Finance – это онлайн-сервис альтернативного кредитования MoneyMan. Он работает в семи странах – Польше, Испании, Мексике, Бразилии, Грузии, Казахстане и России. Когда мы только запускали его в России в 2015 г., мы не могли обойти стороной мобильные платформы: доля пользователей смартфонов среди россиян составляла 67% от общего числа пользователей мобильных телефонов. Как показало внутренне исследование, 80% клиентов пользовались смартфонами на платформе Android, выбор платформы для разработки первого приложения стал очевиден
На первых порах было решено отдать разработку приложения на аутсорс и параллельно набирать команду разработчиков: мы были ограничены в ресурсах, а приложение хотелось получить как можно быстрее.
Аутсорс разработки оказался дорогим и неповоротливым, внутри компании некому было следить за внешней командой разработки, после публикации рейтинг приложения в store был пугающе низкий – 1,2 из 5. Недовольны были все: и клиенты и бизнес. Нужно было что-то менять и от аутсорса отказались в пользу небольшой команды андроид разработчиков внутри компании, состоящей по началу из двух человек.
Проекты на ауторсе, помимо низкого качества, чреваты и другими проблемами
Приложение от аутсорсеров предсказуемо пришло в отвратительном состоянии, в нем не было архитектуры в принципе, было ощущение что его сделал junior на коленке за три месяца. В классе application разработчики нашли совершенно волшебный комментарий, цензурная версия которого звучит примерно, как: «API – г***о, валим отсюда». Тогда API менялось примерно раз в две недели и это мало кому нравилось: поддерживать сложно, бизнес-аналитики не сообщали об изменениях, бэкэнд тоже не особо охотно делился тем, что у них происходит.
По истории коммитов было видно, что чуваки его делали более-менее сведущие, но почему приложение получилось таким плохим, мы уже не узнаем.
Мы начали переделывать приложение и сделали отдельный layer, который отвечает исключительно за сетевые взаимодействия. Это позволяло не переписывать половину приложения ради незначительных изменений. Мы успешно внедрили архитектуру, на которой приложение Moneyman просуществовало три года без особых проблем. Она уже не актуальна, но все еще жива, и тогда она позволяла нам быстро расширяться, в 2016 году с одной страны до двух (Россия и Казахстан), а в 2017-2018 годах приложение было запущено еще в четырех странах, сейчас планируется запуск еще в одной.
Схема взаимодействия компонентов приложения
После запуска в Казахстане стало очевидно, что количество стран будет только расти и поддерживать это будет очень сложно, было решено сделать общий фреймворк. Здесь мы допустили эволюционную ошибку: в этот фреймворк мы потянули вообще все, что было общего у приложений. Да, пакеты для стран стали легкие и тонкие, но мы столкнулись с тем, что наш бизнес в разных странах развивается очень по-разному, и фичи приложений в один момент очень сильно отличаются. Начали убирать что-то из фреймворка, переносить обратно в пакеты, иногда избыточно. Сейчас в приложении баланс, когда фреймворк имеет смысл и содержит в себе все общее что есть у приложений в разных странах, и в приложении для каждой страны можно легко что-то изменять, не прибегая к переписыванию. Самым большим испытанием для нашего фреймворка был запуск сразу двух стран за один месяц, которое он успешно прошел. Во многом это получилось именно благодаря тому, что в фреймворке была реализована значительная часть функционала.
Существовавшее дизайн решение, хоть и соответствовало гайдлайнам, было морально устаревшим и не соответствовало современным понятиям о дизайне. Так появилась компонентная дизайн-система. Сейчас она в процессе разработки, первой страной в которой дизайн-система будет ведена станет Испания.
Дизайн-система это тоже фреймворк, который отвечает за UI и не касается бизнес-логики. Паттерн дизайн-системы не предполагает использование разработчиком элементов, которые живут вне её. Если разработчик вдруг захочет сделать кнопку чуть более теплого оттенка оранжевого, ему придется добавить эту кнопку в дизайн-систему и пройти с этой кнопкой все этапы согласования и только после подтверждения эта кнопка станет доступна для всех приложений в системе. Таким образом разработчик не сможет внести диссонанс во внешний вид приложения и все приложения в экосистеме будут консистентны.
Скрин слева – старое приложение для Испании, справа – новое. На первый взгляд может показаться что изменения косметические, но дизайн-система позволит нам поддерживать консистентность всех приложений Moneyman без особых усилий.
К сожалению, полноценная дизайн-система довольно дорогая штука, и может вылиться в отдельный проект, со своим бэкэндом, фронтэндом, штатом дизайнеров и т.д, но даже в условиях ограниченных ресурсов она неплохо работает.
Мы обновляем приложения по мере необходимости. Иногда — каждые две недели. Но зачастую изменения касаются только бэкэнда, и, хоть это и “не по процессам”, такие обновления в спринт иногда пропускаются.
Из неприятного — мы практикуем Forced update, который не дает пользователю пользоваться приложением, пока он не обновит его до последней версии. Используем мы это когда API меняется и некоторые функции приложения могут перестать работать. Со стороны бэкэнда система очень большая и поддерживать совместимость всех версий API дорого.
В планах — выход приложения Moneyman в еще одной стране и внедрение дизайн системы для приложений Moneyman во всех странах.
Почему аутсорс не подходит
На первых порах было решено отдать разработку приложения на аутсорс и параллельно набирать команду разработчиков: мы были ограничены в ресурсах, а приложение хотелось получить как можно быстрее.
Аутсорс разработки оказался дорогим и неповоротливым, внутри компании некому было следить за внешней командой разработки, после публикации рейтинг приложения в store был пугающе низкий – 1,2 из 5. Недовольны были все: и клиенты и бизнес. Нужно было что-то менять и от аутсорса отказались в пользу небольшой команды андроид разработчиков внутри компании, состоящей по началу из двух человек.
Проекты на ауторсе, помимо низкого качества, чреваты и другими проблемами
Приложение от аутсорсеров предсказуемо пришло в отвратительном состоянии, в нем не было архитектуры в принципе, было ощущение что его сделал junior на коленке за три месяца. В классе application разработчики нашли совершенно волшебный комментарий, цензурная версия которого звучит примерно, как: «API – г***о, валим отсюда». Тогда API менялось примерно раз в две недели и это мало кому нравилось: поддерживать сложно, бизнес-аналитики не сообщали об изменениях, бэкэнд тоже не особо охотно делился тем, что у них происходит.
По истории коммитов было видно, что чуваки его делали более-менее сведущие, но почему приложение получилось таким плохим, мы уже не узнаем.
Что мы исправили
Мы начали переделывать приложение и сделали отдельный layer, который отвечает исключительно за сетевые взаимодействия. Это позволяло не переписывать половину приложения ради незначительных изменений. Мы успешно внедрили архитектуру, на которой приложение Moneyman просуществовало три года без особых проблем. Она уже не актуальна, но все еще жива, и тогда она позволяла нам быстро расширяться, в 2016 году с одной страны до двух (Россия и Казахстан), а в 2017-2018 годах приложение было запущено еще в четырех странах, сейчас планируется запуск еще в одной.
Схема взаимодействия компонентов приложения
После запуска в Казахстане стало очевидно, что количество стран будет только расти и поддерживать это будет очень сложно, было решено сделать общий фреймворк. Здесь мы допустили эволюционную ошибку: в этот фреймворк мы потянули вообще все, что было общего у приложений. Да, пакеты для стран стали легкие и тонкие, но мы столкнулись с тем, что наш бизнес в разных странах развивается очень по-разному, и фичи приложений в один момент очень сильно отличаются. Начали убирать что-то из фреймворка, переносить обратно в пакеты, иногда избыточно. Сейчас в приложении баланс, когда фреймворк имеет смысл и содержит в себе все общее что есть у приложений в разных странах, и в приложении для каждой страны можно легко что-то изменять, не прибегая к переписыванию. Самым большим испытанием для нашего фреймворка был запуск сразу двух стран за один месяц, которое он успешно прошел. Во многом это получилось именно благодаря тому, что в фреймворке была реализована значительная часть функционала.
Дизайн-система
Существовавшее дизайн решение, хоть и соответствовало гайдлайнам, было морально устаревшим и не соответствовало современным понятиям о дизайне. Так появилась компонентная дизайн-система. Сейчас она в процессе разработки, первой страной в которой дизайн-система будет ведена станет Испания.
Дизайн-система это тоже фреймворк, который отвечает за UI и не касается бизнес-логики. Паттерн дизайн-системы не предполагает использование разработчиком элементов, которые живут вне её. Если разработчик вдруг захочет сделать кнопку чуть более теплого оттенка оранжевого, ему придется добавить эту кнопку в дизайн-систему и пройти с этой кнопкой все этапы согласования и только после подтверждения эта кнопка станет доступна для всех приложений в системе. Таким образом разработчик не сможет внести диссонанс во внешний вид приложения и все приложения в экосистеме будут консистентны.
Скрин слева – старое приложение для Испании, справа – новое. На первый взгляд может показаться что изменения косметические, но дизайн-система позволит нам поддерживать консистентность всех приложений Moneyman без особых усилий.
К сожалению, полноценная дизайн-система довольно дорогая штука, и может вылиться в отдельный проект, со своим бэкэндом, фронтэндом, штатом дизайнеров и т.д, но даже в условиях ограниченных ресурсов она неплохо работает.
Обновления ради обновлений
Мы обновляем приложения по мере необходимости. Иногда — каждые две недели. Но зачастую изменения касаются только бэкэнда, и, хоть это и “не по процессам”, такие обновления в спринт иногда пропускаются.
Из неприятного — мы практикуем Forced update, который не дает пользователю пользоваться приложением, пока он не обновит его до последней версии. Используем мы это когда API меняется и некоторые функции приложения могут перестать работать. Со стороны бэкэнда система очень большая и поддерживать совместимость всех версий API дорого.
Приложение Moneyman сейчас:
- запущено в 6 странах,
- количество установок приложения стремится к 500 000
- средняя оценка приложения – 4,6.
- Более 8-ми тысяч отзывов в российском сторе
- Над приложением работает команда из пяти разработчиков
В планах — выход приложения Moneyman в еще одной стране и внедрение дизайн системы для приложений Moneyman во всех странах.
Комментарии (5)
aPiks
06.08.2018 17:17Прочитал статью — вода.
Отдали разработку на аутсорс — оказалось, что компания на аутсорсе дно, хотя у самих API работает через одно место, да и скорее всего на компании сэкономили.
Завели свою команду разработки, выделили общие компоненты и сделали единый дизайн.
Будем расширяться.
Отжатая от воды статья. Пользы от статьи мало.
К тому же тут видно пару негативных вещей.
Плохая организация процесса — как это API меняется, а никто об этом не знает?
Плохое планирование — вы должны были изначально в разработку закладывать требование под масштабируемость и единый дизайн. Изначально же были планы идти в другие страны?
Полноценная дизайн-система это один дизайнер со знанием мобильного UI, который откроет страничку гугла Material design и скопирует элементы интерфейса от-туда, получилось бы лучше, чем то что было изначально. Да и финансовой организации с 500000 клиентов стыдно должно быть говорить, что нет бюджета на дизайнерскую команду.Sasha_Godina
06.08.2018 18:54Спасибо за такой развернутый комментарий.
Дальше будут более технические тексты, здесь мы хотели вкратце рассказать о том, как мы создавали приложение для для уже существующего продукта.Плохая организация процесса — как это API меняется, а никто об этом не знает?
Плохое планирование — вы должны были изначально в разработку закладывать требование под масштабируемость и единый дизайн. Изначально же были планы идти в другие страны?
Эти проблемы действительно были, и сейчас мы активно исправляем это.
Приложение изначально делалось только под Россию, решение о выходе в новые страны принимается очень быстро, особенно если речь идет о странах ближнего разубежья с похожей законодательной базой.Да и финансовой организации с 500000 клиентов стыдно должно быть говорить, что нет бюджета на дизайнерскую команду.
Нет не бюджета, нет смысла превращать это в отдельный продукт внутри продукта. А дизайнерская команда у нас есть :)
firuz1844
Мне кажется, картинка с биноклем тут не в тему. Да и тема сама не раскрыта. Как вы «сделали» в итоге приложение то? Статья менеджерская или о разработке? Что с iOS версией?
Sasha_Godina
По-моему картинка отлично отражает отношения клиента с удаленной командой подрядчика на аутсорсе.
Если кратко, фреймворки и дизайн-система это средства благодаря которым возможна быстрая и эффективная разработка и поддержка приложений с общим «ядром» и их последующее масштабирование.
iOS-версия есть в планах :)