什么是需求，通俗點來講，就是人們需要的東西，服務或者體驗。互聯網的需求，個人覺得就是通過技術手段來滿足人們的需要。

1.需求的來源有哪些？

首先是來自用戶，這時候就要考慮一個問題：場景；我們也可以嘗試從幾個關鍵因素來進行場景分析。

基于什么環境：地鐵/辦公室/室內/公共場合/走路/夜晚/戶外……深入情景周圍的細節中去

基于什么用戶：具備什么特征，比如身份、收入、區域…..

基于什么行為：行為或操作流程，比如購物流程、操作習慣、行為認知…….

場景分析也就是需要考慮具體什么環境（時間、地點、情境）什么類型用戶的什么動機，想達到什么目標，以及人與人的關系。如實地記錄下來，如果偏差或缺乏信息，之后的分析就會有所偏差。

可能還有輔以用戶訪談、問卷調查、用戶反饋等各種用戶調研方法，進行信息的收集和補充。

蘇杰老師分享過一個需求分析的”Y理論”

“需求分析”的過程就是經歷圖中的“1 –>2 — >3”，把“用戶需求”轉化為“產品功能”。

“Y”的越上面越是解決方案，越下面越是背后的目的。“1-用戶需求”，大多表現為用戶的解決方案，往往是不好的，但好的“3-產品功能”一定是從用戶需求轉化而來，而不是憑空想出來的。所以說，“聽不聽用戶”都是一個意思，更準確的說法是“聽用戶的，但不要照著做”。同時，也不要誤解“創造需求”，你創造的只能是滿足用戶需求的解決方案——產品功能，而不是用戶需求。

1–>2，通過問“Why”，逐步歸納，2–>3，通過問“How”，逐步演繹。過程中都要用到各種輔助信息，比如數據、競品、行業等。

把“2-產品需求”追溯到“4-馬斯洛需求”的過程是可選的，畫為虛線，只是為了這個理論的完備，如果感興趣，每個產品需求總能挖到馬斯洛的層面。“2-產品需求”的點如何選擇，我們到底應該挖到那個層面上，作為產品需求，取決于公司和產品的定位。

其次來自公司內部，這就比較多了，公司領導，市場，運營，產品，開發等等，

除此之外，需求還可能來自甲方，這是我目前接觸過的需求來源，當然還有可能來源其他渠道。

2.需求分析

有了需求，我們就需要對需求進行分析，因為不是所有的需求，我們到要做，這里面要考慮的因素很多。比如：

1、需求提出的原因是什么？

2、需求在什么場景下，解決了什么問題？

3、需求滿足的人群基數有多少？

4、需求產生的價值有多少？包括商業價值、用戶體驗價值等

5、采用什么方式滿足需求？如果要開發，工作量和開發成本如何？

6、需求的重要程度？按1-3打分，1為最重要

7、需求的緊急程度？按1-3打分，1為最緊急

8、如何評估需求的達成效果？是數據？用戶反饋？商業收入？還是其他？

按照上面分析后，如果確定要做，我們接下來就要考慮需求的優先級，定義需求優先級暫時有這七個方法：

1.KANO模型法：基本型需求>期望型需求>興奮型需求

2.矩陣分析法：重要且緊急>重要不緊急>緊急不重要>不重要也不緊急

3.經濟收益法：經濟收益高且緊迫的功能需求??＞ 經濟收益高但不緊迫的功能需求??＞ 緊迫但經濟收益不高的功能需求??＞ 不緊迫且經濟收益不高的功能需求

4.前/后置需求分析法：前置需求的優先級??＞ 后置需求的優先級；前置需求的重要性和緊迫性??＞ 后置需求的重要性和緊迫性

5.滿足核心用戶需求的優先（二八原則）

6.滿足核心業務的需求優先（資源最大化利用）

7.滿足核心業務的投入產出比最大的需求優先（ROI最大化）

之前和看網上有一種方法：記分卡，如何使用記分卡

1. 確保你有一個可靠的理論依據和下一個版本的計劃

2. 優先級評定前，該版本需要考慮的因素都要列在記分卡中

記分卡的建立需要參數和權重，如果評審需求時只是拿一張白紙，結果估計不會好到哪去。

舉個栗子：

上面的例子中，特點是影響運營效率都被賦予權重最高，因為下個版本的目的是提高該部分。

3. 確定與該版本最相關的功能

如果使用記分卡，遺漏每一個功能都可能使結果偏離正常軌道。記分卡適用于已經初步討論過的待做功能列表。

4. 把記分卡上的100分分到每一個功能當中

這100分意味著這些功能具有極大的影響

舉個栗子：

在圖文資訊中，用戶交互一項的分數打到了90，代表它的發布將會用戶參與產生了極大的影響。然后計算出圖文咨詢的優先級：90*20%+90*10%+50*30%+20*40%=50

完成所有計算后，得出優先列表。

小提示：

如果你想要降低一個特定的類別，你可以增加一個“負權重”。例如，“風險實行”一個類別具有負權（-20%）。因此，當計算分數時，減去這一項；“風險實行”的特點是降低優先級。

