【資料圖】

這是Kevin的8月第35篇分享 覺得文章不錯，記得點贊＆在看

產(chǎn)品經(jīng)理有一個必備技能：文檔技能。

輸出的文檔內(nèi)容包含了需求文檔、MRD等等，而需求文檔的撰寫標(biāo)準(zhǔn)，各家公司都有自己的規(guī)范。

所以一個產(chǎn)品經(jīng)理隨著工作時間久了，在不同的公司工作，也會積累不同的標(biāo)準(zhǔn)。對于沒有標(biāo)準(zhǔn)或規(guī)范的團隊或個人來說，找到一個好用的需求文檔模版，也可以提升效率。

下面這份模板時間過去了6年，但仍然是一個非常好用的模板。畢竟需求文檔不能做的很細(xì)，會導(dǎo)致下游產(chǎn)品設(shè)計、開發(fā)閱讀效率降低，反而不能夠理解需求。

我做產(chǎn)品經(jīng)理工作累計8年了，也積累了”標(biāo)準(zhǔn)“的PRD文檔。今天這篇文章分享下這個需求文檔模版，在文章末尾回復(fù)關(guān)鍵詞：“PRD”，可以領(lǐng)取下載。

需求前文檔準(zhǔn)備
需求前我會將文檔設(shè)置為web版式，字體使用微軟雅黑，標(biāo)題分級用默認(rèn)等級，方便進(jìn)行瀏覽和閱讀。

而如果你選擇使用在線文檔，那么就不用設(shè)置。
【W(wǎng)ORD版式】

1.需求概述
需求文檔的第一部分：需求概述

在需求概述中，我首先會使用一個表格來羅列當(dāng)前需求是什么、需求的版本、以及需求的完成日期和需求的狀態(tài)。
用于簡單陳述當(dāng)前的需求狀況，讓閱讀者知道該文檔是做什么、文檔當(dāng)前的狀態(tài)、該需求負(fù)責(zé)人是誰、修訂版本（當(dāng)前文檔的修訂版本，并不是產(chǎn)品迭代版本
需求文檔結(jié)構(gòu)開頭

2.背景概述
背景概述是說明需求出現(xiàn)的背景是什么，是基于什么原因想完成什么。比如下面是社區(qū)論壇UGC功能模塊需求。

將用戶發(fā)帖流程優(yōu)化，在不阻礙發(fā)帖體驗的情況下，增加了話題路徑，豐富了用戶選擇性，滿足平臺運營內(nèi)容多樣化的需求
原有功能模塊為：發(fā)帖功能、點贊功能、評論功能、轉(zhuǎn)發(fā)功能
用戶執(zhí)行發(fā)帖流程：發(fā)帖入口——輸入內(nèi)容——發(fā)帖完成
同時因為內(nèi)容多樣性后，用戶需要有針對性的選擇內(nèi)容瀏覽。針對信息流進(jìn)行了優(yōu)化，增加了過濾功能，用戶可以屏蔽相應(yīng)的不感興趣內(nèi)容，增加了話題功能，用戶可以對感興趣內(nèi)容進(jìn)行選取。

2.需求來源

本次需求來源負(fù)責(zé)人：Kevin，部門：產(chǎn)品部
3.關(guān)聯(lián)負(fù)責(zé)人
需求相關(guān)的負(fù)責(zé)人版塊
4.需求執(zhí)行成員
項目成員
需求執(zhí)行成員給出了具體的項目各個聯(lián)系人。這一點要說明的是，如果團隊沒有以上職位，可以將做這個項目的人員拉進(jìn)來?？赡躊M會做UI、UE，類似這樣的情況，也需要填表。
當(dāng)然敏捷開發(fā)的創(chuàng)業(yè)團隊，可能會當(dāng)面溝通，文檔中存在執(zhí)行成員與否反而不重要，本來人就少，大家都心知肚明啦。
5.項目進(jìn)度

【項目執(zhí)行周期】
每個公司的研發(fā)流程有一些區(qū)別，比如上面是適用于在產(chǎn)品研發(fā)人員在20人以內(nèi)的團隊，有2次評審。
需求評審周期和UI評審的周期是反復(fù)、漫長的，并不是將每一次的評審開會時間填上去，而是將相應(yīng)周期。

