專案覆盤：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 協議