產品經理在日常工作中，不可避免地要接觸產品需求文檔這類產出物。那么，產品需求文檔要怎么寫，才是一份合格的需求文檔呢？這篇文章里，作者梳理了核心思路，并從五個方面進行了講解，一起來看。

產品需求文檔（Product requirements document 簡稱PRD）是產品經理在工作中最重要的產出物，是承上啟下的核心文檔。

圖：

• 承上：業務需求。
• 啟下：研發、測試、UXD的工作依據。

因此，PRD文檔是產品經理職業生涯中必須要掌握的技能。

我會從以下幾個方面講解，到底怎么才能寫好PRD文檔。

1. 目的
2. 形式
3. 技巧
4. 態度
5. 環境

一、目的

寫PRD最重要的目的是：把需求講清楚，但一份優質的需求文檔一定是合適的方案+表達清晰。

合適的方案是指：我能分析清楚業務的現狀是什么，期望是什么，要解決什么問題，用什么方案解決。

表達清晰是指：我能把我希望用的解決方案表達清楚，傳遞清晰。

如何分析需求并找到合適的方案，我會在另外的文章中來講解，本文的重點會著重放在表達清晰上，但在我多年的實際文檔經驗中，往往合適的方案和表達清晰是一個交替生成的，當你盡可能想表達清晰時也能促使你獲得更加合適的方案，所以表達清晰不僅僅是應該，而是必要。

如果把需求講清楚是總綱，它還能分為三個小目標：

文檔受眾能精準理解文檔并轉化為他們的產出物：

• 研發人員 ====> 代碼
• 測試人員 ====> 測試用例
• 交互設計人員 (User experience design，簡稱UXD) ====> 交互圖

多個角色間的無歧義標準：涉及研發、測試、UXD以及跨域的產品等角色時，需求文檔應作為在發生分歧時的唯一標準，幫助多個人之間消除歧義而不是引發新的歧義。

可追溯性文件：

• 上線一段時間后的線上BUG，用來判斷是產品設計缺陷 OR 是代碼問題。
• 后續迭代需求的基石：能夠讓新人快速理解現狀并輸出需求，同時能夠幫助新人查漏補缺（往往新人會漏考慮一些細節，當文檔足夠完善時能起到提醒的作用）。

二、形式

一般來講，需求文檔總是圖表和文字的形式出現，幾乎沒有人會使用視頻和音頻，需求文檔一般會伴隨著需求評審，以便能夠進一步解釋說明和對文檔查漏補缺。

三、技巧-結構

技巧分為結構和表達，本篇文章會著重介紹結構部分，表達不分：圖表的介紹和使用以及其他文字性技巧、習慣會在后續的文章中體現。

從宏觀到微觀的描述順序，能夠讓文檔受眾在獲取到背景信息的前提下理解文檔的內容。比如當你看到Chair is blue時會認為它是什么含義？

• 椅子是藍色的？
• 主席是憂郁的？

想要正確的理解這個句子，需要是加一些背景，比如在一個辦公室里，他得知公司將要破產，這樣我們才能順利成章的理解他作為主席，聽到這個消息非常沮喪。

因此，我會推薦將整個需求文檔都變為總分的結構，這會更加的便于文檔受眾的理解，也恰好符合金字塔原理。

金字塔原理是一種重點突出、邏輯清晰、層次分明,簡單易懂的思考方式、溝通方式、規范動作。

金字塔原理的基本結構是:結論先行,以上統下,歸類分組,邏輯遞進。

先重要后次要,先總結后具體,先框架后細節,先結論后原因,先結果后過程,先論點論據。

針對整個文檔，我會將他們分為兩大部分：為什么要做 和 要做什么。

1. 為什么要做？

此部分著重交待清楚背景、問題、價值、目的。

背景：用來描述此需求發生的業務背景，比如業務將要開拓一個新的市場，這個市場上大家普遍都會以貨到付款作為交易的方式。一番描述之后會讓對這個需求不熟悉的人更快的進入到這個需求的情境中。

問題：用來描述業務的預期與現在現狀的落差，這個落差是問題也是需求。如果能正確的描述歸納和描述問題，就能更快找到問題所對應的“答案”。

價值：做這個需求有什么價值？我發現大多數產品經理，尤其是新手，往往會忽略價值的思考和表達。認為這可能是上一級或者業務應該思考的事情。我在產品經理的任何階段都建議大家去思考價值，價值背后所隱藏的信息有：

