如果產品的架構不良，或者業務的方向發生了變化，這時就需要對產品進行重構。本文作者在一次產品重構之旅中，收獲了一些經驗，有了飛速成長，遂將本次產品重構經歷和經驗進行分享，希望能給你帶來幫助。

文章導讀：

• 通常意義上講，一個產品為什么要重構？
• 我們團隊的產品為何要重構？
• 重構的目標是什么？
• 最終結果如何？
• 我是如何做的？
• 過程中遇到了哪些問題？分別是如何解決的？
• 收獲與成長
• 最后談一下 0-1與產品重構哪個難？哪個易？

這次產品重構之旅，是我在漫漫產品路上，接觸到的第一次關于“重構”的實踐，收獲了頗多經驗，個人也因此在這4個多月中，有了飛速的成長，遂將本次產品重構經歷和經驗進行分享，以期幫助到有類似“重構”任務或有著“重構困惑”的產品er們。

01 通常意義上講，一個產品為什么要重構？

先引用《業務中臺產品搭建指南：電商業務平臺全流程設計與實戰》一書中，作者關于重構的原因及必要性的解讀：

每個系統的誕生都源于業務需要，為了能夠支撐飛速發展的業務，很多時候我們需對多個方案進行一些妥協來贏取時間。方案的妥協往往會造成架構不良，只能滿足中短期需求，對于長期的延伸都有致命的傷害。

還有一種情況是業務的方向發生了變化或者融合，導致原有設計的結構需要進行重新設計調整。

如果把一個系統看作是一個人，那么人身體里面的骨骼、血肉就可以看作是系統的邏輯和技術架構，它們支撐著身體的穩定運行。而產品架構的邏輯和規則，則代表著這個人的精氣神和性格，一個人身體再好，精氣神如果不順暢，身體早晚也會出問題。

所以每次重構既是對這身體的血肉和骨骼進行大刀闊斧的改造外，也需要對它的精氣神和性格做重新的審視和定位。

結合我本次重構的經歷來看，無不印證了上述書中作者的觀點和看法。

1）我新加入的產品團隊，組建時間不算短不算長，一年左右，為了滿足團隊初期的生存和發展，會承接一些商業化項目，基本上都是定制的，因此在架構設計上，也僅最大程度上考慮了多個項目的復用性，沒有考慮“產品化”。

舉個架構不良的例子（真實例子）：

團隊前臺產品（姑且叫做產品吧，實際是為幾個商業化項目建的業務應用系統）運轉用到的后臺系統有：采集系統、數據治理與融合系統、信源管理系統（現在重構后的名字，之前的產品名字與產品功能極度不符）、工單管理系統、掃描系統等等。

其中“信源管理系統”的定位是用于運營和管理各類信源數據的，即增刪改查和打各類標簽用的。但是，在給各個前臺應用使用數據時，卻僅將采集到的數據經過【AI模型】打標后，直接給到業務去用，完全沒有 采納“信源管理系統”的“運營管理成果”，信源管理系統用的數據與客戶業務系統用的數據，是兩份孤立的數據島嶼。

很顯然，這是極度不合理的業務架構設計。

如果不及早解決，任由這樣的態勢發展下去，很難想象團隊會在多久的將來，會因為這些問題“over”，幾個月？一年？——但可以明確預見的是：如果不解決這些問題，團隊的資源將永遠都不夠、團隊也將無法拓展更多新的業務，因為忙著修修補補每一個孤島上“零零散散的部件”。

2）團隊此前有一個標品，但是是試水的v0.1產品，只有1個在線系統，沒有產品需求文檔、沒有產品使用手冊、沒有技術設計文檔，也沒有什么人維護了。

02 我們團隊的產品為何進行重構？

讀完上面我舉的例子，換作任何一個產品經理/技術都不能忍受吧，鑒于那么多問題，所以我們需要重構。再總結一下，我們團隊的產品為何進行重構：

