小程序—银行、券商们下一代APP的进阶方向

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了小程序—银行、券商们下一代APP的进阶方向，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含14460字，纯文字阅读大概需要21分钟。

内容图文

传统金融机构们的App——尤其以手机银行、手机证券为最，发展到今天，已经产生一系列的问题：从用户角度看，体验普遍不好、高度同质化；从业务运营角度看，几乎没有什么“运营”的抓手；从IT角度看，投入产出比低、难以真正敏捷迭代持续交付。并且这些App普遍违背移动互联网的基本要素。

 

金融类App真的以客户为中心？

 

先说用户体验。从用户视角来看，我们恐怕无法认同现在市场上的大部分这类App是以客户为中心的。很多App的产品其实谈不上设计，只是堆叠功能，要么是根据业务部门的需求增加一些菜单、入口，要么是基于合规监管的要求改造一些操作流程（例如配合KYC、适当性管理增删一些界面），要么是“借鉴”友商的一些做法进行一点改良，要么是基于“臆想”进行一点“创新”；行业总体相互因循沿袭，唯独缺乏对客户核心诉求的关注和理解。

 

收集用户在App端侧的交互行为数据，结合其云侧的交易历史，再匹配每天交易市场的行情变化，完全可以构建出模型对用户的操作习惯、投资偏好、对市场变化的反应、所关注的功能等等进行描绘，或者说把客户给“数字化”了。这些海量的客户画像，对App的优化产生关键影响，决定下一个版本的设计。

 

但是，估计这个“闭环”对于目前市场上大部分传统金融机构的App并没有实际形成（虽然很多App产品经理和大数据团队会大谈App“数据埋点”，但是团队能够常态性的哪怕用Excel进行手工统计分析并迅速反馈到研发中已经很不错了），所以大部分的App在很长时间内看上去都是“千人一面”、一成不变的，直到某一天也许出于下一任App产品经理的灵光一现进行大改版。

 

再说说同质化。以券商的手机证券类App为例，同质化程度是非常高的，虽然业内的这些App水平也有高下之分，可是对于大部分的用户而言，App的差异恐怕不足以让用户决定成为哪家券商的粉丝乃至客户吧。

 

换句话说，客户更有可能是因为你的App做的特别烂而抛弃你，却不见得能仅仅因为你的App做的稍微好而投奔你，况且一家金融机构的App哪里是那么容易把自己在消费者中的口碑做起来？

 

同质化的原因之一，是券商们的业务形态总体相似，业务层面就已经高度同质化，在手机屏幕的弹丸之地，界面布局、交互设计还能玩出花来？行业相互“借鉴”、“沿袭”的习惯也非常严重。原因之二，是业内绝大部分App的“内核”，都来自有限的厂商，外观看上去大同小异，券商的科技团队自己尝试把这些传统封闭技术换张皮估计也得自己先掉层皮吧。

 

活跃度低。移动互联网时代，用户手机里充斥数以百计的App，但大部分都处于“长期无用”状态。银行、证券类的应用，是典型的效用工具，随需随用。某些银行尝试让自己的App增加各种与客户的触点，从而提升用户活跃度、黏着度、使用时长，但即便银行具备无比丰富的生活应用场景，在这方面努力收效甚微。

 

对于券商来说，其App启动的频次也许会高一些，毕竟股民每天还是需要看一下行情。可是我们看到股民一边用某互联网公司的股票行情App看行情、一边用某第三方财经App看资讯、最后才用自己账户所在券商的App做交易的情况不在少数。

 

正如银行虽然掌握着巨型的资产负债表却被第三方支付平台、技术平台拦截、割裂了与客户的直接联系一样，大部分中小券商也可能逐渐沦为可被随意切换的交易通道，议价能力越来越低。

 

金融类App普遍没有运营抓手

 

