一、前言

　　最近Mr湯進er在學習PRD的寫作。直接的感觸就是：寫PRD是一個技術活，也是一個細心活。PRD的主要閱覽用戶就是開發(fā)工程師，為了能夠和開放人員進行高效的溝通，一份優(yōu)秀的PRD文檔應該滿足的基本要求包括：完整、準確、清晰、簡潔和穩(wěn)定。其中”完整"便是指考慮周全沒有遺漏。完整的功能描述和用例，不但可以方便開發(fā)工程師快速了解完整的功能需求，同時也為產(chǎn)品上線前的產(chǎn)品測試提供必要的參考。完整的產(chǎn)品功能描述主要包括兩方面：功能點無遺漏和功能描述完整。

　　為了方便自己項目中進行相關功能點及其描述自查，Mr湯進er整理了一套針對應用開發(fā)的產(chǎn)品功能點及其描述自查清單。個人感覺，這個自查清單對于四類人群都是有幫助的：

　　1、產(chǎn)品經(jīng)理：可以通過產(chǎn)品功能描述自查清單來系統(tǒng)的梳理產(chǎn)品功能點和描述，PRD可以幫助產(chǎn)品經(jīng)理更加透徹和完整的梳理產(chǎn)品，同時，產(chǎn)品經(jīng)理可以通過PRD和其他人員進行高效的溝通。

　　2、交互設計師：可以通過功能點及其描述自查來檢查自己的交互稿是否遺漏特殊情況、異常情況、極限情況等等

　　3、開發(fā)工程師：可以通過功能點及其描述自查清單來檢查自己的程序開發(fā)是否符合PRD中的相關要求。

　　4、測試工程師：可以將PRD中的功能描述和用例轉(zhuǎn)化為測試用例的一部分，進行產(chǎn)品可用性測試。

　　二、原則

　　在整理自查清單之前，我自己先梳理了幾條自查原則或者叫做邏輯(建議在自查前先用Xmind等軟件梳理下自查邏輯 )：

　　1、先總體，再細分：如果拿一棵大樹舉例，應該是按照樹干→樹枝→樹葉的順序去檢查產(chǎn)品功能點，可以結合產(chǎn)品功能架構圖來進行主要功能點的檢查，在主要功能點完整的基礎之上，再深入到主要功能點下的細節(jié)功能進行自查。

　　2、有順序，依次檢查：這個和撰寫PRD中的功能點和描述是一致的，可以依據(jù)PRD功能描述撰寫的標準綜合運用以下順序進行自查：

　　1)產(chǎn)品功能點需求：用戶需求→后臺需求(數(shù)據(jù)監(jiān)控等)

　　2)功能在系統(tǒng)中的位置：前臺界面→用戶管理后臺(個人中心)→官方管理后臺;

　　3)業(yè)務流程：步驟1→步驟2→步驟3→步驟3.1→步驟3.2……

　　4)功能主次關系：主要功能(場景or流程)→次要功能(場景or流程);

　　5)功能點在頁面布局中的位置：從上→下、從左→右;

　　6)按照軟件狀態(tài)：基本狀態(tài)→特殊狀態(tài)→異常狀態(tài);

　　3、隨時關注，及時更新：很多遺漏的點不是自查一遍就可以檢查出來的，說不定某個時間，就突然想起了某一個功能點的遺漏。同時PRD作為交流溝通的工具之一，需要跟進交流的結果，因此我們要隨時關注，并做到及時更新。但別忘了PRD的穩(wěn)定性哦，最好在正式交付其他人員時，完成功能點及其描述的梳理。

　　三、自查清單

　　Mr湯進er自己先用Xmind繪制了一張清單導圖，詳細清單列表見下方

　　PRD中產(chǎn)品功能點及其描述自查清單，繪制@Mr湯進er

　　1 用戶體驗自查：

　　這部分主要注意自查功能框架、業(yè)務流程和用戶界面布局(如菜單、對話框、窗口和其它可規(guī)控件)以及頁面內(nèi)容描述等等是否完整。

　　1.1 流程和頁面布局

　　1.1.1 基本狀態(tài)：

　　1)功能框架和流程的功能點是否完整?特別是注意流程中的主導航常駐or頁面返回，是否是從哪來回哪去?不要出現(xiàn)一個頁面點擊某個BUTTON不知道去哪的問題!可以請交互設計師協(xié)同自查;