如：目前評審處于需求評審，UI還沒做，那么就屬于開發(fā)需求評審。
06更新記錄 這一塊是我認(rèn)為需求文檔中，最為重要的一塊。
文檔更新可能是很簡單的一句話，但卻是開發(fā)與測試人員每次最關(guān)注的就是你的更新記錄，他可不想每次都去查找那一小部分更新內(nèi)容。
這個更新記錄可以在需求評審后，也可以是開發(fā)中更新，畢竟有一些需求是開會中不會遇見的，只有在正在開發(fā)中才會發(fā)現(xiàn)不合理。
【更新記錄】
這里值得注意的是首先分為4個屬性

新增

刪除

修改

新建

新建默認(rèn)為相應(yīng)模塊的首次使用，后期對于文檔的修改用新增、刪除、修改即可，并且這里需要將修改、新增的地方加入超鏈接，方便開發(fā)進(jìn)行查閱。

07需求結(jié)構(gòu)圖
這里介紹了產(chǎn)品需求的全體結(jié)構(gòu)，描述順序為主功能—子功能—子功能詳情頁

【需求結(jié)構(gòu)圖】
并且這里建議將每個頁面超鏈接指向需求文檔后面的功能詳情，方便相應(yīng)人員查看。 鏈接的方式為功能模塊—子功能模塊——詳情頁面，都做可鏈接。
當(dāng)然這樣式比較費時間的，通吃我是只有梳理結(jié)構(gòu)圖，沒有做鏈接形式。
08數(shù)據(jù)間關(guān)系


對象背后的數(shù)據(jù)關(guān)系
通過以用戶的方式來模擬功能模塊流程，將流程涉及的數(shù)據(jù)關(guān)聯(lián)以流程圖展現(xiàn)，當(dāng)然也可以用腦圖，可以方便測試和開發(fā)人員指導(dǎo)哪一個數(shù)據(jù)是哪一個對象的，在哪一些流程中會增加或判別什么數(shù)據(jù)。

TIPS： 這一點對于大功能模塊來說比較常用，但一些小的功能模塊，這一塊可以不梳理，比如很常見的一個廣告BANNER等小功能模塊，想用的數(shù)據(jù)關(guān)系可以不用展示，與開發(fā)直接溝通好就行。
09全局說明

全局說明指的是在多個功能、頁面會存在的相同交互或邏輯，這里分類分為3個類，如下圖

全局說明中，產(chǎn)品經(jīng)理可以把最基礎(chǔ)的功能全局和交互全局進(jìn)行說明。在所有的功能PRD文檔中，都需要體現(xiàn)，這里我們列舉了比較常見的交互全局、功能全局

彈層對話

加載

彈層菜單

搜索

導(dǎo)航

表格

按鈕

列表

進(jìn)步器

在這個功能中會涉及哪些全局的控件或交互，PM需要將相應(yīng)的全局控件或交互置于文檔中，這里在這次UGC模塊中，有彈層對話與加載涉及全局，下面是全局的描述。
【UGC模塊中全局彈層】
加載的模塊首先分為以下3種：頁面加載中、內(nèi)容加載中、加載結(jié)果

【加載狀態(tài)】
1.頁面加載中

2.內(nèi)容加載（下拉、松開）

3.頁面加載網(wǎng)絡(luò)正常卻沒數(shù)據(jù)


4.頁面加載網(wǎng)絡(luò)異常

5.頁面加載搜索沒有結(jié)果


全局交互的2種表達(dá)形式

1.頁面間交互
產(chǎn)品經(jīng)理通過全局交互定義頁面間之間的交互，每個頁面哪些地方可以進(jìn)入，可以退出等。以下我分為單張和多張圖示進(jìn)行展示，頁面間交互應(yīng)該如何說明

【單個頁面間交互】

【多個頁面件交互】
2.頁面內(nèi)交互

、 以上為移動端內(nèi)的頁面內(nèi)交互，當(dāng)然還有長安、雙擊等交互，目前以上列舉的是比較常見的一些手勢

