編輯導語：在B端產品中，一些老系統可能會有流程復雜、擴展性不強的問題，此時便需要進行重構。本文作者以其公司運營多年的車聯網數據監控系統為例，分析如何做好B端產品的重構工作，一起來看一下吧。

一、重構背景

1. 系統簡介及重構目標

我們要重構的系統是公司已經運營多年的車聯網數據監控系統，目前的老系統已經使用了大概有8年的時間，功能多、流程復雜、擴展性不強。

重構的目標是將平臺打造成車聯網SAAS標準化服務系統，既要滿足國家新發布的監管政策要求，又要為車廠客戶提供關于車身數據分析報告，為客戶技術改革和銷售預測提供支持，增強產品的市場核心競爭力。

2. 重構原因

早期的平臺沒有產品經理角色，只是研發經理帶著研發團隊，根據過往的經驗和市面上已有的同類產品，把功能堆疊出來的，功能邏輯復雜，流程不暢，嚴重影響使用者的工作效率，前期開發也沒有留下任何文檔說明，一些功能的底層邏輯規則也沒有人懂。

1）重構啟動的時機

• 市場政策變化：正好趕上國家發布新的國四標準，要求車廠必須有自己的車聯網管理平臺進行機械、芯片、終端等數據備案、新標準的排放數據監控和數據實時轉發至國家平臺。
• 用戶需求變化：車廠內部協作流程規范化，我們意識到以前的老平臺已經不能夠滿足用戶的現有部門協作標準，并且車廠對數據分析的需求越來越強烈。
• 產品目標變化：有些車廠也有了自建的DMS和CMMP平臺，客戶希望可以將數據接口開放，實現全平臺數據同步，便于管理和監控。

2）現有平臺的問題總結

• 老系統對數據量級有明顯的天花板，效率分配不合理，資源利用率低，造成任務等待多、進度慢等問題。
• 功能設計過于保守，頁面與交互落后，操作信息不清晰，各模塊劃分不標準，頁面重復率高，流程串聯性低，用戶體驗差。
• 關于參數數據分析的指標維度太少，已不能滿足現在客戶業務需求。
• 沒有將數據抽象化形成標準的接口與客戶自有平臺無法完成數據對接，全靠人工支持。

希望通過這次的重構，能將系統從底層核心架構到用戶感知層進行整體的重塑，包括：平臺承載性能提升、權限體系重塑、整體流程串聯、用戶體驗提升和新功能擴展等方面。

3）團隊組成

參與整個重構項目的團隊成員共15人。其中產品有2人，測試3人，前端2人，后臺4人，大數據4人，UI為公共資源不作為專門項目團隊成員。

二、項目規劃與安排

本平臺功能多，業務復雜，關于重構計劃我們分了三期進行：

1. 基礎版：完成主線流程，目標是能夠將車輛從國四備案、生產到風控管理權限內流程跑通，實現車輛信息的全面管理。
2. 標準版：增加售后、維保管理等支線模塊，目標是完善銷售數據、售后服務、BI數據統計等實現車廠對車輛全線監控管控。
3. 高級版：對數據賦能，目標是能夠將收集到的數據進行分析賦能，幫助實現企業在生產改革和銷售計劃的有效數據驗證。

由于平臺功能復雜，戰線拉得也比較長，并且我們希望在1.0上線后能夠遷移一批用戶使用，以便于盡早地收集到有效的用戶反饋，在后續的任務中進行完善，所以按時完成計劃內的任務十分重要，這需要我們對每個版本都有明確的規劃目標，并嚴格按照計劃執行。否則一旦出現問題，拉長開發周期，無法及時收到用戶的反饋效果，等2期項目上線后再進行修改，那簡直要備受折磨了。

三、項目重構全流程

1. 業務梳理

因為老系統平臺使用年數已久，研發人員也更換了好幾撥，隱藏邏輯無人知曉，所以我們接到重構任務后一起把整個系統的功能和業務邏輯進行全線梳理。

首先我們通過劃分模塊分工去梳理每個頁面，并憑借自己的工作經驗，把頁面中一些邏輯一起進行了梳理，比如有些數據從哪里來，這些數據關聯了哪些業務，數據的即時性和準確性等。

在這個階段，盡可能打破對原有系統的盲區，將整個系統進行一次全面的解剖，使它在我們腦海中有了一次清晰的架構認知，并且在這個過程中尋找到流程中的弊端，以便于在后續的改造升級中提供決策。

2. 用戶調研

雖然之前我們在功能梳理過程中記錄了不少問題，但了解我們真實的客戶訴求才是最重要的，通過分析使用者的使用頻率、日常的需求反饋頻率和客戶規模，篩選出來了三家大客戶作為我們的主要調研用戶。

調研的步驟分兩步：

1）內部收集意見

首先我們先在公司內部進行調研，通過和我們的銷售、售后服務、技術支持等部門內核心員工進行交談，收集用戶的問題、需求和相關競品的發展，分類整理，有助于我們在接下來與用戶面對面調研的過程中提供了依據。

2）面對面用戶調研

在用戶實際調研之前我們聯系了客戶方的負責人，通過他負責幫我們了解了公司的部門架構，并整理了各部門接下來對平臺功能或業務提出的需求與期望。

訪談內容主要圍繞各部門的日常工作流程，協作部門，數據賦能要求，以及希望我們在接下來的設計中要強化的功能。我們還了解了一些車聯網方面的內部專業術語和數據分析計算方式等。在訪談過程中經客戶同意我們采取錄音/筆記方式。

