PRD寫得好看還不如需求把握得準確，PRD寫得好看還不如體驗設計得順暢。

工欲善其事必先利其器。

產品需求文檔（以下都簡稱PRD）對于大多數產品新人來說都并不陌生，它是產品工作中非常重要的一部分。一份PRD可以直接的看出一個產品人對自己所負責的產品的整體把控能力，也能間接的看出產品人的產品思維，表現出產品人對某一垂直行業的專業知識廣度和需求洞察能力。

而PRD從本質上是服務于產品執行的一種工具，它并沒有一種嚴格上的定式，不同產品不同項目都有這樣或那樣的區別，而只有能夠最大程度的服務好產品的PRD才是好的PRD。

一個好的工匠是擅長于利用和打造工具的，產品人亦然。產品人除了要擅于打造PRD這個工具之外，還要善于利用它去服務產品的執行工作。

那么，接下來我將以我的個人經驗分享一下我打造PRD這一工具的方法論。希望各位可以求同存異，不斷迭代優化。

一、頭部。

1、文件撰寫相關信息。

這里的相關信息都是非常常規的信息，包括文件名稱、文件撰寫人、撰寫日期、文件版本號、文件審核人、文件審核日期等。

2、文件聲明。

一般是文件使用權限聲明、文件保密聲明。

3、文件版本與修訂記錄

PRD跟產品一樣也需要不斷的迭代更新優化，那么每一次PRD版本的更新與修改都需要做詳細的記錄。

如圖：

 

版本說明.png

這里的AMD分別代表：添加（added）、修改（modified）、刪除（deleted），每次版本的相應操作都必須做出對應的標注。

二、前言

1、編寫目的。

這部分主要闡述PRD的作用：

• 開發人員開發依據
• 設計人員輸入源
• 產品經理跟進產品執行實現程度的依據
• 測試人員編寫功能測試用例的輸入源
• 外部人員產品理解或執行的依據
• 等等

2、產品（項目）周期。

這部分則是闡述清楚產品需求、設計、開發、測試、上線等的相關周期（可用甘特圖表示）。一個項目開發周期確定后，沒有特殊情況下就必須嚴格把控和執行項目進度。

附上簡單甘特圖：

 

3、相關參考文檔資料。

附上相關參考文檔的信息。以便相關人員獲取更詳細的信息。

如圖：

 

三、產品（項目）概況

1、產品（項目）簡述。

此部分主要是從整體的角度來去闡述一個項目或者產品，包括產品或項目解決的需求、包含哪些產品、包含哪些功能

1.1、產品或項目的整體描述。

整體上描述該產品或項目的全局，從解決的問題、如何解決問題、所創造的價值等方面進行闡述。

1.2、描述項目中包含的產品。

如果是一個相對較大的項目則需要分別闡述清楚項目下擁有的各個產品。比如，從客戶端來說，有PC端、微信端、ios和安卓端；從用戶端來說，有B端、有C端。簡述各個產品在項目中發揮的作用。

1.3、描述產品中包含的功能。

接下則闡述各個產品所包含的主要功能。

如：對于某款K12實時一對一答疑輔導產品來說，他有老師端和學生端兩款產品。老師端的主要功能有為學生解題。學生端的主要功能為上傳問題。

2、專有名詞解釋。

此部分主要解釋產品中涉及的相關專業名詞的解釋。

如下圖，主要為教育機構中的業務專有名詞：

 

3、產品（項目）用戶角色描述。

當今互聯網產品中，產品的用戶都不止一個，PRD需在概況中描述清楚產品中涉及的每一種用戶角色。
如下圖：主要為教育機構中的各種業務角色：

 

4、產品（項目）總體架構。

此處畫出產品的總體功能結構圖：功能結構圖根據產品的每個功能逐一深入畫出結構圖。
如下圖：為K12教育產品學霸君的功能結構圖；

 

5、產品（項目）業務流程圖。

此處畫出產品總體的功能業務流程圖：（該流程圖為現階段搜提類K12在線學習APP的大致業務流程，流程中并沒有對子流程進行細化。實際工作PRD中的細化子流程或文檔可在功能性需求中詳細附上并詳細描述。）

 流程圖中的圖示：

 

四、產品功能性需求

任何產品的需求都可以分為功能性需求和非功能性需求兩類。

