產(chǎn)品經(jīng)理日常工作不可缺少的一點(diǎn)就是寫需求文檔，但寫文檔的時(shí)候常常會疑惑，我的文檔寫給誰看？如何呈現(xiàn)需求內(nèi)容？描寫需求時(shí)需要細(xì)致到什么程度？怎么才能讓團(tuán)隊(duì)快速準(zhǔn)確理解需求？這些都是在寫需求文檔之前需要考慮到的。

筆者是互聯(lián)網(wǎng)行業(yè)的新人，今年開始從事策略類產(chǎn)品的工作，在融入團(tuán)隊(duì)的時(shí)候，在leader的輔導(dǎo)下，開始思考，我們的團(tuán)隊(duì)需要什么樣的PRD才能解決上面這些問題。
寫PRD的方式在經(jīng)歷過幾次迭代之后，逐漸解決了一些問題，當(dāng)然并不完美，這份模版也會持續(xù)迭代下去。

PRD的目標(biāo)用戶

我們的產(chǎn)品需求文檔究竟是寫給誰看？這些不同角色的人都關(guān)注什么？

1. 產(chǎn)品實(shí)際用戶：這是我們產(chǎn)品上線后實(shí)習(xí)使用的用戶，他們關(guān)注的是原型。通過頁面原型而不是文字描述讓他們感知這是一個(gè)什么的產(chǎn)品，知道各個(gè)功能塊，以及操作流程，從而能給我們建議。
2. 交互設(shè)計(jì)師：關(guān)注頁面呈現(xiàn)、操作邏輯，讓他們了解產(chǎn)品功能和邏輯，從而在視覺和交互上優(yōu)化產(chǎn)品。
3. 前端：原型頁面、功能、交互邏輯、操作邏輯，涉及到產(chǎn)品最終呈現(xiàn)效果。
4. 后端：業(yè)務(wù)邏輯、技術(shù)邏輯，其次是原型。
5. 測試：頁面細(xì)節(jié)、功能細(xì)節(jié)、各種情況出現(xiàn)的相應(yīng)方案。
6. leader/其他部門同事：產(chǎn)品目標(biāo)背景、產(chǎn)品迭代歷史、產(chǎn)品最終效果，這類用戶更關(guān)注的是我們?yōu)槭裁匆鲞@個(gè)產(chǎn)品？這個(gè)產(chǎn)品被我們做成了什么樣子？

由此可見，不同角色的人，同一份產(chǎn)品，他們關(guān)注的點(diǎn)并不相同。難道一次迭代，我們就要產(chǎn)出6份不同的文檔嗎？

我們看看這樣做的缺點(diǎn)：

1. 重復(fù)工作：同一份原型，撰寫好幾份文檔，其中可能有大一部分是相同的，然后一小部分根據(jù)角色的不同，再增加相應(yīng)的細(xì)節(jié)描述。比如：前端和交互都關(guān)注產(chǎn)品交互邏輯，但前端可能還會關(guān)注頁面背后的邏輯，而交互更關(guān)注頁面交互。一份需求分這么多份，不僅是重復(fù)工作，可能PM寫著寫著，自己都暈了。
2. 同步麻煩：在方案設(shè)計(jì)、需求評審、甚至是研發(fā)和測試階段，都可能涉及到文檔的修改，一旦有任何變更，都需要同時(shí)更新多份文件才能保證信息一致性。但是很有可能給交互的文檔改了，給前端的文件卻忘記修改。
3. 管理麻煩：多份文件，涉及多次修改，如果還要保留歷史文件，一旦復(fù)盤時(shí)要整理歸檔就會涉及大批文檔。這樣不僅會增加管理成本，在找文檔的時(shí)候也是一團(tuán)亂麻。

所以筆者更傾向于同一份方案只產(chǎn)出一份文檔，文檔中包含所有目標(biāo)用戶需要的所有內(nèi)容的方式。當(dāng)然這樣一份文檔里面的內(nèi)容可能會非常多，因而在此之上，還要組織好文檔的結(jié)構(gòu)，確保不同角色的人知道他關(guān)注的內(nèi)容在哪里。

