如何做需求分析

1 評論 5234 瀏覽 72 收藏 11 分鐘

本文通過一個具體的返利項目案例,詳細介紹了從項目背景理解到需求澄清、分類、優先級排序、方案設計及評審的全過程。通過系統的需求分析方法,確保項目能夠真正解決業務問題,提高產品的市場競爭力和用戶滿意度。

你是否經歷過,業務方跟你提的需求是要一匹馬,你也實際給他了一匹馬,但是業務又說這匹馬不是他想要的。

你又是否經歷過去面試的時候,面試官問你“你怎么做需求分析?”你不知道如何回答更好。

出現問題1的原因,主要在于沒有定義好需求,其實業務并不是要一匹馬,而是要一個能幫他快速到達目的地的工具而已。出現問題2的原因主要在于不夠系統的理解需求分析。

接下來我會拿一個我從0到1負責的一個主機廠給經銷商返利的一個項目來舉例說明。

一、理解項目背景

1. 了解項目愿景

了解項目愿景其實就是了解業務方通過項目實現的長遠目標,即解決什么問題?創造什么機會?帶來什么價值?

再這個返利項目中,業務方的愿景是希望能通過給經銷商提供返利從而提高經銷商的積極性,從而提高汽車的銷量。

2. 了解項目目標

明確具體的目標。如本返利系統一期的目標是通過系統提高計算返利的速度20%。

二、識別干系人

1. 識別干系人主要包括確定干系人和了解關系人的需求。

確定主要干系人

主要干系人通常包括項目發起部門/人員、受益部門/人員、實際操作部門/人員、后續影響部門/人員。在本項目中項目發起人是財務部門、受益部門和實際操作部門是財務部門計算和發放返利的人、品牌部制定返利政策的人、計算返利的人、后續影響人員是財務部門負責計提和結賬的人

2. 了解干系人的關注點和擔憂點

分析關注點時,要從兩個角度出發:一是他們希望系統解決什么問題、提供什么業務支持‘二是他們希望避免出現什么樣的負面影響’。在返利項目中,我們通過和財務部、品牌部溝通,發現他們的關注點有以下兩點:

  1. 能夠方便快速的錄入返利政策
  2. 能快速無誤的計算出返利結果

他們的擔憂點主要是

每個月的返利政策類型都不一樣、形式也不一樣,涉及到的指標也不一樣。是否能支持每個月的政策的錄入?

三、需求收集

需求收集是需求分析的核心,通常需求可能來源于老板、業務方、競品分析、用戶、產品經理自己通過數據分析等手段發現的需求、以及其他同事做其需求時涉及自己配合的需求等,因此我們可以采用訪談、發放問卷調查、觀察用戶使用類似應用的行為等手段段來收集需求。

四、需求澄清

需求澄清是我認為是需求分析中最核心的部分。

在實際工作中,我們常遇到業務方提出我們需要XX功能,這類需求我們可以定義為解決方案級需求,如果產品經理照做,就有可能出現問題1中出力不討好的情況,明明實現了業務要的功能,但是還是沒有辦法解決業務的問題。

因此,我們需要將解決方案級需求重新澄清為問題級需求。

1.如何將解決方案級澄清為問題級需求?

可通過場景分析,一般會從時間、地點、人物、起因、經過、結果幾個維度分析

  • 時間:早/中/晚
  • 地點:室內/室
  • 辦公室/家里
  • 人物:兒童/青年/老
  • 新用戶/老用戶
  • 起因:因為什么原因

1)主動

2)被動

  • 經過:通過什么方式
  • 結果:達到什么結果

2. 多問幾個why

可通過幾個why,挖掘背后的動機,直到挖掘出用戶的行為動機或者心理動機。

我曾經收到運營同學給我提一個功能:增加優惠券申請審批功能。這就是一個典型的方案級需求,我們需要澄清為問題級需求,找到問題。因此我和運營同學有了下面的溝通:

產品:“你為什么需要一個審批功能?”

運營:“因為我們出現了很多次發錯優惠券!”

產品:“你為什么會發錯優惠券呢?”

