编辑导语：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协议