需求若錯，產(chǎn)品何用？需求是一個復(fù)雜工程，不能正確解鎖，那么使用產(chǎn)品的姿勢也會有問題，希望用這篇文章創(chuàng)建需求方法論，供我之用，供你所取。

產(chǎn)品如同一個緊鎖著的無人城池，需求如同一個鑰匙，讓產(chǎn)品能夠一步步地完整呈現(xiàn)在你的眼前，同樣，這個鑰匙有著精藝的工序，根據(jù)工序一步一步就可以制作出通向產(chǎn)品城池的鑰匙。

前一段時間，筆者在學(xué)習(xí)項目管理，對信息系統(tǒng)的需求管理有了較為系統(tǒng)的了解，盡管是傳統(tǒng)的軟件工程領(lǐng)域，但在目前的互聯(lián)網(wǎng)領(lǐng)域還是可以借用其理論與方法，借我之理解，寫我之文字。

在軟件工程中，軟件需求工程包括了需求開發(fā)與需求管理兩個部分，需求開發(fā)的目的是通過調(diào)查與分析，獲取用戶需求并定義軟件需求，需求管理的目的是在客戶與項目組之間建立對需求的共同理解，維護需求與其他工作成果的一致性，并控制需求的變更。

需求開發(fā)的過程主要有四個活動：需求獲取、需求分析、需求定義、需求驗證。

需求管理的過程主要有六個活動：制定需求管理計劃、求得對需求的理解、求得對需求的承諾、管理需求變更、維護對需求的雙向跟蹤性、識別項目工作與需求之間的不一致性。

相對于復(fù)雜龐大的信息系統(tǒng)工程軟件，互聯(lián)網(wǎng)軟件顯得比較輕快，同樣的，應(yīng)對信息系統(tǒng)工程軟件的多道工序可以簡化，使其更貼近互聯(lián)網(wǎng)的特點，適應(yīng)互聯(lián)網(wǎng)的發(fā)展。

需求開發(fā)的過程不管對工程軟件還是互聯(lián)網(wǎng)軟件都是適用的，都會經(jīng)歷一個需求獲取、需求分析、需求定義與需求驗證的過程，但在需求管理的過程中，在圖中可以看到需求管理與需求開發(fā)是一個相互作用的過程，并非有一個先后的順序，所以針對互聯(lián)網(wǎng)的特點，在需求管理這一個過程里可以簡化為需求確認、需求變更與需求跟蹤。在下面的介紹里主要是互聯(lián)網(wǎng)需求工程的七個部分：

一.需求獲取

需求的獲取可以從三個方面來說明：

WHAT（獲取信息）

在需求獲取這一過程里最重要的是獲取的什么信息，畢竟不管白貓黑貓，能抓到老鼠就是好貓，只要能得到需要的信息，選擇何種方式是看你的喜好的，只是說不同的方式有不同的好處。

信息主要是兩個方面：業(yè)務(wù)與用戶，業(yè)務(wù)如業(yè)務(wù)流程、業(yè)務(wù)模式等，用戶如用戶信息、社會屬性、消費行為、使用場景、遇到的問題等。

WHERE（需求來源與渠道）

需求的來源與渠道很多，如：

1. 公司戰(zhàn)略層面
2. 用戶層面
3. 業(yè)務(wù)部門（如銷售、運營、客服等）
4. 領(lǐng)導(dǎo)老板
5. 競爭對手產(chǎn)品
6. 應(yīng)用市場反饋或產(chǎn)品反饋渠道
7. 產(chǎn)品經(jīng)理本人

HOW（獲取方式）

1. 用戶訪談（結(jié)構(gòu)化與非結(jié)構(gòu)化：結(jié)構(gòu)化是指事先準備好一系列問題，有針對地進行；非結(jié)構(gòu)化是指列出一個粗略的想法，根據(jù)訪談的具體情況進行發(fā)揮。在訪談的過程中建議綜合兩種方法）
2. 用戶調(diào)查（由于缺乏面對面的交流，所獲取的信息量比較有限，在實際工作中，建議是采用用戶調(diào)查獲取一定量的信息，然后有針對地去開展用戶訪談）
3. 現(xiàn)場觀摩（典型的定性分析，在現(xiàn)場觀察用戶怎么說怎么做）
4. 運營數(shù)據(jù)分析（針對已上線的產(chǎn)品，通過產(chǎn)品的運營監(jiān)控獲取運營數(shù)據(jù)，分析數(shù)據(jù)提煉需求為產(chǎn)品迭代升級提供一定依據(jù)）
5. 用戶模擬（代入用戶角色，化身小白用戶，親身使用產(chǎn)品，思考在該場景下用產(chǎn)品做什么，怎么做）
6. 需求討論會（聯(lián)合各關(guān)鍵用戶、分析人員、開發(fā)人員等，通過有組織的會議來討論需求。在會前說明此次會議主題，發(fā)放需求記錄單，讓與會人員將使用產(chǎn)品過程中的想法、發(fā)現(xiàn)的問題和不足都記錄下來，形成清單進行討論，從中提煉需求）
7. 原型法（將主要功能開發(fā)出可操作的原型，紙面原型、Axure原型也可以，邀請用戶進行使用，及時征求用戶意見，確定用戶需求）

