編輯導語：對于想要實現數字化轉型、提升業務處理效率、改變冗雜環節的傳統公司來說，系統重構也許是重要一環。不過老系統重構的過程中，總會遇到形形色色的問題。本篇文章里，作者結合實際案例，對老系統重構過程中存在的隱秘問題做了梳理，一起來看一下。

老系統的重構對于一個傳統公司或者是已經經營了很多年的公司來說，是數字化、智能化轉型的必經之路。

公司里一般老系統走到了必須要重構的地步，說明該老系統在公司業務扭轉中是有很重要的作用的。但是往往老系統的重構是一件很讓產品研發團隊比較頭疼的事情，畢竟重構所涉及的反方面面太多，尤其是一些涉及到很多業務方工作扭轉的系統。

15年前的老系統界面截圖如下，供大家感受一下年代感：

一、重構背景

本人是從國內知名互聯網大廠跳槽去了一個國內較老的傳統IT公司，負責重構的老系統是公司在2005年研發出的一個類似erp系統，是.net開發的web系統，主要負責公司內部的一些文件資產的上傳發布和存檔。

該老系統為什么最終決定要重構？原因其實非常明了：

1. 該老系統是公司在05年開發的系統，經過15年之久的“任職”已經在底層技術支持不能滿足研發人員對其正常的維護和迭代；
2. 老系統的功能需求和交互體驗上不能滿足用戶的使用，甚至會導致用戶降低辦公效率；
3. 就是很多高頻使用者對該老系統的“怨氣”極大，整理了60多頁的痛點PPT給到我們部門領導希望優化；

所以，經過和這些“怨氣”較深的用戶詳談后，我們發現很多系統背后的權限劃分、資產、組織與用戶的關聯關系無邏輯可尋，及資產的信息安全管控邏輯等很不清楚，就連高頻用戶也不清楚，因為他們并不知道這個15年的老系統的迭代更替的詳情，在公司內部也未找到相關歷史的需求資料。

二、重構復盤

在新系統上線后其實暴露出很多問題，但是最終還是被認可的，只是整個項目組都是第一次重構這種老系統，會有些經驗不足。

關于整個項目確定到研發上線用時：9個月。

關于我們的研發團隊成員的基本情況：

1. 產品：1.5個人力，我為owner，還有一個產品輔助；
2. 設計：1個人力，因為設計資源緊缺，所以交互和UI各占0.5個人力；
3. 后端：3個人力，有2個人全部投入，另外來個人各投入0.5個人力，其中包含框架設計及所有后端開發人力；
4. 前端：1個人力，全部投入；
5. 測試：2個人力，全部投入；
6. 翻譯：0.5個人力，由國際化翻譯部門支持。

關于重構目標達成情況：

1. 技術項：優化技術支持，將底層技術微服務化及去x——完成；
2. 產品項：挖掘現階段用戶的真實需求、刪減冗余低頻功能、整合信息及調整PAL庫信息架構、根據公司安全部門規定重新定義資產密級和資產權限劃分——基本完成；
3. 設計項：優化用戶任務目標流程路徑，讓交互設計和界面信息布局與時俱進，提升PAL庫用戶體驗——基本完成。

三、系統重構的隱秘角落

本次我先不具體系統重構的過程，想先記錄下系統上線后的一些意外情況，因為，在系統重構的過程中除了人力上的緊張其他感覺沒有大的問題，但是在上線后，就發現在重構系統過程中有些是我們團隊沒有關注到的注意事項——靜靜的都在隱秘的角落里！

首先，從技術角度來講：

1）數據同步這一塊，在新系統上線后經常會爆出歷史數據同步發生異常，比如資產的創建日期、資產的權限范圍會出錯。

2）是因為老系統的數據庫和現在新系統的數據庫不同，沒辦法做實時同步，如果一定要做那就很費人力，所以這點影響到了用戶在新老系統切換時沒有過渡期，很多用戶在使用起來很不習慣（并且現公司是個傳統的IT公司，有很多老員對習慣的改變非常抵觸）。

其次，從產品角度來講：

1）在產品重構的方案前期，應該要同步給到業務方及干系方的領導，即便自己的領導沒有在高層內部同步本項目的事情，自己作為項目的owner也要提醒自己的領導。

這一點其實會很好地在高層建立一些理解和口碑；因為在系統重構后，其實或多或少地都會有用戶反饋一些負面信息，同時，在新系統上線初期也是bug暴露最多的時期，如提前做好對干系方領導的信息同步，他們就會更全面了解你們在研發中所遇到的一些問題，以及過程中的每一次重大產品決策，這其實能很好地幫助各方領導來理解你們重構的系統。

2）不能高估IT公司內部員工對新型互聯網的敏感度，在新系統上線前，一定要通過各種有效方式給大家做新系統的使用培訓，而且要盡最大努力做到培訓的全面性，避免用戶因使用習慣的改變而帶來的負面反饋。

3）有時間和精力一定要在前期做面對面的用戶訪談，比如我們在前期本來是要做用戶訪談的，訪談計劃、訪談用戶及出差城市都已經確定了，但是被領導叫停，原因則是覺得該系統的高頻使用人數不多，感覺也沒必要花時間和精力去做用戶訪談，于是這也成了很多用戶在使用不習慣的時候拿出來說事兒的“小辮子”了。

4）要實時跟進業務方答應的TODO事項是否落到實處，就拿我們的系統來說，公司的老系統其實是功能很龐大的，有不同的業務方在系統中上傳和發布資產，有公司級的資產也有部門級的資產。

但是兩個不同權重的資產對權限管控級別和管理人員的細分度都不同，事先，管理公司級的資產用戶是不希望部門級的資產用戶再使用本系統，建議他們使用公司內部的另一個可替代的老系統（但是誰會愿意用老系統呢）。

但是這個事情主要是得這兩方的使用者或相關領導去協商好的問題，但是相關干系人并沒有重點關注這件事情，最終也導致了兩方業務方各種撕，同時作為產品研發團隊的我們夾在中間其實也是很難受的。

所以實時跟進事先安排給業務方的TODO任務，清楚他們對接的進展也是產品研發團隊所要關注的事情，不然就是兩狗打架粘你一身毛。

5）要將老系統所有的功能點，以及存在的問題都整理出來告知全公司的用戶，不然總有一些噴子會說老系統可以什么什么（其實沒有），或者說老系統權限如何合理（其實是老系統的bug漏洞），還有甚者會說老系統的交互視覺好看的~

總之就是意想不到的的事情太多，想要堵住用戶的嘴是不可能的，但是可以提前準備好有力的回懟材料。

注：由于系統有水印，所以不便于給大家展示最新系統成果了，抱歉！

四、總結

B端產品的產品邏輯往往是比較復雜的，涉及的用戶角色也很多，但是這些往往在產品重構的過程中，只要使用正確的產品研發方法，都不會出大問題。

但是正因為是B端產品，所以很多領導在思想上就不太重視，因為做出來用不用公司內部員工往往是沒有選擇的，但是作為有追求的產品人，還是要避免“強權研發”產品。

同時一個系統的重構是一個很繁瑣的過程，不同的產品及公司級團隊所面臨的的問題是千差萬別的。

但是，除了關注產品本身的需求功能、技術、體驗問題外，還有一些看起來不太起眼的的各部門同步問題、涉及干系方的意見達成問題等和產品本身關系不大的細節也要注意。

最后的最后我想說，系統重構這種中事情遇到了的確令人下頭，但是這種機會也不是所有產品人都能遇到的經歷，所以，只要大家遇到了系統重構的機會，還是大膽上吧！

本文由 @一只船 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Pexels，基于CC0協議