数字化时代 App 们将何去何从？

​C 端 App 已死，有事烧纸

作为普通人，每天在自己的手机上会使用的 App 有几个？社交电商、衣食住行、银行服务、视频娱乐等较为高频的场景日益聚合在互联网大平台所提供的“超级 App”中，独立第三方 App 即便聚焦细分领域的特定群体，依然不得不与大量其他竞争者激烈争夺消费者掌中那方寸之屏。

我们的手机上满屏满屏的App，绝大部分都是僵尸 App；作为消费者，我们日常使用的都是超级 App 而且数量不会超过十根手指。剩下的都是浮云对不对？

B 端 App 都是毫无生气的信息孤岛

作为打工人，谁手机还没有那么几个东家或者甲方指定使用的 App – 移动办公、企业协同、与行业合作伙伴的商务连接、服务客户专用的展业工具等等。大部分这类 App 用起来都是很不爽的，例如体验差却迟迟等不到优化升级、想要的功能久久不能上线、完全是信息孤岛无法与其他常用工具打通、看不到其他同事的活动无法与之互动等等。导致我们打工人对同是打工人的 IT 同志们产生一定的误解和吐槽有没有？

信息化的思维定式

对于缺乏互联网基因的传统行业 IT 来说，迄今大部分还是沿着“信息化”时代的思维定式来看待 App 的开发：C 端和 B 端的 App 都是手机应用、技术上并无差别，而 App 只不过是在一个更小的屏幕上以更友好的交互体验呈现应用逻辑 – 总不能让用户在几英寸的手机屏幕上打开浏览器敲网址吧？屏幕上的 App 其实就是一个个快捷链接…

这种思维定式下，无论用什么计算机语言开发 App，跟 30 年前用 HTML + CGI 开发一个网站，没有什么区别，就是：我们公司已经有了这些那些系统，现在我们得给它们包一层，输出到网上给我们的客户、合作伙伴使用。这就是传说中的信息化，即在“电算化”（以本地软件系统替代手工劳作）的基础上，再接上网络从而使数据字节能够被提交进来、输送出去，形成“信息”。
App 是这么玩的吗？

C端App该怎么玩？

消费者侧，全部是互联网平台的天下，它们才是流量入口、超级应用，才是消费者日常高频使用的东西。对于大部分垂直行业的企业而言，研发 App 的能力有限、运营 App 流量日活的技能不足、互联网化的基因欠缺，要把自己的 App 做好，在应用市场脱颖而出，可谓艰难。研发的投入产出比也很差。

但西谚有云：“如果你不能打败他们，那就加入他们”。所以更实际的策略只能如下：

1. 首先，拥抱消费者所在的互联网流量平台，采用该平台所开放的技术框架，把自己的产品与服务“进驻”到该平台上，让该平台的用户发现、使用。任何能称得上是“平台”的互联网产品，一定是有技术标准、技术接口、开放生态、欢迎第三方“进驻”的。典型例子，就是众所周知的“小程序”了；
2. 其次，我们还是可以向消费者提供 App 的。目标受众，是把通过上述平台“引流”过来并沉淀下来的存量用户，他们可能作为客户需要更直接、更权威、更功能强大的连接工具触达企业。

所以我们的策略，是让自己变身“八爪鱼”，把自己的产品与服务像触须一样延伸到第三方流量平台，例如用户在第三方平台使用我们的小程序的时候，可以被提示去下载采用更强大更直接的 App。

别忘了，我们向消费者提供的 App 需要充分利用手机的社交通讯属性，让消费者通过 App 能找到我们的客服、客户经理、专家。如果用户在 App 里却无法联系到你的员工，有槽无法吐、有建议无法提，这一切明明在一个通讯设备上，是不是一件很愚蠢的事情？你的员工也应该在同一个 App、或者另一个与之连接的所谓 B 端 App 上。

B端App该怎么玩？

这类 App 通常面向我们企业打工人、合作伙伴人员聚合专业性专门性比较高的工具或工具集合。例如银行、保险公司、地产公司可以向他们的网点客户经理、保险代理人、经纪中介人员提供移动端展业工具，聚合了 CRM、ERP、行政管理、协同办公等等的各种应用，美其名曰“赋能”。

这类 App 能否成功玩的起来，不仅取决于公司的“行政命令”逼迫员工们使用，最终取决于它是否“有用”。可怎么样才能有用呢？那不是产品经理拍脑袋拍成的，而是用户们拍砖拍出来的。如何才能让 App 不被拍死、活到成功的那天？诀窍只有一个：敏捷迭代、频繁升级、快速更新、响应拍砖。

当用户吐槽某个功能的时候，马上给他改进，几天见效；当用户用的有点意思开始提出建议，迅速给他实现，一周搞定；当业务部门看到希望而逐渐增加业务创新的需求想法，快捷让他看到雏形试用… 用户的信心起来了，良性循环建立了，这个“赋能”的 App 就有点成功希望。

乐高化的APP

