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

一、重構(gòu)背景

1. 系統(tǒng)簡介及重構(gòu)目標

我們要重構(gòu)的系統(tǒng)是公司已經(jīng)運營多年的車聯(lián)網(wǎng)數(shù)據(jù)監(jiān)控系統(tǒng)，目前的老系統(tǒng)已經(jīng)使用了大概有8年的時間，功能多、流程復雜、擴展性不強。

重構(gòu)的目標是將平臺打造成車聯(lián)網(wǎng)SAAS標準化服務(wù)系統(tǒng)，既要滿足國家新發(fā)布的監(jiān)管政策要求，又要為車廠客戶提供關(guān)于車身數(shù)據(jù)分析報告，為客戶技術(shù)改革和銷售預測提供支持，增強產(chǎn)品的市場核心競爭力。

2. 重構(gòu)原因

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

1）重構(gòu)啟動的時機

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

2）現(xiàn)有平臺的問題總結(jié)

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

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

3）團隊組成

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

二、項目規(guī)劃與安排

本平臺功能多，業(yè)務(wù)復雜，關(guān)于重構(gòu)計劃我們分了三期進行：

1. 基礎(chǔ)版：完成主線流程，目標是能夠?qū)④囕v從國四備案、生產(chǎn)到風控管理權(quán)限內(nèi)流程跑通，實現(xiàn)車輛信息的全面管理。
2. 標準版：增加售后、維保管理等支線模塊，目標是完善銷售數(shù)據(jù)、售后服務(wù)、BI數(shù)據(jù)統(tǒng)計等實現(xiàn)車廠對車輛全線監(jiān)控管控。
3. 高級版：對數(shù)據(jù)賦能，目標是能夠?qū)⑹占降臄?shù)據(jù)進行分析賦能，幫助實現(xiàn)企業(yè)在生產(chǎn)改革和銷售計劃的有效數(shù)據(jù)驗證。

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

三、項目重構(gòu)全流程

1. 業(yè)務(wù)梳理

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

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

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

2. 用戶調(diào)研

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

調(diào)研的步驟分兩步：

1）內(nèi)部收集意見

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

2）面對面用戶調(diào)研

在用戶實際調(diào)研之前我們聯(lián)系了客戶方的負責人，通過他負責幫我們了解了公司的部門架構(gòu)，并整理了各部門接下來對平臺功能或業(yè)務(wù)提出的需求與期望。

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

同使用者直面交流，我覺得是最高效的了解業(yè)務(wù)流程的過程，這樣既能清楚的知道對方內(nèi)部的工作方式又能通過他們的吐槽和建議認識到我們的弊端，并且能夠?qū)⑽覀儗⒁龅氖虑榍逦貍鬟_給客戶，讓客戶以參與者的身份參與其中，根據(jù)客戶的需求迫切程度建立優(yōu)先級，這樣在后期1.0上線后能調(diào)動用戶試用的積極性，反饋給我們更多更有效的建議。

3. 設(shè)計與評審

前期的調(diào)研結(jié)束后，我們花了比較多的時間梳理了所有需求并進行模塊化，輸出業(yè)務(wù)流程圖，需求界定范圍，狀態(tài)變更流程，串聯(lián)整個邏輯，保證我們在進行模塊設(shè)計的時候主流程不會跑偏。

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

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

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

4. 項目管理過程

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

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

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

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

5. 數(shù)據(jù)遷移和同步

新的產(chǎn)品上線后要分步驟做好舊數(shù)據(jù)的遷移工作。

我們采用了三種方式，保證用戶在舊平臺數(shù)據(jù)的穩(wěn)定并能平穩(wěn)的將數(shù)據(jù)過渡到新平臺，給用戶一段時間慢慢適應(yīng)，對新平臺產(chǎn)生安全感逐步遷移過來。

1）平臺基礎(chǔ)信息同步

賬號信息，組織信息，相關(guān)基本信息等靜態(tài)基礎(chǔ)信息數(shù)據(jù)，存儲方式為MySQL數(shù)據(jù)庫，由于新舊平臺表結(jié)構(gòu)和字段不同，所以需要通過工具或編寫程序的方式，將舊平臺數(shù)據(jù)結(jié)構(gòu)匹配新平臺數(shù)據(jù)結(jié)構(gòu)，同步數(shù)據(jù)。

2）新舊平臺數(shù)據(jù)相互同步

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

3）大數(shù)據(jù)遷移

大數(shù)據(jù)環(huán)境分為本部大數(shù)據(jù)環(huán)境，私有化部署大數(shù)據(jù)環(huán)境，云大數(shù)據(jù)環(huán)境。

如平臺使用本部大數(shù)據(jù)環(huán)境，則不受影響，不需要遷移；

如之前使用本部大數(shù)據(jù)環(huán)境，現(xiàn)要私有化部署或使用云環(huán)境，則需要將本部的數(shù)據(jù)同步到私有化部署環(huán)境或云環(huán)境，方式為網(wǎng)絡(luò)同步或線下磁盤拷貝，由于動態(tài)數(shù)據(jù)的數(shù)據(jù)量很大，所以都需要花費相應(yīng)的網(wǎng)絡(luò)資源與時間成本；

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

四、總結(jié)

以上就是我這次關(guān)于平臺重構(gòu)過程所涉及到的各個關(guān)鍵的節(jié)點，在新平臺重構(gòu)的過程中我們一直本著優(yōu)化業(yè)務(wù)流程，提升用戶體驗的原則，盡可能的節(jié)約用戶的學習成本，讓用戶所見即所得。

在這次的重構(gòu)完成之后我總結(jié)了幾點問題：

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

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

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

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

2）能解決用戶問題的產(chǎn)品才是好產(chǎn)品

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

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

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

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

本文由 @塵飛揚 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自 Unsplash，基于 CC0 協(xié)議