產(chǎn)品基本功不僅是基礎
曾經(jīng)有更新過關于PRD撰寫的案例。PRD的個人模版一直都需要新的輸入兽愤，調(diào)和自己的理解彼念，輸出為更適合的PRD方式。
今天為各位朋友帶來一個產(chǎn)品基本功的分享——產(chǎn)品需求文檔浅萧，這一篇分享將是我?guī)啄戤a(chǎn)品進階到今天逐沙，個人要求需求文檔目前的撰寫標準。
個人認為做的很細洼畅、復雜與否不是問題吩案，而是認識到做這件事的理由與目的
常常對于產(chǎn)品新人困惑的交互和功能字段解釋，如何將巧妙加入在需求文檔中帝簇？如果這樣做下去徘郭，相信開發(fā)和測試一定會少很多疑惑，所有的坑已經(jīng)在文檔中被搞干凈啦 特別要感謝PM臥龍的原創(chuàng)丧肴，部分PRD篇幅的撰寫集合了他的方式残揉。
但針對泳道圖、邏輯芋浮，和文字的標注我做了更新
01
需求概述
在需求概述前關于一些基本設置抱环，我采用以WORD WEB版式，并且字體我一直系統(tǒng)是微軟雅黑纸巷。
WEB版式方便橫向內(nèi)容瀏覽镇草，字體微軟雅黑我總認為看著比較舒服。
在需求概述中瘤旨，我首先將一個開文數(shù)據(jù)框圖梯啤，表示目前該需求的大體情況，讓開發(fā)或測試相應人員指導該文檔是做什么存哲、文檔當前的狀態(tài)条辟、該需求負責人是誰黔夭、修訂版本（當前文檔的修訂版本，并不是產(chǎn)品迭代版本
在做產(chǎn)品助理的時候羽嫡，這個文檔的開頭基本就在這里結(jié)束了本姥。但隨著在后期的產(chǎn)品積累上，杭棵，我將開頭添加了項目背景概述婚惫、需求來源、關聯(lián)負責人魂爪、需求執(zhí)行成員（項目成員）先舷、需求執(zhí)行周期（項目周期），下面我通過截圖的方式更新以上
1.背景概述
目前UGC模塊需要優(yōu)化滓侍，提升用戶體驗蒋川。
當前UGC模塊功能為：發(fā)帖功能、點贊功能撩笆、評論功能捺球、轉(zhuǎn)發(fā)功能
用戶執(zhí)行發(fā)帖流程：發(fā)帖入口——輸入內(nèi)容——發(fā)帖完成
目前UGC模塊功能進行了優(yōu)化，比如增加了過濾功能夕冲，用戶可以屏蔽相應的不感興趣內(nèi)容氮兵，增加了話題功能，用戶可以對感興趣內(nèi)容進行選取歹鱼。
將用戶發(fā)帖流程進行優(yōu)化泣栈，在不阻礙發(fā)帖體驗的情況下，增加了話題路徑弥姻，豐富了用戶選擇性南片，增加了平臺內(nèi)容多樣化
2.需求來源
本次需求來源負責人：KEVIN，部門：產(chǎn)品部
3.關聯(lián)負責人
4.需求執(zhí)行成員
這一點要說明的是庭敦，很多團隊可能沒有以上職位铃绒，尤其是在創(chuàng)業(yè)團隊，一人做多事螺捐，因此可以將做這個項目的人員拉進來颠悬。可能PM會做UI定血、UE赔癌，類似這樣的情況，也需要填表澜沟。
當然敏捷開發(fā)的創(chuàng)業(yè)團隊灾票，可能會當面溝通，文檔中存在執(zhí)行成員與否反而不重要茫虽，本來人就少刊苍，大家都心知肚明啦既们。
5.需求執(zhí)行周期
【項目執(zhí)行周期】
這里要說一點，這個是適用于我目前的團隊正什，因為有2次評審啥纸。但是開發(fā)需求評審的周期和UI評審的周期是反復、漫長的婴氮，并不是將每一次的評審開會時間填上去斯棒，而是將相應周期。
如：目前評審處于開發(fā)需求評審主经，UI還沒做荣暮，那么就是開發(fā)需求評審，這個時候往往會干掉一些需求罩驻，PM需要及時收集并且調(diào)整穗酥。
02
更新記錄
這一塊是我認為3年工作中，最為重要的一塊惠遏。最初做產(chǎn)品助理時候砾跃，文檔更新可能就是很簡單的一句話，但隨后發(fā)現(xiàn)爽哎，開發(fā)與測試人員每次最關注的就是你更新記錄蜓席，他可不想每次都去查找那一小部分更新內(nèi)容器一。
這個更新記錄可能是在開發(fā)需求評審后课锌，也可能是開發(fā)中進行更新，畢竟有一些需求是開會中不會遇見的祈秕，只有在正在開發(fā)中才會發(fā)現(xiàn)不合理渺贤。
這里值得注意的是首先分為4個屬性
新增
刪除
修改
新建
新建默認為相應模塊的首次使用，后期對于文檔的修改用新增请毛、刪除志鞍、修改即可，并且這里需要將修改方仿、新增的地方加入超鏈接固棚，方便開發(fā)進行查閱。
03
需求結(jié)構圖
這里主要是設計和技術開發(fā)人員了解產(chǎn)品需求的結(jié)構仙蚜，描述順序為主功能—子功能—子功能詳情頁
并且這里建議將每個頁面超鏈接后面的頁面詳情此洲，方便及時相應人員查看∥郏可以鏈接的地方為功能模塊—子功能模塊——詳情頁面，都做可鏈接。
當然這樣式比較費時間的踱蠢，通吃我是只有梳理結(jié)構圖，沒有做鏈接形式衷畦。
04
數(shù)據(jù)間關系
將功能塊中設計的用戶對象和功能模塊流程，將相應的流程涉及的數(shù)據(jù)關聯(lián)以流程圖的方式展現(xiàn)知牌，當然也可以用腦圖祈争，可以方便測試和開發(fā)人員指導哪一個數(shù)據(jù)是哪一個對象的，在哪一些流程中會增加或判別什么數(shù)據(jù)送爸。
TIPS：這一點對于大功能模塊來說比較常用铛嘱，但一些小的功能模塊，這一塊可以忽略不梳理袭厂，比如很常見的一個廣告BANNER等小功能模塊墨吓，想用的數(shù)據(jù)關系可以不用展示，與開發(fā)直接溝通好就行纹磺。
05
全局說明
全局說明這里分類分為3個類帖烘，如下圖
對于PM來說，一直被認為說所有都要知道橄杨，但又不需要所有都精通秘症，但在全局說明中，尤其是在創(chuàng)業(yè)團隊式矫，并沒有UED等專屬的部門乡摹，產(chǎn)品經(jīng)理可以把最基礎的功能全局和交互全局進行說明。
既然是全局采转，因此在所有的功能PRD文檔中聪廉，都需要體現(xiàn)，這里我們以比較常見的交互全局故慈、功能全局
彈層對話
加載
彈層菜單
搜索
導航
表格
按鈕
列表
進步器
以上是比較常見的全局控件或功能或交互板熊，在這個功能中會涉及哪些全局的控件或交互，PM需要將相應的全局控件或交互置于文檔中察绷，這里在這次UGC模塊中干签，有彈層對話與加載涉及全局，下面是全局的描述拆撼。
加載的模塊首先分為以下3種：頁面加載中容劳、內(nèi)容加載中、加載結(jié)果
1.頁面加載中
2.內(nèi)容加載（下拉闸度、松開）
3.頁面加載網(wǎng)絡正常卻沒數(shù)據(jù)
4.頁面加載網(wǎng)絡異常
5.頁面加載搜索沒有結(jié)果
下面羅列下文檔中竭贩，具體去怎么寫全局交互
分為：頁面間交互也頁面內(nèi)交互
1.頁面間交互
首先是對于NATIVE的交互，另外需要注意H5網(wǎng)頁的交互默認是不作處理的筋岛，因為就是淡入淡出的效果娶视。
頁面間之間的交互，可以進行自定義，但最終進入那個頁面肪获，每個頁面哪些地方可以進入寝凌，可以退出等，PM或交互設計師需要進行說明孝赫。以下我分為單張和多張圖示進行展示较木，頁面間交互應該如何說明
2.頁面內(nèi)交互
以上為移動端內(nèi)的頁面內(nèi)交互，可以看到基本為目前常見的人類手勢青柄，當然還有長安伐债、雙擊等交互，目前以上列舉的是比較常見的一些手勢
6
功清單能
在對于UGC模塊中致开，我將相應的子功能進行羅列峰锁，那么這里我們需要以用表格的方式進行統(tǒng)計，方便設計双戳、開發(fā)人員以及測試人員對工作量的評估虹蒋。
當然值得注意的是可能一個模塊下有子功能，子功能下面還有子功能飒货，這個時候建議方便文檔查看魄衅，就以2個層級進行區(qū)分，在后方描述的時候進行說明塘辅。
7
業(yè)務流程
這里的業(yè)務流程晃虫，我們默認是以用戶開始，依照用戶的操作扣墩，將其流程分為前端和服務端哲银，告知相應端開發(fā)人員應該做什么、不應該做什么沮榜。
當然這里移動端流程指向的用戶相對單一盘榨，當然也有按照用戶角色來進行區(qū)分的流程喻粹，常見的就是在ERP或者一些后臺產(chǎn)品設計中蟆融，PM需要根據(jù)不同的角色將相應流程進行繪制。
另一個流程圖比較常見就是上面說的根據(jù)默認以用戶流程守呜，將前端與服務端的流程涉及
PRD需求文檔型酥，在創(chuàng)業(yè)團隊中可能處于一個空置的情況下，為什么這么說查乒？因為你寫出來沒人看弥喉，只能作為一個留底
但在一些成熟性公司中，那么PRD文檔不僅僅起著留底的作用玛迄，將產(chǎn)品邏輯和用戶使用邏輯描述得清楚由境，將方便開發(fā)人員以及測試人員知道如何去進行開發(fā)和驗收，涉及到數(shù)據(jù)交互的都應該在服務端與
但值得注意的是流程圖千萬要清晰、明了虏杰，不要彎彎曲曲讥蟆，混成一團。在與產(chǎn)品朋友們交流中
8
需求/功能描述
到這里就是PRD主要的篇幅部分纺阔，在這里我建議將功能的每個頁面進行列舉瘸彤，比如某一個功能
每個功能的描述，我們既然按照功能點進行分類笛钝，將不同的子功能分別列舉质况。接下來在文檔中我們需要展現(xiàn)的是三部分內(nèi)容：
1.頁面需求描述
說明該頁面是干什么的？并且該頁面出現(xiàn)的地方玻靡，在什么時間出現(xiàn)结榄，需要有什么條件要求
2.交互手勢
上面所說的交互手勢在這里就可以列舉出來了，當前頁面能做什么交互手勢囤捻？哪些手勢不能做潭陪？
該頁面如果只有點擊手勢，那么即在手勢下面寫有最蕾，并且描述在IOS與安卓那個版本下有依溯，如果沒有是否需要開發(fā)
3.用例描述
描述點擊相應控件或位置，頁面后進入到哪一個頁面瘟则，以什么方式（滑動黎炉？彈出？）
這里以開紅包方式來描述
用例1：??點擊開醋拧，頁面左滑進入紅包首頁?用例結(jié)束
4.異常情況
這里的異常情況或許很多PM朋友都沒有寫進去慷嗜，說實話，今天以前我也沒有寫丹壕。但和產(chǎn)品朋友交流后我發(fā)現(xiàn)庆械，其實異常情況的知曉能夠反映出作為PM你目前的經(jīng)驗豐富情況，到底該頁面下那些異常會出現(xiàn)菌赖，你是否能預知缭乘？
大多數(shù)PM或許會將該異常情況統(tǒng)一交給測試來處理，因此為了百分百保證這一份分享是最完整的PRD干貨琉用，今天就把這個加上了堕绩。
用例1：用戶未登錄，點擊紅包開邑时，頁面左滑進入紅包首頁?用例結(jié)束
9
數(shù)據(jù)統(tǒng)計需求
以上我們的PRD差不多完成了70%奴紧，接下來就是為了后期驗證跟進做的一些輔助性跟進，那就是對于數(shù)據(jù)的統(tǒng)計需求晶丘。數(shù)據(jù)統(tǒng)計的需求我們也需要在文檔中進行撰寫黍氮，當然如果有專門的數(shù)據(jù)部門，我建議PM可以交給數(shù)據(jù)部門完成，PM將其需求過渡給數(shù)據(jù)部門沫浆。
當然不懂數(shù)據(jù)的PM肯定不是好PM觉壶，為此能夠了解產(chǎn)品哪些地方有數(shù)據(jù)統(tǒng)計，我還是把相應的數(shù)據(jù)要求提交在文檔中件缸。
這一點必須說明的是關于自定義事件LABEL和自定義事件參數(shù)铜靶，（圖中時間改為事件），由開發(fā)人員來定就行了他炊。當然如果你是開發(fā)轉(zhuǎn)型的PM争剿，你可以來決定，但為了后期的數(shù)據(jù)參數(shù)統(tǒng)計和分類痊末，建議還是直接交給開發(fā)人員
這里可以簡單舉例比如以UGC模塊蚕苇，以發(fā)帖事件來進行說明，該頁面所能進行的操作都需要將其規(guī)則化凿叠，以事件名稱來確定每個操作的名稱涩笤，可以滿足將其規(guī)則化的目的。
10
其他需求描述
綜上盒件，基本一個PRD文檔就算完成了蹬碧，但在工作中一個功能模塊或一個版本的迭代往往還需要涉及其他需求，涉及人力炒刁、財務資源的需求恩沽，以及對于每次評審或小團隊溝通的記錄。這里我也一并同步出來自己在工作中做的一些需求描述翔始，也可以集中放置于項目文檔或該PRD文檔中罗心。
性能需求
服務需求
營銷需求
安全需求
法務需求
幫助需求
異常場景
溝通記錄
風險描述
1.性能需求
性能需求可以以表格的形式對相應的功能模塊進行要求，如紅包點擊彈出的時間在3S內(nèi)城瞎，成功率是99%渤闷，并發(fā)數(shù)是20000。
2.服務需求
這個涉及到產(chǎn)品客服脖镀，產(chǎn)品人員需要知道要占用客服時間飒箭、相應問題解決的方案是什么？每個問題的優(yōu)先級是什么认然？產(chǎn)品需要從客服人員中得到什么信息补憾？這個需要PM對當前產(chǎn)品數(shù)據(jù)分析漫萄，才能更好的對接資源卷员，總不能要求其他部門把全部資源用在你手上吧。
這里首先要說明的是關于成本建議做一個標準腾务，如果是按照價錢就統(tǒng)一為錢毕骡；如果為時間就統(tǒng)一為時間；預知服務頻率需要PM進行數(shù)據(jù)分析，給予一個恰當?shù)姆秶?/p>
3.營銷需求
營銷需求和上方的服務需求同樣未巫，也是需要產(chǎn)品經(jīng)理進行數(shù)據(jù)分析窿撬，為達到目標計劃一個預計營銷需求，當然其營銷的平臺與方式可以和營銷部進行策劃溝通叙凡。
4.法務需求
法務需求與以上2點需求類似劈伴，建議可以合成為一張表格，將分別的需求資源供應方分類握爷，這樣可以更快的在一張表中了解該項目的資源消耗情況跛璧。
5.財務需求
同法務需求一樣
6.幫助需求
幫助需求可以解釋為FAQ培訓，將產(chǎn)品上線后對于該項目涉及人員和部門進行培訓新啼，建立相應的FAQ追城，并且對于活動類模塊也需要運營提供活動FAQ。
7.項目風險
如果是功能模塊迭代可以說明為版本風險燥撞，但是對于產(chǎn)品的迭代中座柱，其需要明確新增、取締的風險物舒，將其可能存在的風險隱患進行描述
提前說明一些風險能夠給予BOSS一些心理的準備色洞，當然這個風險的預測也不是萬能的，如果出現(xiàn)一些技術無法解決的問題也需要PM注意埋坑冠胯。但將能夠預測的風險進行預測锋玲，也是PM的一個硬戰(zhàn)。
以上就是關于涵叮，目前PRD文檔的撰寫惭蹂，關于交互與字段的描述相信能夠為產(chǎn)品新人提供幫助
最后關于評審中的溝通會議記錄，我也同步一下模板
這樣有了會議溝通記錄之后割粮，相信產(chǎn)品人能夠減少一些坑或者識別一些坑盾碗，避免一些人冤枉PM說：領導這是你之前說的！XX這是你說的
