作為產品經理，編寫產品需求文檔是基本技能之一，本文詳細介紹了如何編寫產品需求文檔（PRD），希望對你編寫有效的PRD有所幫助。

PRD是Product Requirement Document的簡稱，翻譯為：產品需求文檔。該文檔是產品由“概念化”階段進入到“圖紙化”階段的最重要的一個文檔。編寫PRD是一個產品經理最為基礎的工作內容，也是一個產品經理最基礎的能力。不夸張的說，通過一篇PRD文檔就可以體現出一個產品經理的基本功是否扎實，這直接影響到整個研發團隊的效率。

我常年從事To B系統產品的工作，因此本文的內容也僅針對To B系統的PRD文檔，并不完全適用To C的系統產品。想寫出一篇優秀的PRD文檔，需要搞清楚如下4個問題：

1. PRD文檔的編寫目的是什么？
2. PRD文檔在編寫前需要做什么？
3. PRD文檔在編寫的過程中有哪些是需要注意的？
4. PRD文檔編寫完成后如何使用？

一、PRD文檔的編寫目的是什么

編寫PRD文檔最為重要的目的就是：協調各個相關角色，將產品高效正確的“生產”出來。PRD僅僅是為達到這個目標，產品經理經常使用的一種工具，只要是能夠高效的完成最后的系統化產品，那么PRD具體的內容、形式也沒有非常嚴格的標準。從這個目標出發，我們能夠看到這樣幾個關鍵詞：各個角色、高效&正確和生產

1.1 各個角色

這里的角色是涉及到整個產品研發過程中全部相關的角色，每個角色在這個過程中負責的工作和關注點有所不同，PRD中需要照顧到所有參與角色的關注點，To B系統產品在此過程中主要涉及到的角色如下：

• 領導（產品總監等）：這個角色的人一般不會太過關注PRD的細節，重點會看一下，做這項工作的原因、解決問題的影響范圍、成本、以及最終給客戶和公司內部提供的價值。當然，這些內容如果在PRD之前就使用其他的文檔說清楚了，PRD文檔中就不需要寫了，我也建議在PRD編寫之前，通過產品提案等方式，把這些內容全部確定好，達成一致。
• UI&UX設計師：這個角色的人一般會重點關注在一些頁面的元素上，設計師會根據頁面的元素進行視覺和交互設計，所以，PRD中已經要寫清楚頁面的元素以及這些元素的含義，并且說明最終用戶在頁面上大大致操作過程。
• 前后端研發工程師：前后端工程師關注的側重點稍微有點不同，后端工程師側重具體邏輯細節，前端工程師更關注在設計師給出的設計稿、交互說明和一部分少量的前端邏輯。所以，PRD中一定要把具體邏輯寫清楚，最好把設計師的設計稿和設計說明一并匯入PRD中。
• 測試工程師：這個角色的人除了關注前后端邏輯、交互外，還關注系統最后希望達到的標準，以及最終的和興使用場景。所以，盡可能的寫一下最核心的幾個使用方式，相當于最重要的幾個測試用例。
• 產品運營：這個角色的人會關注最終產生的價值以及具體的使用方式，產品運營作為產品的客戶之間的重要橋梁。所以，最好可以寫一下系統使用說明。

1.2 高效&正確

寫出來文檔永遠比無效的溝通更高效，工作的事件越長，對此越是認可，對于很多問題，特別是復雜問題，前午安不要覺得說一下大家就明白了，前因后果、如何做大家都清楚了，相信我一定不是這樣的。

PRD就是提高效率的，把各個角色的共識全部寫出來，大家都已PRD為最終的工作指導文檔，在墻漆可以討論修改，在后期可以追根溯源，多花點時間在PRD上一定會比不斷地回答問題，不斷地因為沒有大臣一致的邏輯反復修改要高效的多。

1.3 生產

本質上，軟件開發也是生產的過程，和生產實物是沒有本質區別的。PRD作為指導生產過程的重要文檔，類似實物生產的設計文檔，必須要滿足在生產過程中各種各樣問題的回答。因此需要從生產流程的角度進一步的來說審視PRD的內容，包括：現狀、準備工作、前提條件、開發邏輯、效果要求等。

二、PRD文檔在編寫前需要做什么？

在上一小節中建議在PRD編寫之前，通過產品提案等方式把價值、成本等內容全部確定好，達成一致。實際上在PRD文檔編寫之前還遠不止這些內容。

PRD開始編寫，意味著整個業務調研、方案邏輯、可行性、價值判斷基本上已經完成了，如果沒有完成那么是不建議直接編寫PRD文檔的，因為就算寫完了也很有可能改來改去或不做了，這不僅僅影響工作的效率，還會大大打擊個人和團隊的積極性。