1. 技術架構上有諸多問題，如后臺各系統邊界不清晰、數據是孤島、無標準化前臺產品等；
2. 團隊此前標品沒有人運營維護了，且文檔資料缺失。
3. 團隊核心業務發展的需要。需要整合幾個核心業務系統（為項目做的）為一個“一體化平臺”，重新進行產品定位、打造標品并持續迭代，并努力成為行業內標桿產品。

03 重構的目標是什么？

——棄糟粕、取精華，對產品重新定位。包括產品目標行業與目標客戶、產品形態、產品商業模式、產品價值主張的重新明確，產品架構和技術架構的重新調整和設計，以重塑產品的骨骼和血肉，讓產品恢復精氣神兒，讓產品可以解決客戶問題的同時為團隊“掙錢”。

本次產品重構的目標，是基于當時團隊的業務背景需要，分成了幾個階段，每個階段有著不同的目標：

• 階段一：重新明確產品定位，設計產品業務架構，整合三個不同的業務應用（但業務流程及業務邏輯基本相同）至一個“一體化平臺”中，共用一套后臺系統，通過各類權限配置為不同類型的客戶及用戶提供產品服務。
• 階段二：優化線上系統邏輯漏洞、功能優化完善，提高用戶使用體驗。
• 階段三：重新設計后臺產品架構，厘清各系統職責和邊界，并分版本分別重構有問題的后臺系統。
• 階段四：隨業務發展，再將各個系統中的一些功能模塊剝離出去，形成單個子系統運轉。

比如后續可將采集系統中的采集優先級判斷、采集狀態的管理從“采集系統”中剝離出去，形成“采集調度模塊”，而采集系統僅做采集的執行，這樣整體的業務邏輯就會清晰很多。

再比如將積分規則設置、積分分配、積分管理等從用戶管理中剝離出去，形成單獨的“積分管理系統”，這樣也會減輕用戶管理的負擔。

為什么這樣劃分產品重構的階段？

——在當時，我不能特別領悟為何要這樣劃分。只是按照老板的大致意思那樣去做了。

甚至現在，團隊研發在做后臺系統重構時還在說：“XXX后臺系統本就該優先重構，然后再重構前臺業務系統！現在都是反的~”

但真的是研發說的這樣嗎？

現在回過頭來看，我想我理解了按上述節奏和周期去劃分工作的原因：

1）為了維持團隊業務的生存和發展，所以需響應市場需求、響應客戶需求。

有市場需求了，有客戶需求了，就需要趕快出客戶用戶“可見的”東西（產品v1.0），后臺亂成怎么樣，客戶和用戶看不到。

2）為了占據客戶及用戶心智，所以要不斷打磨產品，讓用戶看得見我們的變化。

后臺不急著重構，原因是：在產品初期，占據客戶及用戶心智是很重要的，因此“俘獲用戶芳心的新功能” 與 后臺優化的需求相比，仍是“俘獲用戶芳心”的功能更重要。

3）等業務運轉起來，且用戶沒有其它顯著的使用問題后，再花時間和精力好好優化后臺系統。千萬要注意，后臺的優化升級，不能影響到線上正常使用。

如遇其它重構任務，該如何合理地安排每個階段的產品迭代工作呢？

——可以按照如下金字塔來執行（從底到頂）：

（圖引自《業務中臺產品搭建指南：電商業務平臺全流程設計與實戰》一書，如有侵權，聯系刪除）

通俗一點概況就是：讓業務RUN起來->讓業務閉環->讓業務流程完善->提高用戶體驗->再拓展其它新的東西。

上面的這個做事情的優先級順序，同樣也適用于生活、學習。比如學跳舞這件事：

目標是——老師教一支新的舞蹈，本節課你要學會這支舞蹈，長期目標是：你要學會自己跳舞。

可以怎么去做呢？

step1：你首先要將老師教的新舞蹈中的難的部分學會；

step2：然后將完整的片段記住，要能完整地跳下來；

step3：然后再是完扣每一塊的動作，做得盡量標準；

step4：然后再是提高你跳舞的可觀賞性（比如表情管理?。┛紤]下臺下觀眾；