二.需求分析

需求分析是一次用戶需求轉(zhuǎn)化為產(chǎn)品需求的過程。

用戶需求表述的是用戶的期望與目的，或用戶希望產(chǎn)品完成的任務(wù)。通常情況下，用戶所提出的需求都是從自身角度出發(fā)，從用戶角度來說是絕對正確的，但在其不了解產(chǎn)品整體的情況下，這并不一定能達到用戶的要求，一方面用戶表達的并不一定是內(nèi)心最真實的期望，另一方面這也不一定是產(chǎn)品的最佳解決方式。

產(chǎn)品需求是通過分析挖掘出用戶內(nèi)心最真實的需求，并提出符合產(chǎn)品定位的解決方案。

需求分析的過程可以依照以下幾個步驟：

判斷用戶需求

用戶需求的判斷可從以下方面進行：

• 該用戶是否是目標用戶（非目標用戶所提出的需求其參考價值意義不大，當(dāng)然并非絕對）
• 用戶群大?。ㄊ占脩艋拘畔?，輸出用戶畫像，調(diào)查用戶群體數(shù)量。對于上一條非目標用戶，可進行用戶群數(shù)量調(diào)查，挖掘出新用戶群的新需求）
• 該需求是否符合產(chǎn)品定位（該需求的滿足有可能影響到產(chǎn)品的核心服務(wù)，對產(chǎn)品調(diào)性產(chǎn)生負面影響，也有可能影響到用戶體驗等）
• 該需求能否被解決
• 需求價值（是否迫切強烈、是否必須解決、是否高頻、持續(xù)時間是否長、是否符合產(chǎn)品版本規(guī)劃）

描述用戶需求

描述用戶需求的過程主要兩個方面：構(gòu)建用戶畫像與描述使用場景。

• 構(gòu)建用戶畫像

一切工作的開展都應(yīng)該圍繞著用戶需求來展開，而不是產(chǎn)品團隊里某個人的喜好，為了讓整個團隊在產(chǎn)品設(shè)計的過程中拋棄個人喜好，將焦點關(guān)注在目標用戶的目的與動機上，就需要構(gòu)建用戶畫像進行聚焦。

用戶畫像的PERSONA七要素：

• P代表基本性（Primary）：指該用戶是否基于對真實用戶的情景訪談
• E代表同理性（Empathy）：指用戶角色中包含姓名、照片和產(chǎn)品相關(guān)的描述，該用戶角色是否引同理心
• R代表真實性（Realistic）：指對那些每天與顧客打交道的人來說，用戶角色是否看起來像真實人物
• S代表獨特性（Singular）：每個用戶都是獨特的，彼此很少有相似性
• O代表目標性（Objectives）：該用戶角色是否包含于產(chǎn)品相關(guān)的高層次目標，是否包含關(guān)鍵詞來描述該目標
• N代表數(shù)量性（Number）：用戶角色的數(shù)量是否足夠少，以便設(shè)計團隊能記住每個用戶角色的姓名，以及其中的一個主要用戶角色
• A代表應(yīng)用性（Applicable）：設(shè)計團隊是否能使用用戶角色作為一種實用工具進行設(shè)計決策

關(guān)于構(gòu)建用戶畫像的方法很多，像Alen Cooper的“七步人物角色法”、Lene Nielsen的“十步人物角色法”等，借鑒于這些方法，可以將構(gòu)建用戶畫像分為以下幾個步驟：

