[[355134]]

 原來簡單提過這個話題，今天再相對深入的和大家探討下。中國目前絕大多數saas公司都是銷售驅動，客戶需求驅動，很難拒絕定制開發，很容易就做成項目了，除非有很強產品力和業務洞察力的團隊來做，否則慢慢的經過幾年積累，產品就會變得臃腫不堪。

產品一旦變的臃腫，就會碰到很多問題：

• 維護成本越來越高
• 用戶體驗越來越差
• 積累的客戶從資源變成繩索，調整的難度以及工作量越來越大。

這種情況下，應對一些市場新銳的競爭就很被動。而且體驗差了之后客戶會慢慢流失，團隊對此無能為力，從而陷入進退兩難的困境，這也是中國大多數B端產品企業的現狀。

現有產品上重構or另起爐灶新開發一套?這個時候，公司就面臨艱難的抉擇，基本上所有研發團隊都會建議另起爐灶，從研發角度這是更簡單，更高效的方式，不用管原來的惡心代碼，團隊士氣也會更高一些，但從公司的角度，更需要考慮幾個因素：

新系統的開發成本以及開發周期。

一套新的系統從開發到小部分客戶上線使用，再到成熟穩定，是需要相當長的打磨周期的。

老客戶的遷移成本。

這個成本包括在遷移過程中投入的BD、實施、培訓、售后成本，也包括客戶投入的成本。

在并行期間，涉及到一些bug或者需求，需要兩邊都開發的成本。

人員需要兩套班子，應對不同產品線，開發，實施，培訓，售后都需要兩套，招聘培養擴展的難度都會變大。另外兩條產品線之間產品還高度耦合，溝通工作量大。

一般來說，B端產品的遷移成本極高，客戶要改變使用習慣成本也極高。而且總有一些客戶不愿意遷移，最終不可避免的結局就是長期維護兩套系統。沒有經歷過的人是很難想象這樣的代價和成本的，遷移老客戶，老客戶勞筋動骨;不遷移老客戶，老客戶一定程度受忽視和傷害，影響口碑;

除非客戶非常少，或者可以基本保證比較低成本的全部遷移，筆者很不建議另起爐灶新開發一套，成本極大，除了所有的成本乘以2，還有遷移以及客戶那邊的成本，每一個客戶的遷移以及實施落地可能都是一個復雜的項目。

所以新開發一套相比在現有產品上重構，成本絕對是指數級的增大。很多公司這樣選擇后，陷入對新產品不夠滿意，老產品也遷移不過去的困境，浪費大量時間和資源，筆者鮮有發現成功案例。

那如果需要去庖丁解牛的重構一套系統，我們應該怎樣來做呢，筆者覺得可以參考以下思路以及原則：

1: 做好人的準備。

如同我以前一篇文章中說到的，人是事情成功與否的最關鍵要素。要做好庖丁解牛的工作，有幾個角色非常重要，數據庫架構師，解決方案架構師，功能架構師。不一定每個角色都需要一個人，但是一定要有人承擔對應的角色。比如說數據庫是B端產品的基石，一旦錯誤之后調整的成本非常高，數據庫架構師需要是懂數據庫設計技術，對業務發展、業務細節非常了解并有前瞻性的一個人或者多個人來協作。解決方案架構師實際也是需要是懂業務，并對技術有理解的一個人或者多個人。

B端產品是一個交叉學科，單一的懂業務，懂技術的人都相對好找。既理解業務，也理解技術，并且能夠有機結合的人比較難找，這種人目前在中國屬于稀缺資源。一般來說，這種交叉學科，技術的人去學習業務比業務的人學習技術要容易一些，公司內部要選擇合適的人往這個方向培養。

如果在短時間內很難有合適的人，也最好有一個外部的顧問來進行一定程度的把關。

2: 將理想的產品形態大致的設計出來。

要確定產品重構的路徑，需要將產品最終的大致架構，主要是功能架構，系統架構設計出來，另外確定一些核心業務設計的思路以及原則，反復打磨，才能得出比較滿意的答案。知道了終點大概是怎樣的，才能很好的思考最佳的前進路徑。

