需求定義不準確，程序猿淚崩?。˙端）描述產品的某個需求看似是一件很簡單的事情，感覺只要指出具體的事項和產品需要提供什么就可以了。實則不然，在日常溝通中，我們仍是對很多問題存在爭論。這時候，就要求我們必須轉唄定義產品需求，對問題達成共識。具體如何做？文章對此展開了梳理分析，與大家分享。

需求定義嚴格來說并不屬于需求工程的范疇之內，它是產品立項時要做的事情，最核心的工作是確立一個合理的項目目標與范圍。

關于項目目標與范圍，企業高層通常是依據自己的洞見與經驗去判定，有時缺乏集體智慧與科學驗證，導致它與團隊實際能力及業務真實需求出現偏差，即找不準要解決的根本性業務問題或發展機會，項目出現“上梁不正下梁歪”的情況。

如果方向錯誤且船只結構的打造扛不住實際風浪，那么船只不僅偏離合理的軌跡，還會面臨驚濤駭浪，最終做了很多無用功?？梢?，需求定義是不容忽視的一個環節。

需求定義的工作從方向性著手點是確定問題或者尋找機會。

舉個例子，當一家雜貨店發展為雇用了幾個店員的小型超市時，貨品豐富，日成交量數十倍增，這時候用EXCLE難以滿足經營管理需要，比如多人協作的數據登記工作、數據安全性無法保障、無法固定業務操作流程等問題。

為了解決這個問題，小超市就需要一套采用ERP系統來滿足企業資源管理的需要，才能使業務有序、高效率的發展。

也就說，伴隨著業務量級的增長，企業都會在資源管理、客戶服務等方面出現業務瓶頸，比如資源復用性低、效率差、流程繁瑣不可控等，這時候我們需根據業務發展來確定問題或尋找機會來設計產品以支持發展戰略。

那么我們如何確定問題or機會（目標）？

一類內部尋根，找到項目發起人深入溝通；另一類是外部溯源，有些項目的發起可能受外部環境影響，比如競品同行、新技術趨勢等等，這時我們需要找到參照物進行研究。

通常情況，我們都是根據數據反饋或者KPI指標來發現表象問題，接下來我們該如何找到問題根源并準確定義問題以及合理的解決思路呢？

01 對問題達成共識

1. 準確定義問題

首先我們自己要問題清楚定義，這里涉及到兩個技巧。

第一、轉換思維，即把未知解問題轉換成已知解問題。比如朋友欠錢不還，自己追還不了，那么可以找到他的身份信息起訴，自己不會起訴不要緊，委托個律師就好了。通過解決一些系列已知解問題來解決根本問題第二、追溯本源。問題經常會被表象掩蓋，如果直接解決表層問題，不僅不能治本，還會帶來其它方面的問題。

舉個例子，在一個山脈內建了一條很長的汽車隧道，為了防止停電時隧道內發生車禍，交通部在隧道入口寫了“進隧道前請打開車頭燈！”的提示語。但是，不久后有司機投訴，由于隧道出口景色太美，司機經常忘記關燈，導致返程時汽車沒電了。

有人提出可以提醒他們出隧道時關掉車燈！那么我們思考問題解決了沒？沒有，因為在司機如果是在夜晚行駛（不同的時間狀態下）時候會懵圈。

有人說那我們可以提示司機“白天，進隧道時打開車頭燈，出隧道關閉車頭燈；晚上出隧道時不要關閉車頭燈！”這個方案弊端就是文字太長，在高速行駛上，司機沒有時間和注意力看完一段文字。

那么，我們思考怎樣根本上解決問題？案例中，我們對問題的因果最終推導是：車沒電是因為司機忘記關燈，而忘記關燈時因為缺乏提醒。那么，解決方案在于我們要如何提醒且又能避免夜行司機產生誤解呢？

答案是提示“你的燈亮著嗎？”，這便引導司機關注周圍明暗場景來決定自己的車頭燈是否應該打開。

這個例子就是示范我們如何定義問題以及確定根本問題。

2. 找到問題的根本原因

（1） 利用工具分析

工具1：魚骨圖分析

魚骨圖屬于定性分析，它有利于我們追蹤到問題的根源，使分析人員將問題的原因放在首位，而不是表象，且能讓我們概覽導致問題發生的所有原因的全景圖，這也為收集資料和行動提供全面可靠的指引。

具體實施方法如下：

1. 把第一步定義的每個問題都獨立做一次魚骨圖分析
2. 群體頭腦風暴只找原因而不是找解決方案
3. 分類問題，確定問題歸屬的類型。比如常見的人機料法環
4. 如果某個原因屬于多個類型，并這個情況多次出現，可以考慮新增問題類型
5. 每個原因可以思考what-why-where三者來發展更細層級的原因
6. 公開討論所有原因的想法和經驗
7. 尋找重復性高的原因（即多人提出的）
8. 使用檢查表收集資料、制作流程圖或進行客戶調查，通過帕累托分析法測試
9. 各種原因的相對強度
10. 投票制達成一致意見，縮小范圍進行比對。

