本文作者通過回顧自己6年前編寫的音頻類知識付費App的PRD，總結(jié)了新人產(chǎn)品經(jīng)理在需求文檔編寫中常見的四個問題：過度描述樣式與交互、缺少數(shù)據(jù)取值來源說明、缺乏常規(guī)邏輯規(guī)則說明以及忽略后臺功能。

2018年6月6日我寫下了人生中第一份需求文檔

那時大學(xué)畢業(yè)考研考的中山大學(xué)交互設(shè)計沒考上不知道要去干啥，就去干了產(chǎn)品經(jīng)理

給爹媽要了1萬塊，進了個培訓(xùn)機構(gòu)最終做了個虛擬項目——一個叫「深刻」的音頻類知識付費App

（圖片為AI生成）輸出了這個需求文檔：PRD地址：https://4z0hpd.axshare.com

那時候我覺得寫的可好了，必須要給面試官看?，F(xiàn)在一看真是老臉一紅，寫的是個什么逼玩意

在6年半后的今天，我直接這個需求文檔做個復(fù)盤。

一、關(guān)于這個產(chǎn)品

在培訓(xùn)機構(gòu)的小組里，要確定個產(chǎn)品方向，我們組選了個「知識付費」方向。

我就弄了個一款音頻類知識付費App，起了個名字叫深刻。?

這個產(chǎn)品主要定位在通過音頻+圖片傳播泛生活類知識在線知識付費平臺。

對于產(chǎn)品slogan、項目背景、產(chǎn)品目標、產(chǎn)品定位、目標用戶，以及整個PRD的需求描述。

我都是抄的。

培訓(xùn)機構(gòu)會給一些之前學(xué)員的PRD文檔，所以就抄別人寫的。

項目背景、產(chǎn)品目標、產(chǎn)品定位、目標用戶，這4個內(nèi)容從艾瑞咨詢報告里抄的。

目標用戶中的內(nèi)容，我看別人寫22到32歲，然后我直接抄了。

我現(xiàn)在就納悶，21歲的用戶就不能用了嗎?？

做到这三点挑战，产品经理只会不断升值

好的产品经理是很稀缺的，懂用户、懂商业、懂数据的产品经理走出互联网，依然是抢手货。相反，如果只做简单传话、低效执行、浅层思考的产品经理，恐怕走不过未来3-5年的洪流。

查看详情 >

不知道當時咋想的，而且這種寫法完全沒有必要。

這篇文章我們只說需求文檔的書寫，產(chǎn)品背景、目標、定位先不探究。

二、PRD的主要問題

我仔細看了之前的PRD，有幾個主要問題：

1、僅關(guān)注表面，過度描述樣式與交互

這是個不懂技術(shù)的產(chǎn)品經(jīng)理通病。會使用大量的文字描述交互與UI樣式，甚至是過度描述常規(guī)組件的交互動態(tài)效果。如下圖：

對于PRD中的交互描述

我的建議是常規(guī)交互就正常描述，沒有特殊邏輯時，不用詳盡的描述。

對于PRD 中對頁面樣式的描述，比如超長截斷展示為「…」，超出換行等，當有UI設(shè)計時介入時，我的PRD中都不寫了,但是對于沒有UI時，還是會寫一下。

2、缺少數(shù)據(jù)取值來源說明

這也是非技術(shù)背景產(chǎn)品經(jīng)理的常見問題：只關(guān)注前端頁面，忽略后端取值與邏輯。

在頁面上展示的信息，通常是調(diào)用接口，接口給出的具體數(shù)據(jù)后，然后展示到頁面上的。

在頁面中的信息的取值，就需要給出對應(yīng)的接口，取出對應(yīng)的數(shù)據(jù)。

在下圖中的PRD描述中，都缺乏取值說明：

• Banner來自哪？
• 今日推薦數(shù)據(jù)來自哪？

3、缺乏常規(guī)的邏輯規(guī)則說明

這一點是在剛寫需求文檔時都會存在的問題，很容易漏邏輯，如忽略排序、極值、不同狀態(tài)的處理等等。

漏邏輯描述是個很正常的現(xiàn)象，但是常規(guī)的邏輯不能丟。

比如：

• 列表中的默認排序是什么？
• 收聽記錄為空怎么處理？
• 詳情頁中不同狀態(tài)怎么展示？

