編輯導語：不管是剛剛入職的小伙伴還是已經入職工作很久的小伙伴，在重構系統的時候都應該會有一些問題，在本文中，作者總結了他的工作經驗，分析了如何在舊系統上進行升級的方法，一起來看看。

我目前在一家傳統醫療企業，為實現信息化轉型，領導期望將使用多年的舊系統進行升級。因系統擴展性不高，只能推翻重做。我司和德勤有戰略合作，所以請他們團隊來協助重構系統。

在重構的過程中，我在德勤的需求分析師身上學到了很多做事方法，受益匪淺。因此，把這個關于重構系統的實例分享出來，希望對大家有啟發。

一、重構老系統我們碰到的三大問題

1. 信息架構混亂且重復，業務流程復雜且不合理

早期的系統沒有專門的產品經理規劃，一味圖快，有需求就加功能，留下了非常多問題。比如：

流程復雜：舊系統存在非常多的不必要流程，導致使用者為了達成業務目標，經常要在系統里操作多次，這嚴重影響實際工作效率。

展示復雜：現在的系統包含 900 多個頁面，頁面之間的重復度高。本可將信息整合為一個頁面，實際卻用多個頁面展示。有的頁面有 50-60 個按鈕，且每個按鈕都會觸發不一樣的場景。

培訓難度大：使用者很容易忘記功能的作用和操作順序，導致學習成本巨大。經調研，剛入職的同事要熟練使用系統，一般要 2-3 個月。

2. 缺少需求、設計文檔

舊系統沒有完整的需求說明文檔，概要設計，更不用說詳細設計了。文檔更新不連貫，最新的文檔還是幾年以前的，這幾年新增的業務功能則完全沒有記錄。且文檔內容都非常簡單，無法呈現完整的業務流程和核心細節，很多地方都是簡單帶過。

3. 沒有人了解系統全部功能

文檔不全，我們還寄希望于有“活文檔”，但是這個希望也落空了。老系統的使用角色有近 20 個，因為功能復雜，每種角色只會操作跟自己業務相關的幾個頁面，但也只了解主流程，對于細節部分還是模棱兩可。

系統運行了 10 多年，一直有開發工程師在維護。但因為公司人員不斷有變動，文檔、交接程序都不完善和規范，經過幾手傳遞，公司內沒有一個人了解系統全部功能。

二、面對挑戰必須要有整體且細致的規劃

情況就是這么個情況，挑戰非常巨大。

經驗尚淺的產品經理面對這種場景，可能會急于動手，在還沒有思考清楚工作流程的時候，就直接研究系統功能，看舊系統如何設計，然后在這基礎上做部分優化。但是這種工作方式并沒有大局觀，只知道要做但不知道要做哪些，且需求梳理完的截止時間也不確定，無疑不利于整個項目的落地。

有一陣子，工作進入了停滯期，一時找不到入手點，不知該如何處理工作。后來，在德勤的協助下，我們并沒有著急開始動手，而是先思考再做！

在動手前會認真討論和思考怎么做更有效率，并且能達到一個最好的效果。畢竟我們不可能花幾年時間才把需求全部整理出來，到時候競爭公司早走在前面了。

以下是我們后來的規劃方案：

1. 確定工作的目標，范圍，截止時間

首先就是確定工作的目標，范圍，截止時間。

目標已經很明確，就是需要把需求全都整理一遍，然后重新進行產品設計。而工作的范圍即梳理全量需求：系統里的功能都需要我們全部梳理。截止時間我們是倒推的，因為新系統計劃年底上線，所以需求梳理的時間要早于上線幾個月。開始動工前，梳理這三個事項非常重要。梳理完還要和領導做同步和確認，這樣才能明確工作方向和重心。

2. 量化需求梳理工作

確定第一步的內容后，第二步是對接下來的工作進行量化。

安排幾個同事把系統的所有菜單都用 Excel 整理出來，包括一級菜單，二級菜單，三級菜單等，最后統計下來有 900+ 頁面。

