编辑导语：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 的经验不足是一方面，