產品需求應該如何管理？

目錄：

• 一、 為什麼要管理需求；
• 二、 什麼是需求：需要與需求、從功能性劃分需求分類、需求的層次；
• 三、 需求的來源：調研、使用者反饋、公司戰略、產品研究、政策與標準要求；
• 四、 需求收集記錄；
• 五、 需求管理：給需求分類、確定需求優先順序；
• 六、 需求變更：需求變更的原因、如何應對需求變更、需求變更的流程控制；
• 七、 需求的反饋；
• 八、 需求的後續處理。

需求對於產品的重要性，相當於一日三餐對於人的重要性，需求是我們產品不斷迭代的動力之源；本文所指需求，主要針對企業服務企業服務產品的需求，專案型需求和C端產品需求的處理會有差異，僅供大家參考。

一、為什麼要管理需求

需求的來源多樣，重要性、緊迫性也不一樣；如何處理好紛繁複雜的需求，對於產品發展至關重要。

如果處理不好，無法辨別出需求的範圍、重要性，無法合理安排需求的優先順序等，都可能將產品方向“帶偏”，浪費公司資源，錯失發展時機，失去產品競爭力，嚴重的將會將丟掉市場和客戶；相反，如果能夠識別關鍵需求、緊急需求、緊跟市場，需求處理及時得當，將有助於提高產品競爭力。

二、什麼是需求

在上一篇文章中，介紹到：需求=預期-現狀，這是一個簡單的描述，大家對於需求有一個形象的瞭解。

在不同的領域，對於需求有不同的定義，在產品中，我理解需求是與具體產品有相關性的、為解決具體問題而提出的、尚未滿足的要求。

1. 需要與需求

需要與需求兩個詞語相似，詞義相近，但在產品中，這兩個詞有比較大的差異。

需要往往為使用者提出的訴求，希望滿足某一個要求；而需求是與產品有相關性，並且一般為可設計、可實現的要求。

使用者“需要”一般經過提煉、轉化後才能成為“需求”，而有些需要受制於客觀限制，是不能轉化為需求的。

2. 從功能性劃分需求分類

需求一般分為功能性需求和非功能性需求：

• 功能性需求：是那些用以處理產品所必須滿足使用者需求的功能特性，功能型需求是最基礎也最核心的使用者需求，功能型需求有時也被稱為業務需求。
• 非功能性需求：包括可用性需求、效能需求、可靠性需求和安全需求等；這類需求在系統建設早期重視度往往不高，當用戶量上升，產品越來越重要時，非功能性需求的重要性越來越突出。

3. 需求的層次

提到需求的層次，一般繞不開馬斯洛需求理論，雖然這是基於個體的需求理論，但企業需求場景仍然具有借鑑意義；畢竟B端的產品使用物件，也是一個個鮮活的個體。

但總體上企業服務產品更多注重實用性和效率提升，對於美觀性和心裡滿足的要求相對較弱，但這是由行業現狀導致的；從長遠來看，企業服務產品應吸納借鑑C端產品設計的一些優秀特點。

企業服務產品需求有自身的特點，比如：

• 企業服務產品面向企業或組織，幫助其解決企業經營或管理問題；對於組織來說，需要企業服務產品提供基於管理場景的功能，無法簡單的透過馬斯洛模型來定義描述；
• 企業服務產品的使用物件，也需要關注業務使用者；而業務使用者的需求動機，同馬斯洛需求模型有一定的交叉，但並非完全適用；
• 企業服務產品作為業務管理或協同系統，除了承載業務目標，還需要考慮軟體架構設計、體系構建、生態構建等問題（C端產品的後臺同樣存在類似的問題）；因此需求分析管理中，對於軟體產品本身還需要有足夠的關注度。

基於此，企業服務產品也可分為幾個層面的需求：

1）業務需求

業務需求實際上為滿足企業某一使用場景和目的，必須實現的功能，主要體現在滿足業務規則、管理制度、業務流程等方面。

比如開具一張發票，需要有發票資料相關欄位的錄入功能；新增一張憑證，必須錄入一些摘要、科目、借貸方等資訊；再比如一些工作審批流程功能，沒有流程的相關處理，就沒法完成業務的流轉。

2）使用者需求

企業服務產品的使用物件，是一個個有情感的人，在滿足業務需求後，產品是否好用，會成為評判產品優劣的重要指標。

產品頁面表達是否清晰、操作是否便捷、反饋是否準確、效率能否提升，都是使用者體驗相關的重要因素。

我們在一些專案型需求中，經常會專注於滿足業務需求；但在SaaS、PaaS等平臺型產品中，僅滿足於業務需求，是遠遠不夠的；產品在具備良好的產品體驗後，才會真正具備一定的市場競爭力。