工具2：帕累托圖分析

魚骨圖比較依賴于決策者的經驗與洞見，外界一致是出于變化的趨勢，為了能夠更準確實時把握住根本原因，還需要結合帕累托分析。

它主要作用就是利用2/8定律，去錨定影響問題的最關鍵根本原因，集合有限的資源優先解決它。帕累托分析通常是根據問題發生的各原因從相對頻率和大小從高到低降序排列的直方圖，找到解決80%問題的20%原因。這里就需要我們去收集已有的產品數據及用戶反饋進行分類針對性地統計。

做個比喻，魚骨圖幫助我們找到解決問題的方向靶，帕累托圖則是在靶子標上環數。

（2）確定相關人員與用戶

在產品需求定義階段，溝通最多的應該是對應業務的高層人員，方向性決不能出錯，此者是管理層，最后是基層操作人員。

對于產品的用戶，我們切記要分類產品的直接用戶，羅列各自的特點并分析，這指導著后續的需求分析。

（3）定義解決方案的界限

我們可以把產品的范圍和邊界區分開來。范圍即產品涉及到的哪些功能和內容來支持業務運轉，邊界則是產品與人的職責邊界。

一個產品劃分出子系統之后，子系統中所支持的流程中我們可以切割出邊界，如何確定邊界有三個因素需綜合考慮。

首先我們會以經費、資源等作為考量因素，即多大能耐就做多大的事；

其次，對性價比、可行性方面的考慮，往往需求方出于同樣的資源投入想獲得更高回報的心理而認為所有需求都是最高優先級，即啥都要，這里我們需要從可行性、人力成本去傳達哪些需求該做，哪些需求不該做，哪些先做哪些慢做，哪些能做哪些不能做，以此說服需求方。

最后，對邊界的延伸與創新，則比較少見。它是基于特定戰略或產品方向去做決策的，通常會把客戶及客戶行為習慣等納入產品的考慮范圍，把業務流程延伸到人的身邊，提高服務支持的便捷性，提高用戶體驗。

（4）確定解決方案的約束

我們在做設計產品時，不可能去自由發揮，有時候基于產品特性、技術要求、外部條件等因素會做一些限制，就不如建設一棟房子，想要建成什么樣的房子，它就會受原材料、地基、土壤、經費、住宅建設政策等條件的限制。

軟件產品的約束通常會分為技術開發與項目實施這兩大類。技術開發：技術約束、預期的軟硬件環境、預期的使用環境等。項目實施：項目預算、行政約束、進度要求及資源支持、環境約束等。

02 需求定義產出物中的關鍵點

1. 目標

一個好的目標需滿足SMART原則，即滿足具體的、可度量、可行的、相關性、時間限制這五個要素。下表為例子。

2. 范圍

在目標確定后，需求定義最主要的工作是圍繞“范圍”展開的，系統需要做哪方面的功能服務才能支撐起業務需要。

在范圍的文檔描述上，我們分別會產出系統的構建圖、上下文關系圖以及需求大綱，簡稱為“兩圖一綱”。

3. 相關人員與用戶

需求定義階段確定相關人員與用戶的目的在于可指導我們在獲取需求具體的執行工作，幫助我們了解這些群體，提高產品的可用性。

通常我們會收集群體與系統主題的相關經驗、技術理解、工作態度、受教育程度、語言技能、年齡等等，即群體的形象建模，其次是他們對產品的關注點或需實現什么利益。

4. 相關事實與假定

相關事實指的是當前產品所存在的問題，比如說原有的產品的人機交互上異常繁瑣，導致效率低下。

假定指的是預估未來可能發生的事件導致產品無法應對，需列出假定事件，避免現有的解決方案思考不周，導致做了許多無用功。

03 定義需求范圍

前文已說明需求范圍的產出物是“兩圖一綱”，而一般邏輯簡單的系統出需求大綱即可。為了讓讀者更為明白如何操作，因此篇幅會比較長，后續筆者會做細致的分享。

項目的目標與范圍就是指南針，方向錯了，那么后續的行為就絲毫沒有正確可言，因此，我們要避免拍腦袋的事情，畢竟人總會有知偏誤的時候，依據管理層的經驗洞見不見得是準確，畢竟人腦中的“系統1”有時候會蒙蔽我們的眼睛。

作者：PM達云霄；公眾號：達云霄，歡迎關注交流。

本文由 @PM達云霄 原創發布于人人都是產品經理，未經作者許可，禁止轉載。題圖來自Unsplash，基于CC0協議。