传统泛金融机构的App也好网站也好，总体来说缺乏“可运营”的设计考虑，这方面和互联网公司的差距不是一星半点，毕竟互联网公司们的谋生之道就是全靠网上，在线运营推广套路多多。依靠线下营业网点做零售的银行、券商们，在线上运营确实无论经验、人才都非常缺乏。有在线运营意识的员工只能在互联网公共平台上营销展业，可是又面临巨大的合规监管问题。

 

银行、券商们自身的App，确实没有多少可以与客户进行互动的抓手，除了在App的首页展现一个理财产品的广告条，能做的事情不多。此外，由总部统一运营的内容，也往往和全国各地区域性网点的本地化诉求没关系。或者说，没有哪家机构的App可以允许自己的区域人员参与到运营中，所以网点的员工往往自己都不关注自家App的内容，去某个银行网点咨询App里推广的某些产品，也许当地的服务人员会“措手不及”，给你一个“一脸懵圈”的表情。

 

金融类App版本难以敏捷迭代

 

大家都在讲敏捷迭代，但对于传统金融机构IT而言，“敏捷”在更多时候只是一种良好愿望而已。

 

首先行业特点决定了安全、稳定、合规、健壮的App的基本属性，“维稳”是技术团队要遵循的第一原则，对于能引起生产事故导致监管问责的任何缺陷绝对是零容忍，更多的创新抵不过一张问责函。

 

其次，大部分金融IT缺乏互联网公司通常具备的蓝绿测试、灰度发布的全闭环（包括支持滚动发布技术产品的基础设施、运营配合的方法论、发布与回滚的管理制度），所以试错成本非常高。随着App功能的不断堆叠丰富，每次需要回归的测试场景越来越多。一直以来高度紧耦合的技术架构，导致任何功能的改动增加，都是牵一发动全身，只有维持非常高的测试覆盖率才能真正保障旧有的功能没有被新的改动破坏。

 

结果测试周期越来越长，尤其是在做不到自动化回归测试的情况下，手工测试团队永远疲于奔命：当业务功能从30个堆叠成300个的时候，我们完全可以理解IT运维团队以极其保守的态度对待App新功能的发布、希望以延长测试时间来保障上线质量的心态。所以快速响应业务、市场需要的“敏捷迭代”，哪怕在开发阶段可以维持，到了测试、发布阶段也不得不终止。

 

历史包袱越来越多，App逐渐变成一个“脆弱系统”（随着时间的迁移、人员的变动，整个系统里总是有些没有人愿意触碰的关键部分，唯恐修改不慎导致巨大生产问题），开发步伐越来越慢，投入产出比则越来越低。

 

传统金融机构的App中的功能，用2/8法则来看，很有可能其中80%的功能只有20%（甚至更低）的用户在使用，换句话说绝大部分的功能都是使用价值很低的。但是金融机构无法像互联网企业那样拥有自主选择权去决定放弃某些功能。

 

以券商App的“销户”功能为例，这是一个监管要求在一定截止日期前提供的App功能，哪怕券商多不愿意提供、或无论其客户多么忠诚而不需要这个功能，实现它是一个刚性要求。但是即便开发上架这样一个不算复杂、不算常用的功能，对于某些券商的App也是一个大挑战 ——可以耗费数周、能够引起故障。

 

当前App典型问题的根源

 

导致上述三类问题的根本原因有两个，一个是技术架构的掣肘，一个是产品设计对移动互联网的认知偏差。

 

当前主流银行、券商App的技术架构，完全是“紧耦合”的，以证券类App为例，代码框架不清晰、模块化缺失、功能耦合度高，开发团队在软件工程的专业程度较低，例如面向对象设计及领域建模的最佳实践缺位、在设计阶段对技术架构没有能力预先考虑“可测试性”（Testability）、对组件化理解偏差、版本管理及依赖关系管理的工具链没有正确领会使用等等，技术功底离科技公司的标准有一定差距。

 

在App的设计方面，很多设计者并没有理解透彻移动互联网、手机设备“外形因素”（form factor）的几个基本要素：点对点连接、社交属性强、用户总是“在线”、更加场景化、普适性极强 （一些看似“地球人都明白”可是大部分人没有仔细斟酌深刻理解的东西）。

 

