1 需求管理流程
産品的需求管理有需求采集、需求分析和需求篩選幾個階段，經過這幾個階段之後才會進入立項的階段。
需求管理流程圖
2 使用者研究方法
需求采集主要是從使用者的角度進行需求的采集，橫向看，使用者有說和做，顧名思義，說，就是讓使用者說話，而做，就是讓使用者實際去做；使用者的說和做，往往是不完全一緻的。縱向來看，使用者的研究有定量研究和定性研究，定性研究一般是使用者研究較早階段，從無到有，找出原因，偏于了解，而定量研究，一般是從有到精确，偏向深入研究和證明。
使用者研究方法（圖檔來自網絡）
3 需求采集
需求采集一般會有：明确目标、選擇采集方法、制定采集計劃、執行采集、資料整理等步驟，蘇傑将最常用的需求采集方法歸納為“Z方法”（具體參見蘇傑的“需求采集的”Z方法“），需求采集分為定性地說、定量地說、定性地做、定量地做。
需求采集“z方法”
3.1 定性地說：使用者訪談
-
使用者說和做不一緻
在訪談過程中使用者所講和使用者所做可能并不一緻，原因可能是使用者說的隻是沒有經過大腦思考的結果，實際不會做；也可能是因為使用者覺得說出實際結果會會讓訪談者不滿意，是以編造一個訪談滿意的結果；或者是因為做了壞事而不願意承認。
一般情況下使用者講做了什麼事情，然後由什麼樣的感想或者結論可信度會高一點，如果使用者講“我覺得”、“我認為”可信度要大打折扣。
-
樣本量選擇
5個訪談樣本可以解決85%的問題。是以訪談樣本量的選擇，一般是在後續訪談中，沒有發現新的需求和問題，那麼就可以結束繼續訪談。
-
訪談時間和話題把控
訪談過程切記千萬不要去主導被訪談者，也不要用帶有引導性的方式去訪談和問問題，更不要被參與訪談者的人牽着鼻子走，要時刻記住訪談的目的和方向，跑題了要及時拉回來。
焦點訪談（focus group）：定性地說的另一種方式，由一個經過訓練的主持人以一種無結構的自然的形式與小組的成員交流，一般認為是一種一對多的訪談形式。
3.2 定量地說：調查問卷
-
長尾理論：“沉默的大多數”和“騎牆的大多數”
沉默的大多數：站出來的人總是很少，更多的人選擇沉默，是以主動站出來的人不能代表整體；
騎牆的大多數：大多數人沒有自己明确的觀點，最開始的表态的人容易引導整個觀點的走向。
調查問卷可以避免如焦點訪談過程中所帶來的長尾理論。
-
問卷設計
問卷一般不要太長，
一般開篇放簡單不需要思考的問題，
中間放自己想知道的問題，
最後放訪談者個人資訊，以免個人資訊放前面引起填問卷人的顧忌。
-
問卷樣本選擇（選擇偏差）
雖然需要參與問卷的人盡可能設計方方面面，樣本需要具有代表性，但是在樣本總是會因為各種原因具有偏差，比如無應答偏差，願意回答的人，可能與整體樣本有所不同；選擇偏差，可能參與問卷的人是因為某種利益的誘惑才參與的。是以在樣本選擇過程，最好不要用物質誘惑，而是鼓勵。
-
問卷品質
可能參與填寫問卷的人并沒有認真填寫，而是随機選擇，從嚴謹的角度可以将意思相近的問題分開放置，看回答是否一緻。
-
多選項和評分
有的問題深淺程度不一衡量，可以用多選或者打分的形式，比如問對食堂菜品喜歡程度，可以用0~7分代表非常不喜歡到非常喜歡。
位置偏差：指的是答案與選項位置有關系，比如價格，可能大衆偏向中間的價位。解決方法可以設定不同類型的問卷來避免位置偏差。
灰階釋出：網際網路釋出新産品的一種方式，先讓少部分的使用者看到和使用新産品，根據回報進行改進，然後将産品展現給大衆。
3.3 定性地做：可用性測試
可用性測試（UT，usability testing),設計過程中用來改進易用性的一系列方法。
- 可用性不等于易用性
-
測試産品，而不是測試使用者
明确告訴參與可用性測試的使用者，是要找出産品的漏洞和改進産品，而不是測試使用者，避免使用者心裡有所顧忌，緊張而不能找出産品的不足。
-
千萬不要進行引導
不要對使用者進行引導或者暗示，否則不能有效找出産品的不足和問題。
發聲思維：讓使用者一邊做一邊說，記錄使用者思考的過程。
3.4定量地做：資料分析
-
不要迷信資料
盡管是客觀的資料，但是有的時候為曲解資料。比如一般用均值（means）來衡量中間水準，比如全班同學平均身高，但是如果是平均财富，可能土豪會将平均值大幅度拉高，這個時候均值不顯得那麼重要，可能需要中位數來衡量。（是以我在想，人均GDP是不是也會是以而影響）
-
未雨綢缪，防範于未然
資料分析可能存在于各個階段，産品上線之後也會有各種資料分析，是以為了防止需要做資料分析的時候手足無措，在産品設計的時候就應當考慮資料分析，記錄通路量、交易量等。
3.5單項需求卡片（6W2H）
| 需求編号（可由需求人員填寫） | 需求類型（可由需求人員填寫） |
|---|---|
| “采集時刻+采集者” | 功能需求、非功能需求 |
| 來源（who） | |
| 産生需求的使用者:最好有該使用者的聯系方式等資訊使用者背景資料：受教育程度、崗位經驗、以及其他與本單項需求相關經驗 | |
| 場景（where、when） | |
| 産生該需求的特定時間、地理、環境等 | |
| 描述（what） | |
| 盡量用（主語+謂語+賓語）結構，不要加入主管修飾詞 | |
| 原因（why） | |
| 為什麼會有這樣的需求，以及采集者的解釋 | |
| 驗收标準（how） | 需求重要性權重（how much） |
| （如何确認這個需求被滿足了）1.盡量用量化的語言2.無法量化的舉例解釋 | 滿足後（“1：一般”到“5：非常高興”）未實作（“1：略感遺憾”到“5：非常懊惱”） |
| 需求生命特征（when） | 需求關聯（which） |
| 1.需求的緊急度2.時間持續性 | 人：和此時需求關聯的任何人2.事：和此事需求關聯的使用者業務與其他需求3.物：和此需求關聯的使用者系統、裝置，以及其他産品等 |
| 參考材料 | 競争者對比 |
| 在需求采集活動中的輸入材料，隻要引用一下，能找到即可 | 按照“1分：差”到“10分：好”進行評估：1.競争者對該需求的滿足方式2.使用者、客戶對競争者及公司在該需求上的評價 |
單項需求卡片模闆（參考蘇傑《人人都是産品經理》）
4 需求分析
4.1 需求
4.1.1 使用者需求與産品需求
使用者需求：使用者自己認為需求的請求，經常表達為使用者的解決方案。
産品需求：産品經理分析找到的真是需求，并且表達為産品的解決方案。
需求分析：從使用者提出的需求出發，找到使用者内心真正的需求，再轉化為産品需求的過程。
使用者需求與産品需求的關系
技術分析：樹幹——樹枝——樹葉
需求分析：樹葉——樹枝——樹幹——樹幹——樹枝——樹葉
4.1.2 Y理論
Y理論（圖檔取自http://iamsujie.com/1000/1017/）
蘇傑在部落格中給我們講述了需求分析實際上是從1->2->3的過程，将使用者需求轉化為産品需求再轉化成産品功能，從1->2通過“why”盡心歸納，從2->3通過“how”進行逐漸演繹。産品需求取決于公司和産品的定位。（詳情見蘇傑·需求分析的“Y理論”）
4.1.3 滿足需求的三種方式
-
提高現實
最直接也是最笨的方法，比如食堂飯菜不咋地，同學們希望食堂飯菜能夠好吃的需求，提高現實地方法就是請大廚，做美味。
-
降低理想
告訴同學們，其他學校的食堂比起我們學校的食堂不知道差到哪裡去了，我們學校的食堂已經是食堂中的佼佼者。
-
轉移需求
雖然我們食堂飯菜不好吃，但是菜量足，價格低呀。
4.1.4 創造需求
創造需求需要天賦，并且是非常偉大的天賦。電燈泡、手機、電腦，誰能離開？
4.2 需求分析流程
需求分析流程（圖檔取自蘇傑《人人都是産品經理》）
-
第一步：需求轉化
需求轉化也就是将使用者需求轉化為産品需求。這中間需要發揮産品團隊最大的價值。
- 第二步：确定基本屬性
| 需求屬性 | 屬性說明 |
|---|---|
| 編号 | 需求的順序号，唯一表示 |
| 送出人(*) | 需求的錄入PD，負責解釋需求 |
| 送出時間 | 需求的錄入時間，輔助資訊 |
| 子產品(*) | 根據産品的子產品劃分(一般5±25±2)個子產品 |
| 名稱(*) | 用簡潔的短語描述需求 |
| 描述(*) | 需求描述：無歧義、完整性、一緻性、可測試性等 |
| 提出者 | 即需求的原始提出者，有疑惑時便于追溯 |
| 提出時間 | 原始需求的獲得時間，輔助資訊 |
| bug編号 | 将一些bug視為需求，統一管理 |
需求的基本屬性(表格取自 蘇傑·《人人都是産品經理》
| 需求屬性 | 屬性說明 |
|---|---|
| 分類 | 新增功能、功能改進、體驗提升、bug修複、内部需求等 |
| 層次 | 基礎、擴充（期望需求）、增值（興奮需求）（參見KANO模型） |
需求的種類（表格取自 蘇傑·《人人都是産品經理》）
- 第三步：分析商業價值
| 需求屬性 | 屬性說明 |
|---|---|
| 重要性 | 重要程度，輔助資訊 |
| 緊急度 | 緊急程度，輔助資訊 |
| 持續時間 | 持續時間，輔助資訊 |
| 商業價值(*) | 行業優先級，不考慮實作難度，群體決策 |
需求的商業價值（表格取自 蘇傑·《人人都是産品經理》）
- 第四步：初評實作難度
| 需求屬性 | 屬性說明 |
|---|---|
| 開發量(*) | 需求的開發工作量，表征實作難度，如以“人天”為機關 |
需求的種類（表格取自 蘇傑·《人人都是産品經理》）
-
第五步：計算成本效益
成本效益=商業價值÷實作難度成本效益=商業價值÷實作難度
| 需求屬性 | 屬性說明 |
|---|---|
| 成本效益(*) | 商業價值/開發量，用于決定先做哪個 |
需求的種類（表格取自 蘇傑·《人人都是産品經理》）
5 需求篩選
需求篩選
産品線劃分團隊：産品規劃不容易被改變，線性上司，資源有保證。
職能劃分團隊：有利于資源共享，穩紮穩打，但單個産品速度降低。
5.1 需求打包
将可用的工作量對應到預計的工作量中。個人了解就是将工作量化和細化的過程。
5.2 BRD制作
BRD，Business Requirement Document，商業需求文檔，包括項目背景、商業價值、功能需求描述、非功能需求描述、資源評估、風險和對策等内容。
對應的兩個概念：
MRD, Market Requirement Document，市場需求文檔
PRD，Product Requirement Document，産品需求文檔。
5.3 産品會議
通過産品會議來讨論産品需求、商業價值等。
6 完整需求資訊
6.1 跟蹤資訊
除了應當有基本的需求屬性外，還需要有一些跟蹤資訊來記錄需求的進展情況。
| 需求屬性 | 屬性說明 |
|---|---|
| 狀态(*) | 需求生命周期：待讨論、暫緩、拒絕、需求中、開發中、已釋出 |
| 負責PD(*) | 狀态進入“需求中”後确定 |
| 開發工程師 | 狀态進入“開發中”後确定 |
| 項目名稱 | 需求的釋出項目 |
| 釋出時間 | 需求的釋出時間 |
| 備注 | 其他任何資訊，如：1.被拒絕的理由2.被暫緩的理由和重新開機條件3.相關文檔 |
6.2 完整的需求屬性
| 需求屬性 | 屬性說明 |
|---|---|
| 編号 | 需求的順序号，唯一表示 |
| 送出人(*) | 需求的錄入PD，負責解釋需求 |
| 送出時間 | 需求的錄入時間，輔助資訊 |
| |子產品(*) | 根據産品的子產品劃分(一般**5±25±2**)個子產品 |
| 名稱(*) | 用簡潔的短語描述需求 |
| 描述(*) | 需求描述：無歧義、完整性、一緻性、可測試性等 |
| 提出者 | 即需求的原始提出者，有疑惑時便于追溯 |
| 提出時間 | 原始需求的獲得時間，輔助資訊 |
| bug編号 | 将一些bug視為需求，統一管理 |
| 分類 | 新增功能、功能改進、體驗提升、bug修複、内部需求等 |
| 層次 | 基礎、擴充（期望需求）、增值（興奮需求）（參見KANO模型） |
| 重要性 | 重要程度，輔助資訊 |
| 緊急度 | 緊急程度，輔助資訊 |
| 持續時間 | 持續時間，輔助資訊 |
| 商業價值(*) | 行業優先級，不考慮實作難度，群體決策 |
| 開發量(*) | 需求的開發工作量，表征實作難度，如以“人天”為機關 |
| 成本效益(*) | 商業價值/開發量，用于決定先做哪個 |
| 狀态(*) | 需求生命周期：待讨論、暫緩、拒絕、需求中、開發中、已釋出 |
| 負責PD(*) | 狀态進入“需求中”後确定 |
| 開發工程師 | 狀态進入“開發中”後确定 |
| 項目名稱 | 需求的釋出項目 |
| 釋出時間 | 需求的釋出時間 |
| 備注 | 其他任何資訊，如：1.被拒絕的理由2.被暫緩的理由和重新開機條件3.相關文檔 |
完整的需求屬性
6.3 需求管理完整流程
- 需求周期圖
需求周期
從需求采集到需求分析、讨論、打包和産品會議，一直到産品開發，可能是一個多次循環改進的過程。
- 需求管理詳細圖
需求管理詳細圖
需求采集主要有四個次元：定量和定性、說和做，使用者需求采集圍繞這四個次元展開。
需求分析從需求轉化、到确定基本需求屬性、分析商業價值、初評實作難度，以及計算成本效益。需求轉化是從使用者需求到産品需求，基本屬性來記錄需求的具體内容，商業價值是衡量需求的意義鎖子啊，實作難度以開發量來統計，衡量實作的工作量，成本效益确定需求的優先級。
需求篩選通過将需求打包，合并相同和相近的需求，制作BRD，對項目背景、商業價值、功能需求描述、非功能需求描述、資源評估、風險和對策等内容進行分析闡述，最終通過産品會議來确定其具體的商業價值和是否進入開發狀态。