SaaS重構揭秘(1)：為什麼會出現重構？

市場上的saas公司有一個很奇特的現象，要麼打算開始重構，要麼已經走在重構的路上，似乎永遠脱離不了重構的魔咒。

我當時去丁香園的時候，主要就是為了去做整個系統的重構（嚴格意義上來講應該叫重做）。

一、為什麼頻繁出現重構？

在我看來，主要有以下3點關鍵原因。

1. 沒有考慮清楚業務發展軌跡

很多公司在剛創立之初，或者是業務線剛啓動之初，傾向粗放式發展，或者缺乏有體系的業務和產品規劃。什麼是粗放式發展，就是説前期收到一個客户需求，簡單判斷後，就開始設計並開發落地。

整個過程遵循的一個道理是快速、簡單、高效的落地，並投入市場。

快就會意味着很多環節都缺乏足夠的分析和論證，很多決策會伴隨着大量拍腦袋式的主觀決定。

這樣的方式有好處、也有壞處，好處就是順應了業務，業務需要你快速給她一個可商用的產品，可以直接解決客户目前存在的問題，你在最短的時間內做好並交付，非常靈活

壞處也很明顯，首先你做的產品只能對應的解決現有的客户需求；另外過於快速的前期產品設計調研過程也會驅使產品經理弱視、甚至不去考慮產品未來會如何發展。

而隨着用户需求在不久的未來不斷升級，且產品並沒有做好充足的可擴展性，就會發現現有的底層設計已經無法滿足不斷髮展的業務變化了。

這就像造房子，你當初為了造個小平房，打了個適合小平房的淺地基，結果蓋着蓋着，你蓋成了一座摩天大樓，毫無疑問這樣的地基是無法承載摩天大樓的，無疑只能推倒重來。

很多時候，我們確實不知道未來業務會變成怎麼樣，有經驗的PM能想的更深一些，判斷的更準確些，但是也不可能完全預料的一模一樣，因此無法因為這個原因完全避免重構，但是我們可以通過前期對於業務未來發展的方向判斷，融入更多的可擴展性設計，減少因為這個原因所導致的重構的可能性。

舉個例子，一個營銷活動，涉及到商品選擇、參加人員選擇、參加規則設置、獎品的設置、投放渠道設置。

初期，考慮到儘快上線，採用創建活動頁直接集成這些設置項，然後一步到位創建活動，對用户來説無疑是最便捷的，對開發來講也無疑是最簡單的。

但是隨着營銷活動的場景逐步增加，比如選擇商品的時候需要支持按照規格進行篩選；選擇參加人員的時候需要支持按照是否是會員進行篩選；投放渠道從原來1個渠道變成了3個渠道。

再比如當商品改動了某些屬性，那麼導致了營銷活動創建中也得改；會員增加了等級種類，那麼營銷活動創建中也得增加；投放渠道和活動規則集成在一起，每次增加一個新渠道，就得重新寫一遍活動創建。

這個時候開發就開始瘋狂了，原先的方案隨着業務的發展帶來巨大的迭代成本，前期因為沒有規劃好產品，導致制定的技術方案几乎沒有任何可擴展性，最終只能靠重構來徹底解決這個頑疾。

2. 產品功能設計問題

這是第二種比較高頻的情況，就是產品功能設計有問題導致的重構

比如：我們原來針對診所的預約系統，預約到科室維度，採用了科室組的概念，這是一個在線下沒有的概念，是之前產品為了解決一個問題而生造出來的概念。

什麼問題呢？

因為線下診所存在這樣的場景：一個醫生需要在多個科室進行看診，因此他的看診時間被多個科室佔用着。也就是説當用户A預約了科室1的上午8點，那麼用户B就不能預約科室2（和科室1是同一個醫生）的上午8點了。

所以為了解決這個問題，把科室1和科室2進行打包，設置成一個科室組，同時設置科室組的開放預約時間段。那麼可以針對科室組進行預約。

這在當時其實是為了解決醫生時間衝突的問題而專門設計的一個產品功能。

