產品經理的價值輸出：需求分析

2020-07-03由士振文釋出於科技

編輯導語：作為一個產品經理，我們面對的客戶水平參差不齊，提出的需求也千奇百怪，應該先對需求進行分析，再開展下一步的工作。本文將從三個方面，圍繞需求分析展開討論，希望對你有幫助。

調研時，產品經理常常會看到一個兩極分化的現象，對於沒有軟體基礎的使用者：

那麼使用者提的需求，軟體會做哪些呢？這是所有使用者最關心的問題啦。

上一篇文章《2B產品的需求調研，還真不是人人都是產品經理》，我們講了如何做需求調研。這個環節最關鍵的成功要素是：深入理解客戶和使用者的真實需求。

今天進入產品設計的第三個環節：需求分析。

我們從產品經理的本職崗位，來聊聊使用者需求是如何轉化為產品需求的？

這個環節的成功要素是：將需求調研的內容轉化為可被開發與驗證的產品雛形。

下面我們看看一個需求分析的大致步驟：

一、識別出有效的需求

在需求調研中，一般會出現3種情況：

注意：第3種情況都特別常見，我每次和不同的使用者溝通時，他們都喜歡教我怎麼做產品（噼裡啪啦講一堆他希望軟體有什麼？）。我常聽著聽著，就忍不住打斷他們，讓他們停一下，先回答我下面3個問題：

俞軍提醒產品經理：我們要聽使用者說，但不要完全按照使用者說的去做。

那麼如何識別出有效的需求呢？

我們可以把使用者需求轉化成使用者故事的常用句式：我是“某種使用者型別”，我希望“做某件事情”，從而使我“得到某種期望的收益”。

舉個栗子：我是一個HR，我希望系統每個月能自動計算出所有人員的薪資，從而使我提高薪資計算效率（PS:我們的薪資有明確的計算規則）。

注意看上面這段描述，沒有任何關於如何計算薪資的細節描述，但講清楚了使用者是誰？要達到什麼目的？做這件事有什麼價值？

當一個需求能用上面的使用者故事句式來講清楚後，我們再深入瞭解具體業務流程、業務規則、資料流等，這才有意義。

當產品經理開始關注每個需求的ROI（投入產品比）時，就會謹慎對待使用者提出的每個需求。

二、使用者需求轉化為產品需求1. 將業務流程圖轉化為產品功能流程圖

在需求調研階段，我們根據業務需求描述繪製了業務流程圖，這便於我們直觀地理解業務流。

現在產品經理需要把業務流程圖再轉化為功能流程圖。PS:功能流程圖指的是未來產品上一個個實際的功能。

以上面的使用者故事為例：我是一個HR，我希望系統每個月能自動計算出所有人員的薪資，從而使我提高薪資計算效率。我們只考慮其中固定工資的計算，產品的功能流程圖如下：

我們講解下上面的功能流程圖，是如何計算人員的固定工資：

首先要有人員基本資訊（工號、姓名、身份證、手機號、職級等），職級對應工資表（每個職級對應的基本工資、交通補貼、通訊補貼、住宿補貼等）、人員的出勤記錄（每個人員本月的出勤天數）；
其次根據上述3個功能，我們可以獲取計算每個人員固定工資的必備資訊，比如：姓名張三，職級M2,基本工資5000，各類補貼合計1000，本月出勤天數20（滿勤按22.5天）。工資計算，張三的本月固定薪資=基本工資5000*出勤天數20/滿勤天數22.5+補貼合計1000。
最後有固定工資表用來存放工資計算後的資料結果，便於查詢。

每一個使用者故事，對應到軟體產品，可能由多個功能（矩形代表功能，箭頭代表功能操作順序）來組成。

2. 將業務規則轉化為二維表、狀態圖

需求調研階段，使用者向我們描述了一堆的管理規章制度，那麼這些資訊怎麼樣結構化地轉化為更直觀的需求分析呢？

以運費計算為例：運費模板中包含包郵條件、預設地區運費規則、指定地區運費規則。

功能頁面如下：

我特意製作了下面的二維表作為測試用例，輔助使用者測試。

上面的二維表窮舉了不同訂單下（當收貨地址、訂單金額、重量不同時），運費的計算規則，避免使用者測試時有遺漏。

再以一個訂單狀態為例：電商訂單一般有待付款、待發貨、待收貨、已完成、退款中、已退款、已關閉這些狀態。我們以一個簡易的狀態圖來表示

上面的狀態圖，描述了不同狀態之間是如何變化的？A狀態（待付款）當遇到某個事件發生（買家付款成功）則變為B狀態（待發貨）。透過狀態圖來理解訂單的不同狀態，會讓讀者有種一圖勝千言的感覺.

三、小結

上面我們煞費了一番苦工，終於把使用者需求的調研內容，轉化成了更便於軟體方專案組成員理解的產品雛形。現在拿著這些設計半成品，產品經理就可以更好地進入下一步的原型設計了。

產品經理們看著上面一個個的圖、表，應該有一番成就感。這些才是我們作為產品經理，提供的實實在在的產出物啊。

如果沒有這上面一番的需求分析，直接進入頁面級的原型設計，極易陷入揀了芝麻丟了西瓜的境地。小白們，切記切記~

本文由 @追夢人原創釋出於人人都是產品經理，未經許可，禁止轉載。

題圖來自 Unsplash，基於CC0協議