編輯導語：撰寫一份合理有效的產品需求文檔，有助于產品團隊進行后續(xù)管理，進而在后期有序地推動產品迭代升級。本篇文章里，作者總結了撰寫B(tài)端產品需求文檔的方法以及相關小貼士，也許讀完之后，你能更清晰地了解PRD撰寫。

從各大招聘市場來看，B端產品經理需求日漸旺盛，越來越多的產品新人和C端產品轉而投入了toB行業(yè)。在這樣的大背景下，越來越多的產品新人需要學習如何撰寫B(tài)端產品需求文檔（以下簡稱PRD：Product Requirement Document）。

那么，B端產品PRD到底好不好上手撰寫呢？

答案是否定的。最近，筆者在招聘產品實習生時發(fā)現(xiàn)了這樣一種現(xiàn)象：大部分實習生的初作品都是圍繞校園生活的C端產品，鮮有B端產品文檔；即使有一部分新人報名參加了一些產品培訓，其作品也大多以C端為主。

這個現(xiàn)象從側面說明了注重交互和用戶體驗的C端較好入門，因為產品經理本身就可以嘗試代入角色進行體會。而角色權限眾多、業(yè)務龐亂、流程復雜的B端產品則為新人樹立了一道無形的門檻，只有厘清和理解業(yè)務之后，才可能撰寫出一份高質量的B端PRD。

因此，筆者想和剛剛入行B端亦或是頭疼寫文檔的你分享自己的PRD框架，幫助你又快又好地撰寫一份高質量PRD。此外，還會額外與大家分享2個非常實用的PRD撰寫小tips，幫助你在保證質量和準確度的前提下，提升撰寫速度。

話不多說，直接上干貨。

一、我們?yōu)槭裁匆獙慞RD？

PRD的本質是文檔，而文檔的本質只是大腦產物的一種承載形式。那我們?yōu)槭裁床豢梢允褂每谑觥⒗L制草圖等方式來進行溝通和信息傳遞呢？

并不是不行，在產品初期和團隊人員較為精簡的情況下，有些公司會使用口述和手繪草圖等方式進行溝通。但隨著時間的流逝和團隊成員的壯大，這些方式不便于大范圍傳播和歸檔，而落筆有聲的文檔則可以肩負起記錄、參照和流傳的責任。

因此，當達到一定的產品和團隊階段，我們就需要通過PRD來保證多方目標和需求理解一致，讓整個迭代井然有序的運行。

那么，我們寫產品需求文檔是為了讓讀者了解什么呢？

首先，B端PRD的讀者和C端有很大差異。

B端PRD的讀者除了研發(fā)、老板之外，還包含需求方。不同于C端，B端的用戶往往是較為明確的一些職位和角色，他們會直接將一些需求和問題反饋至公司的銷售或是客服團隊。這就意味著，公司內的銷售部門、業(yè)務部門、客服部門等都會是用戶or客戶的傳話筒，從而成為我們的需求方。

其次，只有明確了讀者范圍，我們才能寫出他們真正需要了解的內容。在參考一些前輩的思路之后，我們需要向讀者傳遞下列3個方面的內容：

• 我們在解決xx用戶在xx場景下的xx問題；
• 我們使用xx資源、提出了xx方案，并期望收獲xx結果；
• 實現(xiàn)這個方案給我們帶來了xx價值（用戶價值、商業(yè)價值、公司價值）。

在上述3點中，上游的需求方（客戶、銷售部門、客服部門等）需要重點了解我們在解決哪些用戶的問題？場景是什么？大致的解決方案是什么樣的？下游的實現(xiàn)方（研發(fā)、測試等）則需要大致上了解用戶的需求場景，并重點關注實現(xiàn)方案及迭代目標。

二、PRD框架及內容

前面向大家傳遞了PRD的價值和目標，第二部分就來和大家細講一下如何組織PRD的內容、每一部分的側重點是什么以及怎樣才能又好又快地撰寫一份B端PRD。

如下圖所示，筆者的B端PRD框架整體分為三大模塊：項目信息、需求&調研、方案信息。下面我們分別就3大模塊進行詳細介紹。

