導語：工作1-3年的產品經理，在沒有任何重構經驗的團隊中，如何獨立操盤一次業務系統的全流程重構？希望本文能提供給在系統重構啟動期的你一些參考思路。

一、重構背景

1. 系統和用戶

1）系統簡介

本次重構的系統，是一個風控大數據測試系統，通過線上化操作實現多種數據產品、模型的批量調用，并可為客戶提供數據分析報告，同時也為我司風控人員提供建模數據的支持。

該系統的特點是小眾且晦澀，與多個系統有交互。

包括上游CRM等多個業務系統有信息交互、還有下游與BI、建模平臺等多個數據系統有數據交互，最重要的是底層還與數據產品API接口有核心的調用交互。

如果不了解公司核心業務邏輯，不了解公司的數據產品，將很難hold住這個系統。

我是在負責舊系統1個月后，確切得知該系統計劃進行重構，雖然在這之前自己已經負責過幾個有相關性的業務系統了，但是還是花了很長時間摸清了這個系統的全部邏輯。

2）用戶特點

值得一提的是，這個系統是少見的有“多視角用戶”的情況，有客戶和分析師兩種角色，兩種登錄賬號類型，可分別從內網和外網登錄，部分數據權限是兩邊互通的，但功能權限是隔離的。

由于客戶方的存量賬號龐大且用戶操作高頻，故系統重構必須將客戶端和風控端的重構分成兩部分，即在一段時間內新舊系統將會并行，而客戶和分析師都是無感知的。

上面這個方案是在設計中期修改的，部門的領導也給了很多建議，這里也是本次重構計劃中的難點之一。

2. 重構原因

1）內因

老系統是公司成立初期最早的一批系統，系統沒有前端，只靠著一個后端python開發維護著，可想而知系統的頁面有多原始。

老系統對數據測試量級有明顯的天花板，效率分配不合理，資源利用率低，造成任務等待多、進度慢等問題。

領導層希望新系統能更換java語言，從而提升系統的性能。

2）外因

與多數需要被重構的系統類似，重構前的老系統往往都有以下令用戶“忍無可忍”的地方：

• 賬號權限體系復雜，有局限性，新用戶學習成本高
• 功能設計過于保守，異常頻出，用戶反饋糟糕
• 頁面與交互落后，操作信息不清晰，用戶體驗差

因此，本次重構是由內到外的重構，從核心的底層性能到用戶有感知功能流程進行的整體重塑。

新系統重構內容包括：技術性能提升、權限體系重塑、功能流程改造、用戶體驗提升、新功能擴展等5個方面。

技術性能提升和業務流程改造因每個系統都不盡相同，這里我們暫不討論，后面主要聊聊產品重構的思路以及各個節點需要經歷什么，以便大家舉一反三，在前期心中有底。

3. 團隊歷時

參與整個項目主要的開發測試成員有5位，均沒有系統重構的相關經驗。

• 產品：1人
• 后端：2人
• 前端：1人
• 測試：1人

備注：UI 屬于公共資源，設計了初版系統界面。

除去技術底層的重構時間，產品參與重建新系統的時間大概是7個月，完成了內部用戶使用端的重構和用戶遷移。

• 前期調研：2周
• 原型設計+公開評審：2周
• 開發v1.0版本：1月
• 功能補全+新功能開發：3月
• 數據同步+新舊系統并行：1月
• 內部用戶完全遷移：1月

二、規劃與安排

對于整個重構項目，按用戶使用端分了兩期：一期遷移內部用戶至新系統，二期遷移外部客戶至新系統（二期啟動時間定在一期任務全部完成并穩定運行3個月之后再開始）。

對于一期計劃我們定了目標，分三步走：

1. 第一步：完成v1.0 MVP版本的上線
2. 第二步：接入更多接口和完善更多功能
3. 第三步：新舊系統數據同步和用戶遷移

這個系統內部的業務源頭是任務申請，有兩個申請入口。一個是系統內部的申請入口，一個是從CRM發起的客戶申請入口，考慮后者涉及外部系統，故不屬于最小化MVP的范圍。

因此第一步 v1.0 版本上線，我們的目標，就是跑通一條完整的用戶使用路徑：即從內部申請測試任務開始，到拿到正確的數據測試結果結束。

PS：界定MVP版本內容是十分重要的，v1.0版本無需完美無缺，做到按時上線，后續能在用戶的反饋下不斷完善是最好的。如一開始就憋了很多大招，不僅拉長了開發測試的周期，還可能會在后續的用戶的檢驗中遭遇滑鐵盧，對上線的內容進行修改，實在不值。

三、重構的全流程

1. 業務梳理

作為產品經理，如果你接到了重構系統的任務，你需要在盡可能短的時間內摸清系統的全部邏輯，除了頁面能看到的邏輯，還需要去了解很多頁面看不到的邏輯。