同使用者直面交流，我覺得是最高效的了解業務流程的過程，這樣既能清楚的知道對方內部的工作方式又能通過他們的吐槽和建議認識到我們的弊端，并且能夠將我們將要做的事情清晰地傳達給客戶，讓客戶以參與者的身份參與其中，根據客戶的需求迫切程度建立優先級，這樣在后期1.0上線后能調動用戶試用的積極性，反饋給我們更多更有效的建議。

3. 設計與評審

前期的調研結束后，我們花了比較多的時間梳理了所有需求并進行模塊化，輸出業務流程圖，需求界定范圍，狀態變更流程，串聯整個邏輯，保證我們在進行模塊設計的時候主流程不會跑偏。

在原型、交互和UI設計階段我們也是認真仔細，并且為了保證開發和設計的質量，我們會經常向項目小組成員同步我們的業務和需求，保證大家能夠更加了解業務和目標，也為之后他們的開發技術做好預備。

評審會議，首先我們會先與各個部門比如業務方、技術支持、客戶方代表、研發組組長，就業務邏輯和技術實現進行小型會議評審，在確?；緵]有大的問題后組織大型評審會議，與項目組相關全員進行評審，并確認項目進度安排。

在評審之前，建議對復雜的邏輯和變動比較大的需求，提前準備好相關的資料、未來擴展及相關問題的解決方法，這樣既確保了自己在評審會上的信心還會讓各方人員感到安心。

4. 項目管理過程

在項目開發過程中，我們會采用晨會和周會的形式對項目進度進行把控，對項目開發過程中業務的理解偏差、遇到的問題、需要與哪方人員進行協調配合等及時進行處理，盡量避免在開發過程中遇到此類問題導致的延期。

項目經理會在每周五下班前將項目整體進度、問題和解決方案進行郵件給小組各方成員，并向領導層同步。

項目測試階段，待核心流程跑通后，我們會邀請公司內部運營、技術支持及部分用戶在內測版上進行試用，對方覺得在核心流程階段試用比較滿意后，我們會上線正式版并通知我們的客戶。

上線后一個月時間內，我們會有專人關注用戶反饋，進行快速迭代修復及后續的任務規劃，把控好項目的進度和時間。

5. 數據遷移和同步

新的產品上線后要分步驟做好舊數據的遷移工作。

我們采用了三種方式，保證用戶在舊平臺數據的穩定并能平穩的將數據過渡到新平臺，給用戶一段時間慢慢適應，對新平臺產生安全感逐步遷移過來。

1）平臺基礎信息同步

賬號信息，組織信息，相關基本信息等靜態基礎信息數據，存儲方式為MySQL數據庫，由于新舊平臺表結構和字段不同，所以需要通過工具或編寫程序的方式，將舊平臺數據結構匹配新平臺數據結構，同步數據。

2）新舊平臺數據相互同步

新產生的數據，需要雙軌同步運行一段時間，即在舊平臺產生的數據需要同步到新平臺一份，直至完全切換至新平臺。

3）大數據遷移

大數據環境分為本部大數據環境，私有化部署大數據環境，云大數據環境。

如平臺使用本部大數據環境，則不受影響，不需要遷移；

如之前使用本部大數據環境，現要私有化部署或使用云環境，則需要將本部的數據同步到私有化部署環境或云環境，方式為網絡同步或線下磁盤拷貝，由于動態數據的數據量很大，所以都需要花費相應的網絡資源與時間成本；

如之前是私有化部署或云環境，也不受影響，不需要遷移。

四、總結

以上就是我這次關于平臺重構過程所涉及到的各個關鍵的節點，在新平臺重構的過程中我們一直本著優化業務流程，提升用戶體驗的原則，盡可能的節約用戶的學習成本，讓用戶所見即所得。

在這次的重構完成之后我總結了幾點問題：

1）不要盲目相信用戶使用文檔

實際上在我們重構完成后，平臺的模塊和功能目錄比老平臺還要多，這是因為我們在調研的過程中發現一部分用戶提出平臺不好用，絕大部分原因不是因為功能的缺失或者流程的復雜，而是因為功能隱藏得太深，甚至由于不了解業務，老平臺當初把一些常用的功能進行整合，造成了后續在培訓的時候用戶明明記得有這個功能，但真正上手去用的時候發現找不到了。

就像客戶吐槽的一句話：“聽培訓的時候覺得很完美，用的時候很崩潰”。

所以產品經理千萬不要盲目地寄希望于用戶使用文檔，即便你寫的文檔誠意滿滿，但用戶很少會打開看，倒不如在設計上讓用戶能一眼看到自己要做的事情在哪，點進去就開干。

2）能解決用戶問題的產品才是好產品

產品經理最重要的能力是解決問題的能力，在與用戶溝通的過程中要多提問，多傾聽，能夠有效地識別出問題的所在，再去找解決方案。

作為一個產品經理首先應該非常清楚自己要做一個什么東西，目標期待是什么，為了達成這個期待我們要做哪些事情，比如要和哪些人進行溝通請教，如何才能做到有效溝通，應該和哪些人去協作完成，把步驟進行一步步分解。最重要的是要把自己的目標和業務清晰地傳達給每一個項目組成員。

相信每一個經歷過重構的產品人，在項目剛上線初期，收獲的都是大量的正向反饋，新系統總歸比老系統好用的多。但重構就像是一場革命，產品上線后一切才剛剛開始。要長期關注用戶的使用情況及反饋，新鮮感過去后，能夠保持長久的核心競爭力才是成功。

以上就是我的分享啦，大家有任何想法，歡迎來評論區留言哦~~
作者：塵飛揚，微信公眾號：作為產品經理的日常（ID：jianghustory1）

本文由 @塵飛揚 原創發布于人人都是產品經理，未經許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協議