需求管理，說起來似乎也沒那麼難，但在各個項目中具體做起來時，往往會出現各式各樣的問題，導致實際的需求管理效果並不理想。
那麼，如何保障需求管理成功？與其羅列保障成功的諸多因素，不如找到最容易導致失敗的幾個關鍵問題，從而提前規避。
本文梳理了需求管理中最容易忽略的10大隱患問題，這些問題在項目開展過程中，大部分情況是「重要但沒那麼緊急的」，能否將項目管理的功夫花在平時，是保障項目需求管理成功的關鍵。
01
沒有制定項目的整體管理計劃
項目整體管理計劃是要確定項目如何執行、監控和結束的方式、方法。定義項目開展過程中，有哪些規則、標準。比如哪些是必須做的、哪些是可以省略的，需要明確出來。
從落實層面上看，可能是平時溝通沒到位，或者啟動會上漏了幾句提醒/聲明；也可能是組織、團隊在流程機制、管理方面的缺失。
具體而言，整體管理計劃中，往往需要關注的有：範圍管理計劃、需求管理計劃、進度管理計劃、成本管理計劃、溝通管理計劃、變更管理計劃、配置管理計劃等。比如，溝通管理中，溝通的渠道/形式/頻率，日報/每日例會、周報/周例會、階段性報告等，有哪些規則必須遵守等等。
關於項目計劃的可以查看以下文章：
- 圖解項目經理必備目標拆分和制定計劃步驟方法
- 2022項目計劃進度管理表：文末可下載直接編輯使用的甘特圖
- 還在為項目管理規劃發愁嗎？這是我見過的最高逼格的項目管理體系和落地計劃
- 制定項目計劃不是你想像中的那麼容易
02
沒有制定有效的範圍和需求管理子計劃
如何制定有效的範圍和需求管理子計劃呢，最關鍵的一點，最基本的流程和標準要清晰：
- 收集需求
- 範圍定義
- 創建WBS
- 範圍核實
- 範圍控制
其中範圍定義，要明確以下基本信息，輸出項目範圍說明書：
- 項目目標
- 產品範圍描述
- 項目可交付物
- 項目邊界
- 產品驗收標準
- 項目的約束條件
- 項目的假設
關於如何創建WBS，可參見如下往期文章：
- 一圖掌握項目管理的核心工具WBS工作分解結構，PM必備技能！
- 一張圖掌握WBS任務分解法
03
沒有制定合理的整體變更流程和需求變更控制流程
變更基本流程可以參考以下幾個方面：
- 提出與接受變更申請
- 項目干係人都可以提出變更，提出可以由不同的方式，口頭、書面均可，但變更應及時以正式方式記錄。
- 對變更的初審
- 這個環節主要是通過對變更申請文檔的審核來實現。項目經理、項目關鍵相關方對變更施加影響，確認變更的必要性，確保變革是有價值的；
- 針對變更記錄的格式、完整性做校驗，確保變更評估所需的信息是準備充分的；
- 與干係人一起，就供評估的變更信息達成共識。
- 變更方案的論證
- 項目管理委員會審查
- 發出變更通知並組織實施
- 變更實施的監控
- 變更效果的評估
- 判斷發生變更後的項目是否已納入正常軌道
- 關於需求變更的可以查看以下文章：
- 如何應對項目需求變更？應對變更的流程步驟和方法
- 項目經理如何應對客戶的需求變更？
- 如何在敏捷項目中管理範圍變更？
- 如何應對頻繁的需求變更？
04
對客戶的需求獲取不充分
對客戶的需求獲取不充分主要有兩種情況：
- 對客戶干係人的識別不完整
- 網際網路軟體項目，通常客戶干係人除了用戶之外，還是甲方的高層領導、IT、運維等部門；往往很多項目只關注用戶需求的調研，而忽視了比如客戶高層、IT、運維關鍵相關方的需求，導致在系統性能、質量、安全等非功能性需求被忽視，開發過程中不斷變更，甚至無法通過驗收。
- 對客戶需求收集、調研不充分
- 通常客戶也比較忙，這就需要在客戶關係、需求收集的方法/技能上多下一些功夫。比如收集之前做好充分的準備，通過訪談、觀察、原型、標杆對照、系統交互圖、文件分析（方案文檔、合作協議、招投標文件、業務流程圖、數據模型、功能清單、用例文檔等）技術方法提高需求收集的效率和質量。
05
需求分析工作不充分，缺乏需求定義環節
往往僅有初步的需求說明書，沒有定義出詳細的需求規格說明書。甚至存在一些公司或項目團隊，不寫需求說明書——這不僅不利於需求的管理，更是公司組織資產流失的一種隱患。
需求定義是收集到客戶的需求之後，對需求的進一步確認。因為客戶提出的往往是基於某一方面的需求意見，至於放在整個軟體系統中，有無與其他需求的關聯、影響、衝突、限制，有無明確具體的度量和驗收標準等等，這些都需要結合需求完整性進行進一步的定義。
針對這一環節的綜合建議是清晰定義需求分析工作的輸出標準，規範需求說明書、需求規格說明書模板，並按要求嚴格執行。
06
缺乏需求驗證環節
當「完成」需求收集時，不少人認為接下來就是要馬上進行需求分析、產品設計，而忽略了什麼才叫做「完成」。
當需求收集之後，只能算作是自認為的完成，實際上並沒有得到客戶的綜合確認，因為通常情況下，需求的收集是來自於多個客戶，多個相關方的，對於每個客戶而言，他們並不一定清楚需求收集「完整」之後是怎麼樣的，對於客戶A收集的需求是否與B的需求有衝突，有沒有他們認為需要調整、補充的地方，都是待定的，因此，請客戶代表一起進行需求評審，得到干係人對需求的一致理解，得到干係人對需求的承諾，這一步非常重要，是對需求驗證的關鍵，是減少後續需求變更的重要保障。
關於需求管理的可以查看以下文章：
如何應對項目需求變更？應對變更的流程步驟和方法
PMO項目集管理中客戶需求挖掘的方法和步驟？【慕哲系列25】
項目管理的最重要的一環需求管理該如何做？
項目經理如何應對客戶的需求變更？
07
沒有有效地管理需求變更控制
關於需求變更常犯的錯誤是，這個需求變更不大，直接做了吧，當一個個小的變更不斷累計，造成里程碑目標不能按時達成時，才發現為時已晚。
關鍵問題在於：變更無記錄，全憑感覺管理，這是不行的。正式的變更記錄是基礎（參見第3點變更流程）；其次是變更的控制，缺少變更控制的標準。需要提前達成共識，什麼情況下可以由項目經理直接決定，什麼情況下必須走變更控制委員會審批。
這裡需要注意的一個點是：當變更走到變更委員會審批時，其宗旨不是為了一味地拒絕變更、減少變更，而是更加完整的評估變更的影響，從而保障必要的變更能夠在合理的時間、資源、成本下得以實現。（往往重大的變更會帶來資源、 成本、時間等方面的調整，多數情況是是增加的投入）
08
範圍沒有管好，導致不斷地範圍蔓延
這一環節強調的是在需求管理的基礎上，綜合時間、資源、成本等多方面因素，對範圍的進一步確認、核實與控制。並且需要注意的是，這項工作不僅僅只在需求完成後進行，而是在整個項目開展過程中，需要持續地關注。
這一步往往沒做好也是可能由於多方面因素造成的，但主要原因在於：
- 沒有流程規範，工作環節遺漏，比如沒有按照收集需求、範圍定義、創建WBS、範圍核實、範圍控制的流程步驟開展工作
- 有流程規範，但往往造成不容易控制的關鍵在於前一步WBS工作不到位，導致評估出現偏差，不能夠有效支撐範圍的核實與確認
09
未做好需求與進度的管理
當需求範圍變更時，沒有充分評估對進度等其他方面的影響，導致進度延誤。尤其在需求、進度被分配為項目團隊中兩個人分別負責又沒能夠有效統籌時，更容易被忽略。
10
項目生命周期模型選擇不當
通常瀑布模型、敏捷疊代模型大家比較熟悉，此外，還有V模型、原型化模型、螺旋模型等。幾種模型各有特點，尤其在目前網際網路軟體行業高速發展的階段，結合不同的場景選擇適當的模型，合理地規劃項目里程碑計劃，也是影響需求管理成敗的一個不可忽略的因素之一。
以上需求管理相關的10大隱患，也是往往會被認為有必要參考但又往往容易被忽視的問題，總認為不用搞那么正式地執行，但至於要執行到什麼程度，又沒有一個清晰的標準和界限——這就是導致頻頻出問題的關鍵所在。
需求管理中，我們不能因為團隊成員總有更緊急重要的事情要做，而忽略了更重要但沒那麼緊急的事情，偏離「規矩」，從而埋下一個個隱患；更不能想當然地認為大家可以結合時間、資源來自由發揮。
以上，供各項目經理們參考，謝謝~
需求管理做不好，怎麼能管好項目？