當(dāng)重構(gòu)不可避免發(fā)生的時候，產(chǎn)品經(jīng)理要弄清楚重構(gòu)的原因并在重構(gòu)之前做好準(zhǔn)備。

市場上的saas公司有一個很奇特的現(xiàn)象，要么打算開始重構(gòu)，要么已經(jīng)走在重構(gòu)的路上，似乎永遠脫離不了重構(gòu)的魔咒。

我當(dāng)時去丁香園的時候，主要就是為了去做整個系統(tǒng)的重構(gòu)（嚴(yán)格意義上來講應(yīng)該叫重做）。

一、為什么頻繁出現(xiàn)重構(gòu)？

在我看來，主要有以下3點關(guān)鍵原因。

1. 沒有考慮清楚業(yè)務(wù)發(fā)展軌跡

很多公司在剛創(chuàng)立之初，或者是業(yè)務(wù)線剛啟動之初，傾向粗放式發(fā)展，或者缺乏有體系的業(yè)務(wù)和產(chǎn)品規(guī)劃。什么是粗放式發(fā)展，就是說前期收到一個客戶需求，簡單判斷后，就開始設(shè)計并開發(fā)落地。

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

快就會意味著很多環(huán)節(jié)都缺乏足夠的分析和論證，很多決策會伴隨著大量拍腦袋式的主觀決定。

這樣的方式有好處、也有壞處，好處就是順應(yīng)了業(yè)務(wù)，業(yè)務(wù)需要你快速給她一個可商用的產(chǎn)品，可以直接解決客戶目前存在的問題，你在最短的時間內(nèi)做好并交付，非常靈活

壞處也很明顯，首先你做的產(chǎn)品只能對應(yīng)的解決現(xiàn)有的客戶需求；另外過于快速的前期產(chǎn)品設(shè)計調(diào)研過程也會驅(qū)使產(chǎn)品經(jīng)理弱視、甚至不去考慮產(chǎn)品未來會如何發(fā)展。

而隨著用戶需求在不久的未來不斷升級，且產(chǎn)品并沒有做好充足的可擴展性，就會發(fā)現(xiàn)現(xiàn)有的底層設(shè)計已經(jīng)無法滿足不斷發(fā)展的業(yè)務(wù)變化了。

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

很多時候，我們確實不知道未來業(yè)務(wù)會變成怎么樣，有經(jīng)驗的PM能想的更深一些，判斷的更準(zhǔn)確些，但是也不可能完全預(yù)料的一模一樣，因此無法因為這個原因完全避免重構(gòu)，但是我們可以通過前期對于業(yè)務(wù)未來發(fā)展的方向判斷，融入更多的可擴展性設(shè)計，減少因為這個原因所導(dǎo)致的重構(gòu)的可能性。

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

初期，考慮到盡快上線，采用創(chuàng)建活動頁直接集成這些設(shè)置項，然后一步到位創(chuàng)建活動，對用戶來說無疑是最便捷的，對開發(fā)來講也無疑是最簡單的。

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

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

這個時候開發(fā)就開始瘋狂了，原先的方案隨著業(yè)務(wù)的發(fā)展帶來巨大的迭代成本，前期因為沒有規(guī)劃好產(chǎn)品，導(dǎo)致制定的技術(shù)方案幾乎沒有任何可擴展性，最終只能靠重構(gòu)來徹底解決這個頑疾。

2. 產(chǎn)品功能設(shè)計問題

這是第二種比較高頻的情況，就是產(chǎn)品功能設(shè)計有問題導(dǎo)致的重構(gòu)

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

什么問題呢？

因為線下診所存在這樣的場景：一個醫(yī)生需要在多個科室進行看診，因此他的看診時間被多個科室占用著。也就是說當(dāng)用戶A預(yù)約了科室1的上午8點，那么用戶B就不能預(yù)約科室2（和科室1是同一個醫(yī)生）的上午8點了。

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

這在當(dāng)時其實是為了解決醫(yī)生時間沖突的問題而專門設(shè)計的一個產(chǎn)品功能。

雖然大致上解決了這個問題，但是因為引入了科室組，導(dǎo)致客戶在設(shè)置排班的時候操作更加復(fù)雜，理解難度也加大了，更不用說使用了（調(diào)研發(fā)現(xiàn)只有很少量客戶在用）