此外，還要把上下游系統的功能交互和數據交互全部理解和走通，知道數據是從哪里來，到哪去。

由于老系統年代久遠，歷經多個產品和研發、很多功能的邏輯沒有很明確的文檔留存。

如你跟你的開發都是新接手系統沒多久，就收到的系統重構的任務。作為產品，你可以帶著你梳理的問題和初步假設去找研發，一起查詢了解問題部分的代碼邏輯，從而驗證自己的猜想，同時對齊你們的認知。

這個階段，要盡可能地打通對舊系統認知的盲區，就像解剖一樣，讓舊系統的骨架和筋脈在腦海中有清晰的認識。

與設計新系統不同，重構系統對兼容性要求高，你需要辯證的去思考每個模塊可優化的幅度和上限，在對原始功能、周邊系統、用戶習慣等多方兼顧的情況下，給出最優解。

因此，前期業務梳理時考慮的全面很重要，尤其是有流程改造時，我們不能只想到好的一面，也需要想到這次改變可能存在的風險和弊端是什么。

2. 用戶調研

除了你自己發現的要去改造的地方，真實的用戶需求是肯定要傾聽的。

用戶調研部分這里我采用了三種方式獲取信息：

1. 日常問題收集
2. 核心用戶訪談
3. 開放問卷調查

1）日常問題收集

收集日常工作中用戶反饋的系統問題，將問題歸納出來，分析高頻問題是不是可以通過改變產品設計來避免。

在舊系統維護期間，每天都很多用戶來找我問問題，如：進行中的任務出現異常、操作哪里走不通報錯了、或是不知怎么操作的咨詢問題。

這些一部分是產品架構設計的問題，一部分是產品交互設計的問題。一般這種情況都是反復出現的，如：今天A反饋給你了，你去找研發解決下；明天B反饋給你，你去找研發再解決下。

高頻的問題背后就是一個急需解決和重塑的核心痛點，這里雖然沒有被用戶明確提出來，甚至用戶已經習慣了這種“理所當然”的操作。但作為產品，你是需要清晰地認識到這里就是最有價值的需求點，也是顛覆老系統產品架構的突破點。

2）核心用戶訪談

針對部分核心用戶和業務方領導，約時間坐在一起聊一聊。

面對核心用戶，可以針對用戶遇到的問題有更深層次的了解，另外這也是一個很好的機會用于方案初步的溝通，可以問問他們對于你的改造思路有什么看法建議，這對于你在設計中優先級的把控很重要，看看自己和用戶最關注的重點有沒有偏差。

此外，與業務方領導也是有必要坐在一起聊一聊的，畢竟系統重構不僅僅是你們自己的事，也關乎于業務方工作效率的提升。你需要讓對方領導知道你的重構計劃，能為他們來怎樣的增益？最重要的，是當你無法判斷某種方案是否可行時，對方領導可以起到拍板的作用。

簡單來講一句話：多溝通，沒壞處。

3）開放問卷調查

收集問卷反饋。

經過上述的日常問題收集和核心用戶訪談，你能基本了解重構中需要改造的地方。

在此情況下我收集的問卷，80%的反饋已經在我預料之中了，但是我仍然建議大家要做這一步，原因有3點：

1. 獲取全量信息最快捷的方式，方便查漏補缺
2. 用戶增強參與感，自己的意見也可以被采納
3. 讓用戶提前知情，后期更好做用戶普及的推廣

問卷作為一種高效的信息收集渠道，不用就虧大了，它可以短時間獲取到所有用戶的對新系統的所有期望，從而可以按相同問題出現的頻率建立新需求開發的優先級，如高頻問題可以優先排期解決。

同時也可以讓用戶有一個心理預期，知道在不久的將來將使用新的系統，這樣像是提前打好招呼一樣，用戶在后期試用新系統的也會有更多的積極性。

3. 原型設計與評審

新系統的原型需要花費較長時間來完成，建議在開始畫原型之前，可以借助流程圖梳理邏輯，防止跑偏，或沉迷細節耽誤進度，保證你的思維的連貫性，因此效率也會更高。

此外建議第一版原型要更加認真對待，頁面布局、顏色，交互路徑等，能交代清楚就別一筆帶過。因為大多數情況，在正式開發前，都會拉一個大型評審會，邀請兩方領導和用戶代表共同參加，一個拿的出手的原型圖能為你在評審會上增加更多的信心。

建議在評審時，除了拿出設計方案和原型圖，還要提前準備好Q&A，也就是針對聽眾最關注的的地方，提前寫好問題和解決方法，為自己爭取更多的主動性，也會讓對方對你感到放心。

4. 首發版本上線前后

1）上線前

經過了專家原型評審，就可以進行后續正常的開發評審了。

