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

寫作背景

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

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

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

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

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

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

1. 產品方案既是看的，也是講的

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

有一些產品的需求文檔和原型都非常詳實，甚至也會有一些產品經理認為需求文檔的字數越多越好，感覺文檔沒寫到幾千幾萬字就總是會漏掉什么一樣。

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

無論是第一種，還是第二種，我都見過，而且我感覺都有很多的優化空間，基于我了解的大多數的公司的研發機制和流程規范，我都會建議：

產品方案既是看的，也是講的。也就是說，不要寫得太多，因為有一些內容你是可以通過講解去表達的；也不要寫得太少，因為有些時候錯過了當面評審的會議或者是時間一長，就容易遺忘一些細節內容。

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

2. 結構化的表達是需要持續提升的能力

在產品需求評審會議上，很多產品經理可能都會遇到一個尷尬的場景：評審到后面的時候大家幾乎沒認真聽了，玩手機的玩手機，看電腦的看電腦，甚至有一些人都在打瞌睡了。

拋開一些外界因素（團隊制度規范、個人素質和專業性、團隊凝聚力等），我發現評審效果不太好的很核心的一個原因是：

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

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

如果此時產品經理在評審自己的方案的時候，沒有一些結構化，脈絡化，畫面感的東西，那么必然就會導致聽眾沒有聽懂，也跟不上節奏，然后就演變成了走神、發呆、各玩各的東西了……

產品經理的結構化表達能力是需要持續鍛煉的，怎么把自己熟悉的一個事情向新人講清楚，講明白，還要把自己的觀點和方案傳達清楚，這不是一件容易的事情，需要我們提前準備足夠的資料，也需要我們有適當的練習，持續地去迭代和完善。

3. 文不如表，表不如圖，圖不如當面溝通

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

文不如表，表不如圖，圖不如當面溝通。

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

“所有權歸屬方即貨主（組織結構勾選業務組織即為貨主），存儲地即倉庫，倉庫所屬組織即“庫存組織”（組織機構勾選業務組織，還得勾選“庫存組織”職能）。從組織機構的設置來看，業務組織一定可以作為貨主，但不一定是庫存組織，但庫存組織一定是業務組織。這點是與K/3WISE的最大區別，K/3WISE沒有組織的概念，沒有貨主的概念，貨主與庫存組織是同一個?！?/p>

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

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

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

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

4. “用戶滿意度”才是核心的指標，而不是“規范和標準”

在產品經理群里時不時會看到一些提問，大概意思是就是“有沒有需求文檔模板可以參考學習的”，“有沒有原型模板借鑒”，“有沒有XXX模板或者規范可以抄作業的”。

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

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

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

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

二、要包含的核心要素

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

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

1. 業務流程圖

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

業務流程圖重點是表達清楚相關的業務邏輯即可，其中有一些細節或者描述可能不太符合流程圖的規范也沒關系，重點是傳達清楚意思即可。

2. 系統流程圖

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

系統流程圖可以簡單地用單據來表示之間的流轉關系，也可以在單據的基礎上增加單據的狀態及其相關的詳細說明，讓這個圖更加豐富，能承載和表達更多的信息。

業務流程圖和系統流程圖在一些不太復雜的業務場景下，基本上可以合并為一個，我一般都稱之為“業務流程圖”多一些。

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

3. ER圖（實體關系圖）

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

實體關系圖也被稱為 ERD、ER 圖、實體聯系模型、實體聯系模式圖或 ER 模型，是一種用于數據庫設計的結構圖。一幅 ERD 包含不同的符號和連接符，用于顯示兩個重要的信息：系統范圍內的主要實體以及這些實體之間的相互關系。當我們談論 ERD 中的實體時，我們經常提到諸如人員/角色（例如學生），有形商業對象（例如產品），無形商業對象（例如日志）等業務對象?！瓣P系”則是這些實體在系統內的相互關聯。

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

1. 實體有哪些？
2. 它們的關系是什么？

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

采購業務中的實體關系圖

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

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

4. 狀態機說明（狀態流轉圖）

完成了ER圖的輸出之后，我們會發現一條業務會串聯多個單據，例如采購計劃單，采購單，收貨單，上架單等，這些單據一般來說都是“執行類+結果類”的綜合單據，也就是意味著這些單據一般來說會有多個狀態。

例如說采購計劃單可能會有以下幾個狀態：

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

而采購單可能又有另外的狀態，例如：

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

產品的方案中必然要對這些狀態進行說明和定義，所以就需要輸出對應的狀態機說明，我一般稱之為“狀態流轉圖”，具體如下。

海外倉OMS的入庫單狀態流轉圖

如果是涉及到一些單據有比較緊密的聯系時，可以采用“多單據狀態流轉圖”的方式，也就是結合版，如下所示。

盤點單和盤點任務單的狀態流轉圖

5. 不同狀態下的操作說明（列表展示）

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

海運頭程計劃單的狀態說明

海運頭程計劃單的狀態說明

6. 核心業務邏輯說明（數據推演，邏輯計算，條件判斷）

前面的幾個核心要素基本上都是圖或者表，而且是按從大到小的結構化思路去輸出和講解的，但是一個具體的產品方案中肯定是少不了核心的業務邏輯說明，還有一些相關的條件判斷等。關于這一塊的內容每個產品經理都有自己的輸出和表達風格，不用刻意去追求所謂的“標準和規范”，只需要能表達清楚，同時效率也不會受到影響即可。

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

操作費的業務公式分析

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

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

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

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

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

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

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

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

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

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

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

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