寫過超10W字的PRD文檔，我總結了一些經驗
編輯導語：作為一個產品經理，PRD文檔是必須要掌握的，PRD文檔是產品需求文檔，是可以將概念化的需求轉變為圖紙化的文檔，做項目時起到輔助作用。本文作者分享了關於PRD文檔5W2H的詳細分析，我們一起來看一下。
經常會有剛入行的產品小夥伴們問：“PRD文檔應該怎麼寫？要寫什麼內容？要細緻到什麼程度？用什麼寫呀？”
這個問題我們可以根據5W2H分析法來進行一一拆解。（以下內容都是根據筆者自己做過的項目總結，適用於筆者本人合作的團隊；實際的文檔內容以及產出形式，只要自己的團隊能接受都OK的。）
一、What | 什麼是PRDPRD（Product Requirements Document），產品需求文檔，是產品經理硬實力的表現形式之一。
“是將商業需求文檔（BRD）和市場需求文檔（MRD）用更加專業的語言進行描述”——百度詞條
簡而言之，就是將天馬行空的概念具象化為實際的業務邏輯、UI頁面、菜單按鈕、字段定義、數據結果，最終輔導開發人員將系統研發出來，落地開花。
二、Why | 為什麼需要PRD文檔PRD文檔是產品項目由“概念化”進入“圖紙化”的最主要的文檔，編寫主要有幾個目的：
- 概念具象化：產品人員蒐集了各方的需求進行去偽存真的處理之後，需要對單個的需求點整合 –> 抽象 –> 具象，輸出為黑字白紙的落地文檔；並且的文檔的編寫過程中，可以從全局的角度和細節中去驗證邏輯是否正確；
- 協助項目開發：從項目立項開始、到項目評審、項目開發、項目驗收，PRD文檔貫穿了整個產品的誕生過程，重要性可想而知；
- 產品定版證據：產品文檔編寫完畢之後就要進行封版處理，不能在開發過程中頻繁變動需求，否則交付會無限延期；
- 記錄產品演進藍圖：若研發過程中需求有變動會首先排查文檔的定版內容，對變動需求單獨進行處理；若為版本迭代，也可以根據以前的版本記錄進行追蹤查源；
- 預防人員變動：若公司的人員流動性比較強，文檔保存不當，會導致產品的持續性研發迭代變得異常困難。
需要使用文檔的時機和文檔的適用對象是緊密相連的，下文一併詳細説明。
四、Who | 誰會閲讀PRD文檔1. 公司領導——調研結束後、項目評審前在經過一系列的公司戰略會議、市場調研、競品分析研究之後，產品就要進入到實際的設計階段；公司領導或者產品直屬領導會查看部分PRD文檔，以確保需求沒有偏離軌道。
2. 設計師、研發人員——項目評審前後、研發過程中項目評審前一般會提前下發PRD文檔，預留一些時間讓研發人員熟悉將要做的業務和內容；以免在評審時不清楚具體需求是什麼，也無法提出相應的意見，結果在開發過程中不斷問產品經理的情況。
3. 測試人員——研發過程中、測試中項目研發過程較長，一般會讓測試人員提前介入測試，而非等開發完結後再統一測試，此舉也是為了避免項目研發出現偏差，或者測試後預留的修復bug時間不足。
如果要做足功課的話，測試人員基本要與研發人員同時熟悉PRD文檔，以免測試工作脱離了實際的業務場景。
4. 運營人員——測試中、上線後有些業務部門可能會提前參與到項目驗收中，需要熟悉產品的關鍵業務流程。
功能性比較複雜的產品，有些公司是會專門設置職位為一線的市場、銷售人員進行使用培訓。
5. 產品的接任者如字面意思，產品的接任者。
五、Where | 在哪裏閲讀PRD這個應該沒什麼好説的，考慮PRD文檔的使用對象，一般就是在PC端閲讀吧，無需考慮閲讀的硬件適配啥的。
如果有人非要用手機閲讀，那隻能眼睛受累了。
六、How | 如何編寫PRD文檔寫了那麼多，終於要到重點部分了。
曾聽過來自技術的一句話“一份好的PRD文檔，開發看見之後應該是能行雲流水的寫代碼，如果寫兩下就卡殼，那肯定是文檔質量或業務邏輯出了問題。”
那一份好的PRD文檔，應該包括哪些內容呢？
1. 目錄或者導航索引方便使用人員快速找到所需的文檔信息，個人認為建立層級分明的側邊欄索引比文檔目錄要使用便捷度高一些。
內容説明：基本沒人看的廢話。
適用對象：如上文所寫；主要是為了強調文檔是公司內部保密資產，不可對外流出。
術語詞彙：很重要，對於新的系統出現的業務用詞或者行業內的專有名詞，需要詳細説明。
（專有名詞説明）
3. 系統概述功能模塊清單：列明系統版本所包含的子模塊、列表清單、菜單、備註、功能的需求等級；方便產品經理清晰梳理系統覆蓋的業務內容。
系統用户角色説明
説明系統設計的所有用户角色，對應角色的職能。
數據權限、角色權限清單：
複雜的系統需要區別用户角色、提供專門的權限清單，方便開發人員提前做好數據隔離、功能權限隔離；
版本規劃藍圖，又稱產品roadtrip。
在產品的前期調研中，會盡量全面的考慮產品的完整生命週期應該如何發展；但是研發資源是緊缺的，而且市場是需要經過驗證的，時間也不等人，所以B端也會存在MVP的概念。
所以大型的產品一般會規劃分期實現，需要注意的是——每一期的產品規劃必須是一個完整的業務閉環，否則項目上線了會面了無法使用的尷尬局面。
本期需要實現的功能要和開發人員詳細溝通，如需預留接口的地方要做到心中有數。
例如：產品規劃要做多種支付通道，但是本期只做一種支付通道，那麼支付通道的類型選擇，需要提前定義為便於拓展的字典，而非寫死的字段。
（某產品的三期規劃藍圖）
5. 框架圖、流程圖組織架構圖、信息框架圖：目前市面上對組織架構圖和信息框架圖也沒有特別嚴格清晰的定義，主要是為了講解產品的整體框架是如何搭建的，具體框架包含的模塊，模塊所附帶的功能等；能將事情講清楚就行，不用過於在意架構圖中是否需要詳細列明每個模塊下的細分功能點。
（某TMS系統單獨模塊的組織架構圖）
業務流程圖：核心的業務流程圖顆粒度比較粗，講述關鍵節點的操作和數據流轉，以及關鍵環節的參與對象。
（某TMS系統核心業務流程圖）
核心業務流程定下來後，可以對業務流程進行細化；顆粒度最細的是具有邏輯判斷、異常流描述的流程圖。
本人的習慣是在進行具體的功能文字描述時，比較複雜的業務流程會配備流程圖，圖形比文字更容易理解。
（細化流程：常見的註冊流程圖）
6. 功能需求描述功能需求的描述，需要覆蓋以下內容：
- 功能描述：1-3句話概括功能要點，建立開發對功能大致瞭解；
- 業務場景描述：比較不容易理解的業務流程，可以描述實際業務場景，或者在評審環節，多詳細講解業務發生的線下場景，需要解決的用户痛點，便於開發建立對業務更全面的認知，產生共鳴；
- 前置條件：動作發生的限制條件；例如操作該功能應該具備的權限；例如司機接單的前置條件是已經完成實名認證等；
- 後置條件：動作發生後引起的結果；例如指派訂單動作後，系統會更新一條訂單記錄，同時司機收到待運訂單消息；
- 異常情況：動作後可能存在的異常情況；；例如指派訂單後，需要對訂單進行取消或者撤回處理（根據個人的項目經驗，異常情況的考慮在業務描述中基本佔比能到30%-50%，甚至可能更高，異常比較考驗產品人員對業務的熟悉情況、逆向思考的邏輯能力以及邏輯的縝密性）；
- 排序方式：數據產生後，以什麼條件進行排序；時間順序、逆序；數值正序、倒序等；
- 交互規則：可以附帶小卡片式頁面跳轉邏輯、彈窗展示描述等；
- 計算規則：有計算值的，給出計算公式；計算過程比較複雜的，最好是可以提供一份測算表格，方便開發人員比對實現的效果是否正確；
- 字段説明：對字段的類型、長度、默認值、計算規則等進行説明；之前寫過一篇《增刪改查顯算傳，7字箴言搭建B端底層框架》的文章，對字段進行過詳細講解，大家有興趣可以看一下；
- 核心字典狀態定義：清晰描述字典值變動的條件和業務狀況，字典之間的切換不要有冗餘狀態或者瞬時狀態；例如支付業務中，常見的字典有：待支付、支付成功、支付失敗；若是瞬時到賬的支付方式，此處加入已凍結狀態，就屬於字典冗餘；需要預留接口的字典，暫時用不上的，需要對字典禁用，以免開發不清楚情況使用了錯誤的字典值。
（核心字典狀態定義）
（功能需求描述）
（字段説明）
7. 頁面原型只要做好了以上的工作，原型只是水到渠成的事情——可謂“邏輯思考10小時，原型作圖2分鐘”。
對於比較簡單的需求，也很常用的是直接在原型頁面上編寫PRD文檔。
（原型直接標註需求描述）
8. 數據説明可能公司不同對產品的要求有區別，目前經歷過的有：
- 要求寫明基本的請求參數，即字段説明；
- 要求設計基礎的業務表結構，表明數據之間的建模關係，一對一、一對多、多對多等；
- 也有要求產品做業務數據建模；正在瞭解中，希望以後有機會可以寫一下。
（ER圖，數據之間的關係）
9. 全局規範對通用交互原則、產品規則的描述，大型的團隊一般會配專門的交互設計師，在原型設計的基礎上對產品交互進行優化。
- 埋點需求：對特定用户的行為和活動路徑進行數據捕捉、獲取的手段，為產品的持續優化迭代提供數據支撐；常用第三方埋點平台而非自研埋點平台，後者研發成本較高（偏向於產品的運營方向）。
- 產品性能需求：目前淺薄的瞭解過併發性能、響應性能、安全性能等（技術向，瞭解不深）。
- Word文字描述 + 原型截圖：常用形式；
- Axure原型 + 批註/説明：需求簡單情況適用；
- 口述：緊急需求適用，後期需補充文檔。
小結：PRD文檔的描述，需要保持交互邏輯的一致性（避免二級頁面，時而為“彈窗”時而為“跳轉頁面”）、文案風格的一致性、功能命名的一致性、字段命名的一致性（避免個人名稱字段此列表叫“名稱”彼列表叫“姓名”的情況）。
七、How much | 文檔版本控制5W2H原則，這裏使用how much其實有點不太合適；但是文檔的版本記錄，還是值得一説的。
一般從0-1的產品文檔相對好寫一些，評審結束後研發期間，基本會對文檔進行封版處理。
如果有不得已的情況需要對文檔進行變動，一定及時告知相關負責人員，例如產品領導、技術開發人員、測試人員，並及時維護文檔，每一次的變更都需要留下文字記錄。
個人認為對閲讀者來説比較好的方式是：文檔頭部增加版本變更記錄，同時在文檔內部用不同的顏色將變動的內容標註出來。
已經上線的版本變更，需要着重梳理變動內容和前後業務流程的關聯影響，特別是產品的業務耦合性比較強的，很容易發生修改一處需求，引起多出報錯的情況。
版本變更記錄，需要包含的信息有：
- 版本號：重大變更V1.0.0/V2.0.0；小規模修改：V1.1.0/V1.2.0；
- 提交時間；
- 狀態：新增、變更或者刪除需求；
- 簡要描述變更的內容；
- 部門：需求提出人；
- 更改人：需求文檔變更人；
- 批准人/批准部門。
PRD文檔的編寫是需要萬分聚精會神的細緻的工作，基礎中現功底。
在評審結束後，PRD文檔交接給設計人員、開發人員，如果文檔編寫的足夠紮實，那基本不太會出現返工的情況，研發的過程也會比較順暢。
好的文檔，會讓研發人員覺得靠譜、安心，也會給產品經理帶來一份自信。
特別是某天你躺在牀上驚坐起，感覺自己漏了什麼關鍵內容，趕快打開文檔，發現聚精會神的狀態下自己的邏輯思考很嚴密沒有遺漏的時候，那種快樂你一定也體會過。
時間久了，你會更相信自己的判斷，能更從容的應對來自各方的質疑。
本文由 @RaRa 原創發佈於人人都是產品經理，未經許可，禁止轉載。
題圖來自 Unsplash，基於CC0協議