雖然大致上解決了這個問題，但是因為引入了科室組，導致客户在設置排班的時候操作更加複雜，理解難度也加大了，更不用説使用了（調研發現只有很少量客户在用）

雖然需求存在，但是因為功能的不合理設計，導致用户並沒有真正用起來。也就是説這樣一個剛需痛點並沒有很好的解決。因此對該功能進行重構，就是當務之急了。

再舉個例子：

產品經理希望用户在瀏覽商品列表頁的時候，能夠根據當前用户會員等級顯示相應的會員價，導致了該頁面最終需要請求多個接口，而使得頁面加載異常的慢，在優化了幾次後，也沒有明顯的改善。因此只能對該功能進行整體改造，這其實就是一次重構，只不過規模和複雜度相對較低，算是一個小重構。

3. 技術架構問題

有些重構，其實並不是產品層面的重構，更多是技術層面的重構。

1. 原先的底層表結構設計，已經無法滿足並實現新的功能，業務倒逼重構
2. 原先的業務代碼過於耦合，導致後續的迭代成本不斷攀升
3. 還有就是原先代碼有很多缺陷的地方，比如編碼規範等，重構是對代碼的完善
4. 原先開發人員的經驗欠缺、業務分析不透徹，導致技術方案並不合理，優化或者更換技術方案
5. 還有就是新技術、新框架的流行所帶來的代碼進化要求

這三類問題幾乎每家公司都遇到的問題，而且不只是產品問題，更多的是管理上的問題和人的問題。

對於saas產品來説，全站重構更是一個大體量、高難度、系統化的活。可以説如果考慮的不夠透徹、準備不夠充分、策略不夠合理，就可能把一次重構變成一次災難。

有的公司為什麼給人感覺一直在重構，很大概率是之前重構完後，只用了1年，就又無法滿足新的業務需求了，怎麼辦呢？再重構。

一次糟糕的重構既耗費了大量人力物力，也錯失了市場的時間窗口，更會帶來數不盡的坑，進而需要二次重構、三次重構來填坑，不誇張的説，很多公司是被重構耗死的。

那麼作為一個重構掌舵者，你該如何規劃好一次全站的系統重構呢？

前期的準備工作必不可少，沒有做好充足的調研和分析，註定又會是一場失敗之旅。

二、重構前必要的準備1. 深度瞭解業務

這個我在之前分享過好幾次了。

先要了解行業、其次是你們在做的市場、然後瞭解你們公司自己的業務、最後則是產品和競品情況

瞭解這些後，有利於你回答以下幾個問題：

1）公司對於本業務在未來3年的發展思路和要求

2）哪些功能相比競品存在較大的落後和不足

3）從打造產品未來競爭優勢角度，你會往什麼方向進行產品迭代

這幾個問題的答案就是為了搞清楚你的產品的主體功能和主流程是否在未來一段時間內會有較大的變化，以及怎麼變？

因為他決定着產品架構，進而決定了重構的策略。

2. 深度接觸客户

通過與客户的一線訪談，觀察客户工作情況，瞭解用户的需求，以及他們對行業的看法和未來自身發展的計劃。

你需要回答以下幾個問題：

1）客户在未來3年隨着自身的發展，更需要什麼樣的產品

2）客户目前使用產品過程中遇到的所有影響使用、功能無法滿足的問題

3）客户對於其他競品中覺得非常好的功能的推薦

3. 要知道一些底層邏輯

1）你需要了解現有的產品設計邏輯

2）需要大致瞭解技術的底層設計

3）目前哪些功能存在較為嚴重的產品設計問題

下一期會講怎麼如何評估需要重構的程度，以及怎麼設計重構

#專欄作家#

司馬特小隊，公眾號：司馬特小分隊，人人都是產品經理專欄作家。8年 互聯網資深產品經驗，多年B端產品管理經驗。具有多個從0到1的大型B端產品的孵化、重構、迭代經驗；主要教授產業互聯網產品相關的硬核知識點。

本文原創發佈於人人都是產品經理，未經許可，禁止轉載

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