3）產品需求

產品需求一般是由產品團隊自發提出的，基於公司戰略及產品戰略，滿足企業持續發展的需要，如使用者中心、訊息中心、訂單中心、賬戶中心、簡訊服務、郵件服務、認證中心等服務建設。

解決產品發展的重複建設問題，搭建技術中臺服務；滿足產品生態建設，建設代理、運營管理平臺，建設合作伙伴開放平臺等等，都可以歸類於產品需求——產品需求在一定階段又會轉化為業務需求和使用者使用者。

業務需求是企業服務產品的需求基石，需求功能的健全程度決定企業使用者是否能夠使用產品；使用者需求解決企業服務產品體驗的問題，是企業服務產品具備競爭力的主要產品因素，滿足使用者更好的使用產品的訴求；產品需求基於集團戰略及產品戰略的規劃而提出，為企業服務產品的可持續發展及最終成功提供產品支援。

三、需求的來源1. 調研

需求調研有多種方式，有行業調研、使用者訪談、需求溝通會等等，其中：

• 行業調研：包括行業研究、競品分析、典型使用者分析等；
• 使用者訪談：與使用者的電話會議、跟蹤使用者工作場景、訪談等方式，獲取需求；
• 需求會議：與相關方開展會議，收集使用者需求；組織頭腦風暴會議，激發大家的觀點碰撞。

需求調研的方式多樣，在產品的不同階段、產品所在的不同行業、不同場景，需要選擇不同的調研方式；需求調研的每一種方式方法，都可以作為專題來研究。

2. 使用者反饋

1）測試反饋

測試人員在測試系統的過程中，實際是在模擬使用者的操作；在這個過程中，可以發現一些系統問題，提出比較好的需求建議，特別是使用者體驗相關的建議。

2）客戶反饋

實際使用者在使用過程中，會發現一些系統提供的功能同實際操作需要之間不匹配的一些功能點，如果溝通渠道通暢，也會收集到一些使用者反饋的需求。

3）運營反饋

在一些有運營支撐部門的公司，運營團隊會代表使用者向產品團隊提出使用反饋的需求，以幫助產品改進。

使用者反饋和需求調研的差異，主要在於是主動還是被動的收集需求。

3. 公司戰略

公司會根據發展需要，推出一些新的發展方向或者提出新的產品方向，對這些公司戰略的分解與分析，形成產品需求。

公司戰略形成的需求，有些可能不是真實的使用者需求，有些是在創造使用者需求，這些都需要產品同學花費更多的精力去研究，對產品有更好的預判能力，避免產品掉入“偽創新”的泥坑。

4. 產品研究

產品同學可基於對行業的理解、使用者的研究，規劃產品設計，對產品進行最佳化迭代；產品研究一般更側重產品宏觀發展和產品內在管理邏輯的實現。

5. 政策與標準要求

在一些國家監管或者存在行業管理標準的行業中，企業服務產品需要滿足國家的政策、檔案及行業標準的要求，為此需要設計相關的功能、流程、管理機制，確保產品本身合法規範。

此類需求，需要產品同學或者公司反饋機制，去查詢相關的政策、檔案、標準，並確保產品及時更新，在要求的時限內完成或儘快完成產品改造，滿足監管要求。

四、需求收集記錄

透過多種渠道獲取需求後，一定要對需求進行記錄，我總結需求記錄一般遵循以下原則：

需求來源可追溯：一般需要對需求來源記錄清楚，當有些需求問題存在不確定性或需要對異常流程進行補充處理時，可以再次進行溝通。

需求場景可還原：需求記錄要能夠清晰的描述使用者實際場景需要，看到需求記錄的相關描述，要能夠明白使用者的實際需要是什麼，儘量不要產生歧義，避免難以理解的需求記錄。

需求分析可實現：需求記錄的問題，應該是經過一定的過濾，比如重複問題、與系統無關的問題等，這些問題需要在更靠前的環節解決掉，需求記錄的問題應該是可實現或理論可實現的需求。

需求推進可持續：有時會存在需求後續推進過程中，提需求的人，我們已經找不到或者無法確認，這種情況時有發生。一個後續無法獲取反饋的需求，上線後無人使用，會浪費團隊大量的精力，我們在需求收集階段，就需要開始辨別此類風險。

需求採集表一般需要體現出如下資訊，比如需求來源（比如客戶、企業員工等）、提出人、提交時間、企業客戶名稱、客戶聯絡人、客戶聯絡方式、需求描述、涉及系統、功能節點等，也可以根據產品的實際情況，調整需求記錄的專案。

五、需求管理1. 給需求分類

