在日常工作中，BRD的存在十分重要，同時借助BRD評審，與會人員可以大致清楚業務方的需求是什么，以及各位系統方需要做的事情是什么。這篇文章里，作者就總結了BRD的價值所在與輸出框架，一起來看看吧。

筆者作為公司內部B端系統的產品經理（筆者的公司不是100%互聯網企業，但是公司的內部系統非常多），最近發現，公司里有些部門的業務伙伴需要數據協同的需求，就是那種需要多個系統一起玩兒的集成任務。每次一遇到這種復雜的任務需求，業務方總是直接找到系統的產品經理小A，然后小A就像個翻譯一樣，把任務轉交給另一個系統的產品經理小B。

說實話，這種工作方式真的讓人很不爽。

原因如下：

1. 利益沖突：在職場里，部門之間要合作，成年人之間要交際，都得遵循一個原則，那就是利益交換。小A作為需求的第一個承接人，沒有把需求負責到底，而是把問題甩給了另一個產品經理小B。小B心里可能會想，為什么別人不行，偏偏是我？難道就因為我和你直接對接？如果我付出了努力，對我有什么好處？憑什么讓我來做嫁衣，幫你賺業績？我如果把系統做出問題了，誰幫我負責？
2. 需求不清：業務在描述需求的時候，沒有用書面的形式來記錄，需求的目的是什么？當前的現狀是什么？這就已經很讓人頭疼了。更讓人無語的是，產品小A連需求分析都沒做，就直接把業務拉去和小B開會了。這種拿業務當擋箭牌、施加壓力的方式，顯然是不對的。另外如果業務需求描述得不夠清楚，很可能就會導致后面的系統方案設計實施出現反工。
3. 缺乏項目管理能力：項目管理能力是產品經理的能力模型之一，無論需求復雜度如何，都至少應該遵守系統集成項目的5大過程組- 項目啟動->項目規劃->項目執行->項目監控->項目收尾。舉的這個例子中很明顯小A和他的業務直接跳過了項目啟動的環節，想要直接進入項目執行階段。流程管理不規范的結果往往導致責任劃分不清，需求范圍可能出現遺漏以及軟件質量問題等。

現在我仍然記得，結果就是業務方的需求沒有完整地推進下去，需求被迫放棄。

如果你是小B或者小A那么遇到這種問題該怎么解決呢？筆者根據自己剛結束的系統集成項目管理的考試知識，和近兩年的B端產品經理的工作經驗，來淺談一下自己的看法。

一、BRD，項目立足的基石

首先，作為產品經理，對業務方提出的任何訴求，不管合理不合理，我們都應該抱有開放的態度。

相信大家都聽說過BRD，對于內部的B端系統，它的輸出角色一般為系統使用的業務方進行輸出，C端可能是產品經理或者體驗經理撰寫，作為PRD材料的基礎。

BRD其實相當于是項目立項過程中項目建議書和項目可行性分析報告的簡要版綜合體，至少需描述清楚需求的背景、目標、ROI可行性分析、需求所有干系方和職責、業務流程框架、系統功能和性能需求、里程碑計劃。用經典的5W1H總結其實就是：

1. what：項目的背景以及當前現狀。
2. when、：項目的實施計劃（里程碑計劃，最終實際項目完成日期可能與開始定義的完成日期有差別，不過工作久了大家就會發現項目延期是常有的事情）。
3. who：需求所有的干系方，他們的職責是什么（這個部分得花時間識別所有需要投入資源建設系統的干系方，比如各個系統對應的產品，開發，測試，項目經理等等。所以建議新進入公司的同學一定要把公司的組織架構花一個星期的時間掌握，不管產品還是業務）。
4. where：項目風險在什么地方？（可寫可不寫）。
5. why：項目實施的理由（ROI分析，能帶來什么盈利，提升多少效率或者減少多少成本，用數據說話）。
6. how：業務流程整個業務需要哪些人？怎么做？輸出的表單是什么？系統需要哪些主要功能進行支持業務？系統在特殊情況下的性能要求等等。

顯然在例子中，面對復雜的系統集成項目中，業務人員并沒有相應的輸出物就直接拉會，這樣的工作方式往往很不專業，被小B直接拉黑也正常不過。凡事預則立，不立則廢。

二、BRD評審

在經過業務人員的一系列的調研和披星戴月地寫完BRD材料之后。這個時候需要協調項目經理資源上PMO（項目管理辦公委員會）會議進行評審，這個時候一定要將BRD里面涉及到的所有干系方都拉到會議中去，俗稱BRD評審，讓所有人都知道業務方的需求是什么，能帶來什么價值，各位系統方需要做的事情是什么？

在這次會議上，有經驗的專家們會對BRD里的需求建設目標、ROI分析（花多少成本能創造多少價值，用什么作為評估依據）對其他系統所需要的功能和性能要求等等進行深入討論和質疑。

項目一旦通過，在BRD的基礎上理論上會形成項目章程文檔（內容上與BRD大差不差），但是在筆者工作中一般會以BRD的以通過評審狀態（也就是BRD簽署）來代替項目章程。

三、項目立項，開始分工

BRD評審通過之后（項目章程輸出之后）也就意味著確定了該項目的合法地位，不管小B有多少個不樂意都得硬著頭皮做（開個玩笑）。

所以這基本上意味著所有相關人員（來自不同業務部門、產品經理、開發人員、測試人員、項目管理等）都已經對需求的信息進行了全面的討論和認可。他們不僅了解了需求的背景和目標，還明確了業務流程、系統功能和性能需求范圍，以及項目的進度計劃和可能出現的風險。

在這個階段，小B以及其他可能涉及系統改造或資源投入的小C或小D，都清晰地了解了自己需要負責的需求范圍，需要做什么內容。

接下來，各方系統產品經理會根據在BRD評審中協商好的需求內容，各自給出自己在系統側的改造方案（也就是PRD文檔）。這些方案將詳細描述系統改造的范圍、功能需求以及其他相關的技術細節。

通過這種方式，每個團隊都清楚地知道自己的任務和責任，從而能夠更好地進行協作和溝通。項目才能正常推進下去。

各位同學歡迎你們在評論區討論哦，也說說自己在需求管理中遇到的煩心事兒。