解决方案，是把 App 化整为零，功能点最大程度的模块化、松散耦合、互不干扰。修改一个功能模块不影响其他模块，增加或删除功能模块不影响整个 App。理想的 App 构建方式，是让 App 像搭积木那样组装。“等等”，负责 App 研发的技术开发会说，“我们早就模块化了，没有人比我更懂模块化”。

事实上的效果如何？是不是 App 越来越重、迭代周期越来越长、功能越多回归测试的负担越大？

我们所谓的“乐高化”，必须做到这样的程度：

1. 每一块“乐高”都是独立生命周期 – 独立于 App 自身的生命周期之外，独立可测试、独立可发布、独立可监测、独立可下架；
2. 每一块“乐高”的开发者都可以是不同的人和团队，甚至可以和 App 组装者毫无关系，这正如 iPhone 上的应用商店里的应用开发者和苹果的技术团队可以没有半毛钱关系一样；
3. 每一块“乐高”自身的质量、稳定性，不影响其所在运行的 App 的性能与安全。
   

一句话，功能模块与 App 实现极度的松散耦合。

有这样的例子吗？我们熟知的小程序、手机厂商们尝试推动的快应用、苹果 iOS 14 开始支持的 Clip 技术，都是。以微信 App 为例，它与它所支持运行的互联网上数以百万计的小程序之间，就是极度的松散耦合。每一个小程序都由不同的团队开发维护、独立上下架、独立升级、独立测试、独立运行，互不干扰。

FinClip – 超级App的开发运行平台

好消息是，现在任何企业都可以轻松、简单的获得上述技术大厂们才具备的技术能力 – 解决方案就是一个100%可以私有化部署的、云原生的、融合 DevOps 能力的小程序开放生态平台 FinClip，它让任何企业瞬间具备打造“乐高化”超级 App 的能力、变身小程序平台运营者，企业 IT 可以自行研发小程序、可以开放平台让第三方合作伙伴提供小程序，通过上下架管理，让丰富的小程序生态上架到自己的 App 中，任何业务部门的需求都能并行快速响应、任何创新功能的试错成本都最大程度可控，敏捷迭代、持续交付都不再只是口号。

基于 FinClip 开发的 App，具有以下强大之处：

首先，采用这个平台的企业，天然拥有了一个名符其实的技术中台：100%全容器化，充分利用容器编排技术实现千万级别的并发支持，对前端“碎片”（小程序）和后端“碎片”（微服务）进行了高效的管控。后台的“上下架”管理能力，首次让企业拥有了内部“应用市场”的机制。引入了“上架”的概念，让企业内外的应用场景的数字化粒度完全可控，任何功能均可以作 AB 测试和灰度发布；任何的活动类、运营类的场景均可以快速实现、代码用完即扔。这样构建出来的 App，具备强大的、中台主导的、云侧运营能力。

其次，基于 FinClip 构建的 App，不再是信息孤岛。这体现在三方面：

1. App 里面的任何一个业务场景，均可以被分享到主流的第三方互联网社交平台，从而产生传播、引流、获客的作用；
2. 支持应用内（in-app）搜索，让用户对本 App 里运行的任何内容、数据进行便利的索引；
3. 支持互联网上网络爬虫、搜索引擎能索引到 App 里的内容（范围粒度安全可控），类似对自身网站的 SEO 实践，在 App 上同样可用。换句话说，如果我们希望自己的 App中内容的透明程度跟普通网站一样，以便于互联网上的用户能搜索到，完全可以实现。

因为在 FinClip 上可以随意实现任何粒度的数字化场景，通过算法去基于用户个性化特点进行各种“乐高”的组装，实现千人千面、智能推荐，不再是空话一句。

在 FinClip 上的任何小程序，可以根据用户画像、客群分层，动态控制可见范围，例如一个仅针对某某地区的金牌会员可见的运营活动小程序，通过简单配置进行发布即可，无需编写任何复杂的应用逻辑代码。

一个数字化生态化运营平台

FinClip 平台上的二次开发，完全建立在互联网主流技术标准或者既成事实标准之上，其设计逻辑是力求开发者无需专门学习掌握封闭的、小众的技术技能，即能迅速发挥生产力。使用 FinClip 的企业，聚焦业务运营，而不是 App 研发，因为他们可以轻易在市场上找到大量的开发人员，包括但不限于第三方开发商、外包工程师、自由技术职业者、实习生 – 只要有互联网上小程序开发的基本知识，以极低的技术门槛即可开发大量一次性、偶发性的运营活动场景，例如小游戏、简单供目标客户填写的临时活动登记表单、问卷调查等等。

有商业生态的企业，可以开放自己的 FinClip 平台，让合作伙伴开发小程序上架到自己的 App 中，形成丰富多彩的场景与功能，服务客户。例如银行信用卡 App 可以上架大量的第三方消费场景类小程序，旅游 App 可以上架食住行类合作伙伴的小程序，最终实现的是以客户为中心的数字化服务闭环。

FinClip，给任何企业 App 带来全新可能。