產(chǎn)品經(jīng)理告訴你PRD寫作的要點(diǎn)（附案例）

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

為什么產(chǎn)品的需求文檔就不能有錯(cuò)誤呢？

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

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

一、需求點(diǎn)的基本描述維度

角色

往往一個(gè)按鈕一個(gè)界面，不同的角色所能進(jìn)行的操作，所能看到的內(nèi)容都不盡相同。

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

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

1、退出機(jī)制

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

2、顯示機(jī)制

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

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

3、排序機(jī)制

凡是涉及到列表、記錄的均需要考慮排序，不管是按照生成時(shí)間倒序還是正序，至少需要確定一個(gè)順序，而不是讓開發(fā)進(jìn)行到這個(gè)頁面時(shí)再來問你，你這個(gè)時(shí)候其實(shí)就是失去了主動(dòng)權(quán)，因?yàn)槭悄愕倪z漏，另外在倉促之下做出的決定很容易導(dǎo)致體驗(yàn)不好或者其他考慮不周的問題。

4、刷新機(jī)制

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

5、加載機(jī)制

其實(shí)加載機(jī)制和刷新機(jī)制經(jīng)常在一塊，有刷新一般會(huì)有加載。

6、緩存機(jī)制

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

（右擊在新標(biāo)簽頁中打開，即可查看大圖）

7、推送機(jī)制

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

8、中斷機(jī)制

也許大部分產(chǎn)品只會(huì)考慮到網(wǎng)絡(luò)中斷的情況，那是因?yàn)樵诖蟛糠值膱鼍昂晚撁嬷兄豢紤]網(wǎng)絡(luò)中斷的情況即可，但是不同的業(yè)務(wù)不同的頁面則可能對(duì)應(yīng)不同的中斷機(jī)制

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

9、刪除機(jī)制

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

三、控件的具體描述

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

四、千思萬慮

1、異常操作

腦圖中之所有沒有展示，就是因?yàn)楫惓２僮魇菬o法預(yù)知的，只能盡量匯總?cè)駵y試那種變態(tài)的一個(gè)按鈕非要以掩耳盜鈴之勢(shì)連擊兩下三下……這種也屬于異常操作，進(jìn)入頁面的瞬間點(diǎn)擊返回，這也算異常操作，有時(shí)候開發(fā)也討厭測試也是有道理的。

2、網(wǎng)絡(luò)情況

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

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

3、賬號(hào)相關(guān)

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

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

4、數(shù)據(jù)相關(guān)

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

5、版本相關(guān)

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

6、平臺(tái)相關(guān)

對(duì)那些大公司來說可能一個(gè)平臺(tái)N個(gè)產(chǎn)品經(jīng)理，但是對(duì)初創(chuàng)型公司來講很多時(shí)候一個(gè)產(chǎn)品經(jīng)理負(fù)責(zé)的需求會(huì)涉及到N個(gè)平臺(tái)，所以這個(gè)時(shí)候就的對(duì)每個(gè)平臺(tái)都進(jìn)行考慮啦，做到一套代碼可以試用于多個(gè)平臺(tái)。

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

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