處理需求是每一位産品經理都需要面對的基礎工作，如何安排好各個需求的排期？怎樣合理安排工作？本文作者将結合自身工作經驗和相關理論，為你講解需求管理是什麼，以及如何進行有效的需求管理，希望對你有幫助。
作為一名B2B産品經理，我的崗位主要職責之一就是需求管理。在我每天的工作中，我面臨的主要挑戰在于需要同時支援内部多個業務線，并為外部客戶提供高度個性化的定制服務。這意味着，我的需求管理工作需要應對各種複雜場景，如内外部需求的平衡、多個業務線的協調以及多個開發團隊的協作。
在本文中，我将結合自身工作經驗和相關理論，為你講解需求管理是什麼，以及如何進行有效的需求管理。無論您是一名産品經理，還是對需求管理感興趣的讀者，我相信這篇文章會對您的工作和學習有所幫助。
一、需求管理是什麼
首先，需要明确一個觀點：需求管理并不僅僅是簡單地管理需求優先級。真正的需求管理是涉及需求的整個生命周期，其中包含需求産生、需求分析、需求優先級、需求開發與測試、需求驗證、需求結項以上六個方面。是以，隻有同時關注以上六個方面，才能算得上真正全面的需求管理，也隻有這樣才能確定需求管理的有效性。
接下來，我們從上述六個方面出發，為您逐層進行分析和闡述需求管理的實作途徑。請您仔細閱讀每個方面的内容，以全面提高您對需求管理方案的認識和了解。
二、需求産生
2.1 需求來源
B2B産品經理的需求來源管道衆多，主要管道有：業務部門、外部客戶、研發、産品、營運、運維、老闆等等。
上述管道産生需求大緻原因如下：
- 業務部門：制定業務目标時，當發現産品功能無法支援業務目标實作，則會産生需求。
- 外部客戶：新的業務合作或已合作業務進行優化時，則會産生需求。
- 研發部門：技術更新或技術架構調整，當需要産品經理配合時，則會産生需求。
- 産品部門：産品經理自驅進行産品功能建設或重構時，則會産生需求。
- 營運、運維部門：日常營運和運維時發現使用者使用問題或可優化功能時，則會産生需求。
- 老闆：參加某些論壇或高層交流等情況時，則會産生需求。
2.2 需求産生過程
接下來，以需求産生最多的管道且最典型的“業務部門“為例，深入剖析需求産生的的底層邏輯。
首先，業務目标是需求的起點。業務為了自身發展，制定業務目标。業務為了完成目标，就會制定相應的業務政策，即行動路徑，以達成目标。但這期間可能會發現，現有系統能力不支援業務的政策，不能支援達成目标，就會産生業務痛點。
業務痛點是代表在完成業務目标時，在行動過程中遇到了問題或障礙。但是在業務中，不同的人對痛點的認知和了解是存在差别的，高層管理者更清楚自己的業務痛點以及對目标的影響程度，而基層員工對痛點的了解更多停留在操作層面和自我層面。是以，業務痛點和業務目标關聯性越強，越容易得到重視，也最容易産生業務需要。而對業務目标影響不大的痛點、業務可以忍受的痛點、甚至業務自己都不知道的業務痛點，反而極少産生業務需要。
業務需要是源于業務痛點的一種感覺缺失的狀态，業務為了滿足自己的需要，就會尋找解決方案。如果發現這個業務需要可通過内部流程優化、人工處理等方式暫時解決，那麼就不會産生業務需求，隻有當業務内部無法解決時，需要依靠外部（産品經理）解決時，才會産生業務需求。
綜上，這個由“業務目标→業務政策→業務痛點→業務需要→業務需求”的轉化過程，是産生需求的底層邏輯。
産生業務需求（MRD）需三個條件：
- 系統現狀不滿足業務政策或計劃。
- 業務認為痛點必須當下解決。
- 自己無法解決，隻能尋找産品解決。
由此及彼，其它管道也遵循上述需求産生的底層邏輯，讀者可以把上述圖檔中“業務”替換為“其它管道目标”進行了解。如：外部客戶因某個業務增長目标，産生新的需求；研發因為某個降本增效的研發目标，産生新的需求；營運部門因為某個體驗營運目标，産生新的需求等等。
三、需求分析
産品經理承接來自各管道的需求，并且投入大量精力實作業務需求。但是，卻經常出現需求中途廢止、上線後不符合業務訴求、未取得預期結果等問題。雖然造成以上問題的原因很複雜，但其中一個最關鍵的因素就是産品經理錯誤地分析了業務需求。
需求分析是什麼？需求分析是：通過分析需求産生過程，識别真正的需求并排除虛假的需求。其中，分析需求産生過程，就是分析“目标→政策→痛點→需要→需求”的過程。那麼，如何進行有效的需求分析呢？接下來，我介紹兩種需求分析方法，都是産品經理日常工作中常用的方法。
方法一：使用5why分析法分析需求産生過程
首先，我們從高次元進行需求分析，即對需求産生過程進行分析。從需求産生過程來看，一個業務需求的形成，到最終傳達至産品經理，是需要經過漫長的流程和多重決策，資訊在傳遞過程中必然會失真。我們可以通過5why方法，分析過程是否存在問題，以保證需求的真實可靠。
是以，産品經理在分析需求産生過程時，可以嘗試問以下問題：
- 業務目标是否合理？目标是否過高或者過低？是否可量化？
- 實作業務目标的政策，是正确路徑麼？
- 業務痛點真實麼？是高層的痛點，還是基層員工的痛點？現狀無法滿足麼，還是他們不會操作？真的影響業務政策麼？
- 業務需要是對業務痛點的真實回報麼？必須現在解決麼？
- 業務需求的方案是唯一解決方案麼，合理麼？業務内部不能自行解決麼？
- 上線後能否助力目标達成？能為目标貢獻多少？投入産出比合理麼？
以上羅列的問題僅抛磚引玉，建議産品經理在實踐中嘗試從不同角度、不同環節進行分析，鍛煉需求分析的能力。
方法二：使用“場景、角色or系統、流程”分析方法
接下來，我們從細次元進行需求分析，即對需求内容進行分析。首先，使用“場景、角色、流程”方法，進行業務流程梳理，進而設計出正确、合理、可執行的業務流程。其次，使用“場景、系統、流程”方法，并結合産品架構能力，将業務流程設計成正确、合理、高效的系統流程。通過以上兩個方法，可以産出業務流程圖和系統流程圖，是産品經理設計方案的關鍵内容。
案例：
業務背景：我司屬于物流平台公司，面向物流市場中大客戶及中小客戶銷售物流服務産品，為客戶提供物流配送及倉儲行業解決方案。是以，需要與客戶簽約，并進行合同單據管理，以作為合同物流憑證。
首先，通過“場景、角色、流程”梳理業務流程。從中發現大客戶與中小客戶合同簽約流程不同，大客戶流程更複雜、更長，而中小客戶流程相對簡化和标準。如下圖：
最後，通過“場景、系統、流程”設計系統流程。（此處作者有意簡述，實際業務場景、系統角色會更加複雜。且針對業務流程與系統流程如何制作，此處不再進行詳述，讀者可以參考BRD、PRD寫作規範進行學習。産品架構能力可參考作者之前文章：https://www.woshipm.com/pd/5794522.html
四、需求優先級管理
從需求優先級的表象看，是在對需求進行排序和取舍，但其背後的實質是：協同業務、研發、測試等部門達成目标一緻， 且高效、合理的利用資源，進而 保證目标達成。
産品經理作為需求優先級管理主要負責人，在協同各方目标達成一緻以及進行資源配置設定時，面臨的難點主要有以下幾個方面：
其一，多部門間的目标取舍、排序問題。需求會同時來自多個管道，會存在多個目标，如業務、産品、研發、營運等目标，對不同部門間的目标取舍、排序是很困難的。
其二，多業務線間的目标取舍、排序問題。面對不同業務線時，當不同業務線的發展階段不同、業務規模大小不同時，對不同業務間的目标取舍、排序是很困難的。（該問題雖被第一點包含，但此處仍被提及，是因為相比多部門間的目标取舍，它更難）
其三，多目标并行時資源配置設定問題。需求雖有先後順序，但實際工作中都是多需求并行。是以，如何配置設定資源并保障多目标都完成是很困難的。
其四，臨時且緊急需求的處理問題。臨時且緊急需求會對現有排序造成巨大沖擊，導緻需要重新排序、重新配置設定資源。是以，既要處理已排好需求，又要滿足緊急需求是很困難的。
通過以上難點不難看出，需求優先級管理考驗的就是：當産品經理面對跨業務線、跨部門 等複雜場景時的 協同溝通能力。
接下來，重點介紹兩個需求優先級管理方法：定量分析法和定性分析法。首先，要先聲明一點，需求優先級管理工作是十分複雜的，上述兩個方法僅能起到輔助作用。若想做好需求優先級管理工作，仍需先具備優秀的協同溝通能力，再結合方法的使用才可做好。
4.1 定量分析法
優先級的評估如果僅憑個人感性判斷的話，會很難讓多位相關方對優先級達成一緻。為了盡量避免個人喜好或偏見帶來的影響，我們需要引入更科學的方法，通過綜合評分打分評價法（或權重求和法）來對需求優先級進行量化。具體步驟如下：
第一步：确定标準。選取和制定優先級衡量标準時，要與其它部門充分溝通，確定衡量标準得到多方認可。
案例：以某工作機關為例，優先級衡量标準有“目标類型、需求來源、重要&緊急程度、收益類型”4個，其中，每個标準下子類目有：
目标類型：公司戰略目标、業務戰略目标、産品目标、疊代優化目标等。
需求來源：業務部門、外部客戶、研發部門、體驗部門等。
重要&緊急程度：重要緊急、重要不緊急、不重要緊急、不重要不緊急。
收益類型：業務規模增長類、效率提升類、體驗提升類、創新類等。
第二步：确定打分标準。制定各标準及标準子類目分值，也要與其它部門充分溝通，并得到多方認可。
案例：仍以上述機關為例，共計4項标準，總分數為80，每個标準均為20分。其中：
- 目标類型（公司戰略目标-20分、業務戰略目标-15分、産品目标-10分、疊代優化目标-5分）
- 需求來源（業務部門-20分、外部客戶-20分、研發部門-10分、體驗部門-5分）
- 重要&緊急程度（重要緊急-20分、重要不緊急-15分、不重要緊急-10分、不重要不緊急-5分）
- 收益類型（業務規模增長類-20分、創新類-15分、效率提升類-10分、體驗提升類-5分）
針對打分标準，有以下幾點補充說明：
- 需求優先級管理中，“綜合打分評價法”相比“權重求和法”應用的更多，因為不同标準間相關性較差，标準間不同權重與實際情況不符。如：目标類型與需求來源之間，無法制定誰的權重更高。
- 綜合打分評價法的分值問題。采取各标準分值相同政策，理由同上。如：若目标類型為30分，需求來源10分，這樣劃分是不合理的。
- 權重求和法使用問題。常見應用于各标準之間可區分重要程度的場景下，讀者可以依據實際情況采用。如：A30%+B20%+C20%+D30%=100%。
第三步：打分。針對不同需求進行打分，确定最終得分。
案例：以上述機關為例，最終打分結果如下：
針對打分，有以下幾點補充說明：
- 打分的前提是：隻有詳細了解需求的目标、收益等資訊後，才能做出客觀、正确的判斷。
- 打分的結果要定期回顧與評估。因為外部環境時刻都在發生變化。如：不緊急需求變成緊急需求、業務部門目标變成公司戰略目标等，分值在變化。
4.2 定性分析法
需求優先級管理僅依靠定量分析法，是不能解決全部問題的。因為，定量分析法不能覆寫全部場景。是以，為使得需求優先級管理更加全面、合理、靈活，還需要使用定性分析方法。
定性分析法屬于感性的判斷，筆者認為定性分析法更多的是來自經驗的積累，憑借“經驗”進行需求優先級管理。我總結了以下經驗，分享給讀者：
- 開發周期短的需求，可以搭車其它相關項目或見縫插針進行開發。
- 産研需求可選擇搭車業務需求，通過一個需求，達成多目标。
- 産品方案設計時，要考慮産品長期規劃目标。說服業務接受更長周期但更合理的産品方案，既滿足業務目标，又能達成産品長期規劃目标。
- 重點關注“重要不緊急”需求，避免變成“重要緊急”需求。
- 周期較長的需求，若上線時間緊張，可采用分批次、分階段實作。
- 老闆或客戶的緊急需求。首先，不要盲目執行和推進。其次，嘗試與老闆、客戶溝通了解背景及原因等。最終可能發現是僞需求或非緊急需求。
- 資源緊張無法按期望上線時，可以嘗試營運、業務線下方案臨時兜底。
- 建議優先處理外部客戶需求，再處理内部需求。一方面以客戶為中心，避免客戶投訴或流失，另一方面，内部需求屬于内部沖突，可以關起門來解決。
- 線上BUG不要進入需求池管理，而應及時解決。
五、需求開發與測試
需求進入開發測試階段後，大部分産品經理認為無需進行需求管理工作，隻需等待上線即可。其實不然，若在該階段出現延期、開發測試品質等問題，仍會影響需求的傳遞。是以，在該階段，需求管理工作仍必不可少！
接下來，分别從“需求開發”與“需求測試”詳述産品經理應做哪些需求管理工作，以保證需求順利傳遞。
5.1 需求開發
在需求開發階段，産品經理要重點關注以下兩點：其一，關注開發是否按計劃進行，有無風險。其二，關注開發品質，保證高品質傳遞。
首先，關于第一點。産品經理應熟練掌握項目管理相關技能，并對需求進行常态化項目管理。例如組織産、研、測日站會、項目周會、需求進度溝通會等。通過定期與研發盤點開發進展及問題，進而提前識别風險，并及時采取措施，避免延期。
其次，關于第二點。雖然産品經理不參加開發工作，無法直接為代碼品質負責，但可以通過建設合理的開發流程，以實作高品質的傳遞。建議：①增加“技術方案概要設計、技術方案詳細設計”評審環節，且産品經理參與評審，把控技術方案符合産品訴求。②增加“代碼評審”環節，架構師參與評審，把控代碼品質。（Ps:如果讀者公司沒有以上流程，産品經理可以發起流程變革，但确實無法增加，那麼隻能自求多福了。）
5.2 需求測試
在需求測試階段，産品經理要重點關注以下兩點：其一，關注測試是否按計劃進行，有無風險。其二，關注測試品質，保證高品質傳遞。
首先，關于第一點。參考上文需求開發第一點。讀者可同時管控開發、測試進展及問題。
其次，關于第二點。建議：
- 增加“測試用例評審”環節，且産品經理參與評審，把控測試場景覆寫全部功能場景。
- 要求測試人員記錄并回報測試問題，并追查問題産生原因，以提升産品、研發、測試品質。
- 測試完成後，産品經理要進行線上驗收。
六、需求驗證
這個環節是最容易被産品經理忽略的環節。大多數産品經理認為，需求上線後就完成了自己的工作，對需求目标是否達成不太關心，并将這視為業務部門的職責。然而，這種想法往往會導緻我們錯失成功的機會。是以，作為産品經理，我們必須“以始為終”，始終牢記需求的初衷，在需求驗證環節中確定需求目标得到充分的實作。隻有這樣，我們才能最終摘取成功的果實，也才能讓需求管理的旅程更加完美圓滿！
接下來，講解在需求驗證階段，産品經理應該采取哪些需求管理工作。
首先，産品經理應該重點關注和參與“三個計劃”的制定與執行。“三個計劃”即：灰階計劃、推廣計劃、營運計劃。雖然它們從職責上是屬于業務方（需求提出方）工作，但它們卻是影響需求能否取得業務結果的關鍵因素。
産品經理應采取如下管理動作：
- 其一，灰階計劃。與業務協同制定灰階目标、場景、時間等，確定灰階期間快速驗證産品方案的可用性及可行性。
- 其二，推廣計劃。與業務協同制定推廣目标、範圍、時間等，確定産品方案可複制，達成業務預期目标。
- 其三，營運計劃。與業務協同制定穩定、長期、高效的日常營運流程，確定産品方案持續産生穩定的業務結果。（讀者尤其要注意，以上三個計劃，雖有先後順序，但盡量一起制定，避免脫節。）
其次，在制定和執行三個計劃時，同時要建立業務資料名額體系。資料名額體系應包含可衡量項目過程和結果表現的名額。名額體系應是客觀的、可量化的，以便更好地監測和評估項目進展以及業務成果。建議參考亞馬遜：Input、Output、觀測名額方法。
最後，疊代産品方案或調整計劃。通過對資料名額體系的監控及分析，找出産品方案、灰階&推廣&營運計劃中存在的問題，分析原因并制定解決方案，及時調整計劃或疊代産品方案。
七、需求結項
需求結項是需求管理旅程的最後一個環節。一般情況下，隻有單獨立項或較大項目才會有這個環節，其它需求在需求驗證通過後就已結束。需求結項階段的核心工作是進行需求結項文檔編寫，并組織結項會議，完成項目的結項。
作為産品經理，需要完成結項文檔的編寫及結項會議的召開。接下來，分别從“結項文檔”和“結項會議”講解産品經理如何進行需求管理。
首先，結項文檔内容主要包含四個方面内容：回顧目标、評估結果、分析原因、總結規律。其中，回顧目标：主要是編寫當初的目标是什麼。評估結果：評估現有結果，判斷是超額完成目标、符合預期目标，還是未完成目标。分析原因：分析實際結果與當初目标差異原因。總結做的好或不好的原因是什麼。總結規律：通過對問題的原因分析，從中總結經驗和規律，為以後工作起到指導作用。
其次，結項會議要組織相關業務、産品、研發、測試等人員參加，針對結項文檔進行閱讀和讨論，共同學習經驗和規律，促進團隊成長。
最後，關于需求結項工作，有幾點需要着重關注。首先，結項文檔的撰寫應該客觀、實事求是，不扭曲事實。其次，在讨論問題時應強調事情本身，而不是關注個人責任。第三，結項會議旨在總結經驗、教訓和規律，而不是追究責任或抱怨。最後，我們需要總結好的經驗和規律，同時也需要總結不良經驗，即我們在過程中遇到的問題和諸多挑戰，進而汲取教訓，防止重蹈覆轍。
八、總結
需求管理是産品經理日常工作中非常重要的一環。本文詳細地講述了如何從需求産生、需求分析、需求優先級、需求開發與測試、需求驗證、需求結項六個方面實作有效的需求管理。但要更好地完成需求管理工作，讀者必須不斷練習和多次應用，積累經驗并不斷優化。願讀者通過此文的指南和建議有所進步，也歡迎各位讀者留言交流經驗！
九、案例分享：排期那點“破事”
這個故事是這樣的，我有個業務項目，需協同其它研發團隊開發。但是評審完成後，該研發團隊回報暫時沒有資源開發，等待資源釋放後再定。給出的理由主要有兩條：
第一、相比其它業務線項目，項目收益太低，以後再做。（潛台詞：項目太小，成績不顯著，不想做，要做就做大的）
第二、如果想做，那各業務線之間先協調下項目優先級。（潛台詞：資源就這麼多，我能怎麼辦？業務線自己PK去吧，誰赢了做誰的）
作為業務體量較小的産品經理，你是不是也遇到過上述場景？是不是很卑微、無助且可憐？接下來，讓我告訴你，我是如何處理并解決這個問題。
針對第一個理由“相比其它業務線項目，項目收益太低，以後再做”。
首先，你要了解各業務線發展情況，以及自身業務線處在什麼階段，要做到知彼知己。結合自身業務實際，我是這樣處理回複的。
第一，不同業務線的市場規模是有大小之分的，這是天生屬性，進行橫向收益對比是不公平的。雖然我們業務線市場規模小，但都是關鍵頭部客戶，也是公司整體重要市場之一。是以規模不是衡量收益的唯一準繩，而應看項目對業務本身發展的重要程度。
——潛台詞：對不起，你的排期邏輯我不認可。如果按照你的邏輯排期，那麼市場規模小的業務線項目收益永遠最低，豈不永遠無法排到？
第二，我們業務線産品建設階段已經從“初期大規模建設”發展為“功能疊代優化建設”。去年已經完成大規模基礎建設，現階段就是針對上階段進行補充和優化。該階段項目的特點就是項目小、收益低。這是産品生命周期發展的必經階段，預計未來會長期處于該階段，大家需要有清晰的認知和共識。
——潛台詞：要認清不同階段，工作是不同的。這個階段工作就是這個特點，難道這個階段的項目都不做了麼？
針對第二個理由“如果想做，那各業務線之間先協調下項目優先級”。
這個理由也是研發常使用的，往往産品經理此時也會讓業務内部進行橫向溝通，其實是不對的。我是這樣處理回複的。
第一，各業務線僅為自身發展負責，不為其它業務線發展負責，也僅知道哪個項目對自己最重要。
——潛台詞：哪個業務會舍棄自身發展，而成全其它業務線發展，不管自己的績效了？通俗點，都是屁股決定腦袋，兩個業務都覺得自己最重要，怎麼辦？
第二，需求管理的職責應在平台型研發部，而不在各業務。各業務線需求應單獨管理，且應預估各業務線需求量，提前準備和配置設定研發資源。避免各業務線資源沖突，否則就會出現被業務投訴資源安排不合理、贻誤業務發展等問題。
——潛台詞：認清自身職責，不要甩鍋，甩鍋的結果就是被反噬，不如提前做好需求管理工作。
以上，就是我處理該問題的方式，你也可以結合自身情況調整政策，抓緊試下吧！當然，雖然場景是發生在産品與研發之間，你可以進行總結歸納，靈活應用到不同公司不同崗位上。
作者：澤哥産品筆記，微信公衆号：澤哥手記（id：xmind1016）
本文由 @澤哥産品筆記 原創釋出于人人都是産品經理。未經許可，禁止轉載。
題圖來自 Unsplash，基于 CC0 協定
該文觀點僅代表作者本人，人人都是産品經理平台僅提供資訊存儲空間服務。