　　2)流程描述是否完整?這部分也可以請交互設計師協(xié)調(diào)完成，比如A→B頁面跳轉(zhuǎn)是否描述完整(包括交互觸發(fā)方式：單擊or長按or滑動;觸發(fā)區(qū)域：整條Button or Button的某個區(qū)域;觸發(fā)前中后狀態(tài)：加載時間、動效、中間狀態(tài)等等);再比如是否有不可點擊的效果，如：你的按鈕此時處于不可用狀態(tài)，那么一定要灰掉，或者拿掉按鈕，否則會給用戶誤導;

　　3)頁面布局是否完整?比如頁面標題欄、導航欄等否缺失?頁面反饋(彈窗or加載狀態(tài)進度提示等)是否缺失;

　　1.1.2 特殊和異常狀態(tài)：

　　1)特殊流程是否缺失?比如登陸流程中是否缺失忘記登陸密碼的流程;啟動頁和用戶引導頁等;

　　2)頁面布局是否考慮橫豎屏問題?

　　3)頁面布局是否考慮不同屏幕尺寸自適應問題?

　　4)不同模式下頁面情況說明：夜間模式?編輯模式?無圖模式?等

　　1.2 內(nèi)容自查

　　1.2.1 基本狀態(tài)：

　　1)描述內(nèi)容是靜態(tài)or動態(tài)數(shù)據(jù)調(diào)用?如靜態(tài)的標題title，動態(tài)的文本內(nèi)容調(diào)用等;

　　2)內(nèi)容描述是否完整?頂部標題、按鈕里的文字等;文本是否錯誤等;

　　3)內(nèi)容加載方式描述是否完整?本地緩存or刷新加載網(wǎng)絡新內(nèi)容等;

　　4)輸入框內(nèi)容描述是否完整?是否有初始內(nèi)容?輸入后是否有聯(lián)系功能(比如搜索);

　　1.2.2 特殊和異常狀態(tài)：

　　考慮等價、邊界、負面、異常或非法等情況

　　1)數(shù)據(jù)內(nèi)容為空如何處理?是否支持離線功能?是否有空數(shù)據(jù)界面設計，引導用戶去執(zhí)行操作;

　　2)內(nèi)容長度是否有限制?比如內(nèi)容展示是否限制字數(shù)，點擊查看更多?昵稱描述不得超出多少字?密碼不得低于多少字符等等;

　　3)內(nèi)容違禁如何處理?敏感詞、違禁內(nèi)容(如：涉及版權、專利、隱私等圖片)等如何處理;

　　4)數(shù)據(jù)內(nèi)容過期or刪除or違禁后如何展示?比如某內(nèi)容發(fā)布后因為違禁被編輯刪除，那么用戶再次點擊后怎么展示等;

　　5)用戶內(nèi)容輸入是否描述完整?比如輸入框輸入空格、特殊字符如何處理?用戶輸入是否保留歷史記錄?等等;

　　2 賬號狀態(tài)及用戶權限自查

　　用戶注冊和賬號管理功能都會涉及到用戶不同登陸狀態(tài)(登陸、非登陸、賬號異常、賬號被凍結等)和用戶等級和權限(會員和非會員、付費和非付費用戶等)，因此要說明清楚不同賬號狀態(tài)及用戶權限下顯示的內(nèi)容和功能。

　　2.1.1 基本狀態(tài)：

　　1)不同賬號狀態(tài)說明：登陸狀態(tài)、非登陸狀態(tài)不同情況是否說明完整?

　　2)不同用戶等級和權限說明：不同等級用戶有哪些權限?在頁面展示上有什么不同?

　　3)不同賬號狀態(tài)切換時是否有特殊展示?

　　2.1.2 特殊和異常狀態(tài)：

　　1)是否說明清楚一個賬號多終端登陸問題?是否允許多終端登陸同一賬號?一般根據(jù)MTOP的現(xiàn)有規(guī)則，一個帳戶只允許登錄一臺機器。檢查一個帳戶登錄多臺手機時，原手機里的用戶需要被踢出，是否給予用戶友好提示?

　　2)是否考慮了多賬號切換問題?是否保留歷史賬號?

　　3)是否支持第三方賬號登陸?登陸后如何綁定自有賬號?

　　3 硬件環(huán)境需求自查：

　　不同的終端水平涉及到包括硬件特性、網(wǎng)絡狀態(tài)等情況，需要在PRD中考慮清晰。

