產品基本功不僅是基礎。
最近剛好負責的一個UGC模塊已經進入文檔階段。本周為各位朋友帶來一個產品基本功的分享——產品需求文檔，這一篇分享將是我3年產品進階到今天，個人要求需求文檔目前的撰寫標準。
從騰訊出來已經有大半年，曾經在騰訊工作期間，當時我做的是偏向運營的產品經理，雖在騰訊的時間不長，但期間完成相應任務時，我的導師一直要求我，做什么事要想清楚為什么這么做？
個人認為：做的很細、復雜與否不是問題，而是認識到做這件事的理由與目的。
3年的產品道路中，常常對于產品新人困惑的交互和功能字段解釋，如何將巧妙加入在需求文檔中？如果這樣做下去，相信開發和測試一定會少很多疑惑，所有的坑已經在文檔中被搞干凈啦~
一、需求概述在需求概述前關于一些基本設置，我采用以WORD WEB版式，并且字體我一直系統是微軟雅黑。
WEB版式方便橫向內容瀏覽，字體微軟雅黑我總認為看著比較舒服。
在需求概述中，我首先將一個開文數據框圖，表示目前該需求的大體情況，讓開發或測試相應人員指導該文檔是做什么、文檔當前的狀態、該需求負責人是誰、修訂版本（當前文檔的修訂版本，并不是產品迭代版本
在做產品助理的時候，這個文檔的開頭基本就在這里結束了。但隨著在后期的產品積累上，，我將開頭添加了項目背景概述、需求來源、關聯負責人、需求執行成員（項目成員）、需求執行周期（項目周期），下面我通過截圖的方式更新以上
1.背景概述目前UGC模塊需要優化，提升用戶體驗。
當前UGC模塊功能為：發帖功能、點贊功能、評論功能、轉發功能用戶執行發帖流程：發帖入口——輸入內容——發帖完成目前UGC模塊功能進行了優化，比如增加了過濾功能，用戶可以屏蔽相應的不感興趣內容，增加了話題功能，用戶可以對感興趣內容進行選取。
將用戶發帖流程進行優化，在不阻礙發帖體驗的情況下，增加了話題路徑，豐富了用戶選擇性，增加了平臺內容多樣化
2.需求來源本次需求來源負責人：KEVIN，部門：產品部
3.關聯負責人
這一點要說明的是，很多團隊可能沒有以上職位，尤其是在創業團隊，一人做多事，因此可以將做這個項目的人員拉進來?？赡躊M會做UI、UE，類似這樣的情況，也需要填表。
當然敏捷開發的創業團隊，可能會當面溝通，文檔中存在執行成員與否反而不重要，本來人就少，大家都心知肚明啦。
5.需求執行周期
這里要說一點，這個是適用于我目前的團隊，因為有2次評審。但是開發需求評審的周期和UI評審的周期是反復、漫長的，并不是將每一次的評審開會時間填上去，而是將相應周期。
如：目前評審處于開發需求評審，UI還沒做，那么就是開發需求評審，這個時候往往會干掉一些需求，PM需要及時收集并且調整。
二、更新記錄這一塊是我認為3年工作中，最為重要的一塊。最初做產品助理時候，文檔更新可能就是很簡單的一句話，但隨后發現，開發與測試人員每次最關注的就是你更新記錄，他可不想每次都去查找那一小部分更新內容。
這個更新記錄可能是在開發需求評審后，也可能是開發中進行更新，畢竟有一些需求是開會中不會遇見的，只有在正在開發中才會發現不合理。
這里值得注意的是首先分為4個屬性
新增刪除修改新建新建默認為相應模塊的首次使用，后期對于文檔的修改用新增、刪除、修改即可，并且這里需要將修改、新增的地方加入超鏈接，方便開發進行查閱。
三、需求結構圖這里主要是設計和技術開發人員了解產品需求的結構，描述順序為主功能—子功能—子功能詳情頁
并且這里建議將每個頁面超鏈接后面的頁面詳情，方便及時相應人員查看?？梢枣溄拥牡胤綖楣δ苣K—子功能模塊——詳情頁面，都做可鏈接。
當然這樣式比較費時間的，通吃我是只有梳理結構圖，沒有做鏈接形式。
四、數據間關系
將功能塊中設計的用戶對象和功能模塊流程，將相應的流程涉及的數據關聯以流程圖的方式展現，當然也可以用腦圖，可以方便測試和開發人員指導哪一個數據是哪一個對象的，在哪一些流程中會增加或判別什么數據。
TIPS：這一點對于大功能模塊來說比較常用，但一些小的功能模塊，這一塊可以忽略不梳理，比如很常見的一個廣告BANNER等小功能模塊，想用的數據關系可以不用展示，與開發直接溝通好就行。
五、全局說明全局說明這里分類分為3個類，如下圖
對于PM來說，一直被認為說所有都要知道，但又不需要所有都精通，但在全局說明中，尤其是在創業團隊，并沒有UED等專屬的部門，產品經理可以把最基礎的功能全局和交互全局進行說明。
既然是全局，因此在所有的功能PRD文檔中，都需要體現，這里我們以比較常見的交互全局、功能全局
彈層對話加載彈層菜單搜索導航表格按鈕列表進步器以上是比較常見的全局控件或功能或交互，在這個功能中會涉及哪些全局的控件或交互，PM需要將相應的全局控件或交互置于文檔中，這里在這次UGC模塊中，有彈層對話與加載涉及全局，下面是全局的描述。
首先分為以下3種：頁面加載中、內容加載中、加載結果
1.頁面加載中
2.內容加載（下拉、松開）
3.頁面加載網絡正常卻沒數據
4.頁面加載網絡異常
5.頁面加載搜索沒有結果
下面羅列下文檔中，具體去怎么寫全局交互
分為：頁面間交互也頁面內交互
1.頁面間交互
首先是對于Native的交互，另外需要注意H5網頁的交互默認是不作處理的，因為就是淡入淡出的效果。
頁面間之間的交互，可以進行自定義，但最終進入那個頁面，每個頁面哪些地方可以進入，可以退出等，PM或交互設計師需要進行說明。以下我分為單張和多張圖示進行展示，頁面間交互應該如何說明
2.頁面內交互
以上為移動端內的頁面內交互，可以看到基本為目前常見的人類手勢，當然還有長安、雙擊等交互，目前以上列舉的是比較常見的一些手勢
六、功能清單在對于UGC模塊中，我將相應的子功能進行羅列，那么這里我們需要以用表格的方式進行統計，方便設計、開發人員以及測試人員對工作量的評估。
當然值得注意的是可能一個模塊下有子功能，子功能下面還有子功能，這個時候建議方便文檔查看，就以2個層級進行區分，在后方描述的時候進行說明。
七、業務流程這里的業務流程，我們默認是以用戶開始，依照用戶的操作，將其流程分為前端和服務端，告知相應端開發人員應該做什么、不應該做什么。
當然這里移動端流程指向的用戶相對單一，當然也有按照用戶角色來進行區分的流程，常見的就是在ERP或者一些后臺產品設計中，PM需要根據不同的角色將相應流程進行繪制。
另一個流程圖比較常見就是上面說的根據默認以用戶流程，將前端與服務端的流程涉及
PRD需求文檔，在創業團隊中可能處于一個空置的情況下，為什么這么說？因為你寫出來沒人看，只能作為一個留底
但在一些成熟性公司中，那么PRD文檔不僅僅起著留底的作用，將產品邏輯和用戶使用邏輯描述得清楚，將方便開發人員以及測試人員知道如何去進行開發和驗收，涉及到數據交互的都應該在服務端與
但值得注意的是流程圖千萬要清晰、明了，不要彎彎曲曲，混成一團。
到這里就是PRD主要的篇幅部分，在這里我建議將功能的每個頁面進行列舉，比如某一個功能
每個功能的描述，我們既然按照功能點進行分類，將不同的子功能分別列舉。接下來在文檔中我們需要展現的是三部分內容：
說明該頁面是干什么的？并且該頁面出現的地方，在什么時間出現，需要有什么條件要求
2.交互手勢上面所說的交互手勢在這里就可以列舉出來了，當前頁面能做什么交互手勢？哪些手勢不能做？
該頁面如果只有點擊手勢，那么即在手勢下面寫有，并且描述在IOS與安卓那個版本下有，如果沒有是否需要開發
3.用例描述描述點擊相應控件或位置，頁面后進入到哪一個頁面，以什么方式（滑動？彈出？）
這里以開紅包方式來描述
用例1：點擊開，頁面左滑進入紅包首頁?用例結束
4.異常情況這里的異常情況或許很多PM朋友都沒有寫進去，說實話，今天以前我也沒有寫。但和產品朋友交流后我發現，其實異常情況的知曉能夠反映出作為PM你目前的經驗豐富情況，到底該頁面下那些異常會出現，你是否能預知？
大多數PM或許會將該異常情況統一交給測試來處理，因此為了百分百保證這一份分享是最完整的PRD干貨，今天就把這個加上了。
用例1：用戶未登錄，點擊紅包開，頁面左滑進入紅包首頁?用例結束
九、數據統計需求以上我們的PRD差不多完成了70%，接下來就是為了后期驗證跟進做的一些輔助性跟進，那就是對于數據的統計需求。數據統計的需求我們也需要在文檔中進行撰寫，當然如果有專門的數據部門，我建議PM可以交給數據部門完成，PM將其需求過渡給數據部門。
當然不懂數據的PM肯定不是好PM，為此能夠了解產品哪些地方有數據統計，我還是把相應的數據要求提交在文檔中。
這一點必須說明的是關于自定義事件LABEL和自定義事件參數，（圖中時間改為事件），由開發人員來定就行了。當然如果你是開發轉型的PM，你可以來決定，但為了后期的數據參數統計和分類，建議還是直接交給開發人員這里可以簡單舉例比如以UGC模塊，以發帖事件來進行說明，該頁面所能進行的操作都需要將其規則化，以事件名稱來確定每個操作的名稱，可以滿足將其規則化的目的。
十、其他需求描述綜上，基本一個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改變世界的點滴，人人都是產品經理關于作者。曾從事騰訊云產品設計與中興通訊產品研發，現金融產品經理一枚。歡迎交流
本文未經許可，禁止轉載。
QQ咨詢
客服中心
客戶案例