5.功清單能
在對于UGC模塊中，我將相應(yīng)的子功能進(jìn)行羅列，方便設(shè)計、開發(fā)人員以及測試人員對工作量的評估。

【功能清單】
當(dāng)然值得注意的是可能一個模塊下有子功能，子功能下面還有子功能，這個時候建議方便文檔查看，就以2個層級進(jìn)行區(qū)分，在后方描述的時候進(jìn)行說明。

6.業(yè)務(wù)流程
是以用戶開始，依照用戶的操作，將其流程分為前端和服務(wù)端2類流程，告知相應(yīng)端開發(fā)人員應(yīng)該做什么、不應(yīng)該做什么。

前端是指具體在系統(tǒng)里，PM需要根據(jù)不同的角色將相應(yīng)流程進(jìn)行繪制。
【根據(jù)不同角色泳道圖】
另一個流程圖就是后端服務(wù)流程，根據(jù)默認(rèn)的用戶流程，將系統(tǒng)APP、后臺之間的信息交互進(jìn)行記錄，有時候我們會用時序圖進(jìn)行記錄。

根據(jù)前端與服務(wù)端不同處理進(jìn)行分類

PRD文檔中的流程圖，將產(chǎn)品邏輯和用戶使用邏輯描述得清楚，將方便開發(fā)人員以及測試人員知道如何去進(jìn)行開發(fā)和驗收，涉及到數(shù)據(jù)交互的都應(yīng)該在服務(wù)端與
值得注意的是流程圖千萬要清晰、明了，不要彎彎曲曲，混成一團。在與產(chǎn)品朋友們交流中
【扭曲成一團】

【規(guī)整的流程圖】
7.需求/功能描述
到這里就是PRD主要的內(nèi)容部分，我建議將功能的每個頁面進(jìn)行列舉，比如某一個功能

【每個頁面進(jìn)行列舉】
每個功能的描述，按照功能點進(jìn)行拆解，以此羅列子功能。接下來在文檔中我們需要展現(xiàn)的是三部分內(nèi)容：

【三大部分】
1.頁面需求描述

說明該頁面是干什么的？并且該頁面出現(xiàn)的地方，在什么時間出現(xiàn)，需要有什么條件要求
2.交互手勢
上面所說的交互手勢在這里就可以列舉出來了，當(dāng)前頁面能做什么交互手勢？哪些手勢不能做？

【交互手勢】
該頁面如果只有點擊手勢，那么即在手勢下面寫有，并且描述在IOS與安卓那個版本下有，如果沒有是否需要開發(fā)
3.用例描述

描述點擊相應(yīng)控件或位置，頁面后進(jìn)入到哪一個頁面，以什么方式（滑動？彈出？）
這里以APP里開紅包方式來描述
用例1：點擊開，頁面左滑進(jìn)入紅包首頁用例結(jié)束
4.異常情況
異常情況的知曉能夠反映出作為PM的經(jīng)驗豐富情況，到底該頁面下那些異常會出現(xiàn)，你是否能預(yù)知？
PM或許會將該異常情況統(tǒng)一交給測試來處理。
異常情況：用戶未登錄，點擊紅包開，頁面左滑進(jìn)入紅包首頁用例結(jié)束

5.數(shù)據(jù)統(tǒng)計需求
以上的部分，可以將PRD差不多完成了70%，接下來就是為了后期驗證做一些輔助性需求，讓需求更加完整。
數(shù)據(jù)統(tǒng)計的需求我們也需要在文檔中進(jìn)行填寫，當(dāng)然如果有專門的數(shù)據(jù)部門，我建議PM可以交給數(shù)據(jù)部門完成，PM將其需求過渡給數(shù)據(jù)部門。
當(dāng)然不懂?dāng)?shù)據(jù)的PM肯定不是好PM，為此能夠了解產(chǎn)品哪些地方有數(shù)據(jù)統(tǒng)計，我還是把相應(yīng)的數(shù)據(jù)要求提交在文檔中。