1. 確定用戶分類維度（大部分用戶體驗研究是將用戶的心理特點與人口統(tǒng)計學(xué)特征來作為分類維度對用戶進行分類的，而用戶畫像是針對特定產(chǎn)品或其功能，其分類是根據(jù)用戶的目標（用戶需求）與行為模式（具體行為或行為傾向）
2. 收集數(shù)據(jù)（數(shù)據(jù)的收集需要考慮到數(shù)據(jù)基本信息與數(shù)據(jù)類型兩個因素，數(shù)據(jù)基本信息包括用戶類型，用戶樣本數(shù)量與收集方式，數(shù)據(jù)類型包括定性數(shù)據(jù)、定量數(shù)據(jù)以及經(jīng)定量數(shù)據(jù)轉(zhuǎn)化而來的定性數(shù)據(jù)；根據(jù)分類維度，不同的數(shù)據(jù)類型使用不同的數(shù)據(jù)收集方式，用戶的目標可以采用定性的研究方式（用戶訪談，定性式問卷調(diào)查、焦點小組等），行為模式可以采用定性的研究方式（現(xiàn)場觀摩、卡片分類法、可用性測試等）或定量的研究方式（數(shù)據(jù)分析等）
3. 分類用戶（根據(jù)大量數(shù)據(jù)中特征的相關(guān)性與相似程度，對用戶進行分類，得到每一類用戶包含的典型特征，對用戶進行分類可以參考親和圖、聚類分析、德爾菲法等）
4. 評定優(yōu)先級（ 評定優(yōu)先級就是根據(jù)產(chǎn)品目標與產(chǎn)品功能對不同用戶評定重要級別。具體評定的標準根據(jù)產(chǎn)品來，可以以市場大小、收益潛力、使用頻率來分，也可以就用戶類型特征與功能特征的相似程度來分等，將用戶劃分為重要用戶、次要用戶、不重要用戶）
5. 豐富畫像（為了豐富用戶畫像，使其看起來像一個獨立的真實的個體，可以加入姓名、性別、年齡、喜好情況等）

• 描述用戶場景

用戶場景（或者叫使用場景）由用戶與場景兩部分組成，用戶為上一步所劃分出來的典型用戶畫像，場景一般由背景、時間、空間、需求組成。

描述產(chǎn)品需求

從用戶需求到產(chǎn)品需求的轉(zhuǎn)化在于探究用戶內(nèi)心，用戶需求是用戶說出來的，并不代表用戶內(nèi)心最真實的需求，所以想要知道用戶內(nèi)心最真實的需求就需要向用戶問“Why”，從產(chǎn)品功能的角度找到一個解決方案來解決用戶的問題，這就形成了產(chǎn)品需求。

三.需求定義

需求定義在軟件工程中分為標識需求、定義需求優(yōu)先級與編寫《需求規(guī)格說明書》，在互聯(lián)網(wǎng)軟件行業(yè)定義需求優(yōu)先級可以在需求驗證這一步中。下面主要簡述標識需求與編寫《需求規(guī)格說明書》

標識需求

在傳統(tǒng)的系統(tǒng)軟件中，由于需求數(shù)目眾多，可能達到上萬，為了高效管理這么大數(shù)量的需求，就需要對需求進行標識。盡管產(chǎn)品在上線階段需求不可能很多，但在產(chǎn)品的生命周期過程中因產(chǎn)品迭代，需求是不斷增加的，這時為了更高效地管理需求也可以對需求進行標識。

下面介紹兩種標識方法：

1. 序列號（簡單地說就是賦予每一個需求一個數(shù)字編號，因為只是簡單的數(shù)字編號，所以不能表示任何更多的信息，不能提供任何層次和邏輯上的區(qū)別）
2. 層次編碼（層次編碼采用標點符隔開，以表示需求文檔中某一段某一個需求，如1.1.1.1，代表1.1.1中的第一個需求，標識中的數(shù)字越多代表劃分的需求越細，這樣的需求標識方法便于區(qū)分該需求是哪一個模塊或某一個功能。

需要注意的是，對需求進行標識是為了更好地管理與更高效地查詢需求，這對管理需求與需求的跟蹤提供巨大的幫助，所以這兩種方法沒有絕對的優(yōu)點，同樣也沒有一種需求標識的方法是絕對完美的。因項目而異，找到最適合項目的標識需求方法，才能最大程度上提高查詢的效率。

編寫需求文檔

《需求規(guī)格說明書》對應(yīng)到互聯(lián)網(wǎng)軟件就是產(chǎn)品需求文檔，而一份產(chǎn)品需求文檔的編寫大致可以參考我的這一篇文章《產(chǎn)品需求文檔丨云之家V1.0版需求文檔》。

