編輯導語：近幾年很多企業(yè)開始做SaaS產(chǎn)品，但是一些企業(yè)的產(chǎn)品經(jīng)過多年的需求驅(qū)動積累，就會變的比較難以推動，產(chǎn)品也會陷入兩難的地步；這時候是選擇重構(gòu)還是重新開發(fā)？本文作者分享了如何解救一款難以持續(xù)的SaaS產(chǎn)品，我們一起來學習一下。

原來簡單提過這個話題，今天再相對深入的和大家探討下。

中國目前絕大多數(shù)saas公司都是銷售驅(qū)動，客戶需求驅(qū)動，很難拒絕定制開發(fā)，很容易就做成項目了；除非有很強產(chǎn)品力和業(yè)務(wù)洞察力的團隊來做，否則慢慢的經(jīng)過幾年積累，產(chǎn)品就會變得臃腫不堪。

產(chǎn)品一旦變的臃腫，就會碰到很多問題：

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

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

現(xiàn)有產(chǎn)品上重構(gòu)or另起爐灶新開發(fā)一套？

這個時候，公司就面臨艱難的抉擇，基本上所有研發(fā)團隊都會建議另起爐灶，從研發(fā)角度這是更簡單、更高效的方式；不用管原來的惡心代碼，團隊士氣也會更高一些。

但從公司的角度，更需要考慮幾個因素：

1）新系統(tǒng)的開發(fā)成本以及開發(fā)周期：一套新的系統(tǒng)從開發(fā)到小部分客戶上線使用，再到成熟穩(wěn)定，是需要相當長的打磨周期的。

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

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

4）人員需要兩套班子，應對不同產(chǎn)品線，開發(fā)、實施、培訓、售后都需要兩套，招聘培養(yǎng)擴展的難度都會變大；另外兩條產(chǎn)品線之間產(chǎn)品還高度耦合，溝通工作量大。

一般來說，B端產(chǎn)品的遷移成本極高，客戶要改變使用習慣成本也極高；而且總有一些客戶不愿意遷移，最終不可避免的結(jié)局就是長期維護兩套系統(tǒng)。

沒有經(jīng)歷過的人是很難想象這樣的代價和成本的，遷移老客戶，老客戶勞筋動骨；不遷移老客戶，老客戶一定程度受忽視和傷害，影響口碑。

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

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

一、重構(gòu)的思路以及原則

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

1. 做好人的準備

如同我以前一篇文章中說到的，人是事情成功與否的最關(guān)鍵要素。

要做好庖丁解牛的工作，有幾個角色非常重要，數(shù)據(jù)庫架構(gòu)師、解決方案架構(gòu)師、功能架構(gòu)師。

不一定每個角色都需要一個人，但是一定要有人承擔對應的角色；比如說數(shù)據(jù)庫是B端產(chǎn)品的基石，一旦錯誤之后調(diào)整的成本非常高，數(shù)據(jù)庫架構(gòu)師需要是懂數(shù)據(jù)庫設(shè)計技術(shù)，對業(yè)務(wù)發(fā)展、業(yè)務(wù)細節(jié)非常了解，并有前瞻性的一個人或者多個人來協(xié)作；解決方案架構(gòu)師實際也是需要是懂業(yè)務(wù)，并對技術(shù)有理解的一個人或者多個人。

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

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

2. 將理想的產(chǎn)品形態(tài)大致的設(shè)計出來

要確定產(chǎn)品重構(gòu)的路徑，需要將產(chǎn)品最終的大致架構(gòu)，主要是功能架構(gòu)、系統(tǒng)架構(gòu)設(shè)計出來；另外確定一些核心業(yè)務(wù)設(shè)計的思路以及原則，反復打磨，才能得出比較滿意的答案。

知道了終點大概是怎樣的，才能很好的思考最佳的前進路徑。

3. 做好重構(gòu)優(yōu)先級的選擇

對于產(chǎn)品的重構(gòu)來說，路徑以及優(yōu)先級的選擇極其重要，能夠找到最合理，最省力的路徑是非常考驗團隊的。

這里很難有一個固定的答案，但是有一些原則性的內(nèi)容可以去遵循：

1）優(yōu)先做好地基式的核心架構(gòu)調(diào)整

做重構(gòu)最核心的是將數(shù)據(jù)庫架構(gòu)、產(chǎn)品功能架構(gòu)、頁面架構(gòu)做正確；數(shù)據(jù)庫也好，功能也好，頁面架構(gòu)也好，實際上就是找到最合理的方式，就是在用戶體驗以及產(chǎn)品的生長性之間找到平衡點。

一般來說，讓用戶用足夠少的頁面看到足夠多關(guān)心的內(nèi)容對于體驗是最好的；但是產(chǎn)品是生長的，架構(gòu)分類沒有分好，最后功能或者頁面也會非常擁擠，不能擴展，所以需要找到體驗和生長性之間最佳的平衡點。

一些核心的數(shù)據(jù)庫表，核心的功能架構(gòu)需要盡量優(yōu)先的去調(diào)整，在錯誤的數(shù)據(jù)庫，錯誤的功能架構(gòu)上做的內(nèi)容都是無用功，還是要重新來過。

2）優(yōu)先做好核心或者特別爛的功能的重構(gòu)

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

3）優(yōu)先做好新需求量大的模塊重構(gòu)

產(chǎn)品不是靜態(tài)的，我們在做產(chǎn)品重構(gòu)的時候，一定會面臨外部大量的需求還在不斷的涌進來；對于新需求很多的功能模塊，與其在錯誤的功能基礎(chǔ)上面花大量的時間做新需求，還不如重新來做一下。

實際上所謂的重構(gòu)，很多時候都是一個個模塊，一個個功能進行重寫，將大的風險用敏捷，庖丁解牛的方式去分解掉。

4. 追求極致，不要重蹈覆轍，每次重構(gòu)的機會都是一次重生的機會

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

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

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

二、建議事項

從客戶角度，每次重構(gòu)之后的升級對于已經(jīng)熟悉歷史系統(tǒng)的人來說，都是一次折磨，折磨的次數(shù)多了客戶是容易崩潰的。

從用戶的體驗和口碑的角度，在迭代安排上面有如下的一些建議事項：

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

每次迭代升級，重構(gòu)后的新版本體驗需要大大超過原來的版本，或者有能夠解決客戶痛點的新功能，用戶才有動力升級。

在設(shè)計安排每次迭代計劃的時候，要充分的考慮用戶升級的動力，否則會碰到很多阻力。

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

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

3. 做好灰度測試，先要確認新的功能可行再進行全量的發(fā)布

每次大的重構(gòu)，都需要一定時間的灰度測試周期，讓一些典型客戶先將重構(gòu)的模塊用一下，確保沒有問題之后再進行全量發(fā)布，這樣可以盡量少的折騰客戶。

每一次折騰，都會帶來不信任以及后面的不配合，產(chǎn)品口碑變差。

4. 新客戶只開放必要的功能，減少后續(xù)遷移的成本

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

#專欄作家#

作者：李東林（微信公眾號：SaaS產(chǎn)品說；微信號：jianguzhuxin），菜小秘聯(lián)合創(chuàng)始人，原ADP大中華區(qū)產(chǎn)品負責人，14年To B研發(fā)與產(chǎn)品設(shè)計，團隊管理經(jīng)驗，主導過多款大型企業(yè)管理軟件的設(shè)計、研發(fā)、上線，也有過數(shù)年移動互聯(lián)網(wǎng)TO C的創(chuàng)業(yè)經(jīng)驗。

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

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