1. 項目信息

一次迭代就是一個小項目。因此，這里的項目信息則是我們從項目經理的角度出發(fā)，向各方闡明本次迭代的總體規(guī)劃、團隊資源及職責、并對相關評審及變更做出記錄。

1）迭代人員

按照不同職責列出項目迭代負責人及成員，并明確各個成員的職責。

2）評審記錄

用戶記錄需求評審的里程碑會議及結論。這里需要提醒大家一點，寫需求評審記錄時除了記錄那些確定要做的需求之外，還需要記錄確認不做的需求并盡量說明決策原因。

記錄決策原因是一個幫助我們回顧和復盤的好方法。依據(jù)幾個月之前的決策思路，我們能很快回憶起當時的出發(fā)點，在對比當前的實際現(xiàn)狀之后，能更好地尋求成長和突破。

3）變更記錄

用于記錄迭代正式開始后的需求變更，便于追溯和復盤。其中，變更類型包含但不限于產品遺漏、邏輯設計缺陷、研發(fā)評估遺漏、老邏輯影響、新增業(yè)務、臨時方案趕工、版本拆分等等。

2. 需求&調研

利用金字塔原理，我們先和大家同步了項目的大致規(guī)劃，讓大家心里有了一個底。這一部分，我們就來和團隊同步我們是「在解決誰在什么場景下的哪些問題」？

不同于模棱兩可、千人千面的C端產品，B端產品往往有較為明確的需求方和用戶。那么，我們還有必要向團隊再闡述一遍需求到底是什么嗎？

當然有必要。

一是因為實現(xiàn)方（研發(fā)、測試等）對需求不了解，我們有必要向他們傳遞需求場景，幫助他們更好設計和架構業(yè)務。

二是因為需求方口述出來的并不一定是客戶真正的需求。客戶往往會提出一個在他們認知范圍內較好的解決方案，告訴需求方“我們缺這個功能、我們想要這個功能、沒有這個功能不行”。但在真正了解之后，我們往往會發(fā)現(xiàn)客戶真正的需求不在于此，可能通過別的功能還能更好地解決問題。

這就說明我們需要對需求方收集來的客戶反饋進行二次甄別和挖掘，最終再到PRD中把問題背后的本質闡述出來，而僅僅照搬用戶反饋則是一種極不負責任的行為。

如下圖所示：在需求&調研部分，我們將整體的內容劃分為調研信息和需求場景2大模塊。

一次迭代的調研信息可以分為用戶調研和競品調研，如果還包含其他類型的調研（例如行業(yè)調研），可自行加入其中）。

1）用戶調研

需求來源于客戶。因此，我們要先通過調研客戶來初步了解需求。調研報告的內容包括但不限于時間、調研對象、調研數(shù)量、客戶類型、調研結論、調研人員等，具體視實情而定。

2）競品調研

知己知彼，百戰(zhàn)不殆。在著手實現(xiàn)之前，我們更需要對競爭對手的情況進行調研。競品調研內容包括但不限于調研時間、調研數(shù)量、競品名稱、調研結論等。

這里插一句，常常有人會問競品調研有沒有什么模版，需要做哪些事情？答案其實就一句話：調研只是手段，只要明確了調研目標，從而也就確立了粒度和內容。

3）需求場景

在通過問卷、訪談、觀察等調研手段之后，我們便能夠初步歸納出用戶的需求場景。當然，只有產品經理知道是遠遠不夠的，我們還需要將這些成果同步給團隊，保證讓大家就需求場景的理解達成一致，即告訴大家我們在解決xx用戶在xx場景下的xx問題。

這里，筆者推薦用戶故事和用例圖2種工具。

故事往往充滿感情，更立體也更容易打動人。因此，用戶故事User story是從感性的角度出發(fā)，讓我們向大家講述一個典型用戶的故事：他們是一群怎樣的用戶、他們在什么場景下遇到了什么問題、他們的情緒怎樣、現(xiàn)在他們是怎么處理這些問題的。

而源自于UML的用例圖則更為理性。它能清楚地告訴研發(fā)本次迭代中涉及到哪些角色、每類角色的需求及邊界、不同需求之間的關系是什么等等。

