雖然大家做的項目都是類似的，但在需求評審階段總會因人而異。本文總結(jié)了需求方案講解的幾種情況，希望能讓大家既輸出好的產(chǎn)品方案，同時也把自己的方案講解好，不留遺憾。

寫作背景

我發(fā)現(xiàn)雖然大家做的項目是類似的，但是實際上在講解自己的產(chǎn)品需求方案（原型/需求文檔）的時候就有很明顯的不同，這里會有這么幾個情況：

1. 產(chǎn)品方案做得很好、很全，文檔詳實，流程圖清晰，原型干凈整潔等，但是在講解需求的時候卻不盡人意，可以立即為做得很好，但是講得不好；
2. 產(chǎn)品方案做得一般，文檔沒有寫很細(xì)節(jié)，流程圖和原型等也沒有很齊全，然后在講解需求的時候也會表現(xiàn)出丟三落四，邏輯不清楚的問題。屬于是，做得不太好，講得也不太好；
3. 產(chǎn)品方案做得好，文檔、流程圖、原型圖等內(nèi)容齊全，講解需求的時候細(xì)膩，考慮周全，而且有層次感，可以讓聽的人get到他的想法等；這種做得好，講得也好的，就比較少了；

而通過這么幾次的評審后，我觀察到情況3的學(xué)員比較少，而情況1和情況2的比較多。其中情況1是最讓人可惜的，因為都花了很多時間做得那么好了，但是卻講得不好，讓人感覺“差一點點”就成了，這種遺憾我覺得完全是可以避免的。

所以，我想通過這篇文章來幫助大家解決以上這些問題，希望能讓大家既輸出好的產(chǎn)品方案，同時也把自己的方案講解好，不留遺憾。

一、需求評審中常見的一些問題

在講產(chǎn)品需求方案中需要包含什么內(nèi)容模塊之前，我覺得可以先和大家分享一下需求評審中常見的一些問題，這些問題既是我過往工作中發(fā)生過的，也是我在私享課的評審會上記錄的，都比較有典型代表性。大家可以在日常的工作中以一個“旁聽者”的視角來審視一下，自己是否也遇到過這些問題，有哪些問題可能是自己意識到了但是沒有改，有哪些問題是自己都沒意識到的。

1. 產(chǎn)品方案既是看的，也是講的

在實際的工作中，產(chǎn)品經(jīng)理輸出的產(chǎn)品方案一般會包含各種圖，文檔，原型，還有附件資料等，其中需求文檔和產(chǎn)品原型應(yīng)該是最常見，也是最花時間輸出的。

有一些產(chǎn)品的需求文檔和原型都非常詳實，甚至也會有一些產(chǎn)品經(jīng)理認(rèn)為需求文檔的字?jǐn)?shù)越多越好，感覺文檔沒寫到幾千幾萬字就總是會漏掉什么一樣。

而另一個極端則是文檔和原型都沒什么內(nèi)容，很多時候可能就截個圖表示一下意思，或者是直接在需求評審的會議上對著競品的內(nèi)容直接講解，然后需求就是做成和競品差不多的樣子……

無論是第一種，還是第二種，我都見過，而且我感覺都有很多的優(yōu)化空間，基于我了解的大多數(shù)的公司的研發(fā)機(jī)制和流程規(guī)范，我都會建議：

產(chǎn)品方案既是看的，也是講的。也就是說，不要寫得太多，因為有一些內(nèi)容你是可以通過講解去表達(dá)的；也不要寫得太少，因為有些時候錯過了當(dāng)面評審的會議或者是時間一長，就容易遺忘一些細(xì)節(jié)內(nèi)容。

在下文中，我會重點提到一個產(chǎn)品方案中最好要包含哪些內(nèi)容，如果不知道自己應(yīng)該拿捏在什么度的朋友，請記得看完后續(xù)的內(nèi)容。

2. 結(jié)構(gòu)化的表達(dá)是需要持續(xù)提升的能力

