PRD 應該追求簡潔易懂，還是精準細化？

01-21

AXURE原型上直接進行PRD內容的文字描述，把原型和PRD直接進行結合，大家感覺這樣的方式來編寫PRD怎麼樣？

當然是後者，PRD是必須具體、精準、細化的。當然裡面可以有簡報，原型圖、流程圖、業務規則等等簡潔易懂的環節。

最近新的公司剛好遇到了產品需求文檔方面的一些問題，因此我也跳出來說說產品需求或PRD文檔規範啥的。

現在很多產品團隊對於PRD文檔的規範有較大分歧，其實文檔本身，只是一個團隊溝通的一個中間工作產品，目的是將產品的實現思路傳達到每個人（重要的如設計、前後端開發、測試，以及運營、商務等部門，甚至是老闆），它一方面和團隊內部溝通機制有莫大的關係，另一方面和產品類別相關，總所周知產品一般分為互聯網產品和政企信息系統產品，從應用領域分又分為移動應用產品和web端產品，政企信息系統產品更模塊化功能化，產品規模都較大，因產品所處行業的關係前期需求比較容易控制，手機端和web端產品功能相似度較高，因此兩者在前期做產品需求基本一樣，為了便於團隊之間溝通，通常藉助於規範化的prd文檔描述各個功能模塊之間的關係、業務流程、信息欄位及非功能性需求，這樣的PRD文檔規格在網上搜索大把，無太大爭議。

而互聯網產品的設計原則是大道至簡，並初期擔負著試探市場及用戶的重任，產品快速的迭代發布讓PRD的規範有更大的靈活度，當我們開展一款新的產品（PRD的工作主要集中在新產品的開發階段），應該以簡為主，當前互聯網如此激烈的市場環境下，很多產品甚至只是主打一個核心功能，因此PRD文檔也有相對應的簡化，比如我們做手機app，我們一般會將UI控制在十個以內，甚至五個，界面布局、交互流程及信息欄位基本可以通過原型圖表達清楚，所以這時候原型圖即是PRD，如果原型圖也無法表達清除應該好好思考團隊之間的協作問題溝通機制了。而對於互聯網的web產品，PRD任然有其必要，考慮到web頁面較大信息量和複雜的交互，我們仍然需要藉助原型以外的流程圖和Excel、Word將更多更複雜的信息表達清楚（一般來說原型圖、流程圖和信息欄位三件東西足矣），這裡可以根據團隊默契程度自行考慮，比如曾經我公司一個產品團隊嘗試過前期只是用過web原型圖即實現了產品的快速敏捷開發和迭代。

前面提到比較多根據團隊自身情況調整PRD的規範問題，其實所謂自身情況即是團隊架構和溝通機制，部分公司是弱矩陣型（根據角色職能劃分部門，根據產品項目配置人員，人員調動可能性較大，如騰訊），可能會受制於不同部門的文化，影響溝通，PRD需要盡量詳細以避免理解衝突；部分公司產品團隊型，比如我公司以前的產品團隊結構，人員默契度較高，溝通頻繁，這時候可以簡化RD不必要的環節。

說到最後，還不得不提一下，有些童鞋仍然搞不清楚MRD（也有人稱之為brd）和PRD的關係，建議做產品前好好研究一下，兩者在產品需求環節都需要且必不可少，前者解釋為什麼做產品（行業市場、競爭環境）、怎麼做產品（功能框架）、怎麼賣（推廣運營）、怎麼賺錢（商務模式）及怎麼規劃，詳細的文檔結構也可以網上找到，這份文檔是產品的根本（個人認為重要程度比PRD高），而PRD重點在於解釋怎麼做產品（功能及分功能的需求），表現形式有很多種，比如原型、流程也可以是任何其他的形式。

要把產品意圖表達得儘可能的精細準確，但要給開發和設計師留出實現方案的發揮空間。

除非你比開發更懂開發，比設計更懂設計……那為什麼還要做產品經理？可以去做喬布斯嘛。

PRD也是產品，問你的用戶感受，看你能承擔的成本。

看具體的產品和具體功能開發人員的風格不管如何有些環節和功能需要在prd里很完善哪怕只是備忘用

說句實話，你們看過兩年前人家寫的PRD嘛？你還會去看自己兩年前寫的PRD嗎？其實很多工作都是覺得別人做了我們也要做blablabla，根據實際情況是不是寫，寫到多清楚，不管怎樣，最後估計還是沒多少人看。（這裡情況也很詭異，如甲乙方需要文檔交付等，都是流程，沒有很實際的意義）

方式並不重要，重要的還是結果，產品、研發和測試有么有達成共識，有么有按照既定的需求進行成果的呈現

技術都特別討厭寫文檔和看文檔（至少我遇到的很多是這樣），所以，寫PRD之前，必須和目標群體進行充分溝通，找出雙方最合適的表達方式。

prd整體應簡潔易懂，能夠讓開發和設計以及測試等相關項目工作人員清楚快速的了解產品，細化到具體功能模塊就需要具體、精準、細化，將功能模塊，業務流程，產品邏輯，異常事件等詳細，精準的表述出來，確保開發，測試，設計能夠順利推進

有多少技術真的會認真看PRD？答是請回復1

無法回答，prd就和其所包含的產品一樣，脫離了對象、環境，

無論簡潔易懂還是精準細化，都無從談起。

先做一個簡潔易懂的，針對細化的部分進行標註，在附件文檔中進行精準細化。

PRD（Product-Requirement-Document，產品需求文檔），這對於任何一個產品經理來說都不會陌生的一個文檔，在網上搜索也很容易找到關於PRD的乾貨，但會寫還是不夠，很多產品新人都問我為什麼我的文檔開發哥都不看？怎樣才能寫好PRD呢？

