細地看了幾遍問題描述，基本上發現和分析需求沒什么關系，更多是集中于如何應對來自各方的需求。

其實每次當我收到其他人的需求提議時，我都是非常興奮的，因為平?？偸强嗫嗟卦谙脒€有哪些地方可以優化，有人直接給自己提出來，其實省了不少功夫。其次，作為一個對產品依然抱有熱情的 PM，總是好奇地想知道別人會提什么需求，在不在自己之前考慮的盲區之內，如果在的話，自己為什么想不到，以及以后如何才能不遺漏這樣的需求。

然而在問題描述中卻說面對各方的需求時，容易陷入混亂，我想當中的原因是非常值得探討的。
為什么會混亂？猜測主要有兩點原因：
1. 工作比較繁忙，工作流經常被臨時的需求提議打斷，導致原有的工作計劃未能按時完成，有時甚至遺漏掉
2. 各方都說希望自己的需求能夠早點被落實，但一個版本能做的需求確實有限，不知道如何推遲甚至拒絕他人的需求
第一點其實是 GTD 的事情，工作流被頻繁打斷確實影響效率，且十分消耗精力，讓人感覺疲憊和混亂。在產品經理怎么與團隊成員建立信任和信服感？ - 鄭堅義的回答中的 “跟進到位” 部分中有簡單說過 GTD 對于產品經理工作的重要性。其實，關于如何避免或者降低來自于他人的打擾，GTD 入門書籍《番茄工作法》里就有說到，要安排專門回應他人的時間。在這個時間段內，統一處理需要和他人溝通的工作事項，而在這個時間段外，遇到他人的 interruption 時，則會告知對方自己正在忙，要不在某某時間再溝通此事。一般只要不是什么緊急的事情，對方都不會拒絕這樣的請求。
雖然我在平常的工作中也不會嚴格地遵循《番茄工作法》，但只要我意識到自己正處于不應該被打斷的狀態時，都會請求對方稍后再聊。這樣也讓人感覺到你的時間是稀缺的，是需要被尊重的，而避免一些事無巨細的隨意打擾。
至于第二點，是需求優先級判定及版本規劃范疇的問題。
關于需求優先級的判定，在產品設計的“節奏感”該如何把握？ - 鄭堅義的回答有提及過，在這里簡單說一下哪些需求的優先級比較高：
1. 產品初期，快速地搭建重要功能優先級比較高
2. 有“窗口期”的戰略性需求優先級比較高
3. 與近期運營目標契合的需求優先級比較高
4. 性價比高的需求優先級比較高
5. 用戶反應惡劣的需求優先級比較高
其實要判定需求的優先級，是繞不開對需求有效性的分析的，在產品經理如何判斷一個新功能是否應該添加？ -，在此不做論述。
然而，在工作中我們發現，其實大部分來自于他人的需求，如果完全按照需求的有效性進行分析的話，優先級往往都不高，那是否就意味著要把他人的需求無限延期？事實上這樣做效果并不會很好，因為對于你或者對于產品優先級不高的需求，對于需求方而言卻非常重要。如果不做變通、一味地拖延，同事會認為你不配合他們的工作，難免產生消極的氣氛。每個版本我們都應該爭取出一些資源投放到配合他人的工作中，這樣以后他人也更愿意配合自己。
對于不能及時放進當前版本的來自于他人的需求，則需要主動跟對方說明版本的重點是什么，為什么排不上，以及會推遲到哪個版本處理。一般而言，如果能夠及時地同步需求的進展，并且表現出配合的積極性，別人都不會故意刁難你。
至于版本規劃，個人一直是提倡提前做好兩個版本左右的需求方案。在產品經理怎么管理項目進度？ - 鄭堅義的回答有說到，這樣可以靈活地調整或穿插需求，面對變化的時候不至于手忙腳亂。請記住，即便明知道每次規劃最終都會擁抱變化，但也一定要做好規劃，因為你必須梳理清楚每個版本的重點是什么。
最后簡單說一下很多人在回答中說到的需求池的管理。由于在需求管理上自己基本不需要與他人協同，而且會經?；仡?，所以我一般都不會標記優先級是 P 幾，至于需求的來源更是沒什么作用。在關于發現需求、篩選需求和設計產品，有哪些成體系的方法論？ - 鄭堅義的回答有說過如何挖掘需求，有零散地收集的、有專門抽時間進行行業調研及競品分析得來的，也有通過用戶的行為或者業務邏輯進行推導的。所有的這些需求，我最終都會通過一張樹狀圖把它們串聯起來。需求被落實后，相應的分支會從樹狀圖中被剔除掉。我的樹狀圖一般都是基于幾個維度去延伸的，這樣會盡量地避免遺漏。因為一些需求在某些維度去分析很容易挖掘出來，而再其它的維度卻很難被發現。對于我而言，屢試不爽的是產品業務數據維度的分析，四大分支分別是：拉新、留存、活躍及銷售。另外，數據統計也是一個通用的重要維度。對于不同的具體產品，還可以將關鍵指標作為一個單獨的維度給提出來。
之所以這樣進行需求池的管理，原因很簡單，因為所有的產品需求都應該緊緊圍繞如何提升產品數據去進行規劃。不要一味地做些花拳繡腿，或者僅僅是感動了自己的功能。

您也可以關注我們的官方微信公眾號（ID：ctoutiao），給您更多好看的內容。