在產(chǎn)品需求評審會議上，很多產(chǎn)品經(jīng)理可能都會遇到一個尷尬的場景：評審到后面的時候大家?guī)缀鯖]認(rèn)真聽了，玩手機(jī)的玩手機(jī)，看電腦的看電腦，甚至有一些人都在打瞌睡了。

拋開一些外界因素（團(tuán)隊制度規(guī)范、個人素質(zhì)和專業(yè)性、團(tuán)隊凝聚力等），我發(fā)現(xiàn)評審效果不太好的很核心的一個原因是：

產(chǎn)品經(jīng)理在表達(dá)輸出自己方案的時候，很容易陷入“不自知”的一種狀態(tài)。例如自己一直持續(xù)地在講，壓根沒留氣口給其他旁聽的人提問或者思考；自己講解的時候各種切換頁面、素材，整個脈絡(luò)混亂，讓人跟不上節(jié)奏；還有就是缺乏圖例，表格，還有一些畫面感的東西講解，基本上就是對著文字在念，讓聽眾很乏味。

對于產(chǎn)品經(jīng)理來說，自己可能花了很多時間去了解需求的背景，然后做了足夠的調(diào)研、會議討論、業(yè)務(wù)設(shè)計、最后整體方案設(shè)計等，這些東西對自己來說可能已經(jīng)滾瓜爛熟了。但是對于聽眾來說，他們可能是第一次聽說這個東西，而且也沒有詳細(xì)的背景鋪墊，沒有足夠的業(yè)務(wù)知識積累，就會導(dǎo)致每次聽需求評審的時候都被臨時丟了一個新的東西，都需要花很多時間和精力去專注理解和吸收。

如果此時產(chǎn)品經(jīng)理在評審自己的方案的時候，沒有一些結(jié)構(gòu)化，脈絡(luò)化，畫面感的東西，那么必然就會導(dǎo)致聽眾沒有聽懂，也跟不上節(jié)奏，然后就演變成了走神、發(fā)呆、各玩各的東西了……

產(chǎn)品經(jīng)理的結(jié)構(gòu)化表達(dá)能力是需要持續(xù)鍛煉的，怎么把自己熟悉的一個事情向新人講清楚，講明白，還要把自己的觀點和方案傳達(dá)清楚，這不是一件容易的事情，需要我們提前準(zhǔn)備足夠的資料，也需要我們有適當(dāng)?shù)木毩?xí)，持續(xù)地去迭代和完善。

3. 文不如表，表不如圖，圖不如當(dāng)面溝通

我的每一節(jié)私享課，我基本上都會花很多時間去畫圖和做表，同時在需求文檔和產(chǎn)品原型輸出的時候，我也會一直強調(diào)一個理念：

文不如表，表不如圖，圖不如當(dāng)面溝通。

過往我接觸過很多產(chǎn)品經(jīng)理都非常喜歡寫文檔，無論是簡單的邏輯還復(fù)雜的邏輯，都是用文檔的形式去闡述，然后用各種序號，表格，分段落等方式去闡述一些概念和方案?？此茖懥撕芏鄸|西，但是讀起來就非常的拗口，例如說我經(jīng)常吐槽金蝶的說明文檔，他們就有這樣的問題，大段的文字說明，但是看完了并不知道他要表達(dá)什么意思。

“所有權(quán)歸屬方即貨主（組織結(jié)構(gòu)勾選業(yè)務(wù)組織即為貨主），存儲地即倉庫，倉庫所屬組織即“庫存組織”（組織機(jī)構(gòu)勾選業(yè)務(wù)組織，還得勾選“庫存組織”職能）。從組織機(jī)構(gòu)的設(shè)置來看，業(yè)務(wù)組織一定可以作為貨主，但不一定是庫存組織，但庫存組織一定是業(yè)務(wù)組織。這點是與K/3WISE的最大區(qū)別，K/3WISE沒有組織的概念，沒有貨主的概念，貨主與庫存組織是同一個?！?/p>