　　3.1 硬件特性需求說明

　　1)橫豎屏是否需要鎖屏?

　　2)不同分辨率是否要適配?如何適配?

　　3)是否調(diào)用手機物理按鍵?什么情況下調(diào)用?如何調(diào)用?

　　4)SD卡問題，文件導入本地時，沒有SD卡、SD卡儲存已滿、儲存位置等情況是否考慮并備注?

　　3.2 網(wǎng)絡狀態(tài)說明

　　1) 無網(wǎng)絡時，顯示什么內(nèi)容?執(zhí)行需要網(wǎng)絡的操作，是否給予用戶友好提示?

　　2) 在網(wǎng)絡信號不好時，有無超時限制?是否說明了如何給予用戶反饋?是否引導用戶執(zhí)行其他操作或退出?

　　3)緩存問題如何處理?什么情況下調(diào)用緩存?

　　3.3 服務器宕機或出現(xiàn)404、502等情況說明

　　后臺服務牽涉到DNS、空間服務商的情況下會影響其穩(wěn)定性，如：當出現(xiàn)域名解析故障時，你對后臺API的請求很可能就會出現(xiàn)404錯誤，拋出異常。如何處理這些異常?

　　4 后臺交互及管理需求自查

　　后臺交互和管理需求涉及到消息推送、數(shù)據(jù)更新方式、軟件權限和后臺監(jiān)管等方面的需求。

　　4.1 PUSH消息說明

　　是否說明必要的push消息業(yè)務規(guī)則?什么情況需要push消息?push什么內(nèi)容等等

　　4.2 數(shù)據(jù)更新說明

　　1)需要說明哪些地方需要用戶手動刷新?哪些地方需要自動刷新?哪些地方是手動+自動刷新?

　　2) 說明哪些地方從后臺切換回前臺時需要進行數(shù)據(jù)更新?

　　3) 需要說明哪些內(nèi)容需要實時更新，哪些需要定時更新?

　　4) 說明數(shù)據(jù)展示部分的處理邏輯，是每次從服務端請求，還是有緩存到本地?

　　4.3 軟件權限及安全性：

　　1)軟件權限說明是否完整?什么功能，在什么情況下，需要調(diào)用什么樣的權限?位置or通訊錄or聯(lián)網(wǎng)or照片等等

　　2)數(shù)據(jù)安全性說明是否完整?輸人的密碼將不以明文形式進行顯示，備份應該加密, 恢復數(shù)據(jù)應考慮恢復過程的異常通訊中斷等

　　3)交叉事件安全性說明是否完整?在運行其軟件過程中, 如果有來電、SMS、EMS、MMS、藍牙、紅外等通訊或充電時, 是否能暫停程序，優(yōu)先處理通信, 并在處理完畢后能正常恢復軟件, 繼續(xù)其原來的功能

　　4.4 后臺數(shù)據(jù)監(jiān)控及管理需求：

　　1)后臺有哪些數(shù)據(jù)檢測點?需要監(jiān)控哪些數(shù)據(jù)?

　　2)后臺有哪些功能點，為前端提供哪些數(shù)據(jù)內(nèi)容?敏感詞、違禁內(nèi)容如何屏蔽?等等

　　3)如何進行內(nèi)容推薦和排序等等

　　四、結語

　　PRD寫作是一個細心的活，確保內(nèi)容描述的完整性，有利于產(chǎn)品經(jīng)理自己梳理產(chǎn)品本身，同時也有利于團隊合作與溝通。產(chǎn)品功能點及其描述自查是為了保證內(nèi)容描述的完整性。當然Mr湯進er整理的這套自查清單肯定是不夠完整的，也不是普適的。重要的是，大家需要有這樣的意識、細心和一定的標準去做自查。雖然看似增加了工作量，但Mr湯進er認為，事實上這樣會大大減少時間成本，特別是在大團隊多人或異地協(xié)調(diào)工作的情況下。歡迎大家針對“PRD”與@Mr湯進er交流討論(微信公共號：chuangshe_space，個人博客：www.tangjinweb.com,知乎or簡書or微博：@Mr湯進er)，共同進步。

　　本文為原創(chuàng)，允許轉(zhuǎn)載，但請注明作者信息和出處：

　　作者：Mr湯進er , 微信公共號“創(chuàng)設空間”：chuangshe_space

晉城龍鼎 - 晉城網(wǎng)站建設為您解答！