編輯導語：BRD，即商業需求文檔，指的是基于商業目標或價值所描述的產品需求內容文檔（報告），其核心的用途就是用于產品在投入研發之前，是由企業高層作為決策評估的重要依據。對于產品經理來說，對于BRD一定都不陌生。那么，B端應該如何撰寫BRD呢？

原本我只是負責產品設計，因為公司流程、人力資源緊張等等的復雜原因，在最近 2 周接手一個新任務，協助業務方進行 BRD 產出。

懷著緊張與期待，終于在昨日通過 BRD 的評審，大大的舒了一口氣。正好做一個 B 端 BRD的復盤，分享給各位。

一、BRD 定義

BRD 是英文” Business Requirement Document “的縮寫，也就是”商業需求文檔“，指的就是基于商業目標或價值所描述的產品需求內容文檔（報告）。

BRD 主要給產品、運營、研發、財務、老板等管理層人看的，決定是否要開始某個產品，是否要給你的項目投資源、人力、物力。

二、BRD 與 PRD 的關系

PRD 是英文”Product Requirement Document“的縮寫，也就是”產品需求文檔“的意思， PRD文檔是產品項目由“概念化”階段進入到“圖紙化”階段的最主要的一個文檔。

PRD 是非常具體的產品設計方案，涉及到交互、文案、邏輯規則等說明，主要給研發、交互設計師、運營、用戶等查看的，用來體現產品邏輯、功能、性能、交互設計等。

結合 BRD 的定義，兩者的關系簡單來說，BRD 決定要不要做，PRD 是決定做成什么樣。先決定要做了，才會有 PRD 的產出。

通過 BRD 和 PRD 的雙重審核，可以很好的避免偽需求帶來的資源浪費。

三、BRD 如何寫

在我們這個環境里，BRD 的要求是要將背景、收益、目標、需要的能力說清楚講明白。也就是為什么要做，值不值得做，做了有哪些好處，需要怎么做。

背景是從現狀、問題來出發，那這些來自哪？

——可以是業務方直接提供的結果，也可以是自己主動參與業務調研收集而來的各種問題。

現狀要緊扣要解決的問題，不要扣過大的帽子。比如，要做一個局部迭代優化，那現狀描述要圍繞這個局部里業務上存在什么問題，而不是說整個業務上存在哪些不足。

收益上，建議是量化指標，但是在 B 端存在諸多無法量化的情況，那采用定性的描述也是可以的，比如降低借款壞賬風險。

需要的能力，主要包括流程上需要哪些調整、涉及了哪些系統的哪些方面進行優化。主要是一個大致的描述，不會像 PRD 里那樣詳細。

在第一次負責的 BRD 中，涉及到了審批金額、審批流的調整、以及三個系統的打通。審批流中的金額比原來高了 5 倍，所以在原有業務、財務審核的基礎上，提高了審批人的級別，增加了必要的復審環節，防控壞賬風險。

撰寫 BRD 的模板也非常重要，通過研發小哥哥的支援，找到了一個非常合適的框架，也分享給大家。包括但不限于問題描述（why）、期望目標、解決方案（What & How）、預期收益（ROI）和附錄。

四、BRD Review過程中發現的問題

第一版 BRD 寫完之后，leader review時指出了如下問題：

• 背景中的帽子扣得過大（上文中已經提到）；
• 流程是最原始、舊的版本，而不是最新的流程；
• 要解決的問題中有一個根本不存在，有一部分預期收益，在此次優化中也不能體現。

這些問題的原因，寫 BRD 的經驗不足是一方面，更多的是對業務理解不足、了解不深。沒有找到正確的人、沒有找到核心問題，只聽別人說而沒有自己再去想。

五、PRD & BRD 協作過程中發現的問題

在 BRD 定稿之后，由產品同學進行產品設計。這次負責產品設計的同學是位實習生，陸陸續續提出了小 20 個問題，包括審批流中各個節點的角色是做什么的，各個系統間是如何配合的，實際的使用者是如何完成工作的等等。

有些問題，是 BRD 里已經考慮到的，有些問題是我也沒有注意到的，通過四處聯絡，終于全部搞定，同時也對復雜的業務鏈路有了一個更清晰的認知，PRD 是對 BRD 的一次細化和審核。

六、BRD 評審過程中發現的問題

昨天進行了BRD的評審，由業務負責人主講，我和另一位小伙伴旁聽。

評委在過程中提出了2個問題，一個是業務問題，這塊業務主要是做什么的；另一個是說此次涉及的流程調整，在之前剛剛調整過，為什么又要調整。

第一個問題反映出，一個公司中不是所有人都會了解所有業務，下次寫 BRD 時，需要有用戶視角，方便評審快速了解業務背景。

第二個問題反映出，關注業務的大佬們可以輕輕松松、一針見血的指出問題。所以需要對業務非常熟悉，才可以在評審時氣定神閑的對答如流。

旁聽的我和小伙伴挺緊張的，但業務負責人答得特別溜。氣勢足、膽子大，非常重要，向業務方小姐姐學習。

最終評審順利通過~~

七、參與 BRD 的收獲

寫 BRD 最大的感受是，非常鍛煉邏輯、整體全局的思考，而不像 PRD 聚焦于產品的落地方案。

即便沒有很多的文字，沒有高保真的圖，仍然需要花費非常多的時間梳理整體的邏輯。只有言之有物，經得起推敲，才能說服各位評審、各個業務合作方一起協作，一起解決問題。

八、最后

第一個 BRD 經過 2 周的打磨，終于評審通過；第二個 BRD 已經完成，等待各位大佬的評議；第三個 BRD 已啟動調研。

成為 BRD 的專家，成為 為業務解題的專家，還遠么？

不遠~~

本文由 @涼涼Lxy 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議