在前期盡可能多跟你的研發團隊溝通對業務的看法，設計初衷是什么、希望解決什么問題，讓研發在開發過程中更多理解業務，減少因理解偏差出現的bug。

整個開發過程一般需要1月以上的時間，這段時間產品經理要做好項目進度管理的工作，至少做到按周統計進度，開進度會議。

如果這個項目高層領導比較關注，要定期發郵件給高層領導同步進度。

2）上線后

這里的上線可以分為兩種：內測版上線、對外正式版上線。

內測版上線流程走通后，可以邀請幾位種子用戶來體驗新系統，待用戶驗證核心流程跑通無誤后，可以對外宣布正式版上線了。

正式上線后，是1-2個月的試用階段，這個這段期間你需要讓更多的用戶試用新系統，及時暴露各種意想不到的問題，并快速進行迭代修復。

不過，用戶此時還在舊系統的使用習慣中，如何讓大家更多地試用新系統呢？這里我使用了三個小技巧：

1. 提供更快的觸達方式（如：免權限申請）
2. 提供用戶關心的試用福利（我這里是提供了一定測試量級給用戶）
3. 小窗口邀請用戶（我私聊了80+以上的用戶，邀請體驗新系統，并附上系統說明書）

當然在這段時間，你需要一邊關注用戶反饋，一邊規劃后續的任務，隨時把控時間和進度。

5. 功能迭代如何抉擇

可能大家都希望，新系統等把舊系統所有的功能都補齊了，再開始加用戶提的新功能。

起初我也這么想，但發現想要吸引用戶的關注，新功能效果最好。人都有好奇心，如果發現你有跟之前不一樣的新東西，會更加想去體驗和嘗試。

這一點，也是我與領導溝通后被點撥到的。

最好的辦法就是平衡舊功能與新功能的開發進度，前提要確定新功能的出現不會與未上線的舊功能有前后順序的嵌套。

比如這次我在重構時，考慮到我的用戶群體為各個地區的多個風控團隊，大家通常以組為單位去對接客戶。而老系統任務申請只能屬于一個人，小組成員無法合作。

在新系統中，我就在首發版本上線的第二個月加了「小組管理」的功能，組內成員互相都可以看到彼此的任務，也可以共享自己的工單數量，不光實現了組內任務靈活流轉，還實現了各團隊負責人對團隊內部成員工作量和工作內容的統計和把控。

這個功能本身與舊功能的沒有必要的嵌套邏輯，上線用戶的反饋非常好，驗證了之前的預期。這種新舊功能交替開發的思路，大家可以多思考下。

6. 過程中出了問題怎么辦

一般重構的系統上線后，都會收到用戶較好的反饋，畢竟舊系統年久失修，新的系統會讓人眼前一亮。這時候，產品經理容易沉浸在對新系統盡善盡美的幻想中，希望新系統的口碑一直保持完美，不允許有任何瑕疵。

然而，你無法避免問題的出現。

在新系統上線后的這段時間，確實是系統相對最不穩定的時期，需要不斷發現問題，修改問題。

作為產品經理，要學會理解新事物發展的規律，把解決問題和如何避免后續問題的發生放在思考的第一位。

下面三點，是我在走了一些彎路之后才明白的道理：

1. 對問題有包容心（出現問題不重要，重要的是如何解決和避免問題的發生）
2. 對開發有信心（與你的開發站在同一立場上，出現線上bug先給予解決問題的信任）
3. 對用戶有耐心（第一時間安撫用戶，誠懇道歉并說明解決時間）

我記得一個導演說過一句話：這個的片子如果成功了，那一定是大家的功勞；如果失敗了，那一定是我的責任。

產品經理并不是僅僅承擔產品設計的工作，更多的還要考慮團隊合作、項目管理等需要考驗軟實力的地方。

而問題矛盾的出現，會更加放大你在這些情況的心態和應對能力，要有大局意識，關建時候擔起項目負責人的責任，你的團隊成員才會更加信服你。

7. 數據同步和用戶遷移

新系統基本功能都與舊系統對齊了，是不是就可以將用戶全部直接切到新系統了？答案是否定的。

用戶遷移到新系統，絕對不能一刀切，要采用平穩過渡的方式，逐步替換。

因為老系統的數據都是這段時間用戶正在使用的，如果強制切到什么數據都沒有的新系統，用戶不炸毛才怪。

況且，我們這次項目分兩期，一期的目標是，在外部客戶無感知的情況下，內部用戶已經全部過渡到了新系統。

可能你會問：外部和內部數據互通的部分該怎么辦？如何保證之前在舊系統運行的流程？

答案就是——數據同步。

數據同步可以拆分為3部分：

1. 賬號同步——內部賬號和外部賬號由舊系統同步至新系統
2. 賬號關聯——新系統的內部賬號關聯舊系統的內部賬號
3. 文件同步——新舊系統產生的文件相互同步

