本文作者將結合自身經驗與你分享，在整理PRD時，產品經理需要注意的幾方面。enjoy~

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

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

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

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

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

角色

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

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

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

1、退出機制

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

2、顯示機制

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

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

3、排序機制

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

4、刷新機制

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

5、加載機制

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

6、緩存機制

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

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

7、推送機制

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

8、中斷機制

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

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

9、刪除機制

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

三、控件的具體描述

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

四、千思萬慮

1、異常操作

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

2、網絡情況

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

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

3、賬號相關

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

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

4、數(shù)據相關

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

5、版本相關

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

6、平臺相關

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

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

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

作者：安迪(微信公眾號：PM大白)，健康管理產品經理，3年互聯(lián)網產品設計經驗，曾主導患者APP，醫(yī)生APP以及醫(yī)院機構健康管理后臺的設計。

本文由 @安迪 原創(chuàng)發(fā)布于人人都是產品經理。未經許可，禁止轉載。

題圖來自 Pexels，基于 CC0 協(xié)議