一、產(chǎn)品經(jīng)理的三大文檔之PRD文檔的意義
（一）百度百度
? 該文檔是產(chǎn)品項目由“概念化”階段進入到“圖紙化”階段的最主要的一個文檔，其作用就是“對MRD中的內(nèi)容進行指標化和技術(shù)化”，這個文檔的質(zhì)量好壞直接影響到研發(fā)部門是否能夠明確產(chǎn)品的功能和性能。
（二）簡單概述
跟項目成員說明產(chǎn)品的需求，可以更高效、高質(zhì)量的進行工作。
二、個人工作中的PRD文檔迭代路徑
（一）1.0版本（word+原型的形式）
15年多數(shù)PM都在用此形式編寫PRD文檔。
缺點：1.項目成員查看需要打開兩個文件進行查看，閱讀成本高、效率低；
?????????? 2.word文檔格式文字占了較大的篇幅，隨便一翻密密麻麻的文字~閱讀較枯燥，需求描述送達率較低；
（二）2.0版本（原型+便簽的形式）
新版Axure迭代出了便簽的形式，在原型旁邊附上便簽，在便簽寫上需求說明，再拉個虛線連接對應(yīng)的元件。
?缺點：頁面的需求說明較少時，此方法還是可以的~然而當(dāng)說明較多時，頁面上懸浮著許多虛線、五彩斑斕的便簽...視覺體現(xiàn)不好，而且展示的太多，在項目成員讀者看來也會無重點！
（三）3.0版本（原型+元件注釋+流程圖形式）
利用Axure新版需求控件的功能~把對應(yīng)的需求寫到元件說明里，流程圖用Axure畫（或者把visio畫好的流程圖帖過來），旨在把表達需求的輸出物整合到一起，自己在17年中之前竟然沒有發(fā)現(xiàn)Axure的這個功能（捂臉痛哭狀），雖說Axure、word等都是工具，但我們還是要善用工具！
三、PRD包含的內(nèi)容以及意義
先展示一下Axure制作的3.0版本的原型目錄
1.項目背景
簡單描述項目的背景、目標等，讓項目的參與者明白項目是為什么而做和價值所在，方便項目的參與者有整體的認知以及明確方向。
2.修訂歷史
寫清楚每次修改的編號、修改的內(nèi)容、備注等，方便溝通和追溯。
3.用戶范圍
本系統(tǒng)涉及的角色以及對應(yīng)角色的職能、描述、權(quán)限等
4.名詞術(shù)語表
具體專業(yè)名詞、縮寫的解釋以及說明，幫助項目成員方便理解業(yè)務(wù)并統(tǒng)一名稱。
5.迭代記錄
上線后的每一次迭代的記錄，產(chǎn)品迭代記錄了產(chǎn)品成長路徑，從產(chǎn)品的迭代中察覺產(chǎn)品動向，為規(guī)劃未來產(chǎn)品成長提供參考。
6.全局交互
? 記錄整個項目通用的交互形式，如：彈框樣式、異常頁面等，在某個頁面需要用到的時候直接寫引用規(guī)范就可以，避免重復(fù)設(shè)計。
7.項目排期進展
項目啟動定完大概的排期后，明確對應(yīng)職能人員以及對應(yīng)的時間節(jié)點，方便協(xié)作、跟進、追溯；
8.產(chǎn)品功能結(jié)構(gòu)圖
結(jié)構(gòu)化的描述系統(tǒng)內(nèi)部對需求實現(xiàn)的具體功能，便于功能評審、溝通等
9.用例圖
定義了系統(tǒng)的的功能需求，系統(tǒng)功能之間以及同功能參與者之間關(guān)系的鳥瞰圖，使讀者對象對功能需求、角色之間的關(guān)系有主體上的認知；
10.流程圖
以水流的形式由淺入深的描述事件、任務(wù)、管理等的過程，可以幫助設(shè)計人員梳理過程、邏輯、準確傳達需求、查漏補缺。流程圖又分為業(yè)務(wù)流程圖、頁面流程、功能流程、數(shù)據(jù)流程等，根據(jù)項目、團隊的需要，流程圖的粒度自行把控。
11.非功能需求
非功能性需求的描述，如：
(1) 性能需求：用戶在軟件響應(yīng)速度、結(jié)果精度、運行時資源消耗量等方面的要求；
(2) 可靠性需求：用戶在軟件失效的頻率、嚴重程度、易恢復(fù)性，以及故障可預(yù)測性等方面的要求；
(3) 易用性需求：用戶在界面的易用性、美觀性，以及對面向用戶的文檔和培訓(xùn)資料等方面的要求；
(4) 安全性需求：用戶在身份認證、授權(quán)控制、私密性等方面的要求；
(4) 運行環(huán)境約束：用戶對軟件系統(tǒng)運行環(huán)境的要求；
(5) 外部接口：用戶對待開發(fā)軟件系統(tǒng)與其他軟件系統(tǒng)或硬件設(shè)備之間的接口的要求；
(6) 數(shù)據(jù)監(jiān)控需求：數(shù)據(jù)埋點監(jiān)控，在新功能上線后，驗證是否達到預(yù)期的商業(yè)目標，用數(shù)據(jù)反饋驅(qū)動迭代；
四、優(yōu)秀PRD需要具備的要素
1.可驗證：對于功能性的描述，不要描述一些無法定性的東西，例如：支持高并發(fā)、響應(yīng)快都是模棱兩可的，無法驗證的；
2.正確、無歧義：確保文檔的表述跟你的思路是一致的，表述不會產(chǎn)生歧義；
3.一致：文檔中用詞用語一致，對于同一事物的表述應(yīng)該一樣，避免混用同義詞 ；
4.方便迭代：利于后期的修改以及調(diào)整；
5.可追蹤：每個功能性需求的來源應(yīng)該是清楚明白的
6.完備：MECE原則的思考方式盡量保證對產(chǎn)品功能需求表述的系統(tǒng)完整；
7.具有優(yōu)先級：產(chǎn)品的功能性需求是有先后主次的，對于一次性規(guī)劃叫多功能的PRD，應(yīng)該注明功能性需求的先后主次
最最最重要的：把問題、需求表述清楚！
五、元件庫的念叨
雖然現(xiàn)在網(wǎng)上有不少元件庫，但是真正實用，適合自己的少之又少，建議每個PM都花點時間花點時間整理一份屬于自己的元件庫，這樣可以提高畫圖效率、保證視覺的統(tǒng)一，整理元件庫的分類可以考慮從常用性、適用性、交互組件、邏輯組件、頁面框架等方面去考慮。
六、結(jié)語
其實PRD并沒有規(guī)定的格式，可以根據(jù)自己公司、項目階段等實際需要來寫適合自己產(chǎn)品團隊的PRD。寫文檔的目的在于把事情說清楚，且有記錄（防止秋后算賬），可傳閱，多跟研發(fā)人員溝通，重要的是讓他們了解需求，把問題和想法表述清楚才是王道！
?????????????????????????????????????????? ----------------歡迎討論、交流----------------
需要原型和組件庫的童鞋可關(guān)注“社稷獅筆記”，回復(fù)“原型”，即可獲取下載地址！本公眾號定期更新互聯(lián)網(wǎng)產(chǎn)品經(jīng)理干貨，歡迎眾汪討論交流~~~
???????????????????????????????????????????????? ? ? ? ?? 公眾號： 社稷獅筆記