這段話就是摘自金蝶的官方社區(qū)，讀起來非常拗口，如果能畫兩個示意圖，我覺得這個概念可能一下子就能讓讀者明白了。

例如我需要表達(dá)一下OMS的入庫單和出庫單的一些操作會導(dǎo)致庫存如何變化，那么我就可以采用表格的形式去說明，這些庫存是怎么變化的。

如果說通過這個表格，還是有一些研發(fā)和測試人員不太懂，那么我可以通過圖的方式再跟他們說明一下，讓他們結(jié)合一個表和一個圖來進(jìn)行理解。

如果用表格和圖片還是不能讓大家理解其中的含義，那么這個時候就可以去當(dāng)面溝通了，直接拉會議或者走到對方的面前，然后對著表格和圖片去講解，講到大家懂了為止。

4. “用戶滿意度”才是核心的指標(biāo)，而不是“規(guī)范和標(biāo)準(zhǔn)”

在產(chǎn)品經(jīng)理群里時不時會看到一些提問，大概意思是就是“有沒有需求文檔模板可以參考學(xué)習(xí)的”，“有沒有原型模板借鑒”，“有沒有XXX模板或者規(guī)范可以抄作業(yè)的”。

無論是需求文檔，產(chǎn)品原型，還是需求評審，規(guī)范和標(biāo)準(zhǔn)只是用來提升效率，同時規(guī)避一些已知的風(fēng)險，并不意味著一定不符合“規(guī)范和標(biāo)準(zhǔn)”就不能做出好產(chǎn)品，或者說就會被定義為是“野路子產(chǎn)品經(jīng)理”。很多初中級的產(chǎn)品經(jīng)理在這個問題上都會糾結(jié)一段時間，尤其是之前的公司團(tuán)隊規(guī)模比較小，然后也沒有見過什么好的案例，就很容易有這種“自我懷疑”和“矯枉過正”的問題出現(xiàn)。

我曾經(jīng)也有過一段時間的糾結(jié)，也很擔(dān)心自己被定義為“野路子產(chǎn)品經(jīng)理”。但是作為一個過來人，回過頭來看的話，我希望大家能夠盡早地意識到：“用戶滿意度”才是核心的指標(biāo)，而不是“規(guī)范和標(biāo)準(zhǔn)”。

誰是你的用戶呢？如果是需求評審，那么在座的研發(fā)、測試、UI、甚至是你的產(chǎn)品同事都是你的用戶，你應(yīng)該在評審了之后去向他們獲取反饋，自己是評審講解的好還是不好，是否有什么值得改進(jìn)的。

如果是需求文檔或者原型，也是同樣的道理，去問使用你“產(chǎn)品”的人，去傾聽他們的反饋，而不是去“XX產(chǎn)品交流群”問廣大群友們。

二、要包含的核心要素

前面分析了需求評審中常見的一些問題，實際上除了這些問題之外還有很多具有代表性的問題，但是礙于篇幅和時間的關(guān)系我就不展開去講了，我直接分享一下我認(rèn)為的一個好的產(chǎn)品方案（需求文檔或者原型）應(yīng)該要包含哪些核心要素。

這里我是以B端產(chǎn)品的日常工作為參考的，所以有一些內(nèi)容不太適用于C端的產(chǎn)品或者其他領(lǐng)域的產(chǎn)品；除此之外，文中提到的是“核心要素”而不是“大而全的模板”，意味著這些是我認(rèn)為特別重要的內(nèi)容模塊，但是并不代表說我沒提到的就不重要，如果你需要“大而全的模板”，那么市面上有很多類似的文章可以參考學(xué)習(xí)。

1. 業(yè)務(wù)流程圖

B端產(chǎn)品往往會涉及到多個組織，多個部門，多個角色（用戶），多種場景和業(yè)務(wù)，所以當(dāng)接受到了某個需求之后，肯定是要先對業(yè)務(wù)進(jìn)行梳理和分析，然后要輸出對應(yīng)的業(yè)務(wù)流程圖。在講解產(chǎn)品方案的時候，先鋪墊需求的背景和價值，然后接下來大概就要講解相關(guān)的業(yè)務(wù)流程圖了，一般來說如果涉及到多部門、多系統(tǒng)等場景，建議使用泳道圖來表達(dá)。

