編輯導(dǎo)語：需求評(píng)審對(duì)于產(chǎn)品經(jīng)理來說是再熟悉不過的一件事了，產(chǎn)品經(jīng)理作為需求的承接者和中間樞紐，需要對(duì)需求進(jìn)行整理分析和準(zhǔn)確輸出，而輸出需求，是一個(gè)不小的難題。

產(chǎn)品經(jīng)理在工作中扮演者一個(gè)角色為“樞紐”，樞紐負(fù)責(zé)是承上啟下，我們從業(yè)務(wù)、市場、老板方面得到需求，經(jīng)過我們的調(diào)研設(shè)計(jì)，需要呈現(xiàn)出一份供所有人閱讀的文檔，如果要做出一份讓所有人都能看懂的文檔，我們的“輸出能力”就顯得特別重要。

很多產(chǎn)品同學(xué)在工作中，經(jīng)常會(huì)出現(xiàn)和技術(shù)同事“扯皮”，會(huì)陷入困惑，明明需求寫的這么清楚，邏輯都是正確的，為什么技術(shù)同事就是不能理解呢？

一、分析各個(gè)角色

1. 業(yè)務(wù)

業(yè)務(wù)部門是需求的提出者，也是后續(xù)系統(tǒng)的使用者。我們與業(yè)務(wù)進(jìn)行溝通的時(shí)候要深談，了解業(yè)務(wù)現(xiàn)在的痛點(diǎn)，我們?nèi)绾谓鉀Q這樣的問題，所付出的成本是多少，能為公司帶來的效益是多少？

2. 后端技術(shù)

后端負(fù)責(zé)處理系統(tǒng)邏輯和數(shù)據(jù)，后端關(guān)心的是數(shù)據(jù)如何存儲(chǔ)，數(shù)據(jù)是怎么流轉(zhuǎn)，如何保證系統(tǒng)運(yùn)行的性能，出現(xiàn)異常是怎么處理的？

3. 前端技術(shù)

前端負(fù)責(zé)信息的展示，功能的操作，界面的跳轉(zhuǎn)；前端需要了解系統(tǒng)的控件怎么使用，哪些控件是可以統(tǒng)一的，要符合什么樣的界面設(shè)計(jì)。

二、信息的不同表達(dá)方式

我們先來回想一下新聞媒體的發(fā)展歷程，純文字報(bào)紙->網(wǎng)絡(luò)圖文->短視頻，傳遞信息的媒介越來越趨于具象化。

我們淡出使用文字來進(jìn)行描述往往比較蒼白，例如文字“嗯”，單純這個(gè)字，我們很難說這個(gè)字表達(dá)出的是什么意思，如果加上標(biāo)點(diǎn)符號(hào)再來看：“嗯?！薄班?？”，能看出來一個(gè)是肯定，一個(gè)是疑問，同樣的文字，因?yàn)闃?biāo)點(diǎn)符號(hào)不同，所表達(dá)的意思也不同。如果這個(gè)文字通過聲音傳達(dá)出來呢？再輔助人的臉部表情呢？

近幾年敏捷開發(fā)越來越流行，我在了解敏捷開發(fā)知識(shí)的時(shí)候，對(duì)“增量和迭代”兩種模式有所困惑，翻找資料過程中，我看到了這樣的描述：

增量模型 (Incremental Model)?是您在部分中構(gòu)建整個(gè)解決方案的地方，但是在每個(gè)階段或部分結(jié)束時(shí)您沒有,?任何可以審查或反饋的東西。您需要等到增量過程的最后階段才能交付最終產(chǎn)品。

迭代模型 (Iterative Model)?是我們迭代這個(gè)想法并在迭代各種版本時(shí)不斷改進(jìn)的地方。你從一個(gè)版本移動(dòng)到另一個(gè)版本你決定（根據(jù)反饋）在新版本中需要什么作為更好的選擇以及需要丟棄什么。

不明所以，然后我又翻找資料，看到了這樣的解釋說明，1為增量，2為迭代，一目了然，這就是圖片的力量：

三、與不同角色溝通

1. 業(yè)務(wù)

我們與業(yè)務(wù)溝通的時(shí)候，已經(jīng)分析了業(yè)務(wù)的痛點(diǎn)和要求，在需求確認(rèn)時(shí)，可以輔助例如這樣的腦圖，清晰的展示業(yè)務(wù)點(diǎn)：

2. 后端技術(shù)

后端的邏輯是最復(fù)雜的，特別是一些算法和業(yè)務(wù)場景。我曾經(jīng)負(fù)責(zé)一個(gè)項(xiàng)目【備貨計(jì)劃系統(tǒng)】，我們對(duì)備貨計(jì)劃的定義是這樣的：

備貨系統(tǒng)依據(jù)銷量、庫存、時(shí)效進(jìn)行一系列運(yùn)算，預(yù)測出未來市場趨勢和備貨需求，由采購負(fù)責(zé)下單，倉儲(chǔ)進(jìn)行收貨、物流執(zhí)行發(fā)運(yùn)，這一套完善的供應(yīng)鏈服務(wù)，支撐客戶的需求，提高庫存周轉(zhuǎn)率，達(dá)到降低缺貨減少庫存資金壓力的目標(biāo)。

在與技術(shù)溝通需求時(shí)，我發(fā)現(xiàn)技術(shù)同事很難理解一些關(guān)鍵參數(shù)名詞定義，于是我畫了下面這張圖，來表達(dá)各個(gè)參數(shù)之間是什么樣的關(guān)系，于是我們針對(duì)這張圖的各個(gè)節(jié)點(diǎn)展開了需求討論：

在模擬庫存變化情況的時(shí)候，我們有了這張圖：

在模擬異常銷量排除時(shí)，我們有了這張圖：

我使用了大量的圖文結(jié)合來表達(dá)我希望實(shí)現(xiàn)的需求，后端技術(shù)同事能夠很快的了解我的意思。

3. 前端技術(shù)

前端同事對(duì)于邏輯沒有太多的關(guān)注，他們更關(guān)心數(shù)據(jù)的展示。

例如我們?cè)诒磉_(dá)希望前端同事在時(shí)間選擇器上面加上快捷搜索的時(shí)候，可以這樣表達(dá)需求，時(shí)間搜索項(xiàng)中加快捷搜索，快捷搜索的為以下幾個(gè)：今日、昨日、近2天、近七天、近15天、近30天，解釋如下；

假設(shè)今天是2021/3/30：

今日：2021/3/30 00:00:00-2021/3/30 23:59:59

昨日：2021/3/29 00:00:00-2021/3/29 23:59:59

近2天：2021/3/29 00:00:00-2021/3/30 23:59:59

近3天：2021/3/28 00:00:00-2021/3/30 23:59:59

近7天：2021/3/24 00:00:00-2021/3/30 23:59:59

近15天：2021/3/16 00:00:00-2021/3/30 23:59:59

近30天：2021/3/1 00:00:00-2021/3/30 23:59:59

四、結(jié)語

我們?cè)俟ぷ髦辛私庑枨?，設(shè)計(jì)系統(tǒng)很重要，我們把設(shè)計(jì)方案傳達(dá)給下個(gè)工作部門去實(shí)現(xiàn)也同樣重要，PRD文檔只是我們用來表達(dá)需求的一種媒介而已，與技術(shù)同事的頻繁溝通可以減少系統(tǒng)的出錯(cuò)概率。

孰能生巧，希望大家能找到自己的方法論；望與君共勉，歡迎評(píng)論騷擾~

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

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