編輯導讀：為什麼女生讨厭男朋友對自己說“多喝熱水”，因為女生的需求是要男生的關懷，而不是具體的解決措施！開發産品也是一樣，對需求分析不對，就對影響産品的研發工作。那麼，如何對需求進行梳理和分析呢？本文将從五個方面展開分析，希望對你有幫助。

為什麼要講梳理與需求分析？

這裡的需求梳理與分析指的不是一個工作項，而是研發流程的一個階段，也是研發流程的前期階段；

那麼需求分析這階段具體是要做些什麼呢？

我們簡單概況一下就是：将用戶非形式的需求表述轉化為完整的需求定義。 這裡關鍵詞是“表述轉化”，用白話講就是把用戶的市場類語言，翻譯成開發能聽得懂的技術類語言。

所以這次為什麼要給大家講《需求分析》呢？

因為需求分析不隻是需求分析師和産品經理的必備技能，對于項目經理/研發經理/解決方案經理等多角色的工作其實都有涉及；

哪怕你這些角色都不是，需求分析在生活中也是用得上的，就例如女生跟你說她肚子痛了，她背後的需求是什麼呢？學了需求分析也許你就不用被人說直男了。

給大家講《需求分析》的第二個原因是，需求分析對于産品成功來說很重要，甚至是最重要的一個階段都不為過。

雷軍說過一句很經典的話：選擇比努力更重要。

用戶需求不等于産品機會。 如果前面的需求做錯了，也許後面的開發的同事再怎麼努力，也許結果都是枉然的。

好吧我們現在進入正題，接下來給大家介紹的第一部分是：

01 需求來源 | 需求從哪裡來

以我目前服務的項目 為例，目前最主要的需求來源渠道主要來自客戶自提的需求。

所以這次的需求分析的方法也主要圍繞着“項目（客戶）的需求”和“用戶反饋的需求”。

（如果大家覺得有需要，其他類型的需求分析分析過程會在往後的内容中分享，可以用點贊或留言的方式告訴我你們想要我講更多）

02 需求确定 ｜ 如何準确的理解與描述需求

為什麼我們需要做需求分析呢？

因為很多少時候人們需求的表達形式并不直白，人們更習慣表達問題。

這到底有沒有什麼标準的公式可言呢？

其實也是有的，下面就給大家分享一個常用的公式。

為什麼要關注角色？因為角色是解決方式和優先級的判斷依據：假如這個角色不是女朋友，而是一個普通的同事，那麼我們的解決方式大概就是假惺惺的說一句：are u OK？lam so sorry to hear that了。

而我們最常犯的失誤，我們經常容易忽略場景。以這個例子說：在例假的時候肚子痛，我們的解決方案可以是喝紅糖水，但是不是來例假的時候就不那麼适用了。忽略場景出來的結果有可能就是：我們在給滴滴司機設計PC客戶端接客程序一樣。

那為什麼關注他的當前的解決途徑呢？因為隻有知道對比他過往的解決途徑才能體現我們的解決方案給他産生了多少價值。

TA期待的解決方式我們最常犯的錯誤就是喜歡照搬，關于這個我後面會單獨講。

當然還有更專業一定的表達方式：

需求記錄下來了，接下來當然要做更深層次的分析咯，這裡我打算給大家提供一些分析的小技巧。

03 需求分析 | 一些分析的小技巧

需求分析的基本内容：其實也是對需求進一步挖掘的過程。

我們大概會做一些的幾件事情。其中我覺得業務流程的梳理畫流程圖是最不能省的一項工作。

假如連這個都沒有，就不能叫需求分析了。

還有這一項工作其實需求分析師跟産品經理有重合的地方，有的需求分析師其實是從業務轉崗而來，所以不一定具備這樣的能力，所以我建議這一些工作需求分析師和産品經理是誰有能力誰做，甚至共同完成。

我覺得需求分析的關鍵是關鍵用戶的分析，而關鍵用戶的分析的關鍵則是決策路徑的分析。

以B、G端産品為例 關鍵用戶主要分為3種；

