在以往的產品需求落地過程中，遇到了形形色色的問題，看看有沒有和你遇到的很相似呢：
1. 開發人員沒有按照一開始約定好的需求做，但是最後在覈對的時候，說是需求沒有講清楚需求，或需求文檔不清晰。
2. 在開發人員與其他部門，或其他公司進行合作的時候，沒有協定好接口需求，就開始做需求實現落地，最後出現了內外需求理解不一致的問題，開發後期不斷地修改實現的東西，最終開發沒有辦法按期交付。
3. 開發過了需求評審階段，進入到需求開發的過程，才又說難以做到，或者難以做好，要求產品人員更改需求，或要求不做此需求。
。。。
這些困擾着產品的問題，都可能是因爲在需求誕生了之後的整個開發落地的週期中，沒有進行需求相關的管理而造成的。我們可以在整個需求管理的過程中問自己四個問題：
1. 需求從哪裏來？
2. 要做哪些需求，不做哪些需求？
3. 要先做什麼需求，再做什麼需求？
4. 需求覈對，需求排期以什麼爲標準？需求，需求排期有變更，如何進行需求變更，需求清單和需求變更清單如何增加？
需求從哪裏來？
產品需求是從用戶需求過來的，我們通過用戶調研的各個方式，如用戶訪談，資料查閱等方式獲取直接或間接的用戶需求。
確定接納哪些需求？
用戶需求經過需求分析，也就是圍繞着我們的產品定位目標，系統性地分析用戶的使用場景，最終生成產品需求，經過技術評估，業務評審等形成可實現，且對用戶有用的產品需求。產品需求的生成不是一個線性的用戶需求轉化爲產品需求的過程，而是一個系統地進行分析，並轉化的過程。
如何對產品需求進行排期？
在確定了產品的業務功能框架之後，需要對大的產品功能需求進行排期，排期都需要綜合圍繞產品的長期目的，以及產品的短期目標而進行。針對C端產品的目標，可以從運營目標中來獲取，一般採用AARRR模型來講，可劃分爲拉新、促活、留存、營利以及自傳播多個階段。而針對B端產品的目標，要從客戶的角度，用戶的角度以及營利的角度來確定。可能一開始是爲了拿下客戶，單手後面在拿下客戶了之後，可能是要滿足客戶的彙報需求，用戶的使用需求，以及客戶的業績需求等，需要綜合各類需求原因確定實際的短期目標和長期目標。
在確定了目標之後，就可以採用四象限法，如重要且緊急，不重要且緊急，重要但不緊急，不重要且不緊急；我個人認爲比較好結合這個四象限的方法，是問自己一個問題，如果這個需求永遠不做，一段時間之內不做，或現在不做，會對產品的目標產生什麼樣的影響，這樣就可以比較好地分辨需求的優先級了。而優先級確定之後可通過以下兩個列表進行管理。
通過哪些需求管理工具對需求進行有序管理？
1. 需求調研
需要對需求調研的資料進行統一的管理，同時用戶提出的需求，可統一進行管理，便於需求的來源回溯。
2. 功能管理
在用戶需求轉化成爲產品需求之後。可通過業務功能框架圖，瞭解產品在產品體系的位置，以及產品內部各個功能之間的邏輯關係。進一步，可通過功能列表清單對於需要實現的產品功能進行統一的標準化管理。最後，對於各個產品功能需求的細節，可通過需求說明原型，進行交互，和詳細的業務規則的定義。便於和開發統一溝通語言。
另外，對於各個層面的需求變更，需要同時做好變更登記，確保需求變更的回溯。
3. 階段管理
對於需求的開發排期，要從短期目標和長期目標，來確定重要性和優先級。定義的過程，也是從大階段，到每個階段的里程碑定義，再最終到對應各個功能點的開發計劃定義。
另外，對於各個層面的開發計劃變更，需要同時做好變更登記，確保需求變更的回溯。
