本次會員新課我們邀請到了前釘釘高級產品經理@周翔老師，作為7年B端產品人，具有豐富的從0~N、產品重構的成功經驗，對B端產品有著深刻的理解和豐富的實戰經驗，沉淀出系統的B端產品方法論。本文由課程內容整理，內容有刪改。

大家好，我是周翔，曾在釘釘任過高級產品經理，現在某知名獨角獸公司做資深B端產品經理，有著豐富的B端產品從0到N及重構經驗。

本次分享主要分為四部分：第一部分是為什么要講B端產品的重構；第二部分是系統重構的三種類型；第三部分是本次分享的核心內容，即B端產品重構的九大步驟；第四部分是分享在重構過程中應注意哪些點，以及在重構過程中的個人思考和主要感悟。

一、為什么要講系統重構？

本次分享重構的原因主要有三個：

第一、重構在B端產品中十分常見，因為有很多軟件系統已在公司運行很長時間，尤其在成立時間比較長的公司，通常都會有運營時間比較長的產品，但隨著業務的發展，很多原本的設計或邏輯已不能滿足現在新業務的訴求，這時就會產生重構的訴求。

第二、對產品經理來講，重構比從0到1更具有挑戰性，因為重構可能需要從-1甚至-N來變成1。

第三、重構是產品能力的進階，當掌握好重構方法后，再去應對從0-1時，就會更加游刃有余，屬于降維操作。

二、系統重構的三種類型

第一種類型是保留原來的系統地基，然后重建上層建筑，即在原系統基礎上重新開發，保留或加固系統原有的底層架構、數據庫，僅對上層代碼包括業務邏輯、頁面交互等部分重新開發。

第二種類型是另起爐灶，即原系統繼續保持運行，另起新的項目，重新做個新系統替換，然后再做數據的遷移；該類型模式在重構中很常見，也是B端產品重構方法中重點提及的一種方式。

第三種類型是在運行中改造，即保持現有的系統持續、穩定運行的情況下，同時對所需要的模塊進行持續性的重構，直至達到系統重構的最終目標。

3種重構方式的對比：

第一、從形式上看，第一種方式是保留地基，重建上層建筑；第二種方式是另起爐灶；第三種是在運行中改造。

第二、適用場景，第一種方式適用于原系統已決定被廢棄或即將廢棄，不需要再繼續維護，但還需保留部分數據；第二種方式適用于原系統的業務仍需要持續運行，且對新系統有較充足的等待時間；第三種方式適用于原系統業務需要持續運行，只需要優化部分模塊，不需要對整個系統進行徹底的重構。

第三、優勢和不足，第一種方式的歷史包袱較小，重構速度也相對更快，但是場景會比較局限；第二種方式相比于方式三，歷史包袱較小，重構時間也更快、成本更低，但是不足之處在于一方面用戶遷移幅度大，沒有過渡期適應，當用戶從老系統遷移到新系統時會產生非常大的不適感，特別對SaaS或商業化產品會有較大風險，用戶會逐步用腳投票從而棄用原來的產品。

另一方面是風險高，因為缺少中間驗證的過程，直接讓用戶使用新系統，對最終結果比較難控制；第三種方式的優勢在于用戶可以逐步接受改造，有較平緩的過渡期，還可以通過小步快跑或迭代的方式逐步驗證和優化，風險較小。不足之處一是歷史包袱沉重，因為在原有的舊系統基礎上改造需要考慮更多，而且在用戶側還保留著之前的使用習慣。

二是依賴、關聯的影響更多，因為改變的只是其中的某個模塊，需要牽扯到現有、已實現的部分功能；三是部分場景需要同時兼容新、舊兩套邏輯，從而增加很多額外、非必要的成本；四是部分功能會存在過渡期，但實際上會有重復的工作量，增加額外成本。

第四、綜合成本的高低總體是方式1<方式2<方式3。

綜上，方式一是在原系統打算或已經廢棄的時候才適用，而這種情況其實比較少，更多時候所面臨的重構場景是在方式二、三中選擇。

從業務方和領導們的角度出發，通常都會傾向于方式三，因為風險更小，感覺上成本也更低，但實際上如果需要改造的模塊較多，方式三的成本其實會更高，因為會有很多兼容、填坑、還技術債的事情；而從產研的角度，通常傾向方式二，因為不用考慮過多的歷史包袱，處理起來更方便，如果需要改造的內容較多，綜合成本也會更小。

但無論采用哪種方式，都需要結合現狀以及公司對于產品的要求綜合決定。