• 業務調研：只有完全搞清楚業務的問題，才可以解決問題，在PRD編寫前一定要進行業務調研，根據需求的復雜程度編寫詳細或簡要的需求調研文檔，明確需要解決的具體問題和要達到的具體目標。
• 方案邏輯：雖然PRD就是最后方案的詳細說明文檔，但是，在方案設計的初期，一定是有不同的方案來解決問題的，這些不同的方案需要進行一些維度的比對，最終選擇合適的方案，因此，在PRD編寫前，需要寫一個設計思路文檔。
• 可行性：圍繞設計思路中的不同方案，要對技術可行性進行論證，這需要與具體的開發負責人進行溝通，明確方案是否可行，以及成本，最后決定最終的方案。
• 價值判斷：如果說一個問題的解決成本大于價值了，那就沒必要做了，也就沒必要繼續寫PRD了，因此需要對方案的的直接和間接價值，以及直接和邊際成本進行明確，確定推進是有意義的。

三、PRD文檔在編寫的過程中有哪些是需要注意的？

終于來到了最核心的部分了，PRD文檔的具體結構，有哪些呢，這一部分在網上確實有非常多的模板可以參考，各個模板也是大同小異，但最為重要的是有一些細節上需要注意，這也和下一小節如何使用PRD文檔有很大的關系。在我看來，一個TO B系統的PRD的結構大致分為：

3.1 文檔管理

版本管理需要記錄每次修改的概要說明，相關人員是為了明確具體的工作人員，開發當中的溝通以及后續問題排查需要，設計稿一般會有一個設計工具的地址，里面會有一些圖片無法表達的內容，相關人員需要查看。

3.2 背景

背景和目標通常是比較簡短的。

一方面是為了在內容層面表述大的背景和目標，比如公司整體的方向是讓系統有更高的開放性，需要做一些API，所以本次的開發是在這個開放性的大背景下的，達到XXX部分對接，降低定開成本等等。

另外一方面是在寫作技巧上，不能上來一桿子通到底了，需要與讀者在某些信息上達成共識，引出問題后在再進行具體的說明。

3.3 需求說明和分析

需求并說明的部分主要分為2各部分，需求描述和需求分析，需求分析又分為現狀分析和需求分析2部分：

• 需求描述：需求描述需要原滋原味的將最原始的需求進行表達，可以是客戶的需求、競品對比的需求、老版提出的需求、售前引申的需求等等，但無論來源是什么，在需求描述中一定要回歸業務場景，沒有業務場景說明出發點就要小心了，很有可能最后不會帶來業務上的實際價值。
• 現狀分析：針對需求，目前系統是如何解決的，還是沒有任何方式解決，現有的解決辦法為什么不是最優的。
• 需求分析：需求分析最考驗一個產品經理的基本功（有人說是設計，我不這么認為），需求分是是在挖掘需求背后的真正目的，多問自己幾個為什么需要。

3.4 產品方案概覽

產品方案概覽是為了讓相關人員在查看詳細的設計方案前對整體的情況有一個初步的認識，直接查看一個不熟悉的產品方案細節，很容易無法透測理解。方案概覽一般從3各方面進行闡釋，最后在將開發的任務和范圍明確一下，為具體的功能說明做好鋪墊。

• ER圖：一般情況下，To B的系統都會有很多數據對象，數據對象之間存在復雜的關聯關系，特別是整個方案中如果引入了新的對象或新的關聯關系，那么一定要繪制ER圖，說明不同抽象對象之間的關系。
• 整體方案：整體方案強烈建議使用一張圖，一圖勝前言，用一張圖說明整條的方案，增加了什么頁面、增加了什么字段、增加了什么邏輯處理、增加了什么對外接口等等，根據具體的需要一般會使用架構圖、時序圖等及西寧表達
• 使用方式：可以叫做使用方式，也可以叫做頁面結構圖，主要是為了闡釋在真正客戶面前這個產品是如何被使用的，當然如果沒有頁面的開發，這部分可以省略。

3.5 功能說明

功能說明就是對概覽性方案的拆分說明，對每一個小的功能點進行詳細的說明。一般分為原型和功能說明，沒有頁面的原型部分可以空著。功能部分一定要寫清楚具體的邏輯。

非核心功能和非功能性需求，更加考驗一個產品經理設計能力的細致，優秀的產品經理需要看到功能背后的需求，比如，性能、安全等等，這些細項像一個檢查清單，產品經理在自己具體的領域里不斷手機問題完善這個清單，然后在每個PRD里面一條一條的問自己需不需要。

3.6 驗收說明

驗收說明類似于P0的測試用例，切實描素用戶最終的使用過程。

四、PRD文檔編寫完成后如何使用？

PRD文檔編寫完成就結束了嗎，還沒有，那就是使用PRD知道整個開發過程的工作了，從Planning會議講解PRD開始，PRD文檔正式投入使用，在這個過程中那面會對PRD文檔進行一些修改，這時一定要記錄好修改的內容，不然回頭就忘了。

另外，在PRD使用的過程中，一定要不斷的發現PRD模板的問題，不斷優化PRD模板。