我之前問我領(lǐng)導(dǎo)，說總是想不全，領(lǐng)導(dǎo)說：你把喬布斯，張小龍，俞軍都叫來，他們也都想不全。

產(chǎn)品經(jīng)理永遠不可能全部考慮到，研發(fā)永遠不可能寫不出bug，測試永遠不可能覆蓋全部測試點。

我們寫PRD的時候，就是盡可能的想全，不斷的積累，這次研發(fā)測試指出來了，就長個記性，下次加上就行了。

4、只考慮App，沒有想到后臺

對于任何一款產(chǎn)品，當有用戶端使用的產(chǎn)品時，就需要有一個后臺。

比如上傳圖文信息，人工需要判斷圖文信息是否合規(guī)，則需要一個審核后臺；

當有用戶惡意操作時，需要對用戶進行封禁，可能需要一個用戶管理后臺；

后臺很大的體系，是另外一整套功能模塊。

還有一點，有一些公共服務(wù)很復(fù)雜，且很多系統(tǒng)都能使用時，則會單獨抽出來，作為一個公共服務(wù)，比如支付中心，用戶中心。

當時的我并不知道這一套東西，當入職第一家公司后，領(lǐng)導(dǎo)給了我后臺賬號后，我才知道原來有 「后臺」這個玩意。

三、重寫PRD

知道問題了，那我們就重新寫下PRD。

首先在PRD的結(jié)構(gòu)劃分上之前的PRD內(nèi)容中仍缺乏一些內(nèi)容，如：非功能需求：性能、安全、埋點。

簡單來說，就把PRD結(jié)構(gòu)當成個左側(cè)菜單，我們需要做的是進行結(jié)構(gòu)劃分，進行分類。

我一般按照功能模塊劃分、按照需求點劃分，從大模塊到小功能依次展示。

接著我挑出「首頁」我們看下：

1、Banner的描述修改

先分析下：Banner作為首頁中的推薦位，最簡單的是需要運營在后臺進行配置，在用戶端則展示出來。

（復(fù)雜的則可以是個性化推薦、根據(jù)用戶群體進行分類展示等）。

在原始描述中，寫到了停留時間、輪播時間，也是服了。

這些不需要寫。

對于Banner一定會是在后臺進行配置的，運營人員上傳Banner圖片，配置對應(yīng)的跳轉(zhuǎn)地址、有效期、有效狀態(tài)等等。

描述則需要補充取值來源說明，根據(jù)后臺的配置項，來確定用戶端的展示方式。

Banner會涉及到有效期、是否停用的狀態(tài)，所以補充描述「僅展示生效中的banner」。

最終如下：

2、今日推薦的描述修改

在下圖中的描述，第5點和第6點中，把字符數(shù)量要求給寫上了，沒必要，不用寫。

還有截斷展示出…如果有UI設(shè)計師，PRD中不用寫對樣式的要求。

上圖第7點中還有錯別字，超過用1w+表示，應(yīng)該是用「1k+」表示。

對于專欄內(nèi)容，也都是通過后臺上傳的，后臺上傳時要求配置專欄的標簽，則頁面可以展示出對應(yīng)的標簽。

重新調(diào)整后：

3、「加入專欄」的描述修改

在下圖的第12/15的描述中，又寫了沒必要的樣式說明，對于第14點，價格會有免費的情況，缺少了免費的狀態(tài)說明，另外缺少了「XX人加入」的邏輯說明。

重新寫后：

最終內(nèi)容為：

四、總結(jié)

對于我來說，幫我提升產(chǎn)品能力的，其實是研發(fā)。

PRD寫的不行我認，認了我就改，改了下次我就不再犯。

當挨懟挨的多了，慢慢的就寫的好了。

文章內(nèi)提到的修改功能描述，在寫描述前，還有一件更重要的事——要不要做這個功能。

當定位成MVP，也就是最小可行產(chǎn)品，

就是盡量以最小的成本和最短的時間推出具備基本功能的產(chǎn)品，以驗證產(chǎn)品的可行性、吸引用戶并收集反饋。

所以，在MVP中，有很多可以砍掉的功能，比如支付、搜索、統(tǒng)計等等。把握產(chǎn)品走向，引領(lǐng)產(chǎn)品，才是對產(chǎn)品經(jīng)理的主要能力。