業(yè)務(wù)流程圖重點是表達(dá)清楚相關(guān)的業(yè)務(wù)邏輯即可，其中有一些細(xì)節(jié)或者描述可能不太符合流程圖的規(guī)范也沒關(guān)系，重點是傳達(dá)清楚意思即可。

2. 系統(tǒng)流程圖

上面提到了“業(yè)務(wù)流程圖”，那么什么是“系統(tǒng)流程圖”呢？其實系統(tǒng)流程圖就是指多系統(tǒng)之間的流程交互，通俗意義上可以理解為在多個系統(tǒng)之間的單據(jù)/模塊的流程交互。

系統(tǒng)流程圖可以簡單地用單據(jù)來表示之間的流轉(zhuǎn)關(guān)系，也可以在單據(jù)的基礎(chǔ)上增加單據(jù)的狀態(tài)及其相關(guān)的詳細(xì)說明，讓這個圖更加豐富，能承載和表達(dá)更多的信息。

業(yè)務(wù)流程圖和系統(tǒng)流程圖在一些不太復(fù)雜的業(yè)務(wù)場景下，基本上可以合并為一個，我一般都稱之為“業(yè)務(wù)流程圖”多一些。

如果是更復(fù)雜一些的業(yè)務(wù)場景，需要業(yè)務(wù)設(shè)計和應(yīng)用設(shè)計解耦的時候，那么業(yè)務(wù)流程圖就要和系統(tǒng)流程圖拆分開。業(yè)務(wù)流程圖只是表達(dá)業(yè)務(wù)之間的關(guān)系，此時還不知道有什么系統(tǒng)，有什么模塊，所以就梳理的時候就不要帶入“技術(shù)思維”。完成了業(yè)務(wù)流程圖的設(shè)計之后，接下來就是應(yīng)用設(shè)計的內(nèi)容，那么就梳理的就是系統(tǒng)流程圖了，而系統(tǒng)流程圖就需要用到“技術(shù)思維”，需要考慮有什么系統(tǒng)，有什么模塊，有什么單據(jù)，甚至是有什么具體的單據(jù)狀態(tài)等，因為定義清楚了這些才知道具體的系統(tǒng)功能模塊有哪些，產(chǎn)品方案是怎么樣的……

3. ER圖（實體關(guān)系圖）

在完成了系統(tǒng)流程圖的梳理之后，作為產(chǎn)品經(jīng)理，也就是作為方案的設(shè)計者，我們知道該需求的滿足會涉及到多少系統(tǒng)，多少模塊，多少頁面等，但是為了讓研發(fā)和測試更好地了解其中的邏輯關(guān)系，我們需要輸出實體關(guān)系圖，也就是ER圖，來幫助他們完成相關(guān)的業(yè)務(wù)建模和數(shù)據(jù)庫表設(shè)計。

實體關(guān)系圖也被稱為 ERD、ER 圖、實體聯(lián)系模型、實體聯(lián)系模式圖或 ER 模型，是一種用于數(shù)據(jù)庫設(shè)計的結(jié)構(gòu)圖。一幅 ERD 包含不同的符號和連接符，用于顯示兩個重要的信息：系統(tǒng)范圍內(nèi)的主要實體以及這些實體之間的相互關(guān)系。當(dāng)我們談?wù)?ERD 中的實體時，我們經(jīng)常提到諸如人員/角色（例如學(xué)生），有形商業(yè)對象（例如產(chǎn)品），無形商業(yè)對象（例如日志）等業(yè)務(wù)對象?！瓣P(guān)系”則是這些實體在系統(tǒng)內(nèi)的相互關(guān)聯(lián)。

