覆盤：在技術重構項目中，產品應該做什麼？

Q2參與了公司一款客服細分場景下數據產品的技術重構，經歷3個月左右的時間，在團隊同學的齊心協力下比較順利的完成了目標。想通過文章覆盤在技術團隊驅動的重構項目中，作為產品經理，應該為團隊做的事。

01 什麼是技術重構？

先補充一下本次重構的背景：

該產品在細分賽道內擁有較大的用户規模，上線後已經穩定運行多年，面對不斷增長的用户數量，原有的技術方案出現了不足，基於這樣的背景，技術團隊做出了使用新技術架構、引入新技術，以現有功能為主導作一次技術方案升級的決策。

從背景中可以發現一個隱藏的條件，技術重構是有前提的，即產品是具有一定價值的，是已經被用户和市場驗證過的，只是存在了不足和問題，需要通過重構來解決

1. 技術重構的定義和原因

對技術重構做一個簡單的定義：指代碼重構，通過代碼重構來改善產品的性能，使產品的設計模式和架構更加合理，提高了擴展性和維護性。

那技術重構的原因有什麼呢？可以從業務和團隊兩個角度來看。

（1）業務角度

業務體量的變化要求了產品需要進行技術重構，不同的業務量級對技術方案的要求是不同的，最簡單的一個例子，一款產品從MPV階段到成熟階段，肯定會經歷技術重構，MPV階段用户體量小，更注重的是驗證功能的可行性，這一階段所選取的技術方案更側重考慮快速性；而在成熟階段，用户體量大，這個階段就要求技術方案的穩定性，以及所帶來良好的用户體驗

（2）團隊角度

還可以從團隊的角度來看是否需要進行技術重構，當現有技術方案影響到了團隊的效率時，也會考慮進行新的技術方案替換和升級

我司這款產品進行技術重構就有從團隊角度的考慮，從背景中可知原有的技術方案已經存在很久了，一方面，日常維護和處理線上問題時，研發同學經常反饋代碼的久遠性導致需要花較多時間來定位和處理問題；另一方面，日常迭代需求時，產品提出的設計方案，研發同學也反饋現有框架不支持一些交互，導致方案妥協，影響希望達到的預期效果

02 產品應該做什麼？

“技術重構”雖然是有技術團隊驅動和主導的，但是作為產品，也需要我們做一些“正確”的事，來幫助“技術重構”更好的完成，具體的表現為：不隨意增加新功能；梳理現有功能結構；思考未來功能需要的技術準備

1. 不隨意增加新功能

技術重構是在原有功能的基礎上進行的技術方案升級，“新功能”不屬於技術重構的範疇。在技術重構的同時進行新功能迭代，從“時間”和“成本”兩個角度看，是性價比極低的行為

（1）時間因素

技術重構的同時，線上版本往往會保持“低頻率”的迭代，即以維護為主，只迭代影響核心功能的緊急業務需求。這就要求了技術重構的開發週期在保持質量的同時可以儘可能的短，因為即使線上版本保持了“低頻率”的迭代模式，但還是存在功能迭代的可能性，拉長開發週期會導致重構結束後需要追的“需求”數量變多

增加新功能則會客觀拉長了開發週期，一起模擬一個案例，有一款電商產品，其交易模塊是該產品的核心功能，原計劃該產品的重構週期是3個月，但是因為加入了新功能導致重構週期擴展成了5個月，線上版本在每個月都迭代了一個交易模塊相關的功能。對比後就能很清楚的發現，“不增加新功能”重構完成後只需要追加3個功能，而“增加新功能”則需要追加5個功能，因此增加新功能是一件性價比低的決策

（2）成本因素

嚴格意義上，技術重構對用户應該是無感的，而增加新功能，導致用户發現差異，存在一定的解釋成本，如果增加的新功能數量很多，甚至需要版本遷移的工作，增加了開發成本。即使在一些特殊的技術重構中，比如技術方案升級了前端組件的樣式和交互，對於用户來説也只是體驗式的不同，對於功能的實現度仍然是一致的

結合“時間”和“成本”的考慮，得出一個結論，在技術重構中，增加新功能是性價比很低的行為

2. 梳理現有功能結構

在技術重構項目中，也是一次產品很好的梳理現有功能結構的機會，一方面可以幫助研發團隊更明確哪些功能是產品的核心功能，哪些功能是產品的次要功能，可以更好的分配開發資源；另一方面可以找出現有功能中存在問題的模塊，並在本次重構中進行修復

（1）原有產品設計存在bug的功能

原有功能和最初產品設計方案存在出入的，這一類功能傳遞給用户的信息並不是我們希望的，不僅沒有實現最初設計想解決某個問題的目的，還可能成為用户產生“產品無法實現功能”甚至產生流失的定時炸彈，而對於b端產品，每流失一個用户都有可能會給公司帶來不少的損失。對於這類功能，就需要我們設計新的方案來更替原有的設計

案例：線上版本提供了通過“柱形圖”來對比客服數據的功能，用户可以選擇字段，通過柱形圖來分析不同客服的數據差異情況，但部分用户的客服團隊人數很多，客服數量變多後導致柱形圖非常擁擠，也沒有辦法觀察出差異情況

調研用户的客服團隊情況，用户主要對比客服的場景時，查看某一分組的客服（一般不超過50個人）最大值或者最小值部分。基於這個情況，將原有的柱形圖改變成直方圖，提供升序和降序的切換功能

（2）原有產品設計影響效率的功能

產品功能實現了用户需求，但是實現方式複雜，增加了用户的操作成本，這一類功能對用户效率產生了影響，對於這一類功能也是需要我們重新設計替換的

案例：線上版本提供了過濾“指定消費者和客服聊天”產生行為數據的能力，目的是為了不讓一些特殊的消費者（例如刷單、廣告等）數據對真實的客服團隊數據產生影響。但是當前添加完指定消費者賬號後，表格是正序的，雖然提示了添加成功，但是不能很直觀的從表格上看到添加後的數據。而更改排序規則後，就能提升用户對於確認添加成功後的效率

這裏我們可以得出一個結論，在技術重構中，我們可以對原有的產品進行梳理，找到存在問題的功能和改動會明顯提升效率的功能，對這兩者進行優化、修復、更替

3. 思考未來功能需要的技術準備

最後也需要我們產品思考未來迭代功能存在的可能性，並及時的將這一可能性告訴研發團隊，以便於他們在技術方案設計的時候，留下足夠的空間或者提前做技術準備

案例：

某款產品正在進行技術重構，存在一個問題：現有一級導航欄已經非常臃腫了，想再加入新的導航菜單顯得非常困難，而後續還會有新的菜單加入的計劃，未來採取的做法是菜單會根據權重可配置展示、根據屏幕分辨率自適應。這就需要在本次技術重構中，提前告知研發團隊未來期望實現的，那就可以提前將菜單不寫死，避免了菜單欄模塊二次重構

總結

在面對技術重構類型的項目時，產品也不是無所事事的，需要我們幫助團隊梳理原有的功能，同時想清楚未來迭代的計劃，提前在技術方案升級時做好準備，留下口子。只有做了應該做的事，才不會影響團隊的進度，提升團隊的效率，避免出現二次重構

作者：晌午，微信公眾號：晌午自習室

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

題圖來自 Unsplash，基於CC0協議