如何撰寫一份“對標大廠”的PRD
產(chǎn)品經(jīng)理從入門（滿足工作需要）到進階（提出解決方案），重要的是學會撰寫一份PRD文檔。
PRD文檔是產(chǎn)品入門的一門必修課，是進入職場的敲門磚，也是產(chǎn)品經(jīng)理基本功的體現(xiàn)，更是衡量產(chǎn)品經(jīng)理整體思維的一個標準。
PRD是將宏觀抽象化的業(yè)務(wù)，拆分成具體化的功能需求，并通過文字或圖像等方式呈現(xiàn)出來。
PRD文檔是每個產(chǎn)品經(jīng)理打交道最多的文檔。也是項目啟動之前，必須要通過項目組評審，并確定最終需求范圍的重要文檔。
產(chǎn)品經(jīng)理一般用它做需求管理和版本管理。PRD文檔首先應(yīng)該展示的內(nèi)容是需求，如果一份PRD文檔能夠充分的表達用戶需求，那么它就可以作為需求驗收的標準。
撰寫PRD文檔的方式有多種，常見的有Word、PPT、Wiki或Axure等，但我個人更傾向于直接在Axure中撰寫PRD。此外，描述需求或業(yè)務(wù)規(guī)則，我側(cè)重于用視化的結(jié)構(gòu)圖、流程圖和原型表示，文字只是作為補充說明。
網(wǎng)上有太多的PRD文檔，可以作為參考，但不是標準規(guī)范。最忌諱的就是把BAT大公司的文檔規(guī)范標準，按部就班的套用過來。要結(jié)合公司的實際需求，去撰寫適合自己產(chǎn)品團隊的PRD文檔。
因此，對標阿里、騰訊、字節(jié)跳動等大廠，基于PRD文檔的文檔概述、項目概述、產(chǎn)品規(guī)范、功能需求、非功能需求等方面，從理論角度闡述，結(jié)合案例來撰寫一份PRD文檔。
1.文檔概述
1.1 修訂記錄
主要包括版本、時間、內(nèi)容、備注等，方便溝通和記錄產(chǎn)品成長路徑，為規(guī)劃未來產(chǎn)品迭代提供參考。以下是華創(chuàng)微課產(chǎn)品迭代的一個簡化修訂記錄。
1.2 項目背景
簡單描述項目的背景、目標、定位和用戶等，讓成員對項目有整體的認知以及明確方向。
1.3 閱讀對象
文檔的主要閱讀對象和使用者，一般包括產(chǎn)品、設(shè)計、項目、開發(fā)、測試和甲方負責人。
?
1.4 專業(yè)術(shù)語
對文檔中會出現(xiàn)一些專業(yè)名詞做解釋，方便項目成員理解業(yè)務(wù)并統(tǒng)一名稱。
?
2.項目概述
從產(chǎn)品生命周期了解各個階段的運營活動，比如產(chǎn)品路線圖、功能清單、產(chǎn)品結(jié)構(gòu)設(shè)計、用例圖、業(yè)務(wù)流程圖、需求列表、產(chǎn)品進度、開發(fā)進度等。
?
2.1 產(chǎn)品路線圖
2.2?功能清單
2.3?產(chǎn)品結(jié)構(gòu)設(shè)計
?
2.4 UML建模
?
2.5?業(yè)務(wù)流程圖
2.6?需求列表
2.7?產(chǎn)品進度
?
2.8?開發(fā)進度
?
3.產(chǎn)品規(guī)范
對產(chǎn)品設(shè)定的一些行為準則，按照既定標準、規(guī)范的要求進行操作。
比如頁面設(shè)計規(guī)范、產(chǎn)品狀態(tài)規(guī)范、操作提示規(guī)范、數(shù)據(jù)加載規(guī)范、消息通知規(guī)范等。
?
3.1 頁面設(shè)計規(guī)范
?
3.2 產(chǎn)品狀態(tài)規(guī)范
?
3.3?操作提示規(guī)范
?
3.4?數(shù)據(jù)加載規(guī)范
?
3.5?消息通知規(guī)范
?
4.功能需求
功能需求一般是由四部分組成，功能總覽、頁面原型、用例描述、業(yè)務(wù)規(guī)則。主要是對所有的產(chǎn)品功能的描述和規(guī)劃。
其實就是通過場景模擬，告訴用戶此功能主要干什么的，并了解產(chǎn)品在哪種情況下會被用戶使用。
?
4.1 原型頁面
常見的原型設(shè)計方式有手繪原型、灰模原型、交互原型。
產(chǎn)品經(jīng)理一般是畫低保真的手繪原型或灰模原型，而高保真的交互原型更多是讓UI去實現(xiàn)，但我們要在軟件需求中，說明所有頁面的展示及每個功能的狀態(tài)。
?
4.2 用例描述
用例描述文檔是用文本方式來表述的，為了更加清晰地描述用例，也可以選擇用例圖或流程圖來輔助說明。
?
4.3 業(yè)務(wù)規(guī)則
業(yè)務(wù)規(guī)則是指對業(yè)務(wù)定義和約束的描述，用于維持業(yè)務(wù)結(jié)構(gòu)或控制和影響業(yè)務(wù)的行為。即告訴我們此功能在操作時有哪些約束條件。
?
以華創(chuàng)微課快捷登錄為例，會對操作、輸入框、內(nèi)容格式、長度、點亮、控件、數(shù)據(jù)之間的關(guān)聯(lián)性做出說明。
產(chǎn)品在使用時要有相應(yīng)的業(yè)務(wù)規(guī)則，且業(yè)務(wù)規(guī)則必須是完整的、準確的、易懂的。
?
業(yè)務(wù)規(guī)則將系統(tǒng)處理的業(yè)務(wù)邏輯從程序代碼中抽取出來，將其轉(zhuǎn)變?yōu)楹唵蔚臉I(yè)務(wù)規(guī)則，以結(jié)構(gòu)化的業(yè)務(wù)規(guī)則數(shù)據(jù)來表示業(yè)務(wù)行為。這樣用戶無需找程序員幫忙，就可以更改業(yè)務(wù)規(guī)則。
??
最典型的就是CRM客戶關(guān)系管理系統(tǒng)，其復(fù)雜且多變的的業(yè)務(wù)規(guī)則，就需要一套業(yè)務(wù)規(guī)則引擎的架構(gòu)設(shè)計。
?
5.非功能需求
非功能性需求是指軟件產(chǎn)品為滿足用戶業(yè)務(wù)需求而必須具有且除功能需求以外的特性。
一般會涉及到的有：性能需求、安全需求、可靠性需求、數(shù)據(jù)監(jiān)控需求、系統(tǒng)需求、運行環(huán)境需求、外部接口需求等。
?
以性能需求為例，我們會關(guān)注每秒處理的事務(wù),功能操作的響應(yīng)時間,頁面刷新時間。以系統(tǒng)需求為例，我們會關(guān)注服務(wù)器連接失敗后的重啟次數(shù).時間引起失敗的比例 失敗時數(shù)據(jù)崩潰的可能性。
?
一份接地氣的PRD文檔，一定是遵循整體邏輯清晰，語言簡潔易懂，信息實時共享，明確功能范圍，并快速需求落地的原則。
?
寫好PRD不是一蹴而就的，除了基本的專業(yè)能力和邏輯思維，還要常收集、常反饋、常總結(jié)。
?
寫PRD文檔不能為了面子工程或個人績效，寫一堆無關(guān)痛癢的廢話。這樣只會導(dǎo)致需求評審時，產(chǎn)品經(jīng)理說的天花亂墜，開發(fā)人員看得眼花繚亂。需求最后最后要回歸到時效性，在業(yè)務(wù)邏輯清晰的前提下，盡量用精簡的語言，把需求快速傳遞給開發(fā)。
總而言之，撰寫PRD最重要的就是把需求表述清楚，并讓開發(fā)“傻瓜式”閱讀需求文檔。
·········?做產(chǎn)品，找朱哥?·········
朱哥的新書《金融產(chǎn)品方法論》已出版，作為市面上第一本講互聯(lián)網(wǎng)金融的產(chǎn)品經(jīng)理書籍，8年金融產(chǎn)品經(jīng)驗沉淀，15位行業(yè)專家推薦。已在京東、當當?shù)荣徫锲脚_開售，如有興趣，歡迎金融朋友捧場惠購。