ER圖聽起來好像很專業(yè)，是一個很技術(shù)性質(zhì)的名詞，但是理解了其含義之后其實并沒有想象中的那么復(fù)雜，也沒有必要恐懼它而不去使用。產(chǎn)品經(jīng)理輸出ER圖的時候，只需要表達(dá)出2個核心點即可：

1. 實體有哪些？
2. 它們的關(guān)系是什么？

我們只需要通過輸出簡單的實體關(guān)系圖就能讓開發(fā)明白不同單據(jù)之間的關(guān)系是什么，是怎么流轉(zhuǎn)的，如下圖所示。

采購業(yè)務(wù)中的實體關(guān)系圖

上面的實體關(guān)系圖雖然簡單，但是清晰易懂，不需要過多的文字描述就可以讓閱讀者Get以下這些信息：

1. 采購流程中一共有4個核心的單據(jù)（有一些內(nèi)容省略了，實際可能會更多）；
2. 可以多個采購計劃單匯總生成一個采購單；
3. 一個采購單可以生成對個收貨單；
4. 一個收貨單可以生成多個上架單，例如多批次收貨或者是正次品上架單區(qū)分；

4. 狀態(tài)機(jī)說明（狀態(tài)流轉(zhuǎn)圖）

完成了ER圖的輸出之后，我們會發(fā)現(xiàn)一條業(yè)務(wù)會串聯(lián)多個單據(jù)，例如采購計劃單，采購單，收貨單，上架單等，這些單據(jù)一般來說都是“執(zhí)行類+結(jié)果類”的綜合單據(jù)，也就是意味著這些單據(jù)一般來說會有多個狀態(tài)。

例如說采購計劃單可能會有以下幾個狀態(tài)：

1. 待審批
2. 待采購
3. 已完成
4. 已駁回
5. 已作廢

而采購單可能又有另外的狀態(tài)，例如：

1. 待提交
2. 待審批
3. 待下單
4. 待到貨
5. 已完成
6. 已作廢

產(chǎn)品的方案中必然要對這些狀態(tài)進(jìn)行說明和定義，所以就需要輸出對應(yīng)的狀態(tài)機(jī)說明，我一般稱之為“狀態(tài)流轉(zhuǎn)圖”，具體如下。

海外倉OMS的入庫單狀態(tài)流轉(zhuǎn)圖

如果是涉及到一些單據(jù)有比較緊密的聯(lián)系時，可以采用“多單據(jù)狀態(tài)流轉(zhuǎn)圖”的方式，也就是結(jié)合版，如下所示。

盤點單和盤點任務(wù)單的狀態(tài)流轉(zhuǎn)圖

5. 不同狀態(tài)下的操作說明（列表展示）

完成了狀態(tài)流轉(zhuǎn)圖的梳理之后，我們知道了某個單據(jù)有多少狀態(tài)，狀態(tài)的流轉(zhuǎn)條件是什么，甚至也可以知道多單據(jù)之間狀態(tài)的流轉(zhuǎn)關(guān)系，接下來要做的就是整理不同狀態(tài)的對應(yīng)的操作說明，一般來說會用列表的方式來展示。

海運頭程計劃單的狀態(tài)說明

海運頭程計劃單的狀態(tài)說明

6. 核心業(yè)務(wù)邏輯說明（數(shù)據(jù)推演，邏輯計算，條件判斷）

前面的幾個核心要素基本上都是圖或者表，而且是按從大到小的結(jié)構(gòu)化思路去輸出和講解的，但是一個具體的產(chǎn)品方案中肯定是少不了核心的業(yè)務(wù)邏輯說明，還有一些相關(guān)的條件判斷等。關(guān)于這一塊的內(nèi)容每個產(chǎn)品經(jīng)理都有自己的輸出和表達(dá)風(fēng)格，不用刻意去追求所謂的“標(biāo)準(zhǔn)和規(guī)范”，只需要能表達(dá)清楚，同時效率也不會受到影響即可。

