產(chǎn)品基本功不僅是基礎(chǔ)

曾經(jīng)有更新過關(guān)于PRD撰寫的案例。PRD的個人模版一直都需要新的輸入，調(diào)和自己的理解，輸出為更適合的PRD方式。

今天為各位朋友帶來一個產(chǎn)品基本功的分享——產(chǎn)品需求文檔，這一篇分享將是我?guī)啄戤a(chǎn)品進(jìn)階到今天，個人要求需求文檔目前的撰寫標(biāo)準(zhǔn)。

個人認(rèn)為做的很細(xì)、復(fù)雜與否不是問題，而是認(rèn)識到做這件事的理由與目的

常常對于產(chǎn)品新人困惑的交互和功能字段解釋，如何將巧妙加入在需求文檔中？如果這樣做下去，相信開發(fā)和測試一定會少很多疑惑，所有的坑已經(jīng)在文檔中被搞干凈啦 特別要感謝PM臥龍的原創(chuàng)，部分PRD篇幅的撰寫集合了他的方式。

但針對泳道圖、邏輯，和文字的標(biāo)注我做了更新

01

需求概述

在需求概述前關(guān)于一些基本設(shè)置，我采用以WORD WEB版式，并且字體我一直系統(tǒng)是微軟雅黑。

【W(wǎng)ORD版式】

WEB版式方便橫向內(nèi)容瀏覽，字體微軟雅黑我總認(rèn)為看著比較舒服。

在需求概述中，我首先將一個開文數(shù)據(jù)框圖，表示目前該需求的大體情況，讓開發(fā)或測試相應(yīng)人員指導(dǎo)該文檔是做什么、文檔當(dāng)前的狀態(tài)、該需求負(fù)責(zé)人是誰、修訂版本（當(dāng)前文檔的修訂版本，并不是產(chǎn)品迭代版本

【需求文檔開頭】

在做產(chǎn)品助理的時候，這個文檔的開頭基本就在這里結(jié)束了。但隨著在后期的產(chǎn)品積累上，，我將開頭添加了項目背景概述、需求來源、關(guān)聯(lián)負(fù)責(zé)人、需求執(zhí)行成員（項目成員）、需求執(zhí)行周期（項目周期），下面我通過截圖的方式更新以上

1.背景概述

目前UGC模塊需要優(yōu)化，提升用戶體驗。

當(dāng)前UGC模塊功能為：發(fā)帖功能、點贊功能、評論功能、轉(zhuǎn)發(fā)功能

用戶執(zhí)行發(fā)帖流程：發(fā)帖入口——輸入內(nèi)容——發(fā)帖完成

目前UGC模塊功能進(jìn)行了優(yōu)化，比如增加了過濾功能，用戶可以屏蔽相應(yīng)的不感興趣內(nèi)容，增加了話題功能，用戶可以對感興趣內(nèi)容進(jìn)行選取。

將用戶發(fā)帖流程進(jìn)行優(yōu)化，在不阻礙發(fā)帖體驗的情況下，增加了話題路徑，豐富了用戶選擇性，增加了平臺內(nèi)容多樣化

2.需求來源

本次需求來源負(fù)責(zé)人：KEVIN，部門：產(chǎn)品部

3.關(guān)聯(lián)負(fù)責(zé)人

【負(fù)責(zé)人版塊】

4.需求執(zhí)行成員

【項目成員】

這一點要說明的是，很多團(tuán)隊可能沒有以上職位，尤其是在創(chuàng)業(yè)團(tuán)隊，一人做多事，因此可以將做這個項目的人員拉進(jìn)來?？赡躊M會做UI、UE，類似這樣的情況，也需要填表。

當(dāng)然敏捷開發(fā)的創(chuàng)業(yè)團(tuán)隊，可能會當(dāng)面溝通，文檔中存在執(zhí)行成員與否反而不重要，本來人就少，大家都心知肚明啦。

5.需求執(zhí)行周期

【項目執(zhí)行周期】

這里要說一點，這個是適用于我目前的團(tuán)隊，因為有2次評審。但是開發(fā)需求評審的周期和UI評審的周期是反復(fù)、漫長的，并不是將每一次的評審開會時間填上去，而是將相應(yīng)周期。

如：目前評審處于開發(fā)需求評審，UI還沒做，那么就是開發(fā)需求評審，這個時候往往會干掉一些需求，PM需要及時收集并且調(diào)整。

02

更新記錄

這一塊是我認(rèn)為3年工作中，最為重要的一塊。最初做產(chǎn)品助理時候，文檔更新可能就是很簡單的一句話，但隨后發(fā)現(xiàn)，開發(fā)與測試人員每次最關(guān)注的就是你更新記錄，他可不想每次都去查找那一小部分更新內(nèi)容。

這個更新記錄可能是在開發(fā)需求評審后，也可能是開發(fā)中進(jìn)行更新，畢竟有一些需求是開會中不會遇見的，只有在正在開發(fā)中才會發(fā)現(xiàn)不合理。

【更新記錄】

這里值得注意的是首先分為4個屬性

新增

刪除

修改

新建

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

03

需求結(jié)構(gòu)圖

這里主要是設(shè)計和技術(shù)開發(fā)人員了解產(chǎn)品需求的結(jié)構(gòu)，描述順序為主功能—子功能—子功能詳情頁

【需求結(jié)構(gòu)圖】

