编辑导语：BRD，即商业需求文档，指的是基于商业目标或价值所描述的产品需求内容文档（报告），其核心的用途就是用于产品在投入研发之前，是由企业高层作为决策评估的重要依据。对于产品经理来说，对于BRD一定都不陌生。那么，B端该怎么样撰写BRD呢？

  原本我只是负责产品设计，因为公司流程、人力资源紧张等等的复杂原因，在最近 2 周接手一个新任务，协助业务方进行 BRD 产出。

  怀着紧张与期待，终于在昨日通过 BRD 的评审，大大的舒了一口气。正好做一个 B 端 BRD的复盘，分享给各位。

  BRD 是英文” Business Requirement Document “的缩写，也就是”商业需求文档“，指的就是基于商业目标或价值所描述的产品需求内容文档（报告）。

  BRD 主要给产品、运营、研发、财务、老板等管理层人看的，决定是不是要开始某个产品，是否要给你的项目投资源、人力、物力。

  PRD 是英文”Product Requirement Document“的缩写，也就是”产品需求文档“的意思， PRD文档是产品项目由“概念化”阶段进入到“图纸化”阶段的最主要的一个文档。

  PRD 是很具体的产品设计的具体方案，涉及到交互、文案、逻辑规则等说明，主要给研发、交互设计师、运营、用户等查看的，用来体现产品逻辑、功能、性能、交互设计等。

  结合 BRD 的定义，两者的关系简单来说，BRD 决定要不要做，PRD 是决定做成什么样。先决定要做了，才会有 PRD 的产出。

  通过 BRD 和 PRD 的双重审核，能很好的避免伪需求带来的资源浪费。

  在我们这个环境里，BRD 的要求是要将背景、收益、目标、需要的能力说清楚讲明白。也就是为何需要做，值不值得做，做了有哪一些好处，需要怎么做。

  ——可以是业务方直接提供的结果，也可以是自己主动参与业务调研收集而来的各种问题。

  现状要紧扣要解决的问题，不要扣过大的帽子。比如，要做一个局部迭代优化，那现状描述要围绕这个局部里业务上存在什么样的问题，而不是说整个业务上存在哪些不足。

  收益上，建议是量化指标，但是在 B 端存在诸多无法量化的情况，那采用定性的描述也能的，比如降低借款坏账风险。

  需要的能力，最重要的包含流程上要哪一些调整、涉及了哪些系统的哪几个方面进行优化。主要是一个大致的描述，不会像 PRD 里那样详细。

  在第一次负责的 BRD 中，涉及到了审批金额、审批流的调整、以及三个系统的打通。审批流中的金额比原来高了 5 倍，所以在原有业务、财务审核的基础上，提高了审批人的级别，增加了必要的复审环节，防控坏账风险。

  撰写 BRD 的模板也很重要，通过研发小哥哥的支援，找到了一个非常合适的框架，也分享给大家。包括但不限于问题描述（why）、期望目标、解决方案（What & How）、预期收益（ROI）和附录。

  这些问题的原因，写 BRD 的经验不足是一方面，更多的是对业务理解不足、了解不深。没找到正确的人、没找到核心问题，只听别人说而没有自己再去想。

  在 BRD 定稿之后，由产品同学进行产品设计。这次负责产品设计的同学是位实习生，陆陆续续提出了小 20 个问题，包括审批流中各个节点的角色是做什么的，各个系统间是如何配合的，实际的使用者是如何完成工作的等等。

  有些问题，是 BRD 里已经考虑到的，有些问题是我也没注意到的，通过四处联络，终于全部搞定，同时也对复杂的业务链路有了一个更清晰的认知，PRD 是对 BRD 的一次细化和审核。

  评委在过程中提出了2个问题，一个是业务问题，这块业务主要是做什么的；另一个是说此次涉及的流程调整，在之前刚刚调整过，为什么又要调整。

  第一个问题反映出，一个公司中不是所有人都会了解所有业务，下次写 BRD 时，需要有用户视角，方便评审快速了解业务背景。

  第二个问题反映出，关注业务的大佬们可以轻轻松松、一针见血的指出问题。所以要对业务很熟悉，才可以在评审时气定神闲的对答如流。

  旁听的我和小伙伴挺紧张的，但业务负责人答得特别溜。气势足、胆子大，很重要，向业务方小姐姐学习。

  写 BRD 最大的感受是，非常锻炼逻辑、整体全局的思考，而不像 PRD 聚焦于产品的落地方案。

  即便没有很多的文字，没有高保真的图，仍然要消耗非常多的时间梳理整体的逻辑。只有言之有物，经得起推敲，才能说服各位评审、各个业务合作方一起协作，一起解决问题。

  第一个 BRD 经过 2 周的打磨，终于评审通过；第二个 BRD 已完成，等待各位大佬的评议；第三个 BRD 已启动调研。