用AXURE寫PRD

每個(gè)團(tuán)隊(duì)都應(yīng)該有一套規(guī)范的PRD寫作方式，因?yàn)閳F(tuán)隊(duì)的人在一個(gè)時(shí)間段內(nèi)，基本上不會大幅度變化，統(tǒng)一的格式能減少團(tuán)隊(duì)同事的學(xué)習(xí)成本。不然一個(gè)版本使用word，下一個(gè)版本使用PPT，再下一個(gè)又使用keynote、sketch，不利于培養(yǎng)團(tuán)隊(duì)默契，也不利于產(chǎn)品版本的歸檔。

PRD的目的在于描述清楚PM的需求，并且保證信息及時(shí)同步。所以一開始，可讀性是最重要的。

對一份PRD來說，沒有什么比可讀性還重要的事情了。原型圖+注釋，能更形象地讓同事們?nèi)ダ斫膺@個(gè)需求。我認(rèn)為目前最適合的PRD寫法就是用Axure，原型+注釋+流程圖。

1. 原型：頁面+交互，最好是所有需求涉及到的頁面都在原型中呈現(xiàn)出來。
2. 注釋：邏輯描述（業(yè)務(wù)邏輯、交互邏輯、功能操作邏輯）和細(xì)節(jié)描述。
3. 交互：可根據(jù)團(tuán)隊(duì)實(shí)際情況考慮給到什么樣的交互細(xì)節(jié)，比如：我所在團(tuán)隊(duì)目前是后臺產(chǎn)品，交互較少，而且大部份交互都是全局通用的，因此將交互統(tǒng)一說明，每次新增需求引用交互說明頁面即可。

PRD結(jié)構(gòu)

1. 迭代版本修訂記錄：讓團(tuán)隊(duì)知道這一次版本在開發(fā)、測試過程中，PM都修改些什么內(nèi)容，也有利于PM進(jìn)行復(fù)盤思考。
2. 版本記錄：讓團(tuán)隊(duì)和其他部門同事知道你的產(chǎn)品都做了些什么。
3. 項(xiàng)目介紹：讓團(tuán)隊(duì)和各部門leader知道你要解決什么問題，達(dá)到什么目標(biāo)。
4. 全局說明：通用性的規(guī)范說明，讓團(tuán)隊(duì)知道什么東西可以復(fù)用。
5. 業(yè)務(wù)邏輯：核心流程圖，讓團(tuán)隊(duì)知道一些核心場景的邏輯，對于一些復(fù)雜的邏輯，一個(gè)圖往往比文字可讀性更好。
6. 原型圖：原型頁面和注釋說明，原型是讓大家知道你又要加些什么東西，注釋說明是讓大家理解你的原型。如果有必要，還可以加上例子，讓大家理解真實(shí)場景下的用戶行為。

文檔導(dǎo)航

給PRD加上導(dǎo)航，可以更清晰地讓團(tuán)隊(duì)成員、其他部門同事快速找到自己關(guān)注的內(nèi)容。

另外，PM在寫PRD的時(shí)候，也知道自己的文檔需要包括什么內(nèi)容。

版本記錄

記錄歷次版本變更基本信息，每個(gè)版本主要內(nèi)容有版本號、新版描述、需求清單。主要是為了大家知道，你的產(chǎn)品到目前為止，主要都實(shí)現(xiàn)了什么能力，讓大家理解你、你的團(tuán)隊(duì)、你的項(xiàng)目。

原型變更是對內(nèi)，對外的版本變更也應(yīng)該記錄起來，供回顧和查詢。相信這一步很多PD做過，但是每次版本的一覽表，估計(jì)做的人不多。

一個(gè)版本，應(yīng)該要將文檔整合歸總，而不是東一塊西一塊，團(tuán)隊(duì)一有人員變動，新來的成員就不知所措。

項(xiàng)目介紹

項(xiàng)目的相關(guān)背景、目標(biāo)和未來規(guī)劃。
主要說明以下幾個(gè)問題：