• 功能性需求一般是指產品中具體的、用戶可使用和感知的功能需求，如登錄注冊功能、導航功能、文件下載功能、支付功能等等。
• 非功能性需求則一般偏向產品的性能需求，如產品響應速度需求、產品測試環境需求、產品的安全需求等等。

通俗的理解，就好比一部電腦功，能性需求是它能上網、能看電影、能聽歌、能玩游戲等等；而非功能性需求則是它的CPU是雙核還是四核，內存是4G還是8G，電腦構成材質是塑料還是金屬等等。

某種程度上，一個產品的功能性需求決定了這個產品能不能用，一個產品的非功能性需求則決定了這個產品能用多久，而一個產品好不好用則是功能性需求及非功能性需求的雙重體現。

以下將以“注冊登錄”功能為例，講解在PRD中一個功能性需求的闡述。功能性需求的闡述也是一份PRD中最重要的部分，在實際工作中功能性需求的描述占了整個PRD的50%以上。

1、需求編號及名稱。

可根據需求的類型、需求的名稱以及需求的優先級對需求進行編號。

需求的類型。如： I=輸入需求(Input)； O=輸出需求(Output)； W=界面需求(Window)； R=角色及權限(Role)

需求的名稱。如：登錄=longin；支付=payment。當然，除了大部分通用的功能需求外，大部分的需求名字是配有專業名詞的。如：課程消耗=CoursesConsumption。

優先級。則可直接按序號排列。

2、需求說明。

對某一項需求功能進行描述，描述清楚功能的使用者、使用場景、使用動作與步驟、使用結果。

如：登錄需求：該需求滿足了用戶在未登錄的情況下，觸發相關條件，輸入用戶id及密碼即可完成用戶登錄。

3、功能的用戶用例。

這里將以用戶主動登錄的一個功能作為例子，展示功能需求中的用戶用例。

 

相關概念的解釋：

• 前置條件：即要完成當前動作，必須經過的上一動作。
• 基本事件流：用戶在正常情況下無卡點完成某一動作的全部流程。
• 其他事件流：用戶在某動作的操作中操作有誤，由操作中的錯誤可能引發的相關流程情況。
• 異常事件流：異常事件流導致該用例無法完成。
• 后置條件：當前動作順利完成后抵達的頁面或觸發的條件。

4、功能流程。

同樣的將以登錄業務流程作為例子展示登錄業務中的流程圖。該流程圖詳細地展示了登錄過程中的所有流程可能，可詳細查看。

 

5、產品界面原型。

此產品界面原型為上面所講述的用戶用例中的產品界面原型：

 

通常的情況下，在原型界面需要附上各個部件的文字解釋以及頁面的動作和跳轉邏輯闡述。因為此登錄功能為較常用功能，且用戶用例中也已經描述較為清楚了，故此處不做文字解釋及跳轉邏輯闡述。

6、相關字段。

每個功能需求須要寫清楚該功能需求下包含的相關字段。字段則是指一個對象中包含的相關變量。

如：對于一個學生用戶來說，他的字段可能包含以下幾種：id、username（用戶名）、手機號碼、qq、年級、所在學校等等

五、非功能性需求

1、產品性能需求。

• 用戶承載量需求。如：支持2萬用戶同時在線。
• 產品響應速度需求。如：在網絡狀況良好的情況下，頁面跳轉速度不超過5秒。

2、測試環境需求。

• 產品測試環境與正式上線環境的需求。

3、產品數據統計需求。

• 自建的統計數據需求。如：相關事件埋點統計需求。
• 接入第三方數據統計接口需求。如：接入友盟統計。

4、安全性需求。

• 惡意注冊防范需求。
• 惡意刷數據防范需求

5、產品兼容性需求。

• 客戶端。如：各種主流手機設備均可正常使用，無顯示異常，無閃退。
• WEB端。如：各種主流的尺寸及終端的WEB端顯示的頁面均無顯示異常。

雖然我在文章開頭寫到“一份PRD可以直接的看出一個產品人對自己所負責的產品的整體把控能力，也能間接的看出產品人的產品思維，表現出產品人對某一垂直行業的專業知識廣度和需求洞察能力”，但是，工具畢竟是工具，他只是服務于產品的執行，闡述一種產品執行思路。做產品的根本是需求和體驗，再好的PRD也不能幫你找準用戶體驗，再清晰的PRD也不能幫你理順用戶體驗。所以，話說回來，PRD寫得好看還不如需求把握得準確，PRD寫得好看還不如體驗設計得順暢。