覺得文章不錯(cuò)，記得點(diǎn)贊＆在看
產(chǎn)品經(jīng)理有一個(gè)必備技能：文檔技能。
輸出的文檔內(nèi)容包含了需求文檔、MRD等等，而需求文檔的撰寫標(biāo)準(zhǔn)，各家公司都有自己的規(guī)范。
所以一個(gè)產(chǎn)品經(jīng)理隨著工作時(shí)間久了，在不同的公司工作，也會(huì)積累不同的標(biāo)準(zhǔn)。對于沒有標(biāo)準(zhǔn)或規(guī)范的團(tuán)隊(duì)或個(gè)人來說，找到一個(gè)好用的需求文檔模版，也可以提升效率。
下面這份模板時(shí)間過去了6年，但仍然是一個(gè)非常好用的模板。畢竟需求文檔不能做的很細(xì)，會(huì)導(dǎo)致下游產(chǎn)品設(shè)計(jì)、開發(fā)閱讀效率降低，反而不能夠理解需求。
我做產(chǎn)品經(jīng)理工作累計(jì)8年了，也積累了”標(biāo)準(zhǔn)“的PRD文檔。今天這篇文章分享下這個(gè)需求文檔模版，在文章末尾回復(fù)關(guān)鍵詞：“PRD”，可以領(lǐng)取下載。
需求前我會(huì)將文檔設(shè)置為web版式，字體使用微軟雅黑，標(biāo)題分級用默認(rèn)等級，方便進(jìn)行瀏覽和閱讀。
而如果你選擇使用在線文檔，那么就不用設(shè)置。
在需求概述中，我首先會(huì)使用一個(gè)表格來羅列當(dāng)前需求是什么、需求的版本、以及需求的完成日期和需求的狀態(tài)。
用于簡單陳述當(dāng)前的需求狀況，讓閱讀者知道該文檔是做什么、文檔當(dāng)前的狀態(tài)、該需求負(fù)責(zé)人是誰、修訂版本（當(dāng)前文檔的修訂版本，并不是產(chǎn)品迭代版本
背景概述是說明需求出現(xiàn)的背景是什么，是基于什么原因想完成什么。比如下面是社區(qū)論壇UGC功能模塊需求。
將用戶發(fā)帖流程優(yōu)化，在不阻礙發(fā)帖體驗(yàn)的情況下，增加了話題路徑，豐富了用戶選擇性，滿足平臺(tái)運(yùn)營內(nèi)容多樣化的需求
原有功能模塊為：發(fā)帖功能、點(diǎn)贊功能、評論功能、轉(zhuǎn)發(fā)功能
用戶執(zhí)行發(fā)帖流程：發(fā)帖入口——輸入內(nèi)容——發(fā)帖完成
同時(shí)因?yàn)閮?nèi)容多樣性后，用戶需要有針對性的選擇內(nèi)容瀏覽。針對信息流進(jìn)行了優(yōu)化，增加了過濾功能，用戶可以屏蔽相應(yīng)的不感興趣內(nèi)容，增加了話題功能，用戶可以對感興趣內(nèi)容進(jìn)行選取。
本次需求來源負(fù)責(zé)人：Kevin，部門：產(chǎn)品部
3.關(guān)聯(lián)負(fù)責(zé)人
需求執(zhí)行成員給出了具體的項(xiàng)目各個(gè)聯(lián)系人。這一點(diǎn)要說明的是，如果團(tuán)隊(duì)沒有以上職位，可以將做這個(gè)項(xiàng)目的人員拉進(jìn)來。可能PM會(huì)做UI、UE，類似這樣的情況，也需要填表。
當(dāng)然敏捷開發(fā)的創(chuàng)業(yè)團(tuán)隊(duì)，可能會(huì)當(dāng)面溝通，文檔中存在執(zhí)行成員與否反而不重要，本來人就少，大家都心知肚明啦。
每個(gè)公司的研發(fā)流程有一些區(qū)別，比如上面是適用于在產(chǎn)品研發(fā)人員在20人以內(nèi)的團(tuán)隊(duì)，有2次評審。
需求評審周期和UI評審的周期是反復(fù)、漫長的，并不是將每一次的評審開會(huì)時(shí)間填上去，而是將相應(yīng)周期。
如：目前評審處于需求評審，UI還沒做，那么就屬于開發(fā)需求評審。
這一塊是我認(rèn)為需求文檔中，最為重要的一塊。
文檔更新可能是很簡單的一句話，但卻是開發(fā)與測試人員每次最關(guān)注的就是你的更新記錄，他可不想每次都去查找那一小部分更新內(nèi)容。
這個(gè)更新記錄可以在需求評審后，也可以是開發(fā)中更新，畢竟有一些需求是開會(huì)中不會(huì)遇見的，只有在正在開發(fā)中才會(huì)發(fā)現(xiàn)不合理。
新建默認(rèn)為相應(yīng)模塊的首次使用，后期對于文檔的修改用新增、刪除、修改即可，并且這里需要將修改、新增的地方加入超鏈接，方便開發(fā)進(jìn)行查閱。
這里介紹了產(chǎn)品需求的全體結(jié)構(gòu)，描述順序?yàn)橹鞴δ堋庸δ堋庸δ茉斍轫?/strong>
并且這里建議將每個(gè)頁面超鏈接指向需求文檔后面的功能詳情，方便相應(yīng)人員查看。
鏈接的方式為功能模塊—子功能模塊——詳情頁面，都做可鏈接。
當(dāng)然這樣式比較費(fèi)時(shí)間的，通吃我是只有梳理結(jié)構(gòu)圖，沒有做鏈接形式。
通過以用戶的方式來模擬功能模塊流程，將流程涉及的數(shù)據(jù)關(guān)聯(lián)以流程圖展現(xiàn)，當(dāng)然也可以用腦圖，可以方便測試和開發(fā)人員指導(dǎo)哪一個(gè)數(shù)據(jù)是哪一個(gè)對象的，在哪一些流程中會(huì)增加或判別什么數(shù)據(jù)。
這一點(diǎn)對于大功能模塊來說比較常用，但一些小的功能模塊，這一塊可以不梳理，比如很常見的一個(gè)廣告BANNER等小功能模塊，想用的數(shù)據(jù)關(guān)系可以不用展示，與開發(fā)直接溝通好就行。
全局說明指的是在多個(gè)功能、頁面會(huì)存在的相同交互或邏輯，這里分類分為3個(gè)類，如下圖
全局說明中，產(chǎn)品經(jīng)理可以把最基礎(chǔ)的功能全局和交互全局進(jìn)行說明。在所有的功能PRD文檔中，都需要體現(xiàn)，這里我們列舉了比較常見的交互全局、功能全局
彈層對話
加載
彈層菜單
搜索
導(dǎo)航
表格
按鈕
列表
進(jìn)步器
在這個(gè)功能中會(huì)涉及哪些全局的控件或交互，PM需要將相應(yīng)的全局控件或交互置于文檔中，這里在這次UGC模塊中，有彈層對話與加載涉及全局，下面是全局的描述。
加載的模塊首先分為以下3種：頁面加載中、內(nèi)容加載中、加載結(jié)果
3.頁面加載網(wǎng)絡(luò)正常卻沒數(shù)據(jù)
產(chǎn)品經(jīng)理通過全局交互定義頁面間之間的交互，每個(gè)頁面哪些地方可以進(jìn)入，可以退出等。以下我分為單張和多張圖示進(jìn)行展示，頁面間交互應(yīng)該如何說明
、
以上為移動(dòng)端內(nèi)的頁面內(nèi)交互，當(dāng)然還有長安、雙擊等交互，目前以上列舉的是比較常見的一些手勢
在對于UGC模塊中，我將相應(yīng)的子功能進(jìn)行羅列，方便設(shè)計(jì)、開發(fā)人員以及測試人員對工作量的評估。
當(dāng)然值得注意的是可能一個(gè)模塊下有子功能，子功能下面還有子功能，這個(gè)時(shí)候建議方便文檔查看，就以2個(gè)層級進(jìn)行區(qū)分，在后方描述的時(shí)候進(jìn)行說明。
是以用戶開始，依照用戶的操作，將其流程分為前端和服務(wù)端2類流程，告知相應(yīng)端開發(fā)人員應(yīng)該做什么、不應(yīng)該做什么。
前端是指具體在系統(tǒng)里，PM需要根據(jù)不同的角色將相應(yīng)流程進(jìn)行繪制。
另一個(gè)流程圖就是后端服務(wù)流程，根據(jù)默認(rèn)的用戶流程，將系統(tǒng)APP、后臺(tái)之間的信息交互進(jìn)行記錄，有時(shí)候我們會(huì)用時(shí)序圖進(jìn)行記錄。
根據(jù)前端與服務(wù)端不同處理進(jìn)行分類
PRD文檔中的流程圖，將產(chǎn)品邏輯和用戶使用邏輯描述得清楚，將方便開發(fā)人員以及測試人員知道如何去進(jìn)行開發(fā)和驗(yàn)收，涉及到數(shù)據(jù)交互的都應(yīng)該在服務(wù)端與
值得注意的是流程圖千萬要清晰、明了，不要彎彎曲曲，混成一團(tuán)。在與產(chǎn)品朋友們交流中
到這里就是PRD主要的內(nèi)容部分，我建議將功能的每個(gè)頁面進(jìn)行列舉，比如某一個(gè)功能
每個(gè)功能的描述，按照功能點(diǎn)進(jìn)行拆解，以此羅列子功能。接下來在文檔中我們需要展現(xiàn)的是三部分內(nèi)容：
說明該頁面是干什么的？并且該頁面出現(xiàn)的地方，在什么時(shí)間出現(xiàn)，需要有什么條件要求
上面所說的交互手勢在這里就可以列舉出來了，當(dāng)前頁面能做什么交互手勢？哪些手勢不能做？
該頁面如果只有點(diǎn)擊手勢，那么即在手勢下面寫有，并且描述在IOS與安卓那個(gè)版本下有，如果沒有是否需要開發(fā)
描述點(diǎn)擊相應(yīng)控件或位置，頁面后進(jìn)入到哪一個(gè)頁面，以什么方式（滑動(dòng)？彈出？）
用例1： 點(diǎn)擊開，頁面左滑進(jìn)入紅包首頁 用例結(jié)束
異常情況的知曉能夠反映出作為PM的經(jīng)驗(yàn)豐富情況，到底該頁面下那些異常會(huì)出現(xiàn)，你是否能預(yù)知？
PM或許會(huì)將該異常情況統(tǒng)一交給測試來處理。
異常情況：用戶未登錄，點(diǎn)擊紅包開，頁面左滑進(jìn)入紅包首頁 用例結(jié)束
5.數(shù)據(jù)統(tǒng)計(jì)需求
以上的部分，可以將PRD差不多完成了70%，接下來就是為了后期驗(yàn)證做一些輔助性需求，讓需求更加完整。
數(shù)據(jù)統(tǒng)計(jì)的需求我們也需要在文檔中進(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)計(jì)，我還是把相應(yīng)的數(shù)據(jù)要求提交在文檔中。
【頁面點(diǎn)擊數(shù)據(jù)模板】
關(guān)于自定義事件LABEL和自定義事件參數(shù)，（圖中時(shí)間改為事件），由開發(fā)人員來定就行了。當(dāng)然如果你是開發(fā)轉(zhuǎn)型的PM，你可以來決定，為了后期的數(shù)據(jù)參數(shù)統(tǒng)計(jì)和分類，建議還是直接交給開發(fā)人員
比如以UGC模塊，以發(fā)帖事件來進(jìn)行說明，該頁面所能進(jìn)行的操作都需要將其規(guī)則化，以事件名稱來確定每個(gè)操作的名稱，可以滿足將其規(guī)則化的目的。
綜上，基本一個(gè)PRD文檔就算完成了，但在工作中一個(gè)功能模塊或一個(gè)版本的迭代往往還需要涉及其他需求，涉及人力、財(cái)務(wù)資源的需求，以及對于每次評審或小團(tuán)隊(duì)溝通的記錄。這里我也一并同步出來自己在工作中做的一些需求描述，也可以集中放置于項(xiàng)目文檔或該P(yáng)RD文檔中。
性能需求
服務(wù)需求
營銷需求
安全需求
法務(wù)需求
幫助需求
異常場景
溝通記錄
風(fēng)險(xiǎn)描述
性能需求可以以表格的形式對相應(yīng)的功能模塊進(jìn)行要求，如紅包點(diǎn)擊彈出的時(shí)間在3S內(nèi)，成功率是99%，并發(fā)數(shù)是20000。
這個(gè)涉及到產(chǎn)品客服，產(chǎn)品人員需要知道要占用客服時(shí)間、相應(yīng)問題解決的方案是什么？每個(gè)問題的優(yōu)先級是什么？產(chǎn)品需要從客服人員中得到什么信息？這個(gè)需要PM對當(dāng)前產(chǎn)品數(shù)據(jù)分析，才能更好的對接資源，總不能要求其他部門把全部資源用在你手上吧。
這里首先要說明的是關(guān)于成本建議做一個(gè)標(biāo)準(zhǔn)，如果是按照價(jià)錢就統(tǒng)一為錢；如果為時(shí)間就統(tǒng)一為時(shí)間；預(yù)知服務(wù)頻率需要PM進(jìn)行數(shù)據(jù)分析，給予一個(gè)恰當(dāng)?shù)姆秶?br style="outline: 0px;">
營銷需求和上方的服務(wù)需求同樣，也是需要產(chǎn)品經(jīng)理進(jìn)行數(shù)據(jù)分析，為達(dá)到目標(biāo)計(jì)劃一個(gè)預(yù)計(jì)營銷需求，當(dāng)然其營銷的平臺(tái)與方式可以和營銷部進(jìn)行策劃溝通。
法務(wù)需求與以上2點(diǎn)需求類似，建議可以合成為一張表格，將分別的需求資源供應(yīng)方分類，這樣可以更快的在一張表中了解該項(xiàng)目的資源消耗情況。
幫助需求可以解釋為FAQ培訓(xùn)，將產(chǎn)品上線后對于該項(xiàng)目涉及人員和部門進(jìn)行培訓(xùn)，建立相應(yīng)的FAQ，并且對于活動(dòng)類模塊也需要運(yùn)營提供活動(dòng)FAQ。
7.項(xiàng)目風(fēng)險(xiǎn)
【項(xiàng)目風(fēng)險(xiǎn)】
如果是功能模塊迭代可以說明為版本風(fēng)險(xiǎn)，但是對于產(chǎn)品的迭代中，其需要明確新增、取締的風(fēng)險(xiǎn)，將其可能存在的風(fēng)險(xiǎn)隱患進(jìn)行描述
這樣有了會(huì)議溝通記錄之后，相信產(chǎn)品人能夠減少一些坑或者識(shí)別一些坑，避免一些人冤枉PM說：領(lǐng)這是你之前說的！XX這是你說的！
一套專注產(chǎn)品設(shè)計(jì)的電子刊
講解了需求調(diào)研&用戶研究、功能減法、組合、微創(chuàng)新、迭代框架的5個(gè)步驟。每周更新2-4節(jié)，是一套非常好用的產(chǎn)品設(shè)計(jì)方法論。
電子刊新書：累計(jì)20萬字，8個(gè)章節(jié)，一個(gè)簡易設(shè)計(jì)方法