并且這里建議將每個頁面超鏈接后面的頁面詳情，方便及時相應(yīng)人員查看?？梢枣溄拥牡胤綖楣δ苣K—子功能模塊——詳情頁面，都做可鏈接。

當(dāng)然這樣式比較費時間的，通吃我是只有梳理結(jié)構(gòu)圖，沒有做鏈接形式。

04

數(shù)據(jù)間關(guān)系

【數(shù)據(jù)的關(guān)系】

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

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

05

全局說明

全局說明這里分類分為3個類，如下圖

對于PM來說，一直被認(rèn)為說所有都要知道，但又不需要所有都精通，但在全局說明中，尤其是在創(chuàng)業(yè)團(tuán)隊，并沒有UED等專屬的部門，產(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é)果

下面羅列下文檔中，具體去怎么寫全局交互

分為：頁面間交互也頁面內(nèi)交互

1.頁面間交互

首先是對于NATIVE的交互，另外需要注意H5網(wǎng)頁的交互默認(rèn)是不作處理的，因為就是淡入淡出的效果。

頁面間之間的交互，可以進(jìn)行自定義，但最終進(jìn)入那個頁面，每個頁面哪些地方可以進(jìn)入，可以退出等，PM或交互設(shè)計師需要進(jìn)行說明。以下我分為單張和多張圖示進(jìn)行展示，頁面間交互應(yīng)該如何說明

【單個頁面間交互】

【多個頁面件交互】

2.頁面內(nèi)交互

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

6

功清單能

在對于UGC模塊中，我將相應(yīng)的子功能進(jìn)行羅列，那么這里我們需要以用表格的方式進(jìn)行統(tǒng)計，方便設(shè)計、開發(fā)人員以及測試人員對工作量的評估。

【功能清單】

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

7

業(yè)務(wù)流程

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

當(dāng)然這里移動端流程指向的用戶相對單一，當(dāng)然也有按照用戶角色來進(jìn)行區(qū)分的流程，常見的就是在ERP或者一些后臺產(chǎn)品設(shè)計中，PM需要根據(jù)不同的角色將相應(yīng)流程進(jìn)行繪制。

【根據(jù)不同角色泳道圖】

另一個流程圖比較常見就是上面說的根據(jù)默認(rèn)以用戶流程，將前端與服務(wù)端的流程涉及

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

PRD需求文檔，在創(chuàng)業(yè)團(tuán)隊中可能處于一個空置的情況下，為什么這么說？因為你寫出來沒人看，只能作為一個留底

但在一些成熟性公司中，那么PRD文檔不僅僅起著留底的作用，將產(chǎn)品邏輯和用戶使用邏輯描述得清楚，將方便開發(fā)人員以及測試人員知道如何去進(jìn)行開發(fā)和驗收，涉及到數(shù)據(jù)交互的都應(yīng)該在服務(wù)端與

但值得注意的是流程圖千萬要清晰、明了，不要彎彎曲曲，混成一團(tuán)。在與產(chǎn)品朋友們交流中

【扭曲成一團(tuán)】

8

需求/功能描述

到這里就是PRD主要的篇幅部分，在這里我建議將功能的每個頁面進(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)入到哪一個頁面，以什么方式（滑動？彈出？）

這里以開紅包方式來描述

用例1：??點擊開，頁面左滑進(jìn)入紅包首頁?用例結(jié)束

4.異常情況

這里的異常情況或許很多PM朋友都沒有寫進(jìn)去，說實話，今天以前我也沒有寫。但和產(chǎn)品朋友交流后我發(fā)現(xiàn)，其實異常情況的知曉能夠反映出作為PM你目前的經(jīng)驗豐富情況，到底該頁面下那些異常會出現(xiàn)，你是否能預(yù)知？

大多數(shù)PM或許會將該異常情況統(tǒng)一交給測試來處理，因此為了百分百保證這一份分享是最完整的PRD干貨，今天就把這個加上了。

用例1：用戶未登錄，點擊紅包開，頁面左滑進(jìn)入紅包首頁?用例結(jié)束

9

數(shù)據(jù)統(tǒng)計需求

以上我們的PRD差不多完成了70%，接下來就是為了后期驗證跟進(jìn)做的一些輔助性跟進(jìn)，那就是對于數(shù)據(jù)的統(tǒng)計需求。數(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ī)則化的目的。

10

其他需求描述

綜上，基本一個PRD文檔就算完成了，但在工作中一個功能模塊或一個版本的迭代往往還需要涉及其他需求，涉及人力、財務(wù)資源的需求，以及對于每次評審或小團(tuán)隊溝通的記錄。這里我也一并同步出來自己在工作中做的一些需求描述，也可以集中放置于項目文檔或該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ù)姆秶?/p>

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)行描述

提前說明一些風(fēng)險能夠給予BOSS一些心理的準(zhǔn)備，當(dāng)然這個風(fēng)險的預(yù)測也不是萬能的，如果出現(xiàn)一些技術(shù)無法解決的問題也需要PM注意埋坑。但將能夠預(yù)測的風(fēng)險進(jìn)行預(yù)測，也是PM的一個硬戰(zhàn)。

以上就是關(guān)于，目前PRD文檔的撰寫，關(guān)于交互與字段的描述相信能夠為產(chǎn)品新人提供幫助

最后關(guān)于評審中的溝通會議記錄，我也同步一下模板

【會議需求記錄】

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