產品經理基本功（PRD）|將交互、業務邏輯、需求字段撰入文檔

產品基本功不只是基礎

曾經有更新過關於PRD撰寫的案例。PRD的我的模版一直都須要新的輸入，調和本身的理解，輸出爲更適合的PRD方式。

今天爲各位朋友帶來一個產品基本功的分享——產品需求文檔，這一篇分享將是我幾年產品進階到今天，我的要求需求文檔目前的撰寫標準。

我的認爲作的很細、複雜與否不是問題，而是認識到作這件事的理由與目的

經常對於產品新人困惑的交互和功能字段解釋，如何將巧妙加入在需求文檔中？若是這樣作下去，相信開發和測試必定會少不少疑惑，全部的坑已經在文檔中被搞乾淨啦 特別要感謝PM臥龍的原創，部分PRD篇幅的撰寫集合了他的方式。

但針對泳道圖、邏輯，和文字的標註我作了更新

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個層級進行區分，在後方描述的時候進行說明。

6

業務流程

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

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

【根據不一樣角色泳道圖】

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

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

PRD需求文檔，在創業團隊中可能處於一個空置的狀況下，爲何這麼說？由於你寫出來沒人看，只能做爲一個留底

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

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

【扭曲成一團】

【規整的流程圖】

7

需求/功能描述

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

【每一個頁面進行列舉】

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

【三大部分】

1.頁面需求描述

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

2.交互手勢

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

【交互手勢】

該頁面若是隻有點擊手勢，那麼即在手勢下面寫有，而且描述在IOS與安卓那個版本下有，若是沒有是否須要開發

3.用例描述

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

這裏以開紅包方式來描述

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

4.異常狀況

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

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

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

8

數據統計需求

以上咱們的PRD差很少完成了70%，接下來就是爲了後期驗證跟進作的一些輔助性跟進，那就是對於數據的統計需求。數據統計的需求咱們也須要在文檔中進行撰寫，固然若是有專門的數據部門，我建議PM能夠交給數據部門完成，PM將其需求過渡給數據部門。

固然不懂數據的PM確定不是好PM，爲此可以瞭解產品哪些地方有數據統計，我仍是把相應的數據要求提交在文檔中。

【數據提交模板】

【頁面點擊數據模板】

這一點必須說明的是關於自定義事件LABEL和自定義事件參數，（圖中時間改成事件），由開發人員來定就好了。固然若是你是開發轉型的PM，你能夠來決定，但爲了後期的數據參數統計和分類，建議仍是直接交給開發人員

這裏能夠簡單舉例好比以UGC模塊，以發帖事件來進行說明，該頁面所能進行的操做都須要將其規則化，以事件名稱來肯定每一個操做的名稱，能夠知足將其規則化的目的。

9

其餘需求描述

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

• 性能需求

• 服務需求

• 營銷需求

• 安全需求

• 法務需求

• 幫助需求

• 異常場景

• 溝通記錄

• 風險描述

1.性能需求

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

【性能需求】

2.服務需求

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

【服務需求】

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

3.營銷需求

營銷需求和上方的服務需求一樣，也是須要產品經理進行數據分析，爲達到目標計劃一個預計營銷需求，固然其營銷的平臺與方式能夠和營銷部進行策劃溝通。

4.法務需求

【人力需求】

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

5.財務需求

同法務需求同樣

6.幫助需求

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

7.項目風險

【項目風險】

若是是功能模塊迭代能夠說明爲版本風險，可是對於產品的迭代中，其須要明確新增、取締的風險，將其可能存在的風險隱患進行描述

提早說明一些風險可以給予BOSS一些心理的準備，固然這個風險的預測也不是萬能的，若是出現一些技術沒法解決的問題也須要PM注意埋坑。但將可以預測的風險進行預測，也是PM的一個硬戰。

以上就是關於，目前PRD文檔的撰寫，關於交互與字段的描述相信可以爲產品新人提供幫助

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

【會議需求記錄】

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