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

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

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

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

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

二、PRD文檔的目的

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

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

PRD文檔在項(xiàng)目立項(xiàng)階段，可評(píng)估產(chǎn)品機(jī)會(huì)。在需求階段，可定義產(chǎn)品功能范圍。

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

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

三、如何寫(xiě)PRD文檔

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

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

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

1、文檔概述

1.1 修訂記錄

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

1.2 項(xiàng)目背景

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

1.3 閱讀對(duì)象

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

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

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

2、產(chǎn)品說(shuō)明

從產(chǎn)品生命周期了解各個(gè)階段的運(yùn)營(yíng)活動(dòng)，比如產(chǎn)品路線圖、功能清單、產(chǎn)品結(jié)構(gòu)設(shè)計(jì)、用例圖、業(yè)務(wù)流程圖、需求列表、產(chǎn)品進(jìn)度、開(kāi)發(fā)進(jìn)度等。

2.1 產(chǎn)品路線圖

2.2 功能清單

2.3 產(chǎn)品結(jié)構(gòu)設(shè)計(jì)

2.4 用例圖

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

2.6 需求列表

2.7 產(chǎn)品進(jìn)度

2.8 開(kāi)發(fā)進(jìn)度

3、全局說(shuō)明

對(duì)產(chǎn)品設(shè)定的一些行為準(zhǔn)則，按照既定標(biāo)準(zhǔn)、規(guī)范的要求進(jìn)行操作。比如頁(yè)面設(shè)計(jì)規(guī)范、產(chǎn)品狀態(tài)規(guī)范、操作提示規(guī)范、數(shù)據(jù)加載規(guī)范、消息通知規(guī)范等。

3.1 頁(yè)面設(shè)計(jì)規(guī)范

3.2 產(chǎn)品狀態(tài)規(guī)范

3.3 操作提示規(guī)范

3.4 數(shù)據(jù)加載規(guī)范

3.5 消息通知規(guī)范

4、功能需求

功能需求一般是由四部分組成，功能總覽、頁(yè)面原型、用例描述、業(yè)務(wù)規(guī)則。主要是對(duì)所有的產(chǎn)品功能的描述和規(guī)劃。其實(shí)就是通過(guò)場(chǎng)景模擬，告訴用戶此功能主要干什么的，并了解產(chǎn)品在哪種情況下會(huì)被用戶使用。

4.1 原型頁(yè)面

常見(jiàn)的原型設(shè)計(jì)方式有手繪原型、灰模原型、交互原型。產(chǎn)品經(jīng)理一般是畫(huà)低保真的手繪原型或灰模原型，而高保真的交互原型更多是讓UI去實(shí)現(xiàn)，但我們要在軟件需求中，說(shuō)明所有頁(yè)面的展示及每個(gè)功能的狀態(tài)。

4.2 用例描述

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

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

用例編號(hào)：該用例的編號(hào)，一般定義到功能Uc級(jí)；

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

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

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

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

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

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

業(yè)務(wù)規(guī)則將系統(tǒng)處理的業(yè)務(wù)邏輯從程序代碼中抽取出來(lái)，將其轉(zhuǎn)變?yōu)楹?jiǎn)單的業(yè)務(wù)規(guī)則，以結(jié)構(gòu)化的業(yè)務(wù)規(guī)則數(shù)據(jù)來(lái)表示業(yè)務(wù)行為。這樣用戶無(wú)需找程序員幫忙，就可以更改業(yè)務(wù)規(guī)則。

最典型的就是CRM客戶關(guān)系管理系統(tǒng)，其復(fù)雜且多變的的業(yè)務(wù)規(guī)則，就需要一套業(yè)務(wù)規(guī)則引擎的架構(gòu)設(shè)計(jì)。

5、非功能需求

非功能性需求是指軟件產(chǎn)品為滿足用戶業(yè)務(wù)需求而必須具有且除功能需求以外的特性。一般會(huì)涉及到的有：性能需求、安全需求、可靠性需求、數(shù)據(jù)監(jiān)控需求、系統(tǒng)需求、運(yùn)行環(huán)境需求、外部接口需求等。

以性能需求為例，我們會(huì)關(guān)注每秒處理的事務(wù),功能操作的響應(yīng)時(shí)間,頁(yè)面刷新時(shí)間。以系統(tǒng)需求為例，我們會(huì)關(guān)注服務(wù)器連接失敗后的重啟次數(shù).時(shí)間引起失敗的比例 失敗時(shí)數(shù)據(jù)崩潰的可能性。

6、改進(jìn)建議

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

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

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

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

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