Флагманский проект ID Finance – это онлайн-сервис альтернативного кредитования MoneyMan. Он работает в семи странах – Польше, Испании, Мексике, Бразилии, Грузии, Казахстане и России. Когда мы только запускали его в России в 2015 г., мы не могли обойти стороной мобильные платформы: доля пользователей смартфонов среди россиян составляла 67% от общего числа пользователей мобильных телефонов. Как показало внутренне исследование, 80% клиентов пользовались смартфонами на платформе Android, выбор платформы для разработки первого приложения стал очевиден
![image](https://habrastorage.org/r/w1560/webt/zg/zo/oq/zgzooqrnhceuxk1ev2ijlx3sr_u.png)
На первых порах было решено отдать разработку приложения на аутсорс и параллельно набирать команду разработчиков: мы были ограничены в ресурсах, а приложение хотелось получить как можно быстрее.
Аутсорс разработки оказался дорогим и неповоротливым, внутри компании некому было следить за внешней командой разработки, после публикации рейтинг приложения в store был пугающе низкий – 1,2 из 5. Недовольны были все: и клиенты и бизнес. Нужно было что-то менять и от аутсорса отказались в пользу небольшой команды андроид разработчиков внутри компании, состоящей по началу из двух человек.
![image](https://habrastorage.org/r/w780q1/webt/7g/ci/uc/7gciucq65pua96ftb3--0vsc1ws.jpeg)
Проекты на ауторсе, помимо низкого качества, чреваты и другими проблемами
Приложение от аутсорсеров предсказуемо пришло в отвратительном состоянии, в нем не было архитектуры в принципе, было ощущение что его сделал junior на коленке за три месяца. В классе application разработчики нашли совершенно волшебный комментарий, цензурная версия которого звучит примерно, как: «API – г***о, валим отсюда». Тогда API менялось примерно раз в две недели и это мало кому нравилось: поддерживать сложно, бизнес-аналитики не сообщали об изменениях, бэкэнд тоже не особо охотно делился тем, что у них происходит.
По истории коммитов было видно, что чуваки его делали более-менее сведущие, но почему приложение получилось таким плохим, мы уже не узнаем.
Мы начали переделывать приложение и сделали отдельный layer, который отвечает исключительно за сетевые взаимодействия. Это позволяло не переписывать половину приложения ради незначительных изменений. Мы успешно внедрили архитектуру, на которой приложение Moneyman просуществовало три года без особых проблем. Она уже не актуальна, но все еще жива, и тогда она позволяла нам быстро расширяться, в 2016 году с одной страны до двух (Россия и Казахстан), а в 2017-2018 годах приложение было запущено еще в четырех странах, сейчас планируется запуск еще в одной.
![image](https://habrastorage.org/r/w780q1/webt/bq/ee/ey/bqeeeynu98n8wcyokvuaicawz4i.jpeg)
Схема взаимодействия компонентов приложения
После запуска в Казахстане стало очевидно, что количество стран будет только расти и поддерживать это будет очень сложно, было решено сделать общий фреймворк. Здесь мы допустили эволюционную ошибку: в этот фреймворк мы потянули вообще все, что было общего у приложений. Да, пакеты для стран стали легкие и тонкие, но мы столкнулись с тем, что наш бизнес в разных странах развивается очень по-разному, и фичи приложений в один момент очень сильно отличаются. Начали убирать что-то из фреймворка, переносить обратно в пакеты, иногда избыточно. Сейчас в приложении баланс, когда фреймворк имеет смысл и содержит в себе все общее что есть у приложений в разных странах, и в приложении для каждой страны можно легко что-то изменять, не прибегая к переписыванию. Самым большим испытанием для нашего фреймворка был запуск сразу двух стран за один месяц, которое он успешно прошел. Во многом это получилось именно благодаря тому, что в фреймворке была реализована значительная часть функционала.
Существовавшее дизайн решение, хоть и соответствовало гайдлайнам, было морально устаревшим и не соответствовало современным понятиям о дизайне. Так появилась компонентная дизайн-система. Сейчас она в процессе разработки, первой страной в которой дизайн-система будет ведена станет Испания.
Дизайн-система это тоже фреймворк, который отвечает за UI и не касается бизнес-логики. Паттерн дизайн-системы не предполагает использование разработчиком элементов, которые живут вне её. Если разработчик вдруг захочет сделать кнопку чуть более теплого оттенка оранжевого, ему придется добавить эту кнопку в дизайн-систему и пройти с этой кнопкой все этапы согласования и только после подтверждения эта кнопка станет доступна для всех приложений в системе. Таким образом разработчик не сможет внести диссонанс во внешний вид приложения и все приложения в экосистеме будут консистентны.
![image](https://habrastorage.org/r/w1560/webt/qv/fw/fd/qvfwfdepcngrdeiw_uthqguwpi4.png)
Скрин слева – старое приложение для Испании, справа – новое. На первый взгляд может показаться что изменения косметические, но дизайн-система позволит нам поддерживать консистентность всех приложений Moneyman без особых усилий.
К сожалению, полноценная дизайн-система довольно дорогая штука, и может вылиться в отдельный проект, со своим бэкэндом, фронтэндом, штатом дизайнеров и т.д, но даже в условиях ограниченных ресурсов она неплохо работает.
Мы обновляем приложения по мере необходимости. Иногда — каждые две недели. Но зачастую изменения касаются только бэкэнда, и, хоть это и “не по процессам”, такие обновления в спринт иногда пропускаются.
Из неприятного — мы практикуем Forced update, который не дает пользователю пользоваться приложением, пока он не обновит его до последней версии. Используем мы это когда API меняется и некоторые функции приложения могут перестать работать. Со стороны бэкэнда система очень большая и поддерживать совместимость всех версий API дорого.
В планах — выход приложения Moneyman в еще одной стране и внедрение дизайн системы для приложений Moneyman во всех странах.
![image](https://habrastorage.org/webt/zg/zo/oq/zgzooqrnhceuxk1ev2ijlx3sr_u.png)
Почему аутсорс не подходит
На первых порах было решено отдать разработку приложения на аутсорс и параллельно набирать команду разработчиков: мы были ограничены в ресурсах, а приложение хотелось получить как можно быстрее.
Аутсорс разработки оказался дорогим и неповоротливым, внутри компании некому было следить за внешней командой разработки, после публикации рейтинг приложения в store был пугающе низкий – 1,2 из 5. Недовольны были все: и клиенты и бизнес. Нужно было что-то менять и от аутсорса отказались в пользу небольшой команды андроид разработчиков внутри компании, состоящей по началу из двух человек.
![image](https://habrastorage.org/webt/7g/ci/uc/7gciucq65pua96ftb3--0vsc1ws.jpeg)
Проекты на ауторсе, помимо низкого качества, чреваты и другими проблемами
Приложение от аутсорсеров предсказуемо пришло в отвратительном состоянии, в нем не было архитектуры в принципе, было ощущение что его сделал junior на коленке за три месяца. В классе application разработчики нашли совершенно волшебный комментарий, цензурная версия которого звучит примерно, как: «API – г***о, валим отсюда». Тогда API менялось примерно раз в две недели и это мало кому нравилось: поддерживать сложно, бизнес-аналитики не сообщали об изменениях, бэкэнд тоже не особо охотно делился тем, что у них происходит.
По истории коммитов было видно, что чуваки его делали более-менее сведущие, но почему приложение получилось таким плохим, мы уже не узнаем.
Что мы исправили
Мы начали переделывать приложение и сделали отдельный layer, который отвечает исключительно за сетевые взаимодействия. Это позволяло не переписывать половину приложения ради незначительных изменений. Мы успешно внедрили архитектуру, на которой приложение Moneyman просуществовало три года без особых проблем. Она уже не актуальна, но все еще жива, и тогда она позволяла нам быстро расширяться, в 2016 году с одной страны до двух (Россия и Казахстан), а в 2017-2018 годах приложение было запущено еще в четырех странах, сейчас планируется запуск еще в одной.
![image](https://habrastorage.org/webt/bq/ee/ey/bqeeeynu98n8wcyokvuaicawz4i.jpeg)
Схема взаимодействия компонентов приложения
После запуска в Казахстане стало очевидно, что количество стран будет только расти и поддерживать это будет очень сложно, было решено сделать общий фреймворк. Здесь мы допустили эволюционную ошибку: в этот фреймворк мы потянули вообще все, что было общего у приложений. Да, пакеты для стран стали легкие и тонкие, но мы столкнулись с тем, что наш бизнес в разных странах развивается очень по-разному, и фичи приложений в один момент очень сильно отличаются. Начали убирать что-то из фреймворка, переносить обратно в пакеты, иногда избыточно. Сейчас в приложении баланс, когда фреймворк имеет смысл и содержит в себе все общее что есть у приложений в разных странах, и в приложении для каждой страны можно легко что-то изменять, не прибегая к переписыванию. Самым большим испытанием для нашего фреймворка был запуск сразу двух стран за один месяц, которое он успешно прошел. Во многом это получилось именно благодаря тому, что в фреймворке была реализована значительная часть функционала.
Дизайн-система
Существовавшее дизайн решение, хоть и соответствовало гайдлайнам, было морально устаревшим и не соответствовало современным понятиям о дизайне. Так появилась компонентная дизайн-система. Сейчас она в процессе разработки, первой страной в которой дизайн-система будет ведена станет Испания.
Дизайн-система это тоже фреймворк, который отвечает за UI и не касается бизнес-логики. Паттерн дизайн-системы не предполагает использование разработчиком элементов, которые живут вне её. Если разработчик вдруг захочет сделать кнопку чуть более теплого оттенка оранжевого, ему придется добавить эту кнопку в дизайн-систему и пройти с этой кнопкой все этапы согласования и только после подтверждения эта кнопка станет доступна для всех приложений в системе. Таким образом разработчик не сможет внести диссонанс во внешний вид приложения и все приложения в экосистеме будут консистентны.
![image](https://habrastorage.org/webt/qv/fw/fd/qvfwfdepcngrdeiw_uthqguwpi4.png)
Скрин слева – старое приложение для Испании, справа – новое. На первый взгляд может показаться что изменения косметические, но дизайн-система позволит нам поддерживать консистентность всех приложений Moneyman без особых усилий.
К сожалению, полноценная дизайн-система довольно дорогая штука, и может вылиться в отдельный проект, со своим бэкэндом, фронтэндом, штатом дизайнеров и т.д, но даже в условиях ограниченных ресурсов она неплохо работает.
Обновления ради обновлений
Мы обновляем приложения по мере необходимости. Иногда — каждые две недели. Но зачастую изменения касаются только бэкэнда, и, хоть это и “не по процессам”, такие обновления в спринт иногда пропускаются.
Из неприятного — мы практикуем Forced update, который не дает пользователю пользоваться приложением, пока он не обновит его до последней версии. Используем мы это когда API меняется и некоторые функции приложения могут перестать работать. Со стороны бэкэнда система очень большая и поддерживать совместимость всех версий API дорого.
Приложение Moneyman сейчас:
- запущено в 6 странах,
- количество установок приложения стремится к 500 000
- средняя оценка приложения – 4,6.
- Более 8-ми тысяч отзывов в российском сторе
- Над приложением работает команда из пяти разработчиков
В планах — выход приложения Moneyman в еще одной стране и внедрение дизайн системы для приложений Moneyman во всех странах.