產品經理日常工作不可缺少的一點就是寫需求文檔，但寫文檔的時候常常會疑惑，我的文檔寫給誰看？如何呈現需求內容？描寫需求時需要細緻到什麼程度？怎麼才能讓團隊快速準確理解需求？這些都是在寫需求文檔之前需要考慮到的。
筆者是互聯網行業的新人，今年開始從事策略類產品的工作，在融入團隊的時候，在leader的輔導下，開始思考，我們的團隊需要什麼樣的PRD才能解決上面這些問題。 寫PRD的方式在經歷過幾次迭代之後，逐漸解決了一些問題，當然並不完美，這份模版也會持續迭代下去。
PRD的目標用戶
我們的產品需求文檔究竟是寫給誰看？這些不同角色的人都關注什麼？
- 產品實際用戶：這是我們產品上線後實習使用的用戶，他們關注的是原型。通過頁面原型而不是文字描述讓他們感知這是一個什麼的產品，知道各個功能塊，以及操作流程，從而能給我們建議。
- 交互設計師：關注頁面呈現、操作邏輯，讓他們瞭解產品功能和邏輯，從而在視覺和交互上優化產品。
- 前端：原型頁面、功能、交互邏輯、操作邏輯，涉及到產品最終呈現效果。
- 後端：業務邏輯、技術邏輯，其次是原型。
- 測試：頁面細節、功能細節、各種情況出現的相應方案。
- leader/其他部門同事：產品目標背景、產品迭代歷史、產品最終效果，這類用戶更關注的是我們為什麼要做這個產品？這個產品被我們做成了什麼樣子？
由此可見，不同角色的人，同一份產品，他們關注的點並不相同。難道一次迭代，我們就要產出6份不同的文檔嗎？
我們看看這樣做的缺點：
- 重複工作：同一份原型，撰寫好幾份文檔，其中可能有大一部分是相同的，然後一小部分根據角色的不同，再增加相應的細節描述。比如：前端和交互都關注產品交互邏輯，但前端可能還會關注頁面背後的邏輯，而交互更關注頁面交互。一份需求分這麼多份，不僅是重複工作，可能PM寫著寫著，自己都暈了。
- 同步麻煩：在方案設計、需求評審、甚至是研發和測試階段，都可能涉及到文檔的修改，一旦有任何變更，都需要同時更新多份文件才能保證信息一致性。但是很有可能給交互的文檔改了，給前端的文件卻忘記修改。
- 管理麻煩：多份文件，涉及多次修改，如果還要保留歷史文件，一旦覆盤時要整理歸檔就會涉及大批文檔。這樣不僅會增加管理成本，在找文檔的時候也是一團亂麻。
所以筆者更傾向於同一份方案只產出一份文檔，文檔中包含所有目標用戶需要的所有內容的方式。當然這樣一份文檔裡面的內容可能會非常多，因而在此之上，還要組織好文檔的結構，確保不同角色的人知道他關注的內容在哪裡。
用AXURE寫PRD
每個團隊都應該有一套規範的PRD寫作方式，因為團隊的人在一個時間段內，基本上不會大幅度變化，統一的格式能減少團隊同事的學習成本。不然一個版本使用word，下一個版本使用PPT，再下一個又使用keynote、sketch，不利於培養團隊默契，也不利於產品版本的歸檔。
PRD的目的在於描述清楚PM的需求，並且保證信息及時同步。所以一開始，可讀性是最重要的。
對一份PRD來說，沒有什麼比可讀性還重要的事情了。原型圖+註釋，能更形象地讓同事們去理解這個需求。我認為目前最適合的PRD寫法就是用Axure，原型+註釋+流程圖。
- 原型：頁面+交互，最好是所有需求涉及到的頁面都在原型中呈現出來。
- 註釋：邏輯描述（業務邏輯、交互邏輯、功能操作邏輯）和細節描述。
- 交互：可根據團隊實際情況考慮給到什麼樣的交互細節，比如：我所在團隊目前是後臺產品，交互較少，而且大部份交互都是全局通用的，因此將交互統一說明，每次新增需求引用交互說明頁面即可。
PRD結構
- 迭代版本修訂記錄：讓團隊知道這一次版本在開發、測試過程中，PM都修改些什麼內容，也有利於PM進行復盤思考。
- 版本記錄：讓團隊和其他部門同事知道你的產品都做了些什麼。
- 項目介紹：讓團隊和各部門leader知道你要解決什麼問題，達到什麼目標。
- 全局說明：通用性的規範說明，讓團隊知道什麼東西可以複用。
- 業務邏輯：核心流程圖，讓團隊知道一些核心場景的邏輯，對於一些複雜的邏輯，一個圖往往比文字可讀性更好。
- 原型圖：原型頁面和註釋說明，原型是讓大家知道你又要加些什麼東西，註釋說明是讓大家理解你的原型。如果有必要，還可以加上例子，讓大家理解真實場景下的用戶行為。
文檔導航
給PRD加上導航，可以更清晰地讓團隊成員、其他部門同事快速找到自己關注的內容。
另外，PM在寫PRD的時候，也知道自己的文檔需要包括什麼內容。
版本記錄
記錄歷次版本變更基本信息，每個版本主要內容有版本號、新版描述、需求清單。主要是為了大家知道，你的產品到目前為止，主要都實現了什麼能力，讓大家理解你、你的團隊、你的項目。
原型變更是對內，對外的版本變更也應該記錄起來，供回顧和查詢。相信這一步很多PD做過，但是每次版本的一覽表，估計做的人不多。
一個版本，應該要將文檔整合歸總，而不是東一塊西一塊，團隊一有人員變動，新來的成員就不知所措。
項目介紹
項目的相關背景、目標和未來規劃。 主要說明以下幾個問題：
- 為什麼要做這個產品，這個產品要解決什麼問題？
- 這個產品主要做什麼，能體現什麼價值，達到什麼目標？
- 項目規劃是什麼？里程碑節點是什麼？
版本管理
每次迭代，都可在原PRD中增加新版本（axure中增加一個folder，比如xx項目xx版本修訂記錄）。新版本主要內容包括新版本修訂記錄+需求清單，以及新增需求點（當前版本涉及的原型圖+註釋），這樣每次迭代版本的詳細記錄都會保留。
當前版本具體要做哪些新頁面，哪些新控件，以及頁面交互怎麼走？
具體來說：
- 知道這個版本需求是啥，為什麼要這麼做，是為了解決什麼問題。
- 知道這個版本需求涉及哪幾個頁面，具體內容是什麼。
- 如果可以，可以將文檔上傳至服務器，PM更新文檔後直接上傳服務器，團隊只要訪問服務器地址，就能直接看到最新版的文檔。從而避免所有人手裡有多份文檔、信息不同步的情況。
當前版本應該放在最上面：
迭代版本的PRD可以在之前版本的PRD中新建一個文件夾，也可以另開一個文檔，重要的是你覺得哪種方式更有利於信息同步。
比如：筆者所在的團隊，迭代版本基本上是新開一個文檔，文檔中包含當前版本的需求清單、修訂記錄和原型頁面說明，並附上全局說明的鏈接。在該版本迭代結束後，將迭代版本的文件整合至整個產品的PRD中（原型和版本修訂記錄），這樣同一個產品的文檔不會分散，有利於文檔管理。
修訂記錄+需求清單
需求清單
以列表形式展示。需求清單為當前版本的需求列表，主要是為了讓團隊知道這一版都包括了什麼需求，需求清單與版本記錄中的需求清單一致。
- 編號：
- ID：需求的ID；
- 需求類型：如新增需求、體驗提升、BUG等；
- 模塊_頁面：該需求涉及到的模塊或者頁面；
- 需求描述：需求的詳細描述；
- 日期：需求確認時的日期，格式：yyyy.mm.dd，一般寫需求評審完成的時間；
- 備註：其他內容，若有原型及說明上的修訂，則可在備註中添加鏈接，點擊【查看】直接鏈接到修改的頁面。
修訂記錄
以列表形式展示。修訂記錄為當前版本需求確認後，在開發和測試過程中每次對文檔和需求進行的修改記錄。
按更新時間，倒序展示，最新的修訂記錄展示在最上方。
- 時間：修訂時間，格式示例：2018.06.15 13：30 精確到時間。
- 修訂內容：修改的內容詳述。
- 修訂原因：修訂原因，如：接口問題、UI更改等。
- 狀態：表明該條修訂內容是採用還是作廢。
- 備註：其他內容。
修訂記錄這一條非常重要。
需求修訂可能帶來的問題：
- ①產品質量出現問題，大家不明確變更的地方、或者變更的點對整個項目影響很大；
- ②增加工作量，項目延期；
- ③增加開銷。
記錄每一次需求修訂能幫助PM：
- ①及時將改動同步給團隊相關同學。
- ②限制PM不要頻繁修改原型，而是在設計方案的時候，就要儘可能考慮到各種情況，並且在開發前就確認好各種問題。
比如：我們之前有一個需求是業務方提的，開發過程中由於業務方提供的接口有問題，方案細節修改了n次，這種變更對產品、對研發、對測試改動都很大，修訂記錄最好是要保留的。
新增需求點
上文說到，在版本迭代的時候，通常是新開一個文檔，這種方式更適合與原有頁面關聯不大的新增需求。若是在原有頁面中加功能、優化，在原PRD文檔中增加一個新增需求點的文件夾，然後通過頁面快照+標註的形式在頁面上新增或優化功能，就不用重新畫原有頁面，省時省力，方便快捷。
頁面快照功能非常好用，大家不妨嘗試一下。
在版本上線之後，就可以將版本PRD中涉及的內容補充到整個PRD中，此時修訂記錄頁面可以保留，新增需求點各個頁面就可以更新至原PRD中了。
全局說明
完整地描述整個系統頁面表現、交互、規則等統一要求和規範。一般會和UI、RD（主要是前端）提前確認並規範的一些交互規則，保證交互的一致性、框架的可複用性。
我們團隊負責的後臺產品，對於交互規則相對來說所有頁面都比較統一。有一個整體的全局說明，不僅PM不用每次都找以前的交互看一遍然後複製粘貼一遍，RD和QA也不用總是來確認交互。
圖中左側為全局說明導航欄，右側為具體說明。
功能及頁面流程圖
對於一些複雜的流程和邏輯，最好能將流程圖繪製出來，不僅是幫助PM自己梳理邏輯，也能讓團隊快速並準確地瞭解業務，大篇的語言描述可能並不如一張圖來得簡單直觀。
繪製流程圖的適合，最好採用統一的規範，若有可能，儘量生成一份流程圖目錄，不僅可以讓團隊快速熟悉業務，也能讓PM自己查漏補缺，提升文檔撰寫能力。
業務流程圖
抽象出整個產品核心業務的走向，可以快速地讓用戶知道，你這個產品的主要業務是什麼，業務的流轉是什麼樣的。
原型圖
原型圖主要分為三個區域：一個原型圖區域，一個功能流程圖區域，一個說明區。
產品需求說明方式對比
（1）使用axure自帶的註釋來寫邏輯：將需求寫在每個控件的notes中
優點：
- 全面：一個控件一個控件的寫邏輯，不容易遺漏。
- 易看：你會發現選中左方tab-notes中的某一個模塊，右方會藍色高亮選中控件的邊緣。標註這個文本框對應的註釋是哪些，比拖拉一個便籤好用太多。
缺點：
- 操作略麻煩，需要點開每個註釋，沒有直接的文字區域直觀。
- 有隱藏、判斷、彈窗等交互的地方用notes描述不夠簡單清晰。
（2）使用便籤、表格或者數字標識，按照控件順序將文字寫到原型頁面旁邊
優點：
- 全面：按順序羅列各項控件操作則不會漏掉控件。
- 易於尋找某個具體的控件。
- 結構、描述清晰。
缺點：若原型圖過大，控件過多時，需要翻頁查看。
採用哪種方式，可根據自己和團隊的習慣抉擇。
其他
這份PRD模版從出生到現在，歷時3個月，在不斷使用這份模版的過程中，發現了一開始設計不夠好的地方，也不斷地在迭代解決問題。
其實這份PRD也是一個小小的產品，它是基於當前問題產生的一個解決方案，在用戶使用過程中又出現新的需求和問題。PM發現問題、迭代PRD，優化出更合適的產品。
題圖來自 Pexels，基於 CC0 協議
閱讀更多 人人都是產品經理 的文章