• 為什么要做這個(gè)產(chǎn)品，這個(gè)產(chǎn)品要解決什么問題？
• 這個(gè)產(chǎn)品主要做什么，能體現(xiàn)什么價(jià)值，達(dá)到什么目標(biāo)？
• 項(xiàng)目規(guī)劃是什么？里程碑節(jié)點(diǎn)是什么？

版本管理

每次迭代，都可在原PRD中增加新版本（axure中增加一個(gè)folder，比如xx項(xiàng)目xx版本修訂記錄）。新版本主要內(nèi)容包括新版本修訂記錄+需求清單，以及新增需求點(diǎn)（當(dāng)前版本涉及的原型圖+注釋），這樣每次迭代版本的詳細(xì)記錄都會保留。

當(dāng)前版本具體要做哪些新頁面，哪些新控件，以及頁面交互怎么走？

具體來說：

1. 知道這個(gè)版本需求是啥，為什么要這么做，是為了解決什么問題。
2. 知道這個(gè)版本需求涉及哪幾個(gè)頁面，具體內(nèi)容是什么。
3. 如果可以，可以將文檔上傳至服務(wù)器，PM更新文檔后直接上傳服務(wù)器，團(tuán)隊(duì)只要訪問服務(wù)器地址，就能直接看到最新版的文檔。從而避免所有人手里有多份文檔、信息不同步的情況。

當(dāng)前版本應(yīng)該放在最上面：

迭代版本的PRD可以在之前版本的PRD中新建一個(gè)文件夾，也可以另開一個(gè)文檔，重要的是你覺得哪種方式更有利于信息同步。

比如：筆者所在的團(tuán)隊(duì)，迭代版本基本上是新開一個(gè)文檔，文檔中包含當(dāng)前版本的需求清單、修訂記錄和原型頁面說明，并附上全局說明的鏈接。在該版本迭代結(jié)束后，將迭代版本的文件整合至整個(gè)產(chǎn)品的PRD中（原型和版本修訂記錄），這樣同一個(gè)產(chǎn)品的文檔不會分散，有利于文檔管理。

修訂記錄+需求清單

需求清單

以列表形式展示。需求清單為當(dāng)前版本的需求列表，主要是為了讓團(tuán)隊(duì)知道這一版都包括了什么需求，需求清單與版本記錄中的需求清單一致。

1. 編號：
2. ID：需求的ID；
3. 需求類型：如新增需求、體驗(yàn)提升、BUG等；
4. 模塊_頁面：該需求涉及到的模塊或者頁面；
5. 需求描述：需求的詳細(xì)描述；
6. 日期：需求確認(rèn)時(shí)的日期，格式：yyyy.mm.dd，一般寫需求評審?fù)瓿傻臅r(shí)間；
7. 備注：其他內(nèi)容，若有原型及說明上的修訂，則可在備注中添加鏈接，點(diǎn)擊【查看】直接鏈接到修改的頁面。

修訂記錄

以列表形式展示。修訂記錄為當(dāng)前版本需求確認(rèn)后，在開發(fā)和測試過程中每次對文檔和需求進(jìn)行的修改記錄。

按更新時(shí)間，倒序展示，最新的修訂記錄展示在最上方。

1. 時(shí)間：修訂時(shí)間，格式示例：2018.06.15 13：30 精確到時(shí)間。
2. 修訂內(nèi)容：修改的內(nèi)容詳述。
3. 修訂原因：修訂原因，如：接口問題、UI更改等。
4. 狀態(tài)：表明該條修訂內(nèi)容是采用還是作廢。
5. 備注：其他內(nèi)容。

修訂記錄這一條非常重要。

需求修訂可能帶來的問題：

• ①產(chǎn)品質(zhì)量出現(xiàn)問題，大家不明確變更的地方、或者變更的點(diǎn)對整個(gè)項(xiàng)目影響很大；
• ②增加工作量，項(xiàng)目延期；
• ③增加開銷。

記錄每一次需求修訂能幫助PM：

• ①及時(shí)將改動同步給團(tuán)隊(duì)相關(guān)同學(xué)。
• ②限制PM不要頻繁修改原型，而是在設(shè)計(jì)方案的時(shí)候，就要盡可能考慮到各種情況，并且在開發(fā)前就確認(rèn)好各種問題。

