產品需求文檔（PRD）定義了產品的功能、邏輯、交互等關于產品的一切，工程師基于此進行開發，測試基于此寫測試用例，它的重要性不言而喻。這里說說寫 PRD 的一些建議和注意事項

1. 不要用 word、用 wiki

一些大廠的產品經理還在用 word 寫需求文檔，他們會在文檔頂部說明修訂時間、作者以及大致的更新內容，看起來很規范。確定最終版后，使用郵件或 IM 將文檔發送給相關的開發、測試人員。

Word 版 PRD 的版本更新記錄

使用 word 寫文檔有以下缺點

1. 不支持全局搜索和即時預覽。隨著產品的迭代，文檔越來越多，查找會越來越不方便，在郵件或 IM 中需要下載下來重新打開查看，手機端查看和修改更加麻煩。
2. 版本管理不便。需要修改時候，修改對應的內容后需要重新發郵件給所有人，如果有很多次版本迭代，很容易就混淆究竟哪個才是最新版。
3. 不利于離職人員交接。當一個同事要離職時，需要把所有他負責過的 word 文檔整理出來交接給另一個人，如果沒有處理到位，一些歷史文檔就丟失了。

wiki 系統中， Confluence 是不錯的選擇，支持全文搜索、每次保存都有記錄，無需手動撰寫版本記錄，支持樹狀層級結構，權限控制也可以做到非常細致，這里強烈推薦。當然，如果你們團隊使用 Teambition、Tower 等在線協作工具，可以直接使用其自帶的文檔管理工具。

Confluence 的版本記錄功能

2. 需求文檔是碎片化的，不是大而全的

我曾見過上百頁的 word 版需求文檔，打印出來簡直就是一本書。它的缺點很明顯：傳遞起來太過笨重，在文檔內查找定位繁瑣，最重要的是，開發人員討厭這種復雜冗長的文檔。

我的建議是，利用好 wiki 系統的樹狀層級結構，將不同的功能模塊進行合理劃分，放在不同的目錄樹中。未來有新的需求，直接在對應的目錄下新增文檔即可。

3. PRD 是動態的，一定記得及時更新

雖然大家都討厭需求變更，但在實際項目中卻又無法避免。需求變更后，最先做的則是更新需求文檔，即使沒有需求變更，產品也是不斷更新迭代的，對應的產品文檔也需及時更新。

很多產品經理經常忽略這件事，以至于一段時間過后，產生很多需求文檔和產品線上版本很多不一致的情況，團隊有新成員加入或有人離職，又增多了很多解釋和說明的成本。