例如我就很喜歡用畫圖、畫表的形式來表達(dá)其中的業(yè)務(wù)邏輯，然后將這一塊的內(nèi)容貼在文檔或者原型即可。

操作費的業(yè)務(wù)公式分析

WMS不同維度的庫存查詢邏輯說明

上面也提到過一個口訣“文不如表，表不如圖，圖不如當(dāng)面溝通”，所以切記不要長篇大論地去用文字表達(dá)相關(guān)的邏輯，看起來動輒幾萬字的PRD實在是讓人看的頭痛，而且自己輸出的效率也不會很高。

上面分別講解了6個我個人認(rèn)為B端產(chǎn)品方案中很核心的要素，幾乎可以理解為是“必做項”，但是實際的產(chǎn)品工作中需求的多元化的，解決方案也是多元化的，所以可能最后要輸出的內(nèi)容遠(yuǎn)不止于這6個要素，可能會更多，也可能會更少。

讀者朋友們需要自己去甄別，以“用戶滿意度”為核心指標(biāo)，去審視自己輸出的產(chǎn)品方案還有哪些遺漏的點，還有哪些可以改進(jìn)的點，而不是盲目地抄模板。

三、怎么講解好自己的需求？

最前面開篇的時候講到，在組織私享課的需求評審的時候，我發(fā)現(xiàn)有一些學(xué)員朋友可能方案很詳細(xì)，但是卻講解的不好，其中最大的問題就是“缺少結(jié)構(gòu)化”，也可以理解為“缺少清晰的脈絡(luò)”。

其實上面提到的6個核心要素，既是我們輸出產(chǎn)品需求方案的順序，也是我們講解產(chǎn)品需求方案的順序，它遵循的是“從大到小，從宏觀到微觀”的邏輯。

在講解產(chǎn)品需求方案的時候，我們會先鋪墊業(yè)務(wù)背景，告訴在座的各位為什么要做這個需求，它解決了誰的問題，帶來了什么價值，誰會使用它，會涉及到哪些部門，哪些業(yè)務(wù)流程等。這些既是產(chǎn)品的需求背景，也是業(yè)務(wù)流程圖的一部分，通過講解業(yè)務(wù)流程圖讓大家先從宏觀層面了解該需求的背景。

對于大多數(shù)的產(chǎn)研團(tuán)隊來說，他們不太關(guān)注這些“上價值”的東西，而是更加關(guān)注自己的“體感”，也就是：我是什么崗位？有哪些是我的活？我做的模塊要怎么搞？

所以第二個部分我們就可以開始講系統(tǒng)流程圖了，告訴大家涉及到了哪些系統(tǒng)，哪些模塊，哪些功能，和誰有關(guān)系，誰需要干活等。系統(tǒng)流程圖的講解可以結(jié)合業(yè)務(wù)流程圖來講，也可以結(jié)合ER圖來講，但是我個人會建議還是先鋪墊業(yè)務(wù)的部分，然后再去講解系統(tǒng)的部分會更好。

講完了前面的三塊內(nèi)容之后，接下來的狀態(tài)流轉(zhuǎn)圖，狀態(tài)說明列表，核心業(yè)務(wù)邏輯等就可以按具體的業(yè)務(wù)線和具體的模塊劃分去講解了，只需要遵循從大到小的邏輯即可。

例如WMS的入庫業(yè)務(wù)，前面鋪墊完了業(yè)務(wù)背景，業(yè)務(wù)流程，系統(tǒng)流程，ER圖等之后，接下來就可以分別去講解預(yù)到貨通知單，質(zhì)檢單，上架單的狀態(tài)流轉(zhuǎn)圖，各個狀態(tài)的說明，各個單據(jù)下的核心業(yè)務(wù)邏輯等。如果是一些比較復(fù)雜的需求，產(chǎn)品方案的內(nèi)容也比較多的情況，最后還是需要把各個模塊的內(nèi)容再串一下，做到首尾呼應(yīng)，讓大家能更好地理解和消化這一大塊的內(nèi)容。