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

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

PRD的目標(biāo)用戶

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

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

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

我們看看這樣做的缺點：

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

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

用AXURE寫PRD

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

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

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

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

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

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

文檔導(dǎo)航

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

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

版本記錄

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

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

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

項目介紹

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

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

版本管理

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

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

具體來說：

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

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

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

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

修訂記錄+需求清單

需求清單

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

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

修訂記錄

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

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

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

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

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

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

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

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

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

新增需求點

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

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

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

全局說明

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

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

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

功能及頁面流程圖

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

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

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

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

原型圖

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

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

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

優(yōu)點：

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

缺點：

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

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