当前的很多金融App是如何无视上述要素的呢？首先是功能繁复堆砌，违背了手机弹丸之地里应用需要简单易用的“普适性”原则。什么是“普适性”（pervasive）？微信就是一个最好的例子 ： PC时代完全无法上网、使用浏览器的祖父祖母们，现在都是微信的重度用户，这就是普适。

 

其次是该App明明运行在一个移动电话里，可是却没有与他人互联互通的能力，客户有疑问无法就当前操作的上下文在App里找到实时响应自己的服务人员、而客户经理则眼睁睁看着客户在App上而无法触达她，最终双方的沟通还需要借助其他渠道。

 

例如：理财师只能通过电话致电VIP客户，费劲的告诉她打开App进入哪个菜单入口打开哪个界面、对哪个合适的理财产品进行交易操作；而客户则同样词不达意、费尽唇舌向客户经理描述自己在App里的操作问题，而对方无法清晰了解，迫不得已只好对App截个屏通过社交平台分享一下来把事情说明白。

 

传统金融机构的App，对于用户而言往往是典型的信息孤岛：App的所有用户只是和服务器端一堆冷冰冰、僵硬的接口连接，虽然人人都以同一个App接入，彼此却无法联通（哪怕移动互联网确实是任何手机可以对接任何其他手机的点对点网络）。

 

在用户的同一台手机里，金融机构的App往往与同一部手机上的其他应用形成孤立、隔绝的信息孤岛，例如无法分享内容至社交平台或反之（合规方面的考虑固然是决定能否这么做的因素，但我们更相信这是App产品经理在这方面意识的欠缺），作为信息孤岛的App是没有生命力的，因为它无视用户在端侧所要求的便利，也失去自身向其他应用渠道传播的能力效应。

上述两个问题根源，导致到目前为止大部分的App开发还是被按作一种“信息化”的方式在进行，也就是把移动端当作小屏幕的PC，采用的技术架构与PC时代无异。

 

我们认为移动互联网是“数字化”的开端，它的应用形态与“信息化”时代的应用形态是不一样的，前者强调双向、连接而后者只是由内而外的单向的信息传播与服务输出（本文受篇幅所限，不就“数字化”与“信息化”的区别进行讨论）。移动端按传统“信息化”思路实现的直接后果，就是割裂金融机构与客户的关系：一方面客户因为移动互联网带来的便利而无需造访金融机构营业网点，另一方面金融机构与客户失去线下面对面的触点但是又无法建立起线上的连接互动。同质化的业务、同质化的App，最终导致的就是客户的忠诚度、黏着度为零。

 

现阶段把App当作一个手机软件来看待是过时的，认为改良一下App的用户界面、调整增删一下功能就能提升“用户体验”，也是一种错误的认知。

 

App并不是用户体验的全部，例如App里有没有服务人员随需随应？一个真实例子是某甲作为某大银行十多年的七钻用户，可是从来没有在该行的App里联系自己的客户经理获得过成功回应 - 恐怕App本身做配备1000项功能，对该用户也无“体验”可言。

 

提升活跃度和建立运营的抓手是“社交”

 

把金融类App当作一个“掌上型门户”、集成各种中后台应用功能向用户提供服务的架构思路，已经走到尽头。如上所述，这种思路导致的产物，实际上无异于一个单向的、把金融机构的业务信息化输出给用户自行使用的Web 1.0时代的“网站”。这种App与客户毫无“关系”可言。客户甚至都懒得销户、换个App就成了别家银行、别家券商的客户。这种风格的App，就不要谈用户“活跃度”和“使用频次”了。用户一定是“无事不登三宝殿”，牛市时使用频次也许高一些，其他时候让用户多使用App的企图则基本上是徒劳。

 

