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

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

前一段時間，筆者在學習項目管理，對信息系統的需求管理有了較為系統的了解，盡管是傳統的軟件工程領域，但在目前的互聯網領域還是可以借用其理論與方法，借我之理解，寫我之文字。

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

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

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

相對于復雜龐大的信息系統工程軟件，互聯網軟件顯得比較輕快，同樣的，應對信息系統工程軟件的多道工序可以簡化，使其更貼近互聯網的特點，適應互聯網的發展。

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

一.需求獲取

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

WHAT（獲取信息）

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

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

WHERE（需求來源與渠道）

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

1. 公司戰略層面
2. 用戶層面
3. 業務部門（如銷售、運營、客服等）
4. 領導老板
5. 競爭對手產品
6. 應用市場反饋或產品反饋渠道
7. 產品經理本人

HOW（獲取方式）

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

二.需求分析

需求分析是一次用戶需求轉化為產品需求的過程。

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

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

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

判斷用戶需求

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

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

描述用戶需求

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

• 構建用戶畫像

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

用戶畫像的PERSONA七要素：

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

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

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

• 描述用戶場景

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

描述產品需求

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

三.需求定義

需求定義在軟件工程中分為標識需求、定義需求優先級與編寫《需求規格說明書》，在互聯網軟件行業定義需求優先級可以在需求驗證這一步中。下面主要簡述標識需求與編寫《需求規格說明書》

標識需求

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

下面介紹兩種標識方法：

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

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

編寫需求文檔

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

四.需求驗證

在系統軟件工程中，需求驗證專指在需求規格說明書完成后，對需求規格說明書進行的驗證活動。應用到互聯網軟件，就是對產品需求文檔進行驗證。

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

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

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

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

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

1.會議前

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

2.會議中

• 點明會議背景與目的
• 介紹需求
• 評定優先級、指定需求聯系人與相關開發、設計、測試等人員
• 遇到爭議時，讓會議中出席的領導一錘定音

3.會議后

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

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

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

需求管理能夠確證：

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

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

五.需求確認

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

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

六.需求變更

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

一般來說，小的需求變更只是產品經理口頭通知相關的開發、設計與測試等人員，但復雜的需求變更必須規范化，使需求有源可尋、有據可跟。

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

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

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

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

流程說明：

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

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

流程說明：

• 需求來源：項目組人員發現邏輯、流程上有問題或產品需求與提出的需求不一致等
• 項目組審核：經過項目組相關人員的審核才能確認是否執行變更
• 郵件通知：將確定在本版本進行變更的內容以郵件的方式來通知相關人員

對于變更的內容，項目組相關人員需要進行記錄，方便對需求進行跟蹤。

七.需求跟蹤

需求跟蹤主要的內容是需求的整個生命周期，即從需求源頭到實現的生存周期。

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

需求狀態

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

需求跟蹤矩陣

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

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

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

題外話

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

作者：風涯，一個想要走產品的項目人，在職找產品工作，坐標深圳。

本文由 @風涯 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自PEXELS，基于CC0協議