做好需求分析需要注意這幾個關鍵點

“接需求”是產品經理（下文簡稱“PM”）工作中必不可少的一環，文章中筆者會結合自己的親身經歷，講述做好需求分析的幾個關鍵點，希望能給剛入行和打算入行的朋友們一點兒啟發。

需求分析在產品生命周期中佔有重要的地位，決定着產品做出後被用戶接納的程度。通過對接觸過的PM進行觀察，我發現大部分人進行需求分析時做的事情大同小異。故總結出幾個關鍵點，形成一個可以應對大多數需求的操作方法。

說明：由於筆者一直從事ToB產品的工作，故本文所述的方法只針對此類產品，不保證對ToC產品適用。

一、需求從哪裡來的

需求是某些用戶在特定場景下為了得到某種服務或功能而提出的訴求或建議，它是產品的組成部分，也是產品最終要達到的目的。它可以是老闆的一句話，可以是用戶使用過程中的一聲抱怨，也可以是對一堆數據分析後得出的結論。

根據筆者的觀察，需求的來源有以下幾種：

1. 老闆

對於老闆提出的需求，一定要重視，並非因為需求方是老闆，而是因為它同時包含着機會和陷阱，而且很難拒絕。

（1）機會

• 通過老闆的需求，了解老闆的思路，藉此一窺公司戰略發展方向；
• 將自己對產品的理解和老闆的對照，找出其中的區別並思考原因；
• 和老闆交流下自己的產品思路，發現自己和老闆的差距；
• 把老闆交代的事做好了，得到老闆的賞識（這個大家都懂）。

（2）陷阱

• 並非所有的老闆都了解產品開發流程，了解業務發展，會出現瞎指揮的情況；
• 某些需求會打亂團隊的產品規劃及開發節奏，PM處理不好將會裡外不是人。

2. 用戶（內部同事）

筆者面對的用戶是公司內部的同事，大部分是使用系統的部門同事，小部分是其他的PM。

從部門同事的需求中看出，他們在意的是系統能否滿足他們的某項要求，通常會在提出需求的同時給出他們的解決方案。但是並不意味着就是真實需求，一個很著名的案例是想要快馬但是福特提供了汽車（不知道的朋友請自行查詢）。因此，PM在溝通中需要引導他們表述出自己的真實需求。

負責其他系統（業務線）的PM也會提出需求，來滿足一些需要跨系統實現的功能。這種情況的溝通會比較順暢，因為彼此對系統、開發流程、技術邊界都比較了解。

3. 自我驅動

這類需求通常會基於以下三種原因產生：

1. 通過數據分析得出的。
2. PM在使用系統時發現的問題（通常用戶無感知）。例如：筆者做風控系統時發現的問題，需要對推送的進件增加控制開關。作用是在風控模型調整或新功能上線後，控制推送進件的數量，待驗證無問題後再打開，允許大量進件。
3. 根據產品感提出的。產品感是指基於PM對產品的理解，對市場的分析，提出了一些對於產品未來發展有益的需求。

二、對需求提出方式做規定是有必要的

每個需求的提出者，通常會站在自己的角度提需求，或基於交互，或基於效率，或基於KPI等。這對PM把握需求的重要程度，了解需求內容的準確性增加了難度。

例如：筆者曾經對接過和我不在一個城市工作的業務部門。對接過程中，出現了同一個部門多人同時提需求且優先級不明確，需求上線後使用者（非需求提出者）反饋需求實用性不高，或者需求上線後很多等待使用的人不知道等問題。

筆者通常會分三步進行操作：

1. 確定接口人並明確其職責

接口人：和需求方部門Leader溝通，讓他指定一名接口人，所有人的需求都在接口人處匯總，再提給PM。

職責：

1. 收集部門同事的需求；
2. 過濾掉不合理和不必要的需求；
3. 給出需求的優先級；
4. 將需求提交給PM；
5. 跟進需求進度；

2. 確定需求提出方式

郵件提出，確保周知所有相關人，並能留存記錄。

3. 部門Leader進行審批

必須由部門Leader審批，確保他了解並認可需求內容和優先級。

三、需求收集方式

一句話概括，就是多提問、多溝通，了解業務和實際使用場景。

1. 5W1H分析法

很多需求提出者不了解系統，他們只關心當前問題是否能夠解決，PM必須詳細了解需求的來龍去脈，以便能提出解決方案。在此推薦5W1H分析法，用來收集需求內容。

（1）What（描述）

需求是什麼？

（2）Why（原因）

為什麼會有這樣的需求？之前的替代方案是什麼？

（3）Who（使用者）

需求的使用者是誰，或者說是哪個部門？

（4）Where（場景）

需求的使用場景是什麼？

（5）When（時機）

需求什麼時候會被用到？被用到的頻率是怎樣的？

（6）How（檢驗）

如何確認需求已經被滿足？

上述問題要求需求方描述清楚，可通過郵件，也可通過面談。需求的收集方法可按照自己的習慣選擇，重點在於對需求信息的收集。

2. 和需求方的溝通頻次

負責ToB產品的PM必須了解業務，筆者曾經負責過財務系統的設計，由於不了解需求方對於結算、對賬、提現等操作使用場景的要求（需求方也不了解），導致設計出現問題，需要進行二次開發。

要想深入了解業務，就需要和需求方保持溝通。筆者認為，在接到需求後，至少應該有三次溝通。

• 第一次是在接到需求後。要遵循5W1H分析法，圍繞其中的問題進行溝通，收集需求詳細信息。
• 第二次是在收集信息並對需求進行分析後。PM會結合自己對系統的了解，挖掘出一些細節問題，其中有一些需要和需求方確認。這期間可能會有多次溝通。
• 第三次是在PRD完成後。要將文檔內容講給需求方聽，在評審前最後一次確認自己是否準確理解需求。至於需求背景這類問題，必須在評審會前了解清楚，以便在會上講給所有人。

