最全的PRD寫作要點（附案例）

PRD，產品需求文檔。世界上沒有兩片相同的樹葉，也沒有不做修改的需求文檔，需求文檔不是在去修改的路上就是正在修改ing，開發看到我這言論估計會幹死我，其實大家沒有必要總是想著一版搞定需求文檔，那基本是不可能的，開發也會寫出bug，測試也會遺漏用例。

為什麼產品的需求文檔就不能有錯誤呢？

之所以需求文檔的修改會引起開發和測試的極大反感，主要是產品經理的需求文檔處在一個產品開發的源頭，一開始源頭就出現了問題，後面的流程能順利實現目標嗎？可想而知源頭出現了錯誤，會對後面加班工作的開發兄弟造成多大的打擊。所以，作為產品經理的我們必須儘可能地將PRD整理的詳細易懂，不要遺漏，不要誤解，不用意淫。

前段時間同樣是在某社區上看到一篇關於如何撰寫PRD的文章，寫的很好但是個人覺得還不是很全面，以下PRD寫作要點都是個人躺過的坑，被開發被測試屌過的路，希望可以給大家一個參考，幫助大家更好的完成產品需求文檔，不免有遺漏，大家可以留言補充。

一、需求點的基本描述維度

角色

往往一個按鈕一個界面，不同的角色所能進行的操作，所能看到的內容都不盡相同。

例如一個組團參加活動的需求，其中角色可分為隊長、成員、非團隊成員、組織者，隊長可以做什麼？隊長在界面上可以看到什麼？成員又可以做什麼？成員又可以看到什麼……這些都需要界限清楚，這是一個需求點的「定位」，「定位」偏了，也許後面寫了烏壓壓的一片，到頭來全白搭。

二、需求中常見但又容易遺漏、描述不全的9大類型需求點

1、退出機制

退出分為4類：退出登錄、退至後台運行、殺死程序、關機；特別是數據型的產品，當發生這4類退出時分別對應的數據同步、數據中斷都該如何進行，你可以簡單處理一視同仁，但是必須了解有這幾類，不認測試問起就懵逼了。

2、顯示機制

顯示其實可以按照正常/異常來分類，也可以按照靜態/動態來分類；我這裡按照靜態和動態進行分類，一個界面或一個按鈕的展示必須從兩方面來描述，靜態：展示形態、內容、格式、數量等，動態：初始狀態的展示、觸發時的狀態的展示、觸發後的狀態的展示、觸發成功/失敗的展示等。

例如微信底部的四個按鈕，分為兩種靜態顯示：選中時填充色為綠色，未選中時無填充色；但是介於選中和未被選中之間是什麼顏色呢？這個可以定義為一個過程色，我們可以在微信一級界面左右滑動頁面觀察底部按鈕的變化，當即將被選中時，按鈕是從輪廓慢慢變綠並且綠色逐漸加深，然後是慢慢填充綠色；當即將被取消選中時，則按鈕顏色變化正好相反。

3、排序機制

凡是涉及到列表、記錄的均需要考慮排序，不管是按照生成時間倒序還是正序，至少需要確定一個順序，而不是讓開發進行到這個頁面時再來問你，你這個時候其實就是失去了主動權，因為是你的遺漏，另外在倉促之下做出的決定很容易導致體驗不好或者其他考慮不周的問題。

4、刷新機制

如果頁面展示的內容是隨著時間不斷變化的，則必然要考慮到刷新，其中刷新就涉及到一般的刷新前，刷新後，刷新中的展示了，也會有異常刷新失敗的考慮，另外也需要考慮是自動刷新還是手動刷新。

5、載入機制

其實載入機制和刷新機制經常在一塊，有刷新一般會有載入。

6、緩存機制

有人覺得像這種偏點技術的需求應該由開發來決定，這裡就不做爭論了，但是作為一個產品也必須了解，為什麼要做緩存？做緩存會帶來什麼影響？做緩存大多時候是為了讓用戶體驗更流暢，不至於讓用戶長期停留在一處等待轉菊花，如果緩存反而讓系統頻繁卡機，這時就得重新考慮考慮了。

（右擊在新標籤頁中打開，即可查看大圖）

7、推送機制