通過第二部分的需求&調研模塊，能夠幫助團隊成員在腦海里樹立一個亟待解決問題的用戶形象出來，我們能夠知道他有哪些問題、也能嘗試感知他的情緒。

3. 方案信息

方案指我們需要做哪些功能來幫助用戶解決問題。從篇幅上來講，方案信息是整個PRD的大頭部分，也是新人最為關注的內容；但隨著經驗的增長，處于實現(xiàn)層的方案文檔撰寫能力將逐漸轉化為一種基礎能力，而不是競爭性能力。

可能有些人會對文檔撰寫不屑一顧，但筆者認為這是產品經理對外的第一張名片。產品經理本身是一種無授權的團隊leader，我們需要通過遞出一張張合格甚至優(yōu)秀的名片來建立團隊影響力和信任感。因此，一個好的文檔撰寫能力至關重要。

我們將方案信息劃分為3大版塊：方案規(guī)劃、方案內容、埋點信息。

1）方案規(guī)劃

在著手開工之前，我們先需要向團隊講清楚這一次我們大致準備怎么做。方案規(guī)劃的內容包含但不限于分期規(guī)劃、滿足場景、需求清單（粗略版）、目標價值、衡量指標、風險評估等。

• 分期規(guī)劃：B端客戶的需求往往龐亂而復雜，當我們面對的客戶群體標準化程度較低、個性化需求較多時，可能會選擇分期解決、小步快跑，先滿足核心主流場景，再逐次完善分支異常場景。所以，當我們決定分期解決問題時，就需要提前向大家告知清楚。
• 目標價值：指該方案上線后能夠為用戶帶來什么價值、給公司又能帶來什么樣的商業(yè)價值。
• 衡量指標：常言之，無法衡量就無法優(yōu)化。因此，我們需要明確出1-3個能夠真正衡量方案價值的指標，便于我們未來進行優(yōu)化和迭代。
• 風險評估：指迭代上線前，需要對整個迭代可能遭遇或造成的風險進行評估，包含技術風險、用戶體驗變更風險、數(shù)據(jù)修復風險、并發(fā)風險等。

筆者曾經有一次慘痛的迭代教訓就和缺少風險評估有關。那次迭代是對原有的一些“糟糕”交互進行了優(yōu)化，當時并沒有考慮到是否會對用戶原有使用習慣造成影響，最終上線后，“收獲”了一大批的負面反饋。如果能提前對此有所評估，也許就會考慮通過一鍵切換回舊版本等一些緩和性的方案來進行平滑過渡了。

2）需求清單

需求清單指我們需要滿足哪些需求、各需求的優(yōu)先級是什么樣的。其中包含但不限于需求名稱、需求描述、需求類型、所屬模塊、優(yōu)先級等。

• 需求名稱：指核心需求的簡稱、需求描述需說明具體的功能范圍及內容。
• 需求類型：分為功能、優(yōu)化模塊：指該核心需求所歸屬的業(yè)務模塊需求優(yōu)先級說明：P0-優(yōu)先級最高的需求；P1-版本核心需求；P2-與核心需求存在關聯(lián)關系的業(yè)務調整；P3-其他調整需求；T0-承諾上線需求（優(yōu)先級分明，避免全部需求都為P0）。

3）業(yè)務架構/流程

• 業(yè)務架構：描述業(yè)務的整體架構、業(yè)務模型、數(shù)據(jù)關系等（選寫，視版本所需確定）業(yè)務流程：前后端通用的核心業(yè)務流程繪圖標準：基本符合主流繪圖標準，關系/條件描述清晰無歧義。關于業(yè)務架構/流程這里，筆者推薦3種比較常見的UML圖：活動圖、狀態(tài)機圖、時序圖。
• 活動圖：按照時間順序將活動的邏輯整理出來，與我們常見的流程圖類似；
• 狀態(tài)機圖：圍繞一個事物的狀態(tài)為中心來講述流程；
• 時序圖：在描述流程時，能夠清晰地定義角色的具體職責邊界和通信交互；

具體UML的介紹，可以參考此前筆者寫的這篇《一文解決產品經理對UML的全部疑問》。

