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，負責解釋需求 |
| 提交時間 | 需求的錄入時間，輔助信息 |
| 模塊(*) | 根據產品的模塊劃分(一般 |
| 名稱(*) | 用簡潔的短語描述需求 |
| 描述(*) | 需求描述：無歧義、完整性、一致性、可測試性等 |
| 提出者 | 即需求的原始提出者，有疑惑時便於追溯 |
| 提出時間 | 原始需求的獲得時間，輔助信息 |
| 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，負責解釋需求 |
| 提交時間 | 需求的錄入時間，輔助信息 |
| |模塊(*) | 根據產品的模塊劃分(一般** |
| 名稱(*) | 用簡潔的短語描述需求 |
| 描述(*) | 需求描述：無歧義、完整性、一致性、可測試性等 |
| 提出者 | 即需求的原始提出者，有疑惑時便於追溯 |
| 提出時間 | 原始需求的獲得時間，輔助信息 |
| bug編號 | 將一些bug視爲需求，統一管理 |
| 分類 | 新增功能、功能改進、體驗提升、bug修復、內部需求等 |
| 層次 | 基礎、擴展（期望需求）、增值（興奮需求）（參見KANO模型） |
| 重要性 | 重要程度，輔助信息 |
| 緊急度 | 緊急程度，輔助信息 |
| 持續時間 | 持續時間，輔助信息 |
| 商業價值(*) | 行業優先級，不考慮實現難度，羣體決策 |
| 開發量(*) | 需求的開發工作量，表徵實現難度，如以“人天”爲單位 |
| 性價比(*) | 商業價值/開發量，用於決定先做哪個 |
| 狀態(*) | 需求生命週期：待討論、暫緩、拒絕、需求中、開發中、已發佈 |
| 負責PD(*) | 狀態進入“需求中”後確定 |
| 開發工程師 | 狀態進入“開發中”後確定 |
| 項目名稱 | 需求的發佈項目 |
| 發佈時間 | 需求的發佈時間 |
| 備註 | 其他任何信息，如：
1.被拒絕的理由 2.被暫緩的理由和重啓條件 3.相關文檔 |
6.3 需求管理完整流程
- 需求週期圖
需求週期（圖片來自蘇傑·《人人都是PM》）
從需求採集到需求分析、討論、打包和產品會議，一直到產品開發，可能是一個多次循環改進的過程。 - 需求管理詳細圖
需求管理詳細圖
需求採集主要有四個維度：定量和定性、說和做，用戶需求採集圍繞這四個維度展開。
需求分析從需求轉化、到確定基本需求屬性、分析商業價值、初評實現難度，以及計算性價比。需求轉化是從用戶需求到產品需求，基本屬性來記錄需求的具體內容，商業價值是衡量需求的意義鎖子啊，實現難度以開發量來統計，衡量實現的工作量，性價比確定需求的優先級。
需求篩選通過將需求打包，合併相同和相近的需求，製作BRD，對項目背景、商業價值、功能需求描述、非功能需求描述、資源評估、風險和對策等內容進行分析闡述，最終通過產品會議來確定其具體的商業價值和是否進入開發狀態。
更多文章：
1. UCD的產品設計原則
2. 敏捷UX開發與UCD
參考文獻：
蘇傑·《人人都是產品經理》