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

筆者作為公司內(nèi)部B端系統(tǒng)的產(chǎn)品經(jīng)理（筆者的公司不是100%互聯(lián)網(wǎng)企業(yè)，但是公司的內(nèi)部系統(tǒng)非常多），最近發(fā)現(xiàn)，公司里有些部門的業(yè)務(wù)伙伴需要數(shù)據(jù)協(xié)同的需求，就是那種需要多個系統(tǒng)一起玩兒的集成任務(wù)。每次一遇到這種復(fù)雜的任務(wù)需求，業(yè)務(wù)方總是直接找到系統(tǒng)的產(chǎn)品經(jīng)理小A，然后小A就像個翻譯一樣，把任務(wù)轉(zhuǎn)交給另一個系統(tǒng)的產(chǎn)品經(jīng)理小B。

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

原因如下：

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

現(xiàn)在我仍然記得，結(jié)果就是業(yè)務(wù)方的需求沒有完整地推進(jìn)下去，需求被迫放棄。

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

一、BRD，項目立足的基石

首先，作為產(chǎn)品經(jīng)理，對業(yè)務(wù)方提出的任何訴求，不管合理不合理，我們都應(yīng)該抱有開放的態(tài)度。

相信大家都聽說過BRD，對于內(nèi)部的B端系統(tǒng)，它的輸出角色一般為系統(tǒng)使用的業(yè)務(wù)方進(jìn)行輸出，C端可能是產(chǎn)品經(jīng)理或者體驗經(jīng)理撰寫，作為PRD材料的基礎(chǔ)。

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

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

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

二、BRD評審

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

在這次會議上，有經(jīng)驗的專家們會對BRD里的需求建設(shè)目標(biāo)、ROI分析（花多少成本能創(chuàng)造多少價值，用什么作為評估依據(jù)）對其他系統(tǒng)所需要的功能和性能要求等等進(jìn)行深入討論和質(zhì)疑。

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

三、項目立項，開始分工

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

所以這基本上意味著所有相關(guān)人員（來自不同業(yè)務(wù)部門、產(chǎn)品經(jīng)理、開發(fā)人員、測試人員、項目管理等）都已經(jīng)對需求的信息進(jìn)行了全面的討論和認(rèn)可。他們不僅了解了需求的背景和目標(biāo)，還明確了業(yè)務(wù)流程、系統(tǒng)功能和性能需求范圍，以及項目的進(jìn)度計劃和可能出現(xiàn)的風(fēng)險。

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

接下來，各方系統(tǒng)產(chǎn)品經(jīng)理會根據(jù)在BRD評審中協(xié)商好的需求內(nèi)容，各自給出自己在系統(tǒng)側(cè)的改造方案（也就是PRD文檔）。這些方案將詳細(xì)描述系統(tǒng)改造的范圍、功能需求以及其他相關(guān)的技術(shù)細(xì)節(jié)。

通過這種方式，每個團(tuán)隊都清楚地知道自己的任務(wù)和責(zé)任，從而能夠更好地進(jìn)行協(xié)作和溝通。項目才能正常推進(jìn)下去。

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