【數(shù)據(jù)提交模板】
【頁面點擊數(shù)據(jù)模板】
關(guān)于自定義事件LABEL和自定義事件參數(shù)，（圖中時間改為事件），由開發(fā)人員來定就行了。當(dāng)然如果你是開發(fā)轉(zhuǎn)型的PM，你可以來決定，為了后期的數(shù)據(jù)參數(shù)統(tǒng)計和分類，建議還是直接交給開發(fā)人員

比如以UGC模塊，以發(fā)帖事件來進(jìn)行說明，該頁面所能進(jìn)行的操作都需要將其規(guī)則化，以事件名稱來確定每個操作的名稱，可以滿足將其規(guī)則化的目的。
其他需求描述
綜上，基本一個PRD文檔就算完成了，但在工作中一個功能模塊或一個版本的迭代往往還需要涉及其他需求，涉及人力、財務(wù)資源的需求，以及對于每次評審或小團隊溝通的記錄。這里我也一并同步出來自己在工作中做的一些需求描述，也可以集中放置于項目文檔或該PRD文檔中。

性能需求

服務(wù)需求

營銷需求

安全需求

法務(wù)需求

幫助需求

異常場景

溝通記錄

風(fēng)險描述

1.性能需求
性能需求可以以表格的形式對相應(yīng)的功能模塊進(jìn)行要求，如紅包點擊彈出的時間在3S內(nèi)，成功率是99%，并發(fā)數(shù)是20000。

【性能需求】
2.服務(wù)需求

這個涉及到產(chǎn)品客服，產(chǎn)品人員需要知道要占用客服時間、相應(yīng)問題解決的方案是什么？每個問題的優(yōu)先級是什么？產(chǎn)品需要從客服人員中得到什么信息？這個需要PM對當(dāng)前產(chǎn)品數(shù)據(jù)分析，才能更好的對接資源，總不能要求其他部門把全部資源用在你手上吧。
【服務(wù)需求】
這里首先要說明的是關(guān)于成本建議做一個標(biāo)準(zhǔn)，如果是按照價錢就統(tǒng)一為錢；如果為時間就統(tǒng)一為時間；預(yù)知服務(wù)頻率需要PM進(jìn)行數(shù)據(jù)分析，給予一個恰當(dāng)?shù)姆秶?br>
3.營銷需求
營銷需求和上方的服務(wù)需求同樣，也是需要產(chǎn)品經(jīng)理進(jìn)行數(shù)據(jù)分析，為達(dá)到目標(biāo)計劃一個預(yù)計營銷需求，當(dāng)然其營銷的平臺與方式可以和營銷部進(jìn)行策劃溝通。
4.法務(wù)需求

【人力需求】
法務(wù)需求與以上2點需求類似，建議可以合成為一張表格，將分別的需求資源供應(yīng)方分類，這樣可以更快的在一張表中了解該項目的資源消耗情況。
5.財務(wù)需求
同法務(wù)需求一樣
6.幫助需求
幫助需求可以解釋為FAQ培訓(xùn)，將產(chǎn)品上線后對于該項目涉及人員和部門進(jìn)行培訓(xùn)，建立相應(yīng)的FAQ，并且對于活動類模塊也需要運營提供活動FAQ。
7.項目風(fēng)險

【項目風(fēng)險】
如果是功能模塊迭代可以說明為版本風(fēng)險，但是對于產(chǎn)品的迭代中，其需要明確新增、取締的風(fēng)險，將其可能存在的風(fēng)險隱患進(jìn)行描述
8.評審中的溝通會議記錄
可以參考下面的會議模板作為需求評審記錄

【會議需求記錄】
這樣有了會議溝通記錄之后，相信產(chǎn)品人能夠減少一些坑或者識別一些坑，避免一些人冤枉PM說：領(lǐng)這是你之前說的！XX這是你說的！

一套專注產(chǎn)品設(shè)計的電子刊

講解了需求調(diào)研&用戶研究、功能減法、組合、微創(chuàng)新、迭代框架的5個步驟。每周更新2-4節(jié)，是一套非常好用的產(chǎn)品設(shè)計方法論。

電子刊新書：累計20萬字，8個章節(jié)，一個簡易設(shè)計方法

關(guān)鍵詞：