在日常工作中，BRD的存在十分重要，同时借助BRD评审，与会人员可以大致清楚业务方的需求是什么，以及各位系统方需要做的事情是什么
这篇文章里，作者就总结了BRD的价值所在与输出框架，一起来看看吧
笔者作为公司内部B端系统的产品经理（笔者的公司不是100%互联网企业，但是公司的内部系统非常多），最近发现，公司里有些部门的业务伙伴需要数据协同的需求，就是那种需要多个系统一起玩儿的集成任务
每次一遇到这种复杂的任务需求，业务方总是直接找到系统的产品经理小A，然后小A就像个翻译一样，把任务转交给另一个系统的产品经理小B
说实话，这种工作方式真的让人很不爽
原因如下：利益冲突：在职场里，部门之间要合作，成年人之间要交际，都得遵循一个原则，那就是利益交换
小A作为需求的第一个承接人，没有把需求负责到底，而是把问题甩给了另一个产品经理小B
小B心里可能会想，为什么别人不行，偏偏是我？难道就因为我和你直接对接？如果我付出了努力，对我有什么好处？凭什么让我来做嫁衣，帮你赚业绩？我如果把系统做出问题了，谁帮我负责？需求不清：业务在描述需求的时候，没有用书面的形式来记录，需求的目的是什么？当前的现状是什么？这就已经很让人头疼了
更让人无语的是，产品小A连需求分析都没做，就直接把业务拉去和小B开会了
这种拿业务当挡箭牌、施加压力的方式，显然是不对的
另外如果业务需求描述得不够清楚，很可能就会导致后面的系统方案设计实施出现反工
缺乏项目管理能力：项目管理能力是产品经理的能力模型之一，无论需求复杂度如何，都至少应该遵守系统集成项目的5大过程组-项目启动->项目规划->项目执行->项目监控->项目收尾
举的这个例子中很明显小A和他的业务直接跳过了项目启动的环节，想要直接进入项目执行阶段
流程管理不规范的结果往往导致责任划分不清，需求范围可能出现遗漏以及软件质量问题等
现在我仍然记得，结果就是业务方的需求没有完整地推进下去，需求被迫放弃
如果你是小B或者小A那么遇到这种问题该怎么解决呢？笔者根据自己刚结束的系统集成项目管理的考试知识，和近两年的B端产品经理的工作经验，来浅谈一下自己的看法
一、BRD，项目立足的基石首先，作为产品经理，对业务方提出的任何诉求，不管合理不合理，我们都应该抱有开放的态度
相信大家都听说过BRD，对于内部的B端系统，它的输出角色一般为系统使用的业务方进行输出，C端可能是产品经理或者体验经理撰写，作为PRD材料的基础
BRD其实相当于是项目立项过程中项目建议书和项目可行性分析报告的简要版综合体，至少需描述清楚需求的背景、目标、ROI可行性分析、需求所有干系方和职责、业务流程框架、系统功能和性能需求、里程碑计划
用经典的5W1H总结其实就是：what：项目的背景以及当前现状
when、：项目的实施计划（里程碑计划，最终实际项目完成日期可能与开始定义的完成日期有差别，不过工作久了大家就会发现项目延期是常有的事情）
who：需求所有的干系方，他们的职责是什么（这个部分得花时间识别所有需要投入资源建设系统的干系方，比如各个系统对应的产品，开发，测试，项目经理等等
所以建议新进入公司的同学一定要把公司的组织架构花一个星期的时间掌握，不管产品还是业务）
where：项目风险在什么地方？（可写可不写）
why：项目实施的理由（ROI分析，能带来什么盈利，提升多少效率或者减少多少成本，用数据说话）
how：业务流程整个业务需要哪些人？怎么做？输出的表单是什么？系统需要哪些主要功能进行支持业务？系统在特殊情况下的性能要求等等
显然在例子中，面对复杂的系统集成项目中，业务人员并没有相应的输出物就直接拉会，这样的工作方式往往很不专业，被小B直接拉黑也正常不过
凡事预则立，不立则废
二、BRD评审在经过业务人员的一系列的调研和披星戴月地写完BRD材料之后
这个时候需要协调项目经理资源上PMO（项目管理办公委员会）会议进行评审，这个时候一定要将BRD里面涉及到的所有干系方都拉到会议中去，俗称BRD评审，让所有人都知道业务方的需求是什么，能带来什么价值，各位系统方需要做的事情是什么？在这次会议上，有经验的专家们会对BRD里的需求建设目标、ROI分析（花多少成本能创造多少价值，用什么作为评估依据）对其他系统所需要的功能和性能要求等等进行深入讨论和质疑
项目一旦通过，在BRD的基础上理论上会形成项目章程文档（内容上与BRD大差不差），但是在笔者工作中一般会以BRD的以通过评审状态（也就是BRD签署）来代替项目章程
三、项目立项，开始分工BRD评审通过之后（项目章程输出之后）也就意味着确定了该项目的合法地位，不管小B有多少个不乐意都得硬着头皮做（开个玩笑）
所以这基本上意味着所有相关人员（来自不同业务部门、产品经理、开发人员、测试人员、项目管理等）都已经对需求的信息进行了全面的讨论和认可
他们不仅了解了需求的背景和目标，还明确了业务流程、系统功能和性能需求范围，以及项目的进度计划和可能出现的风险
在这个阶段，小B以及其他可能涉及系统改造或资源投入的小C或小D，都清晰地了解了自己需要负责的需求范围，需要做什么内容
接下来，各方系统产品经理会根据在BRD评审中协商好的需求内容，各自给出自己在系统侧的改造方案（也就是PRD文档）
这些方案将详细描述系统改造的范围、功能需求以及其他相关的技术细节
通过这种方式，每个团队都清楚地知道自己的任务和责任，从而能够更好地进行协作和沟通
项目才能正常推进下去
各位同学欢迎你们在评论区讨论哦，也说说自己在需求管理中遇到的烦心事儿
本文由 @Zia 原创发布于人人都是产品经理
未经许可，禁止转载
题图来自Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务

（图片来源网络，侵删）