做需求管理時，我們需要先弄清楚幾個問題，這個需求是否為個性化需求？覆蓋的使用者範圍有多大？帶來的價值有多高？緊迫度有多高？如果對需求工作量有一定的判斷經驗，可以初步評估實現的難易度和工作量。

需求影響力：指需求能夠影響的使用者範圍，對使用者影響範圍越大，得分需要越高，反之越低；例如分值可以為5、4、3、2、1、0，其中5代表最大範圍，0代表無影響範圍。

需求複雜度：評估需求影響產品範圍,可透過數值來標識，可以透過判斷影響功能範圍、複雜度高低，進行評分，用於評估後續的實現難易程度；影響功能範圍越大，複雜度越高，實現難易度就越困難，反之越容易，可用數值進行標識；例如分值可以為5、4、3、2、1，其中5代表實現最簡單，1代表實現最複雜。

需求緊急度：可跟提交需求的夥伴溝通優先順序，瞭解緊急程式，也需要根據產品同學的經驗進行判斷，對於業務需求、阻斷流程需求、政策性需求，可給與較高的緊急程度；例如分值可以設定為5、4、3、2、1,5代表最緊急、1代表不緊急。

需求價值：需求價值可區分為經濟價值和產品價值（沒有想到特別好的命名）。

需求經濟價值是指這個需求的滿足，是否能夠直接帶來經濟價值，在企業服務SaaS產品中，會有客戶願意為某一定製化功能買單；對於SaaS產品來說，需要慎重評估經濟價值和需求影響力之間的關係；例如分值可以設定為5、4、3、2、1進行評估。

需求產品價值：可透過典型的KANO模型進行分類，KANO模型將需求分為五類。

• 必備需求：當最佳化此需求，使用者滿意度不會提升，當不提供此需求，使用者滿意度會大幅降低；
• 期望需求：當提供此需求，使用者滿意度會提升，當不提供此需求，使用者滿意度會降低；
• 魅力需求：使用者意想不到的，如果不提供此需求，使用者滿意度不會降低，但當提供此需求，使用者滿意度會有很大提升；此類需求處理得當，可以很快提升產品競爭力。
• 無差異需求：無論提供或不提供此需求，使用者滿意度都不會有改變，使用者根本不在意；
• 反向需求：使用者根本都沒有此需求，提供後用戶滿意度反而會下降。

KANO模型經常用於C端產品需求分類的工具，關於KANO模型的應用，可以參考《善用KANO模型，做需求分類與評估優先順序》，辛小仲老師對於KANO模型的理論和實操做了非常詳細的講解，可以透過需求調研問卷的形式獲得相對準確的KANO分類，再透過Better-Worse係數確定落入的象限範圍，判斷需求優先順序。

一般來說，可以分別使用3、2、1、-1、-2來分別代表必備需求、期望需求、魅力需求、無差異需求、反向需求。

需求價值可以透過需求經濟價值+需求產品價值來表達。

2. 確定需求優先順序

處理需求的過程中，很重要的事情就是確定需求優先順序，優先順序的確定可以參考使用ICE方法。

ICE是將需求分為影響範圍、自信程度、實現難易3個層面進行評估：

• 影響範圍是指需求的影響力；
• 自信程度是指使用者對需求實現能夠帶來好的反饋的程度；
• 實現難易是指技術實現需求的難易程度。

在上個章節中，我們將需求進行分類打標籤，我們對需求分類標籤的目的，是希望透過對需求進行客觀的分析，以數值的方式記錄評估；然後對需求的總得分比較排序，儘量避免用拍腦袋的方式定義分值，讓使用ICE方法時更加合理。

• 影響範圍：可以用需求影響力*需求產品價值來表達；
• 自信程度：可以使用緊急程度+需求價值來表達；
• 實現難易：可以透過需求複雜度的分值來表達；

最終將每個需求的ICE三個分值相加，根據得分順序，排列需求優先順序。

對於每一個需求的歸類和分值定義，可以在實際的操作過程中進行調整，摸索出一套適合自己產品的方法。我們在對外溝通的過程中，也可以將確定優先順序的方法作為一套標準，爭取各環節共識，各環節能夠理解並達成一致後，有助於產品推進。

六、需求變更

需求變更是難以避免的。

有人說唯一不變的就是變——我深以為然，變更對於產品來說可能是好事也可能是壞事，所以我們需要做好需求變更的控制——對需求變更的管理，不是為了杜絕變更，而是降低需求變更對產品的負面影響，讓產品向更好的方向發展。

在PMP的知識體系中，對於需求變更非常重視，在傳統的瀑布式專案開發過程中，需求變更意味著專案計劃的調整、資源投入的調整，實際情況是大多數情況都會導致專案進度延期或者增加資源投入。