四、需求的分析與整理

1. 需求分析的步驟

判斷需求的真偽–>分析需求的業務價值–>評估需求的可行性–>給出需求的優先級。

筆者將以自己的經歷為例，說明如何進行這四步操作：

（1）判斷需求的真偽

該需求的5W1H分別為：

1. What：需求方是財務部門，需求內容是在財務系統中新增列表，用來展示某項費用的明細，且該列表可以下載。
2. Why：之前的替代方案是從系統中另一個列表下載，由於並不是專門展示此類數據（數據量較大），所以需要人為進行篩選和計算。篩選計算時間不長，筆者親測約為15分鐘。
3. Who：使用者是財務部門的一名同事（只有一人），系統的其他使用者不會用到該列表。
4. Where：使用場景是每月與合作方對賬時，需要下載該列表，然後在excel中對某幾項金額進行計算。
5. When：每個月月初使用，統計上一個月各資金類型的交易量，使用頻率一個月一次。
6. How：列表中能夠按時提供準確、完整的數據，即滿足需求。

根據筆者的判斷，該需求目前有替代方法且不難操作，需求使用頻率低（一月一次），使用人數少（一人）。故該需求的業務價值不高，是偽需求。

筆者向需求方闡明了需求的不合理處，並建議在已有列表處，增加下載入口，可下載每月需要對賬的金額總和，這樣既節省了下載後再計算的工作量，同時也降低了數據量，減少下載時對資源的佔用。

因為需求方堅持按照最初提的方案進行，同時不能給出合理的解釋，故最終砍掉該需求。

（2）分析需求的業務價值

這一條可以和判斷需求真偽互補，通常業務價值很低的需求，即便做出來也很少會被用到。

依照上述事例，雖然是投入人力、耗費時間都很少的需求，但其業務價值只是為了每個月節約一個人15分鐘時間，得不償失。

另外，PM還需要對系統的發展方向、包含的功能、服務的人群有明確定位。對於後台系統來說，在增加功能、列表時必須要有規劃和節制，否則系統很快就會功能冗餘、查找困難、使用不便。

（3）評估需求的可行性

這一步的目的在於判斷需求的開發難度，進而給出大致的實現方案，需要PM和開發共同完成。

上述事例中的需求頁面功能簡單，所需數據在數據中有記錄，接口也有提供，故從可行性來說沒有問題。

PM需要對自己負責的系統、對接的技術人員的能力、代碼開發中的技術邊界有一定了解，才能更好的做出可行性評估。因此建議PM多學習技術，以免提出“根據手機殼顏色變換APP主題色”這類的需求。

（4）給出需求的優先級

筆者一般會運用四象限法則和KANO模型來判斷優先級。這兩個方法在確定優先級中是比較常用的，在此過多介紹，感興趣的朋友可以自行查詢（優秀的PM需要具備查詢能力和自學能力）。

四象限法則：

• 重要性：指需求是否符合公司戰略發展、是否是產品線上的戰略項目、是否和公司的收益掛鈎、是否滿足產品的基礎服務等等。總之，在時間上不具有緊迫性，但是會對未來的發展產生重大影響。
• 緊急性：指需求是否必須立即解決，如不解決會持續產生或將要產生不良影響。這類需求不一定很重要，但是在時間上有緊迫性。

如下圖所示，重要緊急的需求需要立即放下手中的事情，集中精力去解決，例如：筆者接到的風控系統需求，要在合規備案檢查前上線，以滿足合規備案的需要。重要不緊急的，要在了解並分析完需求後，制定出方案，然後按部就班的執行。緊急不重要的，能不做就不做，做的話也盡量採用省時省力的方法解決。不緊急也不重要的，這類多為偽需求，參照上述財務部門的事例，果斷拒絕掉。

KANO模型：

• 必備因素：在業務流程中必須具備的功能，用以保證流程能正常進行。功能缺失時，使用者會發現流程不能走通。故這類需求需要優先考慮。例如：風控系統中跑反欺詐模型時，如果調用失敗後沒有重啟流程這個功能，就會存在調用失敗的進件卡在反欺詐模型環節，造成流程中斷。
• 期望因素：這類需求通常能節省使用者的時間，提升效率。存在的目的是為了讓系統操作起來更流暢。優先級一般沒有必備因素高。例如：財務系統每月做報表時，如果系統能夠將需要從多處查找並計算的數據，統一到一處並展示計算後的結果，那樣能提高使用效率。
• 魅力因素：通常是一些使用者沒有想到的功能，能大幅提升使用者效率、優化體驗和解決使用者線下難以解決的問題的需求。這類需求在ToB產品中不常見，通常是必備因素和期望因素佔據主導地位。

無差異因素和反向因素：這兩類需求我認為是偽需求，是耗費時間、精力後卻不能提升使用者體驗、效率的，遇到後應予以拒絕。

2. 需求整理

需求的收集與整理需要用到需求池。需求池沒有固定的模板，建立的目的是為了幫助PM進行需求的評估和管理，模板內容依照個人習慣建立即可。

需求池中的需求由PM錄入，記錄不需要像收集需求及分析時那樣細緻，重點在於對需求的狀態、優先級、排期進行記錄。

以下是我的需求池模板：

以上是基於筆者對需求分析的想法，可能存在一定的局限性，僅供參考，歡迎大家多交流學習！

作者：打醬油的熊，公眾號（打醬油的白熊）

本文由 @打醬油的熊 原創發佈於人人都是產品經理。未經許可，禁止轉載。

題圖來自 Unsplash，基於CC0協議