由于決策者與執行者的視角不同，必然會導緻用戶體驗的割裂。所以需求分析的過程，有的時候就是一個權衡利弊的過程。

就以這張圖為例： 育兒産品是該讨好父母，還是孩子？

所以當決策者與執行者的體驗站在對立面的時候， 不是優先解決高頻使用的體驗問題，而是優先解決距離決策最近的體驗問題。

當然也有更好的解決方案：

實現賦能是協調決策者與執行者的共同獲得好體驗的最好方式。

前面分析了這麼多為了解決做不做和做什麼的問題，而需求評估則是為了解決什麼時候做的問題。

所以簡單的需求分析之後就要對需求進行分類管理。

那麼接下來就是解決怎麼做的問題，

04 輸出創意/解決方案 | 一些設計的小技巧

輸出解決方案之前，可以先看看競争對方做得怎樣。

具體競品分析怎麼做，在這裡也不展開了，後面有機會再跟大家分享。

接下來解答一下前面遺留的一個問題。

問為什麼不要太關注用戶期待的解決方式：

因為用戶提的解決方案可能不是最适合我們的解決方案，

應該關注用戶真正想要的目的，以選擇适合我們的解決方案。

我們經常會說到做項目和做産品，那麼在項目裡和産品裡的需求産品經理該如何區别對待呢？

項目類解決方案考慮的是：如何用最低的成本，實現用戶期望，如果成本高于項目預算則可能不做。

産品類解決方案考慮的是：有多少人願意為這個功能付費，用戶多成本高也做，用戶少成本低也不一定做。

假如客戶為國企等政府機關：

這個行業有明顯的官僚體制的經濟學想象。面對這個行業的設計策略，不能照搬民企的一套效益為王的方法。官僚體系中的人的追求：津貼、權力與聲望；決策者往往不是企業的所有的者，他們比起提升實際收益，可能會更關注彰顯政績這樣的決策方案。因而這個群體，不是價格敏感型，而是服務敏感型。

信息化有三個階段，産品設計應該循序漸進。

有很多缺乏B端産品設計經驗的人，在做業務信息化的時候還沒完成數字化上來就喊着做大數據，最終會導緻産品的落地性極差。

在業務信息化的過程，很多人做着都會發現，數字化階段其實是最難推動的，因為這一個階段并不一定能減輕執行人員的工作量，相反可能還會增加工作量。所以從結果數據化開始，也許阻力會小一些。

接下來要分享的，也是一個比較常見的問題。

如果涉及到改變流程怎麼辦？

流程變更就可能涉及到别人的利益，為了避免利益沖突帶來的阻撓，應該先設計紙質流程試運行，确定流程可行後再把流程數字化。

（如果隻考慮合同交付，不考慮用戶成果的項目可忽略）

設計最小可用産品（MVP）：

MVP也是比較大的概念，這裡也不打算展開講，後面有機會再跟大家分享。

研發類項目建議設計MVP（最小可運行版本）

報價主要分兩種方法：

按價值報價就要計算它的價值流了，這裡就不展開講，就簡單舉個例子。

一個優秀的需求分析，它是要明确知道用戶價值的。

05 解決方案/項目篩選

外部評審：

盡量在開發之前與需求方進行充分的原型評審，能在原型階段發生的需求變更就不要拖到開發階段；

（這一階段用戶可能會頻繁變更需求，所以建議使用低保真原型）

内部評審：

通過評分最終得到需求進入開發階段的優先級：

評分維度舉例：

• 戰略一緻性和重要性（戰略契合性和重要性、對業務的影響）
• 産品和競争優勢（獨特的客戶利益、經濟價值、客戶反饋）
• 市場吸引力（市場規模和發展、利潤、競争地位）
• 核心能力影響力（技術、生産、市場與分銷/銷售）
• 技術可行性（技術差距、技術上的複雜性、是否使用内部技術、技術可行性是否被證實）
• 财務收益（機會，投資回收期、淨現值、内部收益率，評估的确定性，風險性和難度）

本文由 @志良LAN 原創發布于人人都是産品經理，未經許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協議

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部