比如：我們之前有一個(gè)需求是業(yè)務(wù)方提的，開發(fā)過程中由于業(yè)務(wù)方提供的接口有問題，方案細(xì)節(jié)修改了n次，這種變更對產(chǎn)品、對研發(fā)、對測試改動都很大，修訂記錄最好是要保留的。

新增需求點(diǎn)

上文說到，在版本迭代的時(shí)候，通常是新開一個(gè)文檔，這種方式更適合與原有頁面關(guān)聯(lián)不大的新增需求。若是在原有頁面中加功能、優(yōu)化，在原PRD文檔中增加一個(gè)新增需求點(diǎn)的文件夾，然后通過頁面快照+標(biāo)注的形式在頁面上新增或優(yōu)化功能，就不用重新畫原有頁面，省時(shí)省力，方便快捷。

頁面快照功能非常好用，大家不妨嘗試一下。

在版本上線之后，就可以將版本PRD中涉及的內(nèi)容補(bǔ)充到整個(gè)PRD中，此時(shí)修訂記錄頁面可以保留，新增需求點(diǎn)各個(gè)頁面就可以更新至原PRD中了。

全局說明

完整地描述整個(gè)系統(tǒng)頁面表現(xiàn)、交互、規(guī)則等統(tǒng)一要求和規(guī)范。一般會和UI、RD（主要是前端）提前確認(rèn)并規(guī)范的一些交互規(guī)則，保證交互的一致性、框架的可復(fù)用性。

我們團(tuán)隊(duì)負(fù)責(zé)的后臺產(chǎn)品，對于交互規(guī)則相對來說所有頁面都比較統(tǒng)一。有一個(gè)整體的全局說明，不僅PM不用每次都找以前的交互看一遍然后復(fù)制粘貼一遍，RD和QA也不用總是來確認(rèn)交互。

圖中左側(cè)為全局說明導(dǎo)航欄，右側(cè)為具體說明。

功能及頁面流程圖

對于一些復(fù)雜的流程和邏輯，最好能將流程圖繪制出來，不僅是幫助PM自己梳理邏輯，也能讓團(tuán)隊(duì)快速并準(zhǔn)確地了解業(yè)務(wù)，大篇的語言描述可能并不如一張圖來得簡單直觀。

繪制流程圖的適合，最好采用統(tǒng)一的規(guī)范，若有可能，盡量生成一份流程圖目錄，不僅可以讓團(tuán)隊(duì)快速熟悉業(yè)務(wù)，也能讓PM自己查漏補(bǔ)缺，提升文檔撰寫能力。

業(yè)務(wù)流程圖

抽象出整個(gè)產(chǎn)品核心業(yè)務(wù)的走向，可以快速地讓用戶知道，你這個(gè)產(chǎn)品的主要業(yè)務(wù)是什么，業(yè)務(wù)的流轉(zhuǎn)是什么樣的。

原型圖

原型圖主要分為三個(gè)區(qū)域：一個(gè)原型圖區(qū)域，一個(gè)功能流程圖區(qū)域，一個(gè)說明區(qū)。

產(chǎn)品需求說明方式對比

（1）使用axure自帶的注釋來寫邏輯：將需求寫在每個(gè)控件的notes中

優(yōu)點(diǎn)：

• 全面：一個(gè)控件一個(gè)控件的寫邏輯，不容易遺漏。
• 易看：你會發(fā)現(xiàn)選中左方tab-notes中的某一個(gè)模塊，右方會藍(lán)色高亮選中控件的邊緣。標(biāo)注這個(gè)文本框?qū)?yīng)的注釋是哪些，比拖拉一個(gè)便簽好用太多。

缺點(diǎn)：

• 操作略麻煩，需要點(diǎn)開每個(gè)注釋，沒有直接的文字區(qū)域直觀。
• 有隱藏、判斷、彈窗等交互的地方用notes描述不夠簡單清晰。

（2）使用便簽、表格或者數(shù)字標(biāo)識，按照控件順序?qū)⑽淖謱懙皆晚撁媾赃?/strong>