需求定義不準(zhǔn)確，程序猿淚崩?。˙端）描述產(chǎn)品的某個(gè)需求看似是一件很簡單的事情，感覺只要指出具體的事項(xiàng)和產(chǎn)品需要提供什么就可以了。實(shí)則不然，在日常溝通中，我們?nèi)允菍芏鄦栴}存在爭論。這時(shí)候，就要求我們必須轉(zhuǎn)唄定義產(chǎn)品需求，對問題達(dá)成共識(shí)。具體如何做？文章對此展開了梳理分析，與大家分享。

需求定義嚴(yán)格來說并不屬于需求工程的范疇之內(nèi)，它是產(chǎn)品立項(xiàng)時(shí)要做的事情，最核心的工作是確立一個(gè)合理的項(xiàng)目目標(biāo)與范圍。

關(guān)于項(xiàng)目目標(biāo)與范圍，企業(yè)高層通常是依據(jù)自己的洞見與經(jīng)驗(yàn)去判定，有時(shí)缺乏集體智慧與科學(xué)驗(yàn)證，導(dǎo)致它與團(tuán)隊(duì)實(shí)際能力及業(yè)務(wù)真實(shí)需求出現(xiàn)偏差，即找不準(zhǔn)要解決的根本性業(yè)務(wù)問題或發(fā)展機(jī)會(huì)，項(xiàng)目出現(xiàn)“上梁不正下梁歪”的情況。

如果方向錯(cuò)誤且船只結(jié)構(gòu)的打造扛不住實(shí)際風(fēng)浪，那么船只不僅偏離合理的軌跡，還會(huì)面臨驚濤駭浪，最終做了很多無用功?？梢?，需求定義是不容忽視的一個(gè)環(huán)節(jié)。

需求定義的工作從方向性著手點(diǎn)是確定問題或者尋找機(jī)會(huì)。

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

為了解決這個(gè)問題，小超市就需要一套采用ERP系統(tǒng)來滿足企業(yè)資源管理的需要，才能使業(yè)務(wù)有序、高效率的發(fā)展。

也就說，伴隨著業(yè)務(wù)量級的增長，企業(yè)都會(huì)在資源管理、客戶服務(wù)等方面出現(xiàn)業(yè)務(wù)瓶頸，比如資源復(fù)用性低、效率差、流程繁瑣不可控等，這時(shí)候我們需根據(jù)業(yè)務(wù)發(fā)展來確定問題或?qū)ふ覚C(jī)會(huì)來設(shè)計(jì)產(chǎn)品以支持發(fā)展戰(zhàn)略。

那么我們?nèi)绾未_定問題or機(jī)會(huì)（目標(biāo)）？

一類內(nèi)部尋根，找到項(xiàng)目發(fā)起人深入溝通；另一類是外部溯源，有些項(xiàng)目的發(fā)起可能受外部環(huán)境影響，比如競品同行、新技術(shù)趨勢等等，這時(shí)我們需要找到參照物進(jìn)行研究。

通常情況，我們都是根據(jù)數(shù)據(jù)反饋或者KPI指標(biāo)來發(fā)現(xiàn)表象問題，接下來我們該如何找到問題根源并準(zhǔn)確定義問題以及合理的解決思路呢？

01 對問題達(dá)成共識(shí)

1. 準(zhǔn)確定義問題

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

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

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

有人提出可以提醒他們出隧道時(shí)關(guān)掉車燈！那么我們思考問題解決了沒？沒有，因?yàn)樵谒緳C(jī)如果是在夜晚行駛（不同的時(shí)間狀態(tài)下）時(shí)候會(huì)懵圈。

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

那么，我們思考怎樣根本上解決問題？案例中，我們對問題的因果最終推導(dǎo)是：車沒電是因?yàn)樗緳C(jī)忘記關(guān)燈，而忘記關(guān)燈時(shí)因?yàn)槿狈μ嵝?。那么，解決方案在于我們要如何提醒且又能避免夜行司機(jī)產(chǎn)生誤解呢？

答案是提示“你的燈亮著嗎？”，這便引導(dǎo)司機(jī)關(guān)注周圍明暗場景來決定自己的車頭燈是否應(yīng)該打開。

這個(gè)例子就是示范我們?nèi)绾味x問題以及確定根本問題。

2. 找到問題的根本原因

（1） 利用工具分析

工具1：魚骨圖分析

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

具體實(shí)施方法如下：

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

工具2：帕累托圖分析