step5：然后再是學習新的動作。

04 最終結果如何？

歷時1個月，完成了階段一的目標。最終成果是：完成了團隊標品v1.0（網絡情報偵察一體化SaaS平臺）的構建，并重新明確了產品對外服務的模式、以及產品所服務的目標行業及目標客戶群體。

又歷時1個月，完成了階段二的目標。最終成果是：1個月內完成了2個大版本的迭代，在春節復工后，正式開放給客戶使用。

當前處于階段三（第4個月），即在重構和優化后臺的幾個系統/模塊，同時打磨客戶高頻使用的模塊中。目前平臺已經有數十個試用客戶以及十多個正式簽約客戶了。

05 我是怎樣做的？

這里分成這樣兩個大階段：重構0.1階段和重構1.x階段，來分別介紹我具體是如何做的。

1. 關于產品重構0.1階段

這個階段主要是：明確重構的產品的業務目標是什么。

——即解決誰在什么場景下的什么問題？——你打算用什么路徑去解決？計劃什么時候可以解決？

帶著這些問題，我開始行動了。

首先是與老板、與其它產品同事，溝通要一些產品資料進行學習和線上系統的親自體驗，目的是了解團隊以前的業務都有哪些，以及與老板溝通當下及未來的業務重點或目標是什么。（攻哪個細分市場？當然是帶著自己對行業的見解與老板談）

接著，大致掌握了團隊的業務及產品現狀、團隊及公司資源情況（技術人員情況等）以及產品未來的發力點（姑且認為方向正確，先入行再懂行）后，我開始著手調研目標市場、目標客戶需求，目的是加深對行業、對客戶的了解。

確認了目標行業、目標客戶后，結合目標行業及客戶的特點，制定產品對外服務的模式。像我們的產品，主要是有幾種對外服務模式：一是SaaS系統，二是人工服務（如寫輿情報告、人員調查報告等），三是數據服務。SaaS是產品對外服務的主要模式。

2. 關于產品重構1.0、2.0、3.0

這個階段產品定位、產品形態已基本明確，主要任務是：具體產品的規劃設計，包括業務模塊的劃分，產品架構設計以及每個版本功能模塊的設計。

在這個階段里，我是按照先搞前臺，后優化后臺的思路來進行的。

1）搞前臺，是要將3個系統（一個輿情系統，一個公安核查工具，一個開源數據監測系統）進行整合，整合為一個前臺應用，并通過各類權限配置為不同類客戶提供服務。

主要是怎樣做的？

先按照數據流向，梳理業務架構，并按不同的業務場景，劃分功能模塊。

接著，上手整合現有幾個系統，功能合并去重、原有功能優化、缺少功能新增，最大程度復用原來的頁面和接口，重點設計rabc（基于角色的訪問控制）部分。

2）v1.x版本已經上線，解決了“邁進市場第一步”的問題，但仍有很多問題和漏洞需要修復。

在這個階段，主要是修復系統的諸多邏輯不一致、邏輯漏洞、業務未閉環、功能不完善等問題。

我是怎樣做的？？

邏輯漏洞第一優先級，邏輯不一致其次，業務閉環其次，最后優化不完善的功能。

注：邏輯漏洞問題應該在v1.0版本前解決掉，但因本產品推出時間緊迫，且初期僅開放給少量用戶使用，所以放在了1.1版本解決。

本產品的邏輯漏洞例子：模塊A和模塊B用到了同樣的“付費數據”查詢功能，但模塊A考慮了“扣除積分”，另一個模塊B不扣除積分，用戶完全可以“鉆空子”——這是由于之前模塊B的系統是私有化部署交付給客戶的，所以模塊B并沒有積分扣除邏輯。

3）x版本已經上線，在“邁進了市場第一步”基礎上，也積累了一部分用戶了，這個階段可以系統優化后臺架構了，同時兼顧前臺的優化。

在這個階段，系統的穩定性、良好的架構設計、系統的數據準確性&及時性&全面性（做數據服務的廠商需要視業務重心酌情考慮），將能夠幫助支撐更多用戶的使用，讓產品活的更久遠。