在產品迭代（常採用敏捷開發的方式）過程中，我們對於需求變更的控制力度或流程管控力度有所降低，迭代開發模式追求快速上線、快速試錯、快速調整，本身也容易導致需求變更的發生。

1. 需求變更的原因

前期需求不夠明確：我們在一些產品早期或者功能早期建設過程中，有時會缺少參照，需要進行一些產品創新；此時對於需求的評估還不夠精準，使用者研究也不夠透徹，上線往往需要根據使用者反饋調整產品設計。

業務場景不夠了解：我們在分析客戶的使用場景的過程中，由於自身專業知識水平和行業經驗的限制，對業務的使用場景不夠了解；對使用者的需求描述，僅看到表面問題，沒有分析到本質問題，設計出來的產品，往往不能滿足客戶的真實完整需要。

業務形態發生變化：當公司的商業形態或者業務運營邏輯發生變化時，我們也需要根據情況進行調整；這類問題在業務主導型公司經常發生，產品團隊作為提供服務方，往往會比較被動。

2. 如何應對需求變更

在管理的過程中，我們需要根據造成需求變更的原因，有針對性的進行管理，在有些產品中，多種情況可能會同時出現。

對於需求不夠明確的情況，我們需要控制需求量，避免一次投入過多的工作量，採用小步快跑的模式，減少資源的浪費。

因為業務場景瞭解不夠導致的需求變更問題，在設計產品前，需要產品人員多方面、深入、客觀的瞭解業務需求，增強自身對業務場景的認知，瞭解需求的真正痛點，不要浮於表面。產品設計過程中，多考慮新需求的相關性，有助於發現更多的場景問題；在產品評審時，需要仔細跟使用者討論確認（有條件的情況下），讓使用者幫助評估是否符合業務場景，對於客戶的疑慮或不解，多追問、多瞭解。

當業務形態發生變化時，需要評估影響範圍和緊迫度，比如公司戰略調整，就需要儘快全面響應需求變更。

當業務管理部門的頻繁變動或業務規則頻繁調整時，我們需要適當降低需求的優先順序；在設計產品的過程中，針對這類頻繁變更的需求，產品同學需要注意總結需求變更前後的特點，找到規則，透過可配置的產品設計實現需求，讓使用者自行配置，保持產品功能的靈活性，減少需求的變更。

在實際的需求管理過程中，需求變更的原因是比較複雜的，有產品自身的原因、有業務的原因、公司管理的問題；我們需要根據具體情況具體分析，當遇到較大的需求變更風險時，應及時反饋到上級。

3. 需求變更的流程控制

在產品迭代過程中，變更的需求往往被作為新需求進行處理，這是目前一些公司的現狀，產品同學可根據自己所在公司的情況，選擇需求變更的控制流程。

但總體來說，遇到需求變更時，需要提升對變更需求的風險關注度。

我們可以總結出相對通用的需求變更控制流程，作為參考：

• 變更申請：如果使用者需要變更需求，最好提出《需求變更申請》，經客戶方和服務方共同確認後，傳送內容給產品需求對接人。
• 變更分析：產品人對接人收到變更需求時，將問題錄入到需求收集表，標識問題型別；接下來組織團隊分析需求變更影響、緊急度、需求價值等。
• 變更決策：團隊相關人員進行內部變更評估、稽核，決定哪些變更無法修改並說明原因，哪些變更需要修改和什麼時候修改。
• 變更實施：需求變更通過後，確定開發時間和納入的版本，制定開發計劃；
• 變更驗收：對於需求變更而進行的版本更新，需交付相應的《版本更新說明》。

七、需求的反饋

我們在確定大致的需求優先順序後，根據專案團隊的初步評估，確定上線週期，及時同各方做好需求的反饋工作。

新產品和處於迭代中的產品，在處理需求的過程中，會有一些差異。

新產品一般需要經過立項過程，其需求來源相對簡單，溝通反饋過程也相對簡單；而迭代中的產品，可能會出現部分需求重要但沒有馬上給出排期計劃的情況，需要分別對待。

一般在溝通需求反饋時，需要對需求受理狀態、解決方案、解決時間等給出響應。

八、需求的後續處理

在需求管理完成後，後續還有很多工作需要處理，比如產品設計、產品評審、UI設計評審、研發過程跟進、配合測試評審、產品驗收、產品釋出、收集反饋意見等，這些內容我們會在後續章節繼續探討。

本文由 @原始森林 原創釋出於人人都是產品經理，未經許可，禁止轉載

題圖來自 Unsplash，基於 CC0 協議