文章未作者所總記得需求文檔要點Checklist，希望能夠給你的産品工作帶來幫助。

本文中的每個Check點，都是我曾經踩過、躺過、摔過……的坑。雖然不敢保證，有了這份checklist就一切順利（畢竟開發也會寫bug、測試也會漏case的），但至少不會在項目進行的各個階段，被小夥伴問得一臉懵。

姑且不提PRD在項目進展中的重要性，PRD本身就是産品經理的一張名片，漏洞百出的作品絕對會降低你在團隊中的信譽度，影響後續工作的進行。

PRD在一個團隊中存在的意義，在我看來主要是以下3點：

1、降低團隊成員的溝通成本

項目相關人可以直接查文檔解決自己的疑問，而不是每個人什麼問題都找産品确認。

2、全面的邏輯梳理，避免遺漏

沒什麼好說的，PRD的内容就是如此

3、信息存檔，備查

一個産品通常會經曆好幾任産品經理，太古老的需求很可能相關人都離職了，沒有文檔的話基本很難知道之前是怎麼做的。開發編寫代碼需要有注釋，PRD也算是産品的注釋。

具體的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、登錄态影響

如果需求中有跟用戶賬戶走的信息，特别需要注意這一點。

1. 設備未登錄賬号
2. 用戶登錄後
3. 用戶退出登錄後
4. 同一設備切換賬号
5. 兩台設備同時登錄一個賬号

5、低版本兼容性

1）系統版本

有些接口特性，舊的系統版本不支持。通常産品不需要考慮這個問題，涉及相關内容，開發會自己找過來的。

2）應用版本

隻要涉及功能優化，都需要考慮這個問題。

• 低版本是否直接就支持新改動，不支持的話是否要做版本隔離
• 用戶從舊版本更新到新版本時，規則變化如何提示，是否會引起問題
• 廣告位是否需要變更
• 新邏輯和其他功能邏輯是否有沖突

6、是否有關聯産品/功能改造

7、是否需要後台查詢功能

8、安全問題

隻要涉及錢、評論、賬戶的，都要慎重考慮這一點。

曾經做一個活動，發放代金券，驗證手續少了一道，于是被盜刷，又上緊急版本；評論相關的審核過濾，避免被查水表。

9、統計

不注意就會被漏掉的一塊，但是因為會占用開發及測試時間，制定埋點計劃也需要人力，如果漏掉，是很不專業的表現。

寫在最後

希望每個産品都能寫出優雅的PRD。

本文由 @ 譚喵 原創發布于人人都是産品經理。未經許可，禁止轉載。

題圖來自PEXELS，基于CC0協議

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部