每一個產品經理都寫過無數的PRD，大到整個系統，小到某一個功能。今天我們來聊聊PRD文檔如何編寫，以及如何寫好一份PRD文檔。
首先，我們用產品的思路來分析一下，PRD文檔的用戶是誰，以及使用場景是什麼。
1、需求方：當需求方提出需求並與產品經理討論後，產品經理開始編寫PRD文檔，編寫完成後，與需求方開會確認PRD文檔中的內容細節。修改確認無誤後，再去跟研發人員進行講解。
2、研發人員（交互設計師、UI設計師、前端工程師、研發、測試）：在與需求方確認並鎖定需求後，將PRD文檔中的需求向研發人員進行講解。讓研發人員明白需求，可以開始進行研發。同時在日後的研發過程中，如果研發人員對細節遺忘或者需要確認，只需打開PRD文檔找到對應內容即可。
從以上兩個最常用的使用場景來看，PRD要具備非常強的可讀性，同時對功能的描述要非常詳細，不能有遺漏（是的，絕對不能漏功能，不然少做一項內容就是產品經理的鍋），最後還要保證專業度。
看起來好像很難，我們來拆解一下，一份完整的PRD都包含哪些內容，請看下圖：
我們一項一項來說：
1、修訂歷史：
在與運營確認需求的時候，總是無法避免修改功能。甚至有時候在給研發講解的時候，由於技術原因有些需求也需要修改。這個時候就產品經理就必須要記錄每一次更新的歷史，同時記錄原因。你可以這麼寫：
2、項目背景：
通常來說這個不是必須寫的，爲了完整性和專業度，建議產品經理還是寫一下，也算是一個記錄。比如“雙11大促，衝刺100億銷售額”之類的。
3、業務描述：
與項目背景一樣，不是必須寫，但依然是建議寫，可以不用寫太多。或者你可以補一張業務流程圖，以抽獎爲例：
4、產品模塊：
依然不是必須要寫，但還是建議寫的內容。主要包含本次項目中的所有模塊，可以不用細到功能點，但建議有功能點的描述。如果是一個跨多個系統的項目，還需要增加屬於哪一個系統這一列，比如一個退換貨流程：
5、功能描述：
這部分是整個PRD的重中之重，必須要寫的很詳細。每一項都要包括一張線框圖和文字解說。如果一張頁面有不同的狀態，要分開解說，以及說明這些狀態是在什麼條件下進行切換。我以登錄框爲例：
這麼一個看上去很簡單的登錄框，要如何寫說明呢？我的原則是，先進行交互元素的描述，然後是規則。你可以這麼寫：
- 手機號輸入框爲文本輸入，能夠輸入最大的長度爲20個字符，如果超過20個字符則不顯示在文本框中；
- 密碼框爲密文密碼輸入，用戶不可見輸入內容。能夠輸入的最大長度爲20個字符，如果超過20個字符則不顯示在密碼框中；
- 出錯信息位只在驗證出錯的時候用於文本提示，平時不用顯示；
- 登錄按鈕，用戶點擊後進入登錄驗證流程：
1、驗證手機號文本框是否爲空，出錯提示爲：請輸入手機號！
2、驗證手機號文本框中輸入內容是否爲合法手機號。驗證規則爲：11個數字。出錯提示爲：輸入的手機號有誤，請從新輸入！
3、驗證密碼框是否爲空，出錯提示位：請輸入密碼！
4、驗證手機號和密碼是否匹配。出錯提示：手機號密碼不正確，請從新輸入！
- 註冊按鈕，用戶點擊後，新打開一頁跳轉到註冊頁。
如果你想寫得更好一點，驗證流程可以補一張流程圖。
至於有一些登錄框是在輸入內容後失去焦點驗證，或者在輸入錯誤3次以上的時候增加驗證碼輸入，大家可以自行腦補如何編寫。
6、數據需求
通常來說，數據需求我們會新啓動一個項目單獨做。但是像活動這樣的PRD，我建議還是補充上數據需求，因爲除了常規的數據監控以外，活動總會有一些特殊的數據需要記錄。這裏的也要寫的很詳細，在什麼頁面記錄哪些事件。
7、人員評估
這裏是一份排期表，一般來說我們會使用單獨的工具（比如project），生成一份排期PDF後，可以附這裏。
8、測試需求
除了功能性的測試，如果有一些特別需要注意的測試內容可以寫在這裏。比如：需要在iOS10、iOS10.1、iOS10.2下進行測試。
9、風險評估
主要寫一些跟項目相關的風險問題，如果沒有就可以不用寫。比如：UI設計師小明身兼三個項目，可能會對項目造成影響；又或者研發小李在10.1之後請了7天年假，可能需要從研發二部臨時抽調人員。
希望對大家編寫PRD有所幫助。