作為產(chǎn)品經(jīng)理，編寫產(chǎn)品需求文檔是基本技能之一，本文詳細(xì)介紹了如何編寫產(chǎn)品需求文檔（PRD），希望對(duì)你編寫有效的PRD有所幫助。

PRD是Product Requirement Document的簡(jiǎn)稱，翻譯為：產(chǎn)品需求文檔。該文檔是產(chǎn)品由“概念化”階段進(jìn)入到“圖紙化”階段的最重要的一個(gè)文檔。編寫PRD是一個(gè)產(chǎn)品經(jīng)理最為基礎(chǔ)的工作內(nèi)容，也是一個(gè)產(chǎn)品經(jīng)理最基礎(chǔ)的能力。不夸張的說，通過一篇PRD文檔就可以體現(xiàn)出一個(gè)產(chǎn)品經(jīng)理的基本功是否扎實(shí)，這直接影響到整個(gè)研發(fā)團(tuán)隊(duì)的效率。

我常年從事To B系統(tǒng)產(chǎn)品的工作，因此本文的內(nèi)容也僅針對(duì)To B系統(tǒng)的PRD文檔，并不完全適用To C的系統(tǒng)產(chǎn)品。想寫出一篇優(yōu)秀的PRD文檔，需要搞清楚如下4個(gè)問題：

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

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

編寫PRD文檔最為重要的目的就是：協(xié)調(diào)各個(gè)相關(guān)角色，將產(chǎn)品高效正確的“生產(chǎn)”出來。PRD僅僅是為達(dá)到這個(gè)目標(biāo)，產(chǎn)品經(jīng)理經(jīng)常使用的一種工具，只要是能夠高效的完成最后的系統(tǒng)化產(chǎn)品，那么PRD具體的內(nèi)容、形式也沒有非常嚴(yán)格的標(biāo)準(zhǔn)。從這個(gè)目標(biāo)出發(fā)，我們能夠看到這樣幾個(gè)關(guān)鍵詞：各個(gè)角色、高效&正確和生產(chǎn)

1.1 各個(gè)角色

這里的角色是涉及到整個(gè)產(chǎn)品研發(fā)過程中全部相關(guān)的角色，每個(gè)角色在這個(gè)過程中負(fù)責(zé)的工作和關(guān)注點(diǎn)有所不同，PRD中需要照顧到所有參與角色的關(guān)注點(diǎn)，To B系統(tǒng)產(chǎn)品在此過程中主要涉及到的角色如下：

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

1.2 高效&正確

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

PRD就是提高效率的，把各個(gè)角色的共識(shí)全部寫出來，大家都已PRD為最終的工作指導(dǎo)文檔，在墻漆可以討論修改，在后期可以追根溯源，多花點(diǎn)時(shí)間在PRD上一定會(huì)比不斷地回答問題，不斷地因?yàn)闆]有大臣一致的邏輯反復(fù)修改要高效的多。

1.3 生產(chǎn)

本質(zhì)上，軟件開發(fā)也是生產(chǎn)的過程，和生產(chǎn)實(shí)物是沒有本質(zhì)區(qū)別的。PRD作為指導(dǎo)生產(chǎn)過程的重要文檔，類似實(shí)物生產(chǎn)的設(shè)計(jì)文檔，必須要滿足在生產(chǎn)過程中各種各樣問題的回答。因此需要從生產(chǎn)流程的角度進(jìn)一步的來說審視PRD的內(nèi)容，包括：現(xiàn)狀、準(zhǔn)備工作、前提條件、開發(fā)邏輯、效果要求等。

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

在上一小節(jié)中建議在PRD編寫之前，通過產(chǎn)品提案等方式把價(jià)值、成本等內(nèi)容全部確定好，達(dá)成一致。實(shí)際上在PRD文檔編寫之前還遠(yuǎn)不止這些內(nèi)容。

PRD開始編寫，意味著整個(gè)業(yè)務(wù)調(diào)研、方案邏輯、可行性、價(jià)值判斷基本上已經(jīng)完成了，如果沒有完成那么是不建議直接編寫PRD文檔的，因?yàn)榫退銓懲炅艘埠苡锌赡芨膩砀娜セ虿蛔隽耍@不僅僅影響工作的效率，還會(huì)大大打擊個(gè)人和團(tuán)隊(duì)的積極性。

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

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

終于來到了最核心的部分了，PRD文檔的具體結(jié)構(gòu)，有哪些呢，這一部分在網(wǎng)上確實(shí)有非常多的模板可以參考，各個(gè)模板也是大同小異，但最為重要的是有一些細(xì)節(jié)上需要注意，這也和下一小節(jié)如何使用PRD文檔有很大的關(guān)系。在我看來，一個(gè)TO B系統(tǒng)的PRD的結(jié)構(gòu)大致分為：

3.1 文檔管理

版本管理需要記錄每次修改的概要說明，相關(guān)人員是為了明確具體的工作人員，開發(fā)當(dāng)中的溝通以及后續(xù)問題排查需要，設(shè)計(jì)稿一般會(huì)有一個(gè)設(shè)計(jì)工具的地址，里面會(huì)有一些圖片無法表達(dá)的內(nèi)容，相關(guān)人員需要查看。

3.2 背景

背景和目標(biāo)通常是比較簡(jiǎn)短的。

一方面是為了在內(nèi)容層面表述大的背景和目標(biāo)，比如公司整體的方向是讓系統(tǒng)有更高的開放性，需要做一些API，所以本次的開發(fā)是在這個(gè)開放性的大背景下的，達(dá)到XXX部分對(duì)接，降低定開成本等等。

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

3.3 需求說明和分析

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

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

3.4 產(chǎn)品方案概覽

產(chǎn)品方案概覽是為了讓相關(guān)人員在查看詳細(xì)的設(shè)計(jì)方案前對(duì)整體的情況有一個(gè)初步的認(rèn)識(shí)，直接查看一個(gè)不熟悉的產(chǎn)品方案細(xì)節(jié)，很容易無法透測(cè)理解。方案概覽一般從3各方面進(jìn)行闡釋，最后在將開發(fā)的任務(wù)和范圍明確一下，為具體的功能說明做好鋪墊。

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

3.5 功能說明

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

非核心功能和非功能性需求，更加考驗(yàn)一個(gè)產(chǎn)品經(jīng)理設(shè)計(jì)能力的細(xì)致，優(yōu)秀的產(chǎn)品經(jīng)理需要看到功能背后的需求，比如，性能、安全等等，這些細(xì)項(xiàng)像一個(gè)檢查清單，產(chǎn)品經(jīng)理在自己具體的領(lǐng)域里不斷手機(jī)問題完善這個(gè)清單，然后在每個(gè)PRD里面一條一條的問自己需不需要。

3.6 驗(yàn)收說明

驗(yàn)收說明類似于P0的測(cè)試用例，切實(shí)描素用戶最終的使用過程。

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

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

另外，在PRD使用的過程中，一定要不斷的發(fā)現(xiàn)PRD模板的問題，不斷優(yōu)化PRD模板。