四.需求驗證

在系統(tǒng)軟件工程中，需求驗證專指在需求規(guī)格說明書完成后，對需求規(guī)格說明書進行的驗證活動。應(yīng)用到互聯(lián)網(wǎng)軟件，就是對產(chǎn)品需求文檔進行驗證。

需求驗證的方法在互聯(lián)網(wǎng)軟件中用的最多的還是需求評審，需求評審的目的是為了讓與會人員能清晰地了解需求是什么，需求從哪里來，需求對用戶的意義，需求對產(chǎn)品的影響，需求的責(zé)任人，評審需求是否正確與評定需求的優(yōu)先級等。

需求評審會議有兩種形式，非正式與正式：

非正式的是吼一嗓子，把各相關(guān)人叫過來，直接對著電腦上的需求開始講，并就需求進行討論。

正式的需求評審會議一般是為產(chǎn)品初始版本或大版本迭代而開，這里要介紹的就是正式的需求評審會議。

按時間進程可以分為會議前、會議中、會議后三個階段：

1.會議前

• 會議前預(yù)定好會議室
• 發(fā)一封會議郵件，言明會議時間、會議室、會議主題，發(fā)送給項目干系人，時間提前3-5天
• 小范圍先將需求溝通，將產(chǎn)品方案進行改善，不然等到正式評審的時候就會被各種懟
• 將產(chǎn)品方案附加在郵件中，可以讓與會人員先對方案有個概覽，加快會議的進程，同時也可以讓因事未參與到會議中的相關(guān)人員查看到產(chǎn)品方案
• 做一些會前準備，如檢查投影設(shè)備

2.會議中

• 點明會議背景與目的
• 介紹需求
• 評定優(yōu)先級、指定需求聯(lián)系人與相關(guān)開發(fā)、設(shè)計、測試等人員
• 遇到爭議時，讓會議中出席的領(lǐng)導(dǎo)一錘定音

3.會議后

• 整理會議記錄群發(fā)郵件
• 與相關(guān)人員溝通會議中的問題，解決問題，補充整理好產(chǎn)品文檔發(fā)送給所有人員

需求確認、需求變更、需求跟蹤屬于需求管理，顧名思義是對需求開發(fā)的過程進行管理。

關(guān)于需求管理的作用，我看到這么一段文字。

需求管理能夠確證：

1. 我們確知客戶的需求是什么（質(zhì)量）
2. 滿足客戶需求的最佳解決方法（統(tǒng)一性）

而著名學(xué)者Crosby對于質(zhì)量的定義就是“同需求保持統(tǒng)一”。我們每個人都應(yīng)該始終明白我們所做的具體任務(wù)其意義何在，然而在一個產(chǎn)品的生命周期里，其需求性是能動的，是處于變化之中的，所以為保證產(chǎn)品的質(zhì)量，我們必須時刻保持與需求的統(tǒng)一性，隨變而變。

五.需求確認

需求確認的意思就是設(shè)法理解需求提供者提出的這些需求的含義，那么作為第一手接觸用戶需求的產(chǎn)品人，需要設(shè)法理解用戶所提出的需求，同時要將我們理解的需求表達給我們開發(fā)、設(shè)計與測試等，設(shè)法讓他們也理解用戶的需求，確保大家對需求的理解一致，實際上需求開發(fā)的四個過程就是需求確認的動作，需求的獲取與分析過程是在理解用戶所提出的需求，而需求驗證的過程則是向項目組人員傳達用戶的需求，設(shè)法讓他們理解。

在系統(tǒng)軟件工程中，需求確認的另一個作用是防止項目范圍的蔓延，項目組理解了客戶的需求，向用戶反饋所理解的需求，得到用戶的認可后，簽署需求確認書，一旦簽訂需求確認書，就意味著整個項目的范圍已經(jīng)確定，在項目實施的過程中不允許客戶隨意更改項目范圍，增加或者變更需求。但在互聯(lián)網(wǎng)軟件工程中，我們是不可能與用戶簽訂一個需求確認書，來防止用戶變更需求，只能在獲取需求與分析需求的過程中準確理解用戶需求，并設(shè)法挖掘到用戶內(nèi)心最真實的需求。

六.需求變更

首先需要明確一點的是需求變更是不可避免的，我們是不可能控制需求永遠不會變更，所以對比我們需要有一個正規(guī)的流程來對變更的需求進行管理。

