將交互、業務邏輯、需求欄位撰入文檔

產品基本功不僅是基礎

最近剛好負責的一個UGC模塊已經進入文檔階段。本周為各位朋友帶來一個產品基本功的分享——產品需求文檔，這一篇分享將是我3年產品進階到今天，個人要求需求文檔目前的撰寫標準。

從騰訊出來已經有大半年，曾經在騰訊工作期間，當時我做的是偏向運營的產品經理，雖在騰訊的時間不長，但期間完成相應任務時，我的導師一直要求我，做什麼事要想清楚為什麼這麼做？

個人認為做的很細、複雜與否不是問題，而是認識到做這件事的理由與目的

3年的產品道路中，常常對於產品新人困惑的交互和功能欄位解釋，如何將巧妙加入在需求文檔中？如果這樣做下去，相信開發和測試一定會少很多疑惑，所有的坑已經在文檔中被搞乾淨啦

01

需求概述

在需求概述前關於一些基本設置，我採用以WORD WEB版式，並且字體我一直系統是微軟雅黑。

【WORD版式】

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

在需求概述中，我首先將一個開文數據框圖，表示目前該需求的大體情況，讓開發或測試相應人員指導該文檔是做什麼、文檔當前的狀態、該需求負責人是誰、修訂版本（當前文檔的修訂版本，並不是產品迭代版本

【需求文檔開頭】

在做產品助理的時候，這個文檔的開頭基本就在這裡結束了。但隨著在後期的產品積累上，，我將開頭添加了項目背景概述、需求來源、關聯負責人、需求執行成員（項目成員）、需求執行周期（項目周期），下面我通過截圖的方式更新以上

1.背景概述

目前UGC模塊需要優化，提升用戶體驗。

當前UGC模塊功能為：發帖功能、點贊功能、評論功能、轉發功能

用戶執行發帖流程：發帖入口——輸入內容——發帖完成

目前UGC模塊功能進行了優化，比如增加了過濾功能，用戶可以屏蔽相應的不感興趣內容，增加了話題功能，用戶可以對感興趣內容進行選取。

將用戶發帖流程進行優化，在不阻礙發帖體驗的情況下，增加了話題路徑，豐富了用戶選擇性，增加了平台內容多樣化

2.需求來源

本次需求來源負責人：KEVIN，部門：產品部

3.關聯負責人

【負責人版塊】

4.需求執行成員

【項目成員】

這一點要說明的是，很多團隊可能沒有以上職位，尤其是在創業團隊，一人做多事，因此可以將做這個項目的人員拉進來。可能PM會做UI、UE，類似這樣的情況，也需要填表。

當然敏捷開發的創業團隊，可能會當面溝通，文檔中存在執行成員與否反而不重要，本來人就少，大家都心知肚明啦。

5.需求執行周期

【項目執行周期】

這裡要說一點，這個是適用於我目前的團隊，因為有2次評審。但是開發需求評審的周期和UI評審的周期是反覆、漫長的，並不是將每一次的評審開會時間填上去，而是將相應周期。

如：目前評審處於開發需求評審，UI還沒做，那麼就是開發需求評審，這個時候往往會幹掉一些需求，PM需要及時收集並且調整。

02

更新記錄

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

這個更新記錄可能是在開發需求評審後，也可能是開發中進行更新，畢竟有一些需求是開會中不會遇見的，只有在正在開發中才會發現不合理。

【更新記錄】

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

新增

刪除

修改

新建

新建默認為相應模塊的首次使用，後期對於文檔的修改用新增、刪除、修改即可，並且這裡需要將修改、新增的地方加入超鏈接，方便開發進行查閱。

03

需求結構圖

這裡主要是設計和技術開發人員了解產品需求的結構，描述順序為主功能—子功能—子功能詳情頁

【需求結構圖】

並且這裡建議將每個頁面超鏈接後面的頁面詳情，方便及時相應人員查看。可以鏈接的地方為功能模塊—子功能模塊——詳情頁面，都做可鏈接。

當然這樣式比較費時間的，通吃我是只有梳理結構圖，沒有做鏈接形式。

04

數據間關係

【數據的關係】

將功能塊中設計的用戶對象和功能模塊流程，將相應的流程涉及的數據關聯以流程圖的方式展現，當然也可以用腦圖，可以方便測試和開發人員指導哪一個數據是哪一個對象的，在哪一些流程中會增加或判別什麼數據。

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

