產(chǎn)品經(jīng)理PM如何撰寫一份“對標(biāo)大廠”的PRD

PRD是產(chǎn)品由立項階段進入到需求階段的最重要的一個文檔。

簡而言之，PRD就是將宏觀抽象化的業(yè)務(wù)，拆分成具體化的功能需求，并通過文字或圖像等方式呈現(xiàn)出來。

PRD文檔主要使用對象有：產(chǎn)品、設(shè)計、項目、開發(fā)、測試。產(chǎn)品經(jīng)理可以根據(jù)PRD進行功能自查，從而更加完整的梳理產(chǎn)品；設(shè)計師可以通過PRD來設(shè)計交互細節(jié)，并改善用戶體驗；項目經(jīng)理可以根據(jù)PRD拆分工作任務(wù)，并分配開發(fā)人員；開發(fā)人員可以根據(jù)PRD獲知整個產(chǎn)品的邏輯；測試人員可以根據(jù)PRD建用例，并進行可用性測試。

傳統(tǒng)的PRD文檔冗長而復(fù)雜，一方面不方便產(chǎn)品經(jīng)理清楚且全面的表達產(chǎn)品設(shè)計的相關(guān)細節(jié)，另一方面不方便產(chǎn)品經(jīng)理將需求簡單且清晰地傳達給PRD閱讀者。

二、PRD文檔的目的

PRD文檔是產(chǎn)品新人入門的一門必修課，是進入職場的敲門磚，也是產(chǎn)品經(jīng)理基本功的體現(xiàn)，更是衡量產(chǎn)品經(jīng)理整體思維的一個標(biāo)準(zhǔn)。

PRD文檔是每個產(chǎn)品經(jīng)理打交道最多的文檔。也是項目啟動之前，必須要通過項目組評審，并確定最終需求范圍的重要文檔。

PRD文檔在項目立項階段，可評估產(chǎn)品機會。在需求階段，可定義產(chǎn)品功能范圍。

PRD文檔可以梳理產(chǎn)品業(yè)務(wù)邏輯，記錄需求變更內(nèi)容，管理產(chǎn)品迭代過程，便于部門需求溝通。PRD文檔的好壞直接影響到開發(fā)進度、測試質(zhì)量以及最終的實現(xiàn)效果。

PRD文檔是產(chǎn)品經(jīng)理和開發(fā)人員溝通需求的重要工具，產(chǎn)品經(jīng)理一般用它做需求管理和版本管理。PRD文檔首先應(yīng)該展示的內(nèi)容是需求，如果一份PRD文檔能夠充分的表達用戶需求，那么它就可以作為需求驗收的標(biāo)準(zhǔn)。

三、如何寫PRD文檔

之前有些想轉(zhuǎn)行和剛?cè)腴T不久的產(chǎn)品朋友，在產(chǎn)品經(jīng)理朱學(xué)敏公眾號留言問我怎么寫PRD文檔。借著這個機會，給大家分享一下我自己的一點產(chǎn)品經(jīng)驗。

撰寫PRD文檔的方式有多種，常見的有Word、PPT、Wiki或Axure等，但我個人更傾向于直接在Axure中撰寫PRD。此外，描述需求或業(yè)務(wù)規(guī)則，我側(cè)重于用視化的結(jié)構(gòu)圖、流程圖和原型表示，文字只是作為補充說明。

PRD文檔內(nèi)容結(jié)構(gòu)包括：文檔概述、產(chǎn)品說明、全局說明、功能需求、非功能需求、改進建議等。基于以上幾個方面，從理論角度闡述，結(jié)合案例做分析。

1、文檔概述

1.1 修訂記錄

主要包括版本、時間、內(nèi)容、備注等，方便溝通和記錄產(chǎn)品成長路徑，為規(guī)劃未來產(chǎn)品迭代提供參考。以下是PMLink產(chǎn)品迭代的一個簡化修訂記錄。

1.2 項目背景

簡單描述項目的背景、目標(biāo)、定位和用戶等，讓成員對項目有整體的認(rèn)知以及明確方向。

1.3 閱讀對象

文檔的主要閱讀對象和使用者，一般包括產(chǎn)品、設(shè)計、項目、開發(fā)、測試和甲方負(fù)責(zé)人。

1.4 專業(yè)術(shù)語

對文檔中會出現(xiàn)一些專業(yè)名詞做解釋，方便項目成員理解業(yè)務(wù)并統(tǒng)一名稱。

2、產(chǎn)品說明

從產(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 用例圖

2.5 業(yè)務(wù)流程圖

2.6 需求列表

2.7 產(chǎn)品進度

2.8 開發(fā)進度

3、全局說明

對產(chǎn)品設(shè)定的一些行為準(zhǔn)則，按照既定標(biāo)準(zhǔn)、規(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 用例描述

用例描述文檔是用文本方式來表述的，為了更加清晰地描述用例，也可以選擇用例圖或流程圖來輔助說明。

用例名稱：該用例的名稱；

用例編號：該用例的編號，一般定義到功能Uc級；

操作角色：參與或執(zhí)行該用例的用戶。

優(yōu)先級：功能優(yōu)先級排序；功能目標(biāo)：功能要實現(xiàn)的預(yù)期效果；

前置條件：參與或執(zhí)行該用例的前提條件，或者所處的狀態(tài)；后置條件：執(zhí)行完畢后的結(jié)果或者狀態(tài)。

4.3 業(yè)務(wù)規(guī)則

業(yè)務(wù)規(guī)則是指對業(yè)務(wù)定義和約束的描述，用于維持業(yè)務(wù)結(jié)構(gòu)或控制和影響業(yè)務(wù)的行為。即告訴我們此功能在操作時有哪些約束條件。

以PMLink快捷登錄為例，會對操作、輸入框、內(nèi)容格式、長度、點亮、控件、數(shù)據(jù)之間的關(guān)聯(lián)性做出說明。產(chǎn)品在使用時要有相應(yīng)的業(yè)務(wù)規(guī)則，且業(yè)務(wù)規(guī)則必需是完整的、準(zhǔn)確的、易懂的。

業(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ù)崩潰的可能性。

6、改進建議

改進建議實際就是基于用戶體驗區(qū)優(yōu)化產(chǎn)品路徑。

網(wǎng)上有太多的PRD文檔，可以作為參考，但不是標(biāo)準(zhǔn)規(guī)范。最忌諱的就是把BAT大公司的文檔規(guī)范標(biāo)準(zhǔn)，按部就班的套用過來。要結(jié)合公司的實際需求，去撰寫適合自己產(chǎn)品團隊的PRD文檔。

寫好PRD不是一蹴而就的，除了基本的專業(yè)能力和邏輯思維，還得此外，要常收集、常反饋、?？偨Y(jié)。

寫PRD文檔不能為了面子工程或個人績效，寫一堆無關(guān)痛癢的廢話。這樣只會導(dǎo)致需求評審時，產(chǎn)品經(jīng)理說的天花亂墜，開發(fā)人員看得眼花繚亂。需求最后最后要回歸到時效性，在業(yè)務(wù)邏輯清晰的前提下，盡量用精簡的語言，把需求快速傳遞給開發(fā)。

一份接地氣的PRD文檔，一定是遵循整體邏輯清晰，語言簡潔易懂，信息實時共享，明確功能范圍，并快速需求落地的原則。總而言之，PRD文檔最重要的就是把需求表述清楚。