目前推送越來越多，主要是想增加用戶的粘性，調動用戶使用APP的積極性，所有推送不能太多導致用戶反感，也不能過少造成用戶的遺忘，這些都是產品經理在撰寫需求文檔之外需要考慮的；需求文檔中對推送的描述必須含一下四個方面：觸發推送的時機，推送內容，推送對象，點擊推送後的跳轉；部分推送還具有時效性，時機一過，也許本該跳轉的目的頁面已不存在了，這個時候就地具體問題具體分析了。

8、中斷機制

也許大部分產品只會考慮到網路中斷的情況，那是因為在大部分的場景和頁面中只考慮網路中斷的情況即可，但是不同的業務不同的頁面則可能對應不同的中斷機制

其中這裡總結了4中類型的中斷：退出登錄、來電話、程序進入後台運行、網路中斷；列如在APP中視頻通話時，突然有電話撥入時，是直接中斷視頻？還是視頻不中斷但是跳出APP進入接聽電話界面？…也許考慮的不對或者不合邏輯，但是有這種疑惑時必須提出來可以和開發討論，否則遺漏了就又懵逼了。

9、刪除機制

主要是注意下是物理刪除還是邏輯刪除；物理刪除：直接從資料庫層面徹底刪除，刪除的數據無法找回；邏輯刪除：僅僅是邏輯和界面展示上刪除，資料庫中還存有該數據，必要時可以恢復。

三、控制項的具體描述

其實在上面的九大機制中或多或少已經涉及到了具體一個控制項該如何描述，以下腦圖也很簡單，就不多贅述了。

四、千思萬慮

1、異常操作

腦圖中之所有沒有展示，就是因為異常操作是無法預知的，只能盡量匯總全，像測試那種變態的一個按鈕非要以掩耳盜鈴之勢連擊兩下三下……這種也屬於異常操作，進入頁面的瞬間點擊返回，這也算異常操作，有時候開發也討厭測試也是有道理的。

2、網路情況

估計說到網路情況，很多人想到了有網路的情況和沒有網路的情況，但是現在的網路按照網路速度可分為2G/3G/4G三種類型啊，另外還分為wifi和非wifi的情況，考慮到用戶體驗，不同的界面也許在不同的網路類型下就該展示不同的內容或不同的提示；

像今日頭條APP中，當你在非wifi情況下觀看視頻時是可以直接觀看的，但是當你在非wif的情況下查看視頻時，系統就會提示你播放該視頻需要耗費多少流量，你可以選擇繼續觀看還是返回，或者其他服務。

3、賬號相關

如果一個需求需要考慮與賬號的關聯性，則可以問4個問題：登錄情況下是什麼情況？非登錄情況下是什麼情況？換手機後登錄又會有什麼情況？登錄手機端時是否與PC端互斥？

我之所以會將這個點列出來，主要是之前在我做的一個運動健康的需求中有涉及，特別是換手機登錄這種情況下運動等時時變化的數據同步的問題很頭痛，最後我們是忽略了這種場景，但是作為一個產品經理你必須知道你的文檔涉及到哪些內容，哪些場景，同時你還必須知道哪些場景哪些情況是可以不用過多考慮的，綜合開發成本、時間周期以及用戶的使用頻率考慮。

4、數據相關

數據的正常和異常展示的考慮就不多說了，數據何時同步？何時刷新？不同階段的數據存儲在那個端：服務端、客戶端？這些看起來都是很技術的問題，但是產品也必須了解，其實產品在這些需求方面可以不出任何方案，也沒有出方案的權力，因為對這些需求你多半沒有開發清楚，但是你可以根據開發給出的方案進行選擇，選擇「看上去」較好的方案，因為開發有時候也不知道哪個好哪個壞，所以這個時候這個責任就得你來但起了，誰叫你是產品dog，這個產品的owner呢！

5、版本相關

主要考慮版本升級後遺留老數據是否會收到影響，該如何做遷移，該如何取捨的問題。

6、平台相關

對那些大公司來說可能一個平台N個產品經理，但是對初創型公司來講很多時候一個產品經理負責的需求會涉及到N個平台，所以這個時候就的對每個平台都進行考慮啦，做到一套代碼可以試用於多個平台。

其他部分可能遇到的比較少，但是基於PRD考慮的越全面越好的格調，了解下也是不錯的，如果需要完整的腦圖或者有補充的可以給我留言。

歲月是把豬飼料，但是我們可以選擇有營養的吃，不然怎麼去尋找風口，練習飛翔！