為什么只按頁面統計，不按功能統計呢？因為涉及頁面太多，有的頁面功能甚至高達 100+ 個，如果按功能整理就需要花費大量時間，但我們得嚴格控制需求梳理的進度。且我們對功能不了解，也不了解實際的業務含義，所以前期整理的顆粒度就僅僅按照頁面劃分。

Excel-V0.1

有的伙伴可能會有疑問：為什么需要列一個這樣的Excel表格去整理頁面菜單呢？對于后臺產品，前期不應該直接進行業務調研嗎?

因為這是個重構系統的項目，上層領導只知道要重構，卻并不知道重構的難度有多少。前期制定的系統梳理至上線時間為 6 個月。但梳理完以后，我們對工作量和工作難度有了新的認知，6 個月是絕對完成不了的。

有了這樣的梳理和量化的結果，我們和領導匯報工作難度并且調整重構時間為 12 個月。

3. 確定頁面梳理優先級

完成第2步的量化工作，我們是不是就開始著手梳理這 900+ 頁面了？不，這還不夠，還得深挖！

梳理那些沒人用的頁面，根本就是浪費時間。我們要搞清楚用戶到底常用哪些頁面，壓根不用的頁面就不梳理。于是，我們繼續梳理頁面優先級。將之前整理的頁面菜單Excel的列后，再加上目前主要使用系統的各大用戶組。

用戶組是由業務負責人提供，大概有近20個用戶組，每個用戶組都有對應組長。所以，我們前期就和各大業務組組長進行溝通，逐個詢問當前所有頁面的使用情況，是否使用以及使用的頻率。

Excel-V0.2

統計下來：高頻使用的頁面有200+，中頻使用有100+，低頻使用100+，幾乎不用頁面 500+。

不過，業務發生頻率和需求優先級還有一定區分，經常使用的頁面肯定是需要優先梳理的，但業務不經常使用的頁面不一定優先級低。因為低頻使用的頁面，可能也會涉及到一些核心流程的流轉。不過不要緊，深入調研的時候去了解詳情即可，初期階段就優先梳理把高頻使用的頁面的需求。

4. 進行需求梳理

需求梳理我們大概分為三步：需求調研，需求梳理，需求分析。

4.1 如何進行需求調研

前期業務負責人給我們提供了15個用戶組的組長資源，于是我們就以用戶組作為突破口，采取線下逐個調研用戶組的方式來了解需求。

因為不同用戶組在系統中都承擔著各自的職能，所以我們只要滿足各個用戶組的核心需求，那么整個系統就相當于是調研成功了。

調研前：我們會在舊系統看該用戶組的主要使用頁面，根據頁面大概了解用戶組的特征；與此同時也會準備自己不明白的問題。

調研時：整個系統的功能特別復雜，在調研時對調研人員也進行了一定的責任安排。每場用戶調研下，都有一位同事負責了解主流程，一位負責了解異常流程，一位負責做筆記/錄音，一位負責技術評估等。

那調研為什么要以主要流程和異常流程來進行劃分呢？主要流程是支撐用戶組的正常職能操作，調研必不可少；但異常流程也十分重要。我們做需求梳理的時候肯定也是要把這些異常場景考慮上，需要給用戶提供一些撤銷的功能來結束整個流程。

調研的方式為在用戶的工作區域進行現場訪談。因為涉及流程性的環節我們需要結合線下用戶的實際操作才會理解更深，避免出現大的偏差。

調研后：前期對調研人員有了具體安排，那調研后也就需要有對應輸出。

在此階段我們主要輸出的文檔為：主要流程圖，異常流程圖，用戶訪談記錄。

?流程圖例

4.2 如何進行需求梳理

因用戶組老師工作繁忙，不可能把每個需求以及舊系統對應的功能一一描述給產品經理。所以，我們采取的工作方式是，根據上述產出的某用戶組主要流程圖和異常流程圖，再把該用戶組使用頻率高的頁面和流程圖中的節點一一匹配。

這樣就可以知道目前該用戶組為實現自己的主要目標的過程中，在系統上有哪些操作。