套一句俗一点的说法，在“移动互联网的下半场”，银行们券商们的App需要认真考虑移动互联网本身的最重要特点，让本身就运行在手机通讯工具里的App回归通讯协同的本源 ——社交化。也就是说，让用户在你的App里能够彼此进行交流互动、与你的员工和团队进行交流互动。

 

当用户（无论个人还是机构客户）打开一个银行App的时候，他在这个App里不仅能自助服务或者联系一下呼叫中心，还能找到一个客户经理、一个能实时解决他此刻问题的理财顾问、一个提供一站式服务的专业团队、甚至一整个营业网点（该客户所属的物理网点在线上“数字孪生”），这就是所谓的“Bank in a pocket” ——让用户带上他的银行/证券公司出行，任何需要的时候打开App，虚拟化的银行、券商就在App里。

 

这样做的好处有三：

（1）客户能通过App与理财师、工作室建立关系——这才是真正的“关系”，没有交流能有关系吗？

（2）银行、券商的员工终于有主动触及客户的途径、出口，可以通过向客户提供有价值的信息来展业、获客、巩固关系。券商App里采购回来的第三方资讯都是同质化的、并且往往也无法成为客户最信任的信息源（很有可能客户宁愿去看专业财经App）。但是券商的明星分析师分享的专业见解、投资顾问向客户个人定向提供的建议，却是App里真正有价值、能产生差异化的资讯，是真正属于券商自己生产的信息。

（3）运营终于有了途径与抓手——双向交流互动，是在线运营的基本条件，如果结合市场化的激励机制，完全可以让区域性营业网点、线上虚拟团队或工作室自主负责O2O运营，扩大本地网点的服务半径，主动出击发展客群，而不是受制于“千人一面”的总部无差异统一运营（也就是找些互联网公司统一引流、在App里推广一些产品等等）。

简单总结：一个运行在手机里的App本身没有交流互动能力，算不算是“忘记了初心“？是时候把这种能力认真构建到App里，重建客户与金融机构的远程却可信赖的数字化关系。

 

敏捷迭代快速创新的诀窍是“化整为零”

 

作为追求代码洁癖的软件工程师，我们对“紧耦合”的技术实现可以说是深恶痛绝。要解决当前金融机构移动端App日益沉重、难以真正迭代、投入产出比低的问题，首先在技术架构上要实现真正的“松散耦合”。

 

松散到什么程度呢？我们知道你可以通过面向对象设计来解耦代码级的依赖关系，你也可以通过组件化以及包管理工具来更进一步解耦二进制模块，但是这些技巧都不足以让一个同时遭受合规监管压力和市场变化压力的传统金融机构App提升敏捷度、降低试错成本。更何况大部分团队并不见得掌握这些技巧。

 

更彻底的解耦，是在一个相对稳定的App“内核”基础上，让绝大部分的应用功能（不管是因为创新需要、业务部门诉求、合规监管要求等等而产生）必须可以（1）独立开发，（2）独立部署，（3）独立运维，（4）独立管理生命周期——随时上下架而不影响App主体。

 

解决方案就是对现有的App做瘦身，化整为零，把功能高度“碎片化”。

 

“碎片化“现在已经是一个潮流。首先，在移动互联网时代，用户的阅读时间、应用使用时间都是高度碎片化的。与之相对应的，就是前端用户体验的碎片化。全中国的手机用户都已经被微信小程序充分教育，各种场景下“随需随用”、“用完即扔”，是非常典型的“效用计算”。

 

而在云端，过去几年来“微服务”大行其道，本质上也是把传统“单体应用”碎片化。碎片化当然带来管理它们（小程序、微服务）的耗损，但是现在这些问题早就被越来越成熟的开发运维平台、工具链解决了。例如：Docker容器化生态、Kubernetes容器编排管理技术、FaaS函数即服务工具链等等让云侧的小粒度服务开发运维更便利、稳定、弹性可扩。而微信本身则实际上在端侧充当了小程序的“运行时”及管理工具。

 