4）頁面說明

在描述好業(yè)務邏輯之后，就需要對頁面中的元素、組件、交互進行一定的說明。C端產品經理往往會花費較多的時間在于細節(jié)體驗和交互之上，而B端產品則全然不同。

因為toB行業(yè)業(yè)務邏輯龐大、流程復雜，產品經理的核心要務就是梳理業(yè)務和流程，交互和體驗則更多是錦上添花的作用。用一句客戶的話來說“業(yè)務都跑不動了，細節(jié)做那么好有什么用？”因此，對于B端產品經理而言，我們要合理分配好文檔中業(yè)務流程和交互體驗上的精力。

在寫頁面注釋這里，筆者為大家提供2個非常實用的小tips，幫助你在保證質量的前提下節(jié)約大量的時間。

Tip1: 將重復邏輯創(chuàng)建為一個母版master

Axure中的母版可以簡單理解為公共元件模板，將母版應用到相應頁面中后，母版內容或樣式發(fā)生變化，那么引用母版的頁面內容或樣式同樣會跟著變化，常用于制作頁面頭部或底部內容。因此 ，母版master常常被我們用于創(chuàng)建一些組件樣式或標準頁等，例如web端標準底頁、iPhone6標準底頁等。

但是，筆者這里要分享的是將一些重復性的邏輯也可以整理為母版。選中某段注釋文字，右鍵點擊創(chuàng)建母版Create Master，即可生成如下圖所示的邏輯母版：

這樣做有什么好處呢？

① 重復的組件或模塊的邏輯注釋只用寫一遍，第二次第三次直接拖拽母版使用即可，無須多次重復撰寫。

如上圖所示，若一次迭代中有3、5處都需要顯示這個沖突提示氣泡，那么我們只需寫一次，后續(xù)直接找到母版拖拽到頁面里即可。

② 文檔免不了要多次修改，那么當這些重復邏輯一旦被修改，我們就只能挨個去窮盡，而且很容易出現(xiàn)遺漏。

但是如果使用了注釋母版，那么只需要在母版處一次修改，剩余引用母版的邏輯注釋部分將自動變更。不僅減輕了工作量，更能幫助我們避免遺漏、保證重復邏輯的統(tǒng)一性。

Tips2: 將標準化組件的邏輯注釋整理為元件庫libraries

我們常常會去Axure社區(qū)及各大資源平臺搜集各式各樣的元件庫lib，例如element、antd、iOS、Android的標準元件庫等，方便自己在畫圖時可以快速進行樣式引用。

而B端產品以PC端、Web端為主，樣式整體較少（以表單、tab、列表等為主），同時相對較為標準化。因此，我們不僅可以將這些標準化組件的樣式整理為元件庫lib，也可以將這些組件對應的邏輯注釋整理為元件庫lib。

如下圖所示，當我們頁面中遇到一個下拉菜單的選項時，就可以直接拖拽元件庫中對應的注釋到頁面中來。

通過提煉各類篩選組件、搜索組件、表單組件等的邏輯交互，不僅能夠提升我們對前端組件的抽象理解能力，同時在撰寫文檔過程中也可以拖拽即用，能夠大大減輕工作量并幫助我們避免邏輯遺漏。

5）埋點說明

埋點說明包含但不限于埋點人群、事件、觸發(fā)條件、對應業(yè)務價值、指標預測及后續(xù)方案等。這里就不展開講了，但埋點的重點是一定要先想好埋點的目標是什么，然后再去規(guī)定對應指標。

That’s all～以上就是筆者對B端產品文檔的一些思考和小訣竅。

本次分享的初衷是給大家提供一個思參考，最建議的方式是在積累一定經驗后花1、2天做一個適合自己業(yè)務和使用習慣的模版及元件庫。文檔不是終點，而是起點。善用工具，能夠幫助我們釋放大腦、留出更多的時間進行思考。

作者：冰冰醬；公眾號：產品冰冰醬

本文由 @冰冰醬 原創(chuàng)發(fā)布于人人都是產品經理，未經許可，禁止轉載

題圖來自Unsplash，基于CC0協(xié)議