• 這個需求該不該做？（同時綜合方案的成本）
• 這個需求什么時候做？（也就是優先級的問題）

描述價值的同時，一方面是對自己工作的肯定，我在做有意義的事情，另一方面也是在說服文檔受眾，告訴他們：為什么你的需求非做不可。

深入思考價值也你后續在跟業務溝通時判斷是否為偽需求打好基礎，沒有價值的事情堅決不浪費時間做。

在盈利性組織中，價值只來源于兩個方面：盈利和成本。

1. 營收：做了這個功能可以帶來多少營收，能增長多少客戶等
2. 成本：做了這個功能可以提高多少效率（提高效率往往意味著精簡人力），可以節省多少成本等。

目的：此處的目的更多的是從系統建設的角度給出一些比較精簡的目標，比如需要在XX模塊兼容貨到付款的業務。

2. 要做什么

此部分著重講方案的主體。

整體設計：也稱為概要設計，主要的目的有2個：

1. 讓文檔閱讀者有整體的概念，能夠讓他站在更加宏觀的視角理解方案。
2. 為后續理解具體的功能用例提供鋪墊。

需求詳情：在這個大模塊里需要對需求要實現的功能/特性做詳細的邏輯說明，一般寫需求時先要對功能（也叫用例）進行拆分，拆分完在針對不同的功能點做詳細補充。

功能拆分：拆分完需求一般可以輸出一份功能地圖（Roadmap），需求拆分核心需要遵守MECE原則，即不重不漏。

• 不重：功能點之間不重復，同樣的功能寫一遍即可。寫一遍能省時間，以及方便后期維護（若寫多遍改的時候要改多個地方，所以要盡量抽象到一個里面。）
• 不漏：一個完成的需求需要不同模塊間的協作，漏了以后可能會導致卡流程。

功能描述：需要對邏輯做最詳盡的說明，根據團隊協作的習慣盡量細化，需細化到是或否應該走哪個分支流程，甚至細化到要用什么表的什么字段。

四、環境

良好的環境能夠幫助產品經理在文檔能力上快速成長，此處羅列一些我認為較重要的因素：

文檔規范：良好的規范有助于產品快速融入團隊整體的表述方式，同時也能夠幫助一些產品些人快速成長，我曾經待過一個團隊，全部都是在需求卡片中寫一句話的需求，既沒有沉淀也沒有規范，導致需求上線后沒有人知道會有這樣一條邏輯。

需求模板：產品團隊一般都會有需求模板，但是模板也只能約束整體格式，具體的寫作風格還是會因人而異。

管理方式：文檔的管理方式大致有三種。

1. 增量式文檔：每次需求都是一個全新的文檔，優勢是前期迭代快，對文檔管理的要求較低，后期維護麻煩，很難溯源。
2. 白皮書式文檔：按模塊劃分，優勢是后期維護較簡單，容易溯源，所見即所得，可以有效縮短產品對現有邏輯的調研時間，但對于跨模塊的需求，閱讀者讀起來較麻煩，文檔分散（需要一些書寫技巧規整以方便閱讀）。
3. 綜合性文檔：增量的內容定期維護到白皮書中，這種管理方式看似能實現前兩者的優勢但需要消耗大量的產品時間去做維護的事情，在實際的工作中很難實現。

研發測試的嚴格要求：同事的高標準、嚴要求，評審會上的“挑戰”都會促使你精進文檔能力，將需求描述的更加簡練清晰，無歧義。

能有機會做大項目：只有較大的項目才會涉及到多個模塊、多個系統，這會有效提升整體設計的能力，全局設計的能力。

有人帶：團隊中有人帶可遇不可求，一方面能手把手讓你快速上手現有業務，一方面可以階梯式的給你分配項目，并不是項目越大越好，循序漸進的增加項目難度會更適合新手。

五、態度

沒有人可以叫醒一個裝睡的人，不管在什么樣的環境中，我們都不要成為那個“裝睡的人”。

精益求精：

• 主動尋找更好的寫文檔的技巧。
• 不因項目/需求大小而放低文檔的質量，沒有小需求，再小的功能也能體現你的價值。

為他人著想：你寫的明白，別人看的清楚，需求文檔就是建立信任最基本的產出物。

保持高標準：認認真真寫一個文檔簡單，認認真真寫每個文檔就很難，但某天當你回首以望時，你早已從小草長成參天大樹。