04

全局說明

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

對於PM來說，一直被認為說所有都要知道，但又不需要所有都精通，但在全局說明中，尤其是在創業團隊，並沒有UED等專屬的部門，產品經理可以把最基礎的功能全局和交互全局進行說明。

既然是全局，因此在所有的功能PRD文檔中，都需要體現，這裡我們以比較常見的交互全局、功能全局

彈層對話

載入

彈層菜單

搜索

導航

表格

按鈕

列表

進步器

以上是比較常見的全局控制項或功能或交互，在這個功能中會涉及哪些全局的控制項或交互，PM需要將相應的全局控制項或交互置於文檔中，這裡在這次UGC模塊中，有彈層對話與載入涉及全局，下面是全局的描述。

【UGC模塊中全局彈層】

載入的模塊首先分為以下3種：頁面載入中、內容載入中、載入結果

【載入狀態】

1.頁面載入中

2.內容載入（下拉、鬆開）

3.頁面載入網路正常卻沒數據

4.頁面載入網路異常

5.頁面載入搜索沒有結果

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

分為：頁面間交互也頁面內交互

1.頁面間交互

首先是對於NATIVE的交互，另外需要注意H5網頁的交互默認是不作處理的，因為就是淡入淡出的效果。

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

【單個頁面間交互】

【多個頁面件交互】

2.頁面內交互

、

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

5

功清單能

在對於UGC模塊中，我將相應的子功能進行羅列，那麼這裡我們需要以用表格的方式進行統計，方便設計、開發人員以及測試人員對工作量的評估。

【功能清單】

當然值得注意的是可能一個模塊下有子功能，子功能下面還有子功能，這個時候建議方便文檔查看，就以2個層級進行區分，在後方描述的時候進行說明。

5

業務流程

這裡的業務流程，我們默認是以用戶開始，依照用戶的操作，將其流程分為前端和服務端，告知相應端開發人員應該做什麼、不應該做什麼。

當然這裡移動端流程指向的用戶相對單一，當然也有按照用戶角色來進行區分的流程，常見的就是在ERP或者一些後台產品設計中，PM需要根據不同的角色將相應流程進行繪製。

【根據不同角色泳道圖】

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

【根據前端與服務端不同處理進行分類】

PRD需求文檔，在創業團隊中可能處於一個空置的情況下，為什麼這麼說？因為你寫出來沒人看，只能作為一個留底

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

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

【扭曲成一團】

【規整的流程圖】

6

需求/功能描述

到這裡就是PRD主要的篇幅部分，在這裡我建議將功能的每個頁面進行列舉，比如某一個功能

【每個頁面進行列舉】

每個功能的描述，我們既然按照功能點進行分類，將不同的子功能分別列舉。接下來在文檔中我們需要展現的是三部分內容：

【三大部分】

1.頁面需求描述

說明該頁面是幹什麼的？並且該頁面出現的地方，在什麼時間出現，需要有什麼條件要求

2.交互手勢

上面所說的交互手勢在這裡就可以列舉出來了，當前頁面能做什麼交互手勢？哪些手勢不能做？

【交互手勢】

該頁面如果只有點擊手勢，那麼即在手勢下面寫有，並且描述在IOS與安卓那個版本下有，如果沒有是否需要開發

3.用例描述

描述點擊相應控制項或位置，頁面後進入到哪一個頁面，以什麼方式（滑動？彈出？）

這裡以開紅包方式來描述

用例1：點擊開，頁面左滑進入紅包首頁用例結束

4.異常情況

這裡的異常情況或許很多PM朋友都沒有寫進去，說實話，今天以前我也沒有寫。但和產品朋友交流後我發現，其實異常情況的知曉能夠反映出作為PM你目前的經驗豐富情況，到底該頁面下那些異常會出現，你是否能預知？

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

用例1：用戶未登錄，點擊紅包開，頁面左滑進入紅包首頁用例結束

7

數據統計需求

以上我們的PRD差不多完成了70%，接下來就是為了後期驗證跟進做的一些輔助性跟進，那就是對於數據的統計需求。數據統計的需求我們也需要在文檔中進行撰寫，當然如果有專門的數據部門，我建議PM可以交給數據部門完成，PM將其需求過渡給數據部門。

當然不懂數據的PM肯定不是好PM，為此能夠了解產品哪些地方有數據統計，我還是把相應的數據要求提交在文檔中。