魚骨圖比較依賴于決策者的經(jīng)驗(yàn)與洞見，外界一致是出于變化的趨勢，為了能夠更準(zhǔn)確實(shí)時(shí)把握住根本原因，還需要結(jié)合帕累托分析。

它主要作用就是利用2/8定律，去錨定影響問題的最關(guān)鍵根本原因，集合有限的資源優(yōu)先解決它。帕累托分析通常是根據(jù)問題發(fā)生的各原因從相對頻率和大小從高到低降序排列的直方圖，找到解決80%問題的20%原因。這里就需要我們?nèi)ナ占延械漠a(chǎn)品數(shù)據(jù)及用戶反饋進(jìn)行分類針對性地統(tǒng)計(jì)。

做個(gè)比喻，魚骨圖幫助我們找到解決問題的方向靶，帕累托圖則是在靶子標(biāo)上環(huán)數(shù)。

（2）確定相關(guān)人員與用戶

在產(chǎn)品需求定義階段，溝通最多的應(yīng)該是對應(yīng)業(yè)務(wù)的高層人員，方向性決不能出錯(cuò)，此者是管理層，最后是基層操作人員。

對于產(chǎn)品的用戶，我們切記要分類產(chǎn)品的直接用戶，羅列各自的特點(diǎn)并分析，這指導(dǎo)著后續(xù)的需求分析。

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

我們可以把產(chǎn)品的范圍和邊界區(qū)分開來。范圍即產(chǎn)品涉及到的哪些功能和內(nèi)容來支持業(yè)務(wù)運(yùn)轉(zhuǎn)，邊界則是產(chǎn)品與人的職責(zé)邊界。

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

首先我們會(huì)以經(jīng)費(fèi)、資源等作為考量因素，即多大能耐就做多大的事；

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

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

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

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

軟件產(chǎn)品的約束通常會(huì)分為技術(shù)開發(fā)與項(xiàng)目實(shí)施這兩大類。技術(shù)開發(fā)：技術(shù)約束、預(yù)期的軟硬件環(huán)境、預(yù)期的使用環(huán)境等。項(xiàng)目實(shí)施：項(xiàng)目預(yù)算、行政約束、進(jìn)度要求及資源支持、環(huán)境約束等。

02 需求定義產(chǎn)出物中的關(guān)鍵點(diǎn)

1. 目標(biāo)

一個(gè)好的目標(biāo)需滿足SMART原則，即滿足具體的、可度量、可行的、相關(guān)性、時(shí)間限制這五個(gè)要素。下表為例子。

2. 范圍

在目標(biāo)確定后，需求定義最主要的工作是圍繞“范圍”展開的，系統(tǒng)需要做哪方面的功能服務(wù)才能支撐起業(yè)務(wù)需要。

在范圍的文檔描述上，我們分別會(huì)產(chǎn)出系統(tǒng)的構(gòu)建圖、上下文關(guān)系圖以及需求大綱，簡稱為“兩圖一綱”。

3. 相關(guān)人員與用戶

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

通常我們會(huì)收集群體與系統(tǒng)主題的相關(guān)經(jīng)驗(yàn)、技術(shù)理解、工作態(tài)度、受教育程度、語言技能、年齡等等，即群體的形象建模，其次是他們對產(chǎn)品的關(guān)注點(diǎn)或需實(shí)現(xiàn)什么利益。

4. 相關(guān)事實(shí)與假定

相關(guān)事實(shí)指的是當(dāng)前產(chǎn)品所存在的問題，比如說原有的產(chǎn)品的人機(jī)交互上異常繁瑣，導(dǎo)致效率低下。

假定指的是預(yù)估未來可能發(fā)生的事件導(dǎo)致產(chǎn)品無法應(yīng)對，需列出假定事件，避免現(xiàn)有的解決方案思考不周，導(dǎo)致做了許多無用功。

03 定義需求范圍

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

項(xiàng)目的目標(biāo)與范圍就是指南針，方向錯(cuò)了，那么后續(xù)的行為就絲毫沒有正確可言，因此，我們要避免拍腦袋的事情，畢竟人總會(huì)有知偏誤的時(shí)候，依據(jù)管理層的經(jīng)驗(yàn)洞見不見得是準(zhǔn)確，畢竟人腦中的“系統(tǒng)1”有時(shí)候會(huì)蒙蔽我們的眼睛。

作者：PM達(dá)云霄；公眾號(hào)：達(dá)云霄，歡迎關(guān)注交流。

本文由 @PM達(dá)云霄 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載。題圖來自Unsplash，基于CC0協(xié)議。