三、系統重構的九大步驟

系統的重構可以分為九大步驟：

• 第一步是需要做大量的前期調研；
• 第二步是需要對現有的舊邏輯做系統性梳理；
• 第三步是需要把需求和舊邏輯做對比分析；
• 第四步是需要對前期收到的問題或需求進行整理和分層；
• 第五步是需要基于前面的信息明確最終的重構目標，以及衡量最終重構目標的指標；
• 第六步是需要分析優先級，分析完后會有對應的模塊優先順序；
• 第七步是需要基于具體的模塊做更加詳盡和針對性的調研；
• 第八步是需要基于調研結果制定和實施優化策略；
• 第九步是需要在上述步驟完成后，處理大量的歷史數據。

當完成以上步驟后，就可以形成整個系統重構步驟的閉環，然后不斷地在下一步的行為中推進。

第一步：前期調研

前期調研主要分成業務調研和用戶調研。

其中業務調研需要了解兩部分內容：

一是業務所在行業的通用玩法，知道行業內一般都是怎么運作的，需要有行業認識，這部分也作為指導整個系統運行的核心業務知識和體系。

二是需要了解公司的整體業務流程、業務特色和形成的歷史淵源，其中需注意的是行業通用性和公司的不同之處，一旦忽略就容易在后面改造中照搬行業玩法，導致與實際業務需求不符，因此無論行業在做相關業務時的操作如何，都需要注意公司是否有限制或條件要求。

而用戶調研則主要分為三大類用戶：

第一類是干系人，主要側重于在系統中對產品有決定性作用的人，比如業務領導或對系統相關有決策權的領導層，這類人群可能對具體的功能不是太關心，甚至都不是最終用戶，卻對產品有著關鍵性的決策作用，所以對這類人群需要優先做調研，了解其對最終的重構結果有怎樣的預期，需要結合這些預期做后面的行為。

第二類是典型用戶，是指有具體產品操作的用戶，對該類人群需要做用戶分群，因為在B端產品中，不同的用戶群體訴求完全不相同，甚至于完全沖突，所以需要基于不同的用戶群體區分的維度做劃分。比如在B端產品中，不同的管理層級的訴求差異較大，基層員工對工具的訴求和管理層對工具的訴求完全不同，這時就可以基于管理層級做劃分。

再比如按照部門或業務線、產品線的維度做劃分，因為不同產品線、業務線的訴求也不相同，所以可以在找到幾個核心的維度后，再對用戶群體做多維切割，切割完后就可以得到不同群體，得到群體后，再從中挑選不同群體的典型用戶做1V1的深度訪談。

第三類是普通用戶，即除了典型用戶外，還需要對普通用戶做調研，這時可以通過問卷方式做大批量的問題收集和需求收集，了解普通用戶通用或較高頻的痛點。

在完成上述兩大類調研后，就需要輸出對應內容，主要包括公司業務流程、業務特色總結形成的文檔記錄、各角色用例圖、用戶調研報告、用戶體驗地圖和用戶問題/需求池。

第二步：舊邏輯梳理

梳理內容主要包括系統現有主流程的產品架構和產品結構，此處需注意，架構和結構屬于兩種類型的東西，很多人容易混淆；當梳理好產品架構和結構后，就需要梳理具體的功能模塊；再往下是細節的功能點具體的邏輯，基于此，通過由上到下逐級細化的過程，逐步梳理清楚舊邏輯。

當梳理完后，在結果上就會有四個呈現：一是產品的主流程圖，二是產品架構圖，三是產品結構圖（腦圖），四是通過表格整理的各模塊功能邏輯清單。尤其對復雜系統而言，清單是必不可少的工作量，因為在前期時B端會有很多的復雜邏輯，如果沒有清單記錄，到了后期時就容易出現遺漏的情況，從而影響到開發節奏。

第三步：對比分析

當了解清楚業務和用戶痛點、需求、業務現狀和系統現有規則后，就可以對這兩部分進行對比，通過對比即可發現業務實際需求和現有規則的缺口在哪里，比如業務有需求A，但實際系統規則實現的卻是需求B，基于對比可以發現很多新問題和新功能缺口，而這些都是在前期調研時，用戶出于遺忘或沒有意識到等原因而沒有反饋，但通過對比分析可以得出。

另外需要結合業務規則來判斷舊系統規則的合理性，很多同學會直接基于原有經驗或競品的處理方式，強硬判斷老系統規則是否合理，但實際上這種判斷方式有很嚴重的問題，因為原有系統的設計邏輯之所以如此，很大概率都是為了迎合當時的業務訴求或有很多業務限制條件在里面。