雖然需求存在，但是因為功能的不合理設(shè)計，導(dǎo)致用戶并沒有真正用起來。也就是說這樣一個剛需痛點并沒有很好的解決。因此對該功能進行重構(gòu)，就是當(dāng)務(wù)之急了。

再舉個例子：

產(chǎn)品經(jīng)理希望用戶在瀏覽商品列表頁的時候，能夠根據(jù)當(dāng)前用戶會員等級顯示相應(yīng)的會員價，導(dǎo)致了該頁面最終需要請求多個接口，而使得頁面加載異常的慢，在優(yōu)化了幾次后，也沒有明顯的改善。因此只能對該功能進行整體改造，這其實就是一次重構(gòu)，只不過規(guī)模和復(fù)雜度相對較低，算是一個小重構(gòu)。

3. 技術(shù)架構(gòu)問題

有些重構(gòu)，其實并不是產(chǎn)品層面的重構(gòu)，更多是技術(shù)層面的重構(gòu)。

1. 原先的底層表結(jié)構(gòu)設(shè)計，已經(jīng)無法滿足并實現(xiàn)新的功能，業(yè)務(wù)倒逼重構(gòu)
2. 原先的業(yè)務(wù)代碼過于耦合，導(dǎo)致后續(xù)的迭代成本不斷攀升
3. 還有就是原先代碼有很多缺陷的地方，比如編碼規(guī)范等，重構(gòu)是對代碼的完善
4. 原先開發(fā)人員的經(jīng)驗欠缺、業(yè)務(wù)分析不透徹，導(dǎo)致技術(shù)方案并不合理，優(yōu)化或者更換技術(shù)方案
5. 還有就是新技術(shù)、新框架的流行所帶來的代碼進化要求

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

對于saas產(chǎn)品來說，全站重構(gòu)更是一個大體量、高難度、系統(tǒng)化的活。可以說如果考慮的不夠透徹、準(zhǔn)備不夠充分、策略不夠合理，就可能把一次重構(gòu)變成一次災(zāi)難。

有的公司為什么給人感覺一直在重構(gòu)，很大概率是之前重構(gòu)完后，只用了1年，就又無法滿足新的業(yè)務(wù)需求了，怎么辦呢？再重構(gòu)。

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

那么作為一個重構(gòu)掌舵者，你該如何規(guī)劃好一次全站的系統(tǒng)重構(gòu)呢？

前期的準(zhǔn)備工作必不可少，沒有做好充足的調(diào)研和分析，注定又會是一場失敗之旅。

二、重構(gòu)前必要的準(zhǔn)備

1. 深度了解業(yè)務(wù)

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

先要了解行業(yè)、其次是你們在做的市場、然后了解你們公司自己的業(yè)務(wù)、最后則是產(chǎn)品和競品情況

了解這些后，有利于你回答以下幾個問題：

1）公司對于本業(yè)務(wù)在未來3年的發(fā)展思路和要求

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

3）從打造產(chǎn)品未來競爭優(yōu)勢角度，你會往什么方向進行產(chǎn)品迭代

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

因為他決定著產(chǎn)品架構(gòu)，進而決定了重構(gòu)的策略。

2. 深度接觸客戶

通過與客戶的一線訪談，觀察客戶工作情況，了解用戶的需求，以及他們對行業(yè)的看法和未來自身發(fā)展的計劃。

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

1）客戶在未來3年隨著自身的發(fā)展，更需要什么樣的產(chǎn)品

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

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

3. 要知道一些底層邏輯

1）你需要了解現(xiàn)有的產(chǎn)品設(shè)計邏輯

2）需要大致了解技術(shù)的底層設(shè)計

3）目前哪些功能存在較為嚴(yán)重的產(chǎn)品設(shè)計問題

下一期會講怎么如何評估需要重構(gòu)的程度，以及怎么設(shè)計重構(gòu)

#專欄作家#

司馬特小隊，公眾號：司馬特小分隊，人人都是產(chǎn)品經(jīng)理專欄作家。8年+互聯(lián)網(wǎng)資深產(chǎn)品經(jīng)驗，多年B端產(chǎn)品管理經(jīng)驗。具有多個從0到1的大型B端產(chǎn)品的孵化、重構(gòu)、迭代經(jīng)驗；主要教授產(chǎn)業(yè)互聯(lián)網(wǎng)產(chǎn)品相關(guān)的硬核知識點。

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

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