一、前言
最近Mr湯進er在學習PRD的寫作。直接的感觸就是：寫PRD是一個技術活，也是一個細心活。PRD的主要閱覽用戶就是開發工程師，為了能夠和開放人員進行高效的溝通，一份優秀的PRD文檔應該滿足的基本要求包括：完整、準確、清晰、簡潔和穩定。其中”完整"便是指考慮周全沒有遺漏。完整的功能描述和用例，不但可以方便開發工程師快速了解完整的功能需求，同時也為產品上線前的產品測試提供必要的參考。完整的產品功能描述主要包括兩方面：功能點無遺漏和功能描述完整。
為了方便自己項目中進行相關功能點及其描述自查，Mr湯進er整理了一套針對應用開發的產品功能點及其描述自查清單。個人感覺，這個自查清單對于四類人群都是有幫助的：
1、產品經理：可以通過產品功能描述自查清單來系統的梳理產品功能點和描述，PRD可以幫助產品經理更加透徹和完整的梳理產品，同時，產品經理可以通過PRD和其他人員進行高效的溝通。
2、交互設計師：可以通過功能點及其描述自查來檢查自己的交互稿是否遺漏特殊情況、異常情況、極限情況等等
3、開發工程師：可以通過功能點及其描述自查清單來檢查自己的程序開發是否符合PRD中的相關要求。
4、測試工程師：可以將PRD中的功能描述和用例轉化為測試用例的一部分，進行產品可用性測試。
二、原則
在整理自查清單之前，我自己先梳理了幾條自查原則或者叫做邏輯（建議在自查前先用Xmind等軟件梳理下自查邏輯 ）：
1、先總體，再細分：如果拿一棵大樹舉例，應該是按照樹干→樹枝→樹葉的順序去檢查產品功能點，可以結合產品功能架構圖來進行主要功能點的檢查，在主要功能點完整的基礎之上，再深入到主要功能點下的細節功能進行自查。
2、有順序，依次檢查：這個和撰寫PRD中的功能點和描述是一致的，可以依據PRD功能描述撰寫的標準綜合運用以下順序進行自查：
1）產品功能點需求：用戶需求→后臺需求（數據監控等）
2）功能在系統中的位置：前臺界面→用戶管理后臺(個人中心)→官方管理后臺；
3）業務流程：步驟1→步驟2→步驟3→步驟3.1→步驟3.2……
4）功能主次關系：主要功能（場景or流程）→次要功能（場景or流程）；
5）功能點在頁面布局中的位置：從上→下、從左→右；
6）按照軟件狀態：基本狀態→特殊狀態→異常狀態；
3、隨時關注，及時更新：很多遺漏的點不是自查一遍就可以檢查出來的，說不定某個時間，就突然想起了某一個功能點的遺漏。同時PRD作為交流溝通的工具之一，需要跟進交流的結果，因此我們要隨時關注，并做到及時更新。但別忘了PRD的穩定性哦，最好在正式交付其他人員時，完成功能點及其描述的梳理。
三、自查清單
Mr湯進er自己先用Xmind繪制了一張清單導圖，詳細清單列表見下方
1 用戶體驗自查：
這部分主要注意自查功能框架、業務流程和用戶界面布局(如菜單、對話框、窗口和其它可規控件）以及頁面內容描述等等是否完整。
1.1 流程和頁面布局
1.1.1 基本狀態：
1）功能框架和流程的功能點是否完整？特別是注意流程中的主導航常駐or頁面返回，是否是從哪來回哪去？不要出現一個頁面點擊某個BUTTON不知道去哪的問題！可以請交互設計師協同自查；
2）流程描述是否完整？這部分也可以請交互設計師協調完成，比如A→B頁面跳轉是否描述完整（包括交互觸發方式：單擊or長按or滑動；觸發區域：整條Button or Button的某個區域；觸發前中后狀態：加載時間、動效、中間狀態等等）；再比如是否有不可點擊的效果，如：你的按鈕此時處于不可用狀態，那么一定要灰掉，或者拿掉按鈕，否則會給用戶誤導；
3）頁面布局是否完整？比如頁面標題欄、導航欄等否缺失？頁面反饋（彈窗or加載狀態進度提示等）是否缺失；
1.1.2 特殊和異常狀態：
1）特殊流程是否缺失？比如登陸流程中是否缺失忘記登陸密碼的流程；啟動頁和用戶引導頁等；
2）頁面布局是否考慮橫豎屏問題？
3）頁面布局是否考慮不同屏幕尺寸自適應問題？
4）不同模式下頁面情況說明：夜間模式？編輯模式？無圖模式？等
1.2 ?內容自查
1.2.1 基本狀態：
1）描述內容是靜態or動態數據調用？如靜態的標題title，動態的文本內容調用等；
2）內容描述是否完整？頂部標題、按鈕里的文字等；文本是否錯誤等；
3）內容加載方式描述是否完整？本地緩存or刷新加載網絡新內容等；
4）輸入框內容描述是否完整？是否有初始內容？輸入后是否有聯系功能（比如搜索）；
1.2.2 特殊和異常狀態：
考慮等價、邊界、負面、異常或非法等情況
1）數據內容為空如何處理？是否支持離線功能？是否有空數據界面設計，引導用戶去執行操作；
2）內容長度是否有限制？比如內容展示是否限制字數，點擊查看更多？昵稱描述不得超出多少字？密碼不得低于多少字符等等；
3）內容違禁如何處理？敏感詞、違禁內容（如：涉及版權、專利、隱私等圖片)等如何處理；
4）數據內容過期or刪除or違禁后如何展示？比如某內容發布后因為違禁被編輯刪除，那么用戶再次點擊后怎么展示等；
5）用戶內容輸入是否描述完整？比如輸入框輸入空格、特殊字符如何處理？用戶輸入是否保留歷史記錄？等等；
2 ?賬號狀態及用戶權限自查
用戶注冊和賬號管理功能都會涉及到用戶不同登陸狀態（登陸、非登陸、賬號異常、賬號被凍結等）和用戶等級和權限（會員和非會員、付費和非付費用戶等），因此要說明清楚不同賬號狀態及用戶權限下顯示的內容和功能。
2.1.1 基本狀態：
1）不同賬號狀態說明：登陸狀態、非登陸狀態不同情況是否說明完整？
2）不同用戶等級和權限說明：不同等級用戶有哪些權限？在頁面展示上有什么不同？
3）不同賬號狀態切換時是否有特殊展示？
2.1.2 特殊和異常狀態：
1）是否說明清楚一個賬號多終端登陸問題？是否允許多終端登陸同一賬號？一般根據MTOP的現有規則，一個帳戶只允許登錄一臺機器。檢查一個帳戶登錄多臺手機時，原手機里的用戶需要被踢出，是否給予用戶友好提示？
2）是否考慮了多賬號切換問題？是否保留歷史賬號？
3）是否支持第三方賬號登陸？登陸后如何綁定自有賬號？
3? 硬件環境需求自查：
不同的終端水平涉及到包括硬件特性、網絡狀態等情況，需要在PRD中考慮清晰。
3.1 ?硬件特性需求說明
1）橫豎屏是否需要鎖屏？
2）不同分辨率是否要適配？如何適配？
3）是否調用手機物理按鍵？什么情況下調用？如何調用？
4）SD卡問題，文件導入本地時，沒有SD卡、SD卡儲存已滿、儲存位置等情況是否考慮并備注？
3.2 網絡狀態說明
1) 無網絡時，顯示什么內容？執行需要網絡的操作，是否給予用戶友好提示？
2) 在網絡信號不好時，有無超時限制？是否說明了如何給予用戶反饋？是否引導用戶執行其他操作或退出?
3）緩存問題如何處理？什么情況下調用緩存？
3.3 服務器宕機或出現404、502等情況說明
后臺服務牽涉到DNS、空間服務商的情況下會影響其穩定性，如：當出現域名解析故障時，你對后臺API的請求很可能就會出現404錯誤，拋出異常。如何處理這些異常？
4 ?后臺交互及管理需求自查
后臺交互和管理需求涉及到消息推送、數據更新方式、軟件權限和后臺監管等方面的需求。
4.1 ?PUSH消息說明
是否說明必要的push消息業務規則？什么情況需要push消息?push什么內容等等?
4.2 ?數據更新說明
1）需要說明哪些地方需要用戶手動刷新？哪些地方需要自動刷新？哪些地方是手動+自動刷新？
2) 說明哪些地方從后臺切換回前臺時需要進行數據更新？
3) 需要說明哪些內容需要實時更新，哪些需要定時更新？
4) 說明數據展示部分的處理邏輯，是每次從服務端請求，還是有緩存到本地？
4.3? 軟件權限及安全性：
1）軟件權限說明是否完整？什么功能，在什么情況下，需要調用什么樣的權限？位置or通訊錄or聯網or照片等等
2）數據安全性說明是否完整？輸人的密碼將不以明文形式進行顯示，備份應該加密, 恢復數據應考慮恢復過程的異常通訊中斷等
3）交叉事件安全性說明是否完整？在運行其軟件過程中, 如果有來電、SMS、EMS、MMS、藍牙、紅外等通訊或充電時, 是否能暫停程序，優先處理通信, 并在處理完畢后能正常恢復軟件, 繼續其原來的功能
4.4 后臺數據監控及管理需求：
1）后臺有哪些數據檢測點？需要監控哪些數據？
2）后臺有哪些功能點，為前端提供哪些數據內容？敏感詞、違禁內容如何屏蔽？等等
3）如何進行內容推薦和排序等等
四、結語
PRD寫作是一個細心的活，確保內容描述的完整性，有利于產品經理自己梳理產品本身，同時也有利于團隊合作與溝通。產品功能點及其描述自查是為了保證內容描述的完整性。當然Mr湯進er整理的這套自查清單肯定是不夠完整的，也不是普適的。重要的是，大家需要有這樣的意識、細心和一定的標準去做自查。雖然看似增加了工作量，但Mr湯進er認為，事實上這樣會大大減少時間成本，特別是在大團隊多人或異地協調工作的情況下。歡迎大家針對“PRD”與@Mr湯進er交流討論（微信公共號：chuangshe_space，個人博客：www.tangjinweb.com,知乎or簡書or微博：@Mr湯進er），共同進步。
本文為原創，允許轉載，但請注明作者信息和出處：
作者：Mr湯進er , 微信公共號“創設空間”：chuangshe_space
并附帶本文簡書鏈接：http://www.lxweimin.com/p/a42c42e0ce09