所以在第三步時就需要把這部分規則梳理出來，避免在后續改造時把不應該改的地方給改了，這也是第三步對比分析中重要目的之一。在對比完成后就可以輸出最終的系統現存問題清單，在輸出清單后，就可以和第一步中的用戶問題需求池相結合，從而得到最終系統或老系統現有問題的大池子，即需要一一去解決的內容。

第四步：問題/需求整理與分層

如果每個問題都需要解決，大部分同學在看到大池子的問題時都會頭皮發麻，比如之前在進入某家公司做產品重構時，一進去已有100多條需求的文檔在等著，再加上后期調研時的需求不斷累加，最終形成了三四百條需求的文檔，這無疑工作量很大，所以需要對問題和需求進行整理。

整理可以從三個方面入手：

一是按照功能模塊進行歸納。

二是需要把重復問題或需求進行合并，因為有時同個問題會有不同人基于不同角度去反饋，在合并問題或需求的過程中，需要對反饋同個問題或需求的人數做記錄，因為反饋人數可以代表痛點的普遍性，對于后續分析優先級時非常有幫助。

三是需要把明顯不合理的問題或需求刪掉，因為有很多用戶的反饋比較局限，因其并不清楚業務的要求或管理上的要求就是這樣，所以對于這種明顯不合理的問題，可以直接做刪除處理。

問題或需求需要按照以下5個層次劃分：

• 第一、最底層是數據層，比較常見的比如數據混亂、不統一、來源不一致等問題。
• 第二、模型層，是指與產品設計的底層模型相關的問題，而作為B端產品經理，都需要掌握關于底層模型設計的知識。
• 第三、領域層，又稱為業務邏輯層，即常見的各類業務邏輯問題。
• 第四、交互層，主要是指頁面的交互問題，比如菜單結構、頁面/操作流程、控件等，這是很多介紹產品重構方法時比較集中的地方，但實際上的問題或需要重構的地方遠不止這一層的內容。
• 第五、UI層，屬于純視覺問題，比如icon語義、樣式、頁面布局等。

在重構時，除了需要清楚重構的目標，更重要的點是還需要知道在重構時可能會產生的關聯影響，這也是對所有問題進行分層的原因。因為在原有系統上做重構時會有很多已有邏輯，不能出現改了一個問題卻引發剩下的10個問題或10個BUG的情況，這在重構中需要極力避免。

分析關聯性最為常見的方式是通過模塊之間的橫向關聯和縱向關聯去分析，比如分析出A模塊和B模塊之間的橫向關聯有哪些，縱向關聯是指在頁面上看到的某個問題，比如數據顯示不對，這不僅是純交互層的問題，還會往下涉及到數據層或其他層級，可能業務邏輯出現問題所以導致頁面上展示的數據不對，需要一層層去分析。

故問題分層實際上是需要做縱向關聯的分析，因為表面看到的問題會涉及到不同層級，而不同層級需要解決的問題或成本時間完全不一樣。

分層的價值主要有兩個：一是通過橫向、縱向的關聯，更容易分析出影響面；二是不同層級的改造成本都不相同，通常都是由上到下的成本逐漸增加，策略則是從左到右。

比如之前需要調整對象的狀態機，最開始以為是操作邏輯即領域層的問題，但在往下分析時才發現，真正的原因在于原有的底層模型設計不合理，從而導致上層業務邏輯的不合理，這時就會涉及到改動模型層，就會牽扯到原有數據的調整，這是非常典型的表象問題。

第五步：明確重構目標和指標

第六步：分析優先級

第七步：模塊調研

第八步：設計、實施優化方案

第九步：歷史數據處理

四、系統重構的Tips

在接下來的部分，周翔老師講解了第五步-第九步的詳細做法，以及在最后根據自己的經驗分享了幾個系統重構時的Tips。

囿于篇幅有限，想要觀看完整視頻的朋友可掃描下方二維碼添加會員學習顧問@betty老師的微信，并備注“周翔”，即可獲得觀看鏈接。

五、三月會員新課回顧

本次會員新課，周翔老師為我們詳細講解了B端產品如何進行系統重構，希望大家都能有所收獲~

起點課堂會員全年將圍繞12大電商/B端/SaaS/運營等主題，全年共計更新48門新課，邀請一線的互聯網產品、運營實戰派專家，與大家分享最新的產品行業動態、運營玩法和干貨知識。