在軟體研發流程中，團隊一步步「過關斬將」，才能把通過業務收集而來的諸多需求轉化成實際的價值功能交付給用戶。作為研發流程的第一步，糟糕的需求管理流程，常常被認為是項目失敗的首要原因。從需求的產生到需求的結束，對需求生命周期的可視可控管理，能幫助項目更快更好地完成並交付產品。

既然需求管理如此重要，那麼我們應該如何讓需求管理更加清晰呢?

相當數量的團隊採用的按部就班的標準流程，我們稱為「金字塔指令式」流程，主要包括以下四個部分：

1. 決策：將收集到的需求進行甄別和整理
2. 計劃：確定要實現的需求的交付相關事宜
3. 監控計劃和實際的偏差：跟蹤計劃執行情況，以防意外
4. 糾正偏差：計划出現偏差時，應對的方式策略

在軟體研發流程中，首要是處理通過業務收集而來的諸多需求。下面，將詳細介紹在第一部分——決策中，如何將收集到的需求進行甄別和整理，這一甄別和整理的過程，也就是需求管理的過程。（以下內容均以 Gitee 企業版為例）

在使用 Gitee 企業版中，「需求」和「缺陷」都將通過一級菜單「任務」進行管理。

1.需求分類

根據業務情況的不同，需求之間會存在諸多的差異。Gitee 企業版從實際出發，對於每個被創建的「需求」提供了用於分類的「標籤」，該標籤同時也支持自定義。

2.需求拆分

確定好需求的分類之後，對於粒度相對較大的需求，應當進行拆分。在 Gitee 企業版中，需要拆分一個「需求」任務時，應當由相關人員（譬如需求分析師、產品經理等）在它下面創建若干的子任務，以便保證之間的關聯。

小提示：需求的拆分通常不超過三級。業內常把需求按大小依次分為「Epic」、「Feature」、「Story」三級。在 Gitee 企業版中，企業管理員可以通過進入「管理-任務類型與狀態」，然後新建名為「Epic」、「Feature」、「Story」的任務類型來滿足上述的管理需要。

3.確定優先順序

經過了分類與分層拆解之後，就該給整理後的需求確定「優先順序」。而確定優先順序的首要步驟，是明確何為優先順序。

在 Gitee 企業版中，我們默認提供了「嚴重」、「主要」、「次要」、「不重要」四個程度的優先順序。在使用之前，團隊成員應當對優先順序的程度形成共識。

比如「嚴重」，團隊約定 關係到戰略目標層面，且需要近期上線 的「需求」才算「嚴重」，遇到這類產生時自然心領神會，降低溝通落地的成本。

當然也可以採用 四象限法則：

• 嚴重：重要且緊急
• 主要：重要不緊急
• 次要：不重要但緊急
• 不重要：不重要不緊急

4.需求評審

確定優先順序後需要各方對需求進行確認，達成統一認知和共識，推進需求實現落地。

在需求評審的過程中，一定要說明清楚需求的背景、價值、意義，而不是純粹的需求講解，這樣有助於各方對需求的理解。

5.需求變更管理

當因外部環境變化或者內部需求定義錯誤導致需求需要更改時，做好需求變更管控，防止因為變更而導致需求執行的過程無法進行下去。善於利用 Gitee 企業版中任務的操作日誌， 自動記錄下需求的每一次變更，讓所有操作有跡可循。

6.需求歸屬

經歷了分類、拆解、確認優先順序、評審之後的需求，通過比較需求定義與後續工作成果之間的對應關係，建立與維護需求跟蹤列表,我們可以根據團隊或者產品功能模塊的區別，分別歸屬於不同的資源池，方便不同的團隊進行統籌管理了。Gitee 企業版中的 資源池 被稱為「項目」。

• 如下圖案例，企業中有「Gitee 研發效能項目」和「Gitee 天氣新功能」兩個功能模塊同時進行開發，就建立對應的「項目」。

• 之後點擊項目卡片，進入「項目-任務」，查看本項目中的待辦事項。與此功能模塊相關的需求在這裡創建。

以上各個需求管理的環節在整個需求的生命周期當中都會實際發生，但很多小夥伴在實際工作更多的是關注在需求分析的環節，而沒有注意後續的落實環節，導致雖然找到了真實需求，但卻沒有辦法落地。從用戶需求轉化為產品需求更多的是前三個環節，而從產品需求變成實際的產品則需要後三個環節。

在整個研發管理流程中，需求管理往往是第一步，也是比較重要的一步，只有需求管理足夠清晰和明確，後續的任務規劃、排期及執行才能更高效地進行。一個好的研發管理工具能幫助更好地管理實踐，達到事半功倍的效果