文章未作者所總記得需求文檔要點Checklist， 希望能夠給你的產品工作帶來説明。
本文中的每個check點， 都是我曾經踩過、躺過、摔過……的坑。
姑且不提PRD在項目進展中的重要性， PRD本身就是產品經理的一張名片， 漏洞百出的作品絕對會降低你在團隊中的信譽度， 影響後續工作的進行。
PRD在一個團隊中存在的意義， 在我看來主要是以下3點：
1、降低團隊成員的溝通成本
專案相關人可以直接查文檔解決自己的疑問， 而不是每個人什麼問題都找產品確認。
2、全面的邏輯梳理， 避免遺漏
沒什麼好說的， PRD的內容就是如此
3、資訊存檔， 備查
一個產品通常會經歷好幾任產品經理， 太古老的需求很可能相關人都離職了， 沒有文檔的話基本很難知道之前是怎麼做的。
具體的Checklist如下（文末附思維導圖）：
一、背景目的PRD的必備元素， 整個需求的立足點。 這部分薄弱的PRD， 一般要做好在評審時被小夥伴質疑到懷疑人生準備。 Check點在於， 需求中的每個需求點提出的原因， 論據包括但不限於資料分析、使用者調研、訪談、合作方要求……
二、需求內容1、場景是否覆蓋完全通常一個功能不會只出現在單一頁面上， 最簡單的以淘寶新增打折資訊為例， 如果有新增折扣方式， 那麼所有涉及價格展示的地方都要做相應修改：詳情、購物車、我的最愛、專題、搜索結果……
2、頁面類型選擇——H5 or Narive？1）H5：
不依賴發版變更容易， 每次進入都要載入， 速度慢， 只支援簡單交互。
適合試錯、或一次性頁面，
2）Native：
依賴發版變更困難， 載入速度快， 支援複雜的交互。
適合有複雜操作的頁面， 應用中出現頻率高的基礎頁面， 穩定的功能。
3、頁面資料顯示只要顯示在頁面上的東西， 每個的資料來源都必須明確
1）資料來源
前端寫死 or 本地儲存 or 網路請求如果是本地儲存是否要上報後臺如果是網路請求， 是否需要本地緩存， 從哪個服務獲取後臺可配的話， 前端和後臺各個欄位的對應關係2）沒有資料處理方式
情況一、首次拉取or前端資料被清除
通常需要在邏輯中寫明， 因為首次拉取的邏輯可能和正常邏輯不同
情況二、網路返回資料為空
展示預設資料、不顯示、顯示歷史緩存資料前端是否重複請求，3）資料更新頻率（上傳&拉取）
前端控制固定頻率更新or後端發送通知觸發更新是否有手動刷新機制3、網路異常情況1）無網路回饋
點擊按鈕提示載入失敗頁面， 點擊重試2）wifi和移動網路轉換
音訊、視頻、圖片等， 涉及到使用者流量消費問題， 需要作出提示反應
4、登錄態影響如果需求中有跟使用者帳戶走的資訊， 特別需要注意這一點。
設備未登錄帳號使用者登錄後使用者退出登錄後同一設備切換帳號兩台設備同時登錄一個帳號5、低版本相容性1）系統版本
有些介面特性， 舊的系統版本不支援。 通常產品不需要考慮這個問題， 涉及相關內容， 開發會自己找過來的。
2）應用版本
只要涉及功能優化， 都需要考慮這個問題。
低版本是否直接就支援新改動， 不支援的話是否要做版本隔離用戶從舊版本更新到新版本時， 規則變化如何提示， 是否會引起問題廣告位元是否需要變更新邏輯和其他功能邏輯是否有衝突6、是否有關聯產品/功能改造7、是否需要後臺查詢功能8、安全問題只要涉及錢、評論、帳戶的， 都要慎重考慮這一點。
曾經做一個活動， 發放代金券， 驗證手續少了一道， 於是被盜刷， 又上緊急版本；評論相關的審核過濾， 避免被查水錶。
9、統計不注意就會被漏掉的一塊， 但是因為會佔用開發及測試時間， 制定埋點計畫也需要人力， 如果漏掉， 是很不專業的表現。
寫在最後希望每個產品都能寫出優雅的PRD。
本文由 @ 譚喵 原創發佈于人人都是產品經理。未經許可，禁止轉載。
題圖來自PEXELS，基於CC0協議
本文由 @ 譚喵 原創發佈于人人都是產品經理。未經許可，禁止轉載。
題圖來自PEXELS，基於CC0協議