Ruby語言的創始者松本行弘說過：「代碼越少，有可能出現bug的機會也越少。」文檔也是一樣，越是簡短，可能出現的錯誤也會越少，同時也更利於閱讀、維護和更新，所以建議大家的PRD要寫成「簡單易懂」。

產品需求文檔作為一種和開發人員溝通的重要工具，如果梳理得不好，會直接影響後續與開發人員的溝通質量，「簡單易懂」顯得十分重要。但很多剛做產品的同學不太了解其重要性，會走不少彎路，他們會發現：在開完需求會議後開發人員在開發的過程中很少去翻看需求文檔，通常情況下都是口頭詢問，同學們就覺得很奇怪，他們寫文檔寫得那麼詳細，為什麼開發人員就不看文檔呢？既然不看，就不用寫了，直接用口頭溝通不是更好嗎？其實，能用口頭闡述都小問題和小項目，如果是中、大型項目，參與人員比較多，文檔是有助於減低溝通成本和提高共走效率；還有一點，很多時候開發不看文檔，是嫌棄文檔的內容太長了，他們只需要簡單了解這個功能大概是做什麼的，怎樣去實現就可以了。反觀很多同學在寫的時候會進入一個誤區，事無巨細地描述規則，總害怕開發同事看不懂，一個比較複雜的功能可能寫個300字，結果人家直接不看了。

怎樣才能寫出簡單易懂的需求文檔呢？

1、分析核心需求

明確開發需求實現哪些功能需求，PRD很多時候只是對原型上沒有的說明進行補充，你總不能輸入框限制多少個字元都寫在原型上面，所以第一步需要看一下哪些是說明並沒有在原型上面提現，然後在PRD上面進行補充。例如，原型上面更多的是交互說明與規則說明，但對欄位的控制一般都很少去解釋，還有時候原型上很難包含所有情況頁面，所以PRD也有時候需要補充一下。

2、先填寫軀幹

為保持簡短性，需求描述主要寫成，提取關鍵詞，關鍵詞字數不要超過6個字，這樣可以讓開發哥最快的速度以內了解功能點；最好使用約定俗成的語言，因為產品與開發部在有些點上面的描述和說法是不一樣的，如果使用大家能馬上看得懂的言語就能提高效率，這個需要平時的積累和溝通的沉澱，最好每次項目結束總結範例，那下次開展項目可以更快更速度。

3、再增加枝葉

寫完關鍵詞後，圍繞關鍵詞展示具體內容，把需要顯示的具體內容放入了解釋中，因為這些內容並不會影響開發，如果放在需求描述中，反而會降低閱讀的速度和增加理解上的負擔。

就前三點舉個例子：我曾經做過一個功能消息待閱讀，一級軀幹為欠費提醒、賬單提醒、生日提醒，二級枝葉為欠費提醒中對象、內容、時間等元素，最後對元素進行描述。

4、備註說明

在備註的加入需求來源、需求提出時間、需求提出人，避免出現產品開發完成後，由於開發周期太長，很多需求來源都淡忘了，無法得知為什麼當初有這樣的功能和需求，為什麼增加這個欄位，如果遇到項目需求確認人或者開發人員離開了，同時文檔中沒有留下任何確認過的需求來源記錄，在產品上線驗收的時候，需求出現了問題，那麻煩就大了，其實文檔也是保護雙方的一種手段。

5、時刻維護

文檔還需要保持時刻更新，因為在產品開發階段，會遇到零零散散的提升用戶體現或者修改功能需求，如果是到了最後上線期間才去補很容易產生遺漏，這裡也推薦避免3個遺漏的方法：

1、一定要及時把變更的需求寫入需求文檔中，不要拖到下次在寫

2、用高亮的顏色標記出變更的細節，如需要顯示的欄位內容

3、對於做了刪改的需求要標明原因以及時間

4、如果中途修改次數過多，建議專門做個文檔來記錄變動情況

6、項目總結

每經過一次項目，總結是必不可少的，在PRD方面也需要總結，在總結大會上需要收集開發對此項目PRD的意見和修改方向，如何才能更清晰簡單地闡述我們的觀點，「簡單易懂」不單單是產品部為這個目標奮鬥，開發的同事也應該參與其中，這個在下一個項目開發中才能取得更大的進步。

如果需要與我討論和合作的話，可以掃一掃下面的二維碼。

1、以溝通為目的，文字和圖要盡量消除歧義；

2、適當精細化，確保需求的準確傳達；

3、對於靈活處理部分留有餘地，可標明。

我覺得關鍵還是看給誰看。簡單版本的給拍板的人看，詳細細節版的給執行的人看。

首先是要讓人看懂，有些環節還需要細化

最近也開始糾結這個問題。

看你做給誰吧。做給技術，那就需求可視化，能畫圖的千萬不要文字。大家都想簡單明了你到底想做什麼。

至於精細準確，那是最後面了，剛開始盡量完整完善即可。

看該PRD的目標人群是誰了。

結構完整，表述極簡。

PRD需要懂得看的人，其風格因人而異。產品經理也需要知音。

可考慮採用用例的方式進行編寫，每一步只寫出目的，規則需要詳細說明。具體的用例編寫可以參考：《編寫有效用例》這本書

針對於標題的回答：

簡潔易懂與精準細化不矛盾，當然這裡的簡潔不是說整個PRD的簡潔，而是在對需求或功能的描述上，讓閱讀者用最小的代價看明白是根本。

針對於問題描述的回答：

用axure做PRD沒問題，重點不在於工具，而在於內容。

精準細化

當然需要prd和產品原型對照看的話，會看的更清晰。