一般來說，小的需求變更只是產(chǎn)品經(jīng)理口頭通知相關(guān)的開發(fā)、設(shè)計與測試等人員，但復(fù)雜的需求變更必須規(guī)范化，使需求有源可尋、有據(jù)可跟。

如前文所說，滿足用戶需求最佳的解決方式就是統(tǒng)一性，所以最終需要解決的就是保證產(chǎn)品與用戶需求的一致性。

需求變更的來源一般是兩個方面，一個是用戶，一個是項目組，但大部分都來自于產(chǎn)品經(jīng)理本人。需求變更一般來說形式就三種：刪除、新增、修改。

下面就兩種情況進行說明：

1.用戶提出需求變更流程

流程說明：

• 需求來源：用戶提出需求變更
• 產(chǎn)品經(jīng)理初步審核：通過產(chǎn)品經(jīng)理自己對需求的判斷，判斷是否有必要做、是否能做等
• 項目組審核：評估實現(xiàn)需求的難度、人力成本、時間成本；對該版本迭代是否有影響，該版本是否能夠?qū)崿F(xiàn)等
• 需求確認：通過項目審核后，可以與用戶確認需求，確保項目對需求的理解與用戶一致，要開發(fā)的功能能故解決用戶的問題
• 郵件通知：確認需求后，發(fā)送郵件通知所有項目干系人，說明需求變更的內(nèi)容

2.項目組提出需求變更流程

流程說明：

• 需求來源：項目組人員發(fā)現(xiàn)邏輯、流程上有問題或產(chǎn)品需求與提出的需求不一致等
• 項目組審核：經(jīng)過項目組相關(guān)人員的審核才能確認是否執(zhí)行變更
• 郵件通知：將確定在本版本進行變更的內(nèi)容以郵件的方式來通知相關(guān)人員

對于變更的內(nèi)容，項目組相關(guān)人員需要進行記錄，方便對需求進行跟蹤。

七.需求跟蹤

需求跟蹤主要的內(nèi)容是需求的整個生命周期，即從需求源頭到實現(xiàn)的生存周期。

上圖是需求跟蹤過程，從用戶需求正向追溯到產(chǎn)品功能，從產(chǎn)品功能反向回溯到用戶需求，在這個過程中，可以區(qū)分用戶需求是否因為需求變更而變化、是否轉(zhuǎn)化為產(chǎn)品功能、產(chǎn)品功能是否有對應(yīng)的用戶需求等，使需求做到有源可溯。

需求狀態(tài)

在需求開發(fā)的過程中，跟蹤需求的狀態(tài)時需求管理的一個重要方面。記錄每條需求的狀態(tài)，對于項目的進度以及對項目的整體把握有很大幫助，下面是幾種建議的狀態(tài)值：

需求跟蹤矩陣

在需求管理中，要收集需求的變更和變更的理由并維持對用戶需求、產(chǎn)品需求和產(chǎn)品功能的雙向跟蹤。

不論采用正向跟蹤還是逆向跟蹤，都要建立與維護需求跟蹤矩陣。需求跟蹤矩陣保證了需求與后續(xù)工作成果的對應(yīng)關(guān)系，當(dāng)后續(xù)工作成果發(fā)生變更時，要及時更新需求跟蹤矩陣，需求跟蹤矩陣對管理需求變更也能提供幫助。下面是簡單的需求跟蹤矩陣：

總體來說，在需求跟蹤的過程中除了上述工具和方法，更常應(yīng)用的是溝通，維持狀態(tài)的改變、及時更新需求跟蹤矩陣以及需求變更都需要通過溝通來進行，所以維持好與項目組人員的溝通，可以更好地開展需求跟蹤工作。

題外話

我只是一個項目人，并不是一個產(chǎn)品人，所以從我的角度并不能完整且完全地描述正確產(chǎn)品角度的需求工程，我希望能通過這篇文章初步構(gòu)建自己的需求方法論，也很希望通過產(chǎn)品人從產(chǎn)品角度來給我述說正確的解鎖需求的姿勢，如果你有關(guān)于需求的方法，請不吝賜教，在評論里提出，從你那里我獲取需要的信息，填補我的需求方法論，謝謝。

作者：風(fēng)涯，一個想要走產(chǎn)品的項目人，在職找產(chǎn)品工作，坐標深圳。

本文由 @風(fēng)涯 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自PEXELS，基于CC0協(xié)議