4）搞后臺，梳理出幾個必要的核心的后臺系統，明確它們的各自定位以及職責邊界，以及它們之間的交互關系（還是可以參照數據的流向思路來梳理）。

06 過程中遇到了哪些問題？分別是如何解決的？

整個重構過程對我來說挑戰極大。

一是我從來沒做過后臺，也從未參與設計過rabc模塊，SaaS系統當然也沒有設計過了。

二是我10月25日入職，在11月上旬就要考慮重構事情，新環境、新同事、新業務、新行業，對我來說處處是挑戰。

我是如何克服并解決的？？

1）首先充分認識自己，對自己的不足與優勢重新認識，對知識盲區瘋狂查漏補缺。

我過往的優勢是：有較豐富的AI類產品設計經驗，以及可以很熟練地掌握產品規劃的一些方案論，如華為的“五看三定”等，同時有著非常強的學習能力，以及調研能力。

對不足的地方，進行知識的查漏補缺。

比如rabc是什么，不清楚。

——我就去網上、去和前同事溝通交流、去看書，以此來構建這塊相對完善的知識體系，然后才能上手設計我要負責的SaaS產品。

再比如，對團隊的業務及產品目標不是很明確。

——我就逮住機會，和老板溝通交流（了解核心業務是什么、核心客戶是誰），充分利用上班及空閑時間，親自上手體驗他們以前做的系統，并與相關同事請教，去了解每一個功能模塊設計的初衷是什么、解決的是什么業務問題，并提出自己的思考

再比如，對后臺的幾個系統的重構和優化，從來沒做過，大多系統沒有界面，看不見摸不著，一頭霧水。

——我就從數據流向開始梳理每個系統的作用和價值，然后搞清楚這幾個系統當前是怎么互相配合（它們的交互關系）支撐業務前臺運轉的，然后再和每一個系統的研發溝通交流系統的主要功能以及核心邏輯，然后再基于自己的思考，發現當前邏輯的不足，并據此提出優化需求。

2）對我效率提升最大的就是：按照五看三定框架進行調研和設計。

整理文檔，按照“五看三定”方法論（看趨勢、看客戶、看競品、看自身、看機會；定目標、定控制點、定路徑），來整理文檔，每一塊都由淺入深地去了解。

對于不是自己做的系統，唯一可以加深體驗和了解的就是（尤其是在沒有文檔資料的情況下）：自己親自上手體驗，有必要可以寫一下操作手冊，以方便后續回顧。

07 收獲與成長

1. 關于重構的實踐與審視。
2. 關于SaaS的實踐與審視。
3. 關于采集系統、運營管理后臺系統的實踐，以及系統前后臺架構的整體設計。
4. 關于知識圖譜的實踐（還不是很深入，主要是圖譜可視化工具，以及簡單的本體關系）。
5. 關于抽象化思維的鍛煉。

比如我們要管理10多類信源，每個頁面如果都要開發的話，需要開發10遍，而將問題轉化成提煉共性，去開發一個動態配置頁面，將變得靈活許多也方便拓展，主要工作變為抽象提煉共性以及業務流程的設計。

08 最后談一下 0-1與產品重構哪個難？哪個易？

談不上幸運的是：0-1（前兩年）和產品重構，我均經歷過。

從個人親身經歷感受來說，我認為產品重構相對難一些，難在于你要“填坑”、你要“擦屁股”、你要“復用”，不像0-1，你有很多發揮空間。

而不論是0-1還是產品重構，都需要你對行業、客戶、市場調研了解，產品重構若只是后臺系統的重構，不涉及面向目標客戶的重構，則不需要了解市場這些，但也要清楚業務邏輯和業務流程。

寫在最后

希望本文的內容，能夠對你有所幫助。

產品經理，說難也難，說易也易。不知道自己會在產品這條路上堅持多久，至少現在還算熱愛，期望每天都能比昨天的自己優秀一點，加油！產品er們共勉~~ ：)