需求管理是項目管理的基石，項目失敗或者延期的原因十之八九都源于需求管理沒做好。在此之前要先分辨兩個概念：一個是需求，一個是想法。需求必須是明確的、可行的和確定的，而想法不是。想法是不嚴謹，或者未經過實踐驗證成熟的偽需求。

需求管理有三大任務：需求收集，需求細化以及需求管控。
一、需求收集
需求一般由業務人員或者產品經理提出。我們經常發現絕大多數人提需求很容易，但是不會寫需求文檔，所以很多情況下在項目組里要配備專業的需求分析員來完成這個工作，如果沒有專業的需求分析員，那么產品經理就要承擔這個角色。
1.需求訪談
并不是所有的需求收集階段都需要需求訪談。針對大型的復合型項目，比如需求方牽扯多個部門或者多個地區時，一定要做好需求訪談，因為幾乎不大可能有人，能夠對所有業務部門的工作細節和需求都了如指掌。
在需求訪談階段需要注意如下5個點：
01制定訪談計劃
在工作中基本上每個人都身兼多項工作，不大可能將100%的時間和精力只投入到一個項目。因此，在需求訪談期初，一定要確定好被訪談對象的時間，并盡早與對方完成時間的確認，以便被訪談人提前做好安排。
02確定訪談對象
在制定訪談計劃的同時需要確定訪談對象。需求的提出方要對自己提的需求承擔責任，站在多一事不如少一事的角度，必然存在互相推諉的情況，因此框定需求訪談對象就是框定需求責任負責人。
03框定訪談內容
框定訪談內容就是撰寫訪談的提綱。為了提升訪談的效率，被訪談對象必定需要提前準備相關的材料、梳理業務流程和邏輯。
04記錄訪談紀要
需求訪談獲取的信息量很大，因此在訪談過程中要有專人記錄訪談紀要，必要時可使用錄音設備。訪談紀要是需求文檔的基礎素材，在撰寫需求文檔的時候經常會反復查看或者回放錄音。
05確認訪談內容
根據經驗，大型項目的需求訪談一般需要進行l三輪，每一輪訪談都會比上一輪訪談更深入。
2.制定需求模板、劃分需求類別
項目經理需要制定需求模板，分發給不同模塊的需求撰寫負責人填充需求內容。需求劃分方法因項目不同而不同，以軟件類項目為例，需求分為9類：流程性需求、數據性需求、接口性需求、界面性需求、權限性需求、表單性需求、報表性需求、功能性需求、非功能性需求。
3.制定需求撰寫詳細計劃
對中大型項目來說，撰寫需求說明書的人應該有多個，所以需要切分工作任務，每個任務盡可能獨立，任務的安排盡可能并行。每個任務必須要確定完成時間，如果時間不滿足項目進度，需調配其它人力資源進行協助。
4.項目內審查
一般來說，需求文檔是很重要的交付物之一，為了確保需求文檔的質量，就需要建立互查機制：項目組內互查、項目組間互查。
5.與業務確定需求
當需求文檔完成審查之后，即可交付給業務負責人做確認。為了加速業務負責人確認需求文檔的時間，可以邀請業務負責人參加需求評審會，然后再讓業務負責人線下確認。
6.修改需求
當業務在確認需求說明書的過程中有反饋意見提出時，需盡快討論并確認意見的合理性，對合理的需求需盡快更新到需求說明書中，再次提交確認。

二、需求細化
業務主流程一般在需求訪談階段都能梳理清楚，所以我們重點討論數據細化、界面細化、權限細化、報表細化、及批處理。
1.數據細化
業務訪談過程中獲取到的數據很多情況下是非結構化、異詞同意的，或者格式不符合系統化管理，此時就需要數據細化。
2.界面細化
界面細化主要是為產品設計做好鋪墊，這個階段需要確定哪些界面應該展現哪些數據項、界面之間的跳轉關系、正常或者異常時的交互方式、不同權限的用戶看到的界面有何不同。
3.權限控制
在需求分析階段，越早梳理用戶權限越好。
4.報表細化
報表是很多經驗不足的產品經理或需求分析員非常容易忽略的內容，甚至有些人不認為報表需求是需求文檔的一部分，這是不對的。
5.批處理
批處理主要涉及的任務有報表和上下游系統的交互。

三、需求管控
需求管控包含：需求跟蹤、需求差異控制、需求變更控制。
1.需求跟蹤
需求跟蹤指的是牽頭或推進一個非體系化的需求成為體系化需求的過程。這些數據很可能分布在很多部門或者系統當中。
2.需求差異控制
需求差異控制指的是控制用戶對需求實現的期望。當然，需求差異控制需要一定的技巧，至少要讓用戶覺得是有理有據。
3.需求變更控制
需求變更控制簡單的說就是控制需求盡量不要發生變化，但不絕對。比如項目進行期間業務模式發生變化，之前提出的業務模式已經不適用了，那么就一定要允許變化，否則失去了項目的意義。

版權聲明：部分內容來源于網絡，如有侵權，請聯系刪除！