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

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

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

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

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

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

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

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

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

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

用戶需求不等于產品機會。 如果前面的需求做錯了，也許后面的開發(fā)的同事再怎么努力，也許結果都是枉然的。

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

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

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

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

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

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

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

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

這到底有沒有什么標準的公式可言呢？

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

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

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

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

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

當然還有更專業(yè)一定的表達方式：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

04 輸出創(chuàng)意/解決方案 | 一些設計的小技巧

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

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

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

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

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

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

我們經常會說到做項目和做產品，那么在項目里和產品里的需求產品經理該如何區(qū)別對待呢？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

報價主要分兩種方法：

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

一個優(yōu)秀的需求分析，它是要明確知道用戶價值的。

05 解決方案/項目篩選

外部評審：

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

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

內部評審：

通過評分最終得到需求進入開發(fā)階段的優(yōu)先級：

評分維度舉例：

• 戰(zhàn)略一致性和重要性（戰(zhàn)略契合性和重要性、對業(yè)務的影響）
• 產品和競爭優(yōu)勢（獨特的客戶利益、經濟價值、客戶反饋）
• 市場吸引力（市場規(guī)模和發(fā)展、利潤、競爭地位）
• 核心能力影響力（技術、生產、市場與分銷/銷售）
• 技術可行性（技術差距、技術上的復雜性、是否使用內部技術、技術可行性是否被證實）
• 財務收益（機會，投資回收期、凈現值、內部收益率，評估的確定性，風險性和難度）

本文由 @志良LAN 原創(chuàng)發(fā)布于人人都是產品經理，未經許可，禁止轉載

題圖來自?Unsplash，基于 CC0 協議