微信本身与运行在它上面的数以百万计的小程序，就是一个“松散耦合”的最佳例子 ：微信自身的版本迭代，从来与任何第三方小程序无关；每天互联网上各种小程序的迭代升级、上架下架，也不会影响到微信运行的稳定性。

 

如果银行、券商们能把自己的App做成像微信一样稳定，把App中的业务功能拆分出去以类似小程序的技术载体进行碎片化、单一职责、独立生命周期的开发部署，是不是金融行业特有的既需要维稳又需要敏捷迭代的矛盾就有希望得到解决？

 

这种程度的松散耦合，让业务功能可以独立于App进行开发、测试与上下架，有这样一些显而易见的好处：

（1）新业务功能单独测试单独发布，不影响基础App的稳定性，也无需对App进行全回归测试。

（2）业务功能开发可以高度并行 – 只要有人手，人多好办事（想想微信让全互联网的开发者都可以同时互不影响为它提供海量应用场景），而在传统原生App的技术体系下，这是不可能的。

（3）容易蓝绿测试、灰度发布 – 粒度细到碎片级（例如一个微信小程序是可以仅在测试白名单的范围内试点）。

（4）形成技术生态 。一家金融机构如果掌握了微信这样的技术，它也可以成为一个技术生态中心，让外部开发者、合作伙伴们遵循一定的标准开发碎片功能并申请上架到该金融机构的“应用商店”，在合规的前提下这些碎片即可类似微信小程序被该金融机构的App用户使用。

 

简单总结：要满足金融行业既稳妥又敏捷的App迭代诉求，银行、券商们需要采用一种新的技术架构，解耦其通用、稳定、基础的核心功能与场景化、变更性强、业务和运营相关的应用功能，一方面使前者健壮稳固，另一方面支持后者灵活多变。

 

解决方案：金融“物”联网

 

凡泰极客认为解决本文所讨论的所有问题的出路，是帮助每家金融机构打造自己的金融“物”联网（Internet of Everything For Financial Services）。它应该回归移动互联网的社交化（social）、场景化嵌入（embedded）、普适（pervasive）、随时在线连接（always-on/connective）、开放（open）的特点，转化传统重型App为轻量化的金融物联网入口，让客户与其他客户、客户与金融专业服务人员、金融机构员工与其他岗位、金融机构与合作伙伴、人与非人（机器人、算法、数据、应用）互相连接，实现在线、协同、强交互、远程信任关系下的连接。

 

零售金融服务，实际上需要构建了一个金融社交技术生态，以合规的通讯协同技术覆盖线上数字化服务的最后一公里，以“碎片化”的技术载体实现业务场景化并融入到交流协同中，满足客户碎片化时间里“随需随用”的特点。

 

金融机构们可以对自己的App进行瘦身，把新旧功能剥离，以独立生命周期、独立开发测试团队的方式进行开发 – 有用的场景继续深入、无效的尝试即时废弃。总体技术架构必须让基础App保持稳定、让频繁增删变更业务功能成为可能，同时最大程度降低开发门槛、减少试错成本、实现敏捷迭代。

 

上架与统一管理各种业务功能“碎片”的技术载体，则需要开放的管理平台，它们由金融企业内部开发人员或者外部合作伙伴开发，经IT与合规审核上架，被投放到该金融企业的FinChat社交网络中，与用户产生连接，形成一个金融“物”联网。应用商店里的每一“物”，都体现了一个单一职责的业务场景。社交网络里的一切交流沟通，均与场景、上下文关联。

 

App必须减重、瘦身、变成入口、合规可控对接互联网公共社交平台，通过这样的技术架构打造下一代零售金融在线服务，代表未来的方向。

 

关于凡泰极客： 以合规的金融社交技术助力金融机构实现数字化服务，促进远程信任关系的建立，实现“在线即在场”，促成“交流中交易”。

 

内容总结

以上是互联网集市为您收集整理的小程序—银行、券商们下一代APP的进阶方向全部内容，希望文章能够帮你解决小程序—银行、券商们下一代APP的进阶方向所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端

---