還需要明確一點，需求調研是一個反復的過程，不可能每個用戶組只調研一次即可。我們調研的整體思路還是采用先整體后細節的邏輯。

先整體：第一次調研了解用戶組的主體流程和異常流程，再與舊系統頁面做對應；后細節：后幾次調研才開始了解頁面上的其他場景和細節。

4.3 如何進行需求分析

對于使用了舊系統近10年的用戶而言，他們對自己想要什么、不想要什么已經非常明確，而我們產品經理只需要能理解用戶的核心需求并作出優化設計就可以了。

但即使是這樣，我們還是會把用戶的需求用”用戶故事”的邏輯來理解。即，用戶故事=用戶+故事=人+事+故：誰要使用這個（角色），要完成什么活動（活動），為什么要這么做，這樣做帶來的價值是什么（價值）。

我們不是需求的搬運工，我們在刻意了解需求意義，進行需求分析之后，才開始進行產品設計。

5. 分配需求梳理工作

組里的產品經理有 7 位，完全前幾步，接下來就是分配具體的任務了。

我們決定以用戶組的維度來進行分配任務，但這也并不是隨意去分配，在分配的時候還要考慮各方因素。

前期在對用戶組調研的時候，已經大概了解了對應的難易程度。于是再根據現有產品經理工作年限以及興趣的情況，進行分配任務。

比如一個產品經理，可以分配2個困難模塊，3個較簡單模塊；比如剛來且工作經驗不足的產品經理可以先分配些簡單的模塊去熟悉，然后逐步開始進入深層次的協作；還有對于難度較大的模塊，可以讓多人共同協作。

如此一來，整體團隊的工作任務就已經分配得當，大家就領好自己的任務專注執行即可。

6. 整體監控

當產品模塊都分配下去后，還需要計劃需求梳理時間，即每個模塊梳理的時間截點；

還要定期詢問各位產品經理的工作情況，是否按時進行，是否遇到問題，是否需要協助等。

經常跟進進度，監控整體進度，也讓整個團隊的目標都在按照計劃的日期如期開展。

我們只有先有條理的規劃，然后一步一步執行，這樣才能順利完成任務。

三、我的感悟

跨進互聯網做產品經理的那一刻，我便暗暗下定決心，要成為一名優秀的產品經理。

轉眼 3 年多了過去了，我在這期間看了不少產品經理的書籍，也系統地學了不少產品知識。

如果問我產品經理最重要的能力是什么？我會毫不猶豫的說，解決問題的能力。

1. 解決問題，需要系統思考

在我看來，任何一個職業都是在不斷發現問題和解決問題，產品經理亦是如此。

但即使是同樣一個問題，換作不同的人處理，事情的完成效果也會不一樣?？傆行┤烁煨?，效率高些，處理的更恰當些。

那這種能力如何去培養呢？

其實最關鍵的一點就是需要平時積極思考，不斷的去總結和復盤。

對于一些復雜的工作，經過總結下來，其實可以形成一套SOP流程（標準作業程序）。

比如：先量化工作，再做任務拆分，排出任務的優先級，然后任務分配到人，設置任務截止時間，最后整體監控。

2. 在錯誤中成長，多復盤，多交流

在工作中會處理很多事情，但并不見得你每次處理事情的方式就是絕對完美的。而當我們復盤時，就好像把整件事情的經過像電影一樣重新放映。

在重溫的過程中，不斷思考，這樣的事情是否還會有一種更好的方式去解決？如果有，那又是什么。那當下次你再遇到這樣的事情時，你就會用一種更好的方式去處理。

如果想不明白也可以請教自己的領導，看看領導給的建議；或者繼續問產品社區的同僚們，看看他們是不是也遇到過類似問題，又是怎么解決。

產品經理需要的能力其實還有很多?！叭巳硕际钱a品經理”，但不代表著“人人都是好的產品經理”。一個好產品的背后總有一些優秀的產品經理在默默付出努力。

本文由 @炸草少女 原創發布于人人都是產品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基于 CC0 協議