3: 做好重構優先級的選擇。

對于產品的重構來說，路徑以及優先級的選擇極其重要，能夠找到最合理，最省力的路徑是非常考驗團隊的，這里很難有一個固定的答案，但是有一些原則性的內容可以去遵循：

優先做好地基式的核心架構調整。

做重構最核心的是將數據庫架構，產品功能架構，頁面架構做正確。數據庫也好，功能也好，頁面架構也好，實際上就是找到最合理的方式，就是在用戶體驗以及產品的生長性之間找到平衡點。一般來說，讓用戶用足夠少的頁面看到足夠多關心的內容對于體驗是最好的，但是產品是生長的，架構分類沒有分好，最后功能或者頁面也會非常擁擠，不能擴展，所以需要找到體驗和生長性之間最佳的平衡點。

一些核心的數據庫表，核心的功能架構需要盡量優先的去調整，在錯誤的數據庫，錯誤的功能架構上做的內容都是無用功，還是要重新來過。

優先做好核心或者特別爛的功能的重構

一些高頻使用的核心模塊，或者特別爛的功能要優先去重構，這種重構對用戶的價值也是最大的，客戶有足夠的動力來進行配合。

優先做好新需求量大的模塊重構。

產品不是靜態的，我們在做產品重構的時候，一定會面臨外部大量的需求還在不斷的涌進來，對于新需求很多的功能模塊，與其在錯誤的功能基礎上面花大量的時間做新需求，還不如重新來做一下。實際上所謂的重構，很多時候都是一個個模塊，一個個功能進行重寫，將大的風險用敏捷，庖丁解牛的方式去分解掉。

4: 追求極致，不要重蹈覆轍，每次重構的機會都是一次重生的機會。

這個不用多說，每次重構一個模塊，都是一次重生的機會。我們不能用一個坑去填另外一個坑，至少要做到85分以上的設計才開始動手，不要一味的追求速度。

5: 盡最大努力的做減法，每一次成功的減法都是一次勝利。

對于臃腫系統的重構，在重構重寫過程中，一定要想盡一切辦法做減法。模塊的減法，功能的減法，甚至一個字段的顯示，一個檢索條件，減到極致，好的重構一定伴隨著大量的減法。

從客戶角度，每次重構之后的升級對于已經熟悉歷史系統的人來說，都是一次折磨，折磨的次數多了客戶是容易崩潰的。從用戶的體驗和口碑的角度，在迭代安排上面有如下的一些建議事項：

1: 每次迭代升級，讓客戶不斷的有甜頭可嘗。

每次迭代升級，重構后的新版本體驗需要大大超過原來的版本，或者有能夠解決客戶痛點的新功能，用戶才有動力升級。在設計安排每次迭代計劃的時候，要充分的考慮用戶升級的動力，否則會碰到很多阻力。

2: 遷移升級過程，盡量做到客戶無感知，免培訓，減少客戶的投入成本。

每次重構之后的升級經常會伴隨數據遷移，這個負擔不要給到客戶，實施團隊幫助客戶完成，另外每次重構后的功能要做到基本上不需要培訓，客戶也可以基本上不用投入實施培訓的成本。

3: 做好灰度測試，先要確認新的功能可行再進行全量的發布。

每次大的重構，都需要一定時間的灰度測試周期，讓一些典型客戶先將重構的模塊用一下，確保沒有問題之后再進行全量發布，這樣可以盡量少的折騰客戶。每一次折騰，都會帶來不信任以及后面的不配合，產品口碑變差。

4: 新客戶只開放必要的功能，減少后續遷移的成本。

這是一個小的tips，對于老產品中一些做的不好的非必要功能，在重構的過程中，通過權限處理，就不要開放給不斷增加的新客戶了，免得后面還增加遷移的成本。

重構很難;簡潔很難;人生很難;不過大部分人只有經歷過足夠多難題之后才能找到內心的從容，過好平淡的生活。