旗舰项目ID Finance是在线另类借贷服务MoneyMan。 他在七个国家工作-波兰，西班牙，墨西哥，巴西，乔治亚州，哈萨克斯坦和俄罗斯。 当我们于2015年在俄罗斯首次推出该产品时，我们不能忽视移动平台：俄罗斯人中的智能手机用户所占份额为手机用户总数的67％。 内部研究表明，有80％的客户在Android平台上使用智能手机，因此开发第一个应用程序的平台选择变得显而易见
为什么外包不起作用
首先，决定外包应用程序的开发，同时又招募开发团队：我们的资源有限，我们希望尽快获得该应用程序。
开发外包原来是昂贵且缓慢的，公司内部没有人跟随外部开发团队。在发布该应用程序后，该应用程序在商店中的评级非常低-满分为5分（1.2分）。每个人都感到不满意：客户和企业。 有必要进行一些更改，外包被公司内部的一小群android开发人员放弃，该团队最初由两个人组成。
外包项目，除了质量差之外，还充满其他问题可以预期，外包商的应用程序处于令人作呕的状态，原则上它没有体系结构，感觉它是由一个大三生在三个月内屈膝完成的。 在应用程序类中，开发人员发现了一个完全神奇的注释，该注释的审查版本听起来像是：“ API-g ***哦，把它从这里拿出来。” 然后，该API每两周更改一次，并且很少有人喜欢它：它很难维护，业务分析师没有报告更改，后端也不十分愿意与他们分享正在发生的事情。
从提交的历史来看，很明显，帅哥们或多或少地做到了知识渊博，但是我们不知道为什么应用程序如此糟糕。
我们修复了什么
我们开始重新制作应用程序，并制作了一个单独的层，该层仅负责网络交互。 这样就可以不重写应用程序的一半进行较小的更改。 我们已经成功实现了Moneyman应用程序持续三年的架构，而没有任何问题。 它不再相关，但仍然存在，然后它使我们得以迅速扩展，在2016年从一个国家扩展到两个国家（俄罗斯和哈萨克斯坦），并在2017-2018年在另外四个国家启动了该应用程序，现在计划在另一个国家启动在一个。
应用程序组件交互图在哈萨克斯坦启动之后，很明显，国家数量只会增加，而且很难维持，因此决定创建一个通用框架。 在这里，我们犯了一个进化错误：在此框架中，我们撤消了应用程序之间常见的所有内容。 是的，为国家/地区提供的服务包已变得越来越薄，但我们面临的事实是，我们在不同国家/地区的业务发展差异很大，而且某一时刻应用程序的功能也有很大差异。 他们开始从框架中删除某些内容，然后将其传输回包，有时是多余的。 现在，在应用程序中可以找到一个平衡点，当该框架有意义并包含不同国家/地区的应用程序共有的所有内容时，在每个国家/地区的应用程序中，您都可以轻松地更改某些内容而无需重新编写。 对我们框架的最大考验是在一个月内成功启动了两个国家。 这主要是由于在框架中实现了很大一部分功能。
设计系统
现有的设计解决方案虽然符合准则，但已过时，并且与现代设计概念不符。 因此，有一个组件设计系统。 现在它正在开发中，第一个将保留设计系统的国家将是西班牙。
设计系统也是负责UI且与业务逻辑无关的框架。 设计系统模式并不意味着开发人员将使用其外部的元素。 如果开发人员突然想将按钮调成稍暖的橙色阴影，则他将不得不将该按钮添加到设计系统中，并经过与该按钮协调的所有阶段，只有在确认后，该按钮才能对系统中的所有应用程序可用。 因此，开发人员将无法协调应用程序的外观，并且生态系统中的所有应用程序将保持一致。
左边的屏幕是西班牙的旧应用程序，右边是新的应用程序。 乍一看，这些更改似乎是表面上的，但是设计系统将使我们能够不费吹灰之力就能保持所有Moneyman应用程序的一致性。不幸的是，成熟的设计系统是一件非常昂贵的事情，并且可能导致一个单独的项目，该项目具有自己的后端，前端，设计人员等，但是即使资源有限，它也可以很好地工作。
更新更新
我们会根据需要更新应用程序。 有时每两周一次。 但是更改通常只涉及后端，尽管这是“离线的”，但有时在sprint中会跳过此类更新。
令人不快的是-我们实行强制更新，这会阻止用户使用应用程序，直到他将其更新到最新版本为止。 当API更改且应用程序的某些功能可能停止工作时，我们将使用此功能。 在后端，该系统非常庞大，并且维持所有版本API的兼容性都很昂贵。
现在的Moneyman应用程序：
- 在6个国家/地区推出
- 应用程序安装数量趋于500,000
- 应用程式的平均评分为4.6。
- 俄罗斯商店有超过8000条评论
- 由五个开发人员组成的团队正在研究该应用程序
这些计划包括在另一个国家发布Moneyman应用程序，以及在所有国家/地区引入针对Moneyman应用程序的系统设计。