運營:“因為我們每個月要發好幾次優惠券,每次發放的用戶不一樣,而我們發放的用戶需要通過Excel上傳一個白名單,但是有時候忙的時候回上傳錯名單,又沒有辦法直接查看名單信息!”

產品:“所以只要防止你發錯就可以了嗎?”

運營:“是的!”

通過上面提問,我們的需求從”增加優惠券審批功能”重新澄清為”如何防止優惠券發錯?”

五、需求分類

將收集到的需求進行分析歸類,如功能性需求、非功能性需求、界面需求、數據需求。

  • 功能性需求:簡單的可以理解為,為了實現用戶的目標,向用戶提供有用的功能,系統必須執行的功能。例如返利項目中為了實現返利項目下發的目標,那么需要提供返利規則制定功能、下發政策功能。
  • 非功能性需求:描述系統的性能、安全性、可用性、容錯性、擴展型等
  • 界面需求:如界面的設計、色彩搭配、布局等用戶視覺需求
  • 數據需求:比如數據獲取,數據存儲,數據分析。尤其在AI時代,數據需求會變得更多,更加智能化

六、需求優先級排序

對于任何一個項目,都會有很多個需求,而我們的資源有限,所以通常根據需求價值、成本、幾個維度評估需求的優先級,通常是需求價值高、成本低、緊急的需求優先做,需求價值低、成本高、不緊急的最后做。

1. 需求價值評估

價值評估是很重要的環節,不管內部需求還是商業化需求,既然要接,一定是有價值的,要不然投入的資源和時間處理,就是浪費。需求價值評估可按以下幾個方面評估

  • 戰略契合:并不是什么需求都必須做,如果需求與當前戰略目標有沖突,即使需求價值再高也不做
  • 市場潛力:相關需求的未來市場有多大?例如iphone面世后,原先全球的手機用戶未來將面臨更新換代的需求
  • 業務價值:需求落地后,對業務目標和收益的貢獻大小
  • 覆蓋人群:需求會影響哪些用戶,什么量級
  • 功能使用頻次:可推測每個用戶在一段時間內,適用該功能的次數
  • 是否影響流程、工作:需求是否會影響主流程,如購物,缺少下單功能,流程就走不通
  • 用戶滿意度:需求對提高用戶滿意度和用戶體驗的影響
  • 需求緊急程度:需求滿足對時間的敏感程度
  • 依賴程度:需求對其他需求或者項目里程碑的依賴程度
  • …..

在日常工作中,接到新需求不一定都要考慮這么多因素,可以根據實際情況進行刪減。一些小功能需求,稍微考慮“覆蓋人群”、“使用頻率”、“研發成本”也夠了

2. 成本評估

成本評估或者叫工時評估,包括產品、UI設計、前后端技術、測試等都加上,一般幾個崗位的工時比例,

產品:設計:前后端技術:測試=1:1:(2-3):1,也就是技術的工時應該是其他的2-3倍,當然也要看具體的需求。

3. 輸出優先級

根據前面的價值和成本評估,我們可以生成一個四象限,可以看到左上角的應該優先級最高,就是價值越高、成本越低的,付出更少的資源成本可以實現更高價值的需求,這個就是最優先的,相反,右下角的就是最低的了。

注意:有的項目中,尤其是乙方項目,還需要把需求優先級和甲方溝通,把排期計劃同步給他們。

七、產品方案設計及評審

再排好需求優先級后,就可以跟進優先級高低進行產品方案設計、PRD文檔撰寫和需求評審。在這里因為不同的項目,產品方案不同,我就不具體闡述了。

八、需求排期

需求評審后,產品和前端、后端、測試、UI設計師(有的需求可能不需要)需要一起定一個具體的排期計劃。

九、需求跟進

需求跟進主要包括設計、研發進度跟進;解答設計師或者研發、測試的一些問題

十、需求驗證

在這里我覺得分為兩步:

第一步:上線前的驗證

第二步:上線后的驗證,可采用數據分析、用戶回訪等方式驗證。

本文由 @y先生 原創發布于人人都是產品經理。未經作者許可,禁止轉載

題圖來自Unsplash,基于CC0協議

該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 需求分析很全面,看完這篇文章對于做需求分析這方面有所感悟。

    來自廣東 回復