项目复盘：H5移动应用开放平台重构

编辑导读：本文作者详细地复盘了一次H5移动应用开放平台重构的经历，从项目背景介绍，到过程中的难点分析和措施制定都展开了复盘并分享了自己的项目思路以及需要注意的问题，与大家分享。

一、项目背景

物流企业的业务流程复杂，一般分为多个业务系统去分工完成，比如负责运输的TMS系统、管理仓储的IMS系统、负责货物取派的巴枪系统。B端系统的复杂性让大部分的业务都是在办公桌上的网页系统去完成，但随着移动互联网的发展，轻量的移动办公得到了重视，越来越多的B端系统发力于移动端的应用。

我所负责的产品是公司内部的移动办公与即使通讯工具，类似于钉钉和企业微信，负责搭建和管理这个移动办公平台，让更多的公司业务不用在办公桌上进行，在手机上就可以进行业务操作。

重构前的对接模式，APP上的所有工作应用，是采用前后端分部门开发的模式。我们部门负责前端设计与开发，业务系统提供负责业务逻辑与接口。这样的对接模式，在前期公司移动化需求不多情况下，我们还能及时响应业务部门。但随着业务发展与对移动化的需求逐步重视，补充再多的APP开发人员都无法跟上公司业务的变化。

所以我们在今年重构了整个工作应用的对接方式，升级为开放平台，将移动应用的开发以H5的方式授权给各业务部门，我们提供平台化的支持，建立类似微信与微信小程序的关系。

二、产品目标

建立高效完善的移动应用开放平台，帮助业务线团队可以自主快速地研发移动端应用，不用我们部门提供人力资源。

提供丰富多样的APP原生能力支持，满足业务线应用各种场景，快速响应公司业务发展。

提供更多管理支持，如数据监控，帮助业务线团队分析用户行为，让移动端应用做得越来越好。

三、产品措施

产品架构图

1. 管理后台

管理后台主要面向业务部门，提供团队成员管理、新建应用和版本发布等功能。业务部门使用这套流程，从新建应用、代码研发到发布上线都可以在平台完成。

团队管理：管理各个业务系统成员与其对应的权限，避免业务系统操作非自己负责的应用，造成平台的混乱。需包含以下信息：所属系统、成员姓名和对应角色权限。

应用管理：业务团队新增并维护应用信息，如应用名称、图标与访问地址等。HR团队需要新增考勤打卡应用时，就可以在这里维护对应信息。

版本管理：完成H5应用代码的研发和测试后，业务团队就可以将版本与代码进行关联，对外发布。这里需支持业务部门不同的发布场景，如全网发布与面向部分群体的灰度发布。

应用管理示例

2. APP端

原生能力支持：如iOS生态对于APP开发者、微信对于小程序，我们需要给业务系统提供丰富的能力支持，满足他们大部分场景的功能开发，不用他们重复造轮子，并对公司定制化的功能需求快速响应。能力分类如下：

【基础能力】打开相机、扫一扫、获取用户定位等；

【业务通用】应用间跳转、运单编码识别和微信支付等；

【业务定制】接入场地监控SDK、车辆监控SDK等。

工作台：给员工展示其可使用的工作应用，员工可以随时在这里找到需要的工作应用，并进行移动办公。为了提升员工移动办公效率，可以支持用户管理常用应用列表，搜索时记录搜索历史等。

数据监控：为了帮助业务部门更好分析用户行为，使用数据协助产品迭代。我们对应用访问人数、访问率等核心指标进行了数据埋点，用后台报表的形式提供给业务部门，让他们可以实时监控自己负责应用的用户使用情况和访问趋势，不断优化移动办公的效率和用户体验。

APP工作台示例

四、项目成果

经历了两个月的重构，我们成功将之前一对一的工作对接模式升级为一对多的开放平台，并把之前的工作应用与用户数据迁移到新的平台上。得益于新平台的标准化流程和丰富的原生能力，对接业务部门数量增长了3倍，工作应用数量实现翻倍增长，应用本身也在各业务部门的努力下功能更加丰富多样，公司信息系统移动化的进程又进了一步。

我们部门也从服务业务部门的角色中抽离出来，转变为移动办公平台的管理者。经历了平台的搭建和管理，我们也更清晰了产品的定位，能够更全面的思考未来发展。

五、项目难点

我们遇到最大的问题，就是如何与多条业务线沟通，抽出共性需求，达成目标的一致。业务方所表达的需求或方案，并不一定对方真正需要的。只按照业务方的意思去做，可能最终的结果是功能重复、逻辑冲突，而且无法真正满足业务。产品经理要在与业务沟通的过程中，梳理出核心需求和对应的核心方案。

比如在重构前的对接方式是，我们与业务线的是分开前后端产品研发。所有业务线都希望我们提供更多的人力与资源进行对接，满足他们的移动端业务需求。但是实际上，他们的核心诉求是能够让自己的业务用户更快并更好地进行移动办公，这与是否我们投入更多的人力在移动办公应用开发上，没有直接关系。

所以在今年公司移动化目标的背景下，我们投入了大量人力去重构移动应用接入的流程和丰富原生能力插件，让各业务线能够自主管理应用。

虽然一开始模式的转变，遇到了业务方的阻力，因为增加了他们部门的工作量。但是只要能够满足业务方的核心诉求，在良好的沟通下，推动起来还是比较顺利的。

六、如果是现在的我来做

会尽早搭好平台的框架与规范。由于我们是平台型产品，虽然对接了近100个工作应用，但是用户都是在同一个APP上进行操作。不同的交互体验会给用户带来困扰，后期再进行规范的统一，需要业务线的配合，会带来很高的成本，效果也差一些。

比如，在移动平台的初期，有的业务方匆匆上线一些应用，对弱网等异常环境考虑较少，导致用户在这种情况下无法加载出页面，也不能退出应用，就会投诉过来说是平台的问题。所以我们后面迭代了个兜底方案，将所有应用右上角都统一作为关闭应用的按钮，类似于iPhone的home键。由于是平台上线后的调整，许多应用的右上角已经有功能按钮了，我们需要跟所有业务部门协调这个平台调整，要投入更多的成本。

 

本文由 @Rex 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议