【數據提交模板】

【頁面點擊數據模板】

這一點必須說明的是關於自定義事件LABEL和自定義事件參數，（圖中時間改為事件），由開發人員來定就行了。當然如果你是開發轉型的PM，你可以來決定，但為了後期的數據參數統計和分類，建議還是直接交給開發人員

這裡可以簡單舉例比如以UGC模塊，以發帖事件來進行說明，該頁面所能進行的操作都需要將其規則化，以事件名稱來確定每個操作的名稱，可以滿足將其規則化的目的。

6

其他需求描述

綜上，基本一個PRD文檔就算完成了，但在工作中一個功能模塊或一個版本的迭代往往還需要涉及其他需求，涉及人力、財務資源的需求，以及對於每次評審或小團隊溝通的記錄。這裡我也一併同步出來自己在工作中做的一些需求描述，也可以集中放置於項目文檔或該PRD文檔中。

性能需求

服務需求

營銷需求

安全需求

法務需求

幫助需求

異常場景

溝通記錄

風險描述

1.性能需求

性能需求可以以表格的形式對相應的功能模塊進行要求，如紅包點擊彈出的時間在3S內，成功率是99%，並發數是20000。

【性能需求】

2.服務需求

這個涉及到產品客服，產品人員需要知道要佔用客服時間、相應問題解決的方案是什麼？每個問題的優先順序是什麼？產品需要從客服人員中得到什麼信息？這個需要PM對當前產品數據分析，才能更好的對接資源，總不能要求其他部門把全部資源用在你手上吧。

【服務需求】

這裡首先要說明的是關於成本建議做一個標準，如果是按照價錢就統一為錢；如果為時間就統一為時間；預知服務頻率需要PM進行數據分析，給予一個恰當的範圍。

3.營銷需求

營銷需求和上方的服務需求同樣，也是需要產品經理進行數據分析，為達到目標計劃一個預計營銷需求，當然其營銷的平台與方式可以和營銷部進行策劃溝通。

4.法務需求

【人力需求】

法務需求與以上2點需求類似，建議可以合成為一張表格，將分別的需求資源供應方分類，這樣可以更快的在一張表中了解該項目的資源消耗情況。

5.財務需求

同法務需求一樣

6.幫助需求

幫助需求可以解釋為FAQ培訓，將產品上線後對於該項目涉及人員和部門進行培訓，建立相應的FAQ，並且對於活動類模塊也需要運營提供活動FAQ。

7.項目風險

【項目風險】

如果是功能模塊迭代可以說明為版本風險，但是對於產品的迭代中，其需要明確新增、取締的風險，將其可能存在的風險隱患進行描述

提前說明一些風險能夠給予BOSS一些心理的準備，當然這個風險的預測也不是萬能的，如果出現一些技術無法解決的問題也需要PM注意埋坑。但將能夠預測的風險進行預測，也是PM的一個硬戰。

以上就是關於我3年產品進階中，目前PRD文檔的撰寫，關於交互與欄位的描述相信能夠為產品新人提供幫助

最後關於評審中的溝通會議記錄，我也同步一下模板

【會議需求記錄】

這樣有了會議溝通記錄之後，相信產品人能夠減少一些坑或者識別一些坑，避免一些人冤枉PM說：領導這是你之前說的！XX這是你說的！

好啦，本周的總結在這裡，在公眾號中回復：原型，因為私人原因不能給於原件文檔，為此我找了一份類似模板，可以下載！

另外關於深圳線下分享會

之前有一個帖子，KEVIN也說了正在和小夥伴們籌備深圳線下產品分享會帖子在這裡啟動|Kevin和他的產品朋友線下沙龍分享會（深圳地區）

這裡建立了個深圳分享會的群，有興趣或到時候可能有時間的朋友，可以先進群，相關活動的進展和情況我也會在群里說明

【KEVIN改變世界的點滴作者：張晉壹】

【 高級產品經理一枚 坐標：深圳】

【每周六，我的一次經驗分享在這裡】

繼續更新中......

2017年，讓我們繼續前進！

（一個KEVIN為產品朋友們建立的討論小基地）

好，大家來看看！另外有更好的建議或支持歡迎微信評論！

另外知乎上也有我的一些產品討論，歡迎關注一起討論

KEVIN的知乎主頁 -http://www.zhihu.com/people/zhang-jin-yi-23?utm_source=qq&utm_medium=social

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！