第一步，賬號信息同步

由于外部客戶賬號創建的源頭來自上游CRM系統與舊系統的用戶創建，考慮客戶外部重構放在二期，故本期在此節點保持外部客戶賬號創建源頭不變，僅將客戶賬號、內部賬號及相關信息同步至新系統。

新系統增加「客戶賬號/內部賬號」模塊，用于替代舊系統后臺的用戶列表。存量數據批量刷進來，增量數據保持實時更新。

第二步，將新舊系統的內部賬號進行關聯

由于用戶都是同一個人，在注冊新系統后，他將擁有新系統和舊系統兩套賬號。

所以，管理員要將同一個內部用戶在新舊系統的兩個賬號進行關聯映射，保證下一步文件同步的穩步實施。

第三步，新舊系統的文件相互同步

為實現外部客戶無感知的內部用戶遷移，新舊系統的文件同步非常重要，也是保證無感知效果的關鍵。

首先確定同步范圍，這里有一個最大化和最小化原則。

• 舊系統同步新系統時要遵循最大化原則。即新系統要在未來替代舊系統，將舊系統產生的全部數據完整地同步至新系統，保證用戶所有在舊系統能查到的內容在新系統也能查到。
• 新系統同步舊系統要遵循最小化原則。即只同步還在舊系統的外部客戶需要看到的數據足夠。如果完全同步，不僅占用資源，還可能讓內部用戶無法脫離舊系統。

以上三步的完成，為后續的「用戶遷移」奠定了基礎。

最后，用戶遷移

因為業務流程的原因，需要客戶參與的任務，都會從CRM申請。因此用戶遷移的最后一步，就是聯合CRM將上游的任務從舊系統切換至新系統。因為前面已經做好關聯，所以CRM來的任務，都能在新系統的已關聯賬號看到。

這樣一來，用戶自然就會主動移步至新系統操作，同時近期產生的數據也能新系統都能查到，可以算是“無縫銜接”，不會給用戶造成來回切系統的困擾。

PS：在正式切換的前期要考慮更多的異常情況和應對機制。如：在正式上線前，我們采取了一段時間的手動切換，在驗證沒有問題后才決定上線切換。又如：當異常情況出現時，可手動將新系統的任務推回舊系統等等。

8. 小結

以上就是一期計劃里所有涉及重構的關鍵節點，可能不同業務不同系統之間會有不同，不過核心思路是相通的，都是遵循「平穩過渡」原則，盡可能減少用戶的學習成本、降低用戶的操作門檻，優化業務流程，提升用戶綜合體驗。

在用戶遷移至新系統后，老系統也不用立即關掉。給內部用戶一段時間的適應期，也能讓內部用戶將之前同步至老系統的任務做完，這樣會讓用戶對系統更有安全感。

四、分享和展望

1. 印象最深的兩件事

1）產品經理也可以看代碼

當時準備做自動生成風控分析報告，涉及風控領域專業知識，老系統對這個功能無文檔記錄，我跟開發都不清楚報告中的數值、比率的生成邏輯是什么。

唯一能參考的就是老系統用python寫的長達數十頁的代碼，由于需要結合業務知識和風控知識去理解，就算開發自己看也有困難，所以我選擇自己扒代碼。

我當時也是想試試，萬一能看懂了呢。后面經過認真的梳理，推導和驗證，花了兩天時間終于搞清楚了這里的邏輯，后面給開發講解的時候還是很有成就感的。

2）意外收獲的點贊

一次偶然發現，自己的一篇wiki被點贊了很多次，包括兩個部門的VP和一些不認識的人。

這篇文檔是我寫的一個風控策略產品的業務邏輯簡述，是別的部門在負責的平臺，因為我的系統即將接入策略產品接口，需要通過對方平臺做調用中轉，為了讓我的研發能明白風控策略的業務原理，我寫了一個科普性質的文檔給他們看，方便他們理解。沒想到最后竟然被那么多人看過，有些受寵若驚。

2. 未來要做的事

現在一期重構的進程已接近尾聲，這個項目已經完成了較為復雜的內部用戶遷移部分。實現了階段目標，即：內部使用端的重構和內部用戶的遷移。

待系統穩定運行3個月后，我們計劃開始二期的客戶使用端重構和用戶遷移。

相對內部重構，外部重構的難度會降低很多。因為外部客戶的操作步驟較內部少了很多，不涉及核心流程，且新系統的框架已經搭建完成，頁面無需重新設計，只需更換部分功能即可。

后續考慮的重點將是，“如何做到無感知或低感知的用戶切換”這個點了。

等二期項目完成時，會再跟大家分享經驗的，請大家期待。

作者：Fancy劉，現某金融科技公司B端產品經理。

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

題圖來自 Unsplash，基于CC0協議。