記分卡可以在每個版本中變化。它的類別和權重應當適應你所在的環境，以確保你專注該版本的主旨。

在創建記分卡的同時，記得考慮其他部門的需求。

我們的責任是照顧用戶的需求，但往往用戶不僅需要的是新的功能或更多的“創新”。有時候是產品缺乏可用性，穩定性和良好的性能，所以優化現有的功能也是非常重要的。

這是一個工具，用來評定優先級。

例如：如果運營效率是下一個版本的主題，你的記分卡應該支持這個方向發展。在上表中，“健康監測”功能，除了“運營效率”分數高，其他分數很低，但這是新版本的方向，那么這個功能立刻獲得最高優先權。另一方面，有時你也需要把其他部門同事的需求列在記分卡中，雖然不符合下個版本的主題，但記分卡的方式會告訴他們你是真正考慮他們的需求，也有利于團隊建設，達到高效工作的目的。

現在分享一位老師對需求優先級評估標準的看法，建立標準，分2種情況，對初創公司，從0到1的階段，更多是老板拍板+用戶核心需求優先，其實還沒到定標準的時候。而大部分公司都處于收入壓力大、需求堆積、bug不斷、研發資源有限的境地，今天就主要說說這種情況下如何確立標準。

首先，要求產品經理有“量化”意識。一個需求來了，該不該做，該不該馬上做，做了有什么好處，每個人都有一套說辭，如何把大家的思想統一達成一致呢？就是要盡量把需求要達到的效果“量化”，用客觀數據說話。這個“量化”的維度，可以是商業化收入，可以是用戶增量，可以是活躍人數，可以是注冊轉化等等。同一個維度的對比，高者勝。

其次，要求產品經理有“抽象”的能力。需求可能是五花八門，今天優化個交互，明天調整個布局，后臺支持各新項目，中間還要插入各種改Bug，很容易讓人應接不暇。如果你是頭痛醫頭永遠無法評估優先級。因此你需要把現有需求List統一歸類，抽象出需求和需求之間的共性。同時，這個“共性”，也要是可量化的，所以不建議按平臺，比如App還是PC站分，也不建議按項目分，畢竟每個項目之間要求和目標不同無法對比，而是盡量按能量化的指標分，這個量化指標，務必能和上一段對上。

還有一些無法量化的需求，比如體驗優化需求，比如改Bug，怎么排定呢？對bug，有一些基本的判斷標準：

1、有邏輯漏洞的bug，優先處理

2、影響用戶量級高的，優先處理

3、涉及PR層的bug，優先處理

4、涉及政策風險的bug，優先處理

而對于用戶體驗和基礎功能級的需求，則建議按以下原則排期：

1、持續在每個版本，拿出15%左右的工作量，在優化體驗層面排期開發

2、提前規劃好要優化哪些體驗功能，讓開發人員心里有數

最后，則需要產品Leader根據具體量化目標，劃定優先級標準，比如根據區間劃分A、B、C，A為量級達到多少萬以上等等。再來需求時，就可以放到對應區間內，依此確認優先級。

如果需求方自己對需求也很模糊，怎么溝通？大概列了幾個步驟：

1、讓對方明確這個需求要達成的目標是什么？

2、確認這個目標是否能量化？并給出量化推演思路，并根據經驗和邏輯推演，判斷這個思路是否合理，數據目標是否合理。對于不合理的目標，則建議想清楚后再繼續溝通 。

3、確認好需求目標后，如果有多個目標，則讓對方先明確哪個是當前階段最重要需要解決的

4、如果反饋是“都重要”，讓對方給出背后的邏輯，為什么，如果無法自恰，在資源不充足的情況下，仍舊要排出優先級

5、如果開發成本高，先給出技術成本低的快速試錯方案，根據數據再決定是否繼續開發提供更優方案。

3.如何完整表達需求？

在需求被采集之后，需要將各種需求具象化并放入需求池中，這里提供兩種方法來表達需求，一個是單項需求卡片描述單個需求，另一個是需求清單（feature list）來管理多個需求。

1. 單項需求卡片

此卡片的核心在于讓開發人員了解每個需求的描述信息（who/where/what/when/why）以及重要緊急程度，為未經加工過的用戶需求，多為需求屬性陳述。下圖為模版并詳細解釋了各個欄目要填寫的內容：

以小黃車為例，近來看到網上討論是否要在小黃車APP增加導航功能（事實上筆者認為此需求為偽需求），那么它的單項需求卡片卡片填寫應該如下：

2. 需求清單

此清單將多個需求整合在一起，每一條對應每一個單項需求卡片的內容，跟單項需求卡片相比，需求清單通常是分析過后的產品需求，偏向于研發時間成本和實現性價比。

案例如下：

單項需求卡片和需求清單不僅僅著重于表達需求，也涉及到部分需求管理內容。而且，面對隨時都有可能蹦出來的需求，如何評估需求性價比并選擇性納入需求池也是產品經理需要考慮的。