如果讓你接手一個老舊的軟件系統，你會如何做好需求？作者結合相關案例，談談自己的做法，一起來看看吧。

作為互聯網產品設計人員，在工作中碰到最多的問題之一：如果讓你接手一個老舊的軟件系統，你會怎么去把需求做好？今天來詳細談談我的案例。

先復盤一下我之前的經歷，我曾經接手過多個舊系統，其中2個舊的軟件系統有印象，比如14年貴金屬交易系統，22年智慧工地老系統。

在14年左右，我剛入行產品崗位，從運營轉到產品部門，我的第一個任務就是優化移動端和PC端貴金屬的注冊流程。剛開始我以為挺簡單，但入手后就碰到一堆問題，這個有點讓我措手不及，后面輸出第一版需求就被領導否決了，領導當時說你只了解表面，沒有了解里面的業務關系。然后給我一點思路，后面根據領導指示和自己的理解花了2天完成任務。其實我做了三步：

1）第1天熟悉貴金屬里面的大概邏輯，核心業務流程，這是打基礎。

2）第2天正式開始，首先換位思考一下，如果你是客戶，當要開戶時你的需求是什么，肯定是注冊越簡單越好，容易操作。所以圍繞這個思路可以展開工作，比如注冊流程的字段能不顯示就不顯示，能放后端就不要放前端，這是一點。第二點頁面要讓客戶看的懂自己要做什么，比如第一視覺要讓用戶明白自己要怎么做，有幾步，要填什么信息，另外提交后反饋，有些需要審核，有些是秒通過，這個取決于客戶的用戶注冊時的L等級。

3）最后就是細節問題，如提示密碼問題，入口問題、體驗還有顯示位置的問題。然后輸出到文檔即可。這個回想起來其實是產品入門時最簡單的需求。

第二個優化項目是22年智慧工地（老）系統優化，這個是我應該見過最復雜的系統。當時接手時難度較大，功能點多達幾百個

1）了解底層的業務需求，因為任何一個軟件系統其目的主要是實用，如果解決不了用戶的需求，再高大上的系統也是雞肋，所以明白這一點，就要從業務需求著手。建議采訪提需求的業務人員，了解需求的動機，多思考一下系統給誰用的，解決了什么問題。

2）在了解業務需求的基礎上，建議畫一個思維導圖，折分不同的業務流程，然后全都跑一下流程。當你熟悉該業務以后，再進行標記。當然這個過程有點麻煩，而且有的不一定有這個條件。比如我之前就是在測試環境時發現全是BUG，而且帳號也不一定有相關的測試數據，串聯不起來，針對這個問題我分3步走，1是讓開發修復，2是要帳號，3如果都不行，只能在生產上跑，不過要注意制造的數據不能影響到系統穩定。

熟悉功能模塊也有順序，建議是優先熟悉底層的架構功能，然后是流程，最后是內容。比如

• 人員組織結構：這個模塊很重要，涉及使用系統的人員架構信息。包括人員怎么進來的，怎么扭轉的，跑什么流程，需要什么權限……
• 流程管理：這個涉及到業務流程配置。所有需要審批的業務基本都在里面。最好全都跑一下流程。
• 角色和操作權限，這些是控制操作權限，控制能看的范圍，能控的菜單等
• 包括系統關聯的APP，公眾號，小程序，或關聯的系統都需要添加、下載、熟悉。

3）第2步中，非必要的流程建議工作閑暇時間完成，而必要的需求建議采用緊急的方法，比如可以問一下熟悉業務客戶，或者內部測試或研發人員，這樣更